IDTA 02005-1-0: Provision of Simulation Models

Imprint

Publisher

Industrial Digital Twin Association
Lyoner Strasse 18
60528 Frankfurt am Main
Germany
https://www.industrialdigitaltwin.org/

Version history

Date	Version	Comment
15.12.2022	1.0	Release of the official Submodel template published by IDTA.

Date

Version

Comment

15.12.2022

1.0

Release of the official Submodel template published by IDTA.

General

About this document

This document is a part of a specification series. Each part specifies the contents of a Submodel for the Asset Administration Shell (AAS). The AAS is described in [1], [2], [3] and [6]. First exemplary Submodel contents were described in [4], while the actual format of this document was derived by the "Administration Shell in Practice" [5]. The format aims to be very concise, giving only minimal necessary information for applying a Submodel template, while leaving deeper descriptions and specification of concepts, structures and mapping to the respective documents [1] to [6].

The target group of the specification are developers and editors of technical documentation and manufacturer information, which are describing assets in smart manufacturing by means of the Asset Administration Shell (AAS) and therefore need to create a Submodel instance out of a Submodel template with a hierarchy of SubmodelElements. This document especially details on the question, which SubmodelElements with which semantic identification shall be used in the Submodel template.

Scope of the Submodel

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 rudimentary 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 required that the asset for which a simulation model should be provided 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).

Relevant standards for the Submodel

Here standards are listed which have an influence on this version of the Submodel or which are referenced.

In addition, some important candidates for further development are listed.

AAS Submodel "Contact Information"

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.

MIC (Model identity Card)

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.

FMI (Functional Mockup Interface)

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

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 preferred standards to provide data specifications.

AutomationML

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:

object topologies including hierarchies, properties and relations of objects: CAEX according to IEC 62424
geometries and kinematics of objects: COLLADA 1.4.1 and 1.5.0 (ISO/PAS 17506:2012)
discrete behavior of objects: PLCopen XML 2.0 and 2.0.1; in addition, IEC62714-4 will allow the usage of IEC61131-10

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.

Future relevant standards

The initial version will contain all relevant properties relevant for the use cases explained in this document. For future releases we are also evaluating other standardization activities. Examples include current releases of the VDI GMA FA 6.XX about quality metrics but also other IDTA working group draft generic forms like the Submodel "Hierarchical Structures enabling Bills of Material".

SSP (System Structure and Parameterization)

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

ProStep iViP Project Smart Systems Engineering

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.

AAS Submodel candidate "Software Nameplate"

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

manufacturer (name, product description, product family)
version (version number, version name, version information)
release date and release notes
build date
serial number and instance name
installation details (installed version, installation date, path, and source)
environment (architecture, operating system, host).

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.

AAS Submodel candidate "Hierarchical Structures enabling Bills Of Material"

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 Hierarchical 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 use cases, such as generating or assisted integration of simulation models, assumptions have been made for the coexistence of the models in the chapter Use cases, requirements and design decisions.

Spatially discretizing methods

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.

Quality of Simulation Model

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

Use cases, requirements and design decisions

The Submodel "Provision of Simulation Models" can be used to implement various use cases in which simulation models are to be integrated. Three basic ones are shown in the following subchapters. All of them have in common that one is in a value network with many partners, as it was shown in Figure 1.

Figure 1. Value network adaptable factory [1]

To provide an overview of the scenarios were targeted with the first version of the Submodel, the use cases are located in Figure 2 of the generic value network published via Plattform Industrie 4.0.

These use cases are described in more detail in the following chapters.

Figure 2. Use cases for AAS Submodel "Provision of Simulation Models"

Zero to many simulation models can be provided to an asset type or instance. More than one model is needed for different simulation methods (see picture left), simulation tools and simulation purposes.

Before describing the different use cases, the differences between a product type and a product instance should be briefly discussed here.

An asset type is a representation that defines all the usual properties that are also contained in asset instances at the beginning of their life cycle [6]. These include, for example, the structure and components used. But also, properties resulting from the engineering are included in the type. For example, the maximum load capacity, allowed environmental conditions. In contrast to this an instance represents a concrete and clearly identifiable entity of a certain type [6]. This instance can contain additional properties like color, serial number, runtime information, etc. in addition to the properties contained in the type. Furthermore, properties in the instance can change over the life cycle and thus deviate from the type.

Use case 1: Provision of simulation models to asset types

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.

Use case 2: Provision of simulation models to asset instances

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.

Use case 3: Create and maintain a simulation of Systems

