See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/225719477

Remote control of CNC machines using the CyberOPC communication system

over public networks

Article  in  The International Journal of Advanced Manufacturing Technology · January 2008

DOI: 10.1007/s00170-007-1244-0

CITATIONS READS

26 1,342

2 authors:

N.M. Torrisi João Fernando Gomes de Oliveira

Universidade Federal do ABC (UFABC) University of São Paulo
33 PUBLICATIONS   179 CITATIONS    70 PUBLICATIONS   1,307 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Tidia - FAPESP View project

Advanced Manufacturing Processes View project

All content following this page was uploaded by N.M. Torrisi on 19 August 2015.

The user has requested enhancement of the downloaded file.

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 technolo-
gy 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: nunzio.torrisi@ufabc.edu.br
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) architec-
tures 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; Manufactur-
ing Execution Systems (MES) and Business Intelligence
System may focus data regarding power consumption
and job process.

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 manufactur-
ing 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 GE-
Fanuc, 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
Int J Adv Manuf Technol
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 out-
lines future project researches.
2 Motivation and related works
In a scenario where a remote monitoring application distrib-
uted 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 demon-
strating 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 MORI-
MONITOR software for MORISEIKI machineries [7].
Other commercial monitoring solutions are machinery-
independent, 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
Fig. 2 General overview of MTConnect middleware and communication
schema
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 JSON-
RPC, 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
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

OPC 2.x/3.x FOCAS MTConnect OPC-XML/UA CyberOPC Shared variables

IP network Private Private Private/public Private/public Private/public Private

