PLC Integration into Industry 4.

0 Middleware:
Function Block Library for the Interaction with
REST and OPC UA Asset Administration Shells
2021 IEEE 26th International Conference on Emerging Technologies and Factory Automation (ETFA) | 978-1-7281-2989-1/21/$31.00 ©2021 IEEE | DOI: 10.1109/ETFA45728.2021.9613267

Jonas Gampig Tarik Terzimehić, Kirill Dorofeev

Technical University Munich fortiss - Research Institute of the Free State of Bavaria
Munich, Germany Munich, Germany
[email protected] {terzimehic, dorofeev}@fortiss.org

Abstract—An asset administration shell (AAS), as a key automation device, a process description, or product data. An
concept of Industry 4.0 (I4.0), provides a machine-accessible AAS might contain administration data, run-time information,
interface to any kind of asset. To enable interoperability and or even executable operations of a device. This is relevant for
smooth integration of the devices into the I4.0 middleware,
an application implementing the device’s functionality should all information systems constituting a production environment,
be able to interact with different AASs. In this work, we and enables interoperability between all the layers of the
investigate the integration of the Programmable Logic Controller automation pyramid.
(PLC) runtime systems into the I4.0 middleware. For doing Further motivation for the AAS-based standardized interac-
this, we specify the function blocks (FBs) for connecting the tion of the components from different layers is the concept of
PLCs with AASs and other I4.0 components, such as registry
and discovery server. We analyze the requirements of such FBs retrofitting the brownfield devices [1], as well as the concept of
while focusing on REST/HTTP- and OPC UA-based AASs, and plug and produce, i.e., automated integration of the shop floor
provide interface specification for IEC 61499- and IEC 61131-3- components, such as PLCs. To support this, the PLC must be
based FBs. Furthermore, we implemented an FB library that capable of identifying and describing itself to the higher layers,
enables communication with an AAS from the respective control as well as to the other shop floor components [2]. For in-
applications. Those FBs allow accessing properties and invoking
operations of remote AASs, as well as hosting AASs submodels. stance, a newly added component registers itself at the registry
Common functionalities, such as registering the runtime system component through its AAS, and reads its configuration data
at the registry component, or finding AASs, are also supported. from its AAS during the initialization phase. Furthermore, this
The results obtained in this paper will ease interaction with the component might want to retrieve status information about its
complex AAS structure from the low-level devices. neighbor component, or some environment information from
Index Terms—Industry 4.0, IEC 61499, IEC 61131-3, asset ad-
ministration shell, digital twin, PLC, OPC UA, REST, discovery the working cell it is contained in, as shown in Figure 1.
server, model-based development. To achieve this, the control program, implementing the
device functionality, needs to connect to various AASs and
I. I NTRODUCTION interact with them. There exist, however, some challenges:
the control applications are usually implemented in low-level
The information systems used in industrial automation (IA) languages [3], and the AAS has a complex structure (see, e.g.,
are typically structured in a strict pyramid of layers, where the [4]), which makes the interaction with AAS difficult from the
data coming from the field layer to the management layer has PLC programmer point of view. A function block (FB) is the
to be transferred through all the intermediate systems. Thus, basic building element of automation applications according to
only neighboring layers are communicating directly with each the IEC 61131-3 and IEC 61499 standards for programming
other. For instance, a Programmable Logic Controller (PLC) automation and control systems [5], [6]. Therefore, we need
controlling the production process, communicates directly with to define FBs for the interaction with AASs, as well as other
the upper layer for monitoring and supervising, but not with Industry 4.0 components, e.g., registry and discovery servers.
the management layer [1]. Several attempts have been made towards realizing an
With the fourth industrial revolution, known as Industry 4.0 interaction mechanism between a PLC and an AAS. However,
(I4.0), this pyramid is broken up to allow a mass integration current research works either 1) provide application-specific
of devices and applications from the shop floor up to higher FBs for the interaction with AASs [7], or 2) neglect IA
layers [2]. Thereby, any design documents and data, e.g., spec- domain specifics, such as OPC UA communication [8], PLC
ifications of a machine, as well as run-time data of IA systems, programming with IEC 61131-3 and IEC 61499 standards [9],
are collected in a standardized format: all assets, including or standardized AAS meta-model [10].
machines and products of a company, are represented by a Opposed to current research works, we specify and imple-
digital twin, i.e., an asset administration shell (AAS) [1]. ment generic FBs for accessing remote, and hosting own AAS
An AAS is the key element of the I4.0 [2] that provides and/or its submodels. We extend our work in [11] and specify
a machine-accessible interface to any kind of asset - be it an the IEC 61131-3- and IEC 61499-based interfaces of client
978-1-7281-2989-1/21/$31.00 © 2021 IEEE and server FBs to host or interact with AASs and submodels.

Authorized licensed use limited to: Universidad Del Norte Biblioteca. Downloaded on December 21,2022 at 17:02:55 UTC from IEEE Xplore. Restrictions apply.
 servers into a registry, an AAS- and a Submodel-server (Fig-
ure 3). An AAS is registered at a central registry together with
its endpoint and its submodels. Knowing the identifier of an
AAS, an application can retrieve the AAS’ endpoint from the
registry. As the submodels may be hosted on separate servers,
they have to register themselves at their parent AAS.

