Function Blocks for the Interaction with
the Asset Administration Shell
Tarik Terzimehić
fortiss - An-Institut TU München fortiss - An-Institut TU München
Munich, Germany
terzimehic@fortiss.org
Abstract—An asset administration shell (AAS), as a key con-
cept of the Industry 4.0, provides a machine-accessible interface
to any kind of asset. An application implementing the devices
functionality should be able to interact with different AASs.
In this work, we specify the function blocks (FBs) for ac-
cessing properties and invoking operations of AASs. We ana-
lyzed the nature and requirements of such FBs while focus-
ing on REST/HTTP- and OPC UA-based AASs and provided
IEC 61499-based implementation.
The results obtained in this paper will ease interaction with
the complex AAS structure from the low-level devices.
Index Terms—Industry 4.0, IEC 61499, AAS, OPC UA, FB
I. I NTRODUCTION
Flexibility continues to gain in importance for manufactur-
ers in many domains. This is due to several reasons such as
faster changing customer expectations or more volatile global
markets. The flexibility demand increases digitalization in
production systems, as digitally available access to production
devices is a prerequisite for an automated task solving. An
example could be a production plant that is capable of auto-
matically recognizing and configuring newly installed devices.
In order to do so, the plant needs to access the new device
and to store information on it in a machine-readable format.
In the domains of Industrial Internet of Things (IIoT) and es-
pecially in Industry 4.0 the concept of an asset administration
shell (AAS) should enable this. An AAS provides a machine-
accessible interface to any kind of asset - be it an automation
device, a process description, or any other relevant entity. An
AAS might contain administration data, runtime information,
or even executable operations of a device.
Primarily, an AAS enables a machine to machine interaction
with an asset. This is relevant both on an Enterprise Resource
Planning (ERP) level, as well as, on the level of the devices
itself. Here, a component might want to retrieve status infor-
mation about its neighbor component or some environment
information from the working cell it is contained in.
To achieve this, the application implementing the device
functionality needs to connect to AASs and interact with
them. As a function block (FB) is the basic building element
of automation applications according to the IEC 61131-3
This work is partly funded by the German Federal Ministry of Education
and Research (BMBF) through the projects BaSys 4.0 (grant no. 01IS16022)
and BaSys 4.2 (grant no. 01IS19022N).
978-1-7281-0303-7/19/$31.00 ©2019 IEEE
Authorized licensed use limited to: Universidad Del Norte Biblioteca. Downloaded on December 21,2022 at 16:59:35 UTC from IEEE Xplore. Restrictions apply.
Andreas Bayha Kirill Dorofeev
fortiss - An-Institut TU München
Munich, Germany Munich, Germany
bayha@fortiss.org dorofeev@fortiss.org
and IEC 61499 standards for programming automation and
control systems [1], [2], there is a need to define FBs for the
interaction with AASs.
In scope of the BaSys 4.0 project1 , Kaspar et al. [3]
proposed the application of OPC UA Programs based on the
PLCopen FBs to achieve implementation independent control
of distributed heterogeneous devices. In this work, we present
the first specification of FBs for reading/writing properties and
invoking operations of AASs.
II. BACKGROUND
In this section we establish the context and background of
the topic by briefly explaining the structure of an AAS and
the nature of control applications in industrial automation.
A. Details of the Asset Administration Shell
Plants often comprise components from different vendors.
To enjoy all the benefits of the AAS concept in practice,
various AASs from different vendors should be compatible.
This compatibility requires a vendor-independent standard.
The German network Platform Industry 4.0 recently pub-
lished a proposal on how to uniformly structure an AAS [4].
Within our work, we use this proposal as a baseline for
defining AASs’ elements and their relations among each other.
Figure 1 shows a simplified metamodel of an AAS2 . An AAS
consists of submodels that contain properties and operations.
All the entities here inherit an idShort from Referable. Via this,
AASs, submodels and SubmodelElements can be referred to.
B. Control Applications in Industrial Automation
The IEC 61131-3 standard [1] for programming automation
and control systems was first released in 1993 by the IEC
and last updated in 2013. It describes textual and graphical
programming languages for Programmable Logic Controller
(PLC) applications. One of these languages is the Function
Block Diagram (FBD). Its graphical syntax consists of FBs
that encapsulate functionality consuming certain input signals
and producing output signals. By connecting FBs via those
input and output signals, PLC applications can be composed.
1 https://www.basys40.de
2 The original metamodel comprises more interfaces and members. How-
ever, we focus on properties and operations, as it is more likely to access
those kinds of submodel elements from low-level devices.
1235

AssetAdministrationShell <<abstract>>
Referable
0..*
+ idShort : string [0..1]
Submodel
0..*
<<abstract>>
SubmodelElement
<<abstract>>
DataElement Operation
+ in : OperationVariable [0..*]
+ out : OperationVariable [0..*]
Property
+ value : PropertyValueType [0..1]
+ valueType : anySimpleTypeDef
Fig. 1: Simplified metamodel of the AAS’s structure from [4].
The IEC 61499 standard [2], which is based on the
IEC 61131-3, also provides a graphical notation using FBs.
The difference to IEC 61131-3 is, among others, the event-
based execution semantics. The IEC 61499 FBs contains
event input and output signals besides data signals. An FB
is executed only if it receives a trigger event. It might also
emit events that again can trigger other FBs.
III. R ELATED W ORK
Several attempts have been made toward realizing an inter-
action mechanism between an Industry 4.0-component (I4.0-
component) and its AAS. Tantik et al. [5] describe an im-
plementation of a flexible AAS, concentrating on the require-
ments for automated access, components hierarchy, storage of
the product life cycle data, and flexibility. The proposed archi-
tecture, however, uses a REST interface as a communication
layer, which is uncommon in legacy production systems. This
makes it hard to apply in the brownfield.
In [6], the authors present an AAS implementation using
existing standardized technologies, such as OPC UA and
AutomationML3 . Additionally, the IEC 61131-3 application of
an I4.0-component is made available by means of PLCOpen
information model4 . However, this work lacks a mechanism
for an I4.0-component itself to interact directly with AASs.
Wenger et al. [7] use XQuery requests to establish an
interaction between an I4.0-component and an AAS. To form
an XQuery request from the PLC, the application side requires
detailed knowledge about the structure of the information
model that forms the AAS. The more complex the AAS
information structure is, the larger the XQuery requests get.
In this work, we specify technology-independent FBs that
allow an I4.0-component to interact directly with different
AASs. While demonstrating the FBs applicability, we focus
on the OPC UA communication paradigm, besides interacting
with REST/HTTP-based AASs.
3 https://www.automationml.org
4 https://opcfoundation.org/developer-tools/specifications-unified-
architecture/opc-unified-architecture-plcopen-information-model/
1236
Authorized licensed use limited to: Universidad Del Norte Biblioteca. Downloaded on December 21,2022 at 16:59:35 UTC from IEEE Xplore. Restrictions apply.
IV. F UNCTION B LOCKS FOR ACCESSING THE AAS
FBs are a common way of abstracting the rising complexity
of current control applications [8], [9]. FB programming is one
of five programming methods specified by the IEC 61131-3
standard, whereas in the IEC 61499 standard, FBs are main
building blocks of control applications [10].
To interact with an AAS from the PLC control application,
a PLC programmer has to take care about different communi-
cation protocols and the quite complex structure of the AAS
(see for example [4]). In this section, we first describe the
nature and requirements of the FBs for interacting with AAS.
Furthermore, we introduce FBs for reading and writing data
elements within specified submodels of the AAS, as well as,
an FB for invoking an operation.
A. Nature of the Function Blocks for Accessing the AAS
FBs interacting with the AAS are a kind of more complex
communication FBs containing state machines (as it is simi-
larly proposed for OPC UA FBs in PLCOpen). Defining the
FBs for interacting with AAS requires consideration of certain
characteristics and requirements.
Portability: The FBs interface should be implementation-
and runtime environment (RTE)-independent to abstract itself
from the technology specifics. Furthermore, the FBs should
be communication-independent: the FB interface should be
the same no matter which communication protocol is used
for communicating with the AAS. Those agnostic client FBs
might contain communication parameters, such as ”opcua”,
”http”, etc., to distinguish different technologies. On the exam-
ple of a REST/HTTP-based AAS, the JSON parsing should be
hidden from the user. However, utility FBs for JSON parsing
might be provided (as well as, some other auxiliary FBs).
Usability: A user (a PLC programmer) writes only the AAS,
submodel and data element IDs; all other things should happen
in the background (queries, IP settings, etc.). Moreover, to
reuse the domain knowledge, the FBs’ specification should be
aligned to the PLCOpen OPC UA FB’s specification by using
similar variables (Busy, Done, Error, etc. ) and state machines.
Interoperability: A standardized FB library requires a fixed
and standardized AAS structure. Also, standard error codes
should be defined. The FB concept should be similar for both
IEC 61131-3- and IEC 61499-based applications.
Performance: Interaction with AAS should not jeopardize
the real-time characteristics of the control application. This
is especially important as the AASs can be implemented
with different technologies and underlying communication
infrastructure might lack real-time capability.
Client & server functionalities: Client functionality is
more important for PLC level as it is more likely that the
AAS is created with some high-level languages and hosted
outside of memory-limited PLCs. However, FBs for server
functionality, i.e., hosting an AAS within PLC, should be also
considered. For client functionality we need a way to read and
write from/into an AAS (e.g., via REST/HTTP interface); for
server functionality we have to be able to store AAS. We have
to be sure that AAS is reachable even in case of device failure operation is finished and that the result is available on the data
(e.g., through back ups). output Result. Providing confirmation and indication events
High-level & low-level APIs: Depending on the use case, allows us to create a non-blocking application: after triggering
there is a need for low-level, as well as, high-level FBs. For an operation, the application can process further FBs without
example, sometimes we solely want to read a value of a certain waiting for the operation completion.
property, whereas in particular cases we need to read the whole
Event INIT INITO Event
JSON string of a property or even to load a whole submodel. Event INIT INITO Event
Event GET CNF Event Event INVOKE CNF Event
ERROR Event IND Event
B. Function Block Library for the Interaction with the AAS getDataElement ERROR Event
STRING AasPath ErrorId DWORD invokeOperation
In this paper, we specify FBs for reading and writing STRING SubmodelId Value ANY STRING AasPath ErrorId DWORD
STRING DataElementId Type STRING STRING SubmodelId Result ANY
data elements, more precisely properties, as well as, FBs for STRING CommId Timer STRING OperationId Timer
invoking operations from an AAS, as those atomic operations STRING CommId
Event INIT INITO Event ANY Parameter1
are more likely on the low-level PLC. In future work, we Event SET CNF Event ANY Parameter2
ERROR Event
will tackle the possibility that a PLC hosts the whole AAS or ...
setDataElement
some of its submodels by using specific FBs, e.g., for creating STRING AasPath ErrorId DWORD
STRING SubmodelId Timer Event TimeOut START Event
a submodel, a data element, etc. STRING DataElementId STOP Event
We will align to the PLCOpen concept of OPC UA FBs STRING CommId ATimeOut
STRING Value DT TIME
to reuse the domain knowledge of application engineers:
less effort needed to create an FBs application. We focus Fig. 2: FBs for reading and writing a data element, as well as,
on the event-based nature of the IEC 61499-based control invoking an operation from the specified AAS
application as they better fit the (desired) nature of the FBs
for interaction with AAS. For example, IEC 61499-based
V. VALIDATION
FB enhances encapsulation, abstraction, interoperability and
portability aspects of control applications [2], [11]. However, In this section, we describe an implementation of FBs
this FB concept can be easily applied to IEC 61131-3 FBs. introduced in the section IV and evaluate their applicability
Figure 2 illustrates those FBs. An FB for reading a data on a cold rolling mill demonstrator.
element is shown in the upper left part of the figure. Besides A. Demonstrator
standard initialization input and output events (INIT and INITO
This work focuses on the pallet transportation system (PTS)
events), this FB contains a GET input event that triggers
within a cold rolling mill. The aluminum is provided on a
reading a data element from the AAS located on the path
coil, whereas pallets are used for the safe transportation of
given by the AasPath data input. The input data elements
a coil and to prevent improper motion, such as rolling away
SubmodelId and DataElementId determine the precise location
and unrolling. The PTS transports empty and loaded palettes
of the data element while respecting the AAS structure briefly
between the different working stations within the plant. The
described in the section II-A. Data input CommId specifies the
roller conveyors perform the entire transportation task [12].
communication protocol used to access the AAS. To avoid
An AAS of a roller conveyor contains several different sub-
waiting for a confirmation event infinitely (e.g., in case a
models, such as (1) a submodel with initialization parameters
communication connection is broken), an ATimeOut adapter
(e.g., maximal velocity of the conveyor), (2) a topology sub-
interface is used to specify reading timeout. When reading
model containing information about neighbouring conveyors
the data element is finished, the FB generates a confirmation
and providing operation for calculating the shortest transporta-
output event CNF and provides a data element value and type
tion paths within PTS, and (3) a submodel containing status
on the Result and Type data outputs, respectively. In case of
variables and state machines (e.g., PackML state machine).
an error, an ERROR event is generated. The nature of the error
is given by an ErrorId data output. B. AAS Implementation
The FB for writing a data element (the lower left part of We created two implementations of a roller conveyor’s AAS
Fig. 2) is similar to the one for reading. An input event SET following the AAS structure defined in [4]. We created one
triggers writing the value given by the data input Value into the AAS in REST/HTTP by using Eclipse BaSyx framework5 .
data element specified by AasPath, SubmodelId and DataEle- As the mapping of the AAS structure from [4] to the OPC
mentId data inputs. Once the writing process is finished, a UA is still unavailable (but an ongoing work of the Plattform
CNF output event is generated. Industrie 4.0), we propose an initial mapping by using the
Invoking an operation from a particular submodel is possible UaModeler tool from Unified Automation.
by using an FB shown in the upper right part of Fig. 2. To Figure 3 depicts a basic AAS object type BaSysAssetAd-
trigger an operation specified by data inputs, the control ap- ministrationShellType with its components, as well as, its
plication provides necessary operation parameters (data inputs subtype ConveyorAssetAdministrationShellType representing a
Parameter1, Parameter2, etc.) and triggers the INVOKE input conveyor specific AAS object type.
event. The CNF output event confirms that the invocation
has started, whereas the IND event indicates that the invoked 5 https://projects.eclipse.org/projects/technology.basyx

