Int J Adv Manuf Technol DOI 10.1007/s00170-011-3580-3
ORIGINAL ARTICLE
Remote monitoring for high-speed CNC processes over public IP networks using CyberOPC Nunzio Marco Torrisi & João Fernando Gomes de Oliveira
Received: 27 July 2010 / Accepted: 8 August 2011 # Springer-Verlag London Limited 2011
Abstract Process analytical technology encourages the industry to adopt innovative technologies to increase quality. The key components of this approach are better understanding the product manufacturing process, data analysis, process analytical tools, process monitoring, and continuous feedback during the manufacturing process. Remote process analytical technology over public IP networks can significantly reduce the cost of maintenances and technical support, and simplify the classical OPC-like architecture based on multiple server gateways. The requirements for using remote process analytical technology for high-speed processes are mainly concerned with cyber security and high data refresh rate on the remote monitoring machine. This work intends to evaluate a new, open application protocol named CyberOPC dedicated to CNC machines. The CyberOPC version presented in this paper supersedes the first version presented in previous papers, which had no streaming features. The CyberOPC technology is not only an open alternative to other data exchange protocols, but it also introduces streaming capabilities to gain high refresh rate on remote control stations. It is based on the Client/Server Model, where a
Electronic supplementary material The online version of this article (doi:10.1007/s00170-011-3580-3) contains supplementary material, which is available to authorized users. N. M. Torrisi (*) Centro de Engenharia, Modelagem e Ciências Sociais Aplicadas (CECS), Universidade Federal do ABC (UFABC), São Bernardo do Campo, São Paulo, Brazil e-mail:
[email protected] J. F. G. de Oliveira Technological Research Institute of the State of Sao Paulo (IPT), São Paulo, Brazil
software layer is introduced between CNC and the remote monitoring station, on the Server side of CyberOPC. Even if the case study adopts a tunneling Schema that includes server gateways, the requirements to develop protocols in embedded devices and modern CNC are fulfilled by several devices that include a TCP/IP stack. Keywords CNC . HTTP. COMET . JSON-RPC . OPC . MTConnect . CyberOPC . Fieldbus . Industrial communications . Factory automation systems
1 Introduction The emerging technologies in industrial monitoring and control, such as OPC-UA [1] and MTConnect [2], design a wide range of prospective Internet Protocol (IP) architectures dedicated to industrial equipments. This vision includes public and non-public IP networks, and issues related to cyber security. In the manufacturing world, modern CNC machines can be considered as shop floor production cells, which embed highly integrated fieldbuses, PLCs, sensors, and actuators to perform milling and grinding operations. Each of these operations carry out data related to the CNC internal functions and to the object manufactured during its processing. Applications consuming these data are heterogeneous. Process Analytical Technology (PAT) applications may analyze data for process optimization; Supervisory Control and Data Acquisition (SCADA) applications will provide graphical process supervision; Manufacturing Execution Systems (MES) and Business Intelligence System may focus data regarding power consumption and job process.
Int J Adv Manuf Technol
The use of public IP networks, such as the Internet, creates scenarios where each consumer application can be strategically distributed in remote locations, where human and physical resources are more specific and convenient. For instance, modern milling machines are equipped with Fast Ethernet interfaces for monitoring and control at local networks. Software interfaces, like Fanuc Open CNC API (FOCAS) [3, 4] and its libraries, represent a de facto standard for local control applications in many manufacturing shop floor environments. So a gateway protocol is required in order to transport the CNC data collected in local networks by legacy libraries, such as the FOCAS GEFanuc, over public IP networks. Furthermore, OPC Classic [1] and OPC-UA Transport Technologies were defined as general purpose technologies for industrial data exchange in a wide range of industrial equipments. Today, these technologies include various transport protocol profiles to cover most IP application protocols, such as TCP and HTTP. Monitoring special fast phenomena as abnormal cutting generated by tool crashing workpiece and from normal cutting and other fast phenomena as crashing and jerk, is a challenge for many commercial remote monitoring solutions. The occurrence of these abnormal phenomena is often followed by enormous energy, causing damages to the system. This work describes related works, gateway protocol features offered by OPC-UA and MTConnect, and their limitations in Section 2. Section 3 details the CyberOPC Application Protocol [5] and Services. Section 4 describes the case study of a remote control using CyberOPC Fig. 1 Comparing the delay variation of unidirectional, consecutive packets, between the first version of CyberOPC and OPC-DA-XML and DCOM-based OPC-DA
Application Protocol to monitor the job in a Mori Seiki vertical machine model over a 3G Mobile Network. Section 5 summarizes the conclusions and Section 6 outlines future project researches.
2 Motivation and related works In a scenario where a remote monitoring application distributed on a large IP network sends and receives data from manufacturing cells, data originated from the device usually passes through at least one intermediate station, which generally supports an OPC interface to exchange data among manufacturing cells. Specific requirements of CNC machines for remote control over public IP networks have been described and compared to the classical OPC model demonstrating the impact on high-speed remote process control [6]. The general performance from the first version of CyberOPC compared to OPC Data Access XML and DCOM-based OPC Data Access is illustrated in Fig. 1, using data obtained from experimental results of different communication architectures, in terms of delay variation of unidirectional, consecutive packets. Figure 1 indicates that the difference in performance between the first version of CyberOPC and other Web Services was the refresh rate for CNC data served to the remote control station. The refresh rate was measured comparing the variation of the delays of unidirectional, consecutive packets between the first version of CyberOPC and OPC-DA-XML and DCOM-based OPC-DA.
Int J Adv Manuf Technol
Tests performed with the first version of CyberOPC demonstrated that the minimal interval to schedule, process, and send a data process message using Web Services demanded more than 1 s, while the correspondent interval for CyberOPC was no longer than 800 ms. This significant reduction encouraged the continuation and enhancement of the CyberOPC Communication System to the current public released version. Another recent alternative communication system based on the HTTP protocol was proposed by the MTConnect Institute [2] in order to offer an application protocol standard capable of passing industrial data to higher level systems using the eXtensible Markup Language (XML)-based standard, as shown in Fig. 2. The MTConnect protocol introduces a cross-platform communication schema over HTTP that is simpler and less sophisticated than OPC, OPC-XML, and OPC-UA. The main advantages are the XML data encoding and the HTTP Client/Server approach, very similar to the first CyberOPC solution. However, MTConnect Communication does not support any specific monitoring schema, such as the OPC subscription polling schema, in order to optimize periodic data monitoring over IP. Commercial monitoring solutions based on FOCAS libraries are available for private IP networks and limited to CNC machine vendor description, such as the MORIMONITOR software for MORISEIKI machineries [7]. Other commercial monitoring solutions are machineryindependent, such as OPC 2.x/3.x (also called OPC Classic) and NI (National Instruments) shared variables [8], but they are limited to private IP networks and sometimes require
the internal use of the same FOCAS libraries mentioned above to exchange data with CNC machineries. Situations like cutting with over-worm tools, reaching a hard point in the material being cut, and the banging phenomena caused by G00 command for fast-feeding the tool, are produced in time intervals of milliseconds. The current CyberOPC solution adopted in the case study described in this paper introduces three important improvements: & & &
The use of HTTP Streaming over SSL (HTTPS), as a faster alternative to the OPC subscription poll mechanism; Data encoding in JavaScript Object Notation (JSON) format [9], as a more compact alternative to XML; The use of the JSON-RPC command syntax [10] over HTTPS to define CyberOPC Services.
These improvements, detailed below, optimize the use of network resources, minimize data access delay, and enhance the flexibility by adopting open standards, such as JSONRPC, for the command syntax. But then, the natural consequence of the optimized use of public IP networks through the HTTP Streaming is optimizing the data-retrieving process from the industrial equipments. For such reason, CyberOPC Server Architecture was extended into a plug-in-based modular server where, for each device, a data access plug-in module can be developed. For special industrial processes with high-speed dynamics, such as a CNC process, the data access module can execute data retrieving faster than an OPC Server, which usually has a lower-bound data access delay of 200 ms. Table 1 outlines the main differences between the current specifications of OPC-UA, DCOM-based OPC 2.x/3. x, MTConnect, and CyberOPC. Table 1 includes a selection of characteristics that influence performance in remote control over IP networks. 2.1 Deadband algorithm and polling mechanism
Fig. 2 General overview of MTConnect middleware and communication schema
In a Client/Server scenario for remote monitoring, client applications are interested in periodic data refresh from Server values. A common practice is grouping the values of items of interest 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 simply requesting the group name identifier. Additionally, it is possible to schedule periodic updates of data values sent from the Server to the Client using a mechanism called Subscription Polling Mechanism. Although this mechanism 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 Client because some values may not change enough to be relevant for the client application.
Int J Adv Manuf Technol Table 1 Comparing OPC Classic, XML/UA, FOCAS, MTConnect and CyberOPC
IP network Device description Polling mechanism Data encoding Authentication Deadband algorithm WebServices
OPC 2.x/3.x
FOCAS
MTConnect
OPC-XML/UA
CyberOPC
Shared variables
Private No Yes Binary User Yes No
Private Limited Yes Binary User No No
Private/public No Yes XML – No No
Private/public Yes Yes XML/Binary Mutual Yes Yes
Private/public Yes No JSON Mutual Yes No
Private No Yes Binary User Yes No
In order to minimize the size of data sent to the Client from the Server related to changed values of interest, the Client can specify a parameter called DeadBand for each group, which determines the percentage of range for an item value that must change prior to the value being of interest to the Client. Changes in values out of the Client's interest are not sent to Client, therefore reducing the size of data delivered over the network. 2.2 XML and JSON data encoding Textual data encoding is required when working over the HTTP Protocol. JSON and XML are simple and well-known textual data representation formats also for manufacturing [11]. XML was selected by the OPC Foundation as the textual data encoding format, since the first release of the OPC-XML Data Access (DA) Specification 1.0 in 2003. More recent than XML, JSON was initially defined in 1999 as part of ECMA Standard 262 [9], ISO/IEC 16262, and detailed in the RFC 4627 in 2006. It is considered a light-weight data-interchange text format. XML and JSON are completely languageindependent, but JSON uses just two primitive data structures: a collection of name/value pairs and an ordered list of values. In almost all languages, these structures are both available and it is easy to write parsers from/to JSON streams. 2.3 Device description Device Description Technology describes the characteristics of the devices to HMI and SCADA configuration tools. In CNC tools, many process variables and internal set points can be accessed by general purpose read/write memory driver functions through their memory addresses. CNC tools provided with FOCAS interface include functions, such as cnc_sramget or cnc_getsraminfo, to read specific CNC memory locations over a local IP, but the meaning and the relevance of those variables are often
detailed and explained in the memory-map library book, which implies a deep investigation to find the exact memory location related to the specific parameter to build process analytical and diagnostic tools. The Device Description Technology has already been applied to FOUNDATION fieldbus™, HART, and PROFIBUS devices [12] to simplify the device documentation process. The purpose of the CyberOPC Application Protocol is to provide basic services to transfer Device Description files from the Server to the remote client application. This means that the Server keeps references between the loaded devices and their Device Description files. The file type and format for the Device Description is not defined in the CyberOPC Specification [5], but an open and non-proprietary Device Description solution, such as Open-EDD [13], could be an interesting option to integrate this technology to CNC machines. 2.4 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 Windows legacy, and for such reason, the authentication is Windows-based and managed from the Server side's Operating System. OPC XML-DA and MTConnect assume that the transport will handle security. This means it is possible to configure a mutual authentication for the Client and the Server even if the selected transport protocol is SSL, HTTPS, or HTTP-SOAP. The OPC-UA Security Model consists of authentication, authorization, encryption, and data integrity via signatures. Nevertheless, the OPC Foundation has adopted the Web Service Security Specification Model for conversations in encoded text and binary. These conversations are also named Unified Architecture (UA) Secure Conversation and they can include mutual authentication behind an encrypted virtual channel.
Int J Adv Manuf Technol
CyberOPC and OPC-UA authentication use X509 certificates exclusively, but the first adopts SSL Mutual Authentication instead of the Web Services Security Model. 2.5 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 Protocol Transport Message consists of one header and one body as shown in Fig. 3. In order to send commands over this transport protocol, it is necessary to envelop the commands, whether inside the header or the body. OPC-XML and OPC-UA adopt the Web Services technology based on the SOAP Protocol, 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. So, MTConnect and CyberOPC embed commands inside the HTTP bodies. For embedded network devices, thin clients, and microcontrollers that implement a standard HTTP Protocol without SOAP, the computation of HTTP Headers with SOAP could be too sophisticated or simply impossible, while the computation of HTTP bodies should be achievable without extra computational resources [14].
3 The CyberOPC architecture and services The CyberOPC Project [6] also provides Client/Server Software Sample System composed of an HTTP Server and an HTTP Client library. Services defined in the CyberOPC Specification substitutes the weight of Web Services processing based on SOAP–HTTP with the light-weight Web Services based on JSON-RPC over HTTP. Figure 4 shows the software modules that integrate the CyberOPC Server. The block on the left represents the industrial
Header
Server HTTP
Body HTTP Request
equipment or CNC tools; 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; the block on the right sends the HTTP messages, parses the JSON-RPC commands, and forwards the command message to the central block. The communication delays between the blocks in Fig. 4 influence the total delay when receiving updated values from the shop floor device to the remote client. This value can be quantified as a sum of the device data access delay, the application message broker delay, and the remote data access delay. The device access delay represents the time for the device to process, schedule, and send changed values to the application server. The application message broker delay is the time to send remote requests/responses and process data collected from the device. The remote data access delay depends on the network, but it is possible to tune the transport protocol to optimize that value. The CyberOPC Specification also introduces the use of HTTP Streaming technologies to provide continuous process monitoring. The HTTP Streaming approach adopts AJAX COMET Methodologies [15] to reduce the delay of synchronous traffic in continuous process monitoring. 3.1 Adopting an open standard and interoperable technologies over IP networks The CyberOPC Specification is open, free, and based on open technologies such as JSON, JSON-RPC, HTTP, and SSL. Adopting open standards in Industrial Informatics can be defined as the ability to design software and services with an architecture specially projected to foresee the integration with other technologies. This is, however, a non-functional requirement of the project. Property rights are not strictly tied to the cost, but to the rights to the object or the technology. In practical terms, what characterizes a technology as proprietary or nonproprietary is the license agreement bonded to the technology by the holder of the intellectual property rights [13]. The concept of interoperability is the ability of a system to work with other systems without special efforts from the customer. The solution proposed adopts open standard technologies for communication in manufacturing industries where manufacturing cells, CNC tools, and SCADA systems are typically applied.
HTTP Response
3.2 JSON-RPC services of CyberOPC Header Body
Fig. 3 HTTP protocol communication schema
JSON-RPC is a remote procedure call protocol. The general mechanism consists of two peers establishing a data connection. During the lifetime of a connection, peers may invoke methods provided by other peers. A request is
Int J Adv Manuf Technol Fig. 4 CyberOPC server and client architecture
sent to invoke a remote method, and unless the request is a notification, it must be replied with a response. JSON works over HTTP and does not need SOAP. HTTP requests and responses can be used as transport for communicating between peers. The communication between 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 request 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 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 Data Access Specification, but instead of adopting the complexity of the Web Services over SOAP, a light-weight, more portable, and crossplatform approach is selected for embedded devices, and which is able to support the HTTP protocol without SOAP. The services supported by the CyberOPC partially replace the functionalities of the services described in the OPCXML DA Specification [2]. The CyberOPC primitive services GetStatus, Read, GetParameters, Subscribe, SubscriptionCancel, Write, and Browse provide the same functionalities from the OPC-XML-DA Specification, while SubscriptionPolledRefresh was replaced because, after the initialization, the HTTP Streaming mechanism sends data continuously from the Server to the Client not waiting for refresh request commands from the Client side. The syntax of the Read command and the related JSON-RPC command over an HTTP request is shown in the example in Fig. 5a. The related JSON-RPC response command over an HTTP response is shown in the example in Fig. 5b. When CyberOPC Client and Server need multiple interactions, the performance is improved by using the HTTP KeepAlive header option to reuse the already opened connection, especially during the HTTPS Streaming. Thus, the CyberOPC Communication System replaces the OPC
Polling mechanism over HTTPS forcing the KeepAlive option to maintain an open connection between Client and Server, and to stream the changed data over that connection. Figure 6a and b resumes the Server logic to keep the data
a
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”] } }
b
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-0527T00:15:36.6400000-07:00“, “ReplyTime”:"200305-27T00:15:36.7500000-07:00“, “ServerState”:"running" }, “RItemList”: { {“ItemName”:"Simple Types/UInt“, “Timestamp”:"2003-0527T00:15:36.7343750-07:00“, “Value”:[“unsignedInt",”4294967295”]}, {“ItemName”:"Simple Types/Int“, “Timestamp”:"2003-05-27T00:15:36.734375007:00“, “Value”:[“int”,”2147483647”]}, {“ItemName”:"Simple Types/Float“, “Timestamp”:"2003-0527T00:15:36.7343750-07:00“, “Value”: [“float”,”3.402823E+38”]} } } }
Fig. 5 a Example of a CyberOPC read service request. b Example of a cyberOPC read service response
Int J Adv Manuf Technol
a
Server (CNC side)
SSL Authentication Process
Client (Remote HMI)
Auth. Request
b
Server (CNC side)
Client (Remote HMI)
Auth. Request
SSL Authentication Process
Auth. Response
Auth. Response
Commands Dispatcher (ex. Stream Start)
Commands Dispatcher (ex. StreamStop[x])
Command StreamStart
Command StreamStop
Stream Data
Send Data and Leave Connection Opened (ex. Data Streaming)
90 ms
Stream Data Stream Data
Stop Send Data for Stream[x] and Close Connection
Close Notification
Stream Data
Fig. 6 CyberOPC server schema to keep an open connection during the data streaming
stream over the same open connection and to close the stream using a separate command. 3.3 The GE-Fanuc module The CyberOPC Server adopted in this work, which is available at the project's official web site, operates with multiple devices or CNC tools through the developed ad hoc plug-in modules that are stored at the Server's plug-in folder. To run a plug-in module, it is necessary to implement five interface methods, which are called by the Server in Runtime. These methods are: & & & & &
Initialize(); StartDataEngine(); StopDataEngine(); WriteItemToDevice(string ItemID, string ItemValue); ReadItemFromDevice(string ItemID);
The Initialize method must include a set of all initialization actions required to create and keep a stable connection with the device. The StartDataEngine and StopDataEngine methods start and stop the data collection process in a separated thread. The WriteItemToDevice method concludes a Write request to the local device for a specified ItemID. On the other hand, the ReadItemFromDevice method reads the value from a specified ItemID. This last method is mapped in the GE-Fanuc Module by the FOCAS command cnc_absolute2, which passes a connection handle and the number of axes from CNC. The function cnc_absolute2 reads the value as the absolute position displayed on the CNC screen. The process that collects the absolute coordinates is asynchronous and does not depend on the process related to HTTP processing. As described in the specification, the CyberOPC Server should organize each data collection in a dedicated memory cache where updated data from the module can be remotely read over HTTP.
3.4 CyberSecurity issues For all case scenarios of communication over public IP networks, strong network security is recommended [16]. The standardized network security and safety practice solution proposed in the IEC 61784–4 is the IPSec [17]. 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 solution for HTTP. For HTTP communication, there are two categories of security mechanisms: transport-level security and XMLbased message-level security. The transport-level security mechanism uses Server Secure Socket (SSL), using digital X.509 certificates [18]. SSL is light weight because it does not involve any XML manipulations. Message-level security mechanisms are XML-Signature [19] and WSSecureConversation [20]. 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-Security specification [21]. With XML-Signature, each message is signed with an X509 certificate. It ensures the integrity of a message, but it does not support replay-attack prevention. This mechanism is stateless and does not need any initial handshakes, and thus, it is suitable for a single invocation of a service. WS-SecureConversation is a protocol to establish and use secure contexts with SOAP messages. First, a secure context is established between a Client and a Server. Once the security context is established, following messages are signed using the XML-Signature standard. It is fast because it uses a symmetric key to sign messages, but it requires additional round trips to establish a connection. Comparing the performance of the three 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 option as in the CyberOPC monitoring reduces the response time by half [22].
Int J Adv Manuf Technol
4 Case study The case study shown below was executed with a Mori Seiki CNC Vertical Machining Center, Model NVD1500DCG, equipped with a Fast Ethernet port and GE-Fanuc FOCAS 2 protocol interface [3]. The architecture adopted to perform the remote control test is outlined in Fig. 7. The private IP network at the bottom of Fig. 7 linked the CNC machine to the workstation equipped with 2 GB Network Interfaces. The first interface was connected to the public IP network and the second interface was connected to the shop floor private IP network. The workstation acted as a gateway in order to convert the CNC Protocol to the CyberOPC Protocol. During the test, the public IP address assigned to the CyberOPC Server was 143.107.238.241, and the port configured to accept the HTTPS connection was port 80. On the private IP network side, the CyberOPC Server collected and time-stamped a set of CNC variables performing continuous network polling through the GEFanuc FOCAS 2 interface. The network interface of CNC was a 100 MB Ethernet and the average value of the delay between two consecutive updates 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, samples of synchronous sets of variables X, Y, and Z were collected using the FOCAS 2 command cnc_absolute2. These three variables represent the absolute coordinates for the axis X, Y, and Z as they are displayed on the CNC screen of the local HMI machine display. Each sample of this set of variables was marked with a timestamp by CyberOPC and stored in the DataEngine Memory. The remote Client was an ASUS 1000H Netbook equipped with 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 CyberOPC Sample Client, open source and freely available at the CyberOPC Project website [5], as well as the Server. The NC program loaded for the test in the CNC machine was a simple 2D spiral shape. During the test, this program
Private IP Network over Gigabit Ethernet
CNC Fig. 7 Case study communication overview
was executed with 150% of the actual feed rate, which means approximately 350 mm/min with spindle 100 for the selected Mori Seiki model. The full NC source program, Matlab data files, network dump files, pictures, and videos captured during the test are available at the CyberOPC Project website [5]. 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 data acquisition process is asynchronous: it collects and stores all samples in the DataEngine at the best possible rate without interaction with the HTTPS processor, which serves remote clients. When the Remote Client requests a sample in Streaming mode, the HTTPS processor responds with the last refreshed sample available in the DataEngine Memory, with the timestamp of the Server. The samples received by the remote client were newly time-stamped in order to evaluate the average arrival time later. This way, it will be possible to evaluate two sets of consecutive timestamps separately and analyze the delay variation. Before starting the test, the Client and the Server were initially synchronized via Network Time Protocol in the same local network with an accuracy of around 200 μs. Figure 8 plots the delay variation of consecutives samples time-stamped by the client when received from the network. The irregularities of those plotted delays reflect the besteffort nature of the Internet. The average delay to receive a CyberOPC message was about 93.559 ms, measured during approximately 45 min from the NC spiral test monitored in HTTP Streaming mode. Although the data size of the absolute coordinates enveloped in the CyberOPC message did not demonstrated relevant variations, random packet size variations were measured as indicated by the packet sizes registered at the network layer. Packets were measured using a sniffer station equipped with the WireShark tool [23] connected to the port mirror of the network interface related to the public IP in order to also analyze the performance of the CyberOPC Protocol at the IP layer. The variation of packet sizes registered during the test is justified by the SSL mechanisms that masked traffic details to eventual external attackers.
Public IP Network over Fiber Optic
Gateway CyberOPC Server
Public IP Network over 3G HSPDA
Remote CyberOPC Client
Int J Adv Manuf Technol Fig. 8 Delay variation of consecutive server samples timestamped by the client during the HTTP streaming
1800 1600
Variations in Delay(ms)
1400 1200 1000 800 600 400 200 0
0
0.5
1
1.5
2
2.5
3 4
Test Execution Time
While executing the NC spiral test program, the sampling rate measured on the Server polling, for continuous coordinates requested to the FOCAS interface, was about 28.13 ms. The collection process was performed at the same shop floor's local network of the CyberOPC Server and the CNC machine. Consequently, the access delay measured for collecting data with the GE Fanuc Module was more regular when compared to the access delay measured for the process executed over the Internet. Figure 9 shows the distribution of the medium access delay values for consecutive timestamps from the Server data collection and Remote Client data collection. Comparing the access delay variance, the Server side represents about 16% of the variance on the Remote Client side. This difference is explained by the speed of the sampling rate from the FOCAS interface to the Server because all samples are time-stamped when arriving at the Server, but not all samples are sent to the Remote Client. In this test
Fig. 9 Client and server comparison related to the delay variance for consecutive timestamps
x 10
configuration, the Server streams the most recent available sample to the Remote Client, ignoring older samples.
5 Conclusions The test performed in the case study demonstrated that the CNC data acquisition process in the local network of a shop floor is quite simple. Eventual difficulties are related to acquiring legacy CNC variables that are not included in the library or the environment. Moreover, difficulties in the remote process data delivery are related to network security and transport issues. CyberOPC offers alternative Read/Write services similar to MTConnect, OPC-XML, and OPC-UA, but when the objective becomes remote monitoring over IP, the CyberOPC HTTPS Streaming Solution offers considerably lower delays.
−3
x 10
5
Server Timestamps Client Timestamps
normal distribution
4.5 4 3.5 3 2.5 2 1.5
−150
−100
−50
0
50
100
medium values
150
200
250
300
Int J Adv Manuf Technol
6 Future research and applications The next step on the research should focus access delays related to reserved bandwidth in order to explore the shop floor to shop floor connection over the Internet. The technology and the variety of contracts for Internet access with reserved bandwidth are offered today by several Internet carriers around the world. Multinational companies interested in process control data exchange over distributed networks should take enormous advantage from an open solution. Currently, an application based on CyberOPC is being developed considering the remote 3D online modeling reconstruction for CNC processes. This application tool should provide remote analysis of energy costs and online comparison of the effective 3D models with the estimation before the CNC job.
References 1. OPC Foundation (2011) OPC-UA Specifications, http://www. opcfoundation.org/ Accessed 3 Abr. 2011 2. MTConnect Institute (2011) MTConnect Standard V1.1.0, http:// www.mtconnect.org Accessed 3 Abr. 2011 3. Fanuc GE (2002) Ethernet Communication with Ethernet Board, FOCAS1/2 Open CNC libraries documentation, Edition 2.4 4. Ferraz F Jr, Coelho RT (2005) Data acquisition and monitoring tools with CNC of open architecture using internet. Int J Adv Manuf Tech 26:90–97 5. CyberOPC Project (2011) CyberOPC Specification, http://www. cyberopc.org, Accessed 3 Abr. 2011 6. Torrisi NM, Oliveira JFG (2008) Remote control of CNC machines using the CyberOPC communication system over public networks. Int J Adv Manuf Tech 39:570–577 7. MORI SEIKI CO., LTD (2011) MORI-MONITOR, http://www. moriseiki.com/english/products/app/morimonitor_index.html, Accessed 2 Apr 2011
8. National Instruments Corp (2011) NI Developer Zone http://zone. ni.com/devzone/cda/tut/p/id/4679 Accessed 3 Apr. 2011 9. ECMA International (2009) Standard ECMA-262 - ECMAScript Language Specification, 5th Edition 10. Aziz A, Kollhof J-K (2006) JSON-RPC 1.1 Specification, http:// json-rpc.org/wd/JSON-RPC-1-1-WD-20060807.html Accessed 3 Abr. 2011 11. Wang LD (2007) An information-integrated framework to support e-manufacturing. Int J Adv Manuf Tech 32:625–630 12. Zielinsky M (2005) Digital fieldbus installations use EDDL for simplicity with advanced, full functionality. Comput Contr Eng J Lond 15:24–31 13. Pantoni RP, Torrisi N, Brandao D (2007) An open and nonproprietary device description for fieldbus devices for public IP networks, Proceedings of 5th IEEE International Conference on Industrial Informatics 189–194 14. Yao X, Li H, Ding R, Yang J, Tang H, Zhang X (2009) Remote monitoring and diagnosing of fieldbus systems—an embedded device way, Proceedings of Joint Conferences on Pervasive Computing 15. Crane D, McCarthy P (2008) Comet and reverse AJAX”, Apress, ISBN10: 1-59059-998-5 16. ANSI/ISA Standard 99.00.01 (2007) Security for Industrial Automation and Control Systems 17. IEC Standard 61784–4 (2006) Cyber-Security 18. ISO/IEC Standard 9594–8 (2005) X.509 Cor 3 19. Eastlake DE, Reagle JM Jr, Solo D (2008) XML-Signature Syntax and Processing, W3C, http://www.w3.org/TR/xmldsig-core/ Accessed 2 Apr 2011 20. BEA, Computer Associates, IBM, Layer 7, Microsoft, Netegrity, Oblix, OpenNetwork, Ping Identity, Reactivity, RSA Security, VeriSign, and Westbridge (2004) Web Services Secure Conversation Language Version 1.1, http://specs.xmlsoap.org/ws/2004/04/sc/wssecureconversation.pdf Accessed 2 Apr 2011 21. OASIS Standard 200401 (2004) Web Services Security: SOAP Message Security 1.0 22. Shirasuna S, Slominski A, Fang L, Gannon D (2004) Performance Comparison of Security Mechanisms for Grid, Proceedings of the 5th IEEE/ACM International Workshop on Grid Computing, 360– 364 23. Wireshark Foundation (2011) WireShark, http://www.wireshark. org/, Accessed 2 Apr 2011