get endpoint
«Server»
Registry response

register

request
«Server» «Client»
AAS response Application

Fig. 1: High-level relationship between an asset, its AAS and

register
an application, controlling the asset and accessing the AAS.
response
«Server»
Submodel request
II. M ETAMODEL OF THE A DMINISTRATION S HELL
Manufacturing lines often comprise heterogeneous compo- Fig. 3: Architecture of the AAS servers and clients.
nents from different vendors [1]. To fully benefit from the
AAS concept in practice, various AASs from different vendors III. S PECIFICATION OF THE F UNCTION B LOCKS
should be compatible. This compatibility requires a vendor-
FBs are the main building blocks of the control pro-
independent standard [12].
grams [14], which are used in both IEC 61131-3 [5] and
The German network Platform Industry 4.0 published a pro-
IEC 61499 [6] PLC programming languages. In this section,
posal on how to uniformly structure an AAS [13]. Within our
we first describe the nature and requirements of the FBs
work, we use this proposal as a baseline for defining AASs’
for interacting with AAS. Following, we specify the data
elements and their relations among each other. The metamodel
types that should be implemented in the PLC programming
specified in [13] defines the classes AssetAdministrationShell,
languages to support the interaction with AASs. Afterwards,
Submodel, and various SubmodelElements, among others. A
the interfaces of the FBs for both IEC 61131-3 and IEC 61499
simplified version of the metamodel is depicted in Figure 2.
are defined. Finally, we define the FB error codes, representing
the possible failures in PLC-to-AAS interactions.
«abstract»
AssetAdministrationShell
Referable This library is following the architecture shown in Figure 3.
It is split into three parts: client-, server-, and registry client-
«abstract»
FBs. Hosting a registry is out of scope of this work, as it
Submodel
Identifiable is assumed that the registry is running on a central, more
powerful server, and, therefore, not implemented in one of
«abstract»
the PLC programming languages. The library covers parts
SubmodelElement
of the AAS metamodel that we find especially relevant for
the interaction from the PLC. Future work may extend the
specification to comply with the whole metamodel.
SubmodelElementCollection Operation Property
The specification and implementation were carried out while
part 1 of the Details of the AAS specification [13] was
Fig. 2: Simplified metamodel of the asset administration shell. available. However, part 2 [15] has been published in the
meantime. The newest part focuses on information exchange
An AAS has multiple Submodels, which are not necessarily
via application programming interfaces (APIs), i.e., it specifies
hosted on the same device. A Submodel has multiple Submod-
technology-independent APIs. It does not include the specific
elElements, which can be, among others, a Property, an Opera-
API for, e.g., OPC UA or HTTP/REST. To be compliant with
tion, or a SubmodelElementCollection. All SubmodelElements
the part 2 of the Details of the AAS [15], the following things
are referable, meaning they have a short identifier that is
would have to be adjusted in the specified FBs types: the
unique in the namespace of the parent element. Submodels
structure of the URIs, the available operations on elements,
and AASs are furthermore globally and uniquely identifiable,
and the structure of the input and output parameters.
e.g., by a Universal Resource Identifier (URI). This identifier
may differ from the endpoint address of the server. A. Nature of the Function Blocks for Accessing the AAS
The open source platform Eclipse BaSyx1 , which provides
a reference implementation of the AAS elements, splits the FBs for interacting with the AAS are communication FBs
containing state machines, as it is similarly proposed for
1 https://www.eclipse.org/basyx/ OPC UA FBs in PLCOpen [16], and providing a generic

