Industrial Controls and Asset Administration Shells:

An Approach to the Synchronization of Plant Segments

Stephan Sch

¨

afer

1

, Dirk Sch

¨

ottke

1

, Thomas K

and Bernd Tauber

2

1

Hochschule f

ur Technik und Wirtschaft (HTW) Berlin, Berlin, Germany

The complexity of modular production plants is constantly increasing due to flexible functionalities. The need

to be able to flexibly adjust processes to product requirements is thus becoming more relevant. Therefore,

limiting production plants to their processes is no longer up-to-date and a division of processes into single,

atomic capabilities, which are represented by a Asset Administration Shell (AAS), has proven to be useful.

This article deals with the synchronization of individual capabilities at the field level via the use of the PackML

State Machine. An approach is presented how individual capabilities can be combined into a composite

capability using a higher-level state machine. This approach is similar to the group or control component

presented in BaSyx. To be able to represent the data in the AAS, the PackML does not offer a direct interface.

This is created via a template in the control layer to be able to represent data in the AAS. This allows the AAS

to read data in one structure and independently manipulate parameters in another structure in a non-real-time

the components used, their scalability, their interac-

tion within the systems, and the system-wide com-

munication. Software solutions in the environment of

automation systems, among other things, have a ma-

jor influence on the flexibility and complexity of the

plant. With them, plants can be flexibly configured to

the respective application case.

Here, the interoperability and scalability of the

systems represent a significant challenge. Among

other things, the reference architecture model (RAMI)

machines, products or controllers are considered as

assets. AAS consist of several submodels in which in-

formation and functionalities of an object, and other

the AAS includes documents, properties, parameters,

and other functions (Kuhn et al., 2020). The AAS

thus becomes a provider of bookable services, which

can be synchronized via a coordinator, for example.

For the use of the available services with their

characteristics, their secure booking in and out of the

plant network and a comprehensible process control

nizing processes.

The aspects mentioned (convertibility, interoper-

ability, synchronization of processes) give rise to the

question of how these can be harmonized with exist-

ing systems and their use, for example. A large num-

ber of different industrial controllers are established

in the industrial environment. They can communi-

cate via a variety of field buses. This already results

in a need for adaptation for further processing of the

information. This adaptation can be compensated to

since information is provided here via a standardized

interface.

In new plants, this can already be taken into account

during the conception/design of the plant, but in ex-

isting plants this is essentially only possible during

migration or with adaptation of the project planning.

Currently, industrial control systems do not offer the

tomates individual processes, but also realizes net-

works of plant components. These can be coordi-

nated/synchronized inside or outside the control sys-

tem. Both approaches can usefully complement each

other and are well established. If synchronization

takes place at the level of the industrial controller, the

end-to-end consistency of the data must also be en-

sured in the associated AAS, i.e., its digital represen-

tative. This applies not only to the relevant data for

synchronizing the processes, but also to supplemen-

Codesys - platform) for synchronization and the inte-

gration of the data model into the assigned AAS struc-

ture.

2 INDUSTRIAL CONTROLS AND

Controls/automation devices, with their control pro-

grams according to IEC 61131-3, are assigned to the

lowest level of the RAMI. They represent a close rela-

tionship to the operating equipment of the production

plants/systems (Cavalieri and Salafia, 2020). This re-

relationships to neighboring systems/items. On the

other hand, breaks in the consistent preparation, stor-

age and use of information exist in the engineering

phase. In addition, there is currently no ”established

procedure method” for integrating inventory solutions

with industrial controls in I4.0 system environments,

but rather a variety of proprietary solution methods.

Some deficiencies can be compensated for in the con-

text of using Basys 4.0 middleware (Adolph et al.,

2020).

Reducing the deficits mentioned requires a me-

thodical approach in order to be able to generate as

much added value as possible from the available data.

eling of a reference plant (pick & place station) with

its components was shown. The modeling of capa-

bilities as submodels was also discussed here. The

migration/transfer of existing plants, in their overall

constellation or in sub-areas, to I4.0 environments, for

example, represents a different situation and a chal-

lenge here. Further approaches of reference imple-

mentations are discussed in (Belyaev et al., 2021) and

(Di Orio et al., 2019).

The construction of modular and changeable plants

requires capability-based manufacturing systems. A

distinction can be made between ”atomic” and ”com-

plex process that can be managed by a higher-level

unit.

For the synchronization of processes BaSys 4.2 pro-

poses a ”Control Component” (Grothoff et al., 2021).

state machine. Each process can be controlled uni-

a state machine.The control component has a signif-

icant influence on the use of components here. This

concerns not only the operation, but also the commis-

sioning and the possible component exchange. It en-

ables subsequent tasks in a changeable environment

(Gr

¨

uner et al., 2021):

component level, or composite component level

components, these can be brought into defined

of a component. By selecting an operation mode,

the user of a component specifies what the com-

ponent should do.

Figure 2: Syntax of the PackML SM (OMAC, 2009).

takes into account the operating modes ”Production,

Maintenance and Manual”. These can be supple-

