Difference between revisions of "BaSyx / Documentation / AssetAdministrationShell"

Revision as of 09:06, 29 July 2019

Asset Administration Shells exist for Products, Resources (e.g. devices), and processes

Asset administration shells (AAS) are one main concept of Industrie 4.0 for providing information hiding and higher levels of abstraction for assets. An AAS has a unique identifier and contains sub-models. Sub-models define properties and services, and implement a reflexive interface. They provide high-level information, e.g. regarding offered services of assets, asset status models, or plant topology models. An Asset Administration Shell provides information about Industrie 4.0 assets, and a generic interface to an Industrie 4.0 asset. They turn Assets into digitally manageable assets. Every Industrie 4.0 asset has an Asset Administration Shell that provides access to properties, services, and informs about events. AAS exist for physical and non-physical entities; consequently, devices, workers, products, but also processes may have Asset Administration Shells. An Asset Administration Shell provides properties and operations, and is able to signal changing conditions with events. An AAS defines a generic interface that enables accessing properties, operations, and events. Asset Administration Shells therefore define unified interfaces to heterogeneous entities.

Accessing Asset Administration Shells

AAS communication

Every AAS communicates via a HTTP/REST interface that implements the BaSys Industrie 4.0 communication API

An Asset Administration Shell is accessible via Industrie 4.0 compliant communication. For BaSys 4.0 and Eclipse BaSyx, all AAS are accessible at least via a defined HTTP/REST interface. However, individual AAS may provide additional means of communication, to support for example high throughput communication or required protocols for specific contexts.

AAS layers

Common layers of an AAS include access to AAS specific functions, but also generic access to operations and properties, as well as communication

The AAS turns an entity into a manageable Industrie 4.0 component. It is the logic representation of an Asset in the digital world. In addition to the common AAS interface, an AAS may implement a specific, asset specific API that eases access to Asset Data and services. The AAS provides access to the entirety of information regarding an Asset. The AAS itself provides generic information, AAS sub model provide more detailed. An Asset Administration Shell enumerates AAS sub models and provides access to them. Asset Administration Shells resemble the communication abilities of the underlying asset. Assets may be active or passive, and therefore, AAS may be active or passive entities as well.

We distinguish between type and instance AAS. A type AAS represents a specific type with common properties, e.g. a device type, which could be a specific type of robot. Instance AAS represent one instance, e.g. one specific robot. Every Industrie 4.0 entity is uniquely represented by its Asset Administration Shell, and therefore each AAS must be identifiable by an unique identifier.

AAS sub models

An Asset Administration Shell usually contains numerous sub models that focus on specific data

Asset Administration Shells provide access to meta information about the Industrie 4.0 asset that they represent, and they provide access to sub models. The same asset administration shell may provide access to numerous sub models. Sub models provides access to a focused set of data. This may be physical data, the weight and size of assets, dynamic data, e.g. the availability of spare parts, and live data regarding the condition of a device. AAS sub models may as well export operations that enable, for example, the controlling of a device.

AAS and sub models interfaces

AAS and sub models structure information in a tree of properties

An AAS uses a strict, and coherent format, that organizes all contained information as tree of properties. The same format is used for structuring of sub model properties. AAS and sub models define a unified API for accessing AAS information, as well as information in AAS sub models. The concrete API for accessing the AAS and its sub models is described here.

An Asset Administration Shell and its sub models may be distributed through the system. While the AAS resides for example on a server to ensure its presence in case of device failures, sub models may be deployed to the physical device. If the sub model provides access to frequently changing data, its deployment to the device may be the best solution, as otherwise a steady stream of data needs to be transmitted from the device to the sub model location. The distributed AAS approach enables the use of AAS and sub models as decentral data storage and unified interface to data sources. Static data, databases, and tools may be equipped with a sub model interface to provide various kinds of data as AAS sub models.

Asset Administration Shell based BaSyx architecture examples

BaSys 4.0 conforming Industrie 4.0 production systems consist of production assets (devices, workers, products), as well as apps, a registry, as well as AAS and sub model providers. AAS and sub models realize unified interfaces to assets and to different kinds of data and data sources. Several hosts may implement sub model providers; some providers for example persist AAS and sub model data in databases, other providers only offer volatile data.

The example illustrates a simple BaSys 4.0 architecture. It illustrates the main components of a BaSys 4.0 deployment. The directory registers AAS and provides access to registered Asset Administration Shells and their sub models. Smart devices natively support Asset Administration Shells. They register their Asset Administration Shells autonomously with the directory. Applications, in the shown example a dashboard application, access AAS sub models to receive data from the shopfloor. They also set property values and invoke sub model operations to control the production. Live data updates for sub models are provided by the smart device itself in this example.

The second scenario differs from the first scenario in one aspect: the integrated device is not a smart device, but a legacy device that supports no Industrie 4.0 communication. An explicit device manager registers the AAS and sub models of the device with the directory of the BaSys middleware, communicates with the device using native protocols, and pushes data into sub models of its device.

Asset Administration Shell Meta Model

The AAS meta model defines relevant types as classes, inter-class relationships, properties of the Asset Administration Shell, and related types, e.g. sub models. Source: Details of the Asset Administration Shell, Part 1

The AAS meta model describes the overall structure of Asset Administration Shells and AAS sub models. It describes the minimal amount of properties and their meanings that every AAS and AAS sub model exports. For each property, a description, thy type, and the cardinality is given. The cardinality also defines if a property is optional, i.e. whether the minimum amount of values for that property is zero or greater than zero.

The AAS meta model is defined by the Platform Industrie 4.0, the exact meta model definition can be downloaded from the Platform Industrie 4.0 as "Details of the Asset Administration Shell - Part 1". Eclipse BaSyx provides a reference implementation of the AAS standard. The following descriptions are adapted from that document. Every AAS at least defines the properties described in the AAS meta model.

The following tables describes the attributes of each meta class. Type descriptions and tables were adapted from "Details of the Asset Administration Shell - Part 1". The security attribute and associated security concepts of the AssetAdministrationShell type will be covered in a specific HowTo document. The meaning of table columns are as following:

• Attribute: Defines the attribute name
• Type: Defines the type of the attribute
• Kind: The kind column defines whether an attribute is a reference (ref) to another object, or whether an attribute is contained (aggr) in the object. An aggregation always belongs to one parent object. In case of references, several objects may create a reference to the same referred object.
• Cardinality: Defines the number of references or aggregated elements, as well as whether an attribute is mandatory (minimum cardinality >= 1) or whether it is optional (minimum cardinality = 0).
• Description: Explanatory description of the attribute.

Class AssetAdministrationShell

Class HasDataSpecification

The HasDataSpecification base class marks elements that can have data specification templates. A template defines the additional attributes an element may or shall have.

Class Identifiable

Identifiable is the base class for all elements with a globally unique identifier Source: Details of the Asset Administration Shell, Part 1

The class Identifiable is the base class for all elements with a globally unique identifier.

Class Identifier

Identifier is the base class for all elements with a globally unique identifier Source: Details of the Asset Administration Shell, Part 1

The Identifier class is used to uniquely identify an entity. The IdentifierType enumeration defines three kinds of identifiers:

• IRDI: IRDI according to ISO29002-5 as an Identifier scheme for properties and classifications.
• URI: URI identifier
• Custom Custom identifiers like GUIDs (globally unique Identifiers)

With respect to the global kind of an AAS, we propose a URI based format for the AAS identifier. <<<LINK>>>

Class AdministrativeInformation

The class AdministrativeInformation contains Administrative meta information for elements; currently, this is the version information.

Class Referable

AAS Referable and Identifiable base classes define different kinds of identifiers Source: Details of the Asset Administration Shell, Part 1

The Referable type is the base class for elements that are referable by their idShort property. This short id is not globally unique. It is id unique only within the name space of an enclosing element.

Class Asset

The Asset base class defines a sub model that provides additional identification information about the managed asset Source: Details of the Asset Administration Shell, Part 1

An Asset describes meta data of an asset that is represented by an AAS. The asset may represent either an asset type or an asset instance. The asset has a globally unique identifier plus – if needed – additional domain specific (proprietary) identifiers.

Class HasKind

The HasKind base class defines the Kind property that distinguishes between type and instance AAS Source: Details of the Asset Administration Shell, Part 1

An element with a kind is an element that can represent either a type or an instance. Default for an element is that it is representing an instance.

Class HasSemantics

The HasSemantics base class enables linking of semantic information Source: Details of the Asset Administration Shell, Part 1

The HasSemantics type is the base type for all elements that link a semantic specification. Semantic specifications are objects that provide a meaning for the element, e.g. an Ontology or a formal specification.

Sub model Meta Model

The Sub model meta model defines the Submodel type, as well as sub model elements, and base types Source: Details of the Asset Administration Shell, Part 1

A Submodel defines a specific aspect of the asset represented by the AAS. It is used to structure the virtual representation and technical functionality of an AdministrationShell into distinguishable parts. Each submodel refers to a well-defined domain or subject matter. Submodels can become standardized and thus become submodels types. Submodels can have different life-cycles than their Asset Administration Shell.

The following tables describes the attributes of sub model and proprty type meta classes, as well as of their base classes. Type descriptions and tables were adapted from "Details of the Asset Administration Shell - Part 1".

Class SubModel

Class Qualifiable

For qualifiable elements additional qualifiers may be defined. For details on qualifiers and for predefined standardized qualifier types see IEC 62569-1. For example, a level qualifier defining the level type minimal value, maximum value, typical value and nominal value can be found in IEC 62569-1. Additional qualifier types are planned to be defined in the ongoing work of DIN SPEC 92000 like for example expressions semantics and expression logic.

If there are no predefined qualifier types or the additional qualification is quite complex then instead of a set of qualifiers also a formula can be defined.

AAS implementation and use

The BaSyx code snippets contain several code examples for the creation and use of Asset Administration shells.

Icons on this page are provided by Icons8.com