Authorized licensed use limited to: Universidad Del Norte Biblioteca. Downloaded on December 21,2022 at 17:02:55 UTC from IEEE Xplore. Restrictions apply.
interface (i.e., preferably communication-agnostic). Defining reference to its parent class. The abstract classes are reflected
the FBs for interacting with AASs calls for consideration of by custom data types.
certain characteristics and requirements. They were selected Both standards, IEC 61131-3 and IEC 61499, provide a
by analyzing use-cases, common practice in the industry, and basic set of data types, e. g., STRING and INT. These can
limitations of the hardware the FBs will be deployed to. be extended by defining custom types [17]. Further, we define
Portability: The FB interface should be implementation- multiple STRUCTs that should enable the PLC-to-AAS com-
independent to abstract the technology specifics. Furthermore, munication. The standards also allow multiple data elements
the FBs should be communication protocol-independent: the of the same data type to be grouped in an ARRAY. Defining
FB interface should be generic for any communication pro- the ARRAY’s size is application-specific and thus out of scope
tocol. Those agnostic FBs might contain communication pa- for this work. It is denoted with a * as a placeholder.
rameters, such as opc_ua, http, etc., to distinguish between 1) Reference: A reference, as defined in [4], consists of
different technologies. multiple keys, which can be concatenated to an absolute path.
Usability: A user (a PLC programmer) only has to specify Every key contains the identifier of an element. The structure
the AAS, submodel and data element IDs; all other required is reflected by the data types defined below.
steps, such as the queries, IP settings, string parsing, etc., KEY : STRUCT
should occur automatically in the background. On the example Type : STRING ;
of a REST-based AAS, the JavaScript Object Notation (JSON) L o c a l : BOOL;
parsing should be hidden from the user. However, utility FBs V a l u e : WSTRING ;
for JSON parsing might be provided, as well as some other I d T y p e : STRING ;
END STRUCT ;
auxiliary FBs. Moreover, to reuse the domain knowledge, the REFERENCE : ARRAY [ * ] OF KEY;
FBs’ specification should be aligned with the PLCOpen OPC REFARRAY : ARRAY [ * ] OF REFERENCE ;
UA FB’s specification by using similar variables (Busy, Done,
Error, etc.) and state machines. 2) LangString: LangString keeps a text and a reference
Interoperability: A standardized FB library requires a fixed to the language of the text. This structure together with
and standardized AAS structure. Also, standard error codes LangStringSet is shown below.
should be defined. The FB concept should be similar for both LANGSTRING : STRUCT
IEC 61131-3- and IEC 61499-based programming languages. Language : STRING ;
Performance: Interaction with AAS should not jeopardize T e x t : WSTRING ;
END STRUCT ;
the real-time characteristics of the control application. This LANGSTRINGSET : ARRAY [ * ] OF LANGSTRING ;
is especially important as the AASs can be implemented
using different technologies and underlying communication 3) Qualifiable: All Submodels and SubmodelElements con-
infrastructure might lack real-time capability. tain the Qualifiable attribute. This is an array of Constraints,
Client & server functionalities: Client functionality, i.e., where a Constraint can be either a Qualifier or a Formula.
accessing a remote AAS or one of its submodels from the The structure of the data type is shown below.
PLC, is more important for PLC level: it is more likely that QUALIFIER : STRUCT
the AAS is created with some high-level languages and hosted Type : STRING ;
outside of memory-limited PLCs. However, FBs for server ValueType : STRING ;
functionality, i.e., hosting an AAS within a PLC, should be V a l u e : ANY;
V a l u e I d : REFERENCE ;
also considered. For client functionality, we need to define S e m a n t i c I d : REFERENCE ;
a way to implement reading and writing from/into an AAS END STRUCT ;
(e.g., via REST/HTTP interface); for server functionality a
PLC should be able to store an AAS. CONSTRAINT : UNION
High-level & low-level APIs: The AAS is a very pow- Q u a l i f i e r : QUALIFIER ;
F o r m u l a : REFARRAY ;
erful, but also very complex concept, providing numerous END UNION ;
possibilities for both, client and server functionalities. For QUALIFIABLE : ARRAY [ * ] OF CONSTRAINT ;
example, sometimes we solely want to read a value of a certain
property, whereas in particular cases we need to read the whole 4) Referable and Identifiable: Most of the elements spec-
JSON string of a property, or even to load a whole submodel. ified in [4] are referable, meaning they are assigned a short
Depending on the use case, there is a need for different identifier. AASs, assets and submodels are additionally iden-
granularity of the interaction with the AAS. Therefore, we tifiable with a globally unique ID.
should provide both, low-level, as well as high-level FBs. REFERABLE : STRUCT
I d S h o r t : WSTRING ;
B. Data Types C a t e g o r y : WSTRING ;
D e s c r i p t i o n : LANGSTRINGSET ;
The metamodel of the AAS includes various abstract classes P a r e n t : REFERENCE ;
that group different attributes together. For example, a refer- END STRUCT ;
able class has a short ID, a category, a description, and a

Authorized licensed use limited to: Universidad Del Norte Biblioteca. Downloaded on December 21,2022 at 17:02:55 UTC from IEEE Xplore. Restrictions apply.
 Event INIT INITO Event Event INIT INITO Event
IDENTIFIABLE : STRUCT ERROR Event ERROR Event
R e f e r a b l e : REFERABLE ; HostAas HostSubmodel
STRING CommId ErrorId UINT STRING CommId ErrorId UINT
I d T y p e : STRING ; IDENTIFIABLE Identifiable IDENTIFIABLE Identifiable
I d : WSTRING ; REFARRAY DataSpecification REFARRAY DataSpecification
REFERENCE DerivedFrom QUALIFIABLE Qualifiable
V e r s i o n : STRING ; REFERENCE Asset REFERENCE SemanticId
R e v i s i o n : STRING ;
END STRUCT ; HostAas HostSubmodel
BOOL Enable Done BOOL BOOL Enable Done BOOL
5) Endpoint: Endpoints are not specified in [4] but are STRING CommId Busy BOOL STRING CommId Busy BOOL
necessary when using a registry as described in Section II. For IDENTIFIABLE Identifiable Error BOOL IDENTIFIABLE Identifiable Error BOOL
REFARRAY DataSpecification ErrorId UINT REFARRAY DataSpecification ErrorId UINT
this work, the specification of an endpoint, as it is defined by REFERENCE DerivedFrom QUALIFIABLE Qualifiable
REFERENCE Asset REFERENCE SemanticId
BaSyx, is used. The corresponding data type is shown below.
ENDPOINT : STRUCT Fig. 5: IEC 61499 and IEC 61131-3 FBs to host an AAS and
Type : STRING ; submodels.
V a l u e : WSTRING
END STRUCT ; Hosting certain SubmodelElements is possible with the FBs
ENDPOINTARRAY : ARRAY [ * ] OF ENDPOINT ; defined in Figure 6. First, the parent Submodel and any parent
C. AAS Client FB Interfaces SubmodelElements need to be created. Then, the application
can invoke the FBs to create a SubmodelElementCollection,
Figure 4 shows the IEC 61499 and IEC 61131-3 FBs for a Property, or an Operation. The value of the HostProperty
the interaction with a remote AAS submodel. The GetProperty needs to be supplied. The value is updated at initialization,
FB is used to read a value and a type of a property. The when the REQ event occurs. Furthermore, if ReadOnly is set to
SetProperty FB is used to change a value of a property. Calling false, a remote client can change the value, which is indicated
a method can be done using the InvokeOperation FB, which is by the IND event and the UpdatedValue data output.
a generic FB, meaning it supports a varying number of input
parameters and output results for different FB instances. Event INIT INITO Event Event INIT INITO Event
Event REQ CNF Event Event RSP IND Event
Event INIT INITO Event Event INIT INITO Event IND Event ERROR Event
Event REQ CNF Event Event REQ CNF Event ERROR Event HostOperation
ERROR Event IND Event HostProperty STRING CommId ErrorId UINT
GetProperty ERROR Event STRING CommId ErrorId UINT WSTRING SubmodelId Parameter1 ANY
STRING CommId ErrorId UINT InvokeOperation WSTRING SubmodelId UpdatedValue ANY WSTRING PathToParent Parameter2 ANY
WSTRING SmEndpoint Value ANY STRING CommId ErrorId UINT WSTRING PathToParent REFERABLE Referable ...
WSTRING Path Type STRING WSTRING SmEndpoint Result1 ANY REFERABLE Referable QUALIFIABLE Qualifiable
WSTRING Path Result2 ANY QUALIFIABLE Qualifiable REFERENCE SemanticId
Event INIT INITO Event ANY Parameter1 ... REFERENCE SemanticId REFARRAY InputVariables
Event REQ CNF Event ANY Parameter2 STRING ValueType REFARRAY OutputVariables
ERROR Event ... REFERENCE ValueId REFARRAY InoutputVariables
SetProperty BOOL ReadOnly ANY Result1
STRING CommId ErrorId UINT ANY Value ANY Result2
WSTRING SmEndpoint ...
WSTRING Path
ANY Value
HostProperty HostOperation
BOOL Enable Done BOOL BOOL Enable Done BOOL
GetProperty InvokeOperation BOOL Set Busy BOOL BOOL Response Busy BOOL
BOOL Execute Done BOOL BOOL Execute Done BOOL STRING CommId Error BOOL STRING CommId Indication BOOL
STRING CommId Busy BOOL STRING CommId Busy BOOL WSTRING SubmodelId SetDone BOOL WSTRING SubmodelId Error BOOL

WSTRING SmEndpoint Error BOOL WSTRING SmEndpoint Error BOOL WSTRING PathToParent SetError BOOL WSTRING PathToParent ErrorId UINT

WSTRING Path ErrorId UINT WSTRING Path ErrorId UINT REFERABLE Referable Update BOOL REFERABLE Referable Parameter1 ANY
QUALIFIABLE Qualifiable ErrorId UINT QUALIFIABLE Qualifiable Parameter2 ANY
Value ANY ANY Parameter1 Result1 ANY
REFERENCE SemanticId UpdatedValue ANY REFERENCE SemanticId ...
Type STRING ANY Parameter2 Result2 ANY
STRING ValueType REFARRAY InputVariables
... ...
REFERENCE ValueId REFARRAY OutputVariables
SetProperty
BOOL ReadOnly REFARRAY InoutputVariables
BOOL Execute Done BOOL
ANY Value ANY Result1
STRING CommId Busy BOOL
ANY Result2
WSTRING SmEndpoint Error BOOL
...
WSTRING Path ErrorId UINT
ANY Value
Fig. 6: IEC 61499 and IEC 61131-3 FBs to host SubmodelEle-
Fig. 4: IEC 61499 and IEC 61131-3 FBs to interact with a ments; HostSubmodelElementCollection is not shown, but its
remote submodel. interface is similar to the other server FBs, with the additional
Ordered and AllowDuplicates boolean input parameters.
IEC 61131-3 standard lacks events inputs, which are gen-
erally replaced by Boolean signals. The naming follows the
When a remote client invokes the operation of HostOp-
scheme proposed by PLCopen [16].
eration, the IND event together with the parameter outputs
D. AAS Server FB Interfaces (Parameter1, Parameter2, etc.) arrive at the application to
The FBs for hosting a submodel or an AAS are specified signal the request. Then, the application needs to perform the
in Figure 5. The data inputs are covering the attributes of method call and return its results by activating the RSP event.
the metamodel equivalents, using the data types defined in The FBs for IEC 61131-3, shown in Figure 6, are similar to
the Section III-B. Similar to the client FBs, the data signals their counterparts implemented in IEC 61499. HostOperation’s
for IEC 61131-3 FBs are the same, and the event signals are IND and RSP events are equivalent to the Indication and
changed to Boolean inputs, to comply with the standard. Response Booleans of the IEC 61131-3 version, respectively.

Authorized licensed use limited to: Universidad Del Norte Biblioteca. Downloaded on December 21,2022 at 17:02:55 UTC from IEEE Xplore. Restrictions apply.
E. Registry Client FB Interfaces FBs are composed of a variant for HTTP/REST and a variant
As explained in Section II, the AAS architecture includes a for OPC UA. For example, when HostSubmodel receives an
central registry. The FBs in Figure 7 enable registration of a execution request, it delegates the task to the communication-
submodel and an AAS. The inputs AasDescriptor and SmDe- dependent variant specified by CommId.
scriptor take a descriptor object of the respective element. A. OPC UA
The concept of descriptors is presented in Eclipse BaSyx. The OPC UA data model is represented by AddressSpace
Descriptors are additional classes containing information about comprising a set of nodes connected by references [18].
the identification and the endpoints of an AAS or submodel, The nodes can be structured hierarchically, which enables a
so the registry and clients can find out how to communicate folder-like structure of the nodes. Node types define attributes
with an asset. For instance, a client application can retrieve attached to the node, as well as the relationships between
the endpoint from the registry, as well as the identifier of different node types.
the communication protocol used for communicating with an The OPC UA implementation of the FB library uses the
asset, e.g., opc_ua for OPC UA. The FB interfaces of the Eclipse 4diac OPC UA module, which allows a control ap-
IEC 61131-3 counterparts are not presented in the Figure 7, plication to create nodes on a local server or to interact as a
as they only differ in the event signals. client with nodes from a local or remote server.
Event REQ CNF Event Event REQ CNF Event
The AAS specification [4] defines rules for the mapping the
ERROR
RegisterAas
Event ERROR
GetAasEndpoint
Event
AAS to OPC UA. This includes naming rules and an overview
STRING CommId ErrorId UINT STRING CommId ErrorId UINT of node types that shall be used. The OPC Foundation is
WSTRING RegEndpoint WSTRING RegEndpoint AasCommId STRING
AASDESCR AasDescriptor WSTRING AasId AasEndpoint WSTRING currently developing an OPC UA Information Model, which
Event REQ CNF Event Event REQ CNF Event
specifies the structure of AAS [19]. However, only a release
ERROR Event ERROR Event candidate got published at the time of writing [20].
RegisterSm GetSmEndpoint
STRING CommId ErrorId UINT STRING CommId ErrorId UINT For every object instantiated according to the AAS meta-
WSTRING RegEndpoint WSTRING RegEndpoint SmCommId STRING
WSTRING AasId WSTRING AasId SmEndpoint WSTRING
model, an OPC UA object node is created by the FBs of this
SMDESCR SmDescriptor WSTRING SmId
library. Attributes of the objects are either further structured
Fig. 7: IEC 61499 FBs to interact with a registry. by object nodes, or are represented by variable nodes. For
example, a submodel’s identification attribute is represented
F. Error Codes by an Identification object node, which contains the attributes
All FBs have dedicated output signals that indicate an error Id and IdType as variable nodes.
occurred during execution, including the ErrorId (Table I). B. REST
While the first four codes represent errors that happen in the The REST implementation uses the HTTP module of
underlying communication technology, format error handles Eclipse 4diac. The payload of HTTP requests and responses
the cases of wrongly formatted input data, and unknown are defined using JSON format. The AAS specification [4]
responses from the communication partner. gives hints on how to map the AAS components to JSON.
ErrorId Description However, it neither specifies an HTTP/REST-specific API nor
0 CommId unknown any rules similar to the rules for OPC UA. Thus, the library
1 Communication: Initialization failed is implemented according to the API of Eclipse BaSyx3 .
2 Communication: Client: Request failed
3 Communication: Server: Bad request indication
The general structure of the REST server FBs library is
4 Communication: Client: Bad response from server shown in Figure 8, for the example of HostSubmodelRest. The
5 Format error REST server FBs are composed of multiple HTTP server FBs
TABLE I: Description of the error codes indicating the type that provide endpoints according to the Eclipse BaSyx API,
of a problem, occurred during the execution of AAS FBs. e.g., one HTTP server FB which responds with the serialized
submodel as its payload. Furthermore, all FBs have access to
an internal directory of submodels and AASs.
IV. I MPLEMENTATION IN E CLIPSE 4 DIAC
HostSubmodelRest
The FBs specified in Section III were implemented for
the open source framework Eclipse 4diac2 . This framework
comprises an IDE for implementing the IEC 61499 FBs
and applications, as well as the runtime environment (RTE) HostInternal- InternalSubmodel-
HTTP Server
Submodel ToJson
FORTE, for which the FBs are developed.
The implemented library supports two communication pro-
«uses»
tocols: OPC UA and HTTP/REST. While the former is used «uses»
aaslib

extensively for the communication between I4.0 PLCs [7],

the latter is a common internet technology [11]. All top-level Fig. 8: Internal structure of REST server FBs.
2 https://www.eclipse.org/4diac/ 3 As of commit 5ead0f5 of the git repository of Eclipse BaSyx

Authorized licensed use limited to: Universidad Del Norte Biblioteca. Downloaded on December 21,2022 at 17:02:55 UTC from IEEE Xplore. Restrictions apply.
 When a submodel gets created, HostSubmodelRest delegates FunctionBlock
«uses»
Implement
as Singleton
the task to HostInternalSubmodel. The internal Submodel class
AssetAdministrationShell
gets instantiated, and a reference is added to the internal AasDirectory
toJson()
AasDirectory. When the HostSubmodelRest FB gets destruc-
ted, the submodel gets removed from AasDirectory and the SubmodelElementContainer SubmodelElement

elementsToJson() toJson()
memory is released. This sequence is depicted in Figure 9.

:HostSubmodel- :HostInternal-
:aaslib::AasDirectory Submodel SubmodelElementCollection Operation Property
Rest Submodel
toJson() ordered: Bool inputVariable: OperationVariable [0..*] valueType: String
createSubmodel submodel :
create allowDuplicates: Bool outputVariable: OperationVariable [0..*] value: Any
aaslib::Submodel
inoutputVariable: OperationVariable [0..*] valueId: Reference
toJson()

addSubmodel(submodel) toJson() toJson()

return
return
Fig. 10: Classes of the aaslib module.
destroy
removeSubmodel(submodel)
return
interaction with an AAS. It is split into the four parts: Uniform
destroy
return Resource Locator (URL), JSON, OPC UA, and custom data
types related FBs.
The URL utility FBs include functionality for encoding a
string without the reserved characters of URLs, as defined
Fig. 9: Sequence of the submodel creation and deletion in the in the URI syntax standard RFC 3986 [22]. It is used to
REST implementation. encode an AAS or submodel identifier, which may itself be
a URL, allowing, thereby, a URL concatenation. Other utility
Multiple FBs need to access the same information of some FBs remove the protocol part from a URL, or split a URL into
elements of the AAS, e.g., HostSubmodelRest needs to have host and path parts.
access to the object of HostPropertyRest. This is because Host- The JSON utility FBs allow to add and get an element from
SubmodelRest includes an endpoint (according to the Eclipse a JSON string by using paths, according to the JSON pointer
BaSyx API) from which the whole submodel, including its standard RFC 6901 [23]. The JsonAddElement FB parses the
SubmodelElements, can be retrieved. The problem of shared element and adds it to a JSON object. The JsonAddString FB
data between different FBs is solved by implementing a low- places the element directly into the object, surrounded by quo-
level aaslib module for the RTE Eclipse 4diac FORTE. The tation marks, rather than parsing the element. Otherwise, the
module consists of the AAS metamodel classes, as well as application would have to add the quotations marks manually.
of the class AasDirectory, which is instantiated only once per The AAS metamodel specifies some attributes as arrays,
RTE and is accessible from any other FB. which is reflected by the data types defined in section III-B.
The class diagram in Figure 10 shows the most impor- The library includes FBs to add an element to the array types
tant classes of aaslib. The blue classes in the Figure are Qualifiable, Endpoints, LangStringSet, and Reference.
representing elements of the metamodel. An FB accesses Figure 11 shows two examples of the utility FBs. The
the AasDirectory to either add, remove, or find a submodel ArrayAddReferenceKey FB is part of the array creation FBs.
or AAS. Both Submodel and SubmodelElementCollection are An application triggers this FB to create a reference according
containers of multiple SubmodelElements. to the AAS metamodel. The JsonGetElement FB allows to
The HTTP module of Eclipse 4diac lacks support of some parse a JSON object and search for an element.
HTTP functionalities. In particular, a path can only be regis-
tered to one FB, which means that a path can only be served
by one method. However, the Eclipse BaSyx API uses multiple
different methods, such as POST and GET, for the same path.
This results in some server FBs to be incompatible with the
API implemented by Eclipse BaSyx and the client FBs.
Parsing and creating JSON objects is done using the external
C++ library ”JSON for Modern C++”4 , version 3.7.3. It was Fig. 11: Examples of utility FBs implemented in this work.
chosen due to high popularity among open source solutions,
and its very simple usage [21]. V. VALIDATION
C. Utility FBs The validation scenario (Figure 12) assumes two conveyor
The library implementation includes utility FBs, which belts GF01 and GF02, and an orchestrator that coordinates
encapsulate some repetitive functionalities needed for the these two components. The BaSyx application, created with
the Eclipse BaSyx Java SDK, hosts a registry together with
4 https://github.com/nlohmann/json the two AASs for GF01 and GF02, as well as a Submodel

Authorized licensed use limited to: Universidad Del Norte Biblioteca. Downloaded on December 21,2022 at 17:02:55 UTC from IEEE Xplore. Restrictions apply.
DeviceResources. The latter offers information about GF01’s
device resources, such as its temperature and the operating
system running on it. A REST submodel and an OPC UA
submodel are hosted on two FORTE RTEs, and an orches-
trator, which uses client FBs, is running on the third FORTE
instance.

BaSyx Application
GF01 RTE Orchestrator RTE GF02 RTE
Registry
GF01/Conveyor ExampleOrchestrator GF02/Conveyor
GF01 GF02 Fig. 14: Excerpt of the Eclipse 4diac application to host a
GF01/DeviceResources
submodel using OPC UA.
OPC-UA

HTTP

Fig. 12: Validation scenario: Three applications using the

FBs specified in this paper are deployed across three RTEs.
Furthermore, a BaSyx application hosts the registry, as well
as two AASs, and a submodel.

First, the BaSyx application starts the registry. Then, the

two submodels running on FORTE RTEs are registering
themselves at the remote registry. Afterwards, the orchestrator
retrieves the endpoints of the submodels and interacts with
them, e.g., reads a property value and invokes an operation.
When being tested against this scenario, the implementation is Fig. 15: Conveyor submodel hosted with OPC UA
working as expected, enabling successful interaction between
different AASs, submodels, control applications, orchestrator, VI. R ELATED W ORK
and registry component.
Several attempts have been made towards realizing an
The registry is hosted on an HTTP REST endpoint with
interaction mechanism between a physical component, such as
BaSyx. It answers requests with JSON objects, as partly
PLC, and its digital representation. Kirchhof et al. [9] propose
shown in Figure 13, including some attributes of the registered
a model-based approach to synchronize, or map, a cyber-
GF02 AAS and one of its submodels, conveyor2 (denoted as
physical system (CPS) with its digital twin, i.e., an AAS in our
GF02/Conveyor in Figure 12).
paper. They model CPS’ software and digital twin with Mon-
tiArc architecture language and class diagrams. To specify data
reflecting the CPS, they map ports of the CPS to the attributes
of the digital twin, and generate communication infrastructure
for CPS’ software and digital twin model. Contrary to this
work, we use standardized AAS meta-model [4], and focus
on IA domain, i.e., PLC programming with IEC 61131-3 and
IEC 61499 standards.
Tantik et al. [8] describe an implementation of a flexible
AAS, concentrating on the requirements for automated access,
Fig. 13: Part of the JSON response from the registry. components hierarchy, storage of the product life cycle data,
and flexibility. The proposed architecture, however, uses solely
Figure 14 shows part of the 4diac application to a REST interface as a communication layer, rather than I4.0-
host the conveyor submodel over OPC UA. The compliant communication protocol, such as OPC UA [7].
AAS ArrayAddReferenceKey FB is used to add the semantic Lüder et al. [24] present an AAS implementation using
ID as a reference to the submodel’s template. Then, the standardized domain technologies, such as OPC UA and
AAS HostSubmodel FB hosts the submodel, with CommId AutomationML5 . Additionally, the IEC 61131-3 application of
set to opc_ua. an I4.0-component is made available by means of PLCOpen
The final OPC UA submodel can be partially seen in information model6 . However, this work lacks a mechanism
Figure 15, which is a screenshot of the OPC UA UaExpert for an I4.0-component itself to interact directly with AASs.
client. The submodel conveyor2 has multiple attributes, e.g., 5 https://www.automationml.org
Category and IdShort. It also has multiple SubmodelElements, 6 https://opcfoundation.org/developer-tools/specifications-unified-
e.g., the property locked and the operation moveForward. architecture/opc-unified-architecture-plcopen-information-model/

Authorized licensed use limited to: Universidad Del Norte Biblioteca. Downloaded on December 21,2022 at 17:02:55 UTC from IEEE Xplore. Restrictions apply.
 Wenger et al. [10] use XQuery requests to establish an R EFERENCES
interaction between an I4.0-component and an AAS. To form [1] T. Bangemann, M. Riedl, M. Thron, and C. Diedrich, “Integration of
an XQuery request from the PLC, the application side requires Classical Components into Industrial Cyber-Physical Systems,” Proceed-
detailed knowledge about the structure of the information ings of the IEEE, 2016.
[2] D. A. Breunig, D. Stock, and T. Bauernhansl, “Requirements and
model that forms the AAS. The more complex the AAS concept for a modular and state-oriented control device architecture,”
information structure is, the larger the XQuery requests get. Procedia Manufacturing, 2020.
Cavalieri and Salafia [12] propose an AAS meta-model [3] F. J. Molina, J. Barbancho, C. Leon, A. Molina, and A. Gomez,
“Using industrial standards on PLC programming learning,” in 2007
to represent IEC 61131-3 programs, and, thereby, ease the Mediterranean Conference on Control and Automation, MED, 2007.
development and reconfiguration of the production system. [4] “Details of the Asset Administration Shell: Part 1,”
They implemented the AAS meta-model using OPC UA com- Plattform Industrie 4.0, Tech. Rep. [Online]. Avail-
able: https://www.plattform-i40.de/PI40/Redaktion/EN/Downloads/
munication protocol. Similarly, Pethig et al. [7] implemented Publikation/Details of the Asset Administration Shell Part1 V3.html
the application specific, OPC UA-based, IEC 61131-3 FB for [5] IEC SC65B, “IEC 61131-3 Programmable Controllers. Part 3: Program-
hosting an AAS, more concretely, AAS sub-model’s proper- ming languages,” 2003.
[6] I. SC65B, “IEC 61499-1 Function Blocks for Industrial Process Mea-
ties. Opposed to those works, we provide generic FBs for both, surement and Control Systems. Part 1: Architecture,” 2005.
hosting an AAS locally at the control device, and accessing a [7] F. Pethig, O. Niggemann, and A. Walter, “Towards Industrie 4.0 com-
remote AAS. Thereby, we allow an I4.0-component to interact pliant configuration of condition monitoring services,” in IEEE 15th
International Conference on Industrial Informatics, INDIN, 2017.
directly with different AASs and registry component. [8] E. Tantik and R. Anderl, “Integrated data model and structure for the
VII. C ONCLUSION AND F UTURE W ORK asset administration shell in industrie 4.0,” Procedia CIRP, 2017.
[9] J. C. Kirchhof, J. Michael, B. Rumpe, S. Varga, and A. Wortmann,
In this research paper, we specify generic FBs to host “Model-driven digital twin construction: Synthesizing the integration
and interact with elements of the AAS metamodel. The FBs of cyber-physical systems with their information systems,” in 23rd
ACM/IEEE Int. Conf. on MdE Languages and Systems, MODELS, 2020.
come in two flavors, one complying with IEC 61499, and one [10] M. Wenger, A. Zoitl, and M. Thorsten, “Connecting PLCs with their
for IEC 61131-3. Additionally, the FBs for IEC 61499 were Asset Administration Shell for Automatic Device Configuration,” in
implemented for the open-source framework Eclipse 4diac. IEEE International Conference on Industrial Informatics (INDIN), 2018.
[11] T. Terzimehić, A. Bayha, and K. Dorofeev, “Function Blocks for the
The library was validated against an example scenario, with Interaction with the Asset Administration Shell,” IEEE Int. Conf. on
the AAS reference implementation framework Eclipse BaSyx. Emerging Technologies and Factory Automation, ETFA, 2019.
The library was designed to be independent of commu- [12] S. Cavalieri and M. G. Salafia, “Asset Administration Shell for PLC
Representation Based on IEC 61131-3,” IEEE Access, 2020.
nication technologies. Even though memory efficiency is an [13] “Details of the Asset Administration Shell,” Plattform Industrie 4.0,
important design goal when developing embedded software, Berlin, Germany, Tech. Rep., Dec. 2019.
it was less important for this work. For example, the applied [14] C. Sünder, A. Zoitl, J. H. Christensen, V. Vyatkin, R. W. Bren-
nan, A. Valentini, L. Ferrarini, T. Strasser, J. L. Martinezlastra, and
JSON library is designed to be easy to use and integrate, with F. Auinger, “Usability and interoperability of IEC 61499 based dis-
the trade-off of worse memory efficiency. The focus for the tributed automation systems,” in IEEE International Conference on
implementation was to cover most parts of the specification, Industrial Informatics, INDIN’06, 2007.
[15] “Details of the Asset Administration Shell: Part 2,” Plattform
and the performance characteristic from the Section III is left Industrie 4.0, Berlin, Tech. Rep. [Online]. Available: https:
for the future work. However, other characteristics of the FBs //www.plattform-i40.de/PI40/Redaktion/DE/Downloads/Publikation/
for the interaction with AASs are covered by this work. Details of the Asset Administration Shell Part 2 V1.html
[16] “Creating PLCopen Compliant Libraries,” PLCopen, Tech. Rep., 2017.
The implemented FBs do not use the custom data types [17] K. H. John and M. Tiegelkamp, SPS-Programmierung mit IEC 61131-3:
of section III-B directly. All structures are flattened, so the Konzepte und Programmiersprachen, Anforderungen an Programmier-
interfaces of the FBs have variables of a structure as direct systeme, Entscheidungshilfen, 4th ed., ser. VDI-Buch, 2009.
[18] “IEC 62541 - OPC Unified Architecture,” International Electrotechnical
parameters. Furthermore, the specified HostAas, HostAsset, Commission, Geneva, CH, Standard, Oct. 2016.
and some registry FBs are not implemented. Lastly, a release [19] “I4AAS - Industrie 4.0 Asset Administration Shell,” 11.01.2019. [On-
candidate of the OPC UA Information Model for the AAS was line]. Available: https://opcfoundation.org/markets-collaboration/i4aas/
[20] “OPC 30270 - UA Companion Specification for AAS
recently published [20]. Thus, as future work, the implemen- (Release Candidate).” [Online]. Available: https://opcfoundation.
tation can be adapted to comply with it. org/developer-tools/specifications-opc-ua-information-models/
Despite some open points, this work allows a PLC runtime information-model-release-candidates-for-review/
[21] N. Lohmann, “JSON for Modern C++.” [Online]. Available: https:
system to interact directly with different AASs and registry //github.com/nlohmann/json/tree/v3.7.3#readme
component, focusing, thereby on the OPC UA communication [22] T. Berners-Lee, R. Fielding, and L. Masinter, “RFC 3986 - Uniform
paradigm, besides interacting with REST/HTTP-based AASs. Resource Identifier (URI): Generic Syntax.” [Online]. Available:
https://tools.ietf.org/html/rfc3986
The results obtained in this paper will ease interaction with [23] P. Bryan, K. Zyp, and M. Nottingham, “RFC 6901 - JavaScript Object
the complex AAS structure from the low-level devices. Notation (JSON) Pointer.” [Online]. Available: https://tools.ietf.org/
html/rfc6901
VIII. ACKNOWLEDGMENT [24] A. Lüder, M. Schleipen, N. Schmidt, J. Pfrommer, and R. Henßen, “One
This work is partly funded by the German Federal Ministry step towards an industry 4.0 component,” in 13th IEEE Conference on
Automation Science and Engineering (CASE), 2017.
of Education and Research (BMBF) through the project BaSys
4.2 (grant no. 01IS19022N).

Authorized licensed use limited to: Universidad Del Norte Biblioteca. Downloaded on December 21,2022 at 17:02:55 UTC from IEEE Xplore. Restrictions apply.