AAS Submodel Templates

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 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.

The Submodel Handover Specification defines a standardized exchange format for information or documentation for a specific asset. The scope of this Submodel is to increase the interoperability between the parties that are exchanging asset documentation. These parties can be manufacturers of components or complete machines, or operators using these components or machines. In case a machine manufacturer sells a machine to a customer (operator), the manufacturer hands over the machine and its documentation in form of an AAS with the Submodel “Handover Documentation”. The documents provided can contain information required for e.g. 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 Communauté Européenne (CE) declarations of conformity, Atmosphères Explosives (ATEX) certificates, or material certificates. Besides the structure of a Submodel and the exchange format of an AAS, this Submodel standardizes the meta data that comes with the asset documentation and the classes that classify the type of the document. With these standardized meta data and classes, the asset documentation can be automatically integrated in the customer’s document management system, backend system, or any other system. The meta data as well as the classification classes of this Submodel are based on the VDI Guideline VDI 2770 Blatt 1 “Operation of process engineering plants – Minimum requirements for digital manufacturer information for the process industry” [7]. While the classification of documents according to VDI 2770 is mandatory, additional classification classes can be added.

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 [7], 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.

Software becomes more and more an essential part in manufacturing value networks, in smart manufacturing, and in smart products. For an effective and efficient use and management of such software, it is necessary to gather relevant information in a uniform representation. Use cases like updates, patch management, license management, audits, etc. rely on information regarding identification, sources and features of software. This information shall be provided in a consistent manner in form of a “nameplate for software”, derived and specialized from a common digital nameplate.

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. A time series is a series of data points in time order over a period of time. Time Series can represent raw data, but can also represent main characteristics, textual descriptions or events in a concise way. This Submodel template aims at an interoperable description of time series data in industrial automation for the complete asset lifecycle. The focus of this Submodel template is on the semantic information of time series data. The Submodel claims to integrate time series data within the AAS itself, but also from external data sources. Figure 1 shows the use cases, such as sensor data from real and virtual sensors, and their technical storage options inside or outside the AAS that were taken into account in the creation of this specification.

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 to standardize the description of a Service Request Notification that can be used to create a Service Request Notification for industrial assets, or the asset creates it via his Asset Administration Shell (AAS). These industrial assets, such as production lines, modules, infrastructure elements, and subsystems, are provided by value chain partners such as suppliers, equipment manufacturers, and system integrators. They are utilized in specific applications by industrial operators and end users.
A Service Request Notification is a request for a service to be performed, such as a maintenance, an inspection, or a return. The notification entry can be made by Asset Administration Shell (AAS), via a service dashboard, service portal or even through the customer service department by phone.
The Service Request Notification can be considered as a „call for help“, which, if the business partner responds to it, triggers the further service process.
The objective of the Submodel template is to define and standardize the Service Request Notification, including its content (properties, operations, etc.) and structure. Additionally, service types are defined.
The objective of this Submodel is to enable the interoperable exchange of these notifications between Asset Administration Shells, and the IT systems of various value creation partners.

This Submodel Template aims to provide hierarchical structures applicable to industrial equipment in an interoperable manner. For this primarily Entities and Relationship Elements of the AAS Metamodel are used.
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 subsystems down to material and component level, can include produced products and can be described on type or instance level.
The AAS contains Submodels that cover aspects of the assets among their life cycle. Already in the design phase, assets are composed and aggregated into newly created hierarchical structures.
Typically, assets have their own AAS (Entity with entityType “SelfManagedEntity“), but it is possible that an Asset has no AAS and is represented by a co-managed Entity.
Since nesting of AAS and Submodels is forbidden by the metamodel, this Submodel is intended to provide a description of the internal structure of an asset. It shall allow the consumer of an AAS to identify assets and their corresponding entities and find their respective AAS if they exist. The Submodel serves as an index, pointing to Assets (described as co- or self-managed entities) 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 hierarchical structures within an AAS during all lifecycle phases. Complementing information about each asset and their own lifecycle phase is enabled to be discoverable into the n-th level of the hierarchy and across the whole supply chain depending on the design of the Submodel Instance.

The engineering of a process plant is a complex multi-disciplinary and multi-organizational process involving exchange of a vast number of (semi-)standardized artifacts like diagrams, drawings, tables, certificates, and other documents.
One core artifact which is created and extended during the engineering process is the Piping & Instrumentation Diagram (P&ID) providing among others a good balance of abstraction between the physical layout of the plant (i.e., used equipment and piping connections) and its representation within the automation domain (i.e., signal types, tag names, logical connections between sensor and actuators). Due to this fact P&IDs are long-living artifacts which are frequently used during the whole plant’s lifecycle beyond the engineering phase [7].
Even though most engineering artifacts are created digitally, they are not necessarily exchanged in a machine-readable format. The lack of a machine-readable representation of engineering artifacts (including P&IDs) hinders the digital transformation and can be a show-stoper for digital use-cases due to high costs of creation of a machine-readable P&ID representation.
Efforts to create a standardized machine-readable exchange format for P&ID are made by the DEXPI working group of DECHEMA including of operators from multiple verticals, engineering companies, software tool vendors and research institutes. DEXPI [8] is an UML-Model implemented using an XML-based P&ID exchange format including multiple aspects of plant design like piping topology and its graphical representation, instrumentation structure, tag names. DEXPI is an open industrial standard aiming for a broad usage across industrial domains.
Due to the paramount role of P&ID during whole plant’s lifecycle, the importance of DEXPI has been identified by the Industry 4.0 community. Inclusion of DEXPI models into a standardized lifecycle information container – the Industry 4.0 Asset Administration Shell (AAS) – would facilitate links between different disciplines, organizations and industry domains. Mapping of DEXPI models to the AAS by defining an AAS Submodel template is governed by Industrial Digital Twin Association (IDTA) where a respective working group was founded in 2022. The group consists of representatives of the DEXPI working group, oil and gas industry, engineering and procurement companies, automation equipment suppliers, and research institutes.

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 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 Submodel template aims at interoperable provision of information, especially information for sizing electrical drive systems in industrial automation. For this purpose, the essential components drive, motor, gearbox, transformation, as well as their additional components are described, and the parameters necessary for the calculation are considered. Mechanical and electrical aspects are considered in the drive design. The Submodel specification addresses machine and plant manufacturers, manufacturers of drive components, and developers of sizing tools that exchange information for the use case of drive design. The objective of the drive design is to select suitable components based on movement patterns and system requirements.

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.

This Submodel template provides the means to exchange an asset`s Carbon Footprint (CF) between the partners along a value chain. The aim of this Submodel is to increase the interoperability between the parties, who are interested in documenting, exchanging, evaluating, or optimizing the environmental footprint of their assets. These parties can for example be manufacturers, users/consumers, or logistic partners. The CF might be part of larger initiatives such as the Digital Product Passport or the Product Environmental Footprint. It is not the scope of this Submodel template to substitute the relevant certificates. Use cases with increasing complexity are described in the following section. The first version of this document will focus on Use Case 1 and 2 only. Additional use cases will be supported in future versions.

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 „Provision of 3D Models“ 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

Example
• 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.

Provide detailed product and asset data based on ECLASS categories.

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.

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.

The planned submodel template is supposed to provide the necessary information regarding the inspection of steel products according to DIN EN 10204:2004 and DIN EN 10168:2004. Material tests performed on the product by the manufacturer or supplier are recorded in a test report, which is transmitted to the customer in paper or electronic form. If the product is represented by an administration shell, this instance-specific test report can only be stored as a document up until now. In addition, certain individual characteristic values from this can be only entered in a non-standardized manner, for example in the „Technical Data“ submodel. Immediate use of the data is not possible in the case of PDF, since the data is not stored directly within the model. For single values, the supplier and customer must decide on the modeling in advance, which may lead to the supplier having to provide many different submodel templates for the differing customers.
Our submodel template aims to structure this inspection data in a uniform manner and to store it with semantics so that both suppliers and customers have added value through direct usability and uniform representation. Traceability within the supply chain can also be improved as a result.
The submodel includes the necessary information starting from the business transaction, all the parties involved in it and the description of the product. Furthermore, the inspection specific information is provided. This includes general information regarding the inspection, the tensile test, the hardness test, the notched bar impact test, other mechanical tests, the chemical composition of the product and the steel manufacturing process.

The Submodel should be able to describe all relevant properties of a metal 3D printer
e.g.:
laser_powers=list(), # power [400., 700., 1000.]
laser_number=int(), # number 2
x_dimension=float(), # dimension of the build plate in mm in x-direction
y_dimension=float(), # dimension of the building panel in mm in y-direction
z_dimension=float(), # dimension of the building panel in mm in z-direction (height)
laser_mode=list(), # e.g. [green multimode 1000], # if [green multimode 1000
diameter=list(), # if cylinder
machine_manufacturer=str(), # SLM, TRUMPF
machine_type=str(), # type NXG XII 600, TruPrint 1000
laser_configuration=list(), # list(list()): laser power in use [[700, 1000], [700, 700], [400], [700], [400, 400]]
laser_configuration_mode=list(), # [„standard“, „green multimode“, „green laser“ ]
beam_focus_diameter_min=float(), # if both values are equal focus is not adjustable
beam_focus_diameter_max=float()

The aim of the Submodel „Creation and classification of materials in an ERP, PDM/PLM system“ is to ensure high data quality directly at the plant in leading systems. Through the structured provision of all important information about a component, the entire life cycle of a component from creation to disposal can be provided with high data quality for all processes.

The new EU regulation (2023 EU Battery Regulation) prescribes that LMT batteries, industrial batteries with a capacity of more than 2 kWh and EV batteries must be equipped with a Digital Battery Passport (DBP).
To implement this requirement technically, AAS technology could be used (see also DPP4.0 – ZVEI show case PCF@ControlCabinet).
The aim of this submodel is to develop a template that can be used to provide the data (static and dynamic) required for the DBP for the interoperability of battery-related data along the supply chain.

This Submodel template aims at interoperable provision of product change notifications between suppliers and users of industrial product types and items, particularly industrial components. These industrial product types and items are typically provided by manufacturers and suppliers, including dealers, and used by industrial users, e.g. original equipment manufacturers (OEMs), system integrators and producing enterprises (industrial end users). The product types are typically used to provide more than one product instance, however special cases such as mass-customization and engineer-to-order are applicable.

In the submodel Automation Engineering, information of engineering in the area of electrics, hydraulics, pneumatics and control (general automation engineering) is to be covered. Components of automation engineering are selected, structured, placed and connected in engineering tools. The model consistently continues the concepts of the AAS and transfers them to the engineering of plants and systems. As a link between the requirements definition of a resource and the actually used component and its installed instance, it makes a significant contribution. The objective is to make the existing information available to other software systems in a formally standardised form. This brings considerable added value to a large number of use cases over the life cycle if they are semantically processed. Among other things, collaborative engineering, derivations for production, maintenance and documentation are taken into account. The model will be based on relevant standards such as IEC 81346 and IEC 61355 as well as existing submodels such as Hierarchical Structures enabling Bills of Material and Generic Frame for Technical Data for Industrial Equipment in Manufacturing.

This submodel will define all the relevant parameters for plastics and rubber moulds, used for example with injection moulding machines.
The submodel will cover:
– Identification
– Engineering Data from the development process
– Configuration Data
– Process Optimization Data
– Collaborative Condition Monitoring
– Maintenance

This Submodel template aims at interoperable provision of information models for engineering authoring systems for the handover of industrial components. These industrial components are typically provided by manufacturers and suppliers, including dealers, and used by industrial users, e.g. original equipment manufacturers (OEMs), system integrators and producing enterprises (industrial end users). Industrial components can be described on type or instance level.
The aim of this Submodel is to digitialize and interoperably convey sets of information to faciliate and ease engineering tasks using such industrial components. Engineering authoring systems are considered all systems concerned with selecting, dimensioning, simulating, constructing and sketching industrial systems. For the time being, this document focuses on electrical and fluidic engineering.

Information model representing the engineering data to be exchanged within the engineering process of production systems representing the automation project configuration information of automation system devices relevant within ECAD and PLC engineering.

Information model representing the engineering data to be exchanged within the engineering process of production systems representing the structure and behavior of material handling system elements.

Information model representing the engineering data to be exchanged within the engineering process of production systems representing the the integration of production system engineering witth ERP and MES systems.

Information model representing the engineering data to be exchanged within the engineering process of production systems representing communication system elements.

Information model representing the engineering data to be exchanged within the engineering process of production systems representing the productzion system asset hierarchy.

Information model representing the engineering data to be exchanged within the engineering process of production systems representing information required by operators and maintenance staff.

Information model representing the engineering data to be exchanged within the engineering process of production systems representing layout planning results.

Information model representing the engineering data to be exchanged within the engineering process of production systems representing simulation data required for value stream, material flow or process simulation.

Information model representing the engineering data to be exchanged within the engineering process of production systems representing mechanical engineering.

Information model representing the engineering data to be exchanged within the engineering process of production systems representing electrical engineering.

Information model representing the engineering data to be exchanged within the engineering process of production systems required for virtual commissioning.

Information model representing the engineering data to be exchanged within the engineering process of production systems representing PLC programming results.

Information model representing the engineering data to be exchanged within the engineering process of production systems representing robot programming results.

Information model representing the engineering data to be exchanged within the engineering process of production systems representing building design data required within plant planning.

The proposed submodel template aims to provide a standardized description of the individual production processes and their routing in the electrolyser production.
On the one hand, It generally allows the process engineers to describe the production processes by specifying the required production resources and relevant parameters in a unified way as the inputs for the ERP and MES software. On the other, this submodel template focuses on the specific domain of electrolyser production.

Submodel of quality-relevant production and product characteristics for traceability of finished parts and all components.

Developed in cooperation with InterOpera. 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.

Developed in cooperation with InterOpera. 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.

Developed in cooperation with InterOpera. 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.

Developed in cooperation with InterOpera. 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. 

Developed in cooperation with InterOpera. 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. 

 Developed in cooperation with InterOpera. 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.

Developed in cooperation with InterOpera. 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.

Developed in cooperation with InterOpera. 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.

Developed in cooperation with InterOpera.
The objective of the „Workstation Matching Data“ submodel is to map the information required for the operation of a work unit, particularly with regard to the necessary qualifications, in a generic information model. The IEC 62264 series of standards is used to model the qualification-relevant information. In addition, the submodel contains the administrative data of the work unit, such as the identification of the work unit, the schedule of processing and the reference to a routing or production order. This can be used to request the appropriate qualified employees for the individual work tasks. The submodel is thus used for automated task assignment in real time, facilitating the integration of human beings into the production system.

Developed in cooperation with InterOpera.
The objective of the submodel „Computing Platform Resources“ is to represent platform (device) resources that are required for (re)deployment of the software. In the context of convertible production, different products can thus be manufactured on the same production line. The submodel supports the dynamic addition and removal of capabilities and devices in the production line and enables automated deployment of services/applications to be executed on available and suitable resources. The affected software services can be moved accordingly. To perform the reconfiguration and redeployment of the device-related software, the available platform resources are taken into account. Among other things, the following properties are described: CPU clock, number of CPU cores, RAM, hard disk space, real-time capability, OS, available technologies (virtual machines, containers, etc.).

Developed in cooperation with InterOpera.
The objective of the submodel „Drive Control for NC/CNC Machine Tools“ is to represent the information required for control parameterization in a standardized and structured manner. It enables automated commissioning and reconfiguration of NC/CNC controls for machine tools as well as a manufacturer-independent description of machine components. A common use is during commissioning/reconfiguring controls (NC, CNC) for machine tools, when a number of parameters must be stored. The latter describe properties of the installed machine components, such as kinematic, dynamic, mechanical and electrical properties, and are usually compiled manually from various sources across companies.

Developed in cooperation with InterOpera.
The submodel „Switching Relays for Integration in Automation Technology“ aims at the interoperable provision of relay data. This concerns, for example, the product data and the electrical and mechanical operating behavior of relays, which are relevant for planning, commissioning and maintenance, e.g. in high-voltage and low-voltage switchgear combinations. The description of the relays is available functionally and manufacturer-related in digital form. The data is part of group AAA147 of IEC 61360-4. The submodel is revised with the existing data fields from the IEC CDD, linked with ECLASS and supplements the existing models for the creation of digital twins in Industry 4.0 planning and construction (e.g. „Hierarchical Structures enabling Bills of Material“, IDTA, Number 02011, Version 1.0).

Developed in cooperation with InterOpera.
The submodel „Quality Control for Machining“ aims at an interoperable description of the quality control relevant data in the field of machining, which provides a comprehensive, structured and standardized data basis for the subsequent tasks of data analysis. On the one hand, the information and data relevant to quality control is presented in a structured manner, whereby the data structure and the required administrative data is summarized as general as possible, independent of specialist areas. On the other hand, the option to specify domain-specific features is included in order to provide the meta-information of specific standards as well as the test parameters and to allow the definition of other characteristics specific to the machining process.

Developed in cooperation with InterOpera.
The objective of the submodel „Purchase Order Creation“ is to represent orders regarding the purchase of production resources in a standardized way. It contains e.g. the meta information of the supplier, the identification number of the order, the status of the order, and the information about the receipt of goods as well as ordered goods. Instead of the free text item, the description of the ordered goods is provided in a structured format, e.g. via a product catalog with the order quantity, variants and price. The development of this submodel is synchronized with the InterOpera submodel projects „Purchase Request Notification“ and „Purchase Request Response“. The three submodels are used to address the entire purchase order process.

Developed in cooperation with InterOpera.
The objective of the submodel „Purchase Request Notification“ is to standardize the description of a procurement request that leads to the request notification. This submodel contains, for example, the meta information of the purchaser, the purchase order identification number, the delivery information and the information of the ordered resources. Instead of the free text item, the description of the ordered resources is provided in a structured format, e.g. via a catalog with the order quantity and the variants offered on the market. The development of this submodel is synchronized with that of the InterOpera submodel projects „Purchase Request Response“ and „Purchase Order Creation“. The three submodels are used to address the entire purchase order process.

Developed in cooperation with InterOpera.
The objective of the submodel „Purchase Request Response“ is to standardize the description of a response with the attached offer. This submodel contains, for example, the meta-information of the purchaser and supplier, the delivery information, the connection with the purchase request (through the submodel „Purchase Request Notification“) and the information of the offer. Instead of the free text item, the description of the offer is provided in a structured format, e.g. via a product catalog with the offer quantity, variants, and price. The development of this submodel is synchronized with that of the InterOpera submodel projects „Purchase Request Notification“ and „Purchase Order Creation“. The three submodels are used to address the entire purchase order process.

Developed in cooperation with InterOpera.
The objective of the submodel „Technical Data for Automated Guided Vehicles (AGV) in Intralogistics“ is to standardize the characteristics that represent the transport capabilities of an AGV (such as dimensions, payload, handling, etc.), building on the existing IDTA submodel „Technical Data“ (IDTA number: 02003, version: 1.2). The characteristics are compatible with the „factsheet“ specified in VDA 5050. This allows the data mapping of the partial model into the VDA 5050 protocol. In addition to this “factsheet”, the submodel contains the capability of the manipulator at the AGV, which is required for the planning of the intralogistics. The submodel addresses furthermore the characteristics that are indicated on the type plate of AGVs. In addition, the submodel investigates the possibility of standardizing the transport orders that are transmitted from ERP and WMS systems to line control or directly to AGVs.

Developed in cooperation with InterOpera.
The objective of the submodel „Technical Data for Fiber Optic Microduct Cabling for Broadband Expansion“ is to standardize the technical characteristics of micro tubes and their composites. This is due to the fact that although the planning and documentation of fiber optic lines is carried out digitally, the properties of the pipe assemblies into which fiber optic cables are blown after professional installation are not uniformly defined. This has so far prevented, for example, the comparability of their specifications across manufacturer boundaries and integration in planning according to the Building Information Model (BIM). Since the characteristics belong to the technical specifications, they are standardized in an extended submodel using the IDTA submodel „Generic Frame for Technical Data for Industrial Equipment in Manufacturing“ (IDTA number: 02003, version: 1.2) as a base. The standards DIN EN 60794-5-10, DIN EN 60794-5-20, DIN EN 50411-2-4 and DIN 47609 are taken into account.

Developed in cooperation with InterOpera. 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.

Developed in cooperation with InterOpera. 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. 

Developed in cooperation with InterOpera. 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.

Developed in cooperation with InterOpera. 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.

Developed in cooperation with InterOpera.
The submodel „Safety Function“ provides the machine-readable description of the hazards and operating states of the individual machines in a modular manufacturing system. It contains the data basis for automated verification and documentation of machine safety for plant and machine operators as well as for automated orchestration of intermodular (cross-machine) safety functions.

Developed in cooperation with InterOpera.
The submodel “Digital Calibration Certificate” is based on the globally recognized format for digital calibration certificates developed in cooperation with accredited laboratories. The core information is provided on measurement capabilities, measurement data quality and metrological traceability of sensor and device data. The submodel contains the description of a model for basic metrological core information based on existing standards for calibrations, e.g. DIN EN ISO/IEC 17025 as well as the specification also for test certificates as alternative traceability. Furthermore, it integrates the specification of general traceability data such as accreditation certificates as well as the specification of the procedure for calibration/testing, the factors influencing the result and the result of the test or calibration itself.

Developed in cooperation with InterOpera.
Within the scope of the project, several AAS submodels for injection molding operations are adressed, based on the already existing IDTA submodel „Technical Data“ (IDTA number: 02003, version: 1.2). The submodels aim at standardizing the minimum necessary features of technical data for injection molding operations, which can represent the technical capabilities of injection molding machines, injection molds and peripheral equipment. For example, a submodel „Technical Data for Injection Molding Machine“ specifies the common features of injection molding machines. Similarly, submodels for injection molds and peripheral equipment specify additional features. All targeted submodels provide manufacturers with the interoperable description of technical data that is clearly understood by other market participants such as system integrators and operators. A key added value of the submodels for operators is the minimization of the effort required for the technical feasibility check with regard to machine capability by the collection of the digitized and standardized characteristics of technical data.

Developed in cooperation with InterOpera.
The objective of the submodel „Data Model for Asset Location“ is to define a uniform information model of location data for an asset. Along with the use of different coordinate reference systems, a precise spatial location of assets is realized. Thus, a seamless localization is to be mapped, which includes outdoor coordinates based on global coordinate reference systems as well as indoor coordinates based on local coordinate reference systems. Furthermore, the 3D aspect is taken into account in order to be able to integrate height information as well. The submodel standardizes the physical localization of assets for various industrial and logistical use cases. For example, it allows the interoperable exchange of location data between manufacturers and freight forwarders in cross-location logistics.