AAS Submodel Templates

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.

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 (DPP) 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. Version 1.0 of this document will focus on Use Cases 1,2, and 3. Additional use cases will be supported in future versions.

The proposed submodel template designed to enable an optimally energy-flexible operation across systems within industrial enterprises and to facilitate the communication of energy flexibility between industrial companies and energy market-related services.
The model provides a generic description of energy flexibility, focusing on a minimal set of parameters and metrics, but encompassing technically and energetically relevant information necessary to describe energy flexibility. It serves as a central foundation for communication within a company unit as well as externally with software applications (services) mediated via a marketplace platform. It does not aim to create a digital twin as a virtual and fully realistic representation of energy flexibility. This approach limits the complexity and volume of exchanged information while avoiding the exchange of sensitive production and process data.

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). 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 addition to the general information for Industrial Equipment listed in this document, it may be necessary to supplement the digital nameplate with additional information for specific areas of application, e.g. for explosion safety or radio. Information for the digital nameplate for additional areas of application are defined in supplementary Submodel templates.

Companies collect data/information from their suppliers and must provide data/information to their customers for whom they are suppliers. The information must then be maintained in the course of supplier qualification.
The following information is required:
– Contact details
– Business figures, from the annual reports
– Account data
– Identification numbers, e.g. for taxes
– logo
– Certificates and declarations and their metadata

All companies that have suppliers that need to be qualified and/or have customers that qualify and maintain their suppliers are affected.

As the information can relate to groups of companies, but also to locations, e.g. for production and sales, the mapping of the entities for which a submodel can be specified and how these can be related must also be described.

• The submodel should contain a template to store one or more production calendars of mimeType iCalendar (RFC 5545).
• The iCal format is very abstract and isn’t enough specified for industry requirements. For this, necessary variables, describing the content of the production calendar, will be specified by the working group.
• A Management Execution System and a value chain simulation can use the calendar submodel to exchange information like the shift schedule of a machine and execute operations on it.

The submodel should improve and standardize the process to connect a machine to a manufacturing execution system (MES).
• It contains header information like the endpoint of the machine and process variables that are relevant for a MES regarding to the VDMA 66412-10.
• The process variables are built of one or more machine signals like the process variable “production” can consist of the machine signals “Override > 80 %” and “Door closed”.
• The computing rules of the process variables will be described in the Submodel with a script language, e.g. SCL (Structured Control Language).
• The machine signals will be referenced through the Asset Interfaces Mapping Configuration and Asset Interfaces Description Submodel.
• The Submodel should be delivered by the machine manufacturer to the machine user.

The main goal is to propose submodels consisting of safety list of properties (SLOPs) of safety instrumented functions (SIF) in alignment with IEC 61511.
The SLOP included in this new submodel can then be aligned with and integrated into the IEC CDD. The submodel template will build on the work of two ongoing initiatives: 1) results from the Norwegian joint industry project named Automated process for follow-up of safety instrumented systems (APOS 2.0), including an UML model developed with basis in requirements and definitions in IEC 61511. 2) Results from the NAMUR WG1.3 on Information Management and Tool who is developing a similar UML model. Alignment activities have been carried out between NAMUR and the APOS 2.0 project, and we would like to involve persons from both organizations in preparing the details of the proposed new submodel templates.
Although this specific proposal pertains particularly to establishing thesubmodel for safety instrumented function (SIF), we recognize the need for expanding our scope to establish a set of relevant submodels under the domain of ‘functional safety for process industries’, for example:
-Submodel for safety instrumented system (SIS) components
– Submodel for SIS subsystems
– Submodel for Safety requirement specification (SRS)
– Submodel for data collection in SIF operation.

Information model that describes the interfaces of an asset that are planned or integrated as part of the engineering process of production systems. This includes all kind of connections including: electrical, mechanic, pneumatic etc.

Interoperable representation of all explosion protection features and markings regardless of the certification system.

This Submodel describes a common representation of data retention policies that can be applied to elements in the Asset Administration Shell via semantic identifiers. Based on this information, it is possible to automate the reduction, archiving, or removal of data stored in the Asset Administration Shell. Such data can be, for example, raw sensor data, large images, sensitive data, or any data that becomes obsolete over time.
A data retention policy defines how long data must be stored before it may be deleted. It also provides information about the policy provider, the specific requirement or law that enforces the policy, and the timeframe between which the policy is in effect. Additionally, the authorship of each policy can be traced through an audit log, in which all changes to the policy are documented. Based on this information, an automated service can apply and validate each policy against the data stored in the Asset Administration Shell and reduce, archive, or remove the data as necessary.
This Submodel allows a set of policies to inherit from another set of policies so that an existing policy can be extended or adjusted to more specific use cases. For example, business policies may be overridden or extended by contracts with more specific policies or longer retention periods.
The enforcement of data retention policies described by this Submodel are outside the scope of this document.

