Towards building OPC-UA companions for semi-conductor domain

Abstract

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

Full text

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
Abstract— 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
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.