In order to provide contact options to a simulation-specific support or for the request of a simulation model, structures and features were used from the Submodel "Contact Information" (IDTA 02002-1-0).

The name of the provider of the simulation model, the available communication languages and optionally an e-mail address or a telephone number can be specified.

The Model Identity Card (MIC) contains information to characterize simulation models based on a set of core information [10]. It consists of definitions for general information, integration, content and computation, ports, internal variables and parameters, verification and validation. Information about the port definition were used as inspiration for the Submodel template.

The Functional Mock-up Interface (FMI) is a free standard for exchange and co-simulation of dynamic models. It defines a model container and a model interface using a combination of XML files, binaries and / or C code zipped into a single file. An integration algorithm may be included for co-simulation of models. It is supported by 170+ tools and maintained as a Modelica Association Project [8] on GitHub [9]. Since a large number of simulation models are already provided as FMUs and will continue to be so in the future, the Submodel “Provision of Simulation Models” attempts to represent this type of model as accurately as possible.

ECLASS defined tens of thousands product classes and unique properties to standardize procurement, storage, production, and distribution within and between companies across different business areas, countries, and languages. ECLASS is the only ISO/IEC conform industry standard for classification and unique description of products and services. These unique identifiers called IRDIs (International Registration Data Identifiers) are based on ISO/IEC 11179-6, ISO 29002 and ISO 6532 and are used by AAS to provide data specifications for its properties, values, and units.ECLASS was selected by the IDTA as one of the preference standards to provide data specifications.These unique identifiers called IRDIs (International Registration Data Identifiers) are based on ISO/IEC 11179-6, ISO 29002 and ISO 6532 and are used by AAS to provide data specifications for its properties, values, and units.ECLASS was selected by the IDTA as one of the prefered standards to provide data specifications.

AutomationML [11] is a comprehensive XML based object-oriented data modeling language. It allows the modeling, storage and exchange of engineering models covering a multitude of relevant aspects of engineering. AML provides a comprehensive set of flexible mechanisms and innovations to model today’s engineering aspects as well as future engineering aspects to come. Its language characteristics allow to model existing or new domain models.

AutomationML has a lean and distributed file architecture. It does not define any new file format but combines existing established XML data formats which have been proven in use for their specific domain. This is why the normative part of the IEC62714-1:2018 document consists of 32 pages only. The data formats for the following modeling domains are:

AutomationML also provides an application recommendation [12] which describes the serialization of the AAS Metamodel using AutomationML by defining appropriate serialization rules and role, interface and system unit classes related to them.

https://ssp-standard.org/publications/SSP10/SystemStructureAndParameterization10.pdf[SSP is] a tool-independent format developed by the Modelica Association Project [8] to exchange simulation-capable system structures consisting of individual simulation components, preferably FMUs (Functional Mockup Units). With SSP such a system of interlinked components can be described by a well-structured bundle of subformats, packed into a zip-container. The package comprises the specification of the hierarchical and functional structure of the component network (including all signal flows), the parameters, parameter sets and parameter mappings as well as dictionaries of signals. The first version of SSP is already supported by some system simulation tools (https://ssp-standard.org/tools/). The format can be of interest to the Submodel as it can serve as specification and exchange format for the Use Case 3 “Generate and Simulate a system simulation out of existing simulation components”.

The Smart Systems Engineering (SmartSE) project group works together with a group of participants from almost 30 companies and research institutions to develop application-oriented concepts for overcoming common systems engineering challenges. Since 2012 SmartSE develops recommendations as well as promotes and industrializes technical standards with regard to collaborative systems engineering tasks within and especially across companies. The latest recommendations apply to Simulation-based decision making and the format System Structure and Parameterization. A general SmartSE recommendation V3.0 is in work (SmartSE V2.0). Despite the slightly different focus of system simulation models (SmartSE more focusing on individual models, the Submodel focusing on catalogue models) an exchange between the Submodel and the SmartSE group could yield in a review and industrialization of the Submodel specification and an extension of its current use cases.

The Submodel candidate “Software Nameplate” defines properties relevant for identification of software products (type) and their installed instances. This information shall be provided in a consistent manner in form of a “nameplate for software”, derived and specialized from the Submodel “Digital Nameplate for Industrial Equipment”. The nameplate for software applies to stand-alone software assets, as well as to software as integral part of a physical asset, e.g. firmware.

It describes information on

Further Submodels describing license information, software requirements, and dependencies are currently in initial discussions.

This, at the time of this specification, future Versions of the Submodel “Software Nameplate” will identify and describe a simulation model, in principle. It can be integrated in the management shell of the simulation model itself. The Submodel "Provision of Simulation Models" focuses on the description of simulation-specific properties and is integrated in the asset administration shell of the asset itself, analogous to a documentation or a CAD model for a component.

A Submodel that can describe the structure of an asset or an assembly. At the time of publication of the first version of the Submodel “Provision of Simulation Models”, the Submodel Hierachical Structures enabling Bills Of Material is still work in progress.

The description primarily includes a structured "bill of material" and may also include the connections between components.

Since this Submodel is a very useful addition in perspective for simulation usecases, such as generating or assisted integration of simulation models, assumptions have been made for the coexistence of the models in the Design Decisions and Usecases chapter.

In the current version of the Submodel, due to a lack of expertise, the needs of simulation models from the areas of finite element method (FEM) simulations were not specifically addressed. Nevertheless, simulation models from this area should be provided with the Submodel to at least represent the existence of a corresponding model within the AAS.

The potential deviations of the provided simulation model to the customer specific requirements and associated changes in the model can be overcome by providing multiple parameter files and/or providing multiple complete simulation models. Furthermore, the Submodel with the simulation documentation offers the possibility to formulate a detailed description about the application area of a simulation model.

In future versions of the Submodel, the structure is to be adapted by the inclusion of creators and users of FEM models in such a way that FEM models can also be adequately represented. Nevertheless, it should be noted that such simulations are mainly used for dimensioning components during their development and are less likely to find application in system integration. For the system integrator, a digital data sheet will be of more use. Therefore, cross-company use of such simulation models is considered less likely.

In the working group 6.11 Virtual Commissioning of the GMA, a methodology is currently being developed which is intended to enable the quality of a simulation model to be determined in a standardized manner [(Automation) 7]. This involves evaluating a simulation model on the basis of 25 attributes, among others, and determining an overall quality for the simulation model. In the version of the Submodel described here, this quality metric is not yet applied, but this is explicitly aimed at for future versions. Possibilities for integration and collaboration are currently being discussed in talks between the working groups.

A user is interested in a product (type) and is offered various models via the Submodel with which the user can test the model in simulation environments.

The simulation model is typically provided by the component manufacturer.

A user has ordered an asset and is offered simulation models via the Submodel which he can use to simulate and test the specific behaviour of the component after integration in his own solution.

The instance simulation model differs in detail from those of a type simulation model. It can be adapted e.g., due to measured properties in production, aging phenomena in operation or replacement of subordinate components compared to an original machine. This model is therefore not necessarily provided by the manufacturer of the asset.

A user is designing a solution using various assets, from different manufacturers or internal supliers. Via the Submodel the user gets an overview which simulation models are available to realize a complete simulation of the system. If necessary, the user can send specific requests to the manufacturers/supplier of the components on the basis of the Submodel in order to obtain the corresponding models.

It also supports automated updating of models. Notifications can be generated for new simulation models for the component or new versions of a used model.

More use cases are under discussion, but current work focus on the above three use cases [13].

The table describes the main requirements to the Submodel that were considered during the elaboration.

When designing the Submodel ”Provision of Simulation Models”, Pthe following specifications were made, which are shown in Figure 3.

Figure 4 shows an example of how the asset administration shell with its Submodels and simulation models can describe an asset by using the Submodel “Hierachical Structures enabling Bills of Material” Submodel. The template specification of the Submodel “Hierachical Structures enabling Bills of Material” is currently under construction.

Figure 5 shows the extended use case in which the Submodel “Hierachical Structures enabling Bills of Material” describes the structure of a simulation model consisting of multiple sub-simulation models. The main simulation model is referred to as a gray box model, since the model consists of black box models and its superordinate structure is described via the management shell.

This list of values is recommended as an open selection. The model provider should be able to add more definitions.

This list of values is recommended as an open selection. The model provider should be able to add more definitions.

This list of values is recommended as an open selection. The model provider should be able to add more definitions.

This list of values is recommended as an open selection. The model provider should be able to add more definitions.

This list of values is recommended as an open selection. The model provider should be able to add more definitions.

This list of values is recommended as a closed selection. Only these values should be taken.

This list of values is recommended as an open selection. The model provider should be able to add more definitions.

This list of values is recommended as an open selection. The model provider should be able to add more definitions.

This list of values is recommended as an open selection. The model provider should be able to add more definitions.

This list of values is recommended as a closed selection. Only these values should be taken.

This list of values is recommended as a closed selection. Only these values should be taken.

The following example assumes that there are three different simulation models (Model A, Model B and Model C). Model A has versions V2.0 and V2.1, Model B only has version 8.0 and Model C has three versions V5.0, V5.1 and V5.2. The structure and chronological development are shown again in Figure 7.

In general, all simulation models of a component are encapsulated in a single Submodel contained in the AAS of the Component. A separate SubmodelCollection "SimulationModel" is created for each simulation model. Applied to the example above, there would be one Submodel “SimulationModels” in the administration shell of the component, which itself contains six SubmodelCollections "SimulationModel". Each of these SubmodelCollections thus represents a simulation model in a specific version. This modeling variant is shown in Figure 8. The structure of the Submodel template also allows several versions of one simulation model to be represented within a SubmodelCollection "SimulationModel" as can be seen in Figure 8 (Model C V5.0 and V5.1). However, this modeling structure is only recommended if the description of the SubmodelCollection “Simulation Model” does not change. More detailed information can be found in the subsections "Bug Fixes" and "New Information Model".

The following are recommendations for modeling simulation models with the “Provision of Simulation Models” Submodel for different situations.

Simulation Model C should serve as an example here. Consider the situation, that in V5.0, the pre-factor of an equation is incorrect and must be adjusted in the simulation model itself. The change of the original (V5.0) and corrected model (V5.1) differ only in the referenced file "DigitalFile", representing the new simulation model. For this reason, the corrected version V5.1 can be added to the same SubmodelCollection "Simulation Model" as the previous version 5.0. For this purpose, an additional SubmodelCollection "modelFileVersion" is added to the SubmodelCollection "modelFile", containing the corrected version of the Model C, a different version number, etc.. The structure is shown in Figure 8 and below as a hierarchical structure.

However, if the Bugfix results in a different representation of the simulation model within the SubmodelCollection “SimulationModel”, the usage of a new SubmodelCollection “SimulationModel” is necessary. This scenario is described in the following subsection.

To correctly represent simulation models with different properties, a new SubmodelCollection “SimulationModel” need to be added to the Submodel, regardless if it is a completely new simulation model or a new version of an already existing one. For example, Model C V5.2 contains an additional Port to read an extra Variable value. Since this property is not visible in the AAS description of V5.0 and V5.1, a new SubmodelCollection "SimulationModel" must be created for Model C V5.2. Below the structure of the scenario is depicted containing also a completely different Model A.

A component provider can create a model for its component or solution on request. He provides this only on request, because the provision may not work completely automated or is too costly.

The partial model can be used as follows.

Below is a schematic example:

A component supplier wants to receive requests for simulation models of its components from users. The Submodel can help to ensure that the requests for simulation models are made accurately. Tools, like a simulation environment, but also e.g. a PLM system, can support the organization of needed things, like simulation models, based on this.

The partial model can be used as follows.

Below is a schematic example: