REST and Industrial Applications - An alternative to OPC

Technorati Tag: Visual Studio 2008,REST,OPC

Writing software for industrial application is trivial and risky and a lot of different software platforms and hardware devices must be integrated in a common environment often evolved through tens of years.

In this scenario, one of the most important standard is OPC that defines sets of specification about how to produce and consume data, alarms and events generally produced and processed in a common industrial system.

The following picture is a sample scenario showing the concept behind OPC:

A sample scenario

On the bottom area there are some different sample classes of industrial devices:

• PLC-A is a sample PLC which exposes a set of memory data (called tag).
  A tag is a calculated variable or the value of a physical signal. Usually tags are accessible using proprietary protocol like Siemens SH1 depending from the PLC used.
  In the sample the tags are named (A01, A02, A0n for PLC-A, Z01, Z02, Z0n).
• PLC-B is another sample PLC, working in the same way as PLC-A but using GE EGD protocol to expose tags to the other systems.
• Legacy-Z is a sample system implementing a complex mathematical-model and exposing data to the upper layer using a custom UDP protocol.
  This kind of system usually get data from PLCs, process them with feed-back model and generates setup data-packets sending them back to the PLCs. A lot of etherogenus operating system and programming languages have been used for delivering these application (Real-Time OS, Unix, Fortran, PML, C, etc.).
  In this sample we assume the some of the calculated values are exposed with the tags pattern (name, values) using a custom developed protocol.

Before OPC

As you could realize, before the OPC era, developing the upper software layers (like a databases with trend analysis, HMI modules with the user interfaces) required to create 1:1 connections with each integrated devices implementing custom protocol (SH1, EGD, TCP UDP, etc) from every client applications wasting a lot of effort in application plumbing.

For example, if you HMI needs to integrate the PLC-A, PLC-B, Legacy-Z you must have in your code the SDKs or the components for using Sinec-H1, EGD and custom UDP.The same for the trend-analysis database.

What is OPC

Referring to the depicted scenario:

OPC is a standard communication protocol to mediate and expose the underling protocols to the upper software layers through a single and standardized access model.

As you can see from the sample picture, the Trend server and HMI server are directly connected to the OPC Server using just a single protocol (the OPC protocol).

To implement an OPC Server you should get it from the market. There are a lot of different products (Kepware, OPC Power Server, Matrikon, etc.) and you choose one basing on the availability of the supported protocols you could need.

In the sample scenario there is a logical mapping between the OPC exposed tags values and the underlying tags (like the OPC tag 00-01 is mapped to the physical tag A01. the OPC tag FF-02 correspond to the physical tag Z02 and so on)!

One OPC Server integrates differents etherogeous devices using one common logical tags table.

The translation from the industrial protocols (Siemens SH1, EGD, etc.) is in charge to the OPC drivers (there are a lot of different drivers on the market). If you need to translate a custom protocol (from sample scenario the custom TCP UDP protocol ) you can write your own driver with existing OPC SDK.

Architectural Pattern

From an architectural perspective you can consider OPC as a common layer to map and provide access to a network of underlying devices and resources using a name/value addressing pattern.

When you implement complex mathematical models or process control software in a modern environment you'd like to leverage OPC to implements your common memory areas providing access to your computed variables to different algorithms and models.

So on complex mill there are different applications running on different hardware systems that need to share data in the same way OPC was build for.

The problem is that OPC isn't enough fast to enable process control software doing his tasks and also the code you've to write providing OPC access is trivial and "fat" due to the involved SDKs and components.

So the question is:

How we can leverage the OPC pattern to implement common data areas using modern technologies and providing access to shared variables?

My idea is the development a REST service.

REST

Representational State Transfer (REST) is an architectural style to expose a set of connected resources (and their basic operation) usually leveraging the HTTP protocol suite.

It's a different thing than Web-Services and SOA. I guess to understanding REST the best approach is a sample:

• A multimedia contents could exposes its multimedia catalog through REST providing basic services for updating them;
• A complex system could exposes its configuration and metadata and clients browser could leverage rest to connect and update those data;

The pillar of REST are:

• URI to address a connected resources (for example: http://mycontenctapplication/myCatalog/Author="Rocking Corrado";
• HTTP verbs to specify an operation to the connected resource:
  • Get for fetch or read resource values;
  • Put for updating or insert of resource values;
  • Delete for deleting resources;
  • Post for appending resources;

Now the problem is how we can leverage REST for industrial applications?

REST and Industrial Software

If your software have to manage a complex site (like an Hot-Strip Mill), you've to deal with different applications and process controls (Furnace Control, Roughing Mill, Finishing Mill, Cooling Section) that have to exchange a lot of data and messages.

Those application usually uses custom protocols to exchange messages (pushing data with 1:1 synchronous interfaces) and using common shared areas for in-process communication.

The following pictures shows an Hot-Strip Mill process control system build using a REST architecture.

The Rest application will be developed with the following features:

• A data-structure will be implemented to collect information from existing process control software;
• The data-structure will be updated with standard interface with existing software for example TCP-IP sockets;
• The data structure will be exposed with a restful interface;

If you will use REST to expose common area I guess that you will have a "closed" set of tags so that only GET and PUT verbs will make sense (consumer of REST will never add or delete new Tags).

Which are the main benefits of adopting REST in your process control software?

• A standard protocol to expose data (HTTP)
• Client application could access REST information in an easy way (XML and JSON);
• REST is very well suited:
  • To provide access and update configuration data
  • To provide and update runtime information (like the Finishing-Mill parameters)

How we can write REST applications?

WCF Rest Starter kit is here (developed by MS WCF team)!

It has been published on Codeplex and it could included in .Net 4.0:

A set of templates are available for Visual Studio 2008:

• Rest Collections/Singleton services;
• Atom Feed/Atom Publishing Protocol
• HTTP/POX services

And what about the c# code that we should write? Easy:

[OperationContract]

[WebGet(ResponseFormat=WebMessageFormat.Json,UriTemplate="processControl/{tagId}")]

ProcessControlData GetTag(int tagId);

The WCF Rest Starter Kit also provides:

• the WebProtocolException class to implement exception management in Rest services;
• the RequestInterceptor class to manage the processing pipe-line of the service;