We discussed briefly the asset administration shell in the description of RAMI 4.0 model. Asset administration shell or simply AAS is a bridge between a tangible asset and IoT world. In easy terms, it’s a magical tool which equips any industry component with capabilities to talk and to share information with the digital IoT world. How is this possible? In order to understand that, let us first try to understand the structure of AAS.
AAS, as the name implies, is a shell surrounding an asset (let’s say a table fan). AAS consists of a header and a body as depicted in the figure below. The header part of the AAS contains information for identification, administration, and usage of the asset, its subcomponents and administration shell as a whole. This complete information is stored in the manifest part of the header. The body part of AAS has submodels (or partial models) which contain hierarchically organized asset properties. These properties contain features which refer to the data and functions related to the asset. Even the body of AAS has a manifest which refers to the complete list all submodels, hence acting as a directory of all data and functions of an asset. Another important part of the body is the component manager (or resource manager) which not only administers the sub-models but is also responsible for linking the information in AAS to loT world. Uh! Quite complex, isn’t? Let us try to understand these elements by the means of an example of a smart table fan. A table fan which can communicate with other objects (digital information exchange) and is equipped with smart sensors.
AAS Header- identifier: list the AAS and ID which will help the fan manufacturer, service technician or anybody seeking tech. details to locate our fan. Since there are millions of fans and other IoT capable assets in the world, there is a need for unique identification standards in order to ensure unified identification principle.
AAS Body- Submodels: Here we have defined two submodels:
Fan maintenance: This submodel contains all the maintenance relevant information as a function provided by the manufacturer. This is just to facilitate the service by eliminating the need of going through lengthy service and maintenance manuals. This submodel contains function like motor dismantling, blade and switch repair, general test and so on.
The functions mentioned in the example above are represented in a specific form within the submodels. These functions contain information like ID, function name, the definition of a function, unit-data types, semantic and other aspects.
AAS can have many submodels depending on its complexity or vast functionality. The reference ID of all submodels is then stored in the manifest which then acts as a directory. These submodels can be retrieved by referring to the AAS of an asset, over IoT conforms communication channel.
Example:
A service technician who wants to repair the fan will scan the QR code on the fan or follow the URL made available to him to land to a page (over component manager) where he can select maintenance (submodel) related information from the list (manifest) of widely available features (other submodels).
Any system or document update of an asset gets reflected in the overall value chain or connected devices. A smart home where a thermometer regulates the room temperature by providing commands to the fan or heater needs to have updated system information from all these objects. Here it is the responsibility of the fan manufacturer to keep the documentation and software version etc. up to date. The centralized IT system (IoT conform) along with the component manager of each AAS facilitates the information update within the complete IoT network of connected assets (thermometer, heater, windows etc.).
An asset can have many AAS. This is usually a case in a complex product. For example, a car contains many big and small assets ranging from the engine, board computer, light system to tires, wiper unit, window pane etc. All these assets have their respective AAS with each AAS having different submodels which are interconnected and communicate (over component manager) with each other and IoT world.
AAS and RAMI 4.0
In addition to the industrial, value chain and security-related information, AAS refers to complete RAMI 4.0 model contents. AAS along with asset itself represent the 6 process layer with AAS representing the digital part (communication-business). Being a virtual representation of an actual asset, AAS maintains the asset related information for the complete asset lifecycle (type and instances) and relates to all the hierarchy levels.
To simply sum up, AAS is a digital representation of an asset which maintains all the relevant information needed for its functionality as well as the functionality of all associated assets. It contains information which makes an asset easily administrable and identifiable or on a lighter note, it’s a collection of “National ID, birth certificate, education, health history and social media websites, contact details…” of a product.
I hope you enjoyed reading the article and that it helped you to get at least a basic understanding of the asset administration shell. Your feedback, comments or suggestions are always welcome.
AAS, as the name implies, is a shell surrounding an asset (let’s say a table fan). AAS consists of a header and a body as depicted in the figure below. The header part of the AAS contains information for identification, administration, and usage of the asset, its subcomponents and administration shell as a whole. This complete information is stored in the manifest part of the header. The body part of AAS has submodels (or partial models) which contain hierarchically organized asset properties. These properties contain features which refer to the data and functions related to the asset. Even the body of AAS has a manifest which refers to the complete list all submodels, hence acting as a directory of all data and functions of an asset. Another important part of the body is the component manager (or resource manager) which not only administers the sub-models but is also responsible for linking the information in AAS to loT world. Uh! Quite complex, isn’t? Let us try to understand these elements by the means of an example of a smart table fan. A table fan which can communicate with other objects (digital information exchange) and is equipped with smart sensors.
AAS Header- identifier: list the AAS and ID which will help the fan manufacturer, service technician or anybody seeking tech. details to locate our fan. Since there are millions of fans and other IoT capable assets in the world, there is a need for unique identification standards in order to ensure unified identification principle.
AAS Body- Submodels: Here we have defined two submodels:
- Fan condition monitoring: The manufacturer is interested in condition monitoring of his fan in order to fine-tune his maintenance schedule. For that, he can save information regarding motor temperature monitoring, motor rpm, number of running hours and so on as a function in this submodel. This monitoring is of course done by the means of in-built sensors which generate data for monitoring.
Fan maintenance: This submodel contains all the maintenance relevant information as a function provided by the manufacturer. This is just to facilitate the service by eliminating the need of going through lengthy service and maintenance manuals. This submodel contains function like motor dismantling, blade and switch repair, general test and so on.
The functions mentioned in the example above are represented in a specific form within the submodels. These functions contain information like ID, function name, the definition of a function, unit-data types, semantic and other aspects.
AAS can have many submodels depending on its complexity or vast functionality. The reference ID of all submodels is then stored in the manifest which then acts as a directory. These submodels can be retrieved by referring to the AAS of an asset, over IoT conforms communication channel.
Example:
A service technician who wants to repair the fan will scan the QR code on the fan or follow the URL made available to him to land to a page (over component manager) where he can select maintenance (submodel) related information from the list (manifest) of widely available features (other submodels).
Any system or document update of an asset gets reflected in the overall value chain or connected devices. A smart home where a thermometer regulates the room temperature by providing commands to the fan or heater needs to have updated system information from all these objects. Here it is the responsibility of the fan manufacturer to keep the documentation and software version etc. up to date. The centralized IT system (IoT conform) along with the component manager of each AAS facilitates the information update within the complete IoT network of connected assets (thermometer, heater, windows etc.).
An asset can have many AAS. This is usually a case in a complex product. For example, a car contains many big and small assets ranging from the engine, board computer, light system to tires, wiper unit, window pane etc. All these assets have their respective AAS with each AAS having different submodels which are interconnected and communicate (over component manager) with each other and IoT world.
AAS and RAMI 4.0
In addition to the industrial, value chain and security-related information, AAS refers to complete RAMI 4.0 model contents. AAS along with asset itself represent the 6 process layer with AAS representing the digital part (communication-business). Being a virtual representation of an actual asset, AAS maintains the asset related information for the complete asset lifecycle (type and instances) and relates to all the hierarchy levels.
To simply sum up, AAS is a digital representation of an asset which maintains all the relevant information needed for its functionality as well as the functionality of all associated assets. It contains information which makes an asset easily administrable and identifiable or on a lighter note, it’s a collection of “National ID, birth certificate, education, health history and social media websites, contact details…” of a product.
I hope you enjoyed reading the article and that it helped you to get at least a basic understanding of the asset administration shell. Your feedback, comments or suggestions are always welcome.
- SAP Managed Tags:
7 Comments
