Conference PaperPDF Available

Multi-level modeling to OPC UA for migrating to Industry 4.0 in semiconductor manufacturing

Authors:

Abstract and Figures

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.
Content may be subject to copyright.
Multi-level modeling to OPC UA for migrating to Industry 4.0 in
semiconductor manufacturing
Fahad R. Golra, Selma Azaiez, Marc Engel
This is an author manuscript of the article published as:
F. R. Golra, S. Azaiez and M. Engel, ”Multi-level modeling to OPC UA for migrating to Industry 4.0 in semicon-
ductor manufacturing,” 2020 IEEE Conference on Industrial Cyberphysical Systems (ICPS), Tampere, 2020, pp.
589-595, doi: 10.1109/ICPS48405.2020.9274791.
Abstract
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 semicon-
ductor 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 multi-
ple 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.
1 Introduction
The Reference Architecture Model for Industry 4.0 (RAMI 4.0) [1] is the most common reference that describes
the compliant production architecture of Industry 4.0. It explicitly recommends OPC Unified Architecture (OPC
UA) for implementing the communication layer. Pethig et al. define a process, with three migration steps, for the
implementation of Industry 4.0 communication, based on OPC UA [2]. The first step of this process is to use OPC
UA as a uniform interface to access information; the second step is to use standardized information models (also
called companion specifications) and the third step is to extend the information model with non-standardizable
functionality. Till date, no companion specification has been prepared for the semi-conductor industry and there
is no active working group for its development. With the lack of companion specifications, the stakeholders of
semiconductor industry are hesitant to adopt OPC UA. In this context, there is a need to test the feasibility
of OPC UA for its adoption in semiconductor industry. This work goes in the direction of the first step of the
migration process towards Industry 4.0 specified by Pethig et al. [2], for the semiconductor manufacturing industry.
Established for decades, SEMI1standards are mature and widely adopted in semiconductor industry. The initial
experimentation in this work takes into consideration the real-life constraint of equipment manufacturers that one
can not sell the equipment unless it complies with the SEMI standards.
SEMI standards are mainly related to remotely controlling and monitoring the equipment and devices at the shop
floor by the Manufacturing Execution System (MES), also called a host. This way, the semiconductor fabrication
plants can maintain a flexible production process where a single piece of equipment can perform different processes
on individual batches in production. In this context, SEMI standards provide the specifications for the equipment
and host interfaces. However, like many other standards, these specifications are textual and (meta)models of
the domain for adopting Model Driven Engineering (MDE) solutions are missing. The generation of OPC UA
Agileo Automation, Poitiers, France. fahad.golra@agileo-automation.com
CEA, LIST, Gif-Sur-Yvette, France. selma.azaiez@cea.fr
Agileo Automation, Poitiers, France marc.engel@agileo-automation.com
1Semiconductor Equipment and Materials International (SEMI) is an industrial association that maintains the standards for semi-
conductor production.
1
E5 SECS-II
E37 HSMS-SS
TCP/IP
E4 SECS-I
RS232 Ethernet
GEM300
GEME87E90
SEM
E82E88
Application
model
Message
Definition
Logical
Protocol
Physical
Protocol
E91
Vendor specific model
Figure 1: Model of the SEMI standards stack
specification models from existing domain concepts requires a modeling effort of the domain as a first step. Based on
these models, one can proceed towards solutions like model transformations, model weaving or model federations [3].
In this work, we have contributed to the modeling of semi-conductor communication interfaces and then we have
mapped this model to OPC UA information models. The novelty of our approach is two fold: 1) a first attempt to
modeling semiconductor standards in a multi-level modeling methodology and 2) to test the preliminary feasibility
of the adoption of OPC UA architecture for semiconductor industry, while ensuring maximum compliance to the
existing SEMI standards.
The rest of the paper is organized as follows. We first describe the existing SEMI standards stack in Section 2.
Then, in Section 3, our approach of modeling the communication standards in semiconductor industry is presented.
In Section 4, we describe the architecture of the proposed framework and the mapping between the modeled SEMI
standards and OPC UA. Finally, before the conclusion, the related works are discussed in Section 5.
2 The semi standards
In this section, we first give a background on semiconductor manufacturing standards and then describe a running
example that we use to explain the rest of the section.
2.1 Semiconductor manufacturing
SEMI defines a stack of standards that apply to different aspects of semiconductor manufacturing industry. These
standards can be categorized using four different layers of architecture: physical protocol level, logical protocol
level, message definition level and the application model level, as modeled in Figure 1. The Physical protocol is
the same as other enterprise and factory networks using RS232 and Ethernet, and provides the basis for the logical
communications. The SEMI standards (shaded rounded boxes in the Figure 1) are defined on top of the physical
protocol level, to standardize the logical interfaces.
The logical protocol level in SEMI standards is defined by two standards. E4, also known as the SECS-I, defines
the communication protocol associated to RS232 channel. For the Ethernet channel, by basing itself on the TCP/IP
connection, the E37 standard defines the High-speed SECS Message Services (HSMS). At the message definition
level, the E5 standard, also known as SECS-II, defines the structure of messages. The messages are categorized
in different groups of activities through streams, where each group is a collection of certain related functions. An
individual message can be used for the transfer of a simple data element to a complex hierarchy of variable sized
lists.
At the application model level, GEM 300 (General Equipment Model for 300mm wafer industry) defines a set
of standards that collectively describe the behavior and communication capabilities for the automation support
of semiconductor manufacturing equipment. This behavior and capabilities are defined using scenarios involving
SECS-II messages. On top of the standards for general equipment, SEMI defines the SEM (Specific Equipment
Model) standards for individual class of equipment, for example probers, handlers, etc. Individual vendors can
2
<SECSMessage s="2" f="41" name="Host Command Send"
mnenomic="HCS" blocking="S" direction="H to E"
replyOption="required">
<Description >
The Host requests the Equipment to ...
</Description>
<SECSData>
<LST length="2">
<ASC dataItemName="RCMD"/>
<LST length="n">
<LST length ="2">
<ASC dataItemName="CPNAME"/>
<ASC dataItemName="CPVAL"/>
</LST>
</LST>
</LST>
</SECSData>
</SECSMessage>
Listing 1: Remote command request message
<SECSMessage s="2" f="42" name="Host Command
Acknowledge" mnenomic="HCA" blocking="S"
direction="E to H" replyOption="never">
<Description>
Acknowledge Host command or error. If ...
</Description>
<SECSData>
<LST length="2">
<ASC dataItemName="HCACK"/>
<LST length="n">
<LST length ="2">
<ASC dataItemName="CPNAME"/>
<BIN dataItemName="CPACK"/>
</LST>
</LST>
</LST>
</SECSData>
<Exception>
If there are no invalid parameters, then a list
of zero length will be sent for item 2.
</Exception>
Listing 2: Remote command response message
develop their own standards based on the E5 standard, GEM300 standards or SEM standards. Different levels of
compliance is ensured through the adoption of individual standards or set of standards like GEM300.
2.2 Running example
Semi standards stack (also called SECS/GEM stack) manages the communication between a host and equipment.
This communication is carried out by a sequence of messages that are exchanged between the both. The GEM
standard presents a state transition model to describe the behavior of the equipment. A host can use messages
to send commands for controlling the behavior of the equipment, known as a remote command. We will use a
sequence of request and response messages i.e. a remote command request message (Listing 1) and the remote
command response message (Listing 2), as an example, to demonstrate the proposed methodology in the rest of
the paper.
3 Modeling the semi standards standards
In this section, we present a multilevel model that we have developed to capture the underlying concepts of
communication and control standards, used in the domain of semiconductor fabrication.
3
Metamodel
Project
s2f41K:SECSMessageKind
stream = 2
function = 41
name = HostCommandSend
description = "The Host ..."
blocking = SingleBlock
direction = HtoE
replyOption = required
exception = "None"
itemStructure = {rcmdK, list1K}
<<partitionedType>>
SECSMessage
+ txid: UInt64
+ sECSData: DataItem[]
SECSMessageKind
<<powerType>>
+ stream: String
+ function: String
+ name: String
+ description: String
+ blocking: SECSBlocking
+ direction: SECSDirection
+ replyOption: SECSReplyOption
+ exception: String
+ itemStructure: DataitemKind[]
SECSMessageAlias
SECSMessageAlias
s2f42K:SECSMessageKind
stream = 2
function = 42
name = HostCommandAcknowledge
description = "Acknowledge Host ..."
blocking = SingleBlock
direction = EtoH
replyOption = never
exception = "If there are ..."
itemStructure = {hcackK, listK}
s2f42P:SECSMessage
txid = 1001
sECSData = {hcack, list}
#HostCommandSend #HostCommandAcknowledge
<<enumeration>>
SECSDirection
HtoE
EtoH
Both
<<enumeration>>
SECSBlocking
Single
Multi
<<enumeration>>
SECSReplyOption
required
optional
never
Method
(Standard &
Frameworks)
DataItemKind
<<powerType>>
+ dataItemName: String
+ description: String [0..1]
+ maxLength: String [0..1]
+ minLength: String [0..1]
+ composition: DataItemKind[]
+ length: int [0..1]
<<partitionedType>>
DataItem
+ format:FormatType
FormatType
+ formatCode: Int
+ dataFormat:DataFormatType
self.item.type = self.format.dataFormat
allowedFormats 1..*
BaseDataItem
+ name: String
+ id: Uint64
+ item: Object
CompositeDataItem
+ item: DataItem[]
<<enumeration>>
DataFormatType
LST
BIN
ASC
..
rcmdK:DataItemKind
dataItemName = RCMD
description = "Remote ..."
maxLength = 20
allowedFormats = {20,31,51}
DataItemAlias
list1K:DataItemKind
dataItemName = LIST
allowedFormats = {00}
composition = {list2}
length = -1
DataItemAlias
#RMCD
#LIST
rcmdP:BaseDataItem
name = "HostCommand"
id = 1801
format = ASC
:ASC
value = "PP-SELECT"
:CompositeDataItem
format = LST
:CompositeDataItem
format = LST
sECSData[0]
sECSData[1]
item
item
Transaction
11
request response
self.request.txid = self.response.txid
list2K:DataItemKind
dataItemName = LIST
allowedFormats = {00}
composition = {cpname,
cpval}
length = 2
cpnameK:DataItemKind
dataItemName = CPNAME
description = "Command .."
allowedFormats = {20,30, ..}
cpvalueK:DataItemKind
dataItemName = CPVAL
description = "Command .."
allowedFormats = {10, 11, ..}
cpnameP:BaseDataItem
name = "CmdParameterName"
id = 1802
format = ASC
cpvalueP:BaseDataItem
name = "CmdParameterValue"
id = 1803
format = ASC
:ASC
value = "ppexecname"
:ASC
value = "Recipe101"
item
item[1]item[0]
item
Legend: instanceOf extends powertype clabject Modeling levelcontstraint
Figure 2: Multilevel modeling for SECS/GEM communication
Like many other domains, the standards used in semiconductor manufacturing industry are textual with little
to no formal model specification. In such a scenario, it becomes hard to implement any automated mechanism
to assure compliance to standards. One approach is to develop a metamodel based on these standards and then
conform to that metamodel for the tool implementation. Such metamodels are rarely shared, as most of them are
directly developed in programming languages and end up at the core of the implementation tools of the solution
providers.
For modeling the proposed communication mechanism by SEMI standards, one needs to consider the SECS-II
message structure defined in E5 and the notion of communication scenario from E30. E173 presents an XML based
syntax of SECS-II Message notation for logging purposes. A closer look at the SECS/GEM standards reveals the
classic multi-level modeling problem, where part of the standard presents the instances of the concepts and other
part presents the types. UML as a language follows a strict modeling structure where a model can reside at one
of the four predefined abstraction levels [4]. In this scenario, multilevel modeling approaches such as powertype
modeling [5] and deep instantiation [6] offer the flexibility to develop a model that traverses multiple abstraction
levels. The notion of clabjects in powertype modeling attempts to model a concept that simultaneously has a class
facet and an object facet. We use this notion to model the partially instantiated concepts in SECS/GEM standards.
Using the notion of powertypes, we modeled SECS/GEM at three different levels of abstraction i.e. metamodel,
method and project, as shown in Figure 2.
The metamodel level presents the language for defining communication scenarios using SECS-II messages.
The method level standardizes the use of this language by instantiating and constraining some parts of the
metamodel and assigning it to specific categories of messages.
The project level describes the message instances that conform to the metamodel and comply with the defined
standards.
4
The metamodel level presents the three core concepts to define a language for communication and control in the
semiconductor industry i.e. transaction, message and data item. A transaction is a two-way communication between
hosts and equipment involving a request message and a response message. The request and response messages of
a transaction share the same txid (transaction ID). The concept of message in the metamodel is defined by two
classes where SECSMessage is a powertype of the SECSMessageKind. This means that in the lower abstraction
level, an instance of SECSMessageKind would act as the object facet and SECSMessage would act as the class
facet to form a clabject that can model a specific partially instantiated message of E5 standard.
The properties of SECSMessageKind and SECSMessage classes need to be viewed together to get a complete
picture of a message. Each message is identified by its stream and function. A stream categorizes the messages
that support some related activities. For example, the remote command message from our running example is part
of stream 2, which groups the messages that pertain to equipment control and diagnostics. Similarly, the alarm
reporting message is part of stream 5, which groups the messages that deal with exception handling. Within a
particular stream, each function refers to a specific message to carry out a specific activity. For example, the message
for sending the remote command has a function value 41 and the message for receiving the acknowledgement of
command reception has a function value of 42. Just like this example, the odd values of function are reserved for
request messages and the even values are used for the response messages. One can see the s2f41 and the s2f42
instances of SECSMessageKind at the method level of Figure 2. Stream and function values are used together for
identifying a message type of a specific category. It is important to note that a message identified by stream and
function values at this level is not a message instance i.e. it does not contain the message content (data items) yet.
The blocking property defines whether the message can be sent as a single block or as multiple blocks. The
direction property describes if the message can be sent from equipment to host, host to equipment or in both
directions. The replyOption property defines whether the response for a current message is obligatory, optional or
prohibited. An exception property describes the return values in case of an error. An itemStructure list specifies
the description of data items that can be contained by the message instance. SECSMessageKind defines the object
facet of the message clabject by specifying the properties that can be instantiated at the method level i.e. the
values of these properties are already specified by the SEMI standards. SECSMessage defines the class facet of the
message clabject by specifying the properties that can be instantiated at the project level. Finally, the instances
of SECSMessage and SECSMessageKind together form a complete message instance.
The txid property of the SECSMessage class is used to specify the transaction ID of a message. This class also
specifies the sECSData list associating to DataItem. The actual data item instance is composed by the message,
when it is instantiated at the project level. It should be noted that the “sECSData: DataItem” instantiated at the
project level has access to the already instantiated “itemStructure: DataItemKind” at the method level. Thus, the
sECSData forming the body of a message instance needs to comply with the defined itemStructure. If we observe
the Listing 1 of our example from Section 2.2 presenting the s2f41 request message, we can see that the attributes
are instantiated at the standard level, however the data items shall be instantiated at the project level, once the
message is in use.
Like the concept of message, the concept of data item is also modeled using a clabject, where DataItem is
the powertype of DataItemKind.DataItemKind gets instantiated at the method level, because it is used by the
SECSMessageKind in that level to specify the format for the content of a message body. The E5 standard specifies
a list of predefined data items; all having a name, hence the property dataItemName. This standard also defines
description, maximum length and minimum length of some data items, which is reflected in the DataItemKind class.
Furthermore, this standard specifies the allowed formats (datatypes) that can be used for each data item. Each
format has an associated code e.g. ASCII strings (ASC) have a format code 20. The DataFormatType enumerates
all the formats specified by the SECS/GEM stack. Once instantiated, the allowedFormats list associates a data
item to all the formats it is permitted to have. The S2F41 message of our running example uses a remote command
(RCMD) and a list of parameter names and values as data items in its message body. rcmdK, as the object facet
of this clabjet, specifies that the messages of this category can use either one of the formats pointed by the format
codes 20, 31 or 51. As an optional property, the length of a data item is only important, when it is of list (LST)
type. In this case, a -1 value represents a list of nitems. A data item in a SECS-II message can have a tree
like structure. Using its composition property, DataItemKind specifies the format of the complete hierarchical
structure.
DataItem class, being a powertype, is instantiated at the project level. To support hierarchy of data items,
the item property of a CompositeDataItem follows a composite design pattern. In case of a BaseDataItem, the
item is of the type specified by the format property. A data item instance can have any format permitted by the
allowedFormats list of DataItemKind. The rmcd data item at the project level of our running example is an ASC
(20) i.e. one of the allowed formats at the method level.
5
Figure 3: OPC UA wrapping architecture
With this multilevel modeling for SECS/GEM standards, we can see that the clabjects at the method level
define the message types through partially instantiated concepts. The object facet of a message clabject at this level
is an instantiation of SECSMessageKind, where as the class facet is SECSMessage (the SECSMessageAlias shown
in the Figure 2 is a syntactic sugar for the representation of the clabject). At the project level, these clabjects
are used for the development of message instances that are exchanged between hosts and equipment. A complete
message instance would regroup the instance of SECSMessageKind and SECSMessage . For example, the s2f41
instance message has access to all the properties of s2f41K and s2f41P instances. At the project level of Figure 2,
we see that this message instance sends the remote command “PP-SELECT” to the equipment with the parameter
name “ppexecname” and parameter value “Recipe”, in a tree-like format as described by the E5 standard.
4 Migration framework
In this section, we explain the proposed architecture for integrating legacy systems within an Industry 4.0 compliant
system and describe the mapping between the multilevel model of semi communications and the OPC specifications2
to generate the corresponding address space.
4.1 Framework architecture
As stated earlier, an OPC UA capable equipment can be integrated either via a native OPC UA interface or by using
an OPC UA gateway. No OPC UA companion information model for the semiconductor domain exists till date
and in this case, it is costly and risky for an equipment manufacturer to integrate a native OPC UA interface. For
an initial evaluation, we believe that the second alternative of connecting a semi-conductor equipment to Industry
4.0 through a SEMI/OPC UA gateway, acting as a wrapper around the SEMI native interface, is a better option.
In this architecture, both legacy systems (host and equipment) can communicate to each other using OPC UA. It
also allows both these legacy systems to communicate with other OPC UA compliant systems.
A typical architecture in the semi-conductor industry has a host that remotely controls the equipment via the
SEMI interface. The communication between them is bi-directional and can be initiated either by the host or
by the equipment. A communication is a transaction of a request message followed by a response message. For
instance, the host can send a command to the equipment. At the end of the execution, the equipment will send an
acknowledgement to the host. In the same way, the equipment can initiate the communication by raising an alarm
or by sending a report or an event notification.
In our proposed architecture, as shown in Figure 3, the OPC UA wrapper components are used to wrap the
SEMI interface both on the client and the server sides. The wrapper is used to translate the SEMI messages. For
the communication to take place, the server needs to expose the services that can be accessed by the client. All
the services exposed by the equipment are translated to the Equipment Server wrapper and loaded in its address
space, hence making it possible for the host to access them through the Host Client wrapper. All the services
exposed by the host are translated to the Host Server wrapper and loaded in its address space, hence making it
possible for the equipment to access them through the Equipment Client wrapper. Once the services are exposed
in the respective address spaces, the client wrappers can translate the request messages of the SEMI interface and
2OPC UA specifications are accessible, as multi-part document, at https://opcfoundation.org/developer-tools/
specifications-unified- architecture
6
Obje ctType
VariableType
Method
Variable
Objec t
OPC UA information modeling syntax:
HasComponent
HasProperty
HasTypeDefinition
HasSubtype
HostServiceType
EquipmentServiceType
Semi ServiceT ype
SemiT ransa ction
InputArgumentItems
OutputAr gum entIte ms
Semi Argument
HostService
EquipmentService
SemiM essag eMeta data
SemiI temVa lue
SemiI temKind
Figure 4: SEMI message transactions information model
call the corresponding service from the OPC UA server. The request (plain line arrow) and response (dotted line
arrow) messages together constitute a transaction.
4.2 Model mappings
For the development of the wrapper components around the semi interface, the goal is to be able to transform the
messages in OPC UA address space. Using model driven engineering techniques, these wrapper components can
execute the transformations to partially generate the OPC UA address spaces.
An OPC UA client and server, as wrapping components around the SEMI interface, exist at each end in the
architecture presented in Figure 3 because OPC UA does not allow a server to initiate an interaction with the client.
The server maintains its address space and responds to the requests sent by the client. In case a client is subscribed
to an event or is monitoring a variable, the server can notify it. On the other hand, in semiconductor communication
model, a message can be initiated from either the host end or the equipment end. For the implementation of server
and client components at each end, the clients were embedded in the server implementation. Using this approach,
the servers remain discoverable in the network, and they can, in turn, initiate interactions with other nodes of the
network through the embedded client. The client embedded in the server can directly access the address space of
the server, as both are implemented as a single application.
The metamodel of the OPC UA information models, developed in UML, is defined as Annex B in the part 3 of
OPC UA specification. The OPC Foundation also offers an open source model compiler for the generation of C#
code from a model, serialized as an XML file, that conforms to the schema defined in UA Model Design.xsd3. In
order to facilitate the model transformations, we have developed an OPC UA information model for communications
based on semiconductor standards in a way that can be serialized into an XML file conforming to this official schema.
The graphical view of this information model is depicted in Figure 4, where the legend shows the meta-concepts of
OPC UA metamodel used in this model.
For the partial generation of the OPC UA address space from the messages conforming to the multi-level model
described in the previous section, we have developed a mapping between the corresponding concepts. A pair of
request and response messages, forming a transaction, is transformed as a service provided by the server that can
be accessed by the client. This concept is depicted in Figure 4 as SemiServiceType. It is important to note that
their are two address spaces, one the at the equipment end and one at the host end. SECSMessageKind.direction
property in the multi-level model describes whether this type of message can be sent from the host to equipment
(HtoE), from equipment to host (EtoH), or in both directions. The transactions, where the direction of the request
message is EtoH, are transformed to a host service, whereas for HtoE request messages, the transactions are
transformed to an equipment service. When a request message can be sent in both directions, the transaction is
defined in both the address spaces. The root component of an address space is an object node that contains all
other nodes. The HostService object node contains all the nodes related to SEMI communication standards and
3https://github.com/OPCFoundation/UA-ModelCompiler
7
Table 1: SEMI standards and OPC UA mapping
SECS GEM multi-level model OPC UA information model
Transaction SemiTransaction
DataFormatType UAEnumeration
DataItem SemiItemValue
DataItemKind SemiItemKind
SECSMessageKind SemiMessageMetadata
it resides under the root node of the Host address space. The EquipmentService is the object node containing all
other nodes for SEMI communication that reside in the Equipment address space.
The mapping of the individual meta-concepts from the multi-level model to the nodes of OPC UA information
model are shown in Table 1. Each transaction, as a pair of request and response message, is mapped to the
SemiTransaction method of the information model. Each method node in OPC UA defines two properties i.e. the
inputArguments and the outputArguments. These properties are used to give parameters to the methods and to
define the return types. In our implementation, we map the parameters of the request message to define a type
that can be used as inputArgument of SemiTransaction method. Similarly, we map the parameters of the response
message to define a type that can be used as outArgument of SemiTransaction method.
The DataFormatType of the multilevel model defines all the datatypes used in SEMI standards. This concept is
mapped to a UAEnumeration, which can be used to list all the equivalent datatypes in OPC UA. Each DataItem that
is communicated through a SEMI request message becomes part of the SemiArgument in the form of SemiItemValue.
The DataItemKind meta-concept of the multilevel model is mapped to SemiItemKind and the SecsMessageKind
meta-concept to the SemiMessageMetadata. This way, both the inputArguments and the outputArguments of a
SemiTransaction are formed as a complex structure that contains the information pertinent to the message. Both
these arguments serve for the exchange of data items between the equipment and the host.
This mapping between the multi-level model of SEMI communication architecture and the corresponding OPC
UA information model allows bi-directional model transformations between the two models. The mappings are
implemented in a way that no information remains ”untransformed”. This ensures that the same model can be
regenerated from a reverse transformation. This bi-directional mapping allows developing the architecture in a way
that the SEMI messages can be transformed to enrich the OPC UA address space and the OPC UA address space
can be used generate SEMI messages.
5 Related work
The OPC UA adoption in the manufacturing domain is still at its initial stages. These last years, different
companion information models were developed and they are now available in OPC Foundation site. Most of them
were specified by working groups composed of the main enterprises and organizations acting in that specific domain
e.g. OPC UA for robotics [7] was an initiative of VDMA Robotics.
Not much work has been done for the adoption of Industry 4.0 in semiconductor industry. In an assessment,
Waschneck et al. describe the challenges in the semiconductor industry for production scheduling using the Industry
4.0 perspective [8]. 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.
In the absence of this task force, to implement a OPC UA compliant system related to the semi-conductor
domain, one needs to devise an ad hoc methodology. As OPC UA metamodel is based on object oriented ap-
proach so several works propose to adopt a model-based approach by automating the translation between UML
models capturing domains concepts towards OPC UA Address Space model. In [10], authors proposed to handle
interoperability problem in manufacturing domain by using a systematic methodology of translating UML models
towards OPC UA information model. They also suggest the transformation of other communication and modeling
8
languages available in the manufacturing domain (e.g. MTConnect) in a similar way. In another publication, the
same group proposes an automatic transformation from UML class diagrams to OPC UA information models using
ATL [11]. Lee et al. analyze the semantics of OPC UA elements and provide transformation algorithms using
Query/View/Transformation (QVT) [12]. Our work is complementary to these works, as we developed the commu-
nication models of the semiconductor manufacturing industry that are compliant with the established standards.
Any of these techniques can be used, alongside our models, for the development of OPC UA information models.
In another such work, Rohjans et al. explain how UML models can be used to generate OPC UA Address Spaces
and they apply their technique on Smart Grid semantics [13]. Using UML to capture domain semantics is a natural
method to follow. However, UML is based on two-level type/instance dichotomy, which imposes modeling rigidity.
Indeed, as shown in section 3, such dichotomy makes the modeling of SECS/ GEM messages quite difficult. So
instead of using UML, we use a multi-leveled modeling approach [5] that can handle partially instantiated models
at the standard level. With this multi-level modeling approach we modeled both the instance facet and the class
facet of the concepts. Using this modeling technique, we describe a model mapping to OPC UA that takes into
account this partial initialization.
6 Conclusion
In this work, we modeled the semiconductor manufacturing communication interfaces and carried out an initial
experimentation to use OPC UA standards for communication in semiconductor industry, maximizing the compli-
ance to existing SEMI standards. In order to stay compliant with the SEMI standards, instead of developing an
information model from scratch, we chose to transform the SEMI standards. In our evaluation, we came across two
possible architectural choices i.e. to generate an OPC UA interface, or to wrap the SEMI interface with OPC UA
interfaces. We chose the wrapping option, as it was suitable for a preliminary experimentation.
In future, we would like to implement both the architectures and share a comparative assessment of both these
architectural choices. We also plan to compare OPC UA architecture with SEMI standards based architecture
based on functional and non-functional attributes. Using our implementation strategy, we were able to implement
a communication channel between the equipment and the host. However, our chosen method might not be suitable
for all situations, specifically for the reasons of scalability. We think it is still early for equipment manufacturers to
provide an OPC UA interface for their equipment in semiconductor industry. It is better to wait for the formation
of a working group that standardizes a OPC UA companion specification model for the domain. Compliance to such
an companion specifications would ensure interoperability for the equipment manufacturers and standardization
across the semiconductor domain.
References
[1] D. Spec, “91345: Reference Architecture Model Industrie 4.0 (RAMI4. 0),” DIN Std. DIN SPEC, vol. 91, no.
345, p. 04, 2016.
[2] F. Pethig, S. Schriegel, A. Maier, J. Otto, S. Windmann, B. B¨ottcher, O. Niggemann, and J. Jasperneite,
“Industrie 4.0 Communication Guideline Based on OPC UA,” VDMA, Tech. Rep., 2017.
[3] F. R. Golra, A. Beugnard, F. Dagnat, S. Guerin, and C. Guychard, “Addressing modularity for heterogeneous
multi-model systems using model federation,” in Companion Proceedings of the 15th International Conference
on Modularity, 2016, pp. 206–211.
[4] F. R. Golra and F. Dagnat, “The lazy initialization multilayered modeling framework (NIER track),” in
Proceedings of the 33rd International Conference on Software Engineering. ACM, 2011, pp. 924–927.
[5] B. Henderson-Sellers and C. Gonzalez-Perez, “The rationale of powertype-based metamodelling to under-
pin software development methodologies,” in Proceedings of the 2nd Asia-Pacific conference on Conceptual
modelling-Volume 43. Australian Computer Society, Inc., 2005, pp. 7–16.
[6] C. Atkinson and T. K¨uhne, “The essence of multilevel metamodeling,” in International Conference on the
Unified Modeling Language. Springer, 2001, pp. 19–33.
[7] VDMA-OPC, “OPC UA for Robotics, Part 1: Vertical Integration, OPC 40010-1,” Jul 2019, Release 1.00.
[Online]. Available: https://opcfoundation.org/developer-tools/specifications-opc-ua-information-models
9
[8] B. Waschneck, T. Altenm¨uller, T. Bauernhansl, and A. Kyek, “Production Scheduling in Complex Job Shops
from an Industry 4.0 Perspective: A Review and Challenges in the Semiconductor Industry.” in SAMI@
iKNOW, 2016, pp. 1–12.
[9] S. Azaiez, F. Tanguy, and M. Engel, “Towards building OPC-UA companions for semi-conductor domain,” in
IEEE International Conference on Emerging Technologies and Factory Automation, ETFA, 2019, pp. 142–149.
[10] F. Pauker, T. Fuhwirth, B. Kittl, and W. Kastner, “A systematic approach to OPC UA information model
design,” Procedia CIRP, vol. 57, pp. 321–326, 2016.
[11] F. Pauker, S. Wolny, S. M. Fallah, and M. Wimmer, “UML2OPC-UATransforming UML Class Diagrams to
OPC UA Information Models,” Procedia CIRP, vol. 67, pp. 128–133, 2018.
[12] B. Lee, D.-K. Kim, H. Yang, and S. Oh, “Model transformation between OPC UA and UML,” Computer
Standards & Interfaces, vol. 50, pp. 236–250, 2017.
[13] S. Rohjans, K. Piech, and S. Lehnhoff, “UML-based modeling of OPC UA address spaces for power systems,”
in 2013 IEEE International Workshop on Inteligent Energy Systems (IWIES). IEEE, 2013, pp. 209–214.
10
... An individual message can transfer a simple data element to a complex hierarchy of variable-sized collections. A meta-model of the SECS II communication architecture is presented in our previous work [3]. ...
... For the second variation, we established a complete communication architecture between the equipment and the MES for establishing communications, remote commands, defining and linking reports, data collection of traces, events, etc. 3 ...
... 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
Conference Paper
Full-text available
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
Book
Full-text available
An important basis and the central challenge for the successful implementation of Industrie 4.0 is the manufacturer-independent exchange of data by establishing uniform interfaces in production. The standard “Open Platform Communications Unified Architecture” (OPC UA) is increasingly establishing itself in the field of machine and plant engineering. The VDMA prioritizes its activities on the interface standard OPC UA and gives an important orientation to machine and plant engineering sector. The VDMA guideline “Industrie 4.0 Communication Guideline Based on OPC UA” should be understood as a practice-oriented tool. It shows action steps that help to implement the industry 4.0 communication in the company. Special thanks go to Prof. Dr. Oliver Niggemann and Prof. Dr.-Ing. Jürgen Jasperneite from the Fraunhofer Application Center Industrial Automation (IOSB-INA) for the scientific preparation of the VDMA guideline. In addition, it is important to thank the participating VDMA members for their commitment.
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.
Article
Full-text available
Metamodelling provides a way of modelling the rules underpinning not only modelling languages such as UML but also processes. In the context of object-oriented development, we evaluate the conceptual framework used to reason about metamodelling from the different perspectives of methodologist, method engineer and software developer. We propose the use of clabjets and powertype patterns as a solution to avoid the present inconsistencies in the use of a strict metamodelling multi-level hierarchy and demonstrate their efficacy in providing a solid and improved framework for OO-based process (and product) metamodelling.
Conference Paper
Full-text available
Lazy Initialization Multilayer Modeling (LIMM) is an object oriented modeling language targeted to the declarative definition of Domain Specific Languages (DSLs) for Model Driven Engineering. It focuses on the precise definition of modeling frameworks spanning over multiple layers. In particular, it follows a two dimensional architecture instead of the linear architecture followed by many other modeling frameworks. The novelty of our approach is to use lazy initialization for the definition of mapping between different modeling abstractions, within and across multiple layers, hence providing the basis for exploiting the potential of metamodeling.
Conference Paper
Full-text available
As the UMLattempts to make the transition from a single, albeit extensible, language to a framework for a family of languages, the nature and form of the underlying meta-modeling architecture will assume growing importance. It is generally recognized that without a simple, clean and intuitive theory of how metamodel levels are created and related to one another, the UML2.0 vision of a coherent family of languages with a common core set of concepts will remain elusive. However, no entirely satisfactory metamodeling approach has yet been found. Current (meta-)modeling theories used or proposed for the UML all have at least one fundamental problem that makes them unsuitable in their present form. In this paper we bring these problems into focus, and present some fundamental principles for overcoming them. We believe that these principles need to be embodied within the metamodeling framework ultimately adopted for the UML2.0 standard.
Article
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
Model-Driven Engineering (MDE) proposes to modularize complex software-intensive systems using multiple models where each module serves a specific concern. These concerns of a system might be diverse and the use of multiple heterogeneous models often becomes inevitable. These models adhere to different paradigms and use distinct formalisms, which makes it hard to ensure consistency among them. Moreover, these models might contain certain concepts (at times overlapping) that are reused for building cross-concern views/models. Maintaining models using separation of concerns in a heterogeneous modeling space becomes difficult. Traditional MDE suggests the use of model transformations to maintain the mappings between heterogeneous models. In this paper, we introduce a different approach based on model federation to map heterogeneous models. In contrast to traditional approaches where heterogeneous models are gathered in a single technological space, model federation keeps them in their own technological spaces. We provide a mechanism so that elements of these models are accessible for the development of cross-concern views/models from their respective technological spaces.
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.