A user is designing a solution using various assets, from different manufacturers or internal suppliers. 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].

Requirements

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

Table 1. Requirements to the Submodel "Provision of Simulation Models"
No.	Title	Description
Req 000	Providing simulation models to a component	The Submodel provides simulation models and their descriptions of an Industrie 4.0 component.
Req 010	All types of simulation models	The Submodel can represent all types of simulation models.
Req 020	Integration of standards	The Submodel integrates existing standards, such as FMI.
Req 021	Adopting artifacts	The Submodel adopts artifacts from existing standards that support the intended use cases of the Submodel and whose use also appears to make sense beyond the standard.
Req 030	Version management	The Submodel should support common version management.
Req 040	Providing simulation model files	The Submodel can make simulation model files available, such as download.
Req 041	User specific request	The Submodel is intended to enable a request for a user specific simulation model to be submitted to the component suppliers.
Req 042	Models available on request	The Submodel shall enable the supplier of a component to describe a model which can be realized and delivered.
Req 050	simulation specific properties	The Submodel should show simulation-specific properties, which support the search and comparison of suitable models.

Design decisions

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

The Submodel "Provision of Simulation Models" Prcomplements the description of an asset
A simulation model will have its own asset administration shell in the future, the following general Submodels can be used then
Considering Submodels like "Digital Nameplate for Industrial Equipment", "Generic Frame for Technical Data for Industrial Equipment in Manufacturing" and "Handover Documentation"
The Submodel "Provision of Simulation Models" can be assigned to an asset type or an asset instance
The Submodel "Hierarchical Structures enabling Bills of Material" describes composite solutions including their connections

Figure 3. Information model architecture with the first available Submodels

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 "Hierarchical Structures enabling Bills of Material" Submodel. The template specification of the Submodel "Hierarchical Structures enabling Bills of Material" is currently under construction.

Figure 4. Mapping of simulation models in the machine hierarchy

Figure 5 shows the extended use case in which the Submodel "Hierarchical 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.

Figure 5. Using Submodel "Hierarchical Structures enabling Bills of Material" for assembly of simulation model

Submodel "Provision of Simulation Models"

Approach

In this document one Submodel for provision of multiple simulation model files to a component is defined. Simulation models can be added to an asset type and an asset instance.

The goal is to provide all types of simulation models for diverse simulations. With the Submodel "Provision of Simulation Models" information can be provided simplifying searching and finding of suitable models and their integration into a simulation environment. Further a standardized mechanism to find contact information to the simulation model provider is given.

In addition to the use case of providing models, the Submodel can also be used to send a specific request for a simulation model to the manufacturer/supplier of a component. For this purpose, parts of the Submodel "Contact Information" are transferred to this Submodel.

Properties of the Submodel "Provision of Simulation Models"

As an overview, the features and collections are shown here as in a UML diagram.

The following main aspects can be described with the model.

Model file deployment with different versions
Manufacturer’s simulation support contact information
Simulation purposes, positive and negative
Documentation of example simulations
Environment, and tested constellations simulation tool and solver typs
Setting options for model parameters and initial values
License types
Model scope, type and integrated engineering domain
Model ports and interfaces, e.g., for visualization

Practical guidance for Submodel modelers on various scenarios of mapping is presented in Chapter 3.

Figure 6. UML Diagram of the Submodel "Provision of Simulation Models"

Attributes of Submodel instance

For with the Submodel instance, different simulation models can be provided. The table convention is explained in Annex A.2.

Table 2. Attributes of Submodel instance
[SME type]	semanticId = [idType]value	[valueType]	card.
idShort	SimulationModels
Class	Submodel
SemanticId	https://admin-shell.io/idta/SimulationModels/SimulationModels/1/0
Explanation	The Submodel may provide one or more simulation models, a service to generate a specific model, or access to an open or specific query.
idShort	Description@en	example	[SMC] SimulationModel

SubmodelElements of SimulationModel

Basic structure to describe simulation models.

