General

Industry 4.0 utilizes an extended understanding of assets, comprising elements such as factories, production systems, equipment, machines, components, produced products and raw materials, business processes and orders, immaterial assets (such as processes, software, documents, plans, intellectual property, standards), services, human personnel, etc..

The RAMI4.0 model [3] defines a generalized life cycle concept derived from IEC 62890. The basic idea is to distinguish between possible types and instances for all assets within Industry 4.0. This makes it possible to apply the type/instance distinction for all elements such as material type/material instance, product type/product instance, machine type/ machine instance, etc. Business-related information is handled on the 'business' layer of the RAMI4.0 model. The business layer also covers order details and workflows, again for both type and instance assets.

Table Table 1 gives an overview of the different life cycle phases and the role of type assets and instance assets as well as their relationship in these phases.

This important relationship should be maintained throughout the life of the instance assets. It makes it possible to forward updates from the type assets to the instance assets, either automatically or on demand.

The second class of relationships are feedback loops/information within the life cycle of the type asset and instance asset. For product assets, for example, information on usage and maintenance of product instances may be used to improve product manufacturing as well as the design of the (next) product type.

The third class of relationships are feedforward/information exchange with assets of other asset classes. For example, sourcing information from business assets can influence design aspects of products; or the design of the products affects the design of the manufacturing line.

A fourth class of relationships consists between assets of different hierarchy levels. For example, these could be the (dynamic) relationships between manufacturing stations and currently produced products. They could be also the decomposition of production systems in physical, functional, or safety hierarchies. In this class of relationships, automation equipment is seen as a complex, interrelated graph of automation devices and products, performing intelligent production and self-learning/optimization tasks.

Details and examples for composite I4.0 Components can be found in [12]. A composite I4.0 Component is the combination of a complex asset and its Asset Administration Shell. The hierarchy, typically a Bill of Material (BOM) but also any other relationship between different assets, can be represented in one of its submodels.

An Asset Administration Shell either represents a type asset or an instance asset. Typically, there is a relationship between instance assets and a type asset. However, not every instance asset is required to have a corresponding type asset.

Figure 1 gives an example of how to handle type assets and their derived instance assets. The attribute "assetKind" indicates whether the Asset Administration Shell (denoted by the ": AAS" UML notation for a class instance) represents a type asset or an instance asset. Additionally, attributes are added to show that the attributes of type asset and instance assets typically differ from each other.

There shall be a concrete type asset of a temperature sensor and two uniquely identifiable physical temperature sensors of this type. The intention is to provide a separate Asset Administration Shell for the type asset as well as for every single instance asset.

In the example, the first sensor has the unique ID "0215551AAA_T1" and the second sensor has the unique ID "0215551AAA_T2". "0215551AAA_T1" and "0215551AAA_T2" are the global asset IDs of the two assets, i.e. sensors. The Asset Administration Shell for the first sensor has the unique URI "http://T1.com" and the Asset Administration Shell for the second sensor has the unique URI "http://T2.com". The asset kind of both is "Instance". The example shows that the measured temperature at operation time of the two sensors is different: for T1 it is 60 °C, for T2 it is 100 °C. For the time-being we ignore the relationship "derivedFrom" of the two Asset Administration Shells "http://T1.com " and "http://T2.com" with Asset Administration Shell "http://T0215551AA.com".

These two instance assets share a lot of information on the type asset (in this example a sensor type), for which an own Asset Administration Shell is created. The unique ID for this Asset Administration Shell is "http://T0215551AA.com", the unique ID of the sensor type is "0215551AA". The asset kind is "Type" and not "Instance". The information shared by all instances of this temperature sensor type is the product class (="Component"), the manufacturer (="ExampleManufacturer"), the English Description (="precise and fast temperature measurement"), and the value range ("-40 °C / 140 °C").

Now the two Asset Administration Shells of the two instance assets may refer to the Asset Administration Shell of the type asset "0215551AA" using the relationship attribute "derivedFrom".