mented by the user (ISA, 2015; Mu

ˇ

si

each operation mode can have a maximum of 17

states. These are divided into three categories. The

Wait-States, with which it is to be signaled that a cer-

tain condition of the plant was reached. The Acting-

States, in which different activities can be executed

defined states, PackTags were introduced to pass ma-

chine data to IT systems. This means that PackML

state machines can also be controlled by higher-level

or neighboring systems.

Companies benefit from this established stan-

dard, which is now widely used in the packaging in-

dustry (Dorofeev and Zoitl, 2018). This results from

the fact that PackML state machine makes applica-

tions more efficient, flexible and reusable. Commis-

sioning also becomes less costly and interoperability

3 USE CASE AND ASSET

the existing plant to an I4.0-based solution is the re-

producibility of the available plant description and the

implemented programs.

In our application, products, in this case high-

quality thermal switches, are tested in an industrial

environment during production or after the manufac-

turing process. In this environment, each product

passes through predefined test scenarios. The prod-

ucts are placed on a special pallet carrier and made

available to the respective processes. The required

was a discussion of a possible migration of plant com-

ponents using AAS. The analysis of the environment

of the test station of thermoswitches and their compo-

nents showed that a variety of processes, starting with

the preparation of the test specimens, their provision,

the transfer and other processes must be included.

The automation of the stock was carried out with

heterogeneous instrumentation (see Figure 5), start-

ing with the use of programmable logic controllers

(PLC) from different manufacturers and ending with

ing synchronization and coordination of the processes

is required. This can be achieved, for example, by

establishing control components at the AAS level or

by using a PackML state machine implemented at the

ous communication protocols can be used in this plat-

form(Rayment, 2004). However, there are no solu-

tions that allow simple integration into an I4.0 envi-

ronment and its synchronization via AAS.

The challenge is thus the effort-reduced realiza-

tion of a digital representative as I4.0 components and

their integration (Koulamas and Kalogeras, 2018).

These can be mapped in the form of a AAS. Here,

a distinction is made between three types of AAS

based on a uniform information metamodel (Beden-

Figure 5: Instrumentation - initial situation.

with asset description. Type 2 represents a reactive

form, which includes a communication channel in ad-

dition to the asset description. Only the proactive

AAS of type 3 enables an independent communica-

pects.

The discussion of the use case resulted in the ne-

cessity of both migrating the inventory of industrial

controllers to the future environment and implement-

ing their representation in the form of AAS with re-

duced effort. With the implementation of PackML on

the controllers and various extensions, which enable

a similar range of functions as the control component,

a number of advantages result from the step-by-step

migration. These include, for example, the booking

possibility of equalizing the migration over time.

The SDK BaSyx 4.2 (Platform, 2021) was used

in the ”OpenBasys 4.0” project (BMBF, 2019) to im-

plement the representative. It offers the possibility to

realize Asset Administration Shells in different pro-

gramming environments. The project engineering of

Asset Administration Shells with SDKs can be done

manually according to the general description of the

Figure 7: Structure Unit (aUnitInfo and aUnitController) (Sch

¨

afer et al., 2022).

In the project, the online variant was implemented,

which prepares its own structure in the global variable

list (GVL) for the application. Among other things,

the PackML state machine (SM) data (including the

details of used plant components) and the process data

from the process controller (PLC) are transferred. Us-

ing the approach resulted in the infrastructure of the

migrated plant shown in Figure 6. Each controller

Figure 8: Structure ”Process” with its elements (Sch

afer

et al., 2022).

that a solution be found/established that allows en-

gineering data to be integrated efficiently and effec-

tively into the Asset Administration Shell. This ap-

plies not only to the design of new plants, but also to

existing automation solutions. In addition to the tech-

nical description, information from the process events

and their respective status must also be assigned to the

engineering data. For their representation, tags are

embedded in the realized system environment, which

the respective target systems. For supplementary and

specific information from the plant area/processes, an

extended global variable list (Process) is available to

the user for use. Both types of global variable lists are

considered in the automatic generation of the Asset

Administration Shell in the form of submodels with

their properties. In addition, the information is pre-

pared in an associated GUI (FrontEnd) for further use

with any end devices. The structure aUnitController

is used to control and parameterize the master SM and

subordinate machine units (Units).

Units can be, for example, a linear axis or a

able. Changes can be made both by external process

control via the OPC UA interface of the controller and

by internally programmed process control. In the Ele-

mentOfUnitController structure, the parameterization

of the unit and its elements is to be carried out. While

the aforementioned structure has a controlling char-

acter, in the structure aUnitInfo the state of the units

and their elements (incl. the description of the plant

components) is mapped. OPC UA clients have read-

only access to this structure. ActMode and ActState

Control structure. Whereby only the ElementOfPro-

cessControl area can be used for manipulation via an

OPC UA client or the associated AAS.

5 ADDITION OF PROCESS

One of the requirements for the generic generation of

a AAS type 2 is the existence of an asset description

as AAS type 1 (see Fig. 9) with the submodels (SM)

Schneider Electric, as well as solutions based on

firmware from Codesys were essentially used. Dur-

ing the generation process, the structures stored in the

global variable list are assigned to the relevant sub-

models. So that after the generation process one of

the following structures results. The above structures

(Unit, Process) can be transferred selectively or to-

gether into the new asset structure. (cf. Fig.9) For

the generator, it is in principle of secondary impor-

tance whether this is a controller, an edge controller

or other automation device, since the submodels are

created and assigned after successful identification on

the basis of the OPC UA data structure. With the des-

Figure 9: AAS - Supplement with SM ”Unit” (Sch

2022).

to the AAS. This simplifies the integration and ex-

change of system components in the plant operator’s

I4.0 system environment.

6 REQUIREMENT FOR