Table 3. Submodel elements of SimulationModel
[SME type]	semanticId = [idType]value	[valueType]	card.
idShort	SimulationModel
Class	SubmodelElementCollection
SemanticId	[IRI] https://admin-shell.io/idta/SimulationModels/SimulationModel/1/0
Parent	SimulationModels
Explanation	Feature collection to provide or request simulation models. Models can be described by objective and content.
idShort	Description@en	example	[MLP] Summary
[IRI] https://admin-shell.io/idta/SimulationModels/Summary/1/0 Summary of the contents of the simulation model in text form.	[langString]	0..1	[SMC] SimPurpose
[IRI] https://admin-shell.io/idta/SimulationModels/SimPurpose/1/0 This characteristic describes the simulation purpose or suitability for different simulation goals.	n/a	1	[Property] TypeOfModel
[IRI] https://admin-shell.io/idta/SimulationModels/TypeOfModel/1/0 List of modeling approaches used for the model.	[string]	0..\*	[Property] ScopeOfModel
[IRI] https://admin-shell.io/idta/SimulationModels/ScopeOfModel/1/0 List of basic physical characteristics which are represented by the model.	[string]	1..\*	[Property] LicenseModel
[IRI] https://admin-shell.io/idta/SimulationModels/LicenseModel/1/0 If a simulation model usage will be charged and how it will be charged.	[string]	0..1	[Property] EngineeringDomain

[SMC]
Environment

[IRI] https://admin-shell.io/idta/SimulationModels/Environment/1/0

Information about prerequisite environments or dependencies of underlying components on the target system.

n/a

0..\*

[File]
RefSimDocumentation

[IRI] https://admin-shell.io/idta/SimulationModels/RefSimDocumentation/1/0

Simulation Documentation Documentation of example simulations of the model can be supplied. This includes a solver setup and sample circuit and sample results. e.g. zip file, PDF, html, … -

[File]

0..\*

[SMC]
ModelFile

[IRI] https://admin-shell.io/idta/SimulationModels/ModelFile/1/0

Providing versions of the simulation model and with characteristics to distinguish them.

n/a

[Property]
ParamMethod

[IRI] https://admin-shell.io/idta/SimulationModels/ParamMethod/1/0

Indicates whether the model must be parameterized and if so, which method is required.

[string]

[File]
ParamFile

[IRI] https://admin-shell.io/idta/SimulationModels/ParamFile/1/0

File for parameterization of the model. As parameter file or parameter documentation (e.g. pdf).

[File]

0..1

[Property]
InitStateMethod

[IRI] https://admin-shell.io/idta/SimulationModels/InitStateMethod/1/0

Describes the state variables of the simulation model that must be initialized to start the simulation. For initial value problems, these quantities describe the system state at the start of the simulation. In this case, the system is in a state of equilibrium. Alternatively, a simulation model may include a method to determine consistent initial values at this step, e.g., at an operating point.

[string]

[File]
InitStateFile

[IRI] https://admin-shell.io/idta/SimulationModels/InitStateFile/1/0

File for parameterizing the initial states of the model. As parameter file or parameter documentation (e.g. pdf).

[File]

0..1

[Property]
DefaultSimTime

[IRI] https://admin-shell.io/idta/SimulationModels/DefaultSimTime/1/0

Predefined simulation period in seconds.

[float]

0..1

[SMC]
SimModManufacturerInformation

[IRI] https://admin-shell.io/idta/SimulationModels/SimModManufacturerInformation/1/0

Provide access to simulation support service provided by the distributor via mail or phone.

n/a

0..\*

[SMC]
Ports

[IRI] https://admin-shell.io/idta/SimulationModels/Ports/1/0

Interfaces of the model. This includes inputs, outputs as well as acausal connections (e.g. mechanical connections). In addition, it is specified here whether the model provides binary interfaces (e.g. for visualization).

n/a

0..1

SubmodelElements of SimPurpose

Table 4. Submodel elements of SimPurpose
[SME type]	semanticId = [idType]value	[valueType]	card.
idShort	SimPurpose
Class	SubmodelElementCollection
SemanticId	[IRI] https://admin-shell.io/idta/SimulationModels/SimPurpose/1/0
Parent	SimulationModel
Explanation	This characteristic describes the simulation purpose or suitability for different simulation goals.
idShort	Description@en	example	[Property] PosSimPurpose
[IRI] https://admin-shell.io/idta/SimulationModels/PosSimPurpose/1/0 List of simulation purposes for which the model is intended.	[string]	1..\*	[Property] NegSimPurpose

SubmodelElements of Environment

