Gestalten Sie die Zukunft der Industrie 4.0 aktiv mit und seien Sie beim Digitalen Zwilling immer am Puls der Zeit.
Werden Sie jetzt Mitglied in der IDTA!
Startseite / Content Hub / Teilmodelle
Submodels (Teilmodelle) bilden den Inhalt der Asset Administration Shell. Sie beschreiben inhaltliche oder funktionale Aspekte eines Assets. Finden Sie hier die Übersicht der offiziellen IDTA Submodel-Templates.
Sie möchten eigene Submodel Templates entwickeln oder bei der Entwicklung an einem der genannten Submodels Templates mitarbeiten?
Den Erstellungsprozess finden Sie hier. Bei weiteren Fragen nehmen Sie gerne Kontakt mit uns auf.
Jedes Submodel-Template, das den IDTA-Review durchläuft, erhält zur eindeutigen Zuordnung eine IDTA-Nummer. Folgende Nummernbereiche sind definiert:
Within the modular production, module instances are called Process Equipment Assembly (PEA). Module Type Package (MTP) is the integration technology for production modules within the modular production. MTP definies the communication interface towards the PEA and the representation of these interfaces within an MTP file. Per definition this file exclusively contains type-specific module information.
The submodels defined in this document describe the integration of PEA (instance) and MTP (type) information into an AAS. The models do not intend to cover asset aspects addressed by further submodel definitions like technical data or digital nameplate. Therefore, introduced models should be used along with mentioned ones to complete the AAS of the respective asset.
This Submodel template aims at interoperable provision of contact information in regard to the asset of the respective Asset Administration Shell. Central element is the provision of properties, ideally interoperable by the means of dictionaries such as ECLASS and IEC CDD (Common Data Dictionary). The purpose of this document is to make selected specifications of Submodels in such manner that information about assets can be exchanged in a meaningful way between partners in a value creation network. It targets equipment for process industry and factory automation by defining standardized meta data.
The intended use-case is the provision of a standardized property structure for contact information, which can effectively accelerate the preperation for asset maintenance.
This concept can serve as a basis for standardizing the respective Submodel. The conception is based on studies of common practices at enterprises.
Beside standardized Submodel this template also introduces standardized SubmodelElementCollections (SMC) in order to improve the interoperability while modelling aspects of contact information within other Submodels.
This Submodel template aims at interoperable provision of technical data describing the asset of the respective Asset Administration Shell. Central element is the provision of properties, ideally interoperable by the means of dictionaries such as ECLASS and IEC CDD (Common data dictionary).
The intended use-case is, that a manufacturer of industrial equipment describes assets (type or instance), which are provided to the market, by the means of technical data (properties), which are interoperable and unambiguously understood by the other market participants, such as system integrators or operators of industrial equipment. For providing individual industrial equipments to the market, also a supplier is covered by the use-case (for this purpose seen as functioning as manufacturer).
This Submodel template specifies a basic set of SubmodelElements in order to bring about the necessary information according to this use-case.
This Submodel template aims at interoperable provision of information, especially documentation, from manufacturers to operators of industrial equipment. It primarily targets process industry but is also suitable for equipment in factory automation by defining standardadized meta data and a classification for documents. The hereby provided documents contain information required for correct design, installation, commissioning, spare parts stocking, operation, cleaning, inspection, maintenance and repair. In addition, there are legal regulations that stipulate the existence of certain manufacturer documents, such as CE declarations of conformity, ATEX certificates or material certificates. The transfer of this information to the IT systems of the plant operators is standardised in order to minimise the effort for manufacturers and operators.
This Submodel template specifies a basic set of SubmodelElements in order to bring about the necessary information according to VDI 2770-1.
The presented Submodel allows the interoperable provision of simulation model files for an asset via the asset administration shell. The Submodel enables this for a wide range of simulation model types and simulation purposes. It contains information about the type of model, how to use the model, and the areas of application.
The main underlying class of models for this Submodel are DAEs, models described by differential algebraic equations. However, models of other types, such as CAD, FMEA, etc., can also be described. FEM type models are not considered explicitly, they will be covered by another Submodel by interest. The models described by this Submodel may be provided in ASCII or binary form to be used with a specific simulation software (e.g. Matlab/Simulink, Virtuos, etc.), as source code (e.g. C, Modelica, etc.), or in a model exchange format such as FMI.
It describes rudimentarily the content of the model.
Assets, where you can provide simulation models via AAS, can be passive parts, active devices, subsystems, machines or even production plants. When using this Submodel template, it is requiered that the asset for which a simulation model should beprovided has an AAS. That is, if there are no AAS yet, first an asset-ID needs to be defined and an AAS created. A Submodel can then be added to this AAS.
In the first step, the Submodel supports searching and finding, as well as requesting simulation model files from manufacturers or distributors.
In further steps, the Submodel will also support the automatic integration of a model into a specific simulation environment, up to an automatic generation of an overall simulation based on structural descriptions of a system containing different components. As it is possible with e.g., the Submodel candidate for hierarchical structures enabling “Bills of Material” (BoM).
This Submodel template aims to provide asset nameplate information to the respective Asset Administration Shells in an interoperable manner. Central element is the provision of properties , ideally interoperable by the means of dictionaries such as ECLASS and IEC CDD (Common Data Dictionary). While in the current version an IRI is provided for a small quantity of the specified properties as their semantic identifier, a complete harmonization of all properties is planned for the subsequent version 2.1. The purpose of this document is to make selected specifications of Submodels in such manner that information about assets and their nameplate can be exchanged in a meaningful way between partners in a value creation network. It targets equipment for process industry and factory automation by defining standardized meta data.
The intended use case is the provision of a standardized property structure within a digital nameplate, which enables the interoperability of digital nameplates from different manufacturers.
This concept can serve as a basis for standardizing the respective Submodel. The conception is based on existing norms, directives and standards so that a far-reaching acceptance can be achieved.
Beside standardized Submodel this template also introduces standardized SubmodelElementCollections (SMC) in order to improve the interoperability while modelling partial aspects within Submodels. The standardized SMCs include address and asset product marking.
This Submodel template aims at interoperable provision of information describing the nameplate of the asset of the respective Asset Administration Shell. Central element is the provision of properties, ideally interoperable by the means of dictionaries such as ECLASS and IEC CDD (Common Data Dictionary). The purpose of this document is to make selected specifications of submodels in such manner that information about assets and their nameplate can be exchanged in a meaningful way between partners in a value creation network. It targets equipment for process industry and factory automation by defining standardized meta data.
The intended use case is the provision of a standardized property structure within a digital nameplate, which enables the interoperability of digital nameplates from different manufacturers.
This concept can serve as a basis for standardizing the respective submodel. The conception is based on existing norms, directives and standards so that a far-reaching acceptance can be achieved.
Beside standardized submodel this template also introduces standardized SubmodelElementCollections (SMC) in order to improve the interoperability while modelling partial aspects within submodels. The standardized SMCs include address and asset product marking.
In the context of Industrie 4.0, software as an asset becomes increasingly important. For an effective and efficient use and management of software in manufacturing value networks, in smart manufacturing, and in smart products, it is necessary to gather relevant information in a uniform representation, as a “nameplate for software”. This supports use cases like updates, patch management, license management, audits, etc.
This Submodel template specifies a basic set of SubmodelElements in order to describe the necessary information.
A time series is a series of data points in (regular or non-regular) time order over a period of time. Time Series can represent raw data with actual values, but can also represent main characteristics in a concise way. For example, two equal values within a time series can have different meanings, depending on whether they are in a rising or falling curve. In the same way, whole subsequences of a time series can be of importance, whereas intermediate sequences only represent unstructured data.
In Industrie 4.0, the ubiquity of data sources and sensors and low costs of storage has resulted in increasing amounts of time series data being captured – not only during the operational phase of an asset. This Submodel template aims at an interoperable description of time series data in industrial automation for the complete asset lifecycle to fit time series into a big holistic picture and to obtain a better understanding of complex systems that produces and processes time series data.
The focus of this submodel template is on the semantic information about the time series and its storage within the asset administration shell, as many techniques, data formats and methods have already been developed to process, store and analyse time series data in external systems. The submodel claims to integrate time series data within the asset administration shell itself, but also from external data sources.
To enable the discovering of time series, every AAS that provides time series should have this submodel. In addition, elements of this submodel specification may be used or referenced in other submodels or submodel element collections.
Content describes data of an OPC UA Server (provided with an asset).
This includes information to find and access the OPC UA server and information about the content implemented in the OPC UA server (used Namespaces, implemented Profiles/Facets/CUs, …) and information about other sources where descriptions are available.
Content could be updated while provisioning and installation.
This Submodel template aims at interoperable provision of information, that can be used to generate a Service Order in an ERP System.
This Submodel template aims at interoperable provision of hierarchical entities and relations which are applicable for industrial equipment. This industrial equipment, for example production lines, modules and sub systems, are provided by partners in the value chain, such as suppliers, equipment manufacturers and systems integrators and used in specific applications by industrial operators and end users, both in factory as also process automation. Industrial equipment can be composed of sub systems down to material and component level, described on type or instance level and can include produced products.
The AAS models assets thoughout their lifecycle. Already in the design phase, assets are composed and aggregated into hierarchical structures. As some assets are parts of larger assets, they may each have their own AAS. Since nesting of AAS and Submodels is forbidden by the meta-model, this Submodel shall describe the internal structure of an asset. It shall allow the consumer to identify components and find their respective AAS if they exist. The Submodel serves as an index pointing to Assets and AAS in a distributed network capable of transcending the limits of a single organization.
Instances of this Submodel Template shall be the authoritative source for topological structure within an AAS during all lifecycle phases. Complementing information about each component and their own lifecycle phase shall be made discoverable into the n-th tier, depending on the design of the Submodel Instance.
Proposal for AAS-submodel to package and transfer P&I-Diagrams packaged according to the DEXPI-Standard.
The submodel shall specify the functional safety and reliability data model descriptions for devices to be used by engineering tools for the design of safety related control systems according to IEC 62061, IEC 61508-2 or ISO 13849-1 or for dependability analysis of electrotechnical systems. This submodel is used to facilitate the exchange between computers of data characterizing safety relevant devices in particular. The data models described in this document is based on the definition in the IEC/CDD 62683-1 DB.
The scope of this Submodel is the definition of type-specific information of a Control Component (CC) into an AAS. Together with its counterpart, the CCInstance Submodel (IDTA 02016), both Submodels aim to establish templates to ensure a uniform structure. The use of these templates allows the development of manufacturer- and domain-independent control concepts and facilitates the exchange of process information with other Submodels. Additionally, it allows the use of standardized call and monitoring sequences, as well as standardized description of its services, endpoints, error-codes, etc.
The scope of this Submodel is the definition of instance-specific information of a Control Component (CC) into an AAS. Together with its counterpart, the CCType Submodel (IDTA 02015), both Submodels aim to establish templates to ensure a uniform structure. The use of these templates allows the development of manufacturer- and domain-independent control concepts and facilitates the exchange of process information with other Submodels. Additionally, it allows the use of standardized call and monitoring sequences, as well as standardized description of its services, endpoints, error-codes, etc.
Standardization of the structure and semantics required to interact with an asset or service, e.g., to request/subscribe to specific data points or to perform operations based on communication protocols such as Modbus, OPC UA, HTTP, and MQTT. The W3C Web of Things Thing Description is considered to have a base line for content and structure for submodule definition.
Submodel for the transfer of all relevant information regarding maintenance (maintenance instructions/maintenance steps, required maintenance materials, maintenance intervals, …) for integration into various higher-level maintenance software/systems. Standardization of the transfer of maintenance information to plant or machine manufacturers, or to plant operators and service organizations.
The submodel describes the plant asset management aspects of production plants in the process industry. It refers to the condition and criticality of assets in production processes, as well as to functions and methods for providing all relevant information to asset managers. It also forms the basis for the development of PAM methods.
Submodel to express capability definitions of a production resource, allowing to connect capability definitions and their properties from ontologies/catalouges to executable skills and their parameters.
The objective of the drive design is to select suitable components based on movement patterns and system requirements. Major components that are described: Sizing Project: Identifying characteristics of the sizing project with reference to the sizing project file. Customer Requirements: • Motion and load profile: The specified motion sequence and the calculated motion, taking into account the workload and customer specifications. • Environmental: Environmental conditions in which the drive train is to be operated. • System Requirements: The features required by the customer in the selection of individual components and in the consideration of the overall system. Transformation mechanisms: Mechanisms for transmitting the force in the drive task, such as belt or rack and pinion applications. Sizing Results: Bill of Material: Simple list for ordering the individual components. Utilization Rates: Technical data of the drive components and their utilization rates in relation to the requirements in the motion profile.
A crucial part of highly interconnected I4.0 systems is the wireless communication system (WCS). Therefore, it has to cope with the level of adaptability required by I4.0 and, should not be planned and installed for worst-case scenarios as in the traditional systems. It means that if changes are necessary, the WCS and/or its use of the medium should be adapted accordingly. It includes changes due to the production process requirements or changes due to external disturbances, for example, interferences. For that, WCS should be capable of self-configuration to adjust itself to the possible changes.
To reach this capability, a collaboration between the production system and WCS is necessary. To enable this collaboration between the parties, it is proposed a digital twin approach. In this approach, data exchange between the production system and the WCS in the digital domain is required. For that it is necessary that the relevant parameters of WCS are also considered when developing the AAS of assets. The AAS must have a submodel that contain all relevant information related with wireless communication. This information will be used in the digital domain to manage communication resources.
Among the submodels and properties proposed, there is the submodel TransceiverFunction. Two submodels element collection are defined within this submodel element: Transmiter and Receiver. Under these two elements are properties as bitrate, modulation type and receiver sensitivity. A management system can use information from the AAS related to the wireless signal as RSSI and RSRP to monitor the conditions of the radio channel. The management system can take actions based on these values.
Due to new regulations, carbon pricing and increasing requirements for the sustainability of manufactured products, the need for a way to determine the carbon footprint of manufactured products (PCF) as well as the provision of information about the carbon footprint over the entire supply chain is also increasing. The goal is to create a sub-model to enable sharing and low-effort retrieval of carbon footprint information per product across the entire supply chain. Existing standards are to be taken into account.
Generic integration of material and product information as an ontology to provide a uniform data model on needed usage levels in different steps.
The objective is to propose a model for the definition of AAS for industry-specific assets of batch-manufactured products based on the ISA 88 standard, which makes it possible to digitally represent information related to the production recipe, as a step towards the digitization of the product life cycle. The ultimate goal is use the data obtained by the AAS to execute blockchain-based smart contracts that validate compliance with the technical specifications of the product.
This AAS Submodel Template „3D CAD“ aims to provide fully functional 3D CAD files (either directly embedded or referenced) and 3D CAD related properties in a software vendor independent way.
The intended use case is, that an industrial equipment manufacturer can fully integrate 3D CAD files and properties of product types or instances of an asset in the format required by his specific tool landscape, without loss of information, performance and features, like it’s the case with formats like STEP (ISO 10303).
During development of „Asset Interfaces Description“ SM it became clear that a separation of responsibilities is necessary to describe asset interfaces and to configure DT interactions with them.
Separation of responsibilities
• Asset Interfaces Description SM
– Describes available interfaces of an asset
– Is developed by asset provider
• Asset Integration Configuration SM
– Describes how to configure a DT connector to an asset’s interface
– Is developed by asset user
• A DT of a machine must integrate data from the machine
– Asset Interfaces Description SM in DT of machine by machine provider
– Asset Integration Configuration SM in DT of machine by machine user
• A DT of a product must integrate product specific data from a machine manufaturing the product
– Asset Interfaces Description SM in DT of machine by machine provider
– Asset Integration Configuration SM in DT of product by machine user = product manufacturer
Modeling of the information needed for the security engineering of process automation plants.
Model structure for the (runtime) representation of platform (device) resources such as memory and CPU capacities, available communication infrastructure, etc.
The platform resources submodel enables a uniform representation of the platform resources for different use cases. For example, this information is required to analyze the real-time capability of a deployment as part of a “what-if” analysis.
In this project the conventional data sheets of power semiconductors that include information about their electrical, mechanical and thermal properties are to be amended into a machine-readable format within the framework of a submodel of the Asset Administration Shell with a focus on the transmission of data sheet curves. This enables more advanced functionalities (e.g. manufacturers of power semiconductors can provide larger data sets to customers (possibly by service level); data sets can also be extended by additional measurements on trusted sources; manufacturers of simulation environments can also access the machine-readable formats and automatically parameterise simulation models). The ability to link data sets with confidentialities offers further advantages, since manual processes for releasing data sets only have to be carried out once. This includes not only the aspects of which data should be available to whom, but also the release and thus the trustworthiness of a checked data set.
This scope may be linked to the submodels of electric drives and components: ECLASS 27-02 and 27-26. With regard to product-specific IEC standards, there are links to IEC 60747-2 Power diodes, IEC 60747-6 Thyristors, IEC 60747-8 MOSFET, IEC 60747-9 IGBT, IEC 60747-15 Isolated power modules.
The submodel „Digital Standards Datasheet“ aims at providing information and meta-information at the document level of a standard, so that the partners in a value network can acquire, exchange and apply standards interoperably. The aim is to enable the automated implementation for example of the following use cases:
1. finding suitable standards for the certification of developed products,
2. identification of predecessors and successors of a standard, and
3. determination of international conformities of a standard.
The submodel „Software Package Manager“ aims at vendor-independent automated software package management in automation technology based on IEC 61131. It contains, in particular following IEC 61131-3, all necessary information required for an automated software package management and an associated automated dependency and version management. In addition, the submodel includes information about different package sources in order to avoid a single source vendor lock-in for users via the package management. The generally required information structure is derived from the known management systems from the world of high-level language technology such as npm, pip, nugget or also proprietary proprietary mechanisms on the market from the IEC 61131 world (if the providers agree) will be adapted.
The submodel „Facility Related Environmental Data“ aims at establishing a submodel with standardised, interoperable environmental data for the asset „facility“ (industrial plant/operation/site) for a wide range of use cases in practice and with regard to implementation of EU legal requirements, such as those resulting from the European Green Deal.
The environmental data sets are based on the environmental regulations applicable at EU and national level and the resulting reporting and disclosure requirements for companies in relation to „facilities“. With regard to the creation of the submodels, reference can be made to the preliminary work from the research project „Digital harmonisation and availability of environmentally relevant data in the context of the digital transformation of industry and the associated processes and services“ (2019-2022), commissioned by the Federal Environment Agency.
The submodel „Product Related Environmental Data“ aims at establishing a submodel with standardised, interoperable environmental data for the asset „product“ (EU internal market) for a wide range of use cases in practice and with regard to implementation of EU legal requirements, such as those resulting from the European Green Deal.
The environmental data sets are based on the environmental regulations applicable at EU and national level and the resulting reporting and disclosure requirements for companies in relation to „product“. With regard to the creation of the submodels, reference can be made to the preliminary work from the research project „Digital harmonisation and availability of environmentally relevant data in the context of the digital transformation of industry and the associated processes and services“ (2019-2022), commissioned by the Federal Environment Agency.
The submodel „iiRDS Handover Documentation“ defines the integration of usage information in Industrie 4.0-compliant environments. It is to be established as a metadata model for intelligent information based on the existing IDTA submodel „Handover Documentation“, the guideline VDI 2770 and the iiRDS standard to enable cross-manufacturer provision, exchange and aggregation of usage information. This allows intelligent, format-independent linking and efficient use of technical documentation from different manufacturers in machines, plants and smart factories. The delivery format with a defined but extensible metadata model enables the use of different technical and individualised systems that are already used to create technical documentation and usage information including established content management systems.
The aim of the submodel „Vulnerability Management“ is to establish a clear assignment between vulnerabilities, safety instructions and components used in an industrial plant. In doing so, the CSAF standard can be applied to avoiding duplicate structures. For instance, the submodel may contain the meta-information, the uniform data structure and the information about the vulnerabilities and safety instructions specified by the component manufacturers.
Note: The vulnerability assessment follows the CVSS standard and refers to the corresponding entries in the public registers, such as National Vulnerability Database and VDE CERT. As a rule, the security advisories are created in the open JSON-based CSAF format. Existing references for information exchange of vulnerabilities and security advisories are taken into account, such as Common Security Advisory Framework.
The submodel „Vulnerability Management“ has a wide range of applications; in particular, it enables the resource-saving identification and the unambiguous, machine-readable description of security-relevant vulnerabilities and the corresponding countermeasures for industrial plants. This can significantly increase IT security.
The submodel „Software Bills of Material“ represents a formal, machine-readable inventory of software components and their dependencies, as well as information about these components and their hierarchical relationships. The mandatory features of the submodel enable unambiguous identification of the individual software components. Optional features are defined to support extended use cases. The current standardised formats for interoperable exchange of the Software Bill of Material are taken into account in the development of the submodel. The submodel is based on the results of the IDTA submodel „Hierarchical Structures enabling Bills of Material“.
The submodel offers numerous advantages for the use cases in the collaborative value chains, e.g. in software development, supply chain management, vulnerability management, asset management, procurement, etc.
The aim of the submodel „Artificial Intelligence Dataset“ is to unambiguously identify and explain the data/dataset artefact that is used to train and thus instantiate an AI model. In addition to a unique identification of the data/data set artefact, e.g. by a type of ID, further properties and characteristics in the form of a self-description are useful. These include, for example, relevant parameters, details and references to the origin of the data used to train an AI model. Here, for example, information about a data source (industrial installation, database, etc.), details about access or query parameters may be included. On top of that, a basic description of the data series contained in the data artefact with a description of the data type and the number of data points per data series can be of a great advantage here. As an added value, data aggregation in data sets can thus be simplified, since the available plant data can be integrated directly as data sources via the Asset Administration Shell and used for data preprocessing in a standardised manner.
The aim of the submodel „Artificial Intelligence Deployment“ is to describe all relevant meta-information and details relating to the operation of an AI model. On the one hand, this should include information about the runtime and dependencies that are required for the pure operation of the AI model. On the other hand, further information need to describe the requirements for the deployment of the AI model on a target platform, for example through quality-of-service specifications. If all this information is available for an AI model, an automatic comparison of the requirements with the available platform resources (e.g. described by the IDTA submodel „Platform Resources“) is possible, which in turn enables an automatic, optimal and dynamic deployment of AI models.
Furthermore, the submodel shall illustrate the format of input data for AI inference, referencing other corresponding submodels of industrial plants as the data source. It shall also describe how the raw data and the results are handled after the AI inference. With the help of this submodel, the operation of an AI model can be fully described, which will accelerate the deployment of an AI model and enable autonomous interaction between the AI deployment and production.
The aim of the submodel „Artificial Intelligence Model Nameplate“ is the unambiguous identification and explanation of an AI model artefact by the self-description of the properties and characteristics of the AI model. Relevant features for the submodel include an ID, a (machine) readable name, versioning, the type of model, the class of training algorithm applied, the data structure, the input and output data of the AI model, the intended use, validity, reliability and others. This can also include the artefact in the form of a binary file or the specification of the interfaces through which an instantiated and running AI model can be accessed. The mapping of further information, such as about the dataset used for training or the infrastructure required for the operation of the AI model, shall be verified. The submodel has to take into account the existing IDTA submodels such as „Digital Nameplate“ and „Software Nameplate“.
Through the clean identification of AI models as well as their history (from data to provision), AI models can be used in processes requiring documentation. In addition, identification mechanisms will facilitate transparency in IT systems for management and deployment, similar to a software nameplate. The ability to store parameters and properties with e.g. binary files in an AASX file will thus result in an „all-in-one“ exchange format for AI model artefacts.
In the „Predictive Maintenance“ (PM) submodel, the PM process and the information of the relevant subprocesses shall be mapped in a structured way according to the relevant standards such as IEC 63270 „Industrial automation equipment and systems – Predictive maintenance“. The goal of this work is not to develop a concrete PM solution, but standardised templates and metadata that enable the implementation of PM for the relevant use cases. In addition, thorough investigations should be carried out with regard to the linkage to other relevant submodels, in particular to the IDTA submodel „Maintenance“.
For example, in plastic injection molding, the submodel should help to identify machine downtimes, initiate measures and reject inefficient processes at an early stage.
The content of the submodel is intended to provide the necessary and basic information for the production of the wiring harness. The production of the wiring harness is peppered with manual processes and a comparatively low level of digitization or automation. By using the AAS and a corresponding submodel, interoperable and automated data provision should be made possible.