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.
Accessing Asset Administration Shells
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.
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
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
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 describes the structure of the AAS. It 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.
|derivedFrom||AssetAdministrationShell||ref||0..1||The reference to the AAS the AAS was derived from.|
|security||Security||aggr||1||Definition of the security relevant aspects of the AAS.|
|BaSyx project links: Project BaSyx main wiki page | What is BaSyx? | BaSyx Developer Documentation|