Table 5. Submodel elements of Environment
[SME type]	semanticId = [idType]value	[valueType]	card.
idShort	Environment
Class	SubmodelElementCollection
SemanticId	[IRI] https://admin-shell.io/idta/SimulationModels/Environment/1/0
Parent	SimulationModel
Explanation	Information about prerequisite environments or dependencies of underlying components on the target system.
idShort	Description@en	example	[Property] OperatingSystem
[IRI] https://admin-shell.io/idta/SimulationModels/OperatingSystem/1/0 Name of the operating system including version and architecture (e.g. Windows 10 64bit).	[string]	1	[Property] ToolEnvironment
[IRI] https://admin-shell.io/idta/SimulationModels/ToolEnvironment/1/0 List with required simulation tools, interpreters, model libraries or runtime libraries. In each case the exact designation of the software producer is given as free text.	[string]	0..\*	[MLP] DependencyEnvironment
[IRI] https://admin-shell.io/idta/SimulationModels/DependencyEnvironment/1/0 Description of dependencies to associated hardware and software.	[langString]	0..1	[Property] VisualizationInformation
[IRI] https://admin-shell.io/idta/SimulationModels/VisualizationInformation/1/0 Ability to use a visualization. This can be integrated in a model or the model offers capabilities for connection. The connection can be described in more detail under Ports.	[string]	0..1	[SMC] SimulationTool

SubmodelElements of SimulationTool

Table 6. Submodel elements of SimulationTool
[SME type]	semanticId = [idType]value	[valueType]	card.
idShort	SimulationTool
Class	SubmodelElementCollection
SemanticId	[IRI] https://admin-shell.io/idta/SimulationModels/simulationTool/1/0
Parent	Environment
Explanation	Properties of the model with regard to concrete simulation tools.
idShort	Description@en	example	[Property] SimToolName
[IRI] https://admin-shell.io/idta/SimulationModels/SimToolName/1/0 Name of the simulation tool including version.	[string]	1	[Property] DependencySimTool
[IRI] https://admin-shell.io/idta/SimulationModels/DependencySimTool/1/0 Dependencies of Simulation Tools.	[string]	0..\*	[Property] Compiler
[IRI] https://admin-shell.io/idta/SimulationModels/compiler/1/0 Name of necessary compiler including version.	[string]	0..\*	[SMC] SolverAndTolerances

SubmodelElements of SolverAndTolerances

Table 7. Submodel elements of SolverAndTolerances
[SME type]	semanticId = [idType]value	[valueType]	card.
idShort	SolverAndTolerances
Class	SubmodelElementCollection
SemanticId	[IRI] https://admin-shell.io/idta/SimulationModels/SolverAndTolerances/1/0
Parent	SimulationTool
Explanation	Useful settings of the simulation environment. Includes e.g. solver settings.
idShort	Description@en	example	[Property] StepSizeControlNeeded
[IRI] https://admin-shell.io/idta/SimulationModels/StepSizeControlNeeded/1/0 Solver with step size control recommended.	[boolean]	1	[Property] FixedStepSize
[IRI] https://admin-shell.io/idta/SimulationModels/FixedStepSize/1/0 Fixed integration step size, if there is no adaptive step size.	[float]	0..1	[Property] StiffSolverNeeded
[IRI] https://admin-shell.io/idta/SimulationModels/StiffSolverNeeded/1/0 Stiff solver needed.	[boolean]	1	[Property] SolverIncluded
[IRI] https://admin-shell.io/idta/SimulationModels/SolverIncluded/1/0 Solver is integrated in the model (e.g. FMU for co-simulation).	[boolean]	1	[SMC] TestedToolSolverAlgorithm

SubmodelElements of TestedToolSolverAlgorithm

Table 8. Submodel elements of TestedToolSolverAlgorithm
[SME type]	semanticId = [idType]value	[valueType]	card.
idShort	TestedToolSolverAlgorithm
Class	SubmodelElementCollection
SemanticId	[IRI] https://admin-shell.io/idta/SimulationModels/TestedToolSolverAlgorithm/1/0
Parent	SolverAndTolerances
Explanation	List of validated tool-solver combinations.
idShort	Description@en	example	[Property] SolverAlgorithm
[IRI] https://admin-shell.io/idta/SimulationModels/SolverAlgorithm/1/0 validated solver.	[string]	1	[Property] ToolSolverFurtherDescription
[IRI] https://admin-shell.io/idta/SimulationModels/ToolSolverFurtherDescription/1/0 Further tool- and solver-specific information.	[string]	0..1	[Property] Tolerance

SubmodelElements of ModelFile

Table 9. Submodel elements of ModelFile
[SME type]	semanticId = [idType]value	[valueType]	card.
idShort	ModelFile
Class	SubmodelElementCollection
SemanticId	[IRI] https://admin-shell.io/idta/SimulationModels/ModelFile/1/0
Parent	SimulationModel
Explanation	Providing versions of the simulation model and with characteristics to distinguish them.
idShort	Description@en	example	[Property] ModelFileType
[IRI] https://admin-shell.io/idta/SimulationModels/ModelFileType/1/0 Designation of the exchange format of the model. E.G.: FMI 1.0, Co-Simulation, Platform / Source - Code. FMI 2.0.2, Model Exchange, Source - Code, S-function, Version 2, 64bit, mex - Format / or C-Code, Modelica 3, encoded, VHDL	[string]	0..1	[SMC] ModelFileVersion

SubmodelElements of ModelFileVersion

Table 10. Submodel elements of ModelFileVersion
[SME type]	semanticId = [idType]value	[valueType]	card.
idShort	ModelFileVersion
Class	SubmodelElementCollection
SemanticId	[IRI] https://admin-shell.io/idta/SimulationModels/ModelFileVersion/1/0
Parent	ModelFile
Explanation	Provision of a version of the simulation model with information to distinguish the versions. The versions are primarily intended for bug fixes without content changes.
idShort	Description@en	example	[Property] ModelVersionId
[IRI] https://admin-shell.io/idta/SimulationModels/ModelVersionId/1/0 Version number of the model from the vendor.	[string]	1	[File] ModelPreviewImage
[IRI] https://admin-shell.io/idta/SimulationModels/ModelPreviewImage/1/0 Image file to represent the model in user interfaces, e.g. in a search.	[File]	0..1	[File] DigitalFile
[IRI] https://admin-shell.io/idta/SimulationModels/DigitalFile/1/0 Deployment of the model file.	[File]	1	[MLP] ModelFileReleaseNotesTxt
[IRI] https://admin-shell.io/idta/SimulationModels/ModelFileReleaseNotesTxt/1/0 contains information about this release	[langString]	0..1	[File] ModelFileReleaseNotesFile

SubmodelElements of SimModManufacturerInformation

Table 11. Submodel elements of SimModManufacturerInformation
[SME type]	semanticId = [idType]value	[valueType]	card.
idShort	SimModManufacturerInformation
Class	SubmodelElementCollection
SemanticId	[IRI] https://admin-shell.io/idta/SimulationModels/SimModManufacturerInformation/1/0
Parent	SimulationModel
Explanation	Provide access to simulation support service provided by the distributor via mail or phone.
idShort	Description@en	example	[Property] Company
[IRDI] 0173-1#02-AAW001#001 name of the company	[string]	1	[Property] Language
[IRDI] 0173-1#02-AAO895#003 available language	[string]	1..\*	[SMC] Email
[IRDI] 0173-1#02-AAQ836#005 E-mail address and encryption method	n/a	0..1	[SMC] Phone

SubmodelElements of Email

Table 12. Submodel elements of Email
[SME type]	semanticId = [idType]value	[valueType]	card.
idShort:	Email Note: according to Submodel "Contact Information"
Class	SubmodelElementCollection
SemanticId	[IRDI] 0173-1#02-AAQ836#005
Parent	SimModManufacturerInformation
Explanation	E-mail address and encryption method
idShort	Description@en	example	[Property] TypeOfEmailAddress
[IRDI] 0173-1#02-AAO199#003 characterization of an e-mail address according to its location or usage	[string]	0..1	[Property] EmailAddress
[IRDI] 0173-1#02-AAO198#002 electronic mail address of a business partner	[string]	1	[Property] TypeOfPublicKey
[IRDI] 0173-1#02-AAO201#002 characterization of a public key according to its encryption process	[string]	0..1	[Property] PublicKey

SubmodelElements of Phone

Table 13. Submodel elements of Phone
[SME type]	semanticId = [idType]value	[valueType]	card.
idShort:	Phone Note: according to Submodel "Contact Information"
Class	SubmodelElementCollection
SemanticId	[IRI] https://admin-shell.io/zvei/nameplate/1/0/ContactInformations/ContactInformation/Phone
Parent	SimModManufacturerInformation
Explanation	Phone number including type
idShort	Description@en	example	[Property] TypeOfTelephone
[IRDI] 0173-1#02-AAO137#003 characterization of a telephone according to its location or usage	[string]	0..1	[Property] TelephoneNumber
[IRDI] 0173-1#02-AAO136#002 complete telephone number to be called to reach a business partner	[string]	1	[MLP] AvailableTime

SubmodelElements of Ports

