The SSP Traceability Specification is a free specification intended as a third-party layered standard upon SSP 1.0 to support traceability of simulation tasks. This is a development version of the specification. Releases and issues can be found on github.com/PMSFIT/SSPTraceability.
1. Introduction
In the development of products, systems, and system components, design decisions often need to be made based on simulation results. The results of a simulation can be used as one aspect among others for design decisions. Design decisions have a major impact on the further development of a product, system or system component and can also have a significant impact on development costs. It is therefore important that design decisions are based on reliable information and especially on credible simulation results.
In order to make design decisions based on credible simulation results, it is essential that underlying simulation tasks are planned, executed and documented in a transparent and comprehensible manner and that there is a high degree of confidence in the correctness and validity of simulation results. This is essential not only to make reliable design decisions (quality assurance), but also to be able to understand design decisions retrospectively (traceability).
Improving traceability of decisions and simulations is the core objective of the SSP Traceability specification, based on consistent and compatible documentation of decision processes and simulation process that produces the decision-relevant simulation results. Other goals of the SSP Traceability specification are to provide the ability to re-run a simulation later and to provide the ability to re-use parts of the simulation setup for similar simulations (reusability).
1.1. Credible Simulation Process Framework
The SSP Traceability Specification applies in a Credible Simulation Process Framework as procedural framework, which consists of a Credible Decision Process and a Credible Simulation Process, coupled by a Simulation Request and a Simulation Delivery.
As the traceability of decision and simulation processes improve by applying the SSP Traceability Specification, it is expected that the reliability and credibility of simulation results will increase. This is expected not only when decisions and simulations are performed within a company, but also when the Credible Simulation Process Framework is spread across companies and when simulation results are requested, exchanged and shared across companies. Since the commissioning, preparation and execution of a simulation in that case are usually carried out by different persons or departments, sometimes even by different companies, a common understanding of the simulation task and the objectives of the simulation is essential for the quality and credibility of simulation results. Traceable documentation of simulation requests and simulation deliveries is therefore just as important as traceable documentation of the decision processes and simulation processes themselves.
1.2. Applying SSP Traceability
The SSP Traceability Specification defines and describes a concept for assuring traceability for the processes of the Credible Simulation Process Framework. The specification proposes to document Credible Decision Processes and Credible Simulation Processes by binding (gluing) together all process-relevant resources and information in the sense of process metadata by means of appropriate SSP Traceability files for Credible Decision Processes and Credible Simulation Processes. The essential core of the SSP Traceability Specification document is the documentation of the appropriate set of SSP Traceability file data formats.
1.3. Document structure
Chapter 2 describes the Credible Simulation Process Framework as the procedural context of SSP Traceability while Chapter 3 introduces the SSP Traceability concept and its associated set of data formats without going into detail. The detail description of the SSP Traceability data formats is subject of Chapter 5 through Chapter 8. Chapter 5 describes a common set of re-usable metadata description elements. Chapter 6 describes how the SSP Traceability data format for documenting Credible Decision Processes are structured and Chapter 7 describes the structure of SSP Traceability data formats for the documentation of Credible Simulation Processes. Chapter 8 additionally describes a data format for documenting resource metadata von resources in the sense of SSP Traceability. Chapter 9 describes how SSP Traceability files can be bundled into an SSP Traceability package. The SSP traceability specification concludes with a list of other applicable documents such as relevant standards and referenced literature.
| High-quality documentation of simulation tasks using the SSP traceability mechanisms can only reflect the quality and consistency of the simulation task actually performed to the maximum. However, the quality of the documentation does not guarantee the quality of the performed process. |
1.4. Conventions used in this document
-
The version number of this specification is to be interpreted according to the Semantic Versioning Specification (SemVer) 2.0.0 [SEMVER200].
-
Non-normative text is given in square brackets in italic font: [Especially examples are defined in this style.]
-
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119 [RFC2119].
-
All name spaces and reverse domain notation domain names used in this draft version of this document are subject to change once the draft is finalized.
2. Credible Simulation Process Framework
Throughout the product development process as part of the product life-cycle a large number of design decisions are made, each of which follows its own decision process, named Credible Decision Process. These decisions are based on simulation results, among other criteria. To obtain the decision-relevant simulation results, simulations are performed, often based on a complex simulation process, named Credible Simulation Process. This process constellation forming the Credible Simulation Process Framework is illustrated in Figure 1.
The Credible Decision Process and the Credible Simulation Process in principle are separate and independent processes, especially since they may be carried out by different roles and organizations or even different companies. However, the processes are linked by communication or information transfer. When a Credible Decision Process identifies the need for a simulation, a Simulation Request is made and a Credible Simulation Process is initiated. The Credible Simulation Process then starts as an independent process.
The result of a Credible Simulation Process, i.e. the simulation results, is then delivered to the triggering Credible Decision Process. This information transfer is referred to as Simulation Delivery in Figure 1.
For more information on the processes of the Credible Simulation Process Framework, see [SETLEVEL].
Note: The Credible Simulation Process Framework actually includes more than just Credible Decision Process and Credible Simulation Process. However, the SSP Traceability specification currently only supports traceability with respect to the Credible Decision Process and the Credible Simulation Process.
2.1. Credible Decision Process
The Credible Decision Process as part of the Credible Simulation Process Framework consists of five successive phases, starting with the analysis of the decision to be made through the preparation of the decision and up the actual decision itself. The preparation includes all activities necessary to obtain and evaluate the information on which the decision will be based. The information needed may include simulation results. Figure 2 illustrates this process.
The phases of the Credible Decision Process are:
- Analysis of Decision Task
-
In this phase, the information required for the execution of the decision process is determined and analyzed.
- Definition of Sub-Tasks
-
In this phase, the sub-tasks, e.g. simulation or test tasks, required to obtain the information on which the decision should be based are defined and specified.
- Performing Sub-Tasks
-
In this phase, the sub-tasks, e.g. simulation or test tasks, required to obtain the information on which the decision should be based, are defined and specified. The phase starts e.g. with the simulation request and ends with the simulation delivery from the perspective of the credible decision process.
- Evaluation
-
In this phase, the decision-relevant information returned from the sub-tasks, e.g. simulation results, is evaluated from the point of view of the Credible Decision Process.
- Fulfillment
-
The purpose of this phase is to decide whether the results fulfill the original objectives of the decision task.
For more information on the Credible Decision Process, see [SETLEVEL].
2.2. Credible Simulation Process
The Credible Simulation Process as part of the Credible Simulation Process Framework consists of seven successive phases starting with the analysis of the simulation task through stages of simulation preparation, simulation execution and evaluation of simulation results until the decision is made whether the simulation results meet the simulation objectives and thus the simulation task can be completed. The Credible Simulation Process is triggered and initiated by a Simulation Request. Figure 3 illustrates this process.
The phases of the Credible Simulation Process are:
- Analysis of Simulation Task
-
In this phase, the information from the higher-level Credible Decision Process, provided as a Simulation Request, is analyzed and detailed with respect to the information needed in the subsequent phases of the Credible Simulation Process.
- Definition of Simulation Requirements
-
In this phase, the requirements for the individual components of the simulation setup and their interaction as well as the requirements for quality assurance are formulated in detail.
- Design Specification
-
The purpose of this phase is to create all the specifications needed to implement the complete simulation setup.
- Implementation
-
The purpose of this phase is to implement the complete simulation setup with all its setup components as specified in the design specifications.
- Simulation Execution
-
The purpose of this phase is to run the simulation and record the simulation results. It may also include any necessary post-processing.
- Evaluation
-
The purpose of this phase is to evaluate the simulation results, i.e. to verify that the simulation results are plausible and robust.
- Fulfillment
-
The purpose of this phase is to confirm that the simulation results meet the original objectives of the simulation task.
For more information on the Credible Simulation Process, see [SETLEVEL].
3. Overview of SSP Traceability
As improving traceability of design decisions and simulations is one the core objectives of the SSP Traceability specification, a consistent and compatible documentation of decision processes and the simulation processes that produce decision-relevant simulation results is essential.
3.1. GlueParticle Approach
To enable the documentation of process-relevant information and resources for a Credible Decision Process or a Credible Simulation Process the SSP Traceability Specification introduces the GlueParticle Approach:
-
The GluePartice Approach is a concept for bundling and file-based transfer of process-relevant information and resources of a Credible Decision Process or a Credible Simulation Process.
-
A GluePartice is a bundle of process-relevant information and resources for a Credible Decision Process or a Credible Simulation Process. The form in which this bundle exists, e.g. whether it is stored as a file or in a database or a specific data format, is not specified.
-
A GlueParticle file is a GlueParticle that is in a file-based representation and can therefore be transferred between tools or organizational units such as people, departments, or companies.
-
File-based resources linked by a GlueParticle file should be exchanged with the GlueParticle file itself to take full advantage of the GlueParticle transfer.
| Although the idea of the GlueParticle approach does not depend on a specific data format or representation in general, the SSP Traceability Specification defines a set of data formats for the file-based representation of a GlueParticle content, i.e. process-relevant information and resources. The reason for this is firstly that the Modelica Association uses XML as a general encoding format for the representation of standards specific data and secondly that SSP Traceability uses System Structure and Parameterization (SSP) Standard 1.0 resources and concepts that are also encoded in XML. Independently of this, SSP Traceability files in general and GlueParticle files in particular could use any other applicable data encoding format, e.g. JSON etc. |
The SSP Traceability specification specifies a set of data formats that can be used to document or link process-relevant information and resources for a Credible Decision Process and a Credible Simulation Process introduced in Chapter 2. The data formats are specified as a set of XML Schema files according to the W3C (https://www.w3.org/) XML Schema standard [XMLSCHEMA1.1].
The main data formats specified by this specification are:
- Decision Task Meta Data (DTMD)
-
XML format representing process-relevant information to the Credible Decision Process (see Section 3.2 for an introduction and Chapter 6 for the detailed specification).
- Simulation Task Meta Data (STMD)
-
XML format representing process-relevant information to the Credible Simulation Process (see Section 3.3 for an introduction and Chapter 7 for the detailed specification).
A third XML format defined by the SSP Traceability specification is:
- Simulation Resource Meta Data (SRMD)
-
XML format representing metadata for resources (see Section 3.4 for an introduction and Chapter 8 for the detailed specification).
In order to use recurring description elements consistently, they have been defined in a separate XML Schema that is referenced by the three XML Schemas mentioned above. As a result, these description elements are also available in the DTMD XML Schema, the STMD XML Schema, and the SRMD XML Schema. The XML Schema for common content is named
- Simulation Traceability Common (STC)
-
XML Schema representing recurring description elements of the other tree XML Schemas(see Section 3.5 for an introduction and Chapter 5 for the detailed specification).
XML files that are compatible with the DTMD or STMD XML Schema are referred to as GlueParticle files. SRMD data format instances are not referred to as GlueParticle files. The STC data format is never instantiated as an individual XML file.
Figure 4 summarizes and illustrates the cross-file structure and dependencies of the SSP Traceability data format set and its appropriate file instances.
A GlueParticle file represents the structure of a process to be documented. This means that it is structured in a similar way as the process, i.e., it contains elements for documenting process-relevant information and resources related to phases and steps of the process, supplemented by some additional elements for information about the life-cycle of the GlueParticle information, cross-functional general information and additional administrative information, such as signatures, classifications and annotations.
A GlueParticle file with its embedded or linked information and resources can be used in a number of use cases, including to
-
Transfer information about the current state of a process across an organization, i.e. between teams, departments and business units, or even between companies if both units support the GlueParticle approach
-
Pass process-relevant information from one IT tool to another, if both tools are able to read and write GlueParticle files
-
Support product, system, and simulation engineers and reviewers in understanding a design decision or simulation process
-
Document the quality of a process and thus the quality of the results and outcomes of a process
-
Understand the actual execution of a given process in case it is to be re-executed partially or entirely, or if parts of the process are to be re-used or adapted for similar decisions or simulations.
At any given time, a GlueParticle represents a snapshot of an available process-relevant information and resource stack. A GlueParticle does not contain its own full version history. A GlueParticle version history is built by a sequence of GlueParticles instead, each of them representing a separate snapshot of the information and resource stack. Thus, the GlueParticle version and version history management is subject of IT tool functionalities, not of the GlueParticle itself. Each time new information or a new resource reference is added to a GlueParticle, actually a new instance of the GlueParticle is created, representing the most recent snapshot of the available process-relevant information and resource stack.
Figure 5 illustrates the correlation of the Credible Simulation Process and the Simulation Task Meta Data (STMD) files as the corresponding GlueParticles files.
During the Credible Simulation Process, simulation task metadata is generated and stored as STMD GlueParticles in a data management system. As the Credible Simulation Process evolves, a new GlueParticle is created each time metadata needs to be stored. Thus the sequence of GlueParticles representing process-relevant information and resource stack snapshots correlate to the process progress. The content of the GlueParticles grows more and more with every new instance of the GlueParticle within a given GlueParticle sequence, illustrated by the increasing number of orange stars in Figure 5.
3.2. Decision Task Meta Data
Figure 6 shows the top-level structure of the DTMD XML Schema, which is the structural definition for DTMD GlueParticle files. The structure of a DTMD GlueParticle represents all five phases of the Credible Decision Process and, as further specified in Chapter 6, each element representing a phase has a phase-specific substructure, that represents the process steps within the phase. See Chapter 6 for a detailed specification of the DTMD GlueParticle file structure.
3.3. Simulation Task Meta Data
Figure 7 shows the top-level structure of the STMD XML Schema, which is the structural definition for STMD GlueParticle files. The structure of an STMD GlueParticle represents all seven phases of the Credible Simulation Process and, as further specified in Chapter 7, each element representing a phase has a phase-specific substructure, that represents the process steps within the phase. See Chapter 7 for a detailed specification of the STMD GlueParticle file structure.
3.4. Simulation Resource Meta Data
Figure 8 shows the top-level structure of the SRMD XML Schema, which is the structural definition for Simulation Resouce Meta Data files. SRMD files are used to define essential metadata for resources that can help users quickly understand the content and intent of a simulation resource through human-readable attributes without having to examine the resource in detail. For example, this support can reduce the effort required to analyze a set of resources received with a simulation request and simplify the selection of appropriate resources from a resource library.
However, the existence of Simulation Resource Meta Data files is not tied to the actual referencing of corresponding resources by DTMD files or STMD files. Simulation Resource Meta Data files can also exist for resources regardless of whether the corresponding resource is actually referenced or not. See Chapter 8 for a detailed specification of the Simulation Resource Meta Data file structure.
An important type of simulation resource is a simulation model. There are a number of standards, each defining model metadata for simulation models in a specific way. A common set of core simulation model metadata has been defined under the name "MIC Core", which is based on the concept of the "Model Identity Card" ([MICCORE2023]).
3.5. Simulation Traceability Common
The STC XML Schema defines a set of elements reused by the other three XML Schema files for multi-instanced information blocks. See Chapter 5 for a detailed specification of the STC elements.
3.6. GlueParticle Packaging
The SSP Traceability Standard is a so-called layered standard on SSP, i.e. it extends the scope and coverage of the System Structure and Parameterization Standard (SSP Standard) by additional concepts. The boundary conditions emerging from this approach are described in Section 3.6. One of the boundary conditions refer to the packaging format.
GlueParticles, by their nature, are not self-contained, but reference many resources that they tie together in their function as GlueParticles. Packaging GlueParticles together with their referenced resources into easily exchangeable packages is therefore of fundamental importance.
The current packaging approach is based on the SSP 1.0 standard, which also serves as the basis for other aspects. Chapter 9 details how GlueParticles can be packaged in SSP archives, either standalone or in a way that allows these archives to be treated as native SSP packages by SSP-aware processors. Ways to package GlueParticles in other container formats such as FMUs are also specified.
3.7. GlueParticle Linkage
GlueParticles tie the referenced resources together in a two-fold manner: The broad flow of dependencies from inputs via procedures to outputs, supported by rationale information is given by the explicit structure of the step elements.
This broad dependency chain can be enhanced via more fine granular links through the XLink mechanism based link sections that are present in each step and phase. XLink is an existing W3C (https://www.w3.org/) Standard, that is applied here. See [XLINK] for details of he nature and application of XLinks.
4. Common concepts for SSP Traceability
The SSP Traceability specification is based on the SSP standard and therefore employs many of its common concepts (see [SSP10] for details):
- Extensibility
-
SSP Traceability employs the extensibility mechanisms of SSP, specifically the extra files mechanism, to embed traceability information into existing SSP package files. Furthermore, SSP Traceability itself offers the SSP extensibility mechanisms, like annotations, in its own formats, to enable further extension capabilities, e.g. for layered standards on top of the SSP Traceability specification.
- MIME-type based format dispatch
-
For all resources referenced in its file formats, the specification uses MIME-type based format dispatch to allow
- Content addressing
-
All references between files are expressed through URIs, supporting both relative and absolute URIs for references.
The SSP Traceability specification extends on these concepts in the following ways:
- Extended Links
-
The specifications provide for generic linking of resources and parts of resources using XML XLink extended links with full control of grouping, directionalities and semantics through role definitions for anchors and arcs.
- Basic Structuring
-
All steps in process descriptions provide the same information structure (input, procedure, output and rationale) across the board, which provides a basic structuring of related resources at a coarse level, that can then be extended through extended links and classifications.
- Generic Meta Data through Classifications
-
All relevant modeling elements allow for arbitrary, but well-defined, meta-data provisoning through classifications: These are collections of keyword value pairs, including linking capabilities, that are grouped by user-defined namespaces defined by classification types. In this way layered standards can provide additional meaning and rules to meta-data meeting domain-specific or company-specific needs, while providing basic processing expectations for tools even in the absence of detailed knowledge of the specific classification type.
5. SSP Traceability Common
This chapter describes in detail the content and structure of the XML schema stc.xsd, which represent common concepts that are reused in the other XML schemas of the specification. The purpose of extractiong these elements is to increase the flexibility and extensibility of the GlueParticles approach and to help to apply the GlueParticles concept to other topics in product and system engineering.
5.1. GeneralInformationType
This element type is used to encapsulate general information about the simulation or decision task, which is not part of any specific phase or step.
The GeneralInformationType element type is structured by the following subordinated elements.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
DerivationChain |
Optional |
|
GResourceOrReference |
Optional |
|
Link |
Optional |
The Resource and ResourceReference elements if present, are used to provide additional information about the simulation task.
The GeneralInformationType element is not associated with any specific attributes beyond the common SSP attributes.
5.1.1. DerivationChain
The SSP Traceability data formats DTMD and STMD are primarily intended for the standardized exchange of information packages between tools and partners. They do not have built-in versioning mechanisms. The SSP Traceability package represents a snapshot of the used versions of the linked sources and resources. Versioning of sources and resources is done in the generating tools and data management systems.
The exception is the derivation chain. Each time an STMD or DTMD file is written, a new entry is created in the derivation chain with a unique identifier of the file from which the new instance is derived. When a tool or data management system receives an SSP Traceability container with STDM, DTMD back, it can check, by comparing the derivation chain with the target system’s data infrastructure, which version of the DTMD or STMD was sent. This serves as a basis for controlling the reintegration of received DTMD STMD and it can be determined what is already available, what has been modified, what is new, etc.
The DerivationChain element can be used to provide the appropriated set of information about files that were used to derive the current file. If the content of the current file can be considered to be derived from one or a set of other GlueParticle, then the top level meta data and DerivationChain information of those files should be included in their original order as entries in this file’s DerivationChain element.
The DerivationChain element is structured by the following subordinated elements.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
DerivationChainEntry |
Optional |
The DerivationChain element is not associated with any specific attributes beyond the common SSP attributes.
5.1.1.1. DerivationChainEntry
The DerivationChainEntry element is a single entry within the derivation chain.
The DerivationChainEntry element is not structured by subordinated elements.
The DerivationChainEntry element is associated with the following attributes.
| Attribute name | Optional / Mandatory | Attribute description |
|---|---|---|
GUID |
mandatory |
GUID identifier of referenced file. Must be globally unique and MUST change, whenever a new file with differing information is written. |
author |
Optional |
This attribute gives the name of the author of this file’s content. |
fileversion |
Optional |
This attribute gives a version number for this file’s content. |
copyright |
Optional |
This attribute gives copyright information for this file’s content. |
license |
Optional |
This attribute gives license information for this file’s content. |
generatingTool |
Optional |
This attribute gives the name of the tool that generated this file. |
generationDateAndTime |
Optional |
This attribute gives the date and time this file was generated. |
5.2. GElementCommon
Common element content for all modeling elements of the file.
The GElementCommon group is structured by the following subordinated elements.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
Classification |
Optional |
|
Annotations |
Optional |
5.2.1. Classification
The Classification element, which can occur multiple times, provides a set of classifications of an element, provided as keyword value pairs, the meaning of which is interpreted according to the name of the classification provided in the name attribute. This approach can be used, for example, to provide searchable keywords for content, or to assign and track quality or validation level requirements across the process, or to maintain variant or other classification content across the process.
The Classification element is structured by the following subordinated elements.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
ClassificationEntry |
Optional |
The Classification element is associated with the following attribute.
| Attribute name | Optional/ Mandatory | Attribute description |
|---|---|---|
type |
Optional |
This attribute provides the name of the type of classification being provided. The name should be unique across the Classification elements of the immediately enclosing element. In order to ensure uniqueness all types should be identified with reverse domain name notation (cf. Java package names or Apple UTIs) of a domain that is controlled by the entity defining the semantics and content of the classification. |
xlink:type |
Fixed |
Has the fixed value |
xlink:href |
Optional |
This attribute gives an optional link for the classification itself. This link can be given to provide additional, potentially human readable information on the classification type that tools can use to provide this information to the user, especially for unknown classification types. |
linkedType |
Optional |
This optional attribute specifies the MIME type of the resource pointed to by the |
5.2.1.1. ClassificationEntry
The ClassificationEntry element is structured by the following subordinated elements.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
##any |
Optional |
The ClassificationEntry element is associated with the following attributes.
| Attribute name | Optional / Mandatory | Attribute description |
|---|---|---|
keyword |
Mandatory |
This attribute gives the keyword for the classification entry (i.e. keyword value pair). It is left undefined whether this must be unique across the entries of the Classification element, or whether repeated entries are allowed. This will depend on the definition of the classification. |
type |
Optional |
This optional attribute specifies the MIME type of the value of the classification entry, i.e. the element content. It defaults to |
xlink:type |
Fixed |
Has the fixed value |
xlink:href |
Optional |
This attribute gives an optional link for the classification entry (i.e. keyword value pair). This link can be given in addition to any content of the classification entry, or it can be the sole information of the classification entry. The rules will depend on the definition of the classification. |
linkedType |
Optional |
This optional attribute specifies the MIME type of the resource pointed to by the |
5.2.1.1.1. ##any
The ClassificationEntry element may contain XML Elements of any kind, i.e. it provides the possibility and capability to code any kind of information regardless of what the containing schema specifies. This means, the name, structure and attributes of XML elements enclosed by a ClassificationEntry element are completely free.
5.2.2. Annotations
The Annotations element can be used to add a list of annotations, as specified in the SSP standard (see [SSP10] section 4.2 for details). The following description is non-normative, as the type is fully defined in the SSP standard.
The Annotations element is structured by the following subordinated elements.
| Sub element name | Optional/ Mandatory | Details |
|---|---|---|
Annotation |
Optional |
At least one Annotation element must be present if the Annotations element is present.
The Annotations element is not associated with any attributes.
5.2.2.1. Annotation
The Annotation element can be used to add a single annotation to the list of annotations.
| Sub element name | Optional / Mandatory | |
|---|---|---|
##any |
Optional |
The Annotation element is associated with the following attributes.
| Attribute name | Optional / Mandatory | Attribute description |
|---|---|---|
type |
Mandatory |
The unique name of the type of the annotation. In order to ensure uniqueness all types should be identified with reverse domain name notation (cf. Java package names or Apple UTIs) of a domain that is controlled by the entity defining the semantics and content of the annotation. For vendor-specific annotations this would e.g. be a domain controlled by the tool vendor. For MAP-SSP defined annotations, this will be a domain under the org.modelica prefix. |
5.2.2.1.1. ##any
The Annotation element may contain XML Elements of any kind, i.e. it provides the possibility and capability to code any kind of information regardless of what the containing Schema specifies. This means, the name, structure and attributes of XML elements enclosed by an Annotation element are completely free.
5.3. GPhaseCommon
Common element content for all phases.
The GPhaseCommon group is structured by the following subordinated elements.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
Links |
Optional |
|
LifeCycleInformation |
Optional |
|
GElementCommon |
Optional |
5.4. LifeCycleInformationType
The LifeCycleInformationType element type defines the structure and attributes of life-cycle information about the enclosing phase or step element.
The following life-cycle states are intended for use. In the following explanations, the term "information to which life-cycle status applies" always refers to a complete phase with all of its steps, or to a complete step within a phase. Life-cycle information never refers to more than one phase and never refers to more than one step within a phase.
-
Drafted: The information to which the life-cycle status applies represents a draft status and is still in progress. This can also mean that the information is not complete and is still being finalized.
-
Defined: The information to which the life-cycle status applies is considered complete and may be subject to review or validation.
-
Validated: The information to which the life-cycle status applies has been reviewed and validated.
-
Approved: The information to which the life-cycle status applies has been approved based on review and validation.
-
Archived: The information to which the life-cycle state applies has been set as valid and remains valid for this instance of the GlueParticle, but may not be reused for similar steps or phases in other GlueParticles (reuse is not allowed).
-
Retracted: The information to which the life-cycle status applies has been withdrawn and is considered invalid or may need to be revised.
Due to the inherent dependencies of life-cycles, life-cycle information in later phases will depend to some extent on the life-cycle status of earlier phases: For example, if the Implementation phase is marked as having reached Validated status, there would be a contradiction if the Requirements phase had only reached Drafted status. Multiple life-cycle information entries may exist to record the historical progression of the life-cycle status, but only the last entry in the document order, which will also be the most recent, is considered valid for the current file contents; earlier states only record historical data.
The LifeCycleInformationType element is structured by the following subordinated elements.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
Drafted |
Optional |
|
Defined |
Optional |
|
Validated |
Optional |
|
Approved |
Optional |
|
Archived |
Optional |
|
Retracted |
Optional |
5.5. LifeCycleEntryType
The LifeCycleEntryType element defines the structure and the attributes of life-cycle information entries and therefor is the basis of the Drafted, Defined, Validated, Approved, Archived and Retracted XML elements.
The LifeCycleEntryType element is structured by the following subordinated elements.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
GResourceOrReference |
Optional |
|
Responsible |
Mandatory |
|
Signature |
Optional |
|
GElementCommon |
Optional |
The LifeCycleEntryType element is associated with the following attributes.
| Attribute name | Optional / Mandatory | Attribute description |
|---|---|---|
date |
Mandatory |
Time-stamp when life-cycle entry was assigned. Note that the time stamp data type makes time zone information mandatory, so that a full ordering of times is possible. |
checksum |
Optional |
This attribute gives the checksum over the phase/step information stored in the enclosing phase/step element, calculated according to the #STMD' specification. This attribute is optional if the life-cycle stage is not Approved or Archived, but becomes required if the life-cycle stage is Approved or Archived. Optionally, digital signatures over this checksum can be provided using Signature elements in the enclosing lifecycle entry element. The checksum is calculated using the algorithm indicated by the checksumType attribute. |
checksumType |
Optional |
This attribute gives the algorithm for the calculation of the checksum attribute. MUST be SHA3-256 for now, indicating a SHA3 256bit secure hash algorithm, as specified in FIPS 202. In the future other checksum algorithms might be supported. |
5.6. StepType
The StepType element defines the structure and attributes of an individual step inside a phase of the overall simulation task.
The StepType element is structured by the following subordinated elements.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
Input |
Optional |
|
Procedure |
Optional |
|
Output |
Optional |
|
Rationale |
Optional |
|
Links |
Optional |
|
LifeCycleInformation |
Optional |
|
GElementCommon |
Optional |
The essential description elements of a step are explained below.
-
Input: Anything that is used, processed, or used as a source of information for the step can be specified or referenced as input.
-
Procedure: Anything that documents how a step should be performed or has been performed can be specified or referenced as a procedure. This can be self-written documentation or a predefined procedure.
-
Output: Anything that is created by the execution of a step, or that is considered the result of a step, can be specified or referenced as output.
-
Rationale: The rationale for the chosen approach to performing a step can be provided if required. Typically, this is used to justify decisions such as simplifications or deviations from the specification.
The StepType element is associated with the following attributes.
| Attribute name | Optional / Mandatory | Attribute description |
|---|---|---|
id |
Optional |
This attribute gives the model element a file-wide unique id which can be referenced from other elements or via URI fragment identifier. |
description |
Optional |
This attribute gives a human readable longer description of the model element, which can be shown to the user where appropriate. |
5.7. ParticleType
The ParticleType element defines the structure and attributes of an individual particle inside a step of a phase of the overall simulation task.
Particles are the descriptive elements of the step within the phases. There are four types of particles (see Section 5.6).
-
Input
-
Process
-
Output
-
Rationale
The ParticleType element is structured by the following subordinated elements.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
GResourceOrReference |
Optional |
|
GElementCommon |
Optional |
The ParticleType element is associated with the following attributes.
| Attribute name | Optional / Mandatory | Attribute description |
|---|---|---|
id |
Optional |
This attribute gives the model element a file-wide unique id which can be referenced from other elements or via URI fragment identifier. |
description |
Optional |
This attribute gives a human readable longer description of the model element, which can be shown to the user where appropriate. |
5.8. LinksType
The LinksType element defines the structure and attributes for the linkage mechanism to use links within the GlueParticle as well as links to external resources outside the GlueParticle.
The LinksType element is structured by the following subordinated elements.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
Link |
Mandatory |
The LinksType element is not associated with any specific attributes beyond the common SSP attributes.
5.8.1. Link
The Link element represents a single extended link relating two or more endpoints, regardless of whether they are GlueParticle internal or outside of the GlueParticle.
An extended link consists out of two or more Locator elements that address the resources outside of the link that are participating in the link, and optional Arc elements that provide traversal rules among the link’s participating resources:
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
Locator |
Mandatory |
|
Arc |
Optional |
The Link element is associated with the following attributes.
| Attribute name | Optional / Mandatory | Attribute description |
|---|---|---|
xlink:type |
Fixed |
Has the fixed value |
xlink:title |
Optional |
This attribute is used to describe the meaning of an entire link in a human-readable fashion. |
xlink:role |
Optional |
This attribute supplies semantic information about the link as a whole: The xlink:role attribute indicates a property that the entire link has. |
5.8.2. Locator
An extended link indicates resources that participate in it by means of Locator elements.
NOTE: A Locator element, by itself, does not constitute a link just because it has a href attribute; unlike simple links, it does not create an XLink-governed association between itself and the referenced resource.
The Locator element is not structured by subordinated elements.
The Locator element is associated with the following attributes.
| Attribute name | Optional / Mandatory | Attribute description |
|---|---|---|
xlink:type |
Fixed |
Has the fixed value |
xlink:href |
Mandatory |
This attribute provides an IRI reference that identifies a resource. |
xlink:label |
Optional |
This attribute provides a way for an Arc element to refer to it in creating a traversal arc. |
xlink:title |
Optional |
This attribute is used to describe the meaning of the resource in a human-readable fashion. |
xlink:role |
Optional |
This attribute supplies semantic information about the locator’s resource: The xlink:role attribute indicates a property that the resource has. |
5.8.3. Arc
An extended link may indicate rules for traversing among its participating resources by means of a series of optional Arc elements.
The traversal attributes (xlink:from and xlink:to) define the desired traversal between pairs of resources that participate in the same link, where the resources are identified by their locator’s label attribute values. The xlink:from attribute defines resources from which traversal may be initiated, that is, starting resources, while the xlink:to attribute defines resources that may be traversed to, that is, ending resources.
The semantic attributes (xlink:title and xlink:arcrole) describe the meaning of the arc’s ending resource relative to its starting resource. The xlink:arcrole attribute corresponds to the RDF notion of a property, where the role can be interpreted as stating that "starting-resource HAS arc-role ending-resource." This contextual role can differ from the meaning of an ending resource when taken outside the context of this particular arc. For example, a resource might generically represent a "person," but in the context of a particular arc it might have the role of "mother" and in the context of a different arc it might have the role of "daughter."
When the same resource serves as a starting resource in several arcs (whether in a single link or across many links), traversal-request behavior is unconstrained by this specification, but one possibility for interactive applications is a pop-up menu that lists the relevant arc or link titles.
The Arc element is not structured by subordinated elements.
The Arc element is associated with the following attributes.
| Attribute name | Optional / Mandatory | Attribute description |
|---|---|---|
xlink:type |
Fixed |
Has the fixed value |
xlink:from |
Mandatory |
The xlink:from attribute defines resources from which traversal may be initiated, that is, starting resources. |
xlink:to |
Mandatory |
The xlink:to attribute defines resources that may be traversed to, that is, ending resources. |
xlink:title |
Optional |
This attribute is used to describe the meaning of the arc in a human-readable fashion. |
xlink:arcrole |
Optional |
This attribute supplies semantic information about the arc: The xlink:arcrole attribute indicates a property that the arc relationship has. |
5.9. ResourceType
The ResourceType element defines the structure and attributes of information about a resource that is related to the particular step and particle. Multiple (or no) resources may be present.
The ResourceType element is structured by the following subordinated elements.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
Content |
Optional |
|
Summary |
Optional |
|
Metadata |
Optional |
|
Signature |
Optional |
|
GElementCommon |
Optional |
The ResourceType element is associated with the following attributes.
| Attribute name | Optional / Mandatory | Attribute description |
|---|---|---|
kind |
Mandatory |
This attribute indicates the kind of resource that is referenced, i.e. what role it plays in relation to the particle being described. Recommended value entries are 'document', 'requirement', 'specification', 'model', 'parameter', 'system', 'testcase', 'result', 'method', 'rationale', 'report', 'request', 'delivery', 'executable', 'configuration'. The meaning of the values are described directly below this table. If no more precise label applies, the kind 'document' can be used. |
scope |
Optional |
This attribute indicates the scope or level that a resource is specific to, i.e. whether the resource applies at a global, system, subsystem or component level. The use of this attribute is optional, i.e. it should only be specified where it makes sense to give this kind of information. |
type |
Mandatory |
This mandatory attribute specifies the MIME type of the resource, which does not have a default value. If no specific MIME type can be indicated, then the type application/octet-stream is to be used. |
source |
Optional |
This attribute indicates the source of the resource as a URI (cf. RFC 3986). For purposes of the resolution of relative URIs the base URI is the URI of the GlueParticle. Therefore for resources that are located alongside the GlueParticle, relative URIs without scheme and authority can and should be used to specify the component sources. For resources that are packaged inside an SSP that contains this GlueParticle, this is mandatory (in this way, the GlueParticle URIs remain valid after unpacking the SSP into the file system). If the source attribute is missing, the resource is provided inline as contents of the Content element, which must not be present otherwise. |
master |
Optional |
This attribute, if present, indicates the original, canonical master source for the resource. If it is present, it indicates that the content provided via source attribute and/or Content element is only a copy of the original, canonical data, and this attributes provides the URI reference to that original canonical master data. |
id |
Optional |
This attribute gives the model element a file-wide unique id which can be referenced from other elements or via URI fragment identifier. |
description |
Optional |
This attribute gives a human readable longer description of the model element, which can be shown to the user where appropriate. |
List of recommended value entries for the attribute kind with short explanations.
- 'document'
-
The Value 'document' can be used as a generic resource kind in any case a more specific kind does not fit to the referenced resource.
- 'requirement
-
The 'requirement' kind value is used to indicate that a resource contains a requirements document, or sets of consistent single requirements without distinguishing between different subjects to which the requirements apply.
- 'specification'
-
The 'specification' kind value is used to indicate that a resource contain a specifications document , or sets of consistent single specifications without distinguishing between different subjects to which the specifications apply.
- 'model'
-
The kind value 'model' is used to indicate that a resource contains a simulation model. It does not distinguish between parameterized models, which do not need additional parameters or unparameterized models, which require an additional parameter file.
- 'parameter'
-
The kind value 'parameter' is used to indicate that a resource contains parameters or sets of consistent parameters for a simulation model.
- 'system'
-
A resource of kind 'system' is or contains a reference to the system under test in a PDM system or similar IT system or any other kind of description of the system under test.
- 'testcase'
-
A resource of kind 'testcase' should contain information that describe how the simulation objectives are achieved at the operational level by one more test cases. A consistent set of test cases could be considered a technical breakdown of the simulation objectives.#
- 'results'
-
#A resource of kind 'result' should contain information that answers questions posed by the simulation requester about the goals and intent of the simulation. In principle, this could be any kind of result data, no matter what it actually represents in detail. If the result is intended to be an aggregated and condensed report, the value 'report' can be used instead.
- 'method'
-
A resource of kind 'method' should contain information that describes how a described process step is performed or should be performed.
- 'rationale'
-
A resource of kind 'method' should contain information about why a related process step is or was performed in the way it was performed. This is especially true for activities that were not performed in the specified way for good reasons, or where assumptions and simplifications were made.
- 'report'
-
A resource of kind 'report' should provide information about the requested results in a human-readable report format, i.e., aggregated and condensed to a level that directly relates to the requestor’s question or the goals and intent of the simulation.
- 'request'
-
A resource of kind 'request' should contain information provided by the "requester" to perform the task. The requestor here is synonymous with the parent process or requesting organizational unit.
- 'delivery'
-
A resource of kind 'delivery' should contain information that provides the "client" with information about the execution of the task and the result of the task.
- 'executable'
-
The type value 'executable' is used to indicate that a resource contains an executable file, such as a script or an Office file with an executable VBA macro.
- 'configuration'
-
A resource of kind 'configuration' contains a detailed description of the configuration of the simulation environment setup.
5.9.1. Summary
The Summary element provides an optional summary of the resource being referenced. The summary information is intended for human consumption to get an overview of the resource content without looking at the content itself. The summary content can be provided inline through the Content element, or it can be provided through the source URI attribute.
The Summary element is structured by the following subordinated elements.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
Content |
Optional |
|
Signature |
Optional |
|
GElementCommon |
Optional |
The Summary element is associated with the following attributes.
| Attribute name | Optional / Mandatory | Attribute description |
|---|---|---|
type |
Mandatory |
This mandatory attribute specifies the MIME type of the resource summary, which does not have a default value. If no specific MIME type can be indicated, then the type application/octet-stream is to be used. If markdown content is used, then the type text/markdown shall be used. |
source |
Optional |
This attribute indicates the source of the resource summary as a URI (cf. RFC 3986). For purposes of the resolution of relative URIs the base URI is the URI of the GlueParticle, if the sourceBase attribute is not specified or is specified as GlueParticle, and the URI of the referenced resource if the sourceBase attribute is specified as resource. This allows the specification of summary sources that reside inside the resource (e.g. an FMU) through relative URIs. For summaries that are located alongside the GlueParticle, relative URIs without scheme and authority can and should be used to specify the summary sources. For summaries that are packaged inside an SSP that contains this GlueParticle, this is mandatory (in this way, the GlueParticle URIs remain valid after unpacking the SSP into the filesystem). If the source attribute is missing, the summary is provided inline as contents of the Content element, which must not be resent otherwise. |
sourceBase |
Optional |
Defines the base the source URI is resolved against: If the attribute is missing or is specified as GlueParticle, the source is resolved against the URI of the GlueParticle, if the attribute is specified as resource the URI is resolved against the (resolved) URI of the resource source. |
5.9.2. MetaData
The MetaData element can specify additional metadata for the given resource. Multiple (or no) MetaData elements may be present.
The MetaData element is structured by the following subordinated elements.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
Content |
Optional |
|
Signature |
Optional |
|
GElementCommon |
Optional |
The MetaData element is associated with the following attributes.
| Attribute name | Optional / Mandatory | Attribute description |
|---|---|---|
kind |
Mandatory |
This attribute indicates the kind of resource meta data that is referenced, i.e. what role it plays in relation to the resource being described. |
type |
Mandatory |
This mandatory attribute specifies the MIME type of the resource meta data, which does not have a default value. If no specific MIME type can be indicated, then the type application/octet-stream is to be used. |
source |
Optional |
This attribute indicates the source of the resource meta data as a URI (cf. RFC 3986). For purposes of the resolution of relative URIs the base URI is the URI of the GlueParticle, if the sourceBase attribute is ot specified or is specified as GlueParticle, and the URI of the referenced resource if the sourceBase attribute is specified as resource. This allows the specification of meta data sources that reside inside the resource (e.g. an FMU) through relative URIs. For meta data that are located alongside the GlueParticle, relative URIs without scheme and authority can and should be used to specify the meta data sources. For meta data that are packaged inside an SSP that contains this GlueParticle, this is mandatory (in this way, the GlueParticle URIs remain valid after unpacking the SSP into the file system). If the source attribute is missing, the meta data is provided inline as contents of the Content element, which must not be present otherwise. |
sourceBase |
Optional |
Defines the base the source URI is resolved against: If the attribute is missing or is specified as GlueParticle, the source is resolved against the URI of the GlueParticle, if the attribute is specified as resource the URI is resolved against the (resolved) URI of the resource source. |
5.10. SignatureType
The SignatureType element defines the structure and attributes of the signature entity for a given step or phase.
The SignatureType element is structured by the following subordinated elements.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
Content |
Optional |
|
GElementCommon |
Optional |
The SignatureType element is associated with the following attributes.
| Attribute name | Optional / Mandatory | Attribute description |
|---|---|---|
role |
Mandatory |
This mandatory attribute specifies the role this signature has in the overall process. It indicates whether the digital signature is intended to just convey the authenticity of the information, or whether a claim for suitability of the information for certain purposes is made. In the latter case, the digital signature format should include detailed information about what suitability claims are being made. |
type |
Mandatory |
This mandatory attribute specifies the MIME type of the resource signature, which does not have a default value. If no specific MIME type can be indicated, then the type application/octet-stream is to be used. |
source |
Optional |
This attribute indicates the source of the resource signature as a URI (cf. RFC 3986). For purposes of the resolution of relative URIs the base URI is the URI of the GlueParticle, if the sourceBase attribute is not specified or is specified as GlueParticle, and the URI of the referenced resource if the sourceBase attribute is specified as resource. This allows the specification of signature sources that reside inside the resource (e.g. an FMU) through relative URIs. For signatures that are located alongside the GlueParticle, relative URIs without scheme and authority can and should be used to specify the signature sources. For signatures that are packaged inside an SSP that contains this GlueParticle, this is mandatory (in this way, the GlueParticle URIs remain valid after unpacking the SSP into the filesystem). If the source attribute is missing, the signature is provided inline as contents of the Content element, which must not be present otherwise. |
sourdceBase |
Optional |
Defines the base the source URI is resolved against: If the attribute s missing or is specified as GlueParticle, the source is resolved against the URI of the GlueParticle, if the attribute is specified as resource the URI is resolved against the (resolved) URI of the resource source. |
5.11. ContentType
The ContentType element defines the structure and attributes of inline content of an entity. If it is present, then the attribute source of the enclosing element must not be present.
The ContentType element is structured by following subordinated elements.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
##any |
Optional |
The ContentType is not associated with any specific attributes beyond the common SSP attributes.
5.11.1. ##any
The ContentType may contain XML Elements of any kind, i.e. the it provides the possibility and capability to code any kind of information regardless of what the Schema specifies. This mean the name, structure and attributes of XML elements enclosed by a contentType element is completely free.
5.12. ResponsibleType
The ResponsibleType element defines the structure and attributes of the responsible entry for a lifecycle entry of a step or a phase of the overall simulation task.
The ResponsibleType element is not structured by subordinated elements.
The ResponsibleType element is associated with the following attributes.
| Attribute name | Optional / Mandatory | Attribute description |
|---|---|---|
organization |
Optional |
This attribute gives the organization that is responsible for a given step. |
role |
Optional |
This attribute gives the role of the person that is responsible for a given step. |
name |
Optional |
This attribute gives the name of the person that is responsible for a given step. |
5.13. GResourceOrReference
The GResourceOrReference group is used to allow the specification of either a resource element or a reference to an existing resource element.
The GResourceOrReference group is structured by the following subordinated elements, which present a choice, i.e. only one of the elements may and must be present, however the group itself is usually repeated.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
Resource |
Mandatory |
|
ResourceReference |
Mandatory |
5.13.1. ResourceReference
The ResourceReference element is used to reference an existing Resource element, to avoid duplication of information about the resource. All relevant information about the resource is taken from the referenced Resource element, whereas the ResourceReference element only contains a reference to that Resource element, and additional common administrative information.
Semantically, it is treated as if the referenced Resource element where present instead of the ResourceReference element in its location.
The ResourceReference element is structured by the following subordinated elements.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
GElementCommon |
Optional |
The ResourceRefernece element is associated with the following attributes.
| Attribute name | Optional/ Mandatory | Attribute description |
|---|---|---|
xlink:type |
Fixed |
Has the fixed value |
xlink:href |
Optional |
This attribute identifies the |
id |
Optional |
This attribute gives the model element a file-wide unique id which can be referenced from other elements or via URI fragment identifier. |
description |
Optional |
This attribute gives a human readable longer description of the model element, which can be shown to the user where appropriate. |
6. Decision Task Meta Data File Format
The Decision Task Meta Data file (short: DTMD file) is an implementation of a GlueParticle for decition tasks. It is specified to support traceability, quality assurance and re-usability for decision tasks in terms of a credible decision process as it is specified in Document Reference. The following sub-chapters describe the structure of an DTMD file.
6.1. DecisionTaskMetaData
The DecisionMetaData element is the all enclosing top level XML element of DTMD files.
The DecisionTaskTaskMetaData element is structured by following subordinated element.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
GeneralInformation |
Optional |
|
AnalysisPhase |
Optional |
|
DefinitionPhase |
Optional |
|
ExecutionPhase |
Optional |
|
EvaluationPhase |
Optional |
|
FulfillmentPhase |
Optional |
|
GElementCommon |
Mandatory |
The DecisionTaskMetaData element is associated with the following attributes.
| Attribute name | Optional / Mandatory | Attribute description |
|---|---|---|
version |
Mandatory |
Version of DTMD format, 1.0.0-beta2 for this pre-release. |
name |
Mandatory |
This attribute gives the Decision Task a name, which can be used for purposes of presenting the Decision Task to the user, e.g. when selecting individual variant DTMDs from an SSP. |
id |
Optional |
This attribute gives the model element a file-wide unique id which can be referenced from other elements or via URI fragment identifier. |
description |
Optional |
This attribute gives a human readable longer description of the model element, which can be shown to the user where appropriate. |
author |
Optional |
This attribute gives the name of the author of this file’s content. |
fileversion |
Optional |
This attribute gives a version number for this file’s content. |
copyright |
Optional |
This attribute gives copyright information for this file’s content. |
license |
Optional |
This attribute gives license information for this file’s content. |
generatingTool |
Optional |
This attribute gives the name of the tool that generated this file. |
generationDateAndTime |
Optional |
This attribute gives the date and time this file was generated. |
GUID |
Mandatory |
GUID identifier of this DTMD file. Must be globally unique and MUST change, whenever a new file with differing information is written. |
6.1.1. GeneralInformation
The GeneralInformation element is used to encapsulate general information about the decision task, which is not part of any specific phase or step.
For the details of the GeneralInformation element structure and attributes see chapter Section 5.1.
6.1.2. AnalysisPhase
In the analysis phase, the decision-relevant information is taken from the higher-level commissioning engineering process and the essential decision-relevant requirements and goals of the decision task are derived from it. It is important that at the end of the analysis phase the essential decision requirements and the objectives of the decision task fully and clearly understood.
The AnalysisPhase element documents all relevant information.
The AnalysisPhase element is structured by the following subordinated element.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
AnalyzeEngineeringTask |
Optional |
|
VerifyAnalysis |
Optional |
|
GPhaseCommon |
Mandatory |
The AnalysisPhase element is associated with the following attributes.
| Attribute name | Optional / Mandatory | Attribut description |
|---|---|---|
id |
Optional |
This attribute gives the model element a file-wide unique id which can be referenced from other elements or via URI fragment identifier. |
description |
Optional |
This attribute gives a human readable longer description of the model element, which can be shown to the user where appropriate. |
6.1.3. DefinitionPhase
In the definition phase, ….
The DefinitionPhase element documents all relevant information.
The DefinitionPhase element is structured by the following subordinated element.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
DefineTasks |
Optional |
|
DefineResultQuality |
Optional |
|
VerifyTasks |
Optional |
|
GPhaseCommon |
Mandatory |
The DefinitionPhase element is associated with the following attributes.
| Attribute name | Optional / Mandatory | Attribut description |
|---|---|---|
id |
Optional |
This attribute gives the model element a file-wide unique id which can be referenced from other elements or via URI fragment identifier. |
description |
Optional |
This attribute gives a human readable longer description of the model element, which can be shown to the user where appropriate. |
6.1.4. ExecutionPhase
In the execution phase, the previously defined tasks are executed with respect to the defined result quality.
The ExecutionPhase element documents all relevant information.
The ExecutionPhase element is structured by the following subordinated element.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
PerformTasks |
Optional |
|
GPhaseCommon |
Mandatory |
The ExecutionPhase element is associated with the following attributes.
| Attribute name | Optional / Mandatory | Attribute description |
|---|---|---|
id |
Optional |
This attribute gives the model element a file-wide unique id which can be referenced from other elements or via URI fragment identifier. |
description |
Optional |
This attribute gives a human readable longer description of the model element, which can be shown to the user where appropriate. |
6.1.5. EvaluationPhase
In the evaluation phase, the results of the tasks performed are evaluated and quality assurance measures are implemented.
The EvaluationPhase element documents all relevant information.
The EvaluationPhase element is structured by the following subordinated element.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
EvaluateResults |
Optional |
|
AssureResultsQuality |
Optional |
|
DeriveResultsQualityVerdict |
Optional |
|
GPhaseCommon |
Mandatory |
The EvaluationPhase element is associated with the following attributes.
| Attribute name | Optional / Mandatory | Attribute description |
|---|---|---|
id |
Optional |
This attribute gives the model element a file-wide unique id which can be referenced from other elements or via URI fragment identifier. |
description |
Optional |
This attribute gives a human readable longer description of the model element, which can be shown to the user where appropriate. |
6.1.6. FulfillmentPhase
In the fulfillment phase, it is checked and decided whether the entire simulation task, including the simulation results, fulfills the requirements placed on the simulation by the commissioning higher-level engineering task and whether the simulation tasks can be completed.
The FulfillmentPhasePhase element documents all relevant information.
The FulfillmentPhase element is structured by the following subordinated element.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
DecideEngineeringObjectiveFulfillment |
Optional |
|
GPhaseCommon |
Mandatory |
The FulfillmentPhase element is associated with the following attributes.
| Attribute name | Optional / Mandatory | Attribute description |
|---|---|---|
id |
Optional |
This attribute gives the model element a file-wide unique id which can be referenced from other elements or via URI fragment identifier. |
description |
Optional |
This attribute gives a human readable longer description of the model element, which can be shown to the user where appropriate. |
7. Simulation Task Meta Data File Format
The Simulation Task Meta Data file (short: STMD file) is an implementation of a GlueParticle for simulation tasks. It is specified to support traceability, quality assurance and re-usability for simulation tasks in terms of a credible simulation process as it is specified in Document Reference. The following sub-chapters describe the structure of an STMD file.
7.1. SimulationTaskMetaData
The SimulationTaskMetaData element is the all enclosing top level XML element of STMD files.
The SimulationTaskMetaData element is structured by following subordinated element.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
GeneralInformation |
Optional |
|
AnalysisPhase |
Optional |
|
RequirementsPhase |
Optional |
|
DesignPhase |
Optional |
|
ImplementationPhase |
Optional |
|
ExecutionPhase |
Optional |
|
EvaluationPhase |
Optional |
|
FulfillmentPhase |
Optional |
|
GElementCommon |
Mandatory |
The SimulationTaskMetaData element is associated with the following attributes.
| Attribute name | Optional / Mandatory | Attribute description |
|---|---|---|
version |
Mandatory |
Version of STMD format, 0.x for this pre-release. |
name |
Mandatory |
This attribute gives the simulation task a name, which can be used for purposes of presenting the simulation task to the user, e.g. when selecting individual variant STMDs from an SSP. |
id |
Optional |
This attribute gives the model element a file-wide unique id which can be referenced from other elements or via URI fragment identifier. |
description |
Optional |
This attribute gives a human readable longer description of the model element, which can be shown to the user where appropriate. |
author |
Optional |
This attribute gives the name of the author of this file’s content. |
fileversion |
Optional |
This attribute gives a version number for this file’s content. |
copyright |
Optional |
This attribute gives copyright information for this file’s content. |
license |
Optional |
This attribute gives license information for this file’s content. |
generatingTool |
Optional |
This attribute gives the name of the tool that generated this file. |
generationDateAndTime |
Optional |
This attribute gives the date and time this file was generated. |
GUID |
Mandatory |
GUID identifier of this STMD file. Must be globally unique and MUST change, whenever a new file with differing information is written. |
7.1.1. GeneralInformation
The GeneralInformation element is used to encapsulate general information about the simulation task, which is not part of any specific phase or step.
For the details of the GeneralInformation element structure and attributes see chapter Section 5.1.
7.1.2. AnalysisPhase
In the analysis phase, the simulation-relevant information is taken from the higher-level commissioning engineering process and the essential simulation relevant requirements and goals of the simulation task are derived from it. It is important that at the end of the analysis phase the essential simulation requirements and the objectives of the simulation task fully and clearly understood.
The AnalysisPhase element documents all relevant information.
The AnalysisPhase element is structured by the following subordinated element.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
AnalyzeSimulationTaskAndObjectives |
Optional |
|
VerifyAnalysis |
Optional |
|
GPhaseCommon |
Mandatory |
The AnalysisPhase element is associated with the following attributes.
| Attribute name | Optional / Mandatory | Attribut description |
|---|---|---|
id |
Optional |
This attribute gives the model element a file-wide unique id which can be referenced from other elements or via URI fragment identifier. |
description |
Optional |
This attribute gives a human readable longer description of the model element, which can be shown to the user where appropriate. |
7.1.3. RequirementsPhase
In the requirements phase, the requirements for the simulation that were agreed and defined in the analysis phase are broken down to the individual components required for the simulation. This includes the requirements for the models, parameters, test cases and the simulation environment, but also for the integration of all components and for measures to assure the process quality. In addition, all requirements must be finally verified to ensure the integrity and consistency of the requirements.
The RequirementsPhase element documents all relevant information.
The RequirememtsPhase element is structured by the followuing subordinated element.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
DefineModelRequirements |
Optional |
|
DefineParameterRequirements |
Optional |
|
DefineSimulationEnvironmentRequirements |
Optional |
|
DefineSimulationIntegrationRequirements |
Optional |
|
DefineTestCaseRequirements |
Optional |
|
DefineQualityAssuranceRequirements |
Optional |
|
VerifyRequirements |
Optional |
|
GPhaseCommon |
Mandatory |
The RequirementsPhase element is associated with the following attributes.
| Attribute name | Optional / Mandatory | Attribute description |
|---|---|---|
id |
Optional |
This attribute gives the model element a file-wide unique id which can be referenced from other elements or via URI fragment identifier. |
description |
Optional |
This attribute gives a human readable longer description of the model element, which can be shown to the user where appropriate. |
7.1.4. DesignPhase
In the design phase, based on the requirements for the individual components of the simulation defined in the requirements phase, the required components of the simulation are specified, i.e. the models, parameters, test cases and the simulation environment, but also the necessary measures for integrating all components and for assuring the process quality. In addition, all specifications must be finally verified to ensure the integrity and consistency of the specifications.
The DesignPhase element documents all relevant information.
The DesignPhase element is structured by the following subordinated element.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
DefineModelDesignSpecification |
Optional |
|
DefineParaneterDesignSpecification |
Optional |
|
DefineSimulationEnvironmentDesignSpecification |
Optional |
|
DefineSimulationIntegrationDesignSpecification |
Optional |
|
DefineTestCaseDesignSpecification |
Optional |
|
DefineQualityAssuranceDesignSpecification |
Optional |
|
VerifyDesignSpecification |
Optional |
|
GPhaseCommon |
Mandatory |
The DesignPhase element is associated with the following attributes.
| Attribute name | Optional / Mandatory | Attribute description |
|---|---|---|
id |
Optional |
This attribute gives the model element a file-wide unique id which can be referenced from other elements or via URI fragment identifier. |
description |
Optional |
This attribute gives a human readable longer description of the model element, which can be shown to the user where appropriate. |
7.1.5. ImplementationPhase
In the implementation phase, all specified components of the simulation are implemented, i.e. the models, parameters, test cases and the simulation environment is set up. All components are then integrated and the specified measures to ensure process quality are implemented. In addition, it must be determined by a quality verdict that the entire setup of the simulation meets all technical and quality requirements.
The ImplementationPhase element documents all relevant information.
The ImplementationPhase element is structured by the following subordinated element.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
ImplementModel |
Optional |
|
ImplementParameter |
Optional |
|
ImplementSimulationEnvironment |
Optional |
|
ImplementTestCase |
Optional |
|
IntegrateSimulation |
Optional |
|
AssureSimulationSetupQuality |
Optional |
|
DeriveSimulationSetupQualityVerdict |
Optional |
|
GPhaseCommon |
Mandatory |
The ImplementationPhase element is associated with the following attributes.
| Attribute name | Optional / Mandatory | Attribute description |
|---|---|---|
id |
Optional |
This attribute gives the model element a file-wide unique id which can be referenced from other elements or via URI fragment identifier. |
description |
Optional |
This attribute gives a human readable longer description of the model element, which can be shown to the user where appropriate. |
7.1.6. ExecutionPhase
In the execution phase, the previously set up simulation is executed.
The ExecutionPhase element documents all relevant information.
The ExecutionPhase element is structured by the following subordinated element.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
ExecuteSimulation |
Optional |
|
GPhaseCommon |
Mandatory |
The ExecutionPhase element is associated with the following attributes.
| Attribute name | Optional / Mandatory | Attribute description |
|---|---|---|
id |
Optional |
This attribute gives the model element a file-wide unique id which can be referenced from other elements or via URI fragment identifier. |
description |
Optional |
This attribute gives a human readable longer description of the model element, which can be shown to the user where appropriate. |
7.1.7. EvaluationPhase
In the evaluation phase, the simulation results are evaluated and quality assurance measures are implemented. In addition, it must be determined by a quality verdict that the simulation meets all technical and quality requirements.
The EvaluationPhase element documents all relevant information.
The EvaluationPhase element is structured by the following subordinated element.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
EvaluateSimulationResults |
Optional |
|
AssureSimulationQuality |
Optional |
|
DeriveSimulationQualityVerdict |
Optional |
|
GPhaseCommon |
Mandatory |
The EvaluationPhase element is associated with the following attributes.
| Attribute name | Optional / Mandatory | Attribute description |
|---|---|---|
id |
Optional |
This attribute gives the model element a file-wide unique id which can be referenced from other elements or via URI fragment identifier. |
description |
Optional |
This attribute gives a human readable longer description of the model element, which can be shown to the user where appropriate. |
7.1.8. FulfillmentPhase
In the fulfillment phase, it is checked and decided whether the entire simulation task, including the simulation results, fulfills the requirements placed on the simulation by the commissioning higher-level engineering task and whether the simulation tasks can be completed.
The FulfillmentPhasePhase element documents all relevant information.
The FulfillmentPhase element is structured by the following subordinated element.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
DecideSimulationObjectiveFulfillment |
Optional |
|
GPhaseCommon |
Mandatory |
The FulfillmentPhase element is associated with the following attributes.
| Attribute name | Optional / Mandatory | Attribute description |
|---|---|---|
id |
Optional |
This attribute gives the model element a file-wide unique id which can be referenced from other elements or via URI fragment identifier. |
description |
Optional |
This attribute gives a human readable longer description of the model element, which can be shown to the user where appropriate. |
8. Simulation Resource Meta Data File Format
Simulation resource meta data for components or other resources (e.g. parameter sets, etc.) can be provided using SRMD files. These files can be embedded into such resources, where possible, they can be placed outside the resources and reference the resources to which they apply, or they can be tied to the resources through the STMD meta-data mechanisms.
8.1. SimulationRessourceMetaData
The SimulationResourceMetaData element is the all enclosing top level XML element of SRMD files.
The SimulationTaskMetaData element is structured by following subordinated element.
| Sub element name | Optional / Mandatory | Details |
|---|---|---|
GElementCommon |
Mandatory |
The SimulationResourceMetaData element is associated with the following attributes.
| Attribute name | Optional / Mandatory | Attribute description |
|---|---|---|
version |
Mandatory |
Version of SRMD format, 0.x for this pre-release. |
name |
Mandatory |
This attribute gives the simulation resource meta data a name, which can be used for purposes of presenting the simulation resource meta data to the user. |
data |
Optional |
This optional attribute gives a URI to the data item this resource meta data applies to. If this attribute is not present, then the data this resource meta data applies to is provided outside of the meta data (e.g. by embedding SRMD into the data format, or providing it as meta data in an STMD file). |
checksum |
Optional |
This attribute gives the checksum over the data item this meta data applies to. This is optional information to allow the identification of the data item and the precise algorithm specifying. The checksum is calculated using the algorithm indicated by the checksumType attribute. |
checksumtype |
Optional |
This attribute gives the algorithm for the calculation of the checksum attribute. MUST be SHA3-256 for now, indicating a SHA3 256bit secure hash algorithm, as specified in FIPS 202. In the future other checksum algorithms might be supported. |
id |
Optional |
This attribute gives the model element a file-wide unique id which can be referenced from other elements or via URI fragment identifier. |
description |
Optional |
This attribute gives a human readable longer description of the model element, which can be shown to the user where appropriate. |
author |
Optional |
This attribute gives the name of the author of this file’s content. |
fileversion |
Optional |
This attribute gives a version number for this file’s content. |
copyright |
Optional |
This attribute gives copyright information for this file’s content. |
license |
Optional |
This attribute gives license information for this file’s content. |
generatingTool |
Optional |
This attribute gives the name of the tool that generated this file. |
generationDateAndTime |
Optional |
This attribute gives the date and time this file was generated. |
9. SSP Traceability Packaging
This section specifies the packaging of simulation task meta-data packages, as a third-party layered standard upon SSP [SSP10]. Simulation task meta-data packages allow the packaging of simulation task meta-data files together with related system descriptions, models and other resources using the SSP packaging format.
9.1. Introduction
The current specification specifies the packaging of simulation task meta-data files together with all referenced system descriptions, models, parameters, their meta-data, simulation results and other resources in SSP 1.0 package files as a layered standard based on SSP 1.0.
By basing the packaging on the SSP standard, it is possible to treat STMD containing SSP packages as normal SSP packages for use in tools that do not yet support STMD-based work flows. Furthermore this approach simplifies the definition of STMD-based packages by reusing the built-in functionality of the SSP standard.
9.2. SSP 1.0
Any STMD-based package MUST be a valid SSP 1.0 [SSP10] SSP archive.
Inter alia this means that it MUST contain at least one SSD file named
SystemStructure.ssd in the root of the archive, which MUST be a valid
system structure description file. In phases of the simulation task
workflow where a proper system structure description has not yet been
created, this CAN be a dummy file containing an otherwise empty system.
Those cases will be recognizable by the content of the STMD file.
9.3. STMD File
Any STMD-based package MUST include an STMD XML file under the extra/org.ssp-standard.ssp-traceability.stmd/SimulationTask.stmd name.
The file MUST be a valid STMD file according to the specification below.
A Simulation Task Meta Data file (STMD, file extension .stmd) MUST be a well-formed XML 1.0 [XML10] file that conforms to the SimulationTask XML Schema distributed as part of this standard. The file MUST use the UTF-8 encoding.
All STMD-specific elements live in the http://ssp-standard.org/SSPTraceability1/SimulationTaskMetaData namespace, nicknamed stmd in this document.
The root element of an STMD file MUST be a SimulationTaskMetaData
element, which gives overall information about the simulation task
described in this STMD file.
The STMD file CAN reference any system structure descriptions that the
simulation task is intended to use through Resource elements with the
attribute source providing the URI to the SSD file. The relative URI
resolution mechanisms are the same as for SSP generally, so that the
URI will be resolved against the URI of the STMD file as a base URI.
Hence a reference to the main SSD of an SSP package will be specified as
<stmd:Resource source="../../SystemStructure.ssd" type="application/x-ssp-definition" kind="system"/>
due to the relative location of the STMD file.
Simulation model meta data and parameter meta data is referenced inside
the STMD file using either Resource records directly if the meta data
is directly relevant, or through MetaData elements inside Resource
elements if the meta data is only used in a meta data role.
If meta data is intended to be carried in the purely SSP subset of the SSP package, then the following sections apply.
The MIME type of STMD files is application/x-stmd-simulationtask, the
file name extension is .stmd.
9.4. SRMD
Simulation resource meta data for components or other resources (e.g. parameter sets, etc.) can be provided using SRMD files. These files can be embedded into such resources, where possible, they can be placed outside the resources and reference the resources to which they apply, or they can be tied to the resources through the STMD meta-data mechanisms.
The MIME type for SRMD files is application/x-srmd-meta-data, the file
name extension is .srmd.
9.4.1. Attaching via STMD meta-data mechanism
For SRMD data that is to be tied to the resource through the STMD
meta-data mechanism, the SRMD file is either referenced from or
contained in the MetaData elements for the resource.
9.4.2. Embedding into FMUs
For FMUs the SRMD file CAN be embedded by placing the SRMD data into a file named extra/org.ssp-standard.ssp-traceability.srmd/resourceMetaData.srmd in the FMU archive.
9.4.3. Embedding into SSPs
For SSPs the SRMD file that applies to the SSP as a whole CAN be embedded by placing the SRMD data into a file named extra/org.ssp-standard.ssp-traceability.srmd/resourceMetaData.srmd in the SSP archive.
9.4.4. Placing beside resources
When placing an SRMD file beside (i.e. outside of) the referenced
resources, the SRMD file SHOULD be named like the resource file name,
where possible, with a file name extension of .srmd.
The data attribute of the SRMD top-level element SHOULD provide a URI
to the resource.
References
-
[RFC2119] Bradner, S.: Key words for use in RFCs to Indicate Requirement Levels. RFC 2119, March 1997. https://www.ietf.org/rfc/rfc2119.txt
-
[SEMVER200] Preston-Werner, T.: Semantic Versioning 2.0.0. https://semver.org/spec/v2.0.0.html
-
[SSP10] Modelica Association: System Structure and Parameterization 1.0. March 2019. https://ssp-standard.org/publications/SSP10/SystemStructureAndParameterization10.pdf
-
[XMLSCHEMA1.1] World Wide Web Consortium, Inc. (W3C): XML Schema 1.1. April 2012. https://www.w3.org/XML/Schema
-
[XLINK] World Wide Web Consortium, Inc. (W3C): XLink 1.1. May 2010. https://www.w3.org/TR/xlink/
-
[MICCORE2023] IRT SystemX and prostep ivip MIC Core specification: https://mic-core.github.io/MIC-Core/main/
-
[SETLEVEL] Credible Simulation Process Framework in GitLab: https://gitlab.setlevel.de/open/processes_and_traceability/credible_simulation_process_framework