1237

Authorized licensed use limited to: Universidad Del Norte Biblioteca. Downloaded on December 21,2022 at 16:59:35 UTC from IEEE Xplore. Restrictions apply.

Fig. 3: Browsing AAS information model
C. Evaluation of the FBs on Different Use Cases
We implemented the FBs described in the section IV by
using Eclipse 4diac [13]. Figure 4 shows the FBs for reading
and writing data elements interacting with the control appli-
cation of a roller conveyor. To demonstrate communication
independence, we read the data element (maximal velocity)
from the OPC UA AAS and write the conveyor’s status value
into REST/HTTP AAS. Part of the FB for reading the REST-
specific information is shown in Fig. 5. Here, we see the
application of the utility FB for JSON parsing.
Fig. 4: Applying generic F Bs to read and write data elements
within REST/HTTP- and OPC UA-based submodels
VI. C ONCLUSION & F UTURE W ORK
In this paper, we specified the FBs for interaction with AAS
from PLC. First, we analyzed the nature and requirements of
1238
Authorized licensed use limited to: Universidad Del Norte Biblioteca. Downloaded on December 21,2022 at 16:59:35 UTC from IEEE Xplore. Restrictions apply.
Powered by TCPDF (www.tcpdf.org)
Fig. 5: Part of the FB for reading a REST-based data element
such FBs. Second, we specified the FBs’ interface. Further-
more, we mapped the AAS structure from [4] into an OPC
UA information model to exhibit the FBs’ applicability on
OPC UA- and REST/HTTP-based AASs.
A further study could try the specified FBs with other com-
munication protocols, such as TCP/IP and MQTT. However,
this requires specifying AAS models for those technologies.
This work focuses on the client side of the interaction
with AAS: accessing already available data elements and
operations within an AAS. It would be interesting to specify
FBs that handle the server side of the interaction with AAS
by providing the possibility to host an AAS on a PLC.
The presented FBs allow an eased interaction with the
complex AAS structure from the low-level programmed PLCs.
R EFERENCES
[1] I. SC65B, “IEC 61131-3 Programmable Controllers. Part 3: Program-
ming languages,” 2003.
[2] ——, “IEC 61499-1 Function Blocks for Industrial Process Measure-
ment and Control Systems. Part 1: Architecture,” 2005.
[3] M. Kaspar, J. Bock, Y. Kogan, P. Venet, M. Weser, and U. E. Zimmer-
mann, “Tool and technology independent function interfaces by using a
generic opc ua representation,” in IEEE 23rd International Conference
on Emerging Technologies and Factory Automation (ETFA), 2018.
[4] “Details of the Asset Administration Shell,” Plattform Industrie 4.0,
Berlin, Germany, Tech. Rep., Dec. 2018.
[5] E. Tantik and R. Anderl, “Integrated data model and structure for the
asset administration shell in industrie 4.0,” Procedia CIRP, 2017.
[6] A. Lüder, M. Schleipen, N. Schmidt, J. Pfrommer, and R. Henßen, “One
step towards an industry 4.0 component,” in 13th IEEE Conference on
Automation Science and Engineering (CASE), 2017.
[7] M. Wenger, A. Zoitl, and M. Thorsten, “Connecting PLCs with their
Asset Administration Shell for Automatic Device Configuration,” in
IEEE International Conference on Industrial Informatics (INDIN), 2018.
[8] F. Serna, C. Catalan, A. Blesa, and J. M. Rams, “Design patterns for
Failure Management in IEC 61499 Function Blocks.” in 15th IEEE
Conference on Emerging Technologies & Factory Automation, 2010.
[9] G. D. Shaw, P. S. Roop, and P. Z. Salcic, “A hierarchical and concurrent
approach for IEC 61499 function blocks,” in IEEE Conference on
Emerging Technologies & Factory Automation (ETFA), 2009.
[10] C. Sünder, A. Zoitl, J. H. Christensen, V. Vyatkin, R. W. Bren-
nan, A. Valentini, L. Ferrarini, T. Strasser, J. L. Martinezlastra, and
F. Auinger, “Usability and interoperability of IEC 61499 based dis-
tributed automation systems,” in IEEE International Conference on
Industrial Informatics, INDIN’06, 2007.
[11] W. Dai, V. Vyatkin, and J. H. Christensen, “The application of service-
oriented architectures in distributed automation systems,” in IEEE Int.
Conference on Robotics and Automation (ICRA), 2014.
[12] T. Terzimehić, M. Wenger, A. Zoitl, A. Bayha, K. Becker, T. Müller,
and H. Schauerte, “Towards an industry 4.0 compliant control software
architecture Using IEC 61499 & OPC UA,” in IEEE Int. Conference on
Emerging Technologies and Factory Automation, ETFA, 2017.
[13] T. Strasser, A. Zoitl, and A. Valentini, “Framework for Distributed
Industrial Automation and Control (4DIAC),” in 6th IEEE Int. Conf.
on Industrial Informatics, 2008.