Web Services and SCADA

Web services can be another method for connectivity to SCADA and MES systems. They can retrieve tomorrow's weather, the price of stocks or commodities, the time of sunrise and sunset, and a slew of other publicly-available resources. They can also interact with many different ERP and middleware systems.

We have been looking for the best way to implement web services in Ignition for a long time, but the problem has been complicated by three factors:

1. There are many web service standards; in fact, too many.
2. Data formats are wildly variable and can include many nested structures.
3. Responses can dynamically return a varied number of data elements every time.

As regards Ignition, the question has always been how to deal with these factors in an elegant way. How should we map nested and dynamically-changing data into Ignition's resources such as SQLTags, HistoricalSQLTags or other database resources? The problem gets hairy pretty fast.

We recently solved this problem by including the Python SUDS web service client library in version 7.4.2 of Ignition (currently available in beta). In just two lines of Python code you can be up and talking to practically any SOAP server that serves WSDL files. Okay, maybe that's a bit too much information – let's clarify a few things about web services. 

Web Services Demystified
Web services are nothing more than web pages for machines. There are web servers (like the one serving this blog) and web clients (analogous with your web browser) but in the place of you (the one who is controlling your web browser) there is a program which is controlling the web client.

The content of web pages is HTML (which is text) whereas in web services this is replaced with XML (eXtensible Markup Language) which is also text. HTML is intended primarily to manage how content is displayed in your web browser, whereas XML is geared for labeling and structuring the data to be exchanged.

SOAP (Simple Object Access Protocol) sounds scary but is nothing more than some text and XML which essentially makes a contract between the web client and web server concerning how they're going to talk to each other.

WSDL (Web Services Description Language) is nothing more than an initial web page (again in XML) that the server sends (when requested) which answers the questions "How should I talk to you?" and "What should I expect back in response?"

The SUDS Library
The SUDS library can query the server for a WSDL file and parse it to tell you in plan English how to talk to it in order to execute its methods (the name SUDS is clearly a play on the acronym SOAP). Once you know what methods are available you can use SUDS to invoke those methods which can (generally) be used to retrieve and send information to the server. For example, you could retrieve a work order from an ERP system, mark the work order with current production status, and then send it back to the ERP system.

The really good thing about the SUDS library is that it works. Other libraries we tried were complicated or were picky when they tried to parse information from the server (so they "blew-up", so to speak).

The thing to realize is that XML can be (and has been) structured into many arbitrary forms. Therefore, many different standards have been created to try and reign in the chaos I.e. WSI-BP (Web Services Interoperability – Basic Profile). Another variable is that even when standards are followed, there sometimes are unintentional deviations. I think both of these reasons are why we saw so many web service client libraries fall short – except for SUDS. SUDS appears to be highly forgiving.

Looking at the example at the top right of this post you can see SUDS in action. Using Ignition's "Interactive Script Tester" we first import the SUDS client. Next, we instantiate a client against a URL and request the "calculator" WSDL file. Then we print the client instance and it tells us that it is a calculator web service and says it has four methods add, divide, multiply, and subtract each of which take two arguments which should be of type float. So now we use this information for our next print command "print client.service.divide(33.33, 11.11)" and the output results are "3.0000002".

There you have it. Four lines of code. The beauty of the library is that it's Python which solves the above issues two and three. Obviously, data on the server end can take any shape, but with the use of Ignition's system scripting functions you can now map the data into any shape and into any resource with only a few lines of Python code. Easy as pie.

It's an extensive library that can do a lot of things but you really don't need to know much more than I've shown you to do magic. Documentation and more examples for the SUDS library are here and the PyDocs are here.

OPC-UA Renders Traditional OPC Tunnelers Obsolete

This post could have been called "Isn't DCOM Dead Yet?" Distributed Component Object Model (DCOM) has been deprecated for years now but it still rears its ugly head, particularly when dealing with OPC servers on remote machines.

This led to the rise of OPC tunnelers as a solution, whereby the travails of dealing with DCOM and its associated security vulnerabilities were addressed. But now, two Ignition gateways can do the the same thing, but better, by leveraging OPC-UA. The cost is next to nothing.

The Ignition platform is, for all intents and purposes, an OPC-UA client that includes a free OPC-UA server module. The module comes with many of the more common drivers, including A-B drivers.

For moment disregard the fact that we could use Ignition's free A-B driver and assume instead we want to talk to an RSLinx OPC server, as the diagram shows. RSLinx uses the older OPC-DA technology relying on Windows COM technology. Since Ignition is written in Java and can run on any OS, the Ignition OPC COM Module is required – which costs $350 but is the only cost to this OPC-UA "tunneler" solution.

In the past, this solution wouldn't work because one piece was missing, but now it can be downloaded here and it is free. This is the "tunneler module" which would be installed in the remote Ignition gateway and will allow you to browse and access your remote PLC address space locally. Setting up and configuring the two Ignition gateways takes just minutes (less than ten) and is a piece of cake.

Of course, with OPC-UA coming of age, most of this is just for picking up those already-configured legacy OPC servers or those supporting oddball protocols. In the example above you would most likely use the free Ignition drivers or for unsupported protocols use the latest KEPServerEX which now supports OPC-UA (installed at the remote location).

I thought you might like the data on this little problem-solver.