At the beginning of 2016, the ZVEI and the Chair of Process Control Engineering at RWTH Aachen University launched the 'openAAS' (open Asset Administration Shell) project, which will run for two years. The project is intended to support the concept of the administration shell with a practical implementation in order to create a basis for further discussions and identify possible specification gaps.

A steering committee consisting of representatives from ZVEI member companies supports the chair and decides on the course of the project, its implementation and the next milestones. In addition, openAAS is intended to synchronize the work of the various associations' working groups and create a basis for stimulating further developments.

The project is special in that development is open. In concrete terms, this means that both specifications and written source code are available to all interested parties on Github. In addition, workshops are being held for developers who are involved in the practical implementation of the administration shell. It is hoped that this will provide direct feedback on the progress of the project.

The project goals

The project has two main objectives: The design and selection of models for the administration shell and the actual implementation. In other words, there is a breakthrough from the conceptual level through to implementation. As the model was specified in a technology-neutral way, it can be implemented with various technologies available on the market. In openAAS, the initial focus was on OPC UA, as it is considered a promising technology that provides the basis for secure communication (encryption, authentication) and also offers the possibility of information modeling.

Specifically, the models developed in openAAS were implemented on the basis of the free OPC UA stack open62541. This ensures the openness of the solution and interested parties can reproduce the work and reuse it if necessary. After the first part of the project focused on the adaptation and development of individual model elements (features, life cycle, communication), the second part focuses on concrete implementation.

The asset administration shell is a concept that the automation industry has been discussing since 2015. It makes it possible to manage the life cycle of any individual object that represents an asset for a company.

Concept of the administration shells

Industry 4.0 components consist of an asset administration shell and an asset and offer a standardized service interface for communication.

© RWTH Aachen

The concept of the asset administration shell can be applied to assets that can be both tangible (a sensor, a motor) and intangible (a plan, a recipe).

This means that the company considers the individual asset to be so important that it makes sense to document the life cycle of this asset. For example, it may be less important for a screw manufacturer to track the life cycle of a single simple screw. The screw type, on the other hand, which records how a screw can be produced with its design and manufacturing plans, represents a value for a company that can be managed via a shell. The advantage of using the asset administration shell is that a wide variety of assets can be managed and interacted with in the same way. Together with the asset, the asset administration shell represents the Industry 4.0 component.

What do they contain?

At its core, the asset administration shell is a narrow, generic interface that can be expanded using so-called submodels. It is therefore not possible to clearly state that something is localized 'in' the asset administration shell; rather, the asset administration shell is an access point that can be identified by its globally unique ID. The asset administration shell thus encapsulates the internal structure to the outside via a service interface. Current discussions revolve around which functionalities can be implemented via the asset administration shell. In principle, it is undisputed that the asset administration shell provides administrative information and functions that can be accessed via services.

Where are they located?

In principle, there are various options as to where the asset administration shell data is stored. On the one hand, in a repository, which is characterized by the fact that it is highly available and independent of the current communication properties of the asset. On the other hand, it is possible to store the asset administration shell on the asset itself. This is conceivable, for example, with intelligent field devices that have the corresponding communication and storage capability. When considering the different approaches, it is also important to consider which information and which functions are to be provided with the asset administration shell.

The openAAS project assumes that asset administration shells are stored in a company repository so that administration information is also available at times when an asset is not integrated into the network - for example, because it is currently undergoing maintenance.

Who owns it?

In line with the assumption that administration shells are not located on the asset itself, the project stipulates that entire administration shells are not exchanged between different organizations, but only individual pieces of information regulated by contract. This in turn also means that several asset administration shells can relate to the same object. It can therefore be assumed that each organizational unit creates and maintains its own administration shell with the information required for administration.

Information and features

Characteristics are a central concept that is also used in the modeling of asset administration shells. Characteristics and the attribute statements assigned to them can be used to uniquely describe a situation - whereby the characteristic definitions are made within a repository. An example of a feature repository is ecl@ss. However, it is to be expected that the scope will have to be significantly expanded, as the ecl@ss catalog currently only covers product characteristics.

Each characteristic statement refers to a definition with a unique ID. In the context of Industry 4.0, two types of ID are preferred: either a URI (Uniform Resource Identifier) or an identifier in accordance with ISO 29002-5 is used. The management of an asset also includes the documentation of life cycle events. For example, operating behavior, maintenance tasks or communication accesses can be logged. Archiving is the basis for data-based services such as predictive maintenance and operational optimization.

Within openAAS, a distinction is made between three basic communication patterns that differ in their semantics: message transport, model interaction and n:n communication for the exchange of mass data.

Patterns of communication

The communication patterns of the administration shell

© RWTH Aachen

Message transport: Together with their assets, the asset administration shells represent independent components that provide services and can be addressed via their unique ID. The project assumes that asset administration shells only need to know the access point to the network in order to communicate with other asset administration shells. This is represented by an infrastructure component. The network infrastructure is thus completely encapsulated for the administration shell. This results in a clear dividing line between the asset administration shell and the communication technology used. The administration shell has a kind of mailbox for receiving messages, such as service requests or service responses. The administration shell itself is responsible for processing the messages within this mailbox.

Model interaction: In contrast to message transport, the administration shell is not the addressee of the request in model interaction, but the system in which the administration shell is embedded. In openAAS, this access is used in particular when engineering the asset administration shell; for example, basic structures can be created in the target system.

Mass data: If necessary, it can be useful to collect current statuses from various sources in the asset administration shell or to make them available to other participants. This means that n:n communication is necessary. The publisher/subscriber pattern has proven itself for this type of communication.

At Hannover Messe 2017, the Industry 4.0 demonstrator, which was already on show at the IT Summit 2015 and HMI 2016, was equipped with the latest software version of openAAS to demonstrate various use cases. Among other things, the 'Live Analytics' use case showed how diagnostic sensors can be flexibly integrated into existing systems and how data collected in this way can be made available in the administration shell.

Visitors were also able to see how the administration shell can be used to implement the Plug'n'Produce approach. The demonstrator was the first time that the functionality of openAAS was tested in an industrial environment and presented to a wide audience.

Author:
Florian Palm is a research assistant at the Chair of Process Control Engineering at RWTH Aachen University.