diff --git a/README.md b/README.md index 695085515..2f6111fe5 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,4 @@ -# This is the repository of the Asset Administration Shell +# IDTA-01001 - Metamodel of the Asset Administration Shell [![Check]( https://github.com/admin-shell-io/aas-specs/workflows/Check/badge.svg @@ -11,7 +11,13 @@ https://licensebuttons.net/l/by/4.0/88x31.png https://creativecommons.org/licenses/by/4.0/ ) -This repository contains specifications of the Asset Administration Shell, including the normative schemas of the serializations, the rules applied to create them, how the specification is mapped into the serializations, and examples of how to use the schemas. +This repository contains specifications of the metamodel of the Asset Administration Shell, including the normative schemas of the serializations, the rules applied to create them, how the specification is mapped into the serializations, and examples of how to use the schemas. + +## Industrial Digital Twin Association (IDTA) + +Governance of the specification is done in the working group Open Technology of the [IDTA](https://industrialdigitaltwin.org/en/) + +The specification number is: **IDTA-01001** ## Industrial Digital Twin Association (IDTA) @@ -66,7 +72,7 @@ Previous releases (deprecated by [3.0.7](https://github.com/admin-shell-io/aas-s Feature requests, reports about inconsistencies, mistakes *etc.* are highly welcome! Please [submit a new issue]( -https://github.com/admin-shell-io/aas-specs/issues/new +https://github.com/admin-shell-io/aas-specs/issues/new/choose ). If you want to contribute, see [CONTRIBUTING.md](CONTRIBUTING.md). diff --git a/documentation/IDTA-01001/antora.yml b/documentation/IDTA-01001/antora.yml new file mode 100644 index 000000000..d0202ae22 --- /dev/null +++ b/documentation/IDTA-01001/antora.yml @@ -0,0 +1,6 @@ +name: IDTA-01001 +title: Specification Asset Administration Shell - Part 1 Metamodel +version: 'snapshot' +start_page: ROOT:index.adoc +nav: + - modules/ROOT/nav.adoc \ No newline at end of file diff --git a/documentation/IDTA-01001/modules/ROOT/IDTA-01001.adoc b/documentation/IDTA-01001/modules/ROOT/IDTA-01001.adoc deleted file mode 100644 index 4f9be0b48..000000000 --- a/documentation/IDTA-01001/modules/ROOT/IDTA-01001.adoc +++ /dev/null @@ -1,7567 +0,0 @@ -//// -Copyright (c) 2023 Industrial Digital Twin Association - -This work is licensed under a [Creative Commons Attribution 4.0 International License]( -https://creativecommons.org/licenses/by/4.0/). - -SPDX-License-Identifier: CC-BY-4.0 - -Illustrations: -Plattform Industrie 4.0; Anna Salari, Publik. Agentur für Kommunikation GmbH, designed by Publik. Agentur für Kommunikation GmbH -//// - -:toc: left -:toc-title: Specification of the Asset Administration Shell. Part 1: Metamodel -:sectlinks: -:sectnums: -:imagesdir: images/ -:nofooter: - - -include::../Constraints/constraints.adoc[] - - -= image:img.png[width=100%] -//:author: IDTA -//:version-label: Number -//:revnumber: 01001 -//:revdate: April 2023 -//:revremark: Specification of the Asset Administration Shell - -== Preamble - -=== Editorial Notes - -This document (version 3.0) was produced from June 2022 to January 2023 by the joint sub working group "Asset Administration Shell" of the working group "Reference Architectures, Standards and Norms" of the Plattform Industrie 4.0 and the working group "Open Technology" of the Industrial Digital Twin Association (IDTA). It is the first release published by the Industrial Digital Twin Association. - -A major change consists in splitting the overall document into four parts: Part 1 (this document) covers the core metamodel of the Asset Administration Shell, Part 5 covers the AASX package exchange format, Part 3 is a series that covers the predefined data specifications and Part 4 covers the security metamodel. Another major change is that the mapping rules for the different supported exchange formats (XML, JSON and RDF) are moved to the github repositories themselves that also contain the schemata. Part 2, the API Specification, was defined in a separate document from the very beginning. - -Version 3.0RC02 was produced from November 2020 to May 2022 by the sub working group "Asset Administration Shell" of the joint working group of the Plattform Industrie 4.0 working group "Reference Architectures, Standards and Norms" and the "Open Technology" working group of the Industrial Digital Twin Association. - -Version 3.0RC01 of this document, published in November 2020, was produced from November 2019 to November 2020 by the sub working group "Asset Administration Shell" of the Plattform Industrie 4.0 working group "Reference Architectures, Standards and Norms". - -The second version V2.0 of this document was produced from August 2018 to November 2019 by the sub working group "Asset Administration Shell" of the Platform Industrie 4.0 working group "Reference Architectures, Standards and Norms". Version 2.0.l was published in May 2020. - -The first version of this document was produced September 2017 to July 2018 by a joint working group with members from ZVEI SG "Models and Standards" and the Plattform Industrie 4.0 working group "Reference Architectures, Standards and Norms ". The document was subsequently validated by the platform’s working group "Reference Architectures, Standards and Norms". - -For better readability the abbreviation "I4.0" is consistently used for "Industrie 4.0" in compound terms. The term "Industrie 4.0" continues to be used when standing on its own. - -This specification is versioned using https://semver.org/spec/v2.0.0.html[Semantic Versioning 2.0.0] (semver) and follows the semver specification link:#bib36[[36\]]. - -The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in https://tools.ietf.org/html/bcp14[BCP 14] https://tools.ietf.org/html/rfc2119[RFC2119] https://tools.ietf.org/html/rfc8174[RFC8174]footnote:[https://www.ietf.org/rfc/rfc2119.txt]: - -* MUST word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. -* MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification. -* SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. -* SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. -* MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) - -=== Scope of this Document - -The aim of this document is to define the structure of the Administration Shell to enable the meaningful exchange of information about assets and I4.0 components between partners in a value creation network. - -This part of the document focuses on how such information needs to be processed and structured. In order to define these specifications, the document formally stipulates some structural principles of the Administration Shell. This part does not describe technical interfaces of the Administration Shell or other systems to exchange information, protocols, or interaction patterns. - -This document focuses on: - -* a metamodel for specifying information of an Asset Administration Shell and its submodels, -* an introduction to the need of mappings to suitable technologies used in different life cycle phases of a product: XML, JSON, RDF, AutomationML, and OPC UA. - -This document presumes some familiarity with the concept of the Asset Administration Shell. Some of the concepts are described in Annex A for convenience sake. The concepts are being standardized as IEC standard IEC 63278 series link:#bib44[[44\]]. The main stakeholders addressed in this document are architects and software developers aiming to implement a digital twin using the Asset Administration Shell in an interoperable way. Additionally, the content can also be used as input for discussions with international standardization organizations and further initiatives. Please consult the continuously updated reading guide link:#bib38[[38\]] for an overview of documents on the Asset Administration Shell. The reading guide gives advice on which documents should be read depending on the role of the reader. - -=== Structure of the Document - -All clauses that are normative have "(normative)" as a suffix in the heading of the clause. - -Clause 2 provides terms and definitions as well as abbreviations, both for abbreviations used in the document and for abbreviations that may be used for elements of the metamodel defined in this document. - -Clause 3 gives a short introduction into the content of this document. - -Clause 4 summarizes relevant, existing content from the standardization of Industry 4.0; i.e. it provides an overview and explains the motives, but is not absolutely necessary for an understanding of the subsequent definitions. - -Clause 5 is the main normative part of the document. It stipulates structural principles of the Administration Shell in a formal manner to ensure an exchange of information using Asset Administration Shells. A UML diagram has been defined for this purpose. - -Clause 6 explains how to define predefined data specifications, including those for defining concept descriptions. - -Clause 7 provides information on the exchange of information compliant to this specification in existing data formats like XML, AutomationML, OPC UA information models, JSON, or RDF. - -Clause 8 summarizes the content and gives an outlook on future work. - -Annex A contains additional background information on Asset Administration Shell, while a mapping to the requirements can be found in Annex B. - -Annex C defines the grammar language used in the specification. Annex E contains information about UML, while Annex D provides the tables used to specify UML classes etc. as used in this specification. - -Annex H describes metamodel changes compared to previous versions. Annex F provides some hints for modelers, and Annex G shows selected metamodel diagrams including all inherited attributes for developers. - -The bibliography can be found in Annex I. - -=== Working Principles - -The work is based on the following principle: keep it simple but do not simplify if it affects interoperability. - -To create a detailed specification of the Administration Shell according to the scope of Part 1 result papers published by Plattform Industrie 4.0, the trilateral cooperation between France, Italy, and Germany, as well as international standardization results were analyzed and taken as source of requirements for the specification process. As many ideas as possible from the discussion papers were considered. See Annex A for more information. - -The partners represented in the Plattform Industrie 4.0 and the Industrial Digital Twin Association (IDTA) and associations such as ZVEI, VDMA, VDI/ VDE and Bitkom, ensure that there is broad sectoral coverage of process, hybrid, and factory automation and in terms of integrating information technology (IT) and operational technology (OT). - -Design alternatives were intensively discussed within the working group. An extensive feedback process of this document series is additionally performed within the working groups of Plattform Industrie 4.0 and IDTA. - -Guiding principle for the specification was to provide detailed information, which can be easily implemented also by small and medium-sized enterprises. - -== Terms, Definitions and Abbreviations - -=== Terms and Definitions - -==== -[.underline]#Please note#: the definitions of terms are only valid in a certain context. This glossary applies only within the context of this document. -==== - -If available, definitions were taken from IEC 63278-1 DRAFT, July 2022. - -*access control* - -protection of system resources against unauthorized access; a process by which use of system resources is regulated according to a security policy and is permitted by only authorized entities (users, programs, processes, or other systems) according to that policy - -* [SOURCE: IEC TS 62443-1-1] - -*application* - -software functional element specific to the solution of a problem in industrial-process measurement and control - - -==== -Note 1 to entry: an application can be distributed among resources and may communicate with other applications. -==== - - -* [SOURCE: IEC TR 62390:2005-01, 3.1.2] - -*asset* - -physical, digital, or intangible entity that has value to an individual, an organization, or a government - - -==== -Note 1 to entry: an asset can be single entity, a collection of entities, an assembly of entities, or a composition of entities. -==== - - - -==== -EXAMPLE 1: examples for physical entities are equipment, raw material, parts components and pieces, supplies, consumables, physical products, and waste. -==== - - - -==== -EXAMPLE 2: examples for digital assets are process definitions, business procedures, or actual states. -==== - - - -==== -EXAMPLE 3: a software license is an example of an intangible asset. -==== - - -* [SOURCE: IEC 63278-1, based on IEV 741-01-04, editorial changes] - -*attribute* - -data element of a _property_, a relation, or a class in information technology - -* [SOURCE: ISO/IEC Guide 77-2, ISO/IEC 27460, IEC 61360] - -*Asset Administration Shell (AAS)* - -standardized digital representation of an asset - - -==== -Note 1 to entry: Asset Administration Shell and Administration Shell are used synonymously. -==== - - -* [SOURCE: IEC 63278-1, note added] - -*class* - -description of a set of objects that share the same _attributes_, _operations_, methods, relationships, and semantics - -* [SOURCE: IEC TR 62390:2005-01, 3.1.4] - -*capability* - -implementation-independent potential of an Industrie 4.0 component to achieve an effect within a domain - - -==== -Note 1 to entry: capabilities can be orchestrated and structured hierarchically. -==== - - - -==== -Note 2 to entry: capabilities can be made executable via services. -==== - - - -==== -Note 3 to entry: the impact manifests itself in a measurable effect within the physical world. -==== - - -* [SOURCE: Glossary Industrie 4.0, minor changes] - -*coded value* - -value that can be looked up in a dictionary and can be translated - -* [SOURCE: link:https://eclass.eu/support/technical-specification/data-model/conceptual-data-model[ECLASS] footnote:[In IEC61360:2017, this refers to a "term" of a value list]] - -*component* - -product used as a constituent in an assembled product, _system_, or plant - -* [SOURCE: IEC 63278-1; IEC 61666:2010, 3.6, editorial changes] - -*concept* - -unit of knowledge created by a unique combination of characteristics - -* [SOURCE: EC 63278-1; IEC 61360-1:2016, 3.1.8; ISO 22274:2013, 3.7] - -*digital representation* - -information and services representing an entity from a given viewpoint - - -==== -EXAMPLE 1: examples of information are properties (e.g. maximum temperature), actual parameters (e.g. actual velocity), events (e.g. notification of status change), schematics (electrical), and visualization information (2D and 3D drawings). -==== - - - -==== -EXAMPLE 2: examples of services are providing the history of the configuration data, providing the actual velocity, and providing a simulation. -==== - - - -==== -EXAMPLE 3: examples of viewpoints are mechanical, electrical, or commercial characteristics. -==== - - -* [SOURCE: IEC 63278-1, editorial changes] - -*digital twin* - -_digital representation_, sufficient to meet the requirements of a set of use cases - - -==== -Note 1 to entry: in this context, the entity in the definition of digital representation is typically an asset. -==== - - -* [SOURCE: IIC Vocabulary IIC:IIVOC:V2.3:20201025, adapted (an asset, process, or system was changed to an asset)] - -*explicit value* - -commonly used _concept_, like numbers (e.g. 109, 25) which do not need lookup in dictionaries - -* [SOURCE: link:https://eclass.eu/support/technical-specification/data-model/conceptual-data-model[ECLASS]] - -*identifier (ID)* - -identity information that unambiguously distinguishes one entity from another one in a given domain - - -==== -Note 1 to entry: there are specific identifiers, e.g. UUID Universal unique identifier, IEC 15418 (GS1). -==== - - -* [SOURCE: Glossary Industrie 4.0] - -*instance* - -concrete, clearly identifiable component of a certain _type_ - - -==== -Note 1 to entry: an individual entity of a type, for example a device, is obtained by defining specific property values. -==== - - - -==== -Note 2 to entry: in an object-oriented view, an instance denotes an object of a class (of a type). -==== - - -* [SOURCE: IEC 62890:2016, 3.1.16 65/617/CDV, editorial changes] - -*instance asset* - -specific _asset_ that is uniquely identifiable - - -==== -EXAMPLE 1: examples of instance assets are material, a product, a part, a device, a machine, software, a control system, a production system. -==== - - -* [SOURCE: IEC 63278-1, editorial changes] - -*operation* - -executable realization of a function - - -==== -Note 1 to entry: the term method is synonymous to operation. -==== - - - -==== -Note 2 to entry: an operation has a name and a list of parameters [ISO 19119:2005, 4.1.3]. -==== - - -* [SOURCE: Glossary Industrie 4.0, editorial changes] - -*ontology* - -collection of concepts, where each concept is constituted by an identifier, name, description, and additional entities and where relationships between concepts can be described without restriction - -* [SOURCE: IEC 63278-1] - -*property* - -defined characteristic suitable for the description and differentiation of products or components - - -==== -Note 1 to entry: the concept of type and instance applies to properties. -==== - - - -==== -Note 2 to entry: this definition applies to properties as described in IEC 61360/ ISO 13584-42. -==== - - - -==== -Note 3 to entry: the property types are defined in dictionaries (like IEC component data dictionary or ECLASS), they do not have a value. The property type is also called data element type in some standards. -==== - - - -==== -Note 4 to entry: the property instances have a value and are provided by the manufacturers. A property instance is also called property-value pair in certain standards. -==== - - - -==== -Note 5 to entry: properties include nominal value, actual value, runtime variables, measurement values, etc. -==== - - - -==== -Note 6 to entry: a property describes one characteristic of a given object. -==== - - - -==== -Note 7 to entry: a property can have attributes such as code, version, and revision. -==== - - - -==== -Note 8 to entry: the specification of a property can include predefined choices of values. -==== - - -* [SOURCE: according to ISO/IEC Guide 77-2] as well as [SOURCE: according to Glossary Industrie 4.0] - -*qualifier* - -well-defined element associated with a _property_ instance or _submodel element_, restricting the value statement to a certain period of time or use case - - -==== -Note 1 to entry: qualifiers can have associated values. -==== - - -* [SOURCE: according to IEC 62569-1] - -*service* - -Demarcated scope of functionality which is offered by an https://www.plattform-i40.de/PI40/Redaktion/EN/Glossary/E/entity_glossary.html[entity] or organization via https://www.plattform-i40.de/PI40/Redaktion/EN/Glossary/I/interface_glossary.html[interfaces] - - -==== -Note 1 to entry: one or multiple operations can be assigned to one service. -==== - - -* [SOURCE: Glossary Industrie 4.0] - -*smart manufacturing* - -manufacturing that improves its performance aspects with integrated and intelligent use of processes and resources in cyber, physical and human spheres to create and deliver products and services, which also collaborates with other domains within enterprises' value chains - - -==== -Note 1 to entry: performance aspects include agility, efficiency, safety, security, sustainability, or any other performance indicators identified by the enterprise. -==== - - - -==== -Note 2 to entry: in addition to manufacturing, other enterprise domains can include engineering, logistics, marketing, procurement, sales, or any other domains identified by the enterprise. -==== - - -* [SOURCE: IEC TR 63283-1:2022 ED1] - -*Submodel* - -container of SubmodelElements defining a hierarchical structure consisting of SubmodelElements - -* [SOURCE: IEC 63278-1] - -*SubmodelElement* - -elements in a Submodel - -* [SOURCE: IEC 63278-1] - -*Submodel template* - -container of Submodel template elements defining a hierarchical structure consisting of Submodel template elements - - -==== -Note 1 to entry: a Submodel template is a specific kind of concept. -==== - - -* [SOURCE: IEC 63278-1] - -*Submodel template element* - -elements in a Submodel template - - -==== -Note 1 to entry: a Submodel template element is a specific kind of concept. -==== - - -* [SOURCE: IEC 63278-1] - -*system* - -interacting, interrelated, or interdependent elements forming a complex whole - -* [SOURCE: IEC 63278-1; IEC TS 62443-1-1:2009, 3.2.123] - -*technical functionality* - -functionality of the _Administration Shell_ that is exposed by an application programming interface (API) and that is creating added value to the respective _assets(s)_ - - -==== -Note 1 to entry: can consist of single elements, which are also known as functions, operations, methods, skills. -==== - - -* [SOURCE: according to link:#bib18[[18\]]] - -*template* - -specification of the common features of an object in sufficient detail that such object can be instantiated using it - - -==== -Note 1 to entry: object can be anything that has a type. -==== - - -* [SOURCE: according to ISO/IEC 10746-2] - -*type* - -hardware or software element which specifies the common _attributes_ shared by all instances of the type - -* [SOURCE: IEC TR 62390:2005-01, 3.1.25] - -*type asset* - -(abstract) representation of a set of instance assets with common characteristics and features - - -==== -Note 1 to entry: the set of instance assets may exist or may not exist. -Examples of type assets are type of material, a product type, a type of a part, a device type, a machine type, a type of software, a type of control system, a type of production system. -==== - - -* [SOURCE: IEC 63278-1] - -*variable* - -software _entity_ that may take different values, one at a time - -* [SOURCE: IEC 61499-1] - -=== Abbreviations Used in this Document - -[cols="21%,79%",options="header",] -|=== -|*Abbreviation* |*Description* -|AAS |Asset Administration Shell -|AASX |Package file format for the Asset Administration Shell -|AML |AutomationML -|API |Application Programming Interface -|BITKOM |Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e. V. -|BLOB |Binary Large Object -|CDD |Common Data Dictionary -|GUID |Globally unique identifier -|I4.0 |Industrie 4.0 -|ID |identifier -|IDTA |Industrial Digital Twin Association -|IEC |International Electrotechnical Commission -|IRDI |International Registration Data Identifier -|IRI |Internationalized Resource Identifier -|ISO |International Organization for Standardization -|JSON |JavaScript Object Notation -|MIME |Multipurpose Internet Mail Extensions -|OPC |Open Packaging Conventions (ECMA-376, ISO/IEC 29500-2) -|OPC UA |OPC Unified Architecture -|PDF |Portable Document Format -|RAMI4.0 |Reference Architecture Model Industrie 4.0 -|RDF |Resource Description Framework -|REST |Representational State Transfer -|RFC |Request for Comment -|SOA |Service Oriented Architecture -|UML |Unified Modelling Language -|URI |Uniform Resource Identifier -|URL |Uniform Resource Locator -|URN |Uniform Resource Name -|UTC |Universal Time Coordinated -|VDE |Verband der Elektrotechnik, Elektronik und Informationstechnik e.V. -|VDI |Verein Deutscher Ingenieure e.V. -|VDMA |Verband Deutscher Maschinen- und Anlagenbau e.V. -|W3C |World Wide Web Consortium -|XML |eXtensible Markup Language -|ZIP |archive file format that supports lossless data compression -|ZVEI |Zentralverband Elektrotechnik- und Elektronikindustrie e. V. -|=== - -=== Abbreviations of Metamodel - -The following abbreviations are not used in the document but may be used as abbreviations for the elements in the metamodel defined in this document. - -. Elements with Allowed Identifying Values -[cols="33%,67%",options=header] -|=== -|*Abbreviation* |*Description* -|AAS |Asset Administration Shell -|Cap |Capability -|CD |Concept Description -|DE |DataElement -|DST |DataSpecification Template -|InOut |inoutputVariable -|In |inputVariable -|Prop |Property -|MLP |MultiLanguageProperty -|xref:Range[Range] |Range -|Ent |Entity -|Evt |Event -|xref:File[File] |File -|xref:Blob[Blob] |Blob -|Opr |Operation -|Out |outputVariable -|Qfr |Qualifier -|Ref |ReferenceElement -|Rel |RelationshipElement -|RelA |AnnotatedRelationshipElement -|SM |Submodel -|SMC |SubmodelElementCollection -|SME |SubmodelElement -|SML |SubmodelElementList -|=== - -== Introduction - -This document specifies the information metamodel of the Asset Administration Shell. - -The general concept and the structure of the Asset Administration Shell is described in IEC 63278-1 (see Figure 1). - -.Asset Administration Shell and Related Roles (Source: IEC 63278-1) -image::image2.png[] - -These are the main specifics and roles defined for the Asset Administration Shell: - -* an Asset Administration Shell has an association to an asset, -* an Asset Administration Shell provides an interface or several interfaces, -* an Asset Administration Shell lists one or several submodels, -* an Asset Administration Shell responsible creates and governs the Asset Administration Shell, -* an Asset Administration Shell user application accesses the information of the Asset Administration Shell via IT interface(s). -* a Submodel template guides the creation of a submodel following the template, -* a Submodel template may reference concept dictionaries and ontologies, -* concept dictionaries and ontologies define the common vocabulary as basis for interoperability, -* submodels may reference the asset services provided by an asset via an asset integration; further services related to the asset can be referenced. - -This document specifies a technology-neutral specification of the information metamodel of the Asset Administration Shell in UML. It serves as the basis for deriving several different formats for exchanging Asset Administration Shells, e.g. for XML, JSON, RDF, AutomationML, and OPC UA information models. - -Figure 2 shows the different ways of exchanging information Asset Administration Shells. This part of the "Asset Administration Shell in Detail" series is the basis for all of these types of information exchange. - -.Types of Information Exchange via Asset Administration Shells -image::image3.jpeg[] - -File exchange (1) is described in detail in Part 5 of this document series. - -The API (2) based on the information metamodel specified in this document is specified in Part 2 of the document series "Details of the Asset Administration Shell" link:#bib37[[37\]]. - -The I4.0 language (3) is based on the information metamodel specified in this document link:#bib47[[47\]]. - -== General - -=== Introduction - -Before specifying the information metamodel of the Asset Administration Shell, some general topics relevant for the Asset Administration Shell are explained. - -Subclause 4.2 describes some general aspects of handling type and instance assets. - -Subclause 4.3 explains the very important aspects of identification in the context of the Asset Administration Shell. - -Subclause 4.4 provides matching strategies for semantic identifiers and references. - -Subclause 4.5 explains the difference between submodel instances and templates. - -Subclause 4.6 discusses aspects of event handling. - -=== Types and Instances - -==== Life Cycle with Type Assets and Instance Assets - -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 link:#bib3[[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. - - -==== -Note: to distinguish asset 'type' and asset 'instance', the term 'asset kind' is used in this document. The three different relationship classes between assets, especially type assets and instance assets, explained below show why the distinction is so important. The attribute "derivedFrom" in the metamodel is used to explicitly state a relationship between assets that are being derived from one another. Other relationships are not explicitly supported by the metamodel of the Asset Administration Shell, but they can be modelled via the "RelationshipElement" submodel element type. -==== - - -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. - - - -.Life Cycle Phases and Roles of Type and Instance Assets -[cols="20%,22%,58%", options=header] -|=== -|*Asset Kind* |*Life Cycle Phase* |*Description* -|Type asset |Development |Valid from the ideation/conceptualization to the first prototypes/test. The 'type' of an asset is defined; distinguishing properties and functionalities are defined and implemented. All (internal) design artefacts associated with the type asset are created, such as CAD data, schematics, embedded software. -| |Usage/ + -Maintenance |Ramping up production capacity. The 'external' information associated to the asset is created, such as technical data sheets, marketing information. The selling process starts. -|Instance asset |Production |Instance assets are created/produced, based on the type asset information. Specific information about production, logistics, qualification, and test are associated with the instance assets. -| |Usage/ + -Maintenance a| -Usage phase by the purchaser of the instance assets. Usage data is associated with the instance asset and might be shared with other value chain partners, such as the manufacturer of the instance asset. - -Also included: maintenance, re-design, optimization, and de-commissioning of the instance asset. The full life cycle history is associated with the asset and might be archived/shared for documentation. - -|=== - -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. - - -==== -Note: the NIST model link:#bib49[[49\]] provides an illustration of the second/third class of relationships. -==== - - -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 link:#bib12[[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. - - -==== -Note: for submodels representing the Bill of Material of a complex asset, the metamodel not only provides the possibility to define relationships (via the submodel element "RelationshipElement", see above), it also explicitly supports the representation of another asset (via the submodel element "Entity"). The term "Entity" is chosen as superordinate concept in this context and refers to either an asset or another item that is not an asset but may be part of a more complex item or asset. -==== - - -==== Asset Administration Shells Representing Type Assets and Instance Assets - -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. - -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. - -.Example: Asset Administration Shells for Type and Instance Assets -image::image4.png[] - - -==== -Note 1: the example is simplified for ease of understanding and only roughly complies with the metamodel as specified in Clause 5. The ID handling is simplified as well: the names of the classes correspond to the unique global identifier of the Asset Administration Shells. -==== - - - -==== -Note 2: in the context of Plattform Industrie 4.0, types and instances typically refer to "type assets" and "instance assets". When referring to types or instances of an Asset Administration Shell, this is explicitly denoted as "Asset Administration Shell types" and "Asset Administration Shell instances" to not mix them up. Asset Administration Shell types are synonymously used with the term "Asset Administration Shell template". -==== - - - -==== -Note 3: please refer to 2 for the IEC definition of types and instances. Within the scope of this document, there is no full equivalency between these definitions and the type/instance concepts of object-oriented programming (OO). -==== - - -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". - - -==== -Note 1: even though the HTTP scheme is used for the identifier, please be aware that these identifiers are logical ones. Identifiers do not have to be URLs. At the same time, URLs used as identifiers do not have to refer to accessible content. -==== - - - -==== -Note 2: the physical unit can be obtained by the semantic reference of the element "measuredTemperature". This is not shown in the example for simplicity reasons. -==== - - -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". - - -==== -Note 1: in the UML sense, "attribute" refers to the property or characteristic of a class (instance). -==== - - - -==== -Note 2: if a specific type asset exists, it typically exists in time before the respective instance assets. -==== - - - -==== -Note 3: the term Asset Administration Shell is used synonymously with the term Asset Administration Shell instance. An Asset Administration Shell may be realized based on an Asset Administration Shell type. Asset Administration Shell types are out of the scope of this document. -==== - - - -==== -Note 4: in public standardization, the Asset Administration Shell types might be standardized. However, it is much more important to standardize the property types (called property definitions or concept descriptions) or other submodel element types as well as complete submodel types because these can be reused in different Asset Administration Shells. -==== - - - -==== -Note 5: in the domain of the Internet of Things (IoT), instance assets are typically denoted as "Things" whereas type assets are denoted as "Product". -==== - - -==== Asset Administration Shell Types and Instances - -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 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 . - -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 5. - - -==== -Note 1: the metamodel of the Asset Administration Shell is suitable for type assets or instance assets. An alternative approach could have been to define two metamodels, one for type assets and one for instance assets. However, the large set of similarities led to the decision of only one metamodel. -==== - - - -==== -Note 2: the metamodel itself does not require the existence of mandatory submodels. This is another step of standardization similar to the standardization of submodels of the Asset Administration Shell type level. -==== - - - -==== -Note 3: an Asset Administration Shell type shall be realized based on the metamodel of an Asset Administration Shell as defined in this document. This metamodel is referred to as "Asset Administration Shell Metamodel". -==== - - - -==== -Note 4: it is not mandatory to define an Asset Administration Shell type before defining an Asset Administration Shell (instance). An Asset Administration Shell instance that does not realize an Asset Administration Shell type shall be realized based on the metamodel of an Asset Administration Shell as defined in this document. -==== - - -.Example: Asset Administration Shell, Asset Administration Shell Types and Instances -image::image5.png[] - -=== Identification of Elements - -==== Overview - -According to link:#bib4[[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 - -* Asset Administration Shells, -* assets, -* submodel instances and submodel templates, -* property definitions/concept descriptions in external repositories, such as ECLASS or IEC CDD. - -Identification will take place for two purposes - -* to uniquely distinguish all elements of an Administration Shell and the asset it is representing, and -* to relate elements to external definitions, such as submodel templates and property definitions, in order to bind semantics to this data and the functional elements of an Administration Shell. - -==== Identifiers for Assets and Administration Shells - -In the domain of smart manufacturing, the assets need to be uniquely identified worldwide link:#bib4[[4\]] link:#bib20[[20\]] by the means of identifiers (IDs). The Administration Shell also has a unique ID (see Figure 5). - -.Unique Identifier for Administration Shell and Asset (Modified Figure from link:#bib4[[4\]]) -image::image6.jpeg[] - -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 link:#bib13[[13\]]. - -The ID of the asset needs to comply with the restrictions for global identifiers according to link:#bib4[[4\]]link:#bib20[[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 itselffootnote:[Such additional asset identifiers are contained in _AssetInformation/specificAssetIds_.]. - -==== What Type of Identifiers Exist? - -In link:#bib4[[4\]]link:#bib20[[20\]], two standard-conforming global identification types are defined: - -* *IRDI* – ISO29002-5, ISO IEC 6523 and ISO IEC 11179-6 link:#bib20[[20\]] as an identifier scheme for properties and classifications. They are created in a process of consortium-wise specification or international standardization. To this end, users come together and feed their ideas into the consortia or standardization bodies. Properties in ISO, IEC help to safeguard key commercial interests. Repositories like ECLASS and others make it possible to standardize a relatively large number of identifiers in an appropriately short time. -* *IRI* – IRI (link:https://tools.ietf.org/html/rfc3987[RFC 3987]) or URI and URL according to link:https://tools.ietf.org/html/rfc3986[RFC 3986] as identification of assets, Administration Shells and other (probably not standardized, but globally unique) properties and classifications. - -The following is also permitted: - -* *Custom* – internal custom identifiers such as UUIDs/GUIDs (link:https://en.wikipedia.org/wiki/Universally_unique_identifier[universally unique identifiers]/globally unique identifiers), which a manufacturer can use for all sorts of in-house purposes within the Administration Shell. - -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 link:#bib31[[31\]] for further information on identification. - -==== Which Identifiers for Which Elements? - -Not every identifier is applicable for every element of the UML model representing the Asset Administration Shell. Table 2 therefore gives an overview on the different constraints and recommendations on the various entities, which implement "Identifiable" or "HasSemantics". Attributes relate to the metamodel in Clause 5.1 and Clause 5.3. - -See Annex A for more information on how to create new identifiers and best practices for creating URI identifiers. - -.Elements with Allowed Identifying Values -[cols="21%,17%,22%,40%",options="header",] -|=== -|*Elements with identifying values* |*Attribute* |*Allowed identifiers (recommended or typical)* |*Remarks* -|xref:AssetAdministrationShell[AssetAdministrationShell] |id |IRI (URL) a| -mandatory - -Typically, URLs will be used. - -| |idShort |string |optionalfootnote:[Note: in version V1.0 of this specification, idShort was optional for identifiables. This changed in V2.0: idShort was set to mandatory for all referables. With V3.0, idShort was again made optional.] -| |displayName |multi language string |optional -|xref:AssetInformation[AssetInformation] |globalAssetId |IRI a| -recommended - -As soon as the Asset Administration Shell is "released" for production or operation, a globalAssetId should be assigned. - -An Asset ID may be retrieved e.g., by a QR code on the asset, by an RFID for the asset, from the firmware of the asset, or from an asset database. IEC 61406 (formerly DIN SPEC 91406) defines the format of such Asset IDs. - -| |specificAssetId |IRI, Custom a| -recommended - -An asset typically may be represented by several different identification properties like for example the serial number, its RFID code etc. - -They are used for lookup of Asset Administration Shells in cases the globalAssetId is not available. However, they do not need to be globally unique. - -|xref:Submodel[Submodel] with kind = Template |id |IRDI, IRI (URI) a| -mandatory - -IRDI, if the defined submodel is standardized and has been assigned an IRDI. - -| |idShort |string a| -recommended - -Typically used as idShort for the submodel of kind Instance as well - -| |displayName |multi language string a| -recommended - -Typically used as displayName for the submodel of kind Instance as well - -| |semanticId |IRDI, IRI (URI) a| -recommended - -The semantic ID might refer to an external semantic model defining the semantics of the submodel. - -| |supplementalSemanticId |IRDI, IRI (URI) |optional -|xref:Submodel[Submodel] with kind = Instance |id |IRI (URI), Custom |mandatory -| |idShort |string a| -recommended - -Typically, the idShort or English short name of the submodel template that is referenced via semanticId. - -| |displayName |multi language string |optional -| |semanticId |IRDI, IRI (URI) a| -recommended - -Typically, the semanticId is an external reference to an external standard defining the semantics of the submodel. - -| |supplementalSemanticId |IRDI, IRI (URI) |optional -|xref:SubmodelElement[SubmodelElement] |idShort |string a| -mandatory - -Typically, the English short name of the concept definition that is referenced via semanticId. - -| |displayName |multi language string a| -optional - -If no display name is defined in the language requested by the application, the display name may be selected in the following order, if available: - -* the preferred name in the requested language of the concept description defining the semantics of the element, -* if there is a default language list defined in the application, the corresponding preferred name in the language is chosen according to this order, -* the English preferred name of the concept description defining the semantics of the element, -* the short name of the concept description, -* the idShort of the element. - -| |semanticId |IRDI, IRI (URI), Custom a| -recommended - -link to a _ConceptDescription_ or the concept definition in an external repository via a global ID - -| |supplementalSemanticId |IRDI, IRI (URI) |optional -|xref:ConceptDescription[ConceptDescription] |id |IRDI, IRI, Custom a| -mandatory - -_ConceptDescription_ needs to have a global ID. If the concept description is a copy from an external dictionary like ECLASS or IEC CDD, it may use the same global ID as it is used in the external dictionary. - -| |idShort |string a| -recommended - -e.g. same as English short name - -| |displayName |multi language string |optional -| |isCaseOf |IRDI, IRI (URI) a| -optional - -links to the concept definition in an external repository, which the concept description is a copy from, or that it corresponds to - -|xref:Qualifier[Qualifier] |semanticId |IRDI, IRI (URI), Custom a| -recommended - -Links to the qualifier type definition in an external repository - -IRDI, if the defined qualifier type is standardized and has been assigned an IRDI. - -|=== - -==== Usage of Short ID for Identifiable Elements - -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 link:#bib4[[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 6. - -.Motivation of Exemplary Identifiers and idShort -image::image7.jpeg[] - -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 (see 5.1). - -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 5.3.2). - -=== Matching Strategies - -==== Matching Strategies for Semantic Identifiers - -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* - -* With exact matching, two semantic IDs need to be string-identical. -** Example: Property with idShort "ManufacturerName" + semanticId 0173-1#02-AAO677#002 and Property with idShort "Herstellername" + semanticId 0173-1#02-AAO677#002 have exactly equal semantics. - -*Intelligent Matching (compatible semanticIds)* - -* Ignore Versioning -** With intelligent matching, different versions of a concept definition may be matched. For example, if semantic versioning is used to version the concept description, then upward or backward compatible versions can be matched. -** Example: property with idShort "ManufacturerName" + semanticId 0173-1#02-AAO677#002 and Property with idShort "Herstellername" + semanticId 0173-1#02-AAO677#003 have equal semantics. - -==== -Note: to compare two semantic IDs, knowledge about versioning needs to be available. In the example above, two IRDIs from ECLASS are compared. ECLASS rules ensure that the semantics is always backward compatible for new versions; a new IRDI would be created for breaking changes. -==== - -* Consider Semantic Mappings -** Existing semantic mapping information can be considered for intelligent matching. Semantic mappings may exist within one and the same dictionary, but also between different dictionaries and ontologies. -** Example: 0112/2///61360_4#AAE530 for nominal capacity of a battery in dictionary IEC CDD and 0173-1#02-AAI048#004 in ECLASS have equal semanticsfootnote:[Semantic mapping files are also used in ECLASS between ECLASS Classic and ECLASS Advanced: https://eclass.eu/support/technical-specification/data-model/basic-advanced-mapping] footnote:[This is the format used for semantic mapping in ECLASS: https://eclass.eu/fileadmin/Redaktion/pdf-Dateien/Wiki/ECLASSXML_3.0/ECLASS_XML/mapping.xsd]. -==== -Note: this example does not represent an existing semantic mapping; it is only a candidate. -==== - -==== -Note: this example does not represent an existing semantic mapping; it is only a candidate. -==== - -* Consider Domain Knowledge -** With intelligent matching, domain knowledge available in machine-readable form may be taken into account, such as an "is-a"-relationship between two concept definitions. -** Example: a Hammer drill (0173-1#01-ADS698#010) and a percussion drill (0173-1#01-ADS700#010) are drills for mineral material (0173-1#01-ADN177#005) and are compatible with a request or constraints asking for drills for mineral material. - -==== Matching Algorithm for References - -Clause 4.4.1 has discussed matching strategies for semantic identifiers. This clause explains matching strategies based on the reference concept (see Clause 5.3.10) in more detail and covers other kinds of identifying elements. - -For example, the string serialization of references as defined in Clause 7.2.3 is used for easier understanding. - -Exact matching of two references - -* An external reference A matches an external reference B if all values of all keys are identical. - - -==== -Note: it is unlikely that a fragment value is identical to a global reference value; it will reference something different. -==== - - -A model reference A matches a model reference B if all values of all keys are identical. + - -==== -Note: the key type can be ignored since the fragment keys are always unique (e.g. all idShorts of submodel elements in a submodel or all submodel elements in a submodel element list or collection). -==== - - -* An external reference A matches a model reference B and vice versa if all values of all keys are identical. - - -==== -Note: since identifiables of the Asset Administration Shell are globally unique, model references are special cases of global references. The only difference is the handling of key types that are predefined for Asset Administration Shell elements. Other key types could be predefined, e.g. for IRDI paths etc. However, so far only generic key types are supported. -==== - - - -==== -Note: if the key types are not identical although all key values follow the correct order of the key chain, then at least one of the references is buggy and a warning should be issued. -==== - - -The definition of link:https://www.w3.org/TR/xmlschema-2/#terminology[XML Schema] is used for matching - -* "(Of string or names:) Two strings or names being compared must be identical. -* Characters with multiple possible representations in ISO/IEC 10646 (e.g. characters with both precomposed and base+diacritic forms) match only if they have the same representation in both strings. -* No case folding is performed. -* (Of strings and rules in the grammar:) A string matches a grammatical production if it belongs to the language generated by that production." - -[.underline]#Examples for matching external referencesfootnote:[The example only contains arbitrary IRDIs and does not represent a real-world example.]:# - -*(GlobalReference)0173-1#01-ADS698#010, (GlobalReference)0173-1#01-ADS700#010* - -matches - -*(GlobalReference 0173-1#01-ADS698#010, (FragmentReference)0173-1#01-ADS700#010* - -[.underline]#Examples for non-matching external references:# - -*(GlobalReference)https://example.com/aas/1/1/1234859590, (FragmentReference)Specification, + -(FragmentReference)Bibliography* - -does not match - -*(GlobalReference)https://example.com/aas/1/1/1234859590, (FragmentReference)Specification, + -(FragmentReference)Bibliographie* - -[.underline]#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 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 5.3.2.2). The matching algorithm would still identify these two model references as matching although one of them is buggy. - -*(Submodel)https://example.com/aas/1/1/1234859590, (File)Specification* - -*(Submodel)https://example.com/aas/1/1/1234859590, (Blob)Specification* - -[.underline]#Examples for matching model and external references:# - -*(Submodel)https://example.com/aas/1/1/1234859590* - -is identical to - -*(GlobalReference)https://example.com/aas/1/1/1234859590* - -*(Submodel)https://example.com/aas/1/1/1234859590, (File)Specification (FragmentReference)Bibliography* - -is identical to - -*(GlobalReference)https://example.com/aas/1/1/1234859590, (FragmentReference)Specification, + -(FragmentReference)Bibliography* - -=== Submodel Instances and Templates - -==== Can New or Proprietary Submodels be Formed? - -It is in the interest of Industry 4.0 for as many submodels as possible, including free and proprietary submodels, to be formed (see link:#bib4[[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 4.3. 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. - - -==== -Note: it is the intention of the Administration Shell to include proprietary information, e.g. to link to company-wide identification schemes or information required for company-wide data processing. This way, a single infrastructure can be used to transport standardized and proprietary information at the same time. New information elements can also be conveyed and introduced (and standardized at a later stage). -==== - - -==== Creating a Submodel Instance Based on an Existing Submodel Template - -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 link:#bib40[[40\]] and one for generic technical data link:#bib39[[39\]]. Others followed and will follow. Please see link:#bib45[[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 - -==== Overview - -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_ “_Event_" to enable declaration of events of an Asset Administration Shell. Further, the general format of event messages is specified. - - -==== -Note: the concept of event is still in the experimental phase. Please be aware that backward compatibility cannot be ensured for future versions of the metamodel. -==== - - -==== Brief Use Cases for Events Used in Asset Administration Shells - -* Event use cases are briefly outlined in the following (see also ): - -image::image8.jpeg[] - -* An integrator has purchased a device. Later in time, the supplier of the device provides a new firmware. The integrator wants to detect the offer of a new firmware and wants to update the firmware after evaluating its suitability ("forward events"). A dependent Asset Administration Shell ("D4") detects events from a parent or type Asset Administration Shell ("D1"), which is described by the _derivedFrom_ relation. An illustration of the use case is given in Figure 7. -* An integrator/operator operates a motor purchased from a supplier. During operation, condition monitoring incidents occur. Both parties agree on a business model providing availability. The supplier wants to monitor device statuses which are located further in the value chain ("reverse events"). An illustration of the use case is given in Figure 7. - -.Forward and Reverse Events -image::image8.jpeg[] - -* An operator is operating a certain I4.0 component over time. Changes that occasionally occur to these I4.0 components from different systems shall be tracked for documentation and auditing purposes. This can be achieved by recording events over time. An illustration of the use case is given in Figure 8. - -.Tracking of Changes via Events -image::image9.jpeg[] - -* An operator is operating different I4.0 components, which are deployed to manufacturer clouds. The operator wants to integrate data from these components, according to DIN SPEC 92222. For this purpose, information needs to be forwarded to the operator cloud ("value push"). An illustration of the use case is given in Figure 9. - -.Value Push Events Across Clouds -image::image10.jpeg[] - -==== Input and Output Directions of Events - -We can distinguish between incoming and outgoing events. See Table 3 for more information on the event directions. - -.Directions of Events -[cols="32%,68%",options="header",] -|=== -|*Direction* |*Description* -|Out |The event is monitoring the _Referable_ it is attached to. An outer message infrastructure, e.g. by OPC UA, MQTT or AMQP, will transport these events to other Asset Administration Shells, further outer systems and users. -|In |The software entity, which implements the respective _Referable_, can handle incoming events. These incoming events will be delivered by an outer message infrastructure, e.g. OPC UA, MQTT or AMQP, to the software entity of the _Referable_. -|=== - -==== Types of Events - -The uses cases described in Clause 4.6.2 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 4.6.3. - -.Types of Events -[cols="26%,12%,62%",options="header",] -|=== -|*Group* |*Direction* |*Motivation / Conditions* -|Structural changes of the Asset Administration Shell |Out a| -* CRUDfootnote:[Create, Retrieve, Update, Delete] of Submodels, Assets, SubmodelElements, etc. - -| |In a| -* Detect updates on parent/type/_derivedFrom_ Asset Administration Shell - -|Updates of properties and dependent attribute |Out a| -* update of values of SubmodelElements -* time-stamped updates and time series updates -* explicit triggering of an update event - -|Operation element of Asset Administration Shell |Out a| -* monitoring of (long-lasting) execution of _OperationElement_ and updating events during execution - -|Monitoring, conditional, calculated events |Out a| -* e.g. when voiding some limits (e.g. stated by Qualifiers with expression semantics) - -|Infrastructure events |Out a| -* Booting, shutdown, out of memory, etc. of software entity of respective Referable (Asset Administration Shell, Submodel) - -|Repository events |In/ Out a| -* Change of semantics of IRDIs (associated concept definition) - -|Security events |Out a| -* logging events -* access violations, unfitting roles and rights, denial of service, etc. - -|Alarms and events |Out a| -* alarms and events management analog to distributed control systems (DCS) - -|=== - -*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, __Submodel__s, 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. - -.Event Scopes -[cols="32%,68%",options="header",] -|=== -|*Event attached to ...* |*Scope* -|xref:AssetAdministrationShell[AssetAdministrationShell] |This event monitors/represents all logical elements of an Administration Shell, such as _AssetAdministrationShell, AssetInformation, Submodels_. -|xref:Submodel[Submodel] |This event monitors/represents all logical elements of the respective _Submodel_ and all logical dependents. -|xref:SubmodelElementList[SubmodelElementList] and xref:SubmodelElementCollection[SubmodelElementCollection] and xref:Entity[Entity] |This event monitors/represents all logical elements of the respective _SubmodelElementCollection, SubmodelElementList or Entity_ and all logical dependents (value or statement resp.). -|xref:SubmodelElement[SubmodelElement] (others) |This event monitors/represents a single atomic _SubmodelElement_, e.g. a data element which might include the contents of a _Blob_ or _File_. -|=== - -== The Information Metamodel of the Asset Administration Shell (normative) - -=== Introduction - -This clause specifies the information metamodel of the Asset Administration Shell. - -An overview of the metamodel of the Asset Administration Shell is given in Subclause 5.1; Subclause 5.3 describes the classes and all their attributes in detail. - -The legend of the UML diagrams and the table specification of the classes is explained in Annex D and Annex E. Readers familiar with UML may skip the first clause in Annex E. It is however recommended to have a look at the specifics used in this modelling, especially those on dealing with model references. - - -==== -Note: an xmi representation of the UML model can be found in the repository "aas-specs" in the github project admin-shell-io *link:#bib51[[51\]]*: https://github.com/admin-shell-io/aas-specs/tree/master/schemas/xmi -==== - - -=== Overview Metamodel of the Asset Administration Shell - -This clause gives an overview of the main classes of the Asset Administration Shell (AAS) metamodel. - -Figure 10 shows the main classes to describe a single Asset Administration Shell. - -An Asset Administration Shell represents exactly one asset (_AssetAdministrationShell/assetInformation_). Type assets and instance assets are distinguished by the attribute "_AssetInformation/assetKind_". See Clause 5.3.4 for details. - - -==== -Note: the UML modelling uses so-called abstract classes for denoting reused concepts like "HasSemantics", "Qualifiable" etc. -==== - - -In case of an Asset Administration Shell of an instance asset, a reference to the Asset Administration Shell representing the corresponding type asset or another instance asset it was derived from may be added (_AssetAdministrationShell/derivedFrom_). The same holds true for the Asset Administration Shell of an type asset. Types can also be derived from other types. - -.Overview Metamodel of the Asset Administration Shell -image::image11.png[] - -An asset may typically be represented by several different identification properties like the serial number, the manufacturer part ID or the different customer part IDs, its RFID code, etc. Such external identifiers are defined as specific asset IDs, each characterized by a user-defined name, a value, and the user domain (tenant, subject in Attribute Based Access Control; _AssetInformation/specificAssetId_). See Clause 5.3.4 for details. Additionally, a global asset identifier should be assigned to the asset (_AssetInformation/globalAssetId_) in the production and operation phase. - -Asset Administration Shells, submodels and concept descriptions need to be globally uniquely identifiable (_Identifiable_). Other elements like properties only need to be referable within the model and thus only require a local identifier (_idShort_ from _Referable_). For details on identification, see Clause 4.3; details on _Identifiable_ and _Referable_ are provided in Clause 5.3.2.7 and Clause 5.3.2.10. - -__Submodel__s consist of a set of submodel elements. Submodel elements may be qualified by a so-called _Qualifier_. There might be more than one qualifier per _Qualifiable_. See Clause 5.3.2.8 and Clause 5.3.2.9 for details. - -There are different subtypes of submodel elements like properties, operations, lists, etc. See Clause 5.3.7 for details. A typical submodel element is shown in the overview figure: a property is a data element that has a value of simple type like string, date, etc. Every data element is a submodel element (not visible in the figure but implicitly the case, since _DataElement_ is inheriting from _SubmodelElement_). For details on properties, see Clause 5.3.7.12. - -Every submodel element needs a semantic definition _(semanticId_ in _HasSemantics_) to have a well-defined meaning. The submodel element might either refer directly to a corresponding semantic definition provided by an external reference (e.g. to an ECLASS or IEC CDD property definition) or it may indirectly reference a concept description (_ConceptDescription_). See Clause 4.4.1 for matching strategies, and Clause 5.3.2.6 for details. - -A concept description may be derived from another property definition of an external standard or another concept description (_ConceptDescription/isCaseOf_). _isCaseOf_ is a more formal definition of _sourceOfDefinition_, which is just text. - - -==== -Note: in this case, most of the attributes are redundant because they are defined in the external standard. Attributes for information like _preferredName_, _unit_ etc. are added to increase usability. Consistency w.r.t. the referenced submodel element definitions should be ensured by corresponding tooling. -==== - - -If a concept description is not just a copy or refinement of an external standard, the provider of the Asset Administration Shell using this concept description shall be aware that an interoperability with other Asset Administration Shells cannot be ensured. - -Data specification templates (_DataSpecification_) can be used to define a named set of additional attributes (besides those predefined by the metamodel) for an element. The data specification template following IEC 61360 is typically used for the concept description of properties, providing e.g. an attribute "preferredName". The _\<