The MIC Core specification is a free standard that defines a set of harmonized model meta data attributes that meta-data standards can adopt to avoid ambuity and incompatibility in common attributes across domains and standards. It is maintained as a joint undertaking of IRT SystemX and prostep ivip. Releases and issues can be found on github.com/MIC-Core/MIC-Core.
Copyright © 2022-2023 IRT SystemX and 2022-2023 prostep ivip.
1. Introduction
1.1. Why MIC Core
The exchange and reuse of simulation models within the company and with external partners is becoming increasingly important.
For efficient exchange and reuse
-
Information, metadata about the properties of the models is required (what does the model represent, which effects are implemented)
-
as well as administrative information (name, owner, version,…).
Currently there are several standards for model meta data, or they are being developed from several organisations
1.2. What is MIC Core
MIC Core is defining a standard of core attributes (key information on simulation models that enables proper useage in the usecases) that other standards can adopt, extend, refine. Goal is to have a set of aligned attributes, that means
-
we are focussing on meta data for simulation models
-
also link to further detailed information which is needed for deeper traceability
The development of MIC Core was prompted by the Model Identity Card (MIC) (see [MIC]) and other metadata standards and the realization that certain core attributes should be standardized across the different metadata standards.
1.3. Overview
In the moment existing "standards" for simulation model meta data adress specific use cases, engineering domains or simulation levels like causal, acausal, geometry level, realtime,…. We want to extract and align the core information from this approaches for
-
traceability
-
support implementation in tools
-
not focusing
-
on process information
-
or how to implement
-
We are open to future transfer of that specification to an other offical standardization body
-
in the moment it is a cooperation of organizations
-
the harmonization activity is result of a long standing cooperation of irt-systemX and prostep ivip, as well as more resent exchanges with other organisations
1.4. Properties and Guiding Ideas
The goal of MIC Core is not to have one standard, but to identify and harmonize the overlapping attributes. So, there is a common aligned part (MIC Core) of attributes in every standard, but also, standard specific attributes according to the different use cases, domains in the standards. The standards will stay independent but will have aligned parts.
Approach:
We identified similar attributes in the standards like
-
model.name
-
General information.Name
-
ModelName
and definded a "Common Attribute Name" Model Name.
The specific attributes differ slightly due to the naming conventions in the different standards. The important point was then the alignment of explanation and interpretation of the attribute name. With that approach a mapping and common understanding is achived.
We introduced three different kinds of attributes: Mandatory, Recommended, Optional.
-
Attributes are mandatory, if they are essential for traceability
-
Attributes are recommended, if the information is in general of high importance for understanding
-
Attributes are optional, if they are important in special use cases
1.5. Versioning
This specification uses semantic version numbers, as defined in [PW13], where the standard version consists of a triple of version numbers, consisting of major version, minor version, and patch version numbers.
In the context of MIC Core, major versions can add, delete or change attribute definitions, minor versions can only add or clarify attribute definitions, and patch versions can only clarify attribute definitions.
1.6. How to Apply this Standard
This specification is directed at authors of meta-data and meta-data format standards. It is intended that standards that want to adopt the MIC Core set of attributes shall do so by claiming conformance as specified in section Section 3. This involves the adoption of the attribute definitions of the MIC Core under the rules set down in section Section 3.
End users of these standards will look towards the standards for the full specifications of all attributes, whether adopted from MIC Core or not.
1.7. How to Read This Document
Conventions used in this document:
-
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", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (regardless of formatting and capitalization).
2. MIC Core Attributes
This chapter introduces and describes the list of MIC core attributes. Each attribute is introduced with a attribute description and an indication of the attribute obligation, i.e., whether the attribute is mandatory, recommended, or optional, and whether the attribute can be instantiated multiple times or not. To enhance the understanding of an attribute, some value examples and, if applicable, additional explanations or rationales for the attribute are provided .
The attributes are organized by the following attribute groups:
-
Administrative data
-
Purpose and objectives
-
Subject information
-
Implementation
-
Verification and validation
2.1. Administrative data
The Administrative Data category contains information used to identify and organize the models. For example, this may include the name, ID, and version information of the model. Administrative data also includes information about the authorization to use the model and the level of confidentiality of the model.
2.1.1. Model name
- Attribute description
-
Human-readable way of referring to the model. Usually short and clear. Not necessarily unique. To be distinguished from the model identifier and file name.
- Obligation
-
Mandatory
- Can have multiple values
-
No
- Value examples
-
-
Electric motor/generator
-
Parametrized motor
-
Permanent magnet DC machine
-
2nd order mass
-
- Additional explanation and rationale
-
From a user’s perspective, the model name is an important characteristic of a model. A model name is easier to remember than an identifier, and model names play an important role when searching for or retrieving models. When models are imported into a data management system, the system typically expects a model name as a mandatory attribute.
2.1.2. Model identifier
- Attribute description
-
Unique identifier for the model. Possibly only locally unique, within a given IT system. May not be specific to a given release of the model. The syntax and interpretation of the identifier is not standardized and open to the implementer. Can for example be based on a URI, a model path, or a UUID.
- Obligation
-
Recommended
- Can have multiple values
-
No
- Value entry examples
-
-
part.Engine.combustion.BMW_S58Engine
-
4fc009cc-2dae-4df9-b6b2-0b535038c8e8
-
//server/home/user/models/mymodel
-
- Additional explanation and rationale
-
The model identifier, unlike the model name, is typically unchangeable. Different releases of a model may have the same model identifier is the same. In this case, both the model identifier and the model release are required for model desambiguation.
2.1.3. Model description
- Attribute description
-
Human-readable, textual, general overview. Highlights important information about the model. May include some information formalized in other attributes, without expectation of completeness.
- Obligation
-
Recommended
- Can have multiple values
-
No
- Value entry examples
-
-
This model simulates the heat exchange between S58 engine and cooling system
-
DRVELMT01 is a model of electric motor/generator with its converter. The output torque and power losses can be determined either by using data files or characteristic parameters. This model is bidirectional.
-
- Additional explanation and rationale
-
For the recipient of a simulation model, a textual description or summary of the model’s contents and possible uses may be helpful. A quick overview avoids having to look at all the attributes.
2.1.4. Release
- Attribute description
-
Unique identifier, preferably human-readable (i.e. semantically meaningfull), for the release of a particular simulation model. Represents the result of the intentional act of releasing a model at a particular stage to a particular audience (different from the more general notion of version).
- Obligation
-
Mandatory
- Can have multiple values
-
No
- Value entry examples
-
-
V3.2.4
-
0.1a
-
1.2.0-alpha.1+build.x64.010
-
Version 10.0.19044 Build 19044
-
1.9.9.12-DB:C5:D9:3F:DA:19:C5:82:40:80:8B:A5:33:A4:DC:5F
-
- Additional explanation and rationale
-
A human-readable release can help the recipient of the model and, more generally, the development stakeholders.
2.1.5. Release date
- Attribute description
-
Date, and possibly time and timezone, of the release of a simulation model. Must respect ISO 8601.
- Obligation
-
Recommended
- Can have multiple values
-
No
- Value entry examples
-
-
2023-03-27T12:27:04Z
-
- Additional explanation and rationale
-
Release dates permit to clarify the chronolgy of releases (How old is a simulation model? What simulation model came first? etc.).
2.1.6. Release type
- Attribute description
-
Relates to the maturity of the model. To be distinguished from a changing status (e.g. outdated). Fixed at the time of the release and not changing. Allows the receiver to evaluate the usage limitations of a given release (e.g. a prelease shall not be used for final system validation).
- Obligation
-
Recommended
- Can have multiple values
-
No
- Value entry examples
-
-
internal-release
-
pre-release
-
production release
-
only for demonstration
-
2.1.7. Model supplier
- Attribute description
-
The responsible body and, if applicable, organizational unit within the body, that is responsible for supplying the model. Can be different from the owner or the creator of the model. Should be as specific as possible but also durable, avoiding for example specific people names. Relevant personal data protection guidelines should be takend into account. In case of model assembly, responsible of the overall assembly.
- Obligation
-
Mandatory
- Can have multiple values
-
No
- Value entry examples
-
-
company Z, department SD
-
www.company-Z/models
-
personal data, e.g. company Z, Peter Miller can be problematic
-
- Additional explanation and rationale
-
The attribute is classified as mandatory because it is very important to know who provided the model, and because it is important to be able to contact the model provider in case of questions about the model.
2.1.8. Model confidentiality level
- Attribute description
-
Protection level to apply to the model. Does not specify the organizational scope. Does not define what a receiver is allowed to do or is not allowed to do. Values should be "0: public", "1: internal", "2: confidential" or "3: strictly confidential". Additional processes and tools are required to ensure confidentiality.
- Obligation
-
Mandatory
- Can have multiple values
-
No
- Value entry examples
-
-
0: public
-
1: internal
-
2: confidential
-
3: strictly confidential
-
- Additional explanation and rationale
-
While such a confidentiality level is less relevant for cross-enterprise model exchange, it is highly relevant for intra-enterprise sharing.
2.1.9. Legal restriction
- Attribute description
-
Defines the rules governing the distribution and usage of the simulation model, including licensing, in the form of an open field: royalties to pay, restriction to noncommercial use, right to modify, related legal contract, etc.
- Obligation
-
Optional
- Can have multiple values
-
Yes
- Value entry examples
-
-
Company Z confidential
-
GPL
-
License MIT
-
Legal contract #0987654321
-
- Additional explanation and rationale
-
Information about legal restrictions can help avoid legal uncertainties in the use of models. However, since such restrictions do not always exist, this attribute is optional.
2.2. Purpose and objectives
Information in the category Purpose and Objectives describe the purpose for which the model is designed and what may be simulated with the model with which objective. This may be formulated quite generally, for example "Simulation of the electrical behavior of a DC motor". However, it may also be much more specific, for example "Simulation of the ramp-up current characteristics of a DC motor", if the model allows a very high sampling rate of the electrical current.
2.2.1. Model purpose
- Attribute description
-
Purpose for which the model has been built/validated. Free textual field for short human-readable description.
- Obligation
-
Recommended
- Can have multiple values
-
No
- Value entry examples
-
-
Minimization of the maximum value of an engine’s energy consumption
-
Evaluation of the average breaking distance under uncertain weather conditions
-
Automated driving function validation in an OEM environment at object-list level
-
Efficency evaluation of a gear box in combination with a SW-function
-
2.3. Subject information
Subject information is information that names the modeled concrete object, for example an individual system or product component, a system, an entire product or an assumed object from the environment of a product. This could be, for example, a very specific DC motor, an electronic vehicle stabilization system in a specific configuration, a specific vehicle type, or even a hypothetical pedestrian with a specific, specifically described set of properties.
2.3.1. Modelled entity
- Attribute description
-
Name or description of the object represented by the simulation model.
- Obligation
-
Recommended
- Can have multiple values
-
No
- Value entry examples
-
-
Camera
-
Gear box type xyz23
-
Electrical car, model X, version Y, configuration Z
-
- Additional explanation and rationale
-
The modelled entity can typically be a system whose development is supported by simulation. There may not be any specific modelled ententy when a simulation rather represents general physical phenomena.
2.4. Implementation
Information from the modeling implementation category describes how the model was created or how it should be created. This includes, for example, information on the modeling language and the modeling tool and, if necessary, on the compiler used. This can also include a description of the modeling approach.
2.4.1. Modeling choice
- Attribute description
-
Explanation of the modeling choices, assumptions or simplifications made during the implementation of the model. It should include:
1) effects or phenomena covered introduced in general terms, such as vibration of thermal effects, and detailed;
2) how they are covered (in an acausal approach, with a look-up table based on experimental data, etc.).
3) typical keywords which permit to facilitate information retrieval (e.g. “Causal”, “Acausal”, “Bond graph”, “Transfer function”).
- Obligation
-
Recommended
- Can have multiple values
-
Yes
- Value entry examples
-
Note: As this attribute can have multiple values, some of the examples below could apply together to the same model:
-
Sensor model is purely object-list driven
-
Weather effects are not modelled.
-
Typical hydraulic fluid is used, the medium is isotropic
-
Acausal thermal and electrical modelling with through and accross variables
-
The car is represented as a single track model
-
The motor is modeled with a look-up table based on experimental data
-
2.4.2. Model limitations
- Attribute description
-
Restrictions on the use of the model. Especially important if these restrictions are not self-evident to a user (e.g. when the model provides an incorrect result).
- Obligation
-
Recommended
- Can have multiple values
-
Yes
- Value entry examples
-
-
The model is only valid between 0 and 50 degrees temperature
-
Not real-time capable
-
The model provides incorrect results at low speeds
-
Eddy currents are neglected
-
Thermal effects are not considered
-
2.4.3. Model classification
- Attribute description
-
Keyword-based classifications of the model in terms, for example, of physics, engineering or implementation. Can refer to standard or locally standard schemes. It is recommended to refer to a scheme with the reverse domain notation prefix.
- Obligation
-
Recommended
- Can have multiple values
-
Yes
- Value entry examples
-
-
Linear
-
org.modelica.causality.acausal
-
org.iso.is11010-1.vhm.2-1
-
2.4.4. Software and hardware environment requirements
Requirements regarding the software and hardware environment of the model, such as specific tool versions required or hardware required to achieve sufficient perfomance.
- Obligation
-
Recommended
- Can have multiple values
-
Yes
- Value entry examples
-
-
Tool xy Version 4.5 and Compiler V
-
GPU with XY and core 5GB RAM
-
2.5. Verification and validation
The information in the Verification and Validation category takes into account all aspects of model quality assurance, for example whether certain standards have been met or are to be met and what additional measures have been taken and checks have been or should be met.
2.5.1. Verification status
- Attribute description
-
Indicates whether a given verification procedure has been followed to successfully reach verification criteria. Verification permits to confirm that a simulation technically works (code without bug, convergence of discretized models, etc.).
- Obligation
-
Recommended
- Can have multiple values
-
No
- Value entry examples
-
-
has been verified
-
has not be verified
-
- Additional explanation and rationale
-
Incentive to verify the model. As verification can cover various aspects, rely on various techniques and be more or less constraining, details should be provided with the attribute "Verification & Validation procedure and criteria" and "Verification & Validation report".
2.5.2. Validation status
- Attribute description
-
Indicates whether a given validation procedure has been followed to successfully reach validation criteria. Validation permits to confirm that a simulation fulfills user needs. For example, validation permits to confirm that a simulation is close enough to a reference given particular needs.
- Obligation
-
Recommended
- Can have multiple values
-
No
- Value entry examples
-
-
has been validated
-
has not been validated
-
validated with limitations
-
- Additional explanation and rationale
-
Incentive to validate the model. As validation can cover various aspects, rely on various techniques and be more or less constraining, details should be provided with the attribute "Verification & Validation procedure and criteria" and "Verification & Validation report".
2.5.3. Verification & Validation procedure and criteria
- Attribute description
-
Steps and methods followed as well as criteria to reach. Verification and validation can be covered together or separately.
- Obligation
-
Recommended
- Can have multiple values
-
Yes
- Value entry examples
-
-
ASME VV10
-
ASME VV40
-
Scale 2 of he NASA verification scale
-
Turing Test
-
Graphical Comparisons
-
Boundary Analysis
-
2.5.4. Verification & Validation report
- Attribute description
-
Reports describing the results of the verification and validation. Verification and validation can be covered together or separately. Can be summaries, to facilitate communication and distribution. Typically a link to a report.
- Obligation
-
Recommended
- Can have multiple values
-
Yes
- Value entry examples
-
-
link Report XS
-
- Additional explanation and rationale
-
A Inspecting the reports may help deciding wheather the validation and verification fulfill the expectatioons in detail with respect to the intended usage in a certain use case. Hence, it is recommended to provuide the report if, available.
3. Conformance
This specification provides a set of standardized attributes, which other standards that define meta-data and meta-data formats can adopt by claiming conformance. This section sets out what claiming conformance entails.
Any standard that claims conformance with this specification must fulfill the following requirements:
-
It MUST provide a sentence claiming conformance and pointing to the relevant version of this specification, as well as any clarifying information in its standard document.
-
It MUST contain equivalent definitions for all attributes of section [mic-core-attributes] marked as mandatory.
-
It MUST require users of said standard to mandatorily provide values for all attributes of section [mic-core-attributes] marked as mandatory.
-
It MUST contain equivalent definitions for all attributes of section [mic-core-attributes] marked as recommended, unless the application domain of the standard excludes a meaningful use of the attribute.
-
It MUST provide guidance to users of said standard to recommend the provision of values for all attributes of section [mic-core-attributes] marked as recommended that the standard has adopted.
-
It CAN contain equivalent definitions for all attributes of section [mic-core-attributes] marked as optional, when the application domain of the standard makes the attribute potentially meaningful.
-
For any of the attributes specified in section [mic-core-attributes], a standard MUST NOT contain any same-named attribute with a non-equivalent definition.
For the purposes of the requirements set out above, the following terms are used according to these definitions:
- equivalent
-
An attribute definition is deemed to be equivalent when the attribute definition is semantically identical, and matches in name and ordinality.
References
-
[PW13] Preston-Werner, T. (2013): Semantic Versioning 2.0.0. https://semver.org/spec/v2.0.0.html
-
[RFC2119] Bradner, S. (1997): Key words for use in RFCs to Indicate Requirement Levels. IETF RFC 2119. https://www.rfc-editor.org/rfc/rfc2119
-
[MIC] IRT SystemX (2020): Model Identity Card - Toward a standard to characterize simulation models. https://mic.irt-systemx.fr
Appendix A: Mapping of MIC-Core to SSP Traceability SRMD Format
This appendix is an optional part of the MIC-Core specification. It provides an implementation of the MIC-Core standard attributes in the SRMD (Simulation Resource Meta Data) format. It is normative for any mapping to the SRMD format that uses the specified classification type.
A.1. Introduction
In the following, an exemplary implementation of the MIC-Core standard into the SRMD metadata format will be shown. The SRMD (Simulation Resoure Meta Data) metadata format is one of the formats specified in the SSP Traceability specification. These formats form part of the Modelica Association Project SSP (System Structuring and Parametrization) provided format specifications. The SRMD format allows to specify any metadata or other attributes in the form of key value pairs in an XML-based format. The format description also specifies where this metadata file should be stored in an FMU or SSP archive. The SSP Traceability specification is a normative reference for this appendix.
A.2. Maping of MIC-Core attributes to the SRMD format
The type attribute of the Classification element must be specified as org.mic-core.mic-core.
This Classification element must only contain ClassificationEntry elements with keyword attributes from the following table.
It should contain entries for all MIC-Core attributes that are considered mandatory.
The following table shows the mapping of MIC-Core attributes to SRMD classification entries. In the first column the attributes defined in the MIC-Core are listed. The second column lists the conversion of the attribute names to SRMD classification entry keywords. For easier machine processability, clustering via presented terms separated by a period is used here. No spaces are used. In column three an abbreviated explanation of the attributes is listed to provide a better overview. Note that the abbreviated explanations are not considered a normative part of this specification, and should not be considered to suupercede the normative definitions in the MIC-Core specification.
| MIC-Core Name | SRMD Mapping | Short Explanation |
|---|---|---|
Model name |
administrative-data.model.name |
Human-readable way of referring to the model. Usually short and clear. Not necessarily unique |
Model identifier |
administrative-data.model.identifier |
Unique identifier for the model. |
Model description |
administrative-data.model.description |
Human-readable, textual, general overview. Highlights important information about the model. |
Model supplier |
administrative-data.model.supplier |
The responsible body and, if applicable, organizational unit within the body, that is responsible for supplying the model. |
Model confidentiality level |
administrative-data.model.confidentiality-level |
Protection level to apply to the model. |
Legal restriction |
administrative-data.legal-restriction |
Defines the rules governing the distribution and usage of the simulation model, including licensing, |
Release |
administrative-data.release |
Unique identifier, preferably human-readable (i.e. semantically meaningfull), for the release of a particular simulation model. |
Release date |
administrative-data.release.date |
Date, and possibly time and timezone, of the release of a simulation model. Must respect ISO 8601. |
Release type |
administrative-data.release.type |
Relates to the maturity of the model. |
Model purpose |
purpose-objectives.model |
Purpose for which the model has been built/validated. |
Modelled entity |
subject-information.modelled-entity |
Name or description of the object represented by the simulation model. |
Modeling choice |
implementation.modeling-choice |
Explanation of the modeling choices, assumptions or simplifications made during the implementation of the model. |
Model limitations |
implementation.model.limitations |
Restrictions on the use of the model. |
Model classification |
implementation.model.classification |
Keyword-based classifications of the model in terms, for example, of physics, engineering or implementation. |
Software and hardware environment requirements |
implementation.software-hardware-environment-requirements |
Requirements regarding the software and hardware environment of the model. |
Verification status |
verification-validation.verification-status |
Indicates whether a given verification procedure has been followed to successfully reach verification criteria. |
Validation status |
verification-validation.validation-status |
Indicates whether a given validation procedure has been followed to successfully reach validation criteria. |
Verification & Validation procedure and criteria |
verification-validation.procedure-criteria |
Steps and methods followed as well as criteria to reach. Verification and validation can be covered together or separately. |
Verification & Validation report |
verification-validation.report |
Reports describing the results of the verification and validation. |
A.3. XML SRMD-Schema for MIC-Core
As part of the specification an XML Schema is provided that extends the SRMD Schema with embedded Schematron rules and Schematron Quick Fixes to check compliance against this specification.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
xmlns:vc="http://www.w3.org/2007/XMLSchema-versioning" vc:minVersion="1.1"
xmlns:srmd="http://ssp-standard.org/SSPTraceability1/SimulationResourceMetaData"
xmlns:stc="http://ssp-standard.org/SSPTraceability1/SSPTraceabilityCommon"
xmlns:ssc="http://ssp-standard.org/SSP1/SystemStructureCommon"
xmlns:sch="http://purl.oclc.org/dsdl/schematron"
xmlns:sqf="http://www.schematron-quickfix.com/validator/process"
targetNamespace="http://ssp-standard.org/SSPTraceability1/SimulationResourceMetaData">
<xs:include schemaLocation="https://pmsfit.github.io/SSPTraceability/master/SRMD.xsd"/>
<xs:annotation>
<xs:appinfo>
<sch:title>MIC Core Classification Checks</sch:title>
<sch:ns uri="http://ssp-standard.org/SSPTraceability1/SimulationResourceMetaData" prefix="srmd"/>
<sch:ns uri="http://ssp-standard.org/SSPTraceability1/SSPTraceabilityCommon" prefix="stc"/>
<sch:pattern>
<sch:title>MIC Core: Classification Presence</sch:title>
<sch:let name="mic-core-type" value="'org.mic-core.mic-core'"/>
<sch:rule context="/srmd:SimulationResourceMetaData" role="info">
<sch:assert test="count(stc:Classification[@type=$mic-core-type])=1" >
Missing or more than one MIC Core classification.
</sch:assert>
</sch:rule>
</sch:pattern>
<sch:pattern>
<sch:title>MIC Core: Mandatory Attributes</sch:title>
<sch:rule context="/srmd:SimulationResourceMetaData/stc:Classification[@type=$mic-core-type]">
<sch:assert test="stc:ClassificationEntry[@keyword='administrative-data.model.name']" sqf:fix="add-model-name-entry">
Missing mandatory model name attribute.
</sch:assert>
<sqf:fix id="add-model-name-entry">
<sqf:description>
<sqf:title>Add missing classification entry</sqf:title>
</sqf:description>
<sqf:add position="last-child">
<stc:ClassificationEntry keyword="administrative-data.model.name">Model</stc:ClassificationEntry>
</sqf:add>
</sqf:fix>
<sch:assert test="stc:ClassificationEntry[@keyword='administrative-data.model.supplier']" sqf:fix="add-model-supplier-entry">
Missing mandatory model supplier attribute.
</sch:assert>
<sqf:fix id="add-model-supplier-entry">
<sqf:description>
<sqf:title>Add missing classification entry</sqf:title>
</sqf:description>
<sqf:add position="last-child">
<stc:ClassificationEntry keyword="administrative-data.model.supplier">ACME Inc.</stc:ClassificationEntry>
</sqf:add>
</sqf:fix>
<sch:assert test="stc:ClassificationEntry[@keyword='administrative-data.model.confidentiality-level']" sqf:fix="add-model-confidentiality-entry">
Missing mandatory model confidentiality level attribute.
</sch:assert>
<sqf:fix id="add-model-confidentiality-entry">
<sqf:description>
<sqf:title>Add missing classification entry</sqf:title>
</sqf:description>
<sqf:add position="last-child">
<stc:ClassificationEntry keyword="administrative-data.model.confidentiality-level">1: internal</stc:ClassificationEntry>
</sqf:add>
</sqf:fix>
<sch:assert test="stc:ClassificationEntry[@keyword='administrative-data.release']" sqf:fix="add-release-entry">
Missing mandatory release attribute.
</sch:assert>
<sqf:fix id="add-release-entry">
<sqf:description>
<sqf:title>Add missing classification entry</sqf:title>
</sqf:description>
<sqf:add position="last-child">
<stc:ClassificationEntry keyword="administrative-data.release">0.1.0</stc:ClassificationEntry>
</sqf:add>
</sqf:fix>
</sch:rule>
</sch:pattern>
<sch:pattern>
<sch:title>MIC Core: Recommended Attributes</sch:title>
<sch:rule context="/srmd:SimulationResourceMetaData/stc:Classification[@type=$mic-core-type]" role="info">
<sch:assert test="stc:ClassificationEntry[@keyword='administrative-data.model.identifier']" sqf:fix="add-identifier-entry">
Missing recommended model identifier attribute.
</sch:assert>
<sqf:fix id="add-identifier-entry">
<sqf:description>
<sqf:title>Add missing classification entry</sqf:title>
</sqf:description>
<sqf:add position="last-child">
<stc:ClassificationEntry keyword="administrative-data.model.identifier">Value</stc:ClassificationEntry>
</sqf:add>
</sqf:fix>
<sch:assert test="stc:ClassificationEntry[@keyword='administrative-data.model.description']" sqf:fix="add-description-entry">
Missing recommended model description attribute.
</sch:assert>
<sqf:fix id="add-description-entry">
<sqf:description>
<sqf:title>Add missing classification entry</sqf:title>
</sqf:description>
<sqf:add position="last-child">
<stc:ClassificationEntry keyword="administrative-data.model.description">Value</stc:ClassificationEntry>
</sqf:add>
</sqf:fix>
<sch:assert test="stc:ClassificationEntry[@keyword='administrative-data.release.date']" sqf:fix="add-release-date-entry">
Missing recommended release data attribute.
</sch:assert>
<sqf:fix id="add-release-date-entry">
<sqf:description>
<sqf:title>Add missing classification entry</sqf:title>
</sqf:description>
<sqf:add position="last-child">
<stc:ClassificationEntry keyword="administrative-data.release.date">1900-01-01T01:00:00Z</stc:ClassificationEntry>
</sqf:add>
</sqf:fix>
<sch:assert test="stc:ClassificationEntry[@keyword='administrative-data.release.type']" sqf:fix="add-release-type-entry">
Missing recommended release type attribute.
</sch:assert>
<sqf:fix id="add-release-type-entry">
<sqf:description>
<sqf:title>Add missing classification entry</sqf:title>
</sqf:description>
<sqf:add position="last-child">
<stc:ClassificationEntry keyword="administrative-data.release.type">pre-release</stc:ClassificationEntry>
</sqf:add>
</sqf:fix>
<sch:assert test="stc:ClassificationEntry[@keyword='purpose-objectives.model']" sqf:fix="add-purpose-objectives-entry">
Missing recommended model purpose attribute.
</sch:assert>
<sqf:fix id="add-purpose-objectives-entry">
<sqf:description>
<sqf:title>Add missing classification entry</sqf:title>
</sqf:description>
<sqf:add position="last-child">
<stc:ClassificationEntry keyword="purpose-objectives.model">Purpose</stc:ClassificationEntry>
</sqf:add>
</sqf:fix>
<sch:assert test="stc:ClassificationEntry[@keyword='subject-information.modelled-entity']" sqf:fix="add-modelled-entity-entry">
Missing recommended modelled entity attribute.
</sch:assert>
<sqf:fix id="add-modelled-entity-entry">
<sqf:description>
<sqf:title>Add missing classification entry</sqf:title>
</sqf:description>
<sqf:add position="last-child">
<stc:ClassificationEntry keyword="subject-information.modelled-entity">Entity</stc:ClassificationEntry>
</sqf:add>
</sqf:fix>
<sch:assert test="stc:ClassificationEntry[@keyword='implementation.modeling-choice']" sqf:fix="add-modeling-choice-entry">
Missing recommended modeling choice attribute.
</sch:assert>
<sqf:fix id="add-modeling-choice-entry">
<sqf:description>
<sqf:title>Add missing classification entry</sqf:title>
</sqf:description>
<sqf:add position="last-child">
<stc:ClassificationEntry keyword="implementation.modeling-choice">Modeling Choice</stc:ClassificationEntry>
</sqf:add>
</sqf:fix>
<sch:assert test="stc:ClassificationEntry[@keyword='implementation.model.limitations']" sqf:fix="add-model-limitations-entry">
Missing recommended model limitations attribute.
</sch:assert>
<sqf:fix id="add-model-limitations-entry">
<sqf:description>
<sqf:title>Add missing classification entry</sqf:title>
</sqf:description>
<sqf:add position="last-child">
<stc:ClassificationEntry keyword="implementation.model.limitations">Limitation</stc:ClassificationEntry>
</sqf:add>
</sqf:fix>
<sch:assert test="stc:ClassificationEntry[@keyword='implementation.model.classification']" sqf:fix="add-model-classification-entry">
Missing recommended model classification attribute.
</sch:assert>
<sqf:fix id="add-model-classification-entry">
<sqf:description>
<sqf:title>Add missing classification entry</sqf:title>
</sqf:description>
<sqf:add position="last-child">
<stc:ClassificationEntry keyword="implementation.model.classification">Classification</stc:ClassificationEntry>
</sqf:add>
</sqf:fix>
<sch:assert test="stc:ClassificationEntry[@keyword='implementation.software-hardware-environment-requirements']" sqf:fix="add-software-hardware-requirements-entry">
Missing recommended software and hardware environment requirements attribute.
</sch:assert>
<sqf:fix id="add-software-hardware-requirements-entry">
<sqf:description>
<sqf:title>Add missing classification entry</sqf:title>
</sqf:description>
<sqf:add position="last-child">
<stc:ClassificationEntry keyword="implementation.software-hardware-environment-requirements">Requirements</stc:ClassificationEntry>
</sqf:add>
</sqf:fix>
<sch:assert test="stc:ClassificationEntry[@keyword='verification-validation.verification-status']" sqf:fix="add-verification-status-entry">
Missing recommended verification status attribute.
</sch:assert>
<sqf:fix id="add-verification-status-entry">
<sqf:description>
<sqf:title>Add missing classification entry</sqf:title>
</sqf:description>
<sqf:add position="last-child">
<stc:ClassificationEntry keyword="verification-validation.verification-status">Status</stc:ClassificationEntry>
</sqf:add>
</sqf:fix>
<sch:assert test="stc:ClassificationEntry[@keyword='verification-validation.validation-status']" sqf:fix="add-validation-status-entry">
Missing recommended validation status attribute.
</sch:assert>
<sqf:fix id="add-validation-status-entry">
<sqf:description>
<sqf:title>Add missing classification entry</sqf:title>
</sqf:description>
<sqf:add position="last-child">
<stc:ClassificationEntry keyword="verification-validation.validation-status">Status</stc:ClassificationEntry>
</sqf:add>
</sqf:fix>
<sch:assert test="stc:ClassificationEntry[@keyword='verification-validation.procedure-criteria']" sqf:fix="add-procedure-criteria-entry">
Missing recommended verification and validation procedure and criteria attribute.
</sch:assert>
<sqf:fix id="add-procedure-criteria-entry">
<sqf:description>
<sqf:title>Add missing classification entry</sqf:title>
</sqf:description>
<sqf:add position="last-child">
<stc:ClassificationEntry keyword="verification-validation.procedure-criteria">Criteria</stc:ClassificationEntry>
</sqf:add>
</sqf:fix>
<sch:assert test="stc:ClassificationEntry[@keyword='verification-validation.report']" sqf:fix="add-report-entry">
Missing recommended verification and validation report attribute.
</sch:assert>
<sqf:fix id="add-report-entry">
<sqf:description>
<sqf:title>Add missing classification entry</sqf:title>
</sqf:description>
<sqf:add position="last-child">
<stc:ClassificationEntry keyword="verification-validation.report">Report</stc:ClassificationEntry>
</sqf:add>
</sqf:fix>
</sch:rule>
</sch:pattern>
<sch:pattern>
<sch:title>MIC Core: Attribute Rules</sch:title>
<sch:rule abstract="true" id="singleton">
<sch:assert test="count(preceding-sibling::element()[@keyword=current()/@keyword])=0" sqf:fix="fix-delete-entry">
The attribute '<sch:value-of select="@keyword"/>' occurred more than once.
</sch:assert>
<sqf:fix id="fix-delete-entry">
<sqf:description>
<sqf:title>Remove duplicate classification entry</sqf:title>
</sqf:description>
<sqf:delete/>
</sqf:fix>
</sch:rule>
<sch:rule context="/srmd:SimulationResourceMetaData/stc:Classification[@type=$mic-core-type]/stc:ClassificationEntry[@keyword='administrative-data.model.name']">
<sch:extends rule="singleton"/>
</sch:rule>
<sch:rule context="/srmd:SimulationResourceMetaData/stc:Classification[@type=$mic-core-type]/stc:ClassificationEntry[@keyword='administrative-data.model.identifier']">
<sch:extends rule="singleton"/>
</sch:rule>
<sch:rule context="/srmd:SimulationResourceMetaData/stc:Classification[@type=$mic-core-type]/stc:ClassificationEntry[@keyword='administrative-data.model.description']">
<sch:extends rule="singleton"/>
</sch:rule>
<sch:rule context="/srmd:SimulationResourceMetaData/stc:Classification[@type=$mic-core-type]/stc:ClassificationEntry[@keyword='administrative-data.model.supplier']">
<sch:extends rule="singleton"/>
</sch:rule>
<sch:rule context="/srmd:SimulationResourceMetaData/stc:Classification[@type=$mic-core-type]/stc:ClassificationEntry[@keyword='administrative-data.model.confidentiality-level']" role="warn">
<sch:extends rule="singleton"/>
<sch:assert test="matches(.,'^(0: public|1: internal|2: confidential|3: strictly confidential)$')">
Unknown confidentiality level '<sch:value-of select="."/>'.
</sch:assert>
</sch:rule>
<sch:rule context="/srmd:SimulationResourceMetaData/stc:Classification[@type=$mic-core-type]/stc:ClassificationEntry[@keyword='administrative-data.legal-restriction']"/>
<sch:rule context="/srmd:SimulationResourceMetaData/stc:Classification[@type=$mic-core-type]/stc:ClassificationEntry[@keyword='administrative-data.release']">
<sch:extends rule="singleton"/>
</sch:rule>
<sch:rule context="/srmd:SimulationResourceMetaData/stc:Classification[@type=$mic-core-type]/stc:ClassificationEntry[@keyword='administrative-data.release.date']">
<sch:extends rule="singleton"/>
<sch:assert test="matches(.,'^(?:[1-9]\d{3}(-?)(?:(?:0[1-9]|1[0-2])\1(?:0[1-9]|1\d|2[0-8])|(?:0[13-9]|1[0-2])\1(?:29|30)|(?:0[13578]|1[02])(?:\1)31|00[1-9]|0[1-9]\d|[12]\d{2}|3(?:[0-5]\d|6[0-5]))|(?:[1-9]\d(?:0[48]|[2468][048]|[13579][26])|(?:[2468][048]|[13579][26])00)(?:(-?)02(?:\2)29|-?366))(?:T(?:[01]\d|2[0-3])(:?)[0-5]\d(?:\3[0-5]\d)?)?(?:Z|[+-][01]\d(?:\3[0-5]\d)?)?$')">
Invalid ISO8601 release date '<sch:value-of select="."/>'.
</sch:assert>
</sch:rule>
<sch:rule context="/srmd:SimulationResourceMetaData/stc:Classification[@type=$mic-core-type]/stc:ClassificationEntry[@keyword='administrative-data.release.type']">
<sch:extends rule="singleton"/>
</sch:rule>
<sch:rule context="/srmd:SimulationResourceMetaData/stc:Classification[@type=$mic-core-type]/stc:ClassificationEntry[@keyword='purpose-objectives.model']">
<sch:extends rule="singleton"/>
</sch:rule>
<sch:rule context="/srmd:SimulationResourceMetaData/stc:Classification[@type=$mic-core-type]/stc:ClassificationEntry[@keyword='subject-information.modelled-entity']">
<sch:extends rule="singleton"/>
</sch:rule>
<sch:rule context="/srmd:SimulationResourceMetaData/stc:Classification[@type=$mic-core-type]/stc:ClassificationEntry[@keyword='implementation.modeling-choice']"/>
<sch:rule context="/srmd:SimulationResourceMetaData/stc:Classification[@type=$mic-core-type]/stc:ClassificationEntry[@keyword='implementation.model.limitations']"/>
<sch:rule context="/srmd:SimulationResourceMetaData/stc:Classification[@type=$mic-core-type]/stc:ClassificationEntry[@keyword='implementation.model.classification']"/>
<sch:rule context="/srmd:SimulationResourceMetaData/stc:Classification[@type=$mic-core-type]/stc:ClassificationEntry[@keyword='implementation.software-hardware-environment-requirements']"/>
<sch:rule context="/srmd:SimulationResourceMetaData/stc:Classification[@type=$mic-core-type]/stc:ClassificationEntry[@keyword='verification-validation.verification-status']">
<sch:extends rule="singleton"/>
</sch:rule>
<sch:rule context="/srmd:SimulationResourceMetaData/stc:Classification[@type=$mic-core-type]/stc:ClassificationEntry[@keyword='verification-validation.validation-status']">
<sch:extends rule="singleton"/>
</sch:rule>
<sch:rule context="/srmd:SimulationResourceMetaData/stc:Classification[@type=$mic-core-type]/stc:ClassificationEntry[@keyword='verification-validation.procedure-criteria']"/>
<sch:rule context="/srmd:SimulationResourceMetaData/stc:Classification[@type=$mic-core-type]/stc:ClassificationEntry[@keyword='verification-validation.report']"/>
<sch:rule context="/srmd:SimulationResourceMetaData/stc:Classification[@type=$mic-core-type]/stc:ClassificationEntry">
<sch:assert test="false()" sqf:fix="fix-delete-entry">
Unknown MIC Core classification attribute '<sch:value-of select="@keyword"/>'.
</sch:assert>
<sqf:fix id="fix-delete-entry">
<sqf:description>
<sqf:title>Remove unknown classification entry</sqf:title>
</sqf:description>
<sqf:delete/>
</sqf:fix>
</sch:rule>
</sch:pattern>
</xs:appinfo>
</xs:annotation>
</xs:schema>A.4. Example
In the following a small example SRMD file is shown.
<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="../schemas/SRMDMICCore.xsd" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?>
<srmd:SimulationResourceMetaData
version="1.0"
name="Demo"
xmlns:srmd="http://ssp-standard.org/SSPTraceability1/SimulationResourceMetaData"
xmlns:stc="http://ssp-standard.org/SSPTraceability1/SSPTraceabilityCommon"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ssp-standard.org/SSPTraceability1/SimulationResourceMetaData ../schemas/SRMDMICCore.xsd">
<stc:Classification type="org.mic-core.mic-core">
<stc:ClassificationEntry keyword="administrative-data.model.name">MyModel</stc:ClassificationEntry>
<stc:ClassificationEntry keyword="administrative-data.model.identifier">MyModel</stc:ClassificationEntry>
<stc:ClassificationEntry keyword="administrative-data.model.description">Model of something</stc:ClassificationEntry>
<stc:ClassificationEntry keyword="administrative-data.model.supplier">PMSF</stc:ClassificationEntry>
<stc:ClassificationEntry keyword="administrative-data.release">1.0.0</stc:ClassificationEntry>
<stc:ClassificationEntry keyword="administrative-data.release.date">2023-11-11</stc:ClassificationEntry>
<stc:ClassificationEntry keyword="administrative-data.release.type">Final</stc:ClassificationEntry>
<stc:ClassificationEntry keyword="administrative-data.model.confidentiality-level">0: public</stc:ClassificationEntry>
<stc:ClassificationEntry keyword="subject-information.modelled-entity">Entity</stc:ClassificationEntry>
<stc:ClassificationEntry keyword="purpose-objectives.model">Initial </stc:ClassificationEntry>
<stc:ClassificationEntry keyword="implementation.model.classification">Physics</stc:ClassificationEntry>
<stc:ClassificationEntry keyword="implementation.model.limitations">Ignores quantum effects</stc:ClassificationEntry>
<stc:ClassificationEntry keyword="implementation.modeling-choice">Modeling Choice</stc:ClassificationEntry>
<stc:ClassificationEntry keyword="implementation.software-hardware-environment-requirements">Requirements</stc:ClassificationEntry>
<stc:ClassificationEntry keyword="verification-validation.verification-status">Status</stc:ClassificationEntry>
<stc:ClassificationEntry keyword="verification-validation.validation-status">Validated</stc:ClassificationEntry>
<stc:ClassificationEntry keyword="verification-validation.procedure-criteria">Fullfills all requirements and is valid within 5% of real world part over operating range</stc:ClassificationEntry>
<stc:ClassificationEntry keyword="verification-validation.report" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="VerificationReport.pdf">Verification Report</stc:ClassificationEntry>
<stc:ClassificationEntry keyword="verification-validation.report" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="ValidationReport.pdf">Validation Report</stc:ClassificationEntry>
</stc:Classification>
<stc:Classification type="net.pmsf.srmd.demo-classification">
<stc:ClassificationEntry keyword="project-number">12345678-90</stc:ClassificationEntry>
</stc:Classification>
</srmd:SimulationResourceMetaData>It demonstrates how multiple entries of an attribute are handled with the classification entry of type verification-validation.report.
It also shows how different classifications beside the MIC-Core classification can be included in the same file, as intended by the SSP Traceability specification.