Conference PaperPDF Available

Towards building OPC-UA companions for semi-conductor domain

Authors:

Abstract and Figures

Semi-conductor industry handles since decades some of Industry 4.0 concepts mainly related to the remote control and the monitoring of the equipment and devices. Production jobs in such industries are launched on aggregated set of equipment responsible of the execution of the production process. Equipment is controlled by a host. Such configurations allow the semi-conductor fabs to be highly flexible since jobs are not constrained to a single machine and a single machine can process several times the same product. SECS/GEM (SEMI Equipment Communications Standard/Generic Equipment Model) standards define the minimum specifications for the equipment/host interfaces. In this paper, we assess SECS/GEM standards against Industry 4.0 communication architecture OPC-UA. We show the complementary between both standards and propose an approach to translate stacks of the specifications of SECS/GEM standards towards OPC-UA information models. We first build UML models from which we generate services that must be exhibited by the host and the equipment interfaces and then we generate from these UML models specific OPC-UA address space model for SECS/GEM that will be deployed on OPC-UA servers and accessible by OPC-UA clients. We also provide a typical architecture for an OPC-UA
Content may be subject to copyright.
Towards building OPC-UA companions for
semi-conductor domain#
Selma Azaiez
CEA, LIST
Saclay, France
selma.azaiez@cea.fr
François Tanguy
Agileo Automation
11 rue Victor Grignard
Poitiers, France
francois.tanguy@agileo-automation.com
Marc Engel
Agileo Automation,
11 rue Victor Grignard
Poitiers, France
marc.engel@agileo-automation.com
AbstractSemi-conductor industry handles since decades some of Industry 4.0 concepts mainly
related to the remote control and the monitoring of the equipment and devices. Production jobs in such
industries are launched on aggregated set of equipment responsible of the execution of the production
process. Equipment is controlled by a host. Such configurations allow the semi-conductor fabs to be
highly flexible since jobs are not constrained to a single machine and a single machine can process several
times the same product. SECS/GEM (SEMI Equipment Communications Standard/Generic Equipment
Model) standards define the minimum specifications for the equipment/host interfaces. In this paper, we
assess SECS/GEM standards against Industry 4.0 communication architecture OPC-UA. We show the
complementary between both standards and propose an approach to translate stacks of the specifications
of SECS/GEM standards towards OPC-UA information models. We first build UML models from which
we generate services that must be exhibited by the host and the equipment interfaces and then we
generate from these UML models specific OPC-UA address space model for SECS/GEM that will be
deployed on OPC-UA servers and accessible by OPC-UA clients. We also provide a typical architecture
for an OPC-UA
I. INTRODUCTION
In the context of Industry 4.0, industrial components are intended to be interconnected horizontally (through
different business units) as well as vertically (from the enterprise to the plant levels). The reference architectural
model RAMI 4.0 [1] figures out enabling technologies and standards for Industry 4.0 as a 3D cube composed by
different layers. The interconnection between Industry 4.0 components belonging to these different layers (e.g.
ERP, MES, clouds, monitors, machines, sensors, etc.) requires a uniform data exchange mechanism as well as a
shared semantic allowing a good interpretation of the exchanged data. To handle such aspects, OPC-UA
standard [2] [3] is recommended as enabling technology allowing independent-platform data exchange. The
strength of OPC-UA is its capability to describe semantics through a framework of information models [4].
In semi-conductor industry, devices such as integrated circuits are manufactured in a fab that is composed by
several equipment (e.g. wafer fab, assembly, and test/back-end equipment) allowing to perform hundreds of
processing steps. Hosts are software applications connected to cluster of equipment in order to control and
monitor equipment processing. Typically, hosts are also called station controllers. Often the host software is part
of the factory's Manufacturing Execution System (MES). Since the eighties, communications between the fab
# Published as: Azaiez, Selma, François Tanguy, and Marc Engel. "Towards building OPC-UA
companions for semi-conductor domain." 2019 24th IEEE International Conference on Emerging
Technologies and Factory Automation (ETFA). IEEE, 2019.
host software and the manufacturing equipment in a fab have been standardized within SECS/GEM interfaces
i.e. SEMI Equipment Communications Standard/Generic Equipment Model [5]. The interface SECS is a
protocol consisting of three levels: message protocol, block transfer protocol, and physical link while the
interface GEM defines data structures, behaviors (specified as state machines) and scenarios enabling fab
software to control and monitor manufacturing equipment.
In this work, we propose to assess SECS/GEM standards against Industry 4.0 communication architecture
OPC-UA. For this purpose, we describe a methodology to build a specific OPC-UA companion for semi-
conductor industry. Two main reasons motivate our work (1) semi-conductor components will have to be
enhanced in order to be integrated within Industry 4.0 platforms; (2) semi-conductor standards provide fine
grained methods to perform remote control on semi-conductor equipment and such methods could also be used
as solutions and best practices for the remote control of other equipment in other domains. Indeed, semi-
conductor standards have proved their ability to connect equipment to MES (Manufacturing Execution Systems)
with remote control since the late eighties. This was done for a wide diversity of equipment types ranging from
stepper to inspection tools and including wafer sorters, wafer stockers, automatic tester equipment and for
multiple factories worldwide including Intel, Samsung, TSMC, ST Microelectronics, Infineon, Toshiba, Micron,
etc. Best practices of semi-conductor industry have already been applied on other industries such as photovoltaic
industry and could be applied to each industry that requires traceability, high flexibility, high level of
reconfiguration and highly fault-tolerant.
In this paper we propose an architecture that maps SECS/GEM stacks into OPC-UA information models. In
the next section, we make a global presentation of OPC-UA architecture and the semi-conductor standards.
Then, we present our architecture of OPC-UA information models for SECS/GEM. After that, we explain how
to deploy this architecture in order to obtain OPC-UA clients\servers offering SECS/GEM interfaces. We
describe the execution of our approach by relying on a simple example of a Host executing a remote command
on an equipment and collecting alarms raised by the equipment later.
II. BACKGROUND
A. OPC-UA Architecture
OPC-UA has been proposed by OPC Foundation as an extension of OPC Standards and specifications for
industrial communication. Its main innovation is its ability to build information models allowing to turn data
into semantic information [4].
To communicate, an OPC-UA client and server must share the same definition about data they exchange. The
information model framework makes the common representation of the information as a specification of an
address space model. Address space models are then deployed in the OPC-UA servers and the OPC-UA clients
can browse them.
Fig. 1. OPC-UA Information Model Framework
Part 3 of OPC-UA specification [6] provides a standard information model domain based on the generic
concepts of View, Object, ObjectType, Variable, Method, DataType, VariableType, ReferenceType. These
concepts are used to define the structure, behavior and semantics of the servers of a specific-domain OPC-UA
companion.
Figure 1 shows the layers of the information model framework provided by OPC-UA. The generic concepts
defined in the OPC-UA specifications constitute the basic meta-model used to describe one information model.
DA (Data Access), AC (Alarms & Conditions), HA (Historical Access) and Programs are proposed as
extensions of the generic information model. Data Access deals with the representation and the use of
automation data in OPC-UA servers. Alarm & Conditions specifies the concepts of condition (the state of the
system or one of its components), dialog conditions (used by a Server to request user input.), and alarms. HA
(Historical Access) allows servers to provide access to different historical data and/or events. Finally, Programs
extends the notion of method included in the AdressSpace to designate more complex and stateful functionality
in the system (e.g. run and control a batch process).
The basic OPC-UA meta-model as well as DA, AC, HA, Prog blocks could be considered as the basic blocks
that standard consortiums and vendors will extend to create the specific information model for an OPC UA
companion in a specific domain. Standardized information models for some domain have already been proposed
by OPC Foundation, in different application areas. The OPC Foundation works with several cooperation
partners, for instance, EDDL, FDI, ISA S88 and S95, MIMOSA, PLCopen, and IEC TC 57 WG 13 that jointly
develop Companion Specifications.
B. SEMI Standards
A typical architecture of a semi-conductor fab connects a host including one or several IT systems (e.g.
MES) to clusters of equipment. The host side of a connection is executing on a computer system provided by the
factory, and the equipment side of a connection is running on a controller computer provided by the equipment
manufacturer.
SECS/GEM standards structure the interface between the host and the equipment. Just like OPC-UA,
SECS/GEM interfaces are platform, technology and programming language independent. It is also service-
oriented. The Host exposes a set of services that can be consumed by the equipment and the equipment exposes
a set of services that can be consumed by the host. SECS/GEM specifies the most basic requirements to
establish the communication channel and to structure complex messages that manage remote commands. For
instance, fab hosts are able to:
start and stop processing,
select, download and upload recipes from/to the equipment,
query the equipment for values of various process parameters and equipment configuration,
set equipment configuration parameter values,
define reports of various variables and associate them with events such as lot start or wafer complete.
Equipment are able to send alarms, various events and associated reports to the fab host.
We propose the figure 2 to simplify the comprehension of SECS/GEM standard. It classifies SECS/GEM
specifications into four main layers. The lower layer defines the physical connection between hosts and the
cluster of equipment that can be based on RS232 or Ethernet. E4 also called SECS-I defines the communication
protocol associated to RS232 channel. E37 standard defines the High-speed SECS Message Services (HSMS)
associated to a TCP/IP connection.
E5 standard, also called SECS-II defines the structure of messages. These ones are organized into categories
of activities, called streams, which contain functions, used to transfer data and commands. There are two types
of E5 messages, primary messages and secondary messages. A message can transfer a simple data element, such
as a binary response or an ASCII string or a complex list structured with multiple levels of lists in the hierarchy.
Fig. 2. SECS/GEM stacks
GEM 300 defines a common set of behaviors and communication capabilities supporting the manufacturing
automation of a semiconductor equipment, i.e. adding a robotics platform to load/unload products in a machine.
Specifically, it defines scenarios and capabilities using SECSII messages. GEM 300 includes different sub-
standards. The required ones to be GEM 300-compliant are:
E30-GEM defining scenarios using E5-SECSII message
E39 defining object attributes remote access
E40 defining functions related to material processing and processing management
E87 defining the carrier management (load/unload materials in the machine)
E90 defining specifications for substrate tracking
E94 defining specifications for control job management
SEM (Specific Equipment Model) provides individual models for specific class of equipment for instance
steppers, tracks, etc. SEM aims to shorten the development cycle of the semi-conductor equipment by sharing
common specifications at the industry level.
III. APPROACH TO SEMI SERVICES MODELING
In this work, our challenge was to propose an approach to build an OPC-UA companion handling
SECS/GEM interfaces. OPC-UA is service-oriented, and the guiding principle of our method have been to select
services that have to be included in the OPC-UA interfaces in order to obtain a SECS/GEM compliant OPC-UA
companion. In OPC-UA, the information model represents the vocabulary while services represent the actual
communication of information model content. OPC-UA defines distinct services specified in the part 4 of OPC-
UA standard [7] such as secure channel, session service, view service etc. In the scope of this work, we focus on
the method call service to publish the GEM300 services provided by the host and the equipment interfaces.
We consider that all messages included in GEM300 or SEM layers are actually services that can be invoked
by the host or the equipment. As described in section II.B, GEM and SEM layers provide capabilities built using
SECS II E5 messages. Capabilities correspond to the sending of a primary E5 message followed by the
reception of the secondary E5 message.
We define a SEMI service as a pair of a primary and a secondary message. According to SECS\GEM
specification, a primary message is a service call and a secondary message is a service response. A primary
message has the Stream and Function SxFy and the corresponding secondary message has the Stream and
Function SxFy+1.
SEMIservice = {SxFy, SxFy+1}
SxFy is the service call while SxFy+1 is the response of the service call. A service in OPC-UA is specified as
a method defined within an object type. We map a SEMI service onto an OPC-UA method. The primary
message is translated as an OPC-UA method. The SECS/GEM body of the primary message where data
structures associated to the message are defined is then mapped as the input parameters of the OPC-UA method
while the secondary message body is mapped as the output parameters of the OPC-UA method. To be able to
perform such mapping all E5 messages have to be translated into an OPC-UA information model. GEM
capabilities that are built using E5 messages will be represented by another information model representing the
GEM interface of the host and the equipment including the OPC-UA methods. The same approach could be used
to build the other SEMI standards. The figure 3 shows the information framework related to SECS/GEM
standard.
In the scope of this work, we will focus on the GEM layer and its corresponding E5 messages.
Fig. 3. A mapping between OPC-UA and SECS/GEM layers
GEM capabilities define a number of E5 message scenarios. Only a subset of E5 messages is required to be
GEM-compliant. Equipment with a GEM interface provides three basic levels of host control, which determine
the host's ability to control and monitor the equipment. Remote control capability allows the host to send GEM-
defined commands like "START," "STOP," "PAUSE," "RESUME," and "ABORT" to control the equipment's
processing. The equipment can define additional custom commands. Each command can have one or more
arguments with process data. The equipment is able to raise alarms.
Semi-conductor standards are textual specifications and capturing digitally their semantics into an OPC-UA
information model is a hard task where we have to cope with two main difficulties: (1) digitalizing the semantics
of textual concepts and (2) get familiar with the new meta-model provided by OPC-UA specially when this one
is not yet provided with a clearly structured SDK as highlighted in [8]. Indeed, to support the modeling of the
information model, OPC-UA provides a DSL with a meta-model as well as a graphical language that represent
the different OPC-UA concepts which are:
Object: it represents the real-world object (e.g. the software components)
Variable: it is used to represent values. They can be complex structures.
Method: it represents the functions with input and output arguments
ObjectType: it is used to represent the type of an object
DataType: it represents the data type of Variables value.
VariableType: it is different from the DataType in the sense that it represents the “meaning” of a Variable.
ReferenceType: it represents the type of relation between the elements.
The following tables resumes the notation associated to these OPC-UA concepts.
TABLE I. OPC-UA NODES
TABLE II. OPC-UA REFERENCES
The deployment of the information model will generate the address space that is composed by nodes
associated to each element. Each Node have four mandatory attributes in common: a NodeId, a NodeClass (one
of the 8 defined above), a BrowseName and a DisplayName. These attributes enable identification of all nodes
in an address space and permits to browse in it.
Unified Automation provides a UA modeler tool [9] implementing the syntax and generating the Address
Space model. However, manually modeling a standard such as SECS/GEM requires a huge effort. As OPC-UA
metamodel is based on object oriented approach, different works claimed the necessity to adopt a model-based
approach by automating the translation between UML models capturing domains concepts towards OPC-UA
Address Space model [10][11][12][13].
The first step of our method is to build the E5 - UML model that provides the digital structure of SECS/GEM
messages. We provide an abstract syntax for E5 message structure based on the E173 standard [14]. From the
textual description found in SECSII-E5 standard [15], UML classes are specified. GEM capabilities are then
captured with two classes: EquipmentGEMServices and HostGEMServices including the capabilities as
methods. The UML model will then be translated to an OPC-UA information model. Finally, this information
model will be deployed on an OPC-UA architecture including a client and a server for the host and the
equipment. In the following sections, we will detail our method by using two SEMI services related to the
execution of a remote command and the notification of alarms.
IV. BUILDING SECSII- E5 INFORMATION MODEL
In this section, we first describe the textual structure of E5 Message then, we specify the different steps to
pass from the textual specification into the OPC-UA information model.
A. E5 Messages
As said previously, E5 messages are identified by the expression SxFy:
- When y is an odd number, then the message is a primary message i.e. request,
- When y is an even number, then the message is a secondary message i.e. response.
The direction of the message indicates whether the service is a host or an equipment service. In the figure 4,
we give an example of the message “Send Command” where the Host requests the Equipment to execute a
specified remote command with the associated parameters. The message is identified by the stream and
function S2F41. It is a primary message from the Host to the Equipment and composed by a list L of two
parameters. The first one, RCMD, represents the name of the command. The second argument <L, n> is a List
composed by n structures composed by a List of two arguments CPNAME and CPVAL.
Fig. 4. Equipement service “send command”
The corresponding secondary message S2F42 is SendCommandAcknowledge having approximatively the
same structure and described in the figure 5.
Fig. 5. Acknowledge of send command
When alarms are raised, the equipment sends the alarm report using the message S5F1 presented in the fig 6.
This message contains a list of three parameters. ALCD is the alarm code byte. ALID is the alarm type identifier
while ALTX is the alarm text.
Fig. 6. Equipement service “send Alarm Report”
The corresponding secondary message S5F2 is SendAlarmReportAcknowledge. Its structure is described in
the figure 7. Once receiving the alarm report, the host sends an alarm report acknowledge with confirmation
code.
Fig. 7. Equipement service “send Alarm Report”
B. E173 MetaModel
The purpose of E173 standard is to define a standardized XML notation to represent the content of E5
messages. It provides an XML Schema Definition from which we extract an UML representation of the message
content. We used this UML representation as a metamodel describing the abstract syntax of E5 Message (cf.
figure 8).
Fig. 8. E173 metamodel
An E5 message is defined by the class SECSMessage with the attributes stream, function, name and
direction. SECSMessage is composed of a body of DataItems describing the parameters. These later are
provided as a named list with a minimum and a maximum size. The list can contain an array of objects or
another List (with a recursive description.
C. Enhancement of E5 messages
One difficulty of E5 standard is that not all data structures are given a name, especially in the list-based
structure. In order to be compliant with E173 metamodel, we give every data structure a name.
Fig. 9. Parameters Naming
For example, as shown in the figure 9, in addition to the standardized names (in between < > characters), the
other structures are given names (in blue). This way one can access any structure by name inside a message.
D. Transformation to UML model
The textual representation enhanced by the name of anonymous structures can now be parsed and
transformed to UML class models according to the following transformation rules:
Each primary message is translated into a service request class which name is the name of the primary
message concatenated with “Request” suffix
Each secondary message is translated into response class which name is the name of the primary
message concatenated with “Response” suffix
Simple type parameters are translated as class attributes
Array type parameters are translated as class attributes
Fixed size lists are translated into a class
Not fixed size lists are translated into a composition labeled with the list name
The figure 10 defines the UML classes after the transformation of S2F41, S2F42, S5F1 and S5F2 messages.
Fig. 10. Transformation recsult of S2F41, S2F42, S5F1 and S5F2 messages
E. Transformation to OPC-UA information model
Each class in the E5 UML models is translated towards an OPC-UA data type structure as shown in the fig 11.
These data types will then be used as input and output parameters in host and equipment OPC UA methods.
Fig. 11. SEMI Datatype, the E5 OPC-UA information model
V. BUILDING GEM INFORMATION MODEL
A. Transformation to UML model
Once E5 information model is built, services related to GEM can be defined. Because services are hosted on
both the host side and equipment side, two classes are defined.
These ones are represented by EquipmentGEMServices and HostGEMServices including UML operations
related to the SEMI services.
UML operations are defined with the following rules:
the operation name is the name of the primary message
the operation has one input parameter of request class type
the operation has one output parameter of response class type
The figure 12 provides an example of a GEM interface composed by the methods SendCommand and
SendAlarmReport.
Fig. 12. Equipement and Host GEM interface
B. Transformation to OPC-UA information model
Fig. 13. GEM OPC-UA Adress Space
The transformation of the GEM UML model to OPC-UA Address Space is based on a simple mapping where:
The Host and Equipment Services are translated into object types
An UML operation is transformed into an OPC-UA method and the input and output arguments of the UML
operation into the input/output parameters of the OPC-UA method. The composition relation is
transformed into a HasComponentReference in OPC-UA.
VI. OPC-UA DEPLOYMENT
The deployment consists of the identification of the correct client/server network architecture, the deployment
of the E5 and the GEM information models on the client and servers.
A. OPC-UA Client/Server Architecture
Services are hosted on both the host and equipment side. Therefore, one server and one client must be
defined on both sides. The host consumes services from the equipment and that the equipment consumes
services from the host. The figure 14 shows the presence of a client and a server on both sides. On the
equipment, an EquipmentGEMServices is instantiated on the server. The host’s client will be able to consume
the EquipmentGEMServices services. On the host, a HostGEMServices is instantiated on the server. The
equipment’s client will be able to consume the HostGEMServices services.
Fig. 14. OPC-UA Host/Equipement interfaces
B. OPC-UA information Models deployement
E5 information model is deployed on every OPC-UA server and client. The figure 15 shows how the
deployment looks like in the Unified Automation UA Modeler.
Fig. 15. SEMI Datatype Address Space
GEM information model is deployed on every OPC-UA server and client. The figure 16 shows how the
deployment looks like in the Unified Automation UA Modeler.
Fig. 16. Browsing Host and Equipement methods
C. GEM information model in action
A typical example in the semi-conductor fab is a host that will execute a remote control on the equipment
controller and an equipment sending an alarm report to the Host. In the example provided in the figure 17, the
OPC-UA client of the Host will call the SendCommand service provided by the Equipment OPC-UA server to
ask the equipment to start the execution of the process. When the equipment finishes its task, it will send an
acknowledgement to the Host.
In parallel, the Equipment client will ask for the SendAlarmReport service provided by the host server and
inform the Host that an overheat alarm have occured.
Fig. 17. Browsing Host and Equipement methods
Once the different services deployed in both host and equipment sides, there is a need of an orchestration
level. Workflows and task schedulers will be responsible of the service invocation. In [16], the orchestration is
ensured by lua scripts, but we could think about a model of execution that will schedule the service’s execution.
VII. CONCLUSION
In this work, we assessed SECS/GEM standard against OPC-UA standard. We structured SECS/GEM
specification within four layers then we propose a mapping between SECS/GEM stacks and OPC-UA ones. In
our opinion OPC-UA and SECS/GEM standards are complementary and if OPC-UA has been adopted as the
main Industry 4.0 standard, its generic information model framework can easily handle SECS/GEM concepts
which provide improved semantics for the remote control and the equipment monitoring.
The architecture of the OPC UA information model allows vendors to develop plug-ins providing a
configuration editor that do not require programming skills and facilitate the configuration. The integration task
is then lightened.
Within this work, we focus on defining a method to build a SECS/GEM information model in OPC-UA and
we did not assess existing OPC-UA information model such as Data Access, Alarms and Conditions to fulfill
some GEM services. This could be part of a complimentary work In our approach we focused on the method call
service to handle GEM and upper layers of SECS/GEM standards. But this work may be considered as an early
stage one as we strongly think that it is necessary to set up a task force composed by the different actors of the
semiconductor domain in order to standardize the different layers of SECS/GEM standards in OPC-UA.
VIII. ACKNOWLEDGMENT
This work was carried out in Productive 4.0 project, a European co-funded innovation and lighthouse
program. Productive 4.0 involves more than 100 hundred partners that share the objective to achieve
improvement of digitalizing the European industry by electronics and ICT.
IX. REFERENCES
[1] M. Hankel B. Rexroth The reference architectural model Industrie 4.0 (rami 4.0)” ZVEI 2015.
[2] OPC Unified Architecture Specification available at https://opcfoundation.org/developer-
tools/specifications-unified-architecture
[3] Mahnke, W., Leitner, S.H., Damm, M.. OPC Unified Architecture. Springer Science & Business Media;
2009
[4] OPC Foundation : OPC-UA Sepcification : Part 5 Information Model. Version 1.04, 22-11-2017.
[5] http://www1.semi.org/eu/Standards
[6] OPC Foundation : OPC-UA Sepcification : Part 3 Address Space Model. Version 1.04, 22-11-2017.
[7] OPC Foundation : OPC-UA Sepcification : Part 4 Services. Version 1.04, 22-11-2017.
[8] Mariusz Postół, OPC-UA information model deployment, White Paper - 18 April 2016.
[9] https://www.unified-automation.com/
[10] Lee, D.K. Kim, H. Yang, S. Oh, “Model transformation between OPC-UA and UML”, Computer
Standards & Interfaces archive volume 50- February 2017. Pages 236-250 Elsevier Science Publishers B.
V. Amsterdam, The Netherlands, The Netherlands
[11] F. Pauker, T. Frühwirth, B. Kittl and W. Kastner, “A systematic approach to OPC UA information model
design”, Proc. CIRP 57, 321-326 (2016)
[12] F. Pauker, S. Wolny, S. Mansour Fallah and M. Wimmer, “UML2OPC-UA Transforming UML class
diagrams to OPC-UA information models” - Proc. 11th Conf. Intel. Comput. in Manufact. Engineer.
(ICME), 2017.
[13] S. Rohjans, K. Piech and S. Lehnhoff, “UML-based Modeling of OPC-UA Address Spaces for Power
systems”, in Proceedings - 2013 IEEE International Workshop on Intelligent Energy Systems, IWIES
2013, 2013, pp. 209-214.
[14] http://ams.semi.org/ebusiness/standards/SEMIStandardDetail.aspx?ProductID=211&DownloadID=3555
[15] E5 standard
[16] Julius Pfrommer, Miriam Schleipen, Selma Azaiez, Michael Boc, Loïc Cudennec, Selma Kchir, Thibaud
Tortech and Xenia Klinge “Deploying New Functionality to Manufacturing Resources Safely at Runtime”,
IEEE International Conference on Emerging Technology & Factory Automation (ETFA 2016), Berlin,
Germany, September 2016.
... Recent advances in the area of Industry 4.0 have contributed to the development of OPC UA as an architectural and communication framework for industrial automation. To promote interoperability between the equipment used in multiple domains, a semiconductor equipment manufacturer may look up to standards like OPC UA, which have a much wider adoption across multiple domains [2]. To establish OPC UA based communications, we came across two architectural choices i.e. either mapping OPC UA to the communication protocol level or to the generic application level constructs in SEMI standards ecosystem. ...
... This approach is fairly simple to implement, however it is a hybrid approach, where one tunnels the SECS-II messages over OPC UA. Implementation details of this mapping are presented in our previous work [2]. ...
... In our previous work, we devised a methodology to map UML models of SECS II to OPC UA information models [2,3]. In this current work, we further developed a mapping between GEM and OPC UA and compared the architectural choices between SECS II mappings and GEM mappings. ...
Conference Paper
Full-text available
As manufacturing, in general, is adopting Industry 4.0, OPC UA is gaining traction to become the de facto architecture for overcoming the issues of interoperability. Even though semiconductor equipment manufacturers need to comply with the existing and now mature SEMI standards (SECS/GEM), it is worthwhile to explore the possibilities of harmonizing them with other automation standards. With the same goal in mind, OPC Foundation has developed standardized companion specifications for different standards like ISA-95, PROFINET, IO-Link, etc. With no companion specification available for semiconductor industry yet, this work compares the architectural choices for the development of an information model for semiconductor industry. We share the lessons learned from our endeavors in implementing OPC UA information models for semiconductor domain.As
... Industry 4.0 aims to take the manufacturing industry to the next level of technological advancement for an interconnected manufacturing ecosystem where machines communicate through the network to exchange messages, instructions, and data. With sophisticated machinery and automation, more integrated machine-tomachine communication, real-time monitoring and data collection, machine learning, and enhanced inter-connectivity, Industry 4.0 is changing the existing manufacturing process for the better and improving overall production [1]. As machines are interconnected, they generate activity analysis, predictive diagnostic data, performance statistics, and other monitoring and control information. ...
... Since the last 16 bytes of the encrypted payload is the tag generated by AES GCM, 16 bytes are subtracted from the length of the remaining payload, and the data is read for that length. Equation (1) can be used to calculate the size of the ciphertext data within the payload: C len = P len -N len + T len (1) C len is the ciphertext length computed by calculating the difference between P len , the payload length, and the sum of N len and T len , where N len is the size of nonce and T len is the size of the tag. The nonce, ciphertext, and the pre-shared key are passed in as inputs to the decryption mechanism. ...
Article
Full-text available
The manufacturing industry has been revolutionized by Industry 4.0, vastly improving the manufacturing process, increasing production quality and capacity. Machine-to-Machine (M2M) communication protocols were developed to strengthen and bind this ecosystem by allowing machines to communicate with each other. The SECS/GEM protocol is at the heart of the manufacturing industry, thriving as a communication protocol and control system for years. It is a manufacturing equipment protocol used for equipment-host data communications. However, it is not without drawbacks, despite being a widely adopted communication protocol used by leading industries. SECS/GEM does not offer any type of security features as it was designed to work in a closed network. Such shortcomings in the protocol will allow attackers to steal secrets such as manufacturing processes by looking at recipes, perform reconnaissance prior to sabotage attempts, and can have severe implications on the entire industry. This paper proposes a mechanism to secure SECS/GEM data messages with AES-GCM encryption and evaluate the performance with the standard SECS/GEM protocol. The results from our evaluations showed that the proposed mechanism achieves data confidentiality and authenticity with a negligible overhead of 0.8 milliseconds and 0.37 milliseconds when sending and receiving a message, respectively, compared to the standard protocol.
... These standards are collectively known as SECS/GEM. The SECS/GEM protocol is an industry-standard that is widely in operation across many manufacturing industries worldwide [3] [32] [33]. It acts as a backbone of the semiconductor industry and is heavily used in the world's leading enterprises, including Intel, Samsung, TSMC, IBM, Qualcomm, Broadcom, UMC, SK Hynix, Micron, TXN, Toshiba, NXP, proving as a de facto communication protocol and control system since decades [3]. ...
Article
Full-text available
Industry 4.0 as a driving force is making huge strides, particularly in the manufacturing sector, where all integral components involved in the production processes are getting digitally interconnected. Fused with improved automation and robotics, machine learning, artificial intelligence, big data, cloud computing, and the Internet of Things (IoT), this open network interconnectivity makes industrial systems increasingly vulnerable to cyber-attacks. While the impacts and intentions of cyber-attacks vary, they always have a detrimental effect on manufacturers, including financial losses, supply chain disruption, loss of reputation and competitiveness, and theft of corporate secrets. Semiconductor Equipment Communication Standard/Generic Equipment Model (SECS/GEM) is a legacy Machine-to-Machine (M2M) communication protocol used profoundly in the semiconductor and other manufacturing industries. It is mainly designed to be utilized in a controlled and regulated factory environment separated from external networks. Industry 4.0 has revolutionized the manufacturing industry and has brought SECS/GEM back to the limelight as it lacks security safeguards to protect against cyber-attacks. This paper proposes a digital signature-based security mechanism that offers authentication, integrity, and protection against cyber-attacks. The proposed mechanism is compared with the industry-standard SECS/GEM implementation in terms of processing time, payload overhead, and resilience against cyber-attacks. The results indicate that SECS/GEMsec effectively prevented untrusted entities from establishing communication links with legit industrial equipment while maintaining message integrity by discarding forged messages. Additionally, it protected SECS/GEM communications against Denial-of-Service (DoS) attacks, Replay attacks, and False-Data-Injection-Attack (FDIA) attacks.
... The scope of this work remains very narrow to the production scheduling techniques and does not take into account the wider aspect of communication interfaces and interoperability. In our previous work, we devised a methodology to map UML models of SECS/GEM communication to OPC UA information models [9]. However, we suggested that a set-up of a task force composed by the different actors of the semiconductor domain is necessary to standardize all layers of SECS/GEM standards in OPC UA. ...
Conference Paper
Full-text available
Semiconductor industry has long been active in standardization of interfaces to deal with interoperability. Even though these standards allow interoperability between different hosts and equipment within the semiconductor industry, it remains hard to make these interfaces interoperable with other domains of manufacturing. One of the main pillars of Industry 4.0 is the interoperability of different equipment and devices across multiple domains and between the operational and information technologies. Though OPC UA is becoming the de facto architecture for Industry 4.0, semiconductor equipment manufacturers need to comply with the existing SEMI standards to ensure the sales of their equipment. In this context, the primary goal of this work is to develop a comprehensive metamodel of the SEMI communication interfaces. As a secondary goal, we want to use this model to carry out a preliminary experimentation on using OPC UA as a communication architecture in semiconductor industry, maintaining maximum compliance to the established SEMI standards.
Conference Paper
An overall information model of an industrial cyberphysical system consists of different sub information models. These sub information models contain attributes and methods that describe parts of the overall information model such as a machine or an order. Every entity within a company has varying requirements in terms of information it needs to represent, or read from the information model. In contrary, especially in environments with a large number of system entities, it is necessary to standardize the information models as much as possible to optimize economic and performance potentials. To address this challenge this paper presents an approach for information model management. This is done via the creation of rules for information modelling and the forming of an enterprise specific information model library.
Article
Zusammenfassung Fertigungssysteme unterliegen aufgrund von Änderungen an Produkt und Prozess einem ständigen Wandel. Besonders in älteren Systemen besteht deshalb zwischen den einzelnen Arbeitsschritten nur eine begrenzte Durchgängigkeit von Daten. Digitalisierung und Schaffung von Interoperabilität zwischen den einzelnen am Fertigungsprozess beteiligten Einheiten kann die Produktivität und Qualität des Produktionsprozesses steigern und somit seine Kosten verringern. Die Grundlage dazu ist ein einheitliches Informationsmodell. Im Folgenden wird ein methodisches Vorgehen zur Erstellung und Validierung von Informationsmodellen sowie ein Ansatz zum Management von Informationsmodellen vorgestellt. Das Vorgehen wird anhand eines durchgehenden Beispiels erläutert.
Technical Report
Full-text available
The industrial IT application domain is an integrated set of ICT systems. System integration means the necessity of the information exchange between them (the nodes of a common domain). The main challenge of deploying an industrial IT solution is that information is abstract, but unfortunately, machines cannot be used to process abstraction. It is also impossible to transfer abstraction from one place to another. The main aim of this paper is to present a new emerging engineering discipline as a synergy between systematic design methodology and available tools. Bothering about information processing is usually recognized as research and development activity. Engaging R&D activity to provide information processing centric solutions has many drawbacks. It requires distinct skills and, in consequence, solving a problem and deploying the solution must be carried out as two independent phases. It is not efficient and, therefore, very expensive and risky. The OPC Unified Architecture standard addresses this problem, namely, it proposes an architecture, services and information modeling consistent concepts with the goal to allow vendors to release out-of-the-box products ready to be used by engineers. The above-mentioned issues could be overcome by reusability and unification. The main challenge of adopting the OPC UA standard is to converge the methodology and tools development to eliminate research and programming needs. This whitepaper is dedicated to architects and software developers to help them deploy the real-time process state and behavior description as a ready to use solution in a real production environment and use this description to integrate the process as a consistent part of a selected Industrial IT application domain. The high-level general discussion refers to the Analyzer Device Integration (ADI) model and is illustrated using CAS Address Space Model Designer tool. It makes the paper a case study that should be useful also for the deployment of any OPC UA product.
Article
Full-text available
Current trends in manufacturing focus on the use of Information and Communication Technologies (ICT). The physical world and its virtual representation are increasingly converging, which leads to Cyber-Physical Production Systems (CPPS) in the manufacturing environment. CPPS synergize conventional production technology as well as ICT, allowing machines and products to exchange information, trigger actions and control other components autonomously. Therefore, seamless communication between physical objects of the shop floor and various computer systems is required. The Reference Architecture Model Industrie 4.0 (RAMI4.0) provided by the Plattform Industrie 4.0 specifies requirements for CPPS consisting of Industrie 4.0-components. In such systems, a major goal is to enable communication of I4.0 components among each other via industrial networks. For this purpose, RAMI4.0 suggests that each component has a virtual representation and uses Service-Oriented Architecture (SOA) based communication with I4.0-semantics. This paper describes a systematic approach to OPC Unified Architecture (OPC UA) information model for representing the static and dynamic behavior of manufacturing systems. Moreover, the approach is generic in the sense that it can be used to define information models for multiple target technologies, such as OPC UA, MTConnect and others. It even allows to reuse large parts of the generated models for similar manufacturing utilities and various target technologies. Therefore, we first present a concept for system analysis and design by using the Unified Modeling Language (UML), which is widely accepted for interdisciplinary work. The information gathered is then transformed to OPC UA information models which serves as target technology in this paper. The purpose of this approach is to simplify the process of defining virtual representations of manufacturing systems. Applying the presented concept allows transformation of classic manufacturing systems into CPPS with SOA-based communication and semantically rich virtual representations of individual components. It is therefore well suited to meet the requirements specified by RAMI4.0.
Article
Full-text available
OPC Unified Architecture (UA) is a platform-independent standard for message-based communication between clients and servers on various types of network to facilitate information exchange. OPC UA has been adopted in various domains such as power grids, building automation, and smart devices to support interoperability of involved systems. These domains also use Unified Modeling Language (UML) as the standard notation for data modeling or system modeling. Use of two different notations in the same domain causes compatibility issues. To address this, we present an approach for transforming OPC UA to UML to improve their compatibility and integration. In the approach, we rigorously analyze the semantics of OPC UA elements and establish a mapping between OPC UA elements and UML elements based on the analysis. Based on the mapping, we define transformation algorithms using Query/View/Transformation (QVT) which is a standard model transformation language by OMG. We demonstrate the approach using case examples in the power grid, building automation, and smart device domains.
Conference Paper
Full-text available
Current trends in manufacturing focus on the use of Information and Communication Technologies (ICT). The physical world and its virtual representation are increasingly converging, which leads to Cyber-Physical Production Systems (CPPS) in the manufacturing environment. CPPS synergize conventional production technology as well as ICT, allowing machines and products to exchange information, trigger actions and control other components autonomously. Therefore, seamless communication between physical objects of the shop floor and various computer systems is required. The Reference Architecture Model Industrie 4.0 (RAMI4.0) provided by the Plattform Industrie 4.0 specifies requirements for CPPS consisting of Industrie 4.0-components. In such systems, a major goal is to enable communication of I4.0 components among each other via industrial networks. For this purpose, RAMI4.0 suggests that each component has a virtual representation and uses Service-Oriented Architecture (SOA) based communication with I4.0-semantics. This paper describes a systematic approach to OPC Unified Architecture (OPC UA) information model for representing the static and dynamic behavior of manufacturing systems. Moreover, the approach is generic in the sense that it can be used to define information models for multiple target technologies, such as OPC UA, MTConnect and others. It even allows to reuse large parts of the generated models for similar manufacturing utilities and various target technologies. Therefore, we first present a concept for system analysis and design by using the Unified Modeling Language (UML), which is widely accepted for interdisciplinary work. The information gathered is then transformed to OPC UA information models which serves as target technology in this paper. The purpose of this approach is to simplify the process of defining virtual representations of manufacturing systems. Applying the presented concept allows transformation of classic manufacturing systems into CPPS with SOA-based communication and semantically rich virtual representations of individual components. It is therefore well suited to meet the requirements specified by RAMI4.0.
Conference Paper
The emergence of cyber physical systems in the manufacturing domain creates new requirements for shop floor devices. Due to their diverse structure, buildup a seamless communication is one major challenge. In recent years, several communication standards, e.g., OPC-UA, tried to tackle this issue. Until now, they have not fully developed their potential, because of inherent implementation complexity and specific formats, although well-known modeling standards such as UML exist. The presented approach aims to overcome this complexity by enabling an automatic transformation from UML class diagrams to OPC-UA information models using ATL and by extending UML to guarantee information preserving transformations.
Conference Paper
Automated manufacturing systems are becoming increasingly flexible in order to support a growing number of different products and product variations, as well as shortening lot sizes and product life cycles. Many manufacturing resource are already multi-purpose. But they are integrated in an automation infrastructure that may require significant effort to adapt. In this contribution, we present a system architecture for the deployment of software functionality to manufacturing resources safely at runtime. The architecture integrates software model verification to ensure the integrity of new functionality, software-defined networking (SDN) to establish new communication pathways for collaboration, and the close interaction between a flexible runtime execution environment and its safety-critical counterpart.
Conference Paper
Automation technologies are a key enabler to realize the vision of so called Smart Grids. They realize the interface between the power system infrastructure that is used to reliably deliver electric power and the information- and communication infrastructure that is utilized to exchange digital information. Thus, analyzing if and how existing automation technologies can be adopted for the energy domain is of key importance. Furthermore, Smart Grids will be highly heterogeneous systems having to address various interoperability issues and thus have to deal with standardization. Therefore, this paper proposes the integration of the established IT-modeling language UML with the OPC Unified Architecture, which is a future-oriented automation standard (and already established in industry automation). It will be explained how UML-models can be used to generate Address Spaces in general and examples will be given introducing the generation of Address Spaces based on Smart Grid semantics in particular.
Chapter
The OPC Foundation defines standards for online data exchange between automation systems. They address access to current data (OPC DA), alarms and events (OPC A&E) and historical data (OPC HDA). Those standards are successfully applied in industrial automation. The new OPC Unified Architecture (OPC UA) unifies the existing standards and brings them to state-of-the-art technology using service-oriented architecture (SOA). Main advantages of the new standard are: •Platform-independent technology allows the deployment of OPC UA beyond current OPC applications only running on Windows-based PC systems. OPC UA can also run on embedded systems as well as Linux / UNIX based enterprise systems. •The provided information can be generically modeled and therefore arbitrary information models can be provided using OPC UA. This book gives an easy to understand introduction into OPC UA and explains the concepts of the standard and other relevant topics that are not directly addressed by the standard. © 2009 Springer-Verlag Berlin Heidelberg. All rights are reserved.
The reference architectural model
  • M Hankel
  • B Rexroth
M. Hankel B. Rexroth "The reference architectural model Industrie 4.0 (rami 4.0)" ZVEI 2015.
Model transformation between OPC-UA and UML
  • D K Lee
  • H Kim
  • S Yang
  • Oh
Lee, D.K. Kim, H. Yang, S. Oh, "Model transformation between OPC-UA and UML", Computer Standards & Interfaces archive volume 50-February 2017. Pages 236-250 Elsevier Science Publishers B. V. Amsterdam, The Netherlands, The Netherlands