Table 14. Submodel elements of Ports
[SME type]	semanticId = [idType]value	[valueType]	card.
idShort	Ports
Class	SubmodelElementCollection
SemanticId	[IRI] https://admin-shell.io/idta/SimulationModels/Ports/1/0
Parent	SimulationModel
Explanation	Interfaces of the model. This includes inputs, outputs as well as acausal connections (e.g. mechanical connections). In addition, it is specified here whether the model provides binary interfaces (e.g. for visualization).
idShort	Description@en	example	[SMC] PortsConnector
[IRI] https://admin-shell.io/idta/SimulationModels/PortsConnector/1/0 List of ports of the model. These include a name, a description, a list of variables, and a list of ports.	n/a	0..\*	[SMC] BinaryConnector

SubmodelElements of PortsConnector

Table 15. Submodel elements of PortsConnector
[SME type]	semanticId = [idType]value	[valueType]	card.
idShort	PortsConnector
Class	SubmodelElementCollection
SemanticId	[IRI] https://admin-shell.io/idta/SimulationModels/PortsConnector/1/0
Parent	Ports
Explanation	List of ports of the model. These include a name, a description, a list of variables, and a list of ports.
idShort	Description@en	example	[Property] PortConnectorName
[IRI] https://admin-shell.io/idta/SimulationModels/PortConnectorName/1/0 Name of the Connector Port.	[string]	1	[MLP] PortConDescription
[IRI] https://admin-shell.io/idta/SimulationModels/PortConDescription/1/0 Description of the Connector Port.	[langString]	0..1	[SMC] Variable

SubmodelElements of Variable

Table 16. Submodel elements of Variable
[SME type]	semanticId = [idType]value	[valueType]	card.
idShort	Variable
Class	SubmodelElementCollection
SemanticId	[IRI] https://admin-shell.io/idta/SimulationModels/Variable/1/0
Parent	PortsConnector
Explanation	-
idShort	Description@en	example	[Property] VariableName
[IRI] https://admin-shell.io/idta/SimulationModels/VariableName/1/0 Name of the variable.	[string]	1	[Property] Range
[IRI] https://admin-shell.io/idta/SimulationModels/Range/1/0 Range of values for the variable (e.g. [min, max], [min, max[, ]min, max], ]min, max[, \{val1, val2, …}). -	[string]	0..1	[Property] VariableType
[IRI] https://admin-shell.io/idta/SimulationModels/VariableType/1/0 Type of the variable (e.g. Real, Integer, Boolean, String or Enum).	[string]	1	[MLP] VariableDescription
[IRI] https://admin-shell.io/idta/SimulationModels/VariableDescription/1/0 Description of the variable.	[langString]	0..1	[Property] UnitList
[IRI] https://admin-shell.io/idta/SimulationModels/UnitList/1/0 The most common units can be selected here. If "others" is selected, a free text can be entered.	[string]	1	[MLP] UnitDescription
[IRI] https://admin-shell.io/idta/SimulationModels/UnitDescription/1/0 Text field for missing units of the list	[langString]	0..1	[Property] VariableCausality
[IRI] https://admin-shell.io/idta/SimulationModels/VariableCausality/1/0 The causality of the variable: input to inputs, output to outputs, acausal connections (e.g. mechanical connection) do not have causality.	[string]	1	[Property] VariablePrefix

SubmodelElements of BinaryConnector

Table 17. Submodel elements of BinaryConnector
[SME type]	semanticId = [idType]value	[valueType]	card.
idShort	BinaryConnector
Class	SubmodelElementCollection
SemanticId	[IRI] https://admin-shell.io/idta/SimulationModels/BinaryConnector/1/0
Parent	Ports
Explanation	Binary interfaces (binaryType) based on the FMI 3.0 standard (https://fmi-standard.org/docs/3.0-dev/#definition-of-types). At this point the name (e.g. "Binary interface visualization") and the description (e.g. "Interface for binary transfer of visualization information") are specified.
idShort	Description@en	example	[Property] BinaryConName
[IRI] https://admin-shell.io/idta/SimulationModels/BinaryConnectorName/1/0 Binary interface name.	[string]	1	[Property] BinaryConDescription

Predefined values for properties

The value lists listed here for certain properties are also contained in the AASX SMT published with the specification.

The values should be mapped in a semantic dictionary in the future, like eCl@ss. Until then, the value lists can be used. Depending on the property, it is recommended in the following subchapters whether a value selection should be closed or open.

"closed" … it is recommended to use one of the selections.

"open" … there is a possibility to add your own definition