BaSyx / Concepts
BaSyx Concepts
The Eclipse BaSys middleware depends on the core concepts Asset Administration Shell (AAS), AAS sub model, control component, registry, and end-to-end communication. These are the core components that are required for the realization of an operational BaSys system. Additional components extend the capabilities of this BaSys system. Every main component of Eclipse BaSyx is described in its own section. The following gives a brief overview on Eclipse BaSyx.
Main BaSyx components and architecture overview =
The Asset Administration Shell (AAS) is the digital representation of any Industrie 4.0 asset. Every relevant asset, e.g. devices, workers, products, but also the manufacturing process has exactly one AAS. The AAS is identified by a unique identifier that represents exactly this asset. Because of this diversity in represented objects, every AAS contains a different set of sub models. Sub models are data models that describe specific aspects of an asset, e.g. its a digital nameplate, offered services, or the plant topology. An AAS and its sub models is a unified representation of a real-world asset. It may contain both static and dynamic models. Static models contain data, i.e. these describe for example offered services and how to reach them, and physical properties of the represented asset. A static model for example describes an OPC-UA server that provides live-sensor data or access to device control functions. Dynamic AAS sub-models contain dynamic data, e.g. live measured sensor data. A dynamic model also may offer callable services, and thus provide direct access to managing, or even controlling assets. It can for example be a facade to an OPC-UA server or a field-bus protocol, and therefore implement a harmonized interface to device-specific communication that can also be used from the IT.
BaSys supports the three types of asset administration shells that are defined by the Platform Industrie 4.0:
- Type 1 Asset Administration Shells are serialized files. A serialized file may contain the serialized AAS and additional static sub-models. A type 1 AAS may refer to dynamic sub models that reside on a host in the network.
- Type 2 Asset Administration Shells are runtime instances that are hosted in the network. They can be reached through a network ID that is retrieved from the AAS registry, and provide a runtime interface. Eclipse BaSyx permits Type 2 AAS to be serialized to a type 1 AAS, and a type 1 AAS can be send to an AAS server component that will host it as type 2 AAS. This way, an AAS can be serialized and send to a receiver.
- Type 3 Asset Administration Shells are type 2 AAS that additionally have an active behavior. For example, these AAS can negotiate with other AAS. A language example is described in VDI/VDE 2193.
The registry enables the registration of new AAS, and looking up of registered AAS by their unique identifier or identifiers, as Eclipse BaSyx enables to reach the same AAS through multiple identifiers. The AAS registry provides access to all registered Asset Administration Shells, and is therefore the first point of contact for most Industrie 4.0 applications and devices. The unique AAS identifier is a logic ID that is independent of the physical deployment of the AAS or its sub models. The registry defines basic API functions for registering and de-registering AAS, as well as to lookup an AAS. The AAS registry is usually provided as docker container that is hosted on a server in the network.
A sub-model describes one logic aspect of the represented asset. Static sub models consist of serialized data, e.g. a digital nameplate. Dynamic sub models are components in the network. Devices update data contained in dynamic sub-models to reflect the current device state. Both AAS and AAS sub-models can be accessed using common and well-defined HTTP and OPC-UA interfaces to enable access from both the IT and shop floor (OT) devices.
Control components provide unified access to production services, e.g. of devices and provide unified access to device states. They provide a common interface to a PackML based device state machine that provides a basic understating of the device state, e.g. whether it is ready, working, done with a service, or whether it is in an error mode. The control component defines a unified interface for setting the device operation mode, for selecting a service, and for invoking that service. Control components are both a unified interface to the device, and they also implement service-oriented control functions on PLC controllers.