This is a copy of the original REST-PCA proposal, posted at http://rest-pca.org no longer available.
Introduction
The most widely accepted standards for communicating with industrial process control devices are arguably the family of specifications produced by the OPC Foundation. From its origins as a Microsoft Windows-specific technology to the current platform-independent Unified Architecture, OPC has grown into a mature set of standards for interoperability within the process and manufacturing industries.
While the general value of the OPC specifications is unquestionable, the OPC model and the mechanism for its ongoing development present several potential issues both for producers and consumers of industrial automation products and services. The REST-Process Control Architecture (REST-PCA) proposes a simplified model for process control interoperability in an effort to address these issues.
REST-PCA is not intended as a replacement for OPC-UA. Instead it aims to provide a alternative model for those situations where OPC UA is inappropriate.
Problems with OPC Unified Architecture
OPC UA is a SOAP-based protocol
OPC UA provides both binary and SOAP protocols for data transfer, a considerable improvement on the earlier DCOM-based protocol. However, both approaches require tradeoffs either in terms of readability or speed - SOAP providing a comprehensive data model at the cost of increased data volumes.
SOAP remains a significant and popular model for interoperability between business systems, though it has lost some ground to REST - an architectural model that eschews wide-ranging and rigid specifications in favour of simple conventions that can be adapted as needed. One of REST’s chief benefits over SOAP is the relative efficiency of data transfer.
The OPC Foundation’s choice of SOAP for data transfer in OPC UA is clearly important for interacting with business systems using the same protocol. The value is not as clear cut for organisations opting for simpler models like REST, where the imposition of SOAP may add unnecessary cost and complexity to their software systems.
OPC UA is not completely open
The OPC UA is not an open standard by the legal and received definition of many countries, organisations and individuals (see: http://en.wikipedia.org/wiki/Open_standard). Access to the specifications requires financial membership of the OPC Foundation and granting of voting rights requires significant larger contributions.
While the OPC Foundation’s aim to provide benefits to members of the foundation is understandable, it has the potential to create problems for groups or individuals who either can’t afford to join the foundation as financial members or who have philosophical concerns over the openness of the standard. By providing only the SDK and WDSL definitions to non-financial members, this model may also sharply separate users of process control systems into either consumers or producers of OPC-based technology.
We believe that the current technical and institutional framework makes OPC UA unsuitable for some circumstances, including:
- Development of open source process control applications
- Interaction with business software designed with architectural models other than SOAP.
Furthermore we believe the apparent complexity of the OPC UA model presents a potential barrier to innovation.
We believe that open standards play a significant role in fostering innovation, reducing cost and complexity and for providing opportunities for collaborative development between a wide range of interested parties. We acknowledge the availability of a standard as an important principle and believe a completely open standard allows for deeper collaboration, based on shared knowledge.
Introducing REST-PCA
REST-PCA proposes a simple model for interactions between software and industrial control systems. At its core it makes use of the REST protocol - an approach to constructing Web Services first put forward in 2000 by Roy Fielding, one of the chief architects of the HTTP protocol.
A Short Primer on REST
REST - or REpresentational State Transfer - is a term used to describe a simple architectural style for transferring domain-specific data over HTTP, without any additional messaging layer like SOAP or XML-RPC.
Central to REST is the concept of a resource - a source of information - that can be addressed via a global identifier (e.g. HTPP URIs). Operations on a REST resource are restricted to so-called CRUD methods (Create, Read, Update and Delete), mapped to the HTTP verbs POST, PUT, GET and DELETE. In REST URIs can be used to access either individual or collections of resources, represented using common data formats, e.g. XML, JSON or HTML.
For example, a web client executing a request for a list of all available devices might expect an XML list containing a summary of available device “resources”:
~~~ GET http://example.com/devices/ returns
The same client requesting the state of an individual device might also request that the data be returned in JSON format:
~~~ GET http://example.com/devices/device1.json returns { “device”: { “name”: “device1”, “state”: “running” “rpm”: 120 } } ~~~
REST does reduce the ways that resources can be manipulated, but has the benefit of providing a mechanism for interacting with online resources that is both simple and readily extensible. REST makes use of existing conventions and so provides longer term compatibility and extensibility that more abstract and complex models like SOAP.
Representations of resources in REST are also highly reusable. As simple HTTP URIs they can be used as bookmarks, in documentation, or sent via email. And as long as the client system understands the returned type it can access and update resources with relatively little coding.
By utilizing REST as its architectural model REST-PCA takes a pragmatic approach to delivering process control as a web-enabled service and creates opportunities for integrating with a wide range of business systems.
REST-PCA Philosophy
Driving principles:
- Simplicity
- Openness
- Innovation through reuse rather than reinvention
Expected outcomes:
- Simple access to Multiple representations of the same data using REST principles
- An open, community-based approach to standards development
Benefits of REST-PCA
When compared to the OPC UA data transfer model, REST-PCA stands midway between the binary and SOAP implementations - providing more readable data than a pure binary representation without as much of the overhead as typical SOAP message passing.
Because REST is an HTTP-based protocol it can be readily used by conventional web-based applications. It’s conceivable - and indeed intended - that web browsers and other web-based clients can be used as HMI interfaces. REST-PCA also simplifies integration with third-party business applications.
REST-PCA Address Space
The REST-PCA address space can be viewed as a series of nodes or containers of nodes represented as REST resources.
REST-PCA does not prescribe or restrict the paths or types of nodes available. The actual nodes are assumed to be an implementation detail that may vary from application to application. It is expected that a catalogue of common mappings from automation protocols to REST will emerge over time, including mappings that incorporate data from external data sources - i.e. applications outside of the process control domain.
Sample mapping to Modbus
The Modbus/TCP protocol follows the same architectural style as REST and subsequently maps directly to REST-PCA. A naive implementation would simply map Modbus coils, registers, etc as nested resources within Modbus remote slaves - themselves represented as resources. For example, assuming “on” and “off” are internally mapped to the Modbus 0xFF and 0x00 output values:
~~~ GET http://example.com/modbus/remote-slaves/0xAF/coils/0xCA ~~~
returns the XML fragment <coil address="0xCA" value="on" /> representing the current state of the coil at address 0xCA on slave address as 0xA, whereas:
~~~ PUT http://example.com/modus/remote-slaves/0xAF/coils/0xCA “value” => “off” ~~~
changes the same coil to the ‘off’ state.
There’s no reason why addresses can’t be given meaningful names, e.g. /modbus/agitator/coils/top-valve. Any names are assumed to be part of an application’s implementation details, accessible via the REST-PC discovery mechanism.
Sample mapping to TC-6 XML
PLCOpen’s TC-6 XML format is intended for portability of PLC programming data from between systems. Its structured approach to PLC internal data representations makes it a candidate for mapping PLC data to external systems. Mapping TC-6 to REST-PC provides a mechanism for further exploration and manipulation of process data. For instance, requesting a resource ‘bin-6’ would return a fragment TC-6 XML representing the current state of a piece of plant equipment:
~~~ GET http://example.com/tc6/devices/modicon-tsx/variables/bin-6 ~~~
returns
~~~
~~~ PUT http://example.com/tc6/devices/modicon-tsx/variables/bin-6 “status” => “stopped”=”false” ~~~
Would restart the plant equipment.
Sample mapping to complex automation objects
REST-PCA can also be used to access resources representing the state of objects existing within SCADA or similar executive function control systems. These are rich resource in the sense that the values represented are derived from raw control data and include abstractions that don’t exist at the level of PLCs and other control devices. In the example below a request for a JSON representation of a active loading sequence returns calculated values provided by a SCADA system:
~~~ GET http://example.com/loading-sequence/3d2d.json ~~~
returns
~~~ {“loading-sequence:{ “id”: “3d2d”, “time_started”: “2009-11-11T12:45:44”, “amount_moved”: “1505Ml”, “state”: “running”, “down_time”: “12.5mins”, “predicted_end_time”: “2009-11-11T12:59”, } } ~~~
^
Sample mapping to business objects
Extending from the model of surfacing complex automation objects as REST resources, it’s possible to present business data via REST-PCA in the same manner. In the example below, historical data from shipments is tallied and used to derive ancillary business data which is then presented as a node within the same REST-PCA address space as other data.
~~~ GET http://example.com/shipments/daily-tallies/20090405 ~~~
returns
~~~
The ability to present automation and business data via the same basic protocol creates opportunities for creating rich interfaces to process control systems.
REST-PCA Security Model
REST-PCA doesn’t dictate a security model, deferring instead to the security models implicit within the HTTP protocol or to application specific authentication schemes. It’s expected that REST-PCA implementations would use one or more of the common set of authentication best practices used in REST applications, including:
HTTP Authentication
The common authentication protocol provided by web servers, requiring clients to authenticate using a simple name/password combination. If the name/password is ever intercepted by a third party it is possible to generate fake requests, though the use of SSL mitigates this risk.
API Key
Providing clients with an API key allows servers to authenticate clients without having to negotiate HTTP authentication on each request. Often used with HTTP authentication or similar simple authentication protocols to establish initial connection and thereafter using the API key for all subsequent requests.
API Key + Secret Key signing
Providing two keys, an API key sent with each request and a secret key used by the client to “sign” each request and by the server to verify it authenticity. Even if the request is intercepted by a third party it can’t be used to generate false requests because the secret key is never revealed. This is the model used by Amazon Web Services and similar secure web service providers.
Use of Secure Socket Layer and the HTTPS protocol further ensures security within REST-PCA. Other schemes and technologies can be used - again depending on application requirements.
REST-PCA Discovery Mechanism
Proponents of REST argue that the hyperlinked representation of resources in REST makes a separate discovery process unnecessary. There is some strength to this argument, as a well-documented interface that can be actively explored using a web browser is preferable to a complex model of service discovery and binding . However, to support software development activities some form of automated discovery process is likely to be required in the future.
Whatever discovery mechanism REST-PCA uses will be based on common discovery protocols. The most likely candidate is the Atom Publishing Protocol - a REST-based standard for publishing web service details.
Because Atom PP uses the same architectural model as REST-PCA it makes for a reasonably good fit - though some work is required to investigate its usefulness.
REST-PCA License
REST-PCA will be made available under a permissive, Creative Commons license. There will be no restrictions on its use.