The submodel represents an interoperable list of spare and consumable parts of an asset that are required for the repair, maintenance or regular operation of a specific product, device or system. The purpose of this list is to provide a clear overview of available spare parts and consumables to ensure the smooth running of repairs and maintenance operations.

The benefit of such a list is that it enables technicians, maintenance personnel or even end users to quickly identify and procure the required parts. This contributes to efficiency by minimizing downtime and ensuring effective maintenance. The list also supports stock management by enabling accurate inventory control and timely reordering.

The replacement and successor product submodel refers to a new product that either replaces or improves the obsolete asset or asset that is no longer available. It is intended to inform the user of a suitable replacement or successor product depending on the discontinuation status of the existing product.

Possible content:
– Discontinuation status of the current product, incl. last order and repair date
– AssetId, product name and model number of the replacement and successor product
– Comparison with predecessor product (improvements, …)

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.

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

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.

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.

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

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 PLC programming results.

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

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 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 layout planning results.

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 the productzion system asset hierarchy.

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 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 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 automation project configuration information of automation system devices relevant within ECAD and PLC engineering.

The Submodel “Creation and classification of materials in an ERP, PDM/PLM and PIM system” has been designed to provide a standardized interface for the creation and classification of materials across various system environments. Its aim is to ensure a consistent and efficient process for the creation and classification of material data within Enterprise Resource Planning (ERP), Product Information Management (PIM), and Product Lifecycle Management (PLM) / Product Data Management (PDM) systems. A Material Master must exist as an object so that Classifications to this Material can be assigned correspondingly.

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()

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

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.

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.

The material flow in the factory will increasingly be driverless and autonomously controlled. With the growing penetration of production with AGVs, these will also take on very specific transport, handling and, with the right setup, possibly also assembly or manufacturing tasks.
Suppliers of AGVs will continue to develop specific capabilities and features for their vehicles and possible attachments. This will inevitably lead to the situation where different types of vehicles and vehicles from different manufacturers have to be operated in one production environment. These mixed fleets have to be integrated in the overall driverless transportation system and controlled via a central or decentral control system. In most cases this control system will be linked to the ERP or MES system where it is receiving the transportation orders from. Control systems can be proprietary systems of the vehicle supplier or manufacturer-independent systems. With increasingly mixed fleets in operation manufacturer-independent control systems will be more widespread on the market.
Against this background, a digital twin in the form of an AAS for the vehicles is to form the data basis for the integration of the individual vehicles into an overall system. The Submodel “Technical Data for Automated Guided Vehicles in Intralogistics” aims to identify the necessary information for integration and standardize it with an AAS Submodel specification. In addition to the integration aspect in an overall system during the engineering phase, the Submodel should also take into account technical data needs for commissioning, operation and maintenance.

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

This Submodel template aims at interoperable provision of information describing the “Control configuration and parametrization for NC/CNC machines” in regard to the asset of the respective AAS. 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 people who are commissioning or integrate Computerized Numerical Control (CNC) machines. Therefore, they need data to parametrize the CNC control.
The intended use-case is the provision of a standardized property structure for Control configuration and parametrization for NC/CNC machines, which enables an easy access of data, which is needed to configure or parametrize a CNC controller.
This concept can serve as a basis for standardizing the respective Submodel. The conception is based on existing norms, studies of common practices at enterprises, 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 aspects of Control configuration and parametrization for NC/CNC machines within other Submodels.

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

The focus of the Submodel “Workstation Worker Matching Planning” is on the employee scheduling and operational deployment of employees who carry out manual activities in production. The activities performed can include, for example, the processing of products, their assembly, the operation of machines and systems, as well as their loading and set-up, transportation, quality inspections, maintenance, servicing and much more. With the high level of automation and increasing digitalization and autonomation of production the requirements for the planning and management of employees are changing. In future, employees will have to be deployed in a more situational and targeted manner according to their qualifications and skills. The fixed assignment of an employee to a workstation for an entire shift, in which the employee covers all the skills potentially required at the workstation, will no longer be the norm.
In an Industry 4.0 production environment, different requirements are placed on employee scheduling than in a traditional production system, in which employees are manually assigned, usually by the group leader. In Industry 4.0 production, employees and the (autonomous) automation system will have to work together synergistically and employees with the appropriate qualifications or skills will have to be scheduled and managed according to the situation. When qualified personnel resources are scarce, the optimal allocation of qualifications and skills is particularly important.
The current approach of employee scheduling (shift planning) and operative employee deployment by the group leader will reach its limits in future Industry 4.0 production. The classic qualification matrix for planning the necessary qualifications and skills will also no longer be sufficient. The manual creation and maintenance of the matrix will get at its limits and is not interoperable.
The “Workstation Worker Matching Data” Submodel is used to map the general-, ad hoc- and order-dependent demand of a workstation for qualifications and skills. In addition, further information will be provided by the Submodel that are relevant for operative worker deployment and employee scheduling.

The location of static or mobile objects (assets / goods / trackables) and, if applicable, the origin and destination of transport processes are naturally the most important information in transport and internal logistics. In the past, the postal address or a simple location description (e.g., hall B, aisle 3) or a GNSS coordinate (Global Navigation Satellite System, like GPS) was sufficient as location information for controlling logistics processes. With the increasing propagation of localization technologies such as Ultra-Wideband (UWB), BLE (Bluetooth Low Energy), RFID (Radio-Frequency Identification) and others, the continuous and precise tracking of objects becomes possible at reasonable costs. This opens up new possibilities for the automation, monitoring and analysis of goods flows and internal transportation tasks. It is also possible to measure masses of localization data for short distances within buildings, which is why the integration of a localization solution into warehouse systems or production lines is becoming increasingly popular. The systems for localization are usually referred to as real-time location systems (RTLS). Automated guided vehicles (AGVs) and autonomous transport robots with free navigation (AGVs) are also increasingly being used for internal transportation tasks. These are another driver for the use of localization technologies in companies. Location data for assets are determined by different localization systems during the life cycle and even at the same point in time more than one system can deliver a location information. Today location data originate from a variety of non-interoperable systems, for which the data model for the localization information is not standardized. Since asset location data are generated and used by different systems, for different use cases, in different life cycle phases and by different organizations it makes particular sense to manage the location data in the AAS of an asset in the form of a standardized Submodel.

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

This Submodel template is intended to provide all the necessary and basic information for a digital process description in the field of production. The development of a BillofProcess-Submodel (BoP-Submodel) is intended to enable interoperable and automated data provision. The concept is based on process knowledge from various companies in the wire harness industry. Although the associated use case is the wire harness value chain, the goal of the working group is to develop a generalised BoP-Submodel that can be used for a variety of products from different industries.
As an extension, a specific description of the production processes of the wire harness is added to the document. They only represent an extended character and are not mandatory for using the submodel in different industries.

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

This Asset Interfaces Mapping Configuration (AIMC) Submodel specifies an information model and a common representation for describing the mapping of interface(s) of an asset service or asset-related service already described in an Asset Interfaces Description (AID) Submodel. It can be understood as a configuration Submodel for south-bound communication between AAS and asset. Based on this information in the AIMC Submodel, it is possible to configure and initiate a connection to an asset service and map payloads to intended locations in an AAS automatically, and vice versa.

The general Scope of the specification IDTA SMT 020026 “Provision of 3D Models” with the Submodel “Models3D” aims to provide enough meta data to find the right file, to integrate the file in the right way and to do plausibility checks. The file can be either provided within the Submodel itself or, as recommended, with a link to an online file source. This Submodel should complement the existing 3D model file formats and is not meant to replace or redefine them. Nevertheless, meta data that is seen as relevant during the exchange (provision, search, integration) of 3D models but is not harmonized across the various 3D formats will be in the scope of this Submodel. Based on the experience of different stakeholders of the working group “Provision of 3D Models”, for various reasons, there is still the demand for different 3D file formats, be it based on standards like ISO 10303 or proprietary software formats. The scope is based on the implemented use cases and might be extended in future versions of the AAS Submodel Template “Provision of 3D Models”. The [SM] “Models 3D” is suitable for Asset Administration Shells (AAS) of the kind type and instance.
In short: the scope of the SubmodelTemplate IDTA 020026 “Provision of 3D Models” with the Submodel “Models3D” is the provision of 3D Models by complementing and not redefining the existing 3D Model formats themselves.

Generic integration of material and product information as an ontology to provide a uniform data model on needed usage levels in different steps.

This document is intended to address aspects of wireless communication. The structure of this Submodel is expressed through diagrams and UML tables, clarifying its constituent elements. In addition, potential assets and usage scenarios that can benefit from the adoption of this Submodel are identified. The main objective of this Submodel is to integrate wireless industrial communication in the context of the Industry 4.0 (I4.0) framework. The approach is based on the design of a Submodel that encompasses the parameters associated with an asset with wireless communication characteristics. Such a Submodel model is configured to create a fundamental set of Submodel elements that digitally represent relevant information about the different parts that make up a wireless communication system. This Submodel incorporates parameters relevant to various wireless communication technologies and assets. The underlying idea is that the Submodel has a generic character, allowing its application to different technologies and different types of assets. Therefore, some Submodel parameters may be more or less relevant depending on the technology and asset that will be modelled. In order to make the Submodel more specific, the user has the possibility to expand it by adding additional parameters at the time of AAS implementation. Other Submodels targeting specific communication technologies can be standardized later based on this Submodel. The Submodel focuses on layers 1 and 2 of the ISO-OSI model. The description of aspects from layer 3 upwards are not considered in this document and should be described for other submodels, as they do not depend on the type of technology, be it wireless or wired.

Modeling of the information needed for the security engineering of process automation plants.

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

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.

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.

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.

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.

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.

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.

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

Provide detailed product and asset data based on ECLASS categories.

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.

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.

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 AAS Submodel “Plant Asset Management Specification Sheet” is a crucial tool for the procurement and documentation of Plant Asset Management (PAM) functions in industrial settings. Its scope includes establishing a clear contractual basis and documenting PAM functions. These functions can range from special control system functions to add-on parts on production equipment or enabled functions within the equipment.
The Submodel ensures a well-defined contractual basis during procurement, minimizing misunderstandings and improving efficiency. It standardizes requirements, specifications, and expectations related to PAM functions, allowing all stakeholders, such as producers, control system manufacturers, and equipment manufacturers, to have a shared understanding.
Furthermore, the Submodel serves as documentation for PAM functions, capturing vital information. It includes detailed descriptions of function blocks, sensors, and monitoring devices, ensuring a comprehensive record of PAM functionalities. This documentation facilitates troubleshooting, maintenance, and modifications.
In addition, the Submodel supports the engineering process, which often involves multiple stakeholders and departments. It acts as a central reference, aligning efforts and fostering collaboration between departments such as procurement, operation, maintenance, sales, and engineering. The Submodel promotes transparency and manages dependencies in engineering PAM functions.
The Submodel also aids decision-making throughout the PAM functions’ lifecycle. It provides information for informed decisions regarding maintenance, upgrades, and component replacement. It also assists in evaluating compatibility and integration of new PAM functions into existing systems. This is crucial for managing complex industrial environments with interconnected systems.
The management of online and historical data for a specific PAM function is not within the scope of this Submodel. This is because such data may contain highly detailed and specific information that is beyond the level of specification covered here. Additionally, the management of this data may be better suited for a separate AAS Submodel focused on general condition monitoring, which is not addressed in this particular Submodel. The primary focus of this Submodel is to establish a contractual basis, document PAM functions, and support the engineering process, rather than delving into the intricacies of online and historical data management.

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

This Submodel specifies an information model and a common representation for describing the interface(s)
of an asset service or asset related service. Based on this information, it is possible to initiate a connection to
such kind of service and start to request or subscribe to served datapoints, and/or perform operations. Such
datapoints of a system service can be, for example, various sensor and/or status values, and an operation
can trigger an actuator, such as switching a motor “on” or “off”.
The Asset Interfaces Description (AID) in version 1.0 supports the description of interfaces based on three
specific protocols: Modbus, HTTP and MQTT. Any other protocols and interfaces will be addressed in
upcoming versions of the AID. As a forward-looking note, the AID working group at IDTA has outlined plans
for the AID 1.1 version to incorporate support for both OPC UA (joint activity with the OPC Foundation) and
BACnet.
The W3C Web of Things Thing Description (WoT TD) as an open, royalty-free standard is considered as a
baseline for the content and structure of the definition of this Submodel template.
In addition to the protocol specific information provided by the AID, it also provides the ability to reference
external descriptors such as GSD, GSDML, IO Device Description, WoT TD (as a supplement) etc. These
external descriptor is not restricted to the protocols currently defined in the AID.