Reverse AJAX Technologies
NUNZIO MARCO TORRISI
T
he asynchronousJavaScript and exten-sible markup lan-guage (XML) (AJAX) technologies have revolutionized the world of Web ap-plications in recent years. This work describes some technical issues from the CyberOPC application protocol based on reverse AJAX and Java-Script object notation (JSON) remote procedure call (RPC). Initially created for monitoring computer numerical control (CNC) tools, this application protocol adopts streaming techni-ques for industrial communication technologies over Internet protocol (IP)-based networks and represents an open and performing alternative for monitoring protocols such as OPC and MTConnect.
The AJAX technologies are a col-lection of methodologies and practi-cal approaches that involve hypertext transfer protocol (HTTP) communica-tion between the clients and servers distributed on the IP networks. The well-known use cases of AJAX [1] are related to the techniques on partial reload of pieces of hypertext markup language (HTML) pages into a Web browser. This solution is largely im-plemented using a standard Web server and Web browser supporting asynchronous HTTP request while parsing the received HTML code. To accomplish this, most Web browsers support a special programmable object called XMLRequestObject, embedded and available in the JavaScript virtual machine. This approach improves the interactivity of Web applications, es-pecially where a large number of graphi-cal user interface controls, such as buttons and tree view, are embedded.
Digital Object Identifier 10.1109/MIE.2011.940253 Date of publication: 25 March 2011
©
Reverse AJAX-based industrial Web applications are explored in Web frameworks to manage electric power system, demonstrating stability in high load traffic [2].
This work outlines a general-pur-pose communication solution for indus-trial applications, named CyberOPC, based on reverse AJAX-streaming tech-niques as an efficient and alternative technology for industrial communica-tion over IP networks.
Motivations
In a scenario where a remote-control station located on a large IP network sends and receives data from a field-bus or manufacturing cell, data origi-nated from the device usually pass through an intermediate station, which mainly supports the OPC interface to exchange data out of the manufacturing
cells. The reverse AJAX-streaming ap-proach was introduced in the current CyberOPC project [3] to reduce the access delay of synchronous traffic related to time-critical data process variables.
Figure 1 shows the general per-formance from the first version of the CyberOPC project compared to OPC data access (DA) XML and distrib-uted component object model (DCOM)-based OPC-DA, using data obtained from experimental results of different communication architectures regard-ing the delay variation of unidirectional, consecutive packets [4]. The first ver-sion of CyberOPC did not include re-verse AJAX-streaming features, and it was built as a middleware between the OPC server and remote Internet client. The refresh rate as shown in Figure 1 was measured by comparing
the variation of the delays of uni-directional, consecutive packets be-tween the first version of CyberOPC and OPC-DA-XML and DCOM-based OPC-DA. The key factor for the differ-ence in performance is the access delay introduced by the OPC-DA 2.x/3.x server, which rarely supports a refresh rate of less than 250 ms. On the other hand, the minimal in-terval to schedule, process, and send a data process message using Web services gateways demands more than 800 ms.
The goal of the CyberOPC project is to define an open standard for in-dustrial data exchange based on open technologies and minimize the access delay in continuous monitoring using reverse AJAX streaming.
Adopting an Open Standard and Interoperable Technologies over IP Networks
The CyberOPC specification is open, free, and based to open technologies such as JSON, JSON-RPC, HTTP, and server secure socket (SSL). Adopting open standards in industrial infor-matics can be defined as the ability to design software and services with an architecture specially projected to foresee the integration with other technologies. Property rights are not strictly tied to the cost but to the rights to the object or technology. In practical terms, what characterizes a technology as a proprietary or non-proprietary is the license agreement bonded to the technology by the holder of the intellectual property rights [5].
The concept of interoperability is the ability of one system to work with other systems without special efforts from the client. The CyberOPC solu-tion adopts open standard technolo-gies for data encoding and remote procedure call in manufacturing in-dustries, where manufacturing cells, supervisory control and data acquisi-tion (SCADA) systems, and program-ming devices are typically found.
Basically, communication can be grouped in three scenarios wherever there is a fieldbus communication link established over public IP networks:
Remote Network >1,500 ms
>800 ms
>200 ms
>30 ms Historian/Demilitarized Zone Network
Controller Network
Field Network Socket TCP/UDP Socket TCP/UDP
OPC-DA Server DCOM over TCP CyberOPC Ver. 1 Gateway OPC-XML-DA Web Service Gateway SOAP-HTTP HTTP Fieldbus Manufacturing Cell
FIGURE 1 – Delay variation of unidirectional, consecutive packets between the first version of CyberOPC and OPC-DA-XML and DCOM-based OPC-DA.
The AJAX technologies are a collection of
methodologies and practical approaches that
involve HTTP communication between the
clients and servers distributed on IP networks.
1) Cell-to-cell scenario: A controller in Plant A from cell alpha com-municating with a controller in Plant B from cell beta.
2) Host-to-cell scenario: A SCADA ap-plication in Plant B controls the manufacturing from cell beta, accessing a PLC in Plant A. 3) Host-to-host scenario: A SCADA
ap-plication in Plant A to a SCADA application communicating in Plant B.
For all communication scenarios, the CyberOPC solution assumes that all PLCs and PCs are able to process HTTP over SSL protocol commands. As an open standard, the SSL proto-col is well supported by many soft-ware libraries and makes it possible to configure client/server mutual authentication.
Minimizing DA Delay Using HTTP over IP Networks for Periodic Transmissions
The reverse AJAX HTTP-streaming approach is known as streaming AJAX or Comet—forever frame. In this model, the data delivery is fully asyn-chronous, both from the server to cli-ent and vice versa. The advantages of the completely asynchronous para-digm are summarized as follows:
1) Ideal zero latency between the gen-eration of new industrial data and the delivery to the final clients: There is no need to wait for the next polling cycle to receive fresh data. The asynchronous polling paradigm shares this same bene-fit, but as a full round trip of request/response is needed for each update, the asynchronous polling mechanism is limited in the maximum frequency allowed for the updates, which depend on the network latency.
2) Reduced bandwidth: With the streaming paradigm, a permanent streaming connection is kept open for each client. When no fresh data are available, no useless traf-fic is generated on the connection. Furthermore, the heavy HTTP headers of the request/response round-trip cycles of the asyn-chronous polling are completely
avoided. Bandwidth reservation technologies, such as multipro-tocol label switching (MPLS) could be added in a CyberOPC communication solution to achieve bound delays for selected streamed variables.
The natural consequence of the optimized use of public IP networks through the reverse AJAX HTTP streaming is the optimization of the data-retrieving process from indus-trial equipment. For such a reason, the CyberOPC server architecture should be structured into a modular server, plug-in based, where an asynchronous DA plug-in module can be developed for each device communication.
Related Technologies
An alternative OPC communica-tion system based on the HTTP pro-tocol was recently proposed by the MTConnect Institute [6] to provide an application protocol standard that is able to send industrial data to higher level systems using the XML-based standard. The MTConnect pro-tocol introduces a cross-platform communication schema over the HTTP protocol that is simpler and less so-phisticated than the OPC 2.x/3.x, OPC-XML, and OPC-unified architecture (UA). The main advantages are the XML data encoding and the HTTP client/server approach. Therefore, MTConnect communication does not support any specific monitoring schema such as the OPC subscription polling schema to optimize periodic data mon-itoring over IP.
The current CyberOPC solution in-troduces three important improvements:
n the use of reverse AJAX HTTP
streaming over SSL (HTTPS), as a faster alternative to the OPC sub-scription poll mechanism
n data encoding in JSON format
[7], as a more compact alternative to XML
n the use of JSON-RPC commands
syntax [8] over HTTPS to define the CyberOPC services.
These improvements optimize the use of network resources, minimize DA delay, and enhance flexibility, adopting open standards such as JSON data encoding and JSON-RPC for the commands syntax.
Table 1 outlines the main differen-ces between the current specification of OPC-UA, DCOM-based OPC 2.x/3.x (also called OPC Classic), and MTCon-nect and CyberOPC. It also includes a selection of characteristics that influ-ence the performance in remote con-trol over public IP networks.
DeadBand Algorithm and Subscription Polling Mechanism
In a client/server scenario for remote monitoring, client applications are interested in periodic data refresh from the server values. A common practice is grouping the values of items of inter-est from the server with similar change rates and assigning them to a group. This procedure will allow the client to later retrieve all updated values from the group by simply requesting the group name identifier. Additionally, it
TABLE 1–COMPARING OPC CLASSIC, XML/UA, MTCONNECT, AND CYBEROPC.
OPC 2.X/3.X OPC-XML/UA MTCONNECT CYBEROPC
HTTP over SSL A O O N
HTTPS streaming A A A N
Subscription polling mechanism N N A A
WebServices HTTP-SOAP A N A A
XML data encoding A N N A
JSON data encoding A A A N
Device description support A A A N
Mutual authentication client/server O O O N
DeadBand algorithm N N A N
is possible to schedule periodic up-dates of data values sent from the server to the client using a mecha-nism called the subscription polling mechanism. Although this mecha-nism speeds up the refresh rate and minimizes the number of update requests to the server, not all data values might be of interest to the cli-ent, because some values may not change enough to be relevant for the client application.
To minimize the size of data sent from the server to the client related to changed values of interest, the cli-ent can specify a parameter called DeadBand for each group, which de-termines the percentage of range for an item value that must change be-fore the value is of interest to the client. Changes in values out of the client’s interest are not sent to the client, reducing the size of data delivered over the network.
XML and JSON Data Encoding Textual data encoding is required when working over the HTTP proto-col. JSON and XML are simple and well-known textual data representa-tion format. XML was selected by the OPC Foundation as the textual data encoding format, as the first release of the OPC-XML DA specification 1.0 in 2003.
More recent than XML, JSON was initially defined in 1999 as part of ECMA Standard 262 [7], ISO/Interna-tional Electrotechnical Commission (IEC) 16262, and detailed in the RFC 4627 in 2006.
It is considered a lightweight data-interchange text format. XML and JSON are completely language independent,
but JSON uses just two primitive data structures: a collection of name/value pairs and an ordered list of values. In almost all languages, both these struc-tures are available, and it is easy to write parsers from/to JSON streams.
Device Description Support
The device description technology describes the characteristics of the devices to human–machine interface (HMI) and SCADA configuration tools. The process variables and internal set points from field devices can be ac-cessed by the general-purpose read/ write memory driver functions when the memory addresses of the devices are known.
The device description technology has already been applied to founda-tion fieldbus, highway addressable remote transducer protocol, and Pro-fibus PA devices [9] to simplify the device documentation process and be compliant with the IEC 61804-3.
The purpose of the CyberOPC ap-plication protocol is to provide basic services to transfer device description files from the server to the remote cli-ent application. This means that the server keeps references between the loaded devices and their device de-scription files. The file type and format for the device description are not defined in the CyberOPC specification [3]. The file format could be textual as in the electronic device description language (EDDL) specification [10]. An open and nonproprietary device de-scription solution such as open elec-tronic device description (Open-EDD) [11] could be an interesting option to integrate this technology to a solution based on open standards.
Mutual Authentication and Security Issues
In OPC classic, the operating system performs the authentication process, while the OPC server holds an access control list. The OPC server based on the 2.x/3.x specification is a Win-dows legacy, and for this reason, the authentication is Windows based and managed from the server side’s oper-ating system.
OPC XML-DA and MTConnect as-sume that the transport protocol will handle security. This means that it is possible to configure a mutual authen-tication for the client and server even if the selected transport protocol is SSL, HTTPS, or HTTP-simple object access protocol (SOAP). The OPC-UA security model consists of authentica-tion, authorizaauthentica-tion, encrypauthentica-tion, and data integrity via signatures. Neverthe-less, the OPC Foundation has adopted the Web service security specification model for conversations in encoded text and binary. These conversations are also named UA secure conversa-tion, and they can include mutual authentication behind an encrypted virtual channel.
CyberOPC and OPC-UA authenti-cations use x509 certificates exclu-sively, but the first adopts SSL mutual authentication instead of the Web ser-vices security model.
Web Services HTTP-SOAP
OPC-XML, OPC-UA, MTConnect, and CyberOPC specifications include at least a profile of use of HTTP as a transport protocol. The HTTP proto-col transport message consists of one header and one body, as shown in Figure 2. To send commands over this transport protocol, it is necessary to envelop the commands, whether in-side the header or body. OPC-XML and OPC-UA adopt the Web services technology based on the SOAP proto-col, which means that the command related to the OPC service is enveloped inside the HTTP headers. MTConnect adopts an XML processor directly applied to the HTTP body. CyberOPC adopts the JSON-RPC protocol syntax to exchange messages inside the HTTP body. MTConnect and CyberOPC
Header Body Header Body HTTP Request HTTP Server HTTP Client HTTP Response
embed the commands inside the HTTP bodies. For embedded network devices, thin clients, and microcon-trollers that implement a standard HTTP protocol without SOAP, the computation of HTTP headers with SOAP could be too sophisticated or sim-ply impossible, while the computation
of HTTP bodies should be avail-able without extra computational resources [12].
The CyberOPC Architecture
and Comparisons
The CyberOPC project also provides a client/server software sample system
composed of an HTTP server and HTTP client library. Services defined in the CyberOPC specification substi-tute the weight of Web services pro-cessing based on SOAP-HTTP for the lightweight Web services based on JSON-RPC over HTTP. Figure 3(a) shows the software modules that integrate
JSON Processor API
CyberOPC Application Server
... C# JAVA JSON Parser CyberOPC Command Kernel HTTP Server JSON-RPC over HTTPS Module Library + Driver or Fieldbus Protocol Stack Device Legacy Interface Client HTTP Client JSON Processor
Device Data Access Delay Application Message Broker Delay Remote Data Access Delay (a)
Device Data Access Delay Application Message Broker Delay Remote Data Access Delay (b)
SOAP Processor API
OPC-XML Application Server Gateway
... C# JAVA XML Parser OPC Client Library HTTP Server Driver or Fieldbus Protocol Stack Device Legacy Interface Client HTTP Client SOAP Processor OPC Server Web Services HTTP-SOAP DCOM over TCP-IP
Device Data Access Delay Application Message Broker Delay
(c)
Remote Data Access Delay API MTConnect Adapter ... C# JAVA XML Parser MTC Connector HTTP Server Device Legacy Interface MTC Agent HTTP Client XML Processor XML Messages over HTTP RS-232 or Specific
FIGURE 3 – (a) CyberOPC server and client architecture. (b) OPC-XML-DA server gateway and client architecture. (c) MTConnect adapter and agent architecture.
the CyberOPC server communication. The block on the left represents the industrial equipment; the central block is the application server that responds and requests the message sent by the block on the right and collects data from the device on the left; and the block on the right sends the HTTP messages, parses the JSON-RPC com-mands, and forwards the command message to the central block.
Figure 3(b) shows the software modules that integrate an OPC-XML-DA server gateway communication schema, which comprises the com-munication between the device and its OPC server 2.x/3.x on the left side, and the communication between the application server and the client using Web services.
The MTConnect communication schema in Figure 3(c) supports the con-nection to the device on the block on the left side using a dedicated library named an MTC connector and a remote connection on the right side using XML messages over HTTP between the ap-plication server (named MTC adapter) and the remote MTC agent.
Communication delays between the blocks shown in Figure 3(a)–(c) influence the total delay when receiv-ing the updated values from the shop floor device to the remote cli-ent. This value can be quantified as a sum of the device DA delay (TDevice), the application message broker delay (TApServer), and the remote DA delay (TRemote), as indicated by the follow-ing equation:
TTotal¼ TDeviceþ TApServerþ TRemote: (1)
To minimize TRemote, the Cyber-OPC specification introduces the use of HTTP streaming for continu-ous process monitoring. The HTTP-streaming approach adopts reverse AJAX methodologies to reduce the delay of synchronous traffic in con-tinuous process monitoring.
The value of TApServer reflects the complexity of the message command processed inside the application server. The Web services HTTP-SOAP approach requires a SOAP processor
dispatcher for the HTTP request/ response header and another XML processor for the body. The JSON-RPC approach, instead, does not re-quire any HTTP request/response header processor because the com-mands and parameters are embed-ded inside the HTTP body. This means the same JSON parser proc-esses the commands and parameters.
The difference between the actions performed to dispatch a Web services invocation and a JSON-RPC is signifi-cant. Although the name JSON-RPC emphasizes a remote procedure call technology, in practice, the techni-ques of localization transparency are not required because the service invo-cation is realized as an HTTP request directly. In other words, the HTTP-SOAP Web services require localiza-tion transparency to invoke the remote services as local. Localization is achieved by providing a function stub to the invoking application. The func-tion stub, when called, accesses a middleware software layer that trans-ports the call and its associated data to the invoked application. Besides, the time spent in the Web service localization does not include an even-tual extra time spent to manage the Web services security authentication policy applied for each request re-sponse. Definitively, a text parser, XML or JSON, is faster even if it directly man-ages the commands and parameters inside HTTP body request/response.
The value of TDevice is limited by the transfer rate of the device with its native protocol. Nevertheless, the OPC-XML architecture in Figure 3(b) and the similar gateway architecture proposed in OPC-UA are also affected by the delay introduced by the OPC server 2.x/3.x.
The CyberOPC Services
The CyberOPC services invocation is accomplished by sending a set of commands and parameters format-ted in JSON-RPC syntax to the server. The JSON-RPC specification is not restricted to a specific transport proto-col, but HTTP has fewer policy restric-tions passing through the routers and firewalls. The general RPC mechanism
consists of two peers establishing a data connection. During the lifetime of a connection, peers may invoke meth-ods provided by another peer. A request is sent to invoke a remote method, and unless the request is a notification, it must be replied with a response.
In a CyberOPC scenario, JSON-RPC works over HTTP without need-ing any SOAP messages. The HTTP request and response can be used as transport for communicating between the peers. The communication be-tween the peers, one being an HTTP client and the other an HTTP server, may span multiple HTTP requests. A client-side peer may send one or more requests, notifications, or responses to its peer by sending an HTTP re-quest containing all serialized objects. The server side peer must reply with responses to all requests sent and may send requests or notifications of its own. The client side peer must reply to the received requests by sending another HTTP request. The CyberOPC JSON-RPC services exchange data with the devices linked to the device or platform replacing the well-known schema of the OPC-DA specifi-cation, but instead of adopting the complexity of the Web services using SOAP, a more portable and cross-platform approach is selected espe-cially for embedded devices, which is able to support the HTTP protocol without SOAP. The services sup-ported by CyberOPC partially replace the functionalities of the main serv-ices described in the OPC-XML DA specification [13].
The structure, parameters, and be-havior of each service are defined as follows:
n Status (parameters—GetStatus and
GetStatusResponse): Allows the cli-ents to query the current status of the server.
n Read (parameters—Read and
Read-Response): Allows the clients to read the values from items.
n Write (parameters—Write and
Writ-eResponse): Allows the clients to write the values to items.
n Subscription
(parameters—Subscrip-tionRequest and SubscriptionRes-ponse): Allows the clients to tell
the server to monitor changes on a set of item values.
n Stream
(parameters—StreamStart-Request and StreamStop(parameters—StreamStart-Request): Allows the clients to start receiv-ing the server stream with any data changes.
n Subscription Cancel (parameters—
StreamSubscriptionCancelRequest and StreamSubscriptionCancelResponse): Allows the clients to tell the server to stop streaming item values for changes.
n Browse (parameters—BrowseRequest
and BrowseResponse): Allows the clients to identify what items exist in the server.
n ReadEDD (parameters—ReadEDD
Request, ReadEDDResponse, Read-EDDTableRequest, and ReadEDD TableResponse): Allows the clients to identify and download device description files related to items specified in the server.
The CyberOPC primitive services GetStatus, Read, Subscribe, Subscrip-tionCancel, Write, and Browse provide similar functionalities to the OPC-XML-DA specification, while Subscription-PolledRefresh was replaced because, after the initialization, the HTTP-streaming mechanism sends data
continuously from the server to the client without expecting refresh request commands from the client side. The syntax adopted for each service invo-cation is the default JSON-RPC over HTTP syntax. An example of a Read command invocation request is shown in Figure 4(a).
The related JSON-RPC response command over an HTTP response is shown in Figure 4(b). Streaming serv-ices and the reverse AJAX approach HTTP streaming is a mechanism for sending data from an HTTP server to an HTTP client in response to an event. The HTTP streaming is achieved through several common mechanisms. In one of the mechanisms, the HTTP server does not terminate the response to the client after the data have been served. This differs from the typical HTTP cycle in which the response is closed immediately following data transmission. The HTTP server leaves the response open so that if an event
is received, it can immediately be sent to the client. Otherwise, the data would have to be queued until the cli-ent’s next request is made to the Web server. The act of repeatedly queuing and rerequesting information is known as polling.
The polling technique over HTTP proposed by the OPC-XML and the OPC-UA profiles using HTTP-SOAP has the following limitations:
n The update frequency cannot be
high. A synchronous paradigm (request/response) makes it impos-sible to receive time-critical data, which require high refresh rate.
n The occupied network bandwidth
is high, because with each response, a whole message structure response is transferred instead of only the changed data.
Overcoming these limitations at the source requires a change in para-digm from synchronous to asynchro-nous. The asynchronous approach
POST /mycyberopcservice HTTP/1.1 User-Agent: CyberOPCClient/1.6 Host: www.example.com Content-Type: application/json Content-Length: 181 Connection: Keep-Alive Accept: application/json { "version" : "1.1", "method" : “Read", "params" : { “Options”: { "ReturnErrorText”:false, “ReturnItemTime“:true, “ReturnItemName“:true, “LocaleID”:“en” },
“ItemList”: [ “ItemName1”, “ItemName2”, “ItemName3”] } } HTTP/1.1 200 OK Connection: close Content-Length: 23 Content-Type: application/json Date: Sat, 08 Jul 2006 12:04:08 GMT Server: CyberOPC Server/1.0
{ "version" : "1.1", "result" : { “ReadResult”: { “RcvTime”:"2003-05-27T00:15:36.6400000-07:00“, “ReplyTime”:"2003-05-27T00:15:36.7500000-07:00“, “ServerState”:"running" }, “RItemList”: { {“ItemName”:"Simple Types/UInt“, “Timestamp”:"2003-05-27T00:15:36.7343750-07:00“, “Value”:[“unsignedInt",”4294967295”]}, {“ItemName”:"Simple Types/Int“, “Timestamp”:"2003-05-27T00:15:36.7343750-07:00“, “Value”:[“int”,”2147483647”]}, {“ItemName”:"Simple Types/Float“, “Timestamp”:"2003-05-27T00:15:36.7343750-07:00“, “Value”: [“float”,”3.402823E+38”]} } } } (a) (b)
FIGURE 4 – (a) An example of a CyberOPC read service request. (b) An example of a CyberOPC read service response.
In a client/server scenario for remote
monitoring, client applications are interested in
periodic data refresh from the server values.
adopted to enhance the CyberOPC communication system is called the push or HTTP-streaming technology. In this model, the client receives updates in an asynchronous manner at the server’s discretion in the form of a continuous data flow. The client becomes a passive part of the sys-tem, receiving updated values as soon as it is available on the server, without having to ask for it periodi-cally. The HTTP-streaming approach adopted for the proposed platform is known as reverse AJAX or Comet— forever frame. In this model, the data delivery is fully asynchronous, both from the server to the client. The advantages of the completely asyn-chronous paradigm, introduced into the CyberOPC platform, over the other two can be summarized as follows:
n Zero latency between the
consecu-tive generation of new data change packets from the service platform and delivering it to the final clients: There is no need to wait for the next polling cycle to receive fresh data. The asynchronous polling paradigm shares this same bene-fit, but since a full round trip of
request/response is needed for each update, the asynchronous polling mechanism is limited in the maximum frequency allowed for updates. This limit depends on the network latency, and it could be overcome by adopting a net-work with reserved bandwidth.
n Reduced bandwidth: With the
streaming paradigm, a permanent connection is kept open for each client. When no updated data are available, no useless traffic is gen-erated on the connection. Further-more, the HTTP headers of the request/response round-trip cycles from the asynchronous polling are completely avoided.
The reverse AJAX technique of leav-ing an open connection uses the HTTP header parameter named KeepAlive.
Usually, when an HTTP client and server need multiple interactions, the performance is improved by using the HTTP KeepAlive header parameter to reuse an already open connection. In the reverse AJAX paradigm, the con-nections are kept open for a time, forc-ing the KeepAlive header parameter, which informs the HTTP server that
the transmission control protocol (TCP) socket connection behind the last request/response cycle should not be closed.
Thus, the CyberOPC communica-tion system replaces and enhances the OPC polling mechanism over HTTPS, forcing the KeepAlive param-eter to maintain an open connection between the client and server and to stream changed data over that con-nection. The algorithm in Figure 5 resumes the CyberOPC server logic to keep the data stream over the same open connection.
The algorithm illustrated in Figure 5 is executed for each service invoked. It starts processing the SSL handshake protocol to authenticate the client and server mutually. If the SSL authentica-tion is successful, then the HTTP header is processed. The CyberOPC protocol does not add the custom-ized HTTP header; it just tunes the KeepAlive parameter when streaming services are invoked.
The algorithm then extracts the JSON-RPC commands and parameters from the HTTP message, and if the KeepAlive value inside the header request is true, the CyberOPC server prepares the streaming channel on the already open connection.
The service invoked to start the streaming is named StreamStart and is called as exemplified in Figure 6, with the parameters ServerHandle, DeadBand, and WaitTime.
The parameter ServerHandle is a unique number assigned by the server to the client after subscribing the items. A ServerHandle is defined for each stream, and a cache is subscribed for the values of the items.
The parameter DeadBand repre-sents the percentage of tolerance for a value change between the last value of the item sent in the flow and the actual value of the data item.
The parameter WaitTime is the maximum time interval of inactivity (in milliseconds) between two consec-utive messages on the stream. When the time interval exceeds, the Cyber-OPC server schedules the transmis-sion of the last values in the cache related to the specified ServerHandle. Process HTTP Header Is KeepAlive True? SSL Client Authenticated Reject Client Connection Process SSL Handshake No Yes Process JSON-RPC Service Dispacther Send Response and Close Socket
Send Response and Leave Socket Opened
No
Yes
In response to the StreamStart service calling, the server starts a flow of messages to the client, delim-ited by the string cyberopcpacket. If no value changes are notified during the last WaitTime, the server will send an empty message in the flow as shown in Figure 7.
The text data included between two consecutive cyberopcpacket delim-iters are the data process values produced by industrial devices, such as PLCs, and asynchronously loaded and refreshed on the server memory.
CyberSecurity Issues
For all case scenarios of communica-tion over public IP networks, a strong network security is recommended [14]. The standardized network secu-rity and safety practice solution pro-posed in the IEC 61784-4 is the IPSec [15]. For the architecture proposed in this work, it is assumed that all public communication is over the HTTPS protocol. The network security solution approach could be restricted from IPSec to a specific security solu-tion for HTTP.
For HTTP communication, there are two categories of security mecha-nisms: transport-level security and XML-based message level security. The transport-level security mechanism employs an SSL using digital X.509 certificates [16]. An SSL is lightweight because it does not involve any XML manipulations. Message-level security
mechanisms are XML-Signature [17] and WS-SecureConversation [18].
The XML-Signature is a standard for digital signatures in XML documents. The usage of XML-Signature with SOAP messages is described in the WS-Secu-rity specification [19]. With XML-Signa-ture, each message is signed with an X.509 certificate. It ensures the integrity of a message, but it does not support replay-attack prevention. This mecha-nism is stateless and does not need any initial handshakes; thus, it is suita-ble for a single invocation of a service.
WS-SecureConversation is a proto-col defined to establish and use secure contexts with SOAP messages. First, a secure context is established between the client and server. Once the security context is established, the following messages are signed using the XML-Signature standard. It is fast because it uses a symmetric key to sign mes-sages, but it requires additional round trips to establish a connection.
Comparing the performance of the tree security solutions, the transport-level security mechanism, SSL, is the fastest. It is interesting to consider that, with SSL, the introduction of HTTP KeepAlive header parameter, as in the CyberOPC monitoring, reduces the response time by half [20].
Case Study
The case study discussed here was exe-cuted on the shop floor at the Labora-tory for Optimization of Manufacturing
Processes [21] using as an indus-trial device a Mori Seiki CNC Vertical Machining Center model NVD1500DCG equipped with a fast Ethernet port and GE-Fanuc open CNC API specifi-cations (FOCASs) 2 protocol interface [22]. The remote JSON-RPC client, the CyberOPC client, was developed in C# with the JayRock [23] library.
The architecture adopted to per-form the remote control test is outlined in Figure 8. The private IP network Figure 8(c) links the CNC machine to a workstation equipped with 2 Gb net-work interfaces: the first was linked to the public IP network and the second to the shop floor private IP network. The workstation worked as a gate-way to convert the CNC protocol to the CyberOPC protocol. The public IP address assigned to the CyberOPC server for the test was 143.107.238.241 and the port configured to accept incoming HTTPS connection was port 80, instead of the default port 443. On the private IP network side, the Cyber-OPC server collected and timestamped a set of CNC variables performing con-tinuous network polling through the GE-Fanuc FOCAS 2 interface. The net-work interface of CNC was a 100-Mb Ethernet and the average value of the delay between two consecutive sam-ple updates using the FOCAS library was about 30–50 ms. This value also depends on the quantity of variables requested and replied in each data frame. In the discussed case study,
POST /EEEHOME HTTP/1.1
User-Agent: CyberOPC Client Library Host: EEEHOME
Accept: application/json Connection: Keep-Alive
{"method":"StreamStart","params":{ServerHandle:1,DeadBand:0.00,WaitTime:2000},"id":7 }
FIGURE 6 – CyberOPC StreamStart request sample.
--cyberopcpacket
[{"itemID":"Simulator.devsim1.SetPoint","timestamp":"634042028608790000","value":"0"}] --cyberopcpacket
--cyberopcpacket --cyberopcpacket
the samples of synchronous sets of variables X, Y, and Z were collected using the FOCAS 2 command cnc_abso-lute2. These three variables represent
the absolute coordinates of the axes X, Y, and Z as they are displayed on the CNC screen of the local HMI machine. Each sample of this set of variables
was marked with a timestamp by the CyberOPC server and stored in the DataEngine memory location.
The remote client was an ASUS 1000H Netbook equipped with a 3G HSDPA network connection and linked to the public IP network with the IP address 187.27.202.210.
The test application installed on the remote client was the open-source CyberOPC sample client, freely avail-able at the CyberOPC project Web site as well as the server. Figure 9 illus-trates the main screen of the remote client application, displaying the Cyber-OPC Read command execution in the log history panel.
The NC program loaded in the CNC machine for the test had a simple two-dimensional spiral shape. The full NC source program, Matlab data files, network dump files, pictures, and vid-eos captured during the test are avail-able at the CyberOPC project Web site. During the test, the CyberOPC server stored timestamps for each sample acquired over the private IP network by the GE-Fanuc FOCAS 2 interface. The CyberOPC server data acquisition process is asynchronous: it collects and stores all samples in the DataEngine memory location at the best possible rate without inter-action with the HTTPS processor, which serves remote clients. The sam-ples received by the remote client are newly timestamped to evaluate the average arrival time later. In this way, it will be possible to evaluate two sets of consecutive timestamps separately and analyze the delay variation.
Figure 10 plots the delay variation of consecutives samples timestamped by the client when received from the network. The irregularities of those plotted delays reflect the best-effort nature of the Internet. The average delay to receive a CyberOPC message was about 93.559 ms, measured ap-proximately 45 min from the NC spiral test monitored in HTTPS-streaming mode. Although the data size of the absolute coordinates enveloped in the CyberOPC message did not dem-onstrate relevant variations, random packet size variations were measured, as indicated by the TCP packet sizes
Remote CyberOPC Client
Gateway CyberOPC Server
CNC Machine with GE-Fanuc FOCAS Sniffer C w Sniffer (a) (b) (c)
FIGURE 8 – Case study communication overview. Public IP network over (a) 3G HSPDA and (b) fiber optic. (c) Private IP network over gigabit Ethernet.
FIGURE 9 – Main screen of the CyberOPC sample client.
The OPC-UA security model consists of
authentication, authorization, encryption, and
data integrity via signatures.
registered at the network layer. Pack-ets were measured using a sniffer sta-tion equipped with the WireShark tool [23] connected to the port mirror of the network interface related to the public IP to analyze the performance of the CyberOPC protocol at the IP layer, as shown in Figure 8. The varia-tion of TCP packet sizes registered during the test is justified by the SSL mechanisms that masked traffic details to eventual external attackers.
The absolute coordinates collected were subscribed as CyberOPC items in the beginning of the test and after the remote client invoked the Stream-Start service, where deadband was zero and WaitTime was 2 s to receive automatic updates from the server on the streaming flow. The sniffer tool detected, as expected, an initial TCP handshake to open the connection behind the streaming [Figure 11(a)], a packet data flow acknowledged [Figure 11(b)], and another final TCP handshake to close the connection and the HTTPS streaming [Figure 11(c)].
During the NC spiral test program execution, the packet acquisition rate measured on the server private net-work interface while polling for contin-uous coordinates requested to the FOCAS interface was about 28.13 ms. The acquisition process was exe-cuted on the same shop floor local network of the CyberOPC server and the CNC machine. For this reason, the access delay measured for col-lecting data was more regular when compared with the access delay mea-sured over the Internet. Figure 12
outlines the normal distribution of the access delay variance of consecu-tive timestamps while collecting server data from CNC and collecting remote client data. The access delay variance on the server side represents about 16% of the variance on the remote client side. This difference is explained by the speed of the sam-pling rate from the FOCAS interface to the server because all samples were timestamped when arriving at the server, but not all samples were sent to the remote client. The test was
configured so that the server would stream the most recent available sample to the remote client, ignoring the older samples.
Conclusions
CyberOPC offers alternative read/write services similar to MTConnect, OPC-XML, and OPC-UA, but when the objec-tive becomes remote monitoring over IP, the HTTPS-streaming solution offers considerably lower delays.
On the other hand, the CyberOPC solution replaces the weight of Web
(3,275) PSH, ACK-Len: 250 PSH, ACK-Len: 140 PSH, ACK-Len: 1,460 PSH, ACK-Len: 22 PSH, ACK-Len: 22 ACK PSH, ACK-Len: 1,460 (3,275) (3,275) (3,275) (3,275) (3,275) (3,275) (80) (80) (80) (80) (80) (80) (80) (3,275) (3,275) (3,275) (80) (80) (80) SYN ACK SYN, ACK (3,275) (3,275) (3,275) (80) (80) (80) FIN, ACK RCT, ACK ACK (b) (a) (c)
FIGURE 11 – (a) TCP opening connection behind the stream. (b) Streaming data over the TCP connection. (c) TCP closing connection behind the stream.
0 0.5 1 1.5 2 2.5 3 × 104 0 200 400 600 800 1,000 1,200 1,400 1,600 1,800
Test Execution Time
V
a
riations in Dela
y (ms)
FIGURE 10 – Delay variation of consecutives server samples timestamped by the client dur-ing the HTTP streamdur-ing.
Multinational companies interested in
process-control data exchange over distributed networks
could gain significant advantages from this
services processing based on SOAP-HTTP with the lightweight Web serv-ices based on JSON-RPC over HTTP, minimizing the computational load.
The CyberOPC client is basically an AJAX client that is able to process JSON-RPC text messages, embedding commands to read, write, subscribe, start, and stop a stream on the server. AJAX and JSON-RPC technologies can also be used from Web browsers that support asynchronous requests, such as Internet Explorer, Opera, Firefox, and most browsers with JavaScript support, including personal digital as-sistants, and smartphones. The enor-mous impact of the AJAX technologies in the Web consumer market indirectly offers a wide range of solutions for visu-alization SCADA applications based on the CyberOPC communication system. The author demonstrated how this approach based on open technologies can perform better than other well-known solutions for data process exchange over public IP networks, con-sidering access delay and portability.
Future Research
and Development
The next step to optimize the service platform will be to study and test the services over an MPLS network with reserved bandwidth. The goal is to investigate and find a relationship be-tween the number of variables periodi-cally served by the CyberOPC server using AJAX streaming and the real-time limits sustainable for a specific reserved bandwidth with an MPLS
network. The MPLS technology for Internet access is provided today by several Internet carriers worldwide. Multinational companies interested in process-control data exchange over distributed networks could gain sig-nificant advantages from this open solution.
Acknowledgments
The author acknowledges the Sa˜o Paulo Research Foundation (FAPESP) in Brazil, for the financial support given to this research during the Ph.D. fellowship.
Biography
Nunzio Marco Torrisi (nunzio. [email protected]) received his M.D. and Ph.D. degrees in computer engi-neering from the University of Cata-nia in CataCata-nia, Italy, in 2002 and 2006, respectively. Since 2005, he has been a member of the IEC, Technical Com-mittee SC65C, Working Group 12, Functional Safety for Fieldbus. Until December 2008, he was a postdoc-toral scholar at University of Sa˜o Paulo in Brazil, with the Nucleus of Advanced Manufacture and the Manu-facturing Process Optimization, where he was responsible for remote control projects over the KyaTera network. Since January 2009, he has been an associate professor at the Federal University of ABC in Sa˜o Paulo, where he is currently teaching computer networks and industrial informatics. He is a Member of the IEEE.
References
[1] D. Crane and P. McCarthy, Comet and Reverse AJAX, New York: Apress, 2008. [2] Q. Zhou, R. Bian, and Y. Pan, ‘‘Design of
electric power web system based on comet,’’ in Proc. 2nd Int. Conf. Intelligent Computation Technology and Automation, 2009 (ICICTA 09), vol. 3, pp. 42–45.
[3] CyberOPC Project (2010, May 10). Cyber-OPC Specification [Online]. Available: http:// www.cyberopc.org
[4] N. M. Torrisi and J. F. G. Oliveira, ‘‘Remote control of CNC machines using the Cyber-OPC communication system over public networks,’’ Int. J. Adv. Manufact. Technol., vol. 39, no. 5–6, pp. 570–577, Nov. 2008. [5] V. V. Vyatkin, J. H. Christensen, and J. L.
M. Lastra, ‘‘OOONEIDA: An open, object-oriented knowledge economy for intelli-gent industrial automation,’’ IEEE Trans. Ind. Informatics, vol. 1, no. 1, pp. 4–17, 2005. [6] MTConnect Institute. (2010, May 10). MTCon-nect Standard V1.1.0 [Online]. Available: http://www.mtconnect.org
[7] Standard ECMA-262 ECMAScript Language Specification, 5th ed. Dec. 2009.
[8] A. Aziz and J.-K. Kollhof, May 10, 2010. JSON-RPC 1.1 Specification [Online]. Avail-able: http://json-rpc.org/wd/JSON-RPC-1-1-WD-20060807.html
[9] M. Zielinsky, ‘‘Digital fieldbus installations use EDDL for simplicity with advanced, full functionality,’’ Comput. Control Eng. J., vol. 15, no. 6, pp. 24–31, 2005.
[10] IEC Function Blocks (FB) for Process Con-trol–Part 3: Electronic Device Description Lan-guage (EDDL), IEC Standard 61804-3, 2006. [11] R. P. Pantoni and D. Brandao, ‘‘Developing
and implementing an open and non-propri-etary device description for FOUNDATION fieldbus based on software standards,’’ Comput. Stand. Interfaces, vol. 31, no. 2, pp. 504–514, 2009.
[12] X. Yao, H. Li, R. Ding, J. Yang, H. Tang, and X. Zhang, ‘‘Remote monitoring and diagnosing of fieldbus systems–An embed-ded device way,’’ in Proc. 2009 Joint Conf. Pervasive Computing (JCPC) pp. 539–542. [13] OPC Foundation (2010, May 10), OPC-UA
Specifications [Online]. Available: http:// www.opcfounfation.org
[14] Security for Industrial Automation and Con-trol Systems, ANSI/ISA-99.00.01-2007. [15] IEC Cyber-Security, IEC Standard 61784-4, 2006. [16] ITU Recommendation X.509 Version 3, ‘‘Information technology–Open systems inter-connection–The directory authentication framework,’’ Geneva, Switzerland, Aug. 1997. [17] World Wide Web Consortium (W3C), (Feb.
2002). XML-signature syntax and proces-singW3C [Online]. Available: http://www. w3.org/TR/xmldsig-core/
[18] IBM, Microsoft, RSA Security, and VeriSign, (2002, Dec.). Web services secure conver-sation language (WS-SecureConverconver-sation) Version 1.0 [Online]. Available: http://xml. coverpages.org/WS-SecureConversationV10.pdf [19] IBM, Microsoft and VeriSign, (2002, Apr.). Web services security (WSSecurity) Ver-sion 1.0 [Online]. Available: http://msdn. microsoft.com/en-us/library/ms951257.aspx [20] S. Shirasuna, A. Slominski, L. Fang, and D. Gannon, ‘‘Performance comparison of secu-rity mechanisms for grid,’’ in Proc. 5th IEEE/ ACM Int. Workshop on Grid Computing (GRID ’04), 2004, pp. 360–364.
[21] Laboratory for Optimization of Manufac-turing Processes (2010, July 19). Available: http://www.opf.sc.usp.br/
[22] GE Fanuc, ‘‘Ethernet communication with Ethernet board,’’ FOCAS1/2 Open CNC Libraries Documentation, Ed. 2.4, 2002. [23] A. Aziz. (2010, July 19). JayRock Library
[Online]. Available: http://jayrock.berlios.de/
−150 −100 −50 0 50 100 150 200 250 300 1.5 2 2.5 3 3.5 4 4.5 5 × 10−3 Medium Values Nor mal Distr ib ution Server Timestamps Client Timestamps
FIGURE 12 – Client and server normal distribution comparison related to the delay variance for consecutive timestamps.