Device description No Limited No Yes Yes No
Polling mechanism Yes Yes Yes Yes No Yes
Data encoding Binary Binary XML XML/Binary JSON Binary
Authentication User User – Mutual Mutual User
Deadband algorithm Yes No No Yes Yes Yes
WebServices No No No Yes No 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 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, 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 func-
tions, 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 PROFI-
BUS 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 Spec-
ifications 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 micro-
controllers 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
HTTP Response
Header
Body
Fig. 3 HTTP protocol communication schema
equipment or CNC tools; the central block is the Applica-
tion 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 non-
proprietary is the license agreement bonded to the technol-
ogy 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 indus-
tries where manufacturing cells, CNC tools, and SCADA
systems are typically applied.
3.2 JSON-RPC services of CyberOPC
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 Polling mechanism over HTTPS forcing the KeepAlive
notification, it must be replied with a response. JSON option to maintain an open connection between Client and
works over HTTP and does not need SOAP. HTTP requests Server, and to stream the changed data over that connection.
and responses can be used as transport for communicating Figure 6a and b resumes the Server logic to keep the data
between peers. The communication between peers, one
being an HTTP Client and the other an HTTP Server, may
a
span multiple HTTP requests. A client-side peer may send POST /mycyberopcservice HTTP/1.1
User-Agent: CyberOPCClient/1.6
one or more requests, notifications or responses to its peer Host: www.example.com
Content-Type: application/json
by sending an HTTP request containing all serialized Content-Length: 181
Connection: Keep-Alive
objects. The server-side peer must reply with responses to Accept: application/json
all requests sent, and may send requests or notifications of {
its own. The client-side peer must reply to received requests "version" : "1.1",
"method" : “Read",
by sending another HTTP request. "params" : {
“Options”:
The CyberOPC JSON-RPC Services exchange data with {
"ReturnErrorText”:false,
the devices linked to the device or platform replacing the “ReturnItemTime“:true,
“ReturnItemName“:true,
well-known schema of the OPC Data Access Specification, “LocaleID”:“en”
but instead of adopting the complexity of the Web Services },
“ItemList”: [ “ItemName1”, “ItemName2”,
over SOAP, a light-weight, more portable, and cross- “ItemName3”]
}
platform 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
b
the functionalities of the services described in the OPC- HTTP/1.1 200 OK Connection: close
Content-Length: 23
XML DA Specification [2]. The CyberOPC primitive Content-Type: application/json
Date: Sat, 08 Jul 2006 12:04:08 GMT
services GetStatus, Read, GetParameters, Subscribe, Sub- Server: CyberOPC Server/1.0

scriptionCancel, Write, and Browse provide the same {

"version" : "1.1",
functionalities from the OPC-XML-DA Specification, "result" :
{
while SubscriptionPolledRefresh was replaced because, “ReadResult”: { “RcvTime”:"2003-05-
after the initialization, the HTTP Streaming mechanism 27T00:15:36.6400000-07:00“, “ReplyTime”:"2003-
05-27T00:15:36.7500000-07:00“,
sends data continuously from the Server to the Client not “ServerState”:"running" },
“RItemList”: {
waiting for refresh request commands from the Client side. {“ItemName”:"Simple
Types/UInt“, “Timestamp”:"2003-05-
The syntax of the Read command and the related JSON-RPC 27T00:15:36.7343750-07:00“,
“Value”:[“unsignedInt",”4294967295”]},
command over an HTTP request is shown in the example in {“ItemName”:"Simple Types/Int“,
“Timestamp”:"2003-05-27T00:15:36.7343750-
Fig. 5a. 07:00“, “Value”:[“int”,”2147483647”]},
The related JSON-RPC response command over an {“ItemName”:"Simple
Types/Float“, “Timestamp”:"2003-05-
HTTP response is shown in the example in Fig. 5b. 27T00:15:36.7343750-07:00“, “Value”:
[“float”,”3.402823E+38”]}
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, Fig. 5 a Example of a CyberOPC read service request. b Example of
the CyberOPC Communication System replaces the OPC a cyberOPC read service response
Int J Adv Manuf Technol
Server
a (CNC side)
SSL Authentication Auth. Request
Process
Auth. Response
Commands
Dispatcher Command StreamStart
(ex. Stream Start)
Stream Data
Stream Data
Send Data and
Stream Data
Leave Connection
Opened
Stream Data
(ex. Data Streaming)
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 ReadItemFrom-
Device 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 connec-
tion 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.
Client Server Client
(Remote HMI) b (CNC side) (Remote HMI)
Auth. Request
SSL Authentication
Process Auth. Response
Commands
Dispatcher Command StreamStop
(ex. StreamStop[x])
ms
90
Stop Send Data for Close Notification
Stream[x] and Close
Connection
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 XML-
based 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 secu-
rity mechanisms are XML-Signature [19] and WS-
SecureConversation [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].

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 GE-
Fanuc 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 Data-
Engine 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 Public IP Network
over Gigabit Ethernet over Fiber Optic
Gateway
CNC CyberOPC Server
Fig. 7 Case study communication overview
Int J Adv Manuf Technol
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 best-
effort 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 3G HSPDA
Remote
CyberOPC Client
Int J Adv Manuf Technol

Fig. 8 Delay variation of con- 1800

secutive server samples time-
stamped by the client during the 1600
HTTP streaming
1400

1200

Variations in Delay(ms)
1000

800

600

400

200

0
0 0.5 1 1.5 2 2.5 3
4
Test Execution Time x 10

While executing the NC spiral test program, the configuration, the Server streams the most recent available
sampling rate measured on the Server polling, for contin- sample to the Remote Client, ignoring older samples.
uous 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 5 Conclusions
Server and the CNC machine. Consequently, the access
delay measured for collecting data with the GE Fanuc The test performed in the case study demonstrated that the
Module was more regular when compared to the access CNC data acquisition process in the local network of a shop
delay measured for the process executed over the Internet. floor is quite simple. Eventual difficulties are related to
Figure 9 shows the distribution of the medium access delay acquiring legacy CNC variables that are not included in the
values for consecutive timestamps from the Server data library or the environment. Moreover, difficulties in the
collection and Remote Client data collection. Comparing remote process data delivery are related to network security
the access delay variance, the Server side represents about and transport issues.
16% of the variance on the Remote Client side. This CyberOPC offers alternative Read/Write services similar
difference is explained by the speed of the sampling rate to MTConnect, OPC-XML, and OPC-UA, but when the
from the FOCAS interface to the Server because all objective becomes remote monitoring over IP, the Cyber-
samples are time-stamped when arriving at the Server, but OPC HTTPS Streaming Solution offers considerably lower
not all samples are sent to the Remote Client. In this test delays.

Fig. 9 Client and server com- −3

x 10
parison related to the delay
Server Timestamps
variance for consecutive time- 5 Client Timestamps
stamps
4.5

4
normal distribution

3.5

2.5

1.5

−150 −100 −50 0 50 100 150 200 250 300

medium values

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
View publication stats
Int J Adv Manuf Technol
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 non-
proprietary 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/ws-
secureconversation.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