In the previous clause, type assets and instance assets were explained. The obvious question now is how to harmonize Asset Administration Shells and Asset Administration Shell types. The example in Figure 2 shows that the attributes "globalAssetId" and "assetKind" as well as the global Asset Administration Shell identifier (id, represented as name of the class) are present for all Asset Administration Shells. However, if there is no standard, the semantics of "id", "globalAssetId" or "kind" are not clear, although they are the same for all Asset Administration Shells. It is also not clear, which of the attributes are mandatory and which are specific for the asset (type or instance), as illustrated in Figure 2.

This is the purpose of this document: the definition of a metamodel that defines which attributes are mandatory and which are optional for all Asset Administration Shells. The Plattform Industrie 4.0 metamodel for Asset Administration Shells is defined in Clause Specification.

According to [4], identifiers are needed for the unique identification of many different elements within the domain of smart manufacturing. They are a fundamental element of a formal description of the Administration Shell. Identification is especially required for

Identification will take place for two purposes

In the domain of smart manufacturing, the assets need to be uniquely identified worldwide [4] [20] by the means of identifiers (IDs). The Administration Shell also has a unique ID (see Figure 3).

An Administration Shell represents exactly one asset, with a unique asset ID. In a batch-based production, the batches will become the assets and will be described by a respective Administration Shell. If a set of assets shall be described by an Administration Shell, a unique ID for the composite asset needs to be created [13].

The ID of the asset needs to comply with the restrictions for global identifiers according to [4][20]. If the asset features further identifications like serial numbers and alike, they are not to be confused with the unique global identifiers of the asset itself^[1].

In [4][20], two standard-conforming global identification types are defined:

The following is also permitted:

This means that the IRIs/URIs/URLs and internal custom identifiers can represent and communicate manufacturer-specific information and functions in the Administration Shell and the 4.0 infrastructure just as well as standardized information and functions. One infrastructure can serve both purposes.

CLSID are URIs for GUIDs. They start with a customer specific schema. Hence, Custom should really only be used if the customer-specific identifier is no IRDI nor IRI.

Besides the global identifiers, there are also identifiers that are unique only within a defined namespace, typically its parent element. These identifiers are also called local identifiers. For example, properties within a submodel have local identifiers.

Besides absolute URIs there are also relative URIs.

See also DIN SPEC 91406 [31] for further information on identification.

Not every identifier is applicable for every element of the UML model representing the Asset Administration Shell. Table Table 2 therefore gives an overview on the different constraints and recommendations on the various entities, which implement Identifiable or HasSemantics.

See Annex How Are New Identifiers Created? for more information on how to create new identifiers and best practices for creating URI identifiers.

The Administration Shell fosters the use of worldwide unique identifiers to a large degree. However, in some cases, this may lead to inefficiencies. Example: a property, which is part of a submodel, which in turn is part of an Administration Shell, each of which is identified by global identifiers [4].

In an application featuring a resource-oriented architecture (ROA), a worldwide unique resource locator (URL) might be composed of a series of segments, which do not need to be globally unique, see Figure 4.

To allow such efficient addressing by the chaining of elements by an API of an Administration Shell, idShort is provided for a set of classes of the metamodel. It inherits from the abstract class Referable, in order to refer to such dependent elements.

Before accessing concrete data provided via a submodel, an application typically checks if the submodel provides the required data, i.e. the semantics of the submodel is checked for suitability. A so-called semanticId should be defined for this submodel as well as the submodel element. This semantic ID helps to easily find the semantic definition of the submodel (see Clause Has Semantics Attributes).

When comparing two elements, different use cases should be considered in order to define how these two elements are semantically related. This clause gives first hints on the aspects to consider when dealing with matching semantic identifiers. For example, semantic references including context information as represented in IRDI-Path in ECLASS are not yet considered. Sometimes a concept description is derived from another concept description or is identical to or at least compatible with another concept description. The metamodel foresees an attribute "isCaseOf" for such semantic IDs. However, these are not considered in the matching strategies described in this clause.

Exact Matching (identical semanticIds) – DEFAULT

Intelligent Matching (compatible semanticIds)

Clause Matching Strategies for Semantic Identifiers has discussed matching strategies for semantic identifiers. This clause explains matching strategies based on the reference concept (see Clause Referencing) in more detail and covers other kinds of identifying elements.

For example, the string serialization of references as defined in Clause Text Serialization of Values of Type "Reference" is used for easier understanding.

Equivalence matching of two references

Examples for non-matching external references^[5]:

matches

Value matching of two references

The definition of XML Schema is used for matching

"

Examples for matching external references^[6]:

matches

Examples for non-matching external references:

does not match

Examples for matching model references:

Although these two model references would match according to the matching rules, other rules are violated, i.e. that the ID of the submodel is unique. If the ID of a submodel is unique, it is not possible that there are two direct submodel element children with the same name (here: Specification). It is also not possible that two different versions of the same submodel are compared here, because we would then assume that the ID also contains the version information (see Clause Administrative Information Attributes). The matching algorithm would still identify these two model references as matching although one of them is buggy.

matches

Examples for matching model and external references:

matches

matches

It is in the interest of Industry 4.0 for as many submodels as possible, including free and proprietary submodels, to be formed (see [4], "Free property sets"). A submodel can be formed at any time for a specific Administration Shell of an asset. The provider of the Administration Shell can form in-house identifiers for the type and instance of the submodel in line with Clause Identification of Elements. All I4.0 systems are called on to ignore submodels and properties that are not individually known. Hence, it is always possible to deposit proprietary – e.g. manufacturer-specific or user-specific – information, submodels, or properties in an Administration Shell.

A public specification of a submodel template (e.g. via publication by Plattform Industrie 4.0) should be available to instantiate an existing submodel template. In special cases, a submodel can also be instantiated from a non-public submodel template, such as a manufacturer specification.

In November 2020, the first two submodel templates for the Asset Administration Shell were published, one for a nameplate [40] and one for generic technical data [39]. Others followed and will follow. Please see [45] for an overview of registered submodel templates.

The identifiers of concept definitions to be used as semantic references are already predefined in each submodel template. An instantiation of such a submodel merely requires the creation of properties with a semantic reference to the property definition and an attached value. The same applies to other subtypes of submodel elements.

The only thing that cannot be defined in the template itself is the unique ID of the submodel instance itself (it is not identical to the ID of the submodel template), as well as the property values, etc. Templates also define cardinalities, for example whether an element is optional or not. Submodel element lists typically contain more than one element: the template contains an exemplary element template; the other elements can be created by copy/paste from this template.

Events are a very versatile mechanism of the Asset Administration Shell. The following subclauses describe some use cases for events. They summarize different types of events to depict requirements, introduce a SubmodelElement EventElement to enable declaration of events of an Asset Administration Shell. Further, the general format of event messages is specified.

Event use cases are briefly outlined in the following:

We can distinguish between incoming and outgoing events. See Table 3 for more information on the event directions.

The uses cases described in Clause Brief Use Cases for Events Used in Asset Administration Shells need different types of events. Each event type is identified by a semanticId and features a specialized payload.

Table 4 gives an overview of types of events. The possible directions of an event are described in Clause Input and Output Directions of Events.

Custom Event Types

Custom event types can be defined by using a proprietary, but worldwide unique, semanticId for this event type. Such customized events can be sent or received by the software entity of the respective referable, based on arbitrary conditions, triggers, or behavior. While the general format of the event messages needs to comply with this specification, the payload might be completely customized.

Event Scopes

Events can be stated with an observableReference to the Referables of Asset Administration Shell, Submodels, and SubmodelElements. These Referables define the scope of the events, which are to be received or sent. Table 5 describes the different scopes of an event.