diff --git a/schema/ssp/SystemStructureCommon.xsd b/schema/ssp/SystemStructureCommon.xsd
index 1be36a5ec..a8179e90f 100644
--- a/schema/ssp/SystemStructureCommon.xsd
+++ b/schema/ssp/SystemStructureCommon.xsd
@@ -5,11 +5,11 @@
This is the normative XML Schema 1.0 schema for the MAP SSP
- SystemStructure 1.0 common content across formats.
+ SystemStructure 2.0 common content across formats.
- Version: 1.0
+ Version: 2.0
- Copyright 2016 -- 2019 Modelica Association Project "SSP"
+ Copyright 2016 -- 2024 Modelica Association Project "SSP"
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the
@@ -116,6 +116,13 @@
+
+
+
+
+
+
+
@@ -221,7 +228,7 @@
-
+
@@ -248,6 +255,197 @@
+
+
+
+
+
+ This element can specify additional meta data for the given resource. Multiple
+ (or no) MetaData elements may be present.
+
+
+
+
+
+
+
+ This optional element can contain inlined content of the resource meta data. If it
+ is present, then the attribute source of the MetaData element must not be present.
+
+
+
+
+
+
+ This element can contain digital signature information on the meta data referenced
+ by the enclosing MetaData element. It is left unspecified what types of signatures
+ are used and/or available for now. Multiple or no signature elements may be present.
+
+
+
+
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+ 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.
+
+
+
+
+
+
+ This attribute indicates the source of the resource meta data as a
+ URI (cf. RFC 3986). The base URI for the resolution of relative URIs
+ is determined by the sourceBase attribute.
+
+ If the source attribute is missing, the meta data is provided inline
+ as contents of a Content element, which must not be present otherwise.
+
+
+
+
+
+
+ Defines the base the source URI is resolved against: If the attribute
+ is missing or is specified as file, the source is resolved against the
+ URI of the containing file. If the containing model element has a
+ source attribute, the sourceBase attribute can be specified as resource.
+ In this case the URI is resolved against the (resolved) source URI of
+ the containing model element.
+
+ The last option allows the specification of meta data sources that
+ reside inside a resource (for example an FMU) through relative URIs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This element can contain digital signature information on the data referenced
+ by the enclosing element. It is left unspecified what types of signatures
+ are used and/or available for now. Multiple or no signature elements may be present.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 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 later case, the digital
+ signature format should include detailed information about what suitability
+ claims are being made.
+
+
+
+
+
+
+
+
+
+
+
+
+ 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.
+
+
+
+
+
+
+ This attribute indicates the source of the digital signature as a
+ URI (cf. RFC 3986). The base URI for the resolution of relative URIs
+ is determined by the sourceBase attribute.
+
+ If the source attribute is missing, the signature must be provided
+ inline as contents of a Content element, which must not be present
+ otherwise.
+
+
+
+
+
+
+ Defines the base the source URI is resolved against: If the attribute
+ is missing or is specified as file, the source is resolved against the
+ URI of the containing file. If the containing model element has a
+ source attribute, the sourceBase attribute can be specified as resource.
+ In this case the URI is resolved against the (resolved) source URI of
+ the containing model element. If the Signature element is contained
+ within a MetaData element, the sourceBase attribute can be specified as
+ metaData. In this case the URI is resolved against the (resolved) URI
+ of the meta data source.
+
+ The last two options allow the specification of signature sources that
+ reside inside a resource (for example an FMU), or the meta data
+ through relative URIs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This optional element can contain inlined content of an entity. If it is present,
+ then the attribute source of the enclosing element must not be present.
+
+
+
+
+
+
+
+
@@ -276,10 +474,82 @@
+
+
+
+
+
+ This attribute gives the unit of the entity and must
+ reference one of the unit definitions provided in the Units
+ element of the containing file.
+
+ If a unit is not supplied, the unit is determined through
+ default mechanisms: For FMU components, the unit of the
+ underlying variable would be used, for systems the units
+ of connected underlying connectors could be used if unambiguous.
+ If a unit cannot be deduced unambinguously, the user should
+ be informed of this error.
+
+
+
+
+
+
+
+
+
+
+ This attribute gives the unit of the entity and must
+ reference one of the unit definitions provided in the Units
+ element of the containing file.
+
+ If a unit is not supplied, the unit is determined through
+ default mechanisms: For FMU components, the unit of the
+ underlying variable would be used, for systems the units
+ of connected underlying connectors could be used if unambiguous.
+ If a unit cannot be deduced unambinguously, the user should
+ be informed of this error.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -321,6 +591,29 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -408,8 +701,8 @@
This element provides for a transformation of integer parameter values
- based on a mapping table and is valid for parameters of integer and
- enumeration type. Each mapping table entry is provided by a MapEntry
+ based on a mapping table and is valid for parameters of all integer and
+ enumeration types. Each mapping table entry is provided by a MapEntry
element.
@@ -417,7 +710,7 @@
-
+
This attribute gives the value of the parameter in the
@@ -425,7 +718,7 @@
-
+
This attribute gives the value of the parameter to use
@@ -477,4 +770,48 @@
+
+
+
+
+
+ This optional element specifies one dimension of an array connector.
+ If no dimension elements are present in a connector, it is a scalar
+ connector. The number of dimension elements in a connector provides
+ the dimensionality of the array.
+
+ Either the size or the sizeConnector attributes CAN be present
+ on the element, indicating a fixed size, or a size that depends on
+ the structural parameter or constant referenced by the sizeConnector
+ attribute.
+
+ If none of the attributes are present, then the size of the dimension
+ is unspecified at the SSD level. If both attributes are present this
+ is considered an error.
+
+
+
+
+
+
+ This attribute gives the size of this dimension of the
+ connector as a fixed, unchangeable number.
+
+
+
+
+
+
+ This attribute references another connector by name, that
+ gives the size of this dimension of the connector, e.g. a
+ structural parameter or a constant of the underlying
+ component that gives the dimension size.
+
+
+
+
+
+
+
+
diff --git a/schema/ssp/SystemStructureDescription.xsd b/schema/ssp/SystemStructureDescription.xsd
index 51faa1b49..72fcbcfc8 100644
--- a/schema/ssp/SystemStructureDescription.xsd
+++ b/schema/ssp/SystemStructureDescription.xsd
@@ -2,16 +2,15 @@
+ targetNamespace="http://ssp-standard.org/SSP1/SystemStructureDescription">
This is the normative XML Schema 1.0 schema for the MAP SSP
- SystemStructureDescription 1.0 format.
+ SystemStructureDescription 2.0 format.
+
+ Version: 2.0
- Version: 1.0
-
- Copyright 2016 -- 2019 Modelica Association Project "SSP"
+ Copyright 2016 -- 2024 Modelica Association Project "SSP"
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the
@@ -42,9 +41,9 @@
POSSIBILITY OF SUCH DAMAGE.
-
+
-
+
@@ -52,17 +51,20 @@
+
+
- Version of SSD format, 1.0 for this release.
+ Version of SSD format, 1.0 or 2.0 for this release.
-
+
+
@@ -79,7 +81,7 @@
-
+
@@ -92,11 +94,11 @@
The set of connectors of this element, which represent
the interface of the element to the outside world.
-
+
For components the set of connectors must match variable/ports
of the underlying component implementation, e.g. the referenced
FMU, by name.
-
+
Note that there is no requirement that connectors must
be present for all variables/ports of an underlying
component implementation. Only those connectors must
@@ -115,7 +117,7 @@
The optional attribute rotation (in degrees) defines an additional rotation
(applied after flipping), where positive numbers indicate left rotation (x->y).
The coordinate system is oriented: x -> right, y -> up.
-
+
The optional attribute iconSource defines an icon URI with the same semantics as
for the source attribute of the Component element. If defined, this icon overrides
any icon that may be defined e.g. in an .fmu file (as disccused in the FMI group).
@@ -145,6 +147,8 @@
+
+
@@ -162,7 +166,7 @@
-
+
@@ -180,36 +184,36 @@
-
+
- This attribute indicates the source of the component as an URI
- (cf. RFC 3986). For purposes of the resolution of relative URIs
+ Optional attribute indicating the source of the component as a URI
+ (cf. RFC 3986). For purposes of the resolution of relative URIs
the base URI is the URI of the SSD. Therefore for components
that are located alongside the SSD, relative URIs without scheme
and authority can and should be used to specify the component
sources. For components that are packaged inside an SSP that
contains this SSD, this is mandatory (in this way, the SSD URIs
remain valid after unpacking the SSP into the filesystem).
-
+
E.g. for an FMU called MyDemoFMU.fmu, that is located in the
resources directory of an SSP, the correct URI would be
"resources/MyDemoFMU.fmu".
-
+
When referencing another SSP, by default the default SSD of the
SSP (i.e. SystemStructure.ssd) is referenced. When a non-default
- SSD should be selected, then the name of the non-default SSD must
- be given through a fragment identifier, i.e. the URI
+ SSD should be selected, then the name of the non-default SSD must
+ be given through a fragment identifier, i.e. the URI
"resources/SubSSP.ssp#VariantB.ssd" would reference the VariantB.ssd
of SubSSP.ssp located in the resources directory relative to this SSD.
-
+
When the URI is a same-document URI with a fragment identifier, e.g.
"#other-system", then the fragment identifier should identify a
system element in this SSD document with an id attribute identical
to the fragment identifier. This mechanism can be used to instantiate
an embedded system definition multiple times through reference to
its definition element.
-
+
Note that implementations are only required to support relative URIs
as specified above, and that especially relative URIs that move beyond
the baseURI (e.g. go "up" a level via ..) are not required to be
@@ -217,6 +221,19 @@
security or other reasons. Implementations are also not required to
support any absolute URIs and any specific URI schemes (but are of
course allowed to support any and all kinds of URIs where useful).
+
+ If the source attribute is missing, this indicates that there is no
+ provided source for the component, indicating a simulation
+ architecture design without complete executable implementation.
+ Implementations *CAN* take any specified type attribute into account
+ when handling such components. In any other regard implementations
+ *CAN* treat such components as equivalent to an empty system with the
+ same connectors and other properties as specified for the component.
+
+ Note that not specifying a source attribute is not the same as
+ specifying a source attribute with an emtpy string value, as that
+ is considered a valid relative URI. Implementations *MUST NOT*
+ specify an empty relative URI to indicate a missing implementation.
@@ -228,9 +245,10 @@
attribute can be used to determine which FMU implementation should be
employed. If the attribute is missing or uses the default value "any",
the importing tool is free to choose what kind of FMU implementation
- to use. If the value is "CoSimulation" or "ModelExchange" the corresponding
- FMU implementation must be used. It is an error if the specified type
- of FMU implementation is not present in the FMU.
+ to use. If the value is "CoSimulation", "ModelExchange", or
+ "ScheduledExecution", the corresponding FMU implementation must be used.
+ It is an error if the specified type of FMU implementation is not present
+ in the FMU.
@@ -238,6 +256,7 @@
+
@@ -252,35 +271,52 @@
This element defines a signal dictionary, describing the signal dictionary
entries present in the signal dictionary.
-
+
The contents of the element can be used to provide a signal dictionary
inline, in which case the source attribute of the SignalDictionary element
must be empty.
-
+
The contents must be an ssb:SignalDictionary element, if the type attribute
- of this element is application/x-ssp-signal-dictionary, or any other valid
+ of this element is application/x-ssp-signal-dictionary, or any other valid
XML content if the type attribute references another MIME type (in that case
there should be a layered specification that defines how embedding the content
works for that MIME type).
-
-
+
+
+
-
-
+
@@ -289,13 +325,13 @@
This attribute indicates the source of the signal dictionary as a URI
(cf. RFC 3986). For purposes of the resolution of relative URIs
the base URI is the URI of the SSD.
-
+
If the source attribute is missing, the signal dictionary is provided
inline as contents of the SignalDictionary element, which must be
empty otherwise.
-
+
For the default type application/x-ssp-signal-dictionary such inline
- content must be an ssb:SignalDictionary element.
+ content must be an ssb:SignalDictionary element.
@@ -318,7 +354,7 @@
-
+
@@ -329,7 +365,7 @@
This attribute gives the name of the signal dictionary that is to
- be referenced. Name lookups occur in hierarchical fashion, i.e.
+ be referenced. Name lookups occur in hierarchical fashion, i.e.
the name is first looked up in the system that contains a signal
dictionary reference. If that lookup yields no match, the lookup
is performed on the enclosing system, etc., until a match is found.
@@ -340,7 +376,7 @@
-
+
@@ -374,14 +410,14 @@
Note that connections between connectors on a system are
allowed, so neither startElement nor endElement has to be
supplied.
-
+
Note also that the terms start and end in the attribute names
of the connector, like startElement or endConnector, do not
denote directionality of the data flow implied by the connector.
That is determined by the combination of the semantics of the
actual connectors (variables/ports) connected and their kind
attributes:
-
+
For component to component connections as well as for connections
between two connectors at the system level, currently the kind of
one connector must be output and of another connector must be
@@ -389,7 +425,7 @@
must be calculatedParameter and the other must be parameter.
Information flows from the output/calculatedParameter to the
input/parameter connector.
-
+
For system to component connections the kinds of the connectors
must match, i.e. either both are input or both output or both
parameter or both calculatedParameter.
@@ -413,10 +449,10 @@
through the coordinates of the corresponding connectors. The only relevant
geometry information provided by the connection geometry is a, by default
empty, list of intermediate waypoint coordinates, which are to be interpreted
- as for the svg:polyline primitive, i.e. as waypoints for straight line
+ as for the svg:polyline primitive, i.e. as waypoints for straight line
segments, with the first and last points added automatically based on the
translated coordinates of the start and end connectors.
-
+
Note that x and y coordinates are in the coordinate system of the
enclosing system.
@@ -458,6 +494,19 @@
+
+
+
+ This optional attribute gives the list of indices of an
+ array connector that this connection is restricted to.
+ If not supplied this indicates that this connection
+ applies to the whole connector, not just a single element.
+
+
+
+
+
+
@@ -479,6 +528,19 @@
+
+
+
+ This optional attribute gives the list of indices of an
+ array connector that this connection is restricted to.
+ If not supplied this indicates that this connection
+ applies to the whole connector, not just a single element.
+
+
+
+
+
+
@@ -487,7 +549,7 @@
available for both start and end definitions. If this attribute is
supplied and its value is true, then the environment will not perform
any automatic unit conversions, otherwise automatic unit
- conversions can be performed. This is also useful in conjunction with
+ conversions can be performed. This is also useful in conjunction with
the optional linear transformation supplied via the LinearTransformation
element: With suppressUnitConversion = true, the linear transformation
is performed instead of any unit conversions, whereas otherwise the
@@ -504,22 +566,22 @@
- This optional element defines the extent of the system canvas.
- (x1,y1) and (x2,y2) define the lower-left and upper-right
+ This optional element defines the extent of the system canvas.
+ (x1,y1) and (x2,y2) define the lower-left and upper-right
corner, respectively.
Different from ElementGeometry, where x1>x2 and y1>y2 indicate
flipping, x1 < x2 and y1 < y2 must hold here.
-
+
If undefined, the system canvas extent defaults to the bounding
box of all ElementGeometry elements of the child elements of the
system.
-
+
When displaying the content of a sub-system together with the
enclosing parent system, the transformation of co-coordinates
inside the sub-system to co-ordinates in the parent system is defined
- by the transformation from SystemGeometry.{x1,y1,x2,y2} to
- ElementGeometry.{x1', y1', x2', y2'}, where ElementGeometry.z'
+ by the transformation from SystemGeometry.{x1,y1,x2,y2} to
+ ElementGeometry.{x1', y1', x2', y2'}, where ElementGeometry.z'
is the respective coordinate of the sub-system when instantiated
in the parent system after rotation.
@@ -538,7 +600,7 @@
that are contained in the system, e.g. things like notes, which have no
semantic impact on the system but aid in presentation of the system in
graphical user interfaces.
-
+
Currently the only graphical element defined is the Note element, which
allows for simple textual notes to be placed into the system diagram, but
in the future more elements might be added as needed for exchange of
@@ -555,7 +617,7 @@
enclosing system. It is sized using the attributes so that the coordinates
(x1,y1) and (x2,y2) define the positions of the lower-left and upper-right
corners of the note in the coordinate system of the parent.
-
+
The note text is given by the text attribute. The presentation expectation
is that the text is automatically sized ad wrapped in such a way that it
fits the note area. If this would lead to too small text, it might be
@@ -591,7 +653,7 @@
This element gives the type of the connector.
-
+
If a type is not supplied, the type is determined through
default mechanisms: For FMU components, the type of the
underlying variable would be used, for systems the types
@@ -603,38 +665,70 @@
+
+
+
+ This optional sequence of elements specifies the dimensions of an
+ array connector. If no dimension elements are present in a
+ connector, it is a scalar connector. The number of dimension
+ elements in a connector providesthe dimensionality of the array.
+
+
+
+
+
+
+ This element associates the connector to a clock of the
+ given name, which must be defined on the given element.
+
+
+
+
+
+
This optional element gives the geometry information of the connector.
- Note that x and y coordinates are in a special coordinate system, where
- 0,0 is the lower-left corner of the component/system, and 1,1 is the
- upper-right corner of the component, regardless of aspect ratio.
-
- For systems the placement of connectors for the inside and outside
- view of the system is identical, the special coordinate system is just
+ Note that x and y coordinates are in a normalized connector coordinate
+ system, where 0,0 is the lower-left corner of the component/system,
+ and 1,1 is the upper-right corner of the component, regardless of
+ aspect ratio.
+
+ By default, the placement of connectors for a system's inside and
+ outside views is identical. The connector coordinate system is just
translated to different actual coordinate systems, namely the one
- determined by the ElementGeometry for the outside view, and the
- one determined by SystemGeometry for the inside view.
+ determined by ElementGeometry for the outside view and the one
+ determined by SystemGeometry for the inside view.
+
+ For systems, optionally, different placement of connectors for the
+ inside view of the system can be specified with the systemInnerX
+ and systemInnerY coordinates. This enables preserving the inside
+ system layout when integrating a system in a system structure and
+ avoiding unintended changes to the position of the connectors on
+ the inside view of the system when making layout changes on the
+ outside view and vice versa.
+
+
-
+
This attribute gives the connector a name, which
shall be unique within the component or system and,
- for components, must match the name of a relevant
+ for components, must match the name of a relevant
variable/port in the underlying component implementation,
e.g. the referenced FMU.
-
+
Note that there is no requirement that connectors must
be present for all variables/ports of an underlying
component implementation. Only those connectors must
@@ -646,31 +740,48 @@
- This attribute specifies the kind of the given connector,
- which indicates whether the connector is an input, an
- output, both (inout), a parameter or a calculated parameter (i.e.
- a parameter that is calculated by the component during initialization).
+ This attribute specifies the kind of the given connector, which
+ indicates whether the connector is an input, an output, both
+ (inout), unspecified, a local variable, a constant, a parameter,
+ a calculated parameter (i.e. a parameter that is calculated by the
+ component during initialization), or a structural parameter (i.e.
+ a parameter that can be set during (re-)configuration mode).
+
For components this must match the related kind of the underlying
- component implementation, e.g. for referenced FMUs it must match the
- combination of variability and causality.
-
- For FMI 2.0 this means that the causality of the variable must
- match the kind of the connector.
-
+ component implementation. For referenced FMUs it must match the
+ combination of variability and causality:
+
+ For FMI 2.0 and 3.0 this means that the causality of the variable
+ must match the kind of the connector (with the kind inout not being
+ valid for either FMI 3.0, 2.0, or 1.0).
+
For FMI 1.0 this means that for connectors of kind input or output
the causality of the variable must be input or output and the
variability of the variable must be discrete or continuous (for
outputs also constant and parameter are allowable). For connectors
- of kind parameter the causality must be input or internal and the
- variablity must be parameter. For connectors of kind
- calculatedParameter the causality must be output and the variablity
- must be parameter.
+ of kind parameter the causality of the FMI 1.0 variable must be
+ input or internal and the variability must be parameter. For
+ connectors of kind calculatedParameter the causality of the FMI 1.0
+ variable must be output and the variability must be parameter. For
+ connectors of kind constant the causality of the FMI 1.0 variable
+ must be output and the variability must be constant.
+ Connectors of kind `local` are used to define variables of the
+ model element. Such a variable is not intended to be used for
+ connections. However, if it is connected, the semantics are same as
+ for an `output`.
+
For SignalDictionaryReferences, the kind of a given connector can
additionally be 'inout', which indicates that the semantics of the
connector are derived from the connections going to the connector.
This can be used for example to allow a connector to function as
- both an input and output within the same SignaleDictionaryReference.
+ both an input and output within the same SignalDictionaryReference.
+
+ Connectors of kind `unspecified` are used to define connectors for
+ which the flow of information is either not yet specified, or is
+ determined at runtime, for example for acausal connections of
+ Modelica models. Such connectors can be connected to any other
+ connector under the rules of the underlying modeling language.
@@ -679,7 +790,11 @@
+
+
+
+
@@ -699,11 +814,11 @@
provided in the parameter source must match the names of the FMU variables, or must be
mapped to the names of the FMU variables through a ParameterMapping element, or are
ignored if no matching variable is found.
-
+
For systems the names in the parameter source must either match the hierarchical names
of parameters or other variables in the system, or must be mapped to those names through
a ParameterMapping element, or are ignored if no matching variable is found.
-
+
The hierarchical names of the parameters or other variables of a system are formed in the
following way: Any variables of the system exposed through connectors of the system have
the name of the connector as their name. For all elements of the system, the hierarchical
@@ -713,14 +828,14 @@
a parameter P2, the hierarchical names of the parameters in system A are B.SP1 and B.C.P2
respectively. The hierarchical name of those parameters inside system B are SP1 and C.P2
respectively.
-
+
More than one ParameterBinding can be supplied, in which case all of the parameters found
will be used to parametrize the component, with parameter values in ParameterBinding
sources appearing at a succeeding position in the element order taking priority over prior
- sources at the same hierarchy level, should a parameter be included in more than one
+ sources at the same hierarchy level, should a parameter be included in more than one
ParameterBinding source.
-
- When ParameterBinding sources on multiple levels of the hierarchy supply values for the
+
+ When ParameterBinding sources on multiple levels of the hierarchy supply values for the
same parameter, bindings at a higher hierarchy level take precedence over lower levels,
i.e. bindings at a system level take precedence over bindings at a sub-system or component
level.
@@ -752,7 +867,7 @@
This optional element can be used to provide parameter values inline
to the parameter binding, in which case the source attribute of the
ParameterBinding element must be empty.
-
+
The contents must be an ssv:ParameterSet element, if the type attribute
of the ParameterBinding element is application/x-ssp-parameter-set, or
any other valid XML content if the type attribute references another
@@ -763,9 +878,9 @@
+
+
+
-
-
+
This attribute indicates the source of the parameter mapping as a URI
- (cf. RFC 3986). For purposes of the resolution of relative URIs
- the base URI is the URI of the SSD, if the sourcebase attribute
- is not specified or is specified as SSD, and the URI of the
- referenced component if the base attribute is specified as component.
- This allows the specification of parameter mapping sources that reside
- inside the component (e.g. an FMU) through relative URIs.
-
+ (cf. RFC 3986). The base URI for the resolution of relative URIs is
+ determined by the sourceBase attribute.
+
If the source attribute is missing, the parameter mapping is provided
inline as contents of the ParameterMapping element, which must be
empty otherwise.
@@ -842,8 +970,10 @@
Defines the base the source URI is resolved against: If the attribute
is missing or is specified as SSD, the source is resolved against the
- URI of the SSD, if the attribute is specified as component the URI is
- resolved against the (resolved) URI of the component source.
+ URI of the containing file. If the attribute is specified as component
+ the URI is resolved against the (resolved) source URI of the component.
+ The last option allows the specification of parameter sources that
+ reside inside a resource (for example an FMU) through relative URIs.
@@ -855,6 +985,8 @@
+
+
@@ -872,16 +1004,9 @@
This attribute indicates the source of the parameters as a URI
- (cf. RFC 3986). For purposes of the resolution of relative URIs
- the base URI is the URI of the SSD, if the sourcebase attribute
- is not specified or is specified as SSD, and the URI of the
- referenced component if the base attribute is specified as component.
- This allows the specification of parameter sources that reside inside
- the component (e.g. an FMU) through relative URIs.
-
- Access to parameter sets over the SSP Parameter Repository Protocol
- is mediated through URIs with the http or https scheme.
-
+ (cf. RFC 3986). The base URI for the resolution of relative URIs is
+ determined by the sourceBase attribute.
+
If the source attribute is missing, the parameter mapping is provided
inline as contents of a ParameterValues element, which must not be
present otherwise.
@@ -893,8 +1018,11 @@
Defines the base the source URI is resolved against: If the attribute
is missing or is specified as SSD, the source is resolved against the
- URI of the SSD, if the attribute is specified as component the URI is
- resolved against the (resolved) URI of the component source.
+ URI of the containing file. If the attribute is specified as component
+ the URI is resolved against the (resolved) source URI of the component.
+ The last option allows the specification of parameter mapping sources
+ that reside inside a resource (for example an FMU) through relative
+ URIs.
@@ -924,7 +1052,7 @@
-
+
@@ -944,7 +1072,7 @@
Default stop time of simulation
-
+
diff --git a/schema/ssp/SystemStructureDescription11.xsd b/schema/ssp/SystemStructureDescription11.xsd
index d74ce636f..8c2d93ea2 100644
--- a/schema/ssp/SystemStructureDescription11.xsd
+++ b/schema/ssp/SystemStructureDescription11.xsd
@@ -10,13 +10,13 @@
This is the XML Schema 1.1 schema for the MAP SSP
- SystemStructureDescription 1.0 format. It is provided
+ SystemStructureDescription 2.0 format. It is provided
as a non-normative alternative to the XML Schema 1.0 schema
to support simpler cross-namespace validation of SSD files.
- Version: 1.0
+ Version: 2.0
- Copyright 2016 -- 2019 Modelica Association Project "SSP"
+ Copyright 2016 -- 2024 Modelica Association Project "SSP"
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the
@@ -60,17 +60,20 @@
+
+
- Version of SSD format, 1.0 for this release.
+ Version of SSD format, 1.0 or 2.0 for this release.
-
+
+
@@ -153,6 +156,8 @@
+
+
@@ -188,11 +193,11 @@
-
+
- This attribute indicates the source of the component as an URI
- (cf. RFC 3986). For purposes of the resolution of relative URIs
+ Optional attribute indicating the source of the component as a URI
+ (cf. RFC 3986). For purposes of the resolution of relative URIs
the base URI is the URI of the SSD. Therefore for components
that are located alongside the SSD, relative URIs without scheme
and authority can and should be used to specify the component
@@ -225,6 +230,19 @@
security or other reasons. Implementations are also not required to
support any absolute URIs and any specific URI schemes (but are of
course allowed to support any and all kinds of URIs where useful).
+
+ If the source attribute is missing, this indicates that there is no
+ provided source for the component, indicating a simulation
+ architecture design without complete executable implementation.
+ Implementations *CAN* take any specified type attribute into account
+ when handling such components. In any other regard implementations
+ *CAN* treat such components as equivalent to an empty system with the
+ same connectors and other properties as specified for the component.
+
+ Note that not specifying a source attribute is not the same as
+ specifying a source attribute with an emtpy string value, as that
+ is considered a valid relative URI. Implementations *MUST NOT*
+ specify an empty relative URI to indicate a missing implementation.
@@ -236,9 +254,10 @@
attribute can be used to determine which FMU implementation should be
employed. If the attribute is missing or uses the default value "any",
the importing tool is free to choose what kind of FMU implementation
- to use. If the value is "CoSimulation" or "ModelExchange" the corresponding
- FMU implementation must be used. It is an error if the specified type
- of FMU implementation is not present in the FMU.
+ to use. If the value is "CoSimulation", "ModelExchange", or
+ "ScheduledExecution", the corresponding FMU implementation must be used.
+ It is an error if the specified type of FMU implementation is not present
+ in the FMU.
@@ -246,6 +265,7 @@
+
@@ -273,10 +293,14 @@
-
-
-
-
+
+
+
+
+
+
+
+
@@ -454,6 +478,19 @@
+
+
+
+ This optional attribute gives the list of indices of an
+ array connector that this connection is restricted to.
+ If not supplied this indicates that this connection
+ applies to the whole connector, not just a single element.
+
+
+
+
+
+
@@ -475,6 +512,19 @@
+
+
+
+ This optional attribute gives the list of indices of an
+ array connector that this connection is restricted to.
+ If not supplied this indicates that this connection
+ applies to the whole connector, not just a single element.
+
+
+
+
+
+
@@ -599,30 +649,62 @@
+
+
+
+ This optional sequence of elements specifies the dimensions of an
+ array connector. If no dimension elements are present in a
+ connector, it is a scalar connector. The number of dimension
+ elements in a connector providesthe dimensionality of the array.
+
+
+
+
+
+
+ This element associates the connector to a clock of the
+ given name, which must be defined on the given element.
+
+
+
+
+
+
This optional element gives the geometry information of the connector.
- Note that x and y coordinates are in a special coordinate system, where
- 0,0 is the lower-left corner of the component/system, and 1,1 is the
- upper-right corner of the component, regardless of aspect ratio.
+ Note that x and y coordinates are in a normalized connector coordinate
+ system, where 0,0 is the lower-left corner of the component/system,
+ and 1,1 is the upper-right corner of the component, regardless of
+ aspect ratio.
- For systems the placement of connectors for the inside and outside
- view of the system is identical, the special coordinate system is just
+ By default, the placement of connectors for a system's inside and
+ outside views is identical. The connector coordinate system is just
translated to different actual coordinate systems, namely the one
- determined by the ElementGeometry for the outside view, and the
- one determined by SystemGeometry for the inside view.
+ determined by ElementGeometry for the outside view and the one
+ determined by SystemGeometry for the inside view.
+
+ For systems, optionally, different placement of connectors for the
+ inside view of the system can be specified with the systemInnerX
+ and systemInnerY coordinates. This enables preserving the inside
+ system layout when integrating a system in a system structure and
+ avoiding unintended changes to the position of the connectors on
+ the inside view of the system when making layout changes on the
+ outside view and vice versa.
+
+
-
+
This attribute gives the connector a name, which
@@ -642,31 +724,48 @@
- This attribute specifies the kind of the given connector,
- which indicates whether the connector is an input, an
- output, both (inout), a parameter or a calculated parameter (i.e.
- a parameter that is calculated by the component during initialization).
+ This attribute specifies the kind of the given connector, which
+ indicates whether the connector is an input, an output, both
+ (inout), unspecified, a local variable, a constant, a parameter,
+ a calculated parameter (i.e. a parameter that is calculated by the
+ component during initialization), or a structural parameter (i.e.
+ a parameter that can be set during (re-)configuration mode).
+
For components this must match the related kind of the underlying
- component implementation, e.g. for referenced FMUs it must match the
- combination of variability and causality.
+ component implementation. For referenced FMUs it must match the
+ combination of variability and causality:
- For FMI 2.0 this means that the causality of the variable must
- match the kind of the connector.
+ For FMI 2.0 and 3.0 this means that the causality of the variable
+ must match the kind of the connector (with the kind inout not being
+ valid for either FMI 3.0, 2.0, or 1.0).
For FMI 1.0 this means that for connectors of kind input or output
the causality of the variable must be input or output and the
variability of the variable must be discrete or continuous (for
outputs also constant and parameter are allowable). For connectors
- of kind parameter the causality must be input or internal and the
- variablity must be parameter. For connectors of kind
- calculatedParameter the causality must be output and the variablity
- must be parameter.
+ of kind parameter the causality of the FMI 1.0 variable must be
+ input or internal and the variability must be parameter. For
+ connectors of kind calculatedParameter the causality of the FMI 1.0
+ variable must be output and the variability must be parameter. For
+ connectors of kind constant the causality of the FMI 1.0 variable
+ must be output and the variability must be constant.
+
+ Connectors of kind `local` are used to define variables of the
+ model element. Such a variable is not intended to be used for
+ connections. However, if it is connected, the semantics are same as
+ for an `output`.
For SignalDictionaryReferences, the kind of a given connector can
additionally be 'inout', which indicates that the semantics of the
connector are derived from the connections going to the connector.
This can be used for example to allow a connector to function as
- both an input and output within the same SignaleDictionaryReference.
+ both an input and output within the same SignalDictionaryReference.
+
+ Connectors of kind `unspecified` are used to define connectors for
+ which the flow of information is either not yet specified, or is
+ determined at runtime, for example for acausal connections of
+ Modelica models. Such connectors can be connected to any other
+ connector under the rules of the underlying modeling language.
@@ -675,7 +774,11 @@
+
+
+
+
@@ -786,22 +889,22 @@
-
-
-
-
+
+
+
+
+
+
+
+
This attribute indicates the source of the parameter mapping as a URI
- (cf. RFC 3986). For purposes of the resolution of relative URIs
- the base URI is the URI of the SSD, if the sourcebase attribute
- is not specified or is specified as SSD, and the URI of the
- referenced component if the base attribute is specified as component.
- This allows the specification of parameter mapping sources that reside
- inside the component (e.g. an FMU) through relative URIs.
+ (cf. RFC 3986). The base URI for the resolution of relative URIs is
+ determined by the sourceBase attribute.
If the source attribute is missing, the parameter mapping is provided
inline as contents of the ParameterMapping element, which must be
@@ -814,8 +917,10 @@
Defines the base the source URI is resolved against: If the attribute
is missing or is specified as SSD, the source is resolved against the
- URI of the SSD, if the attribute is specified as component the URI is
- resolved against the (resolved) URI of the component source.
+ URI of the containing file. If the attribute is specified as component
+ the URI is resolved against the (resolved) source URI of the component.
+ The last option allows the specification of parameter sources that
+ reside inside a resource (for example an FMU) through relative URIs.
@@ -827,6 +932,8 @@
+
+
@@ -844,15 +951,8 @@
This attribute indicates the source of the parameters as a URI
- (cf. RFC 3986). For purposes of the resolution of relative URIs
- the base URI is the URI of the SSD, if the sourcebase attribute
- is not specified or is specified as SSD, and the URI of the
- referenced component if the base attribute is specified as component.
- This allows the specification of parameter sources that reside inside
- the component (e.g. an FMU) through relative URIs.
-
- Access to parameter sets over the SSP Parameter Repository Protocol
- is mediated through URIs with the http or https scheme.
+ (cf. RFC 3986). The base URI for the resolution of relative URIs is
+ determined by the sourceBase attribute.
If the source attribute is missing, the parameter mapping is provided
inline as contents of a ParameterValues element, which must not be
@@ -865,8 +965,11 @@
Defines the base the source URI is resolved against: If the attribute
is missing or is specified as SSD, the source is resolved against the
- URI of the SSD, if the attribute is specified as component the URI is
- resolved against the (resolved) URI of the component source.
+ URI of the containing file. If the attribute is specified as component
+ the URI is resolved against the (resolved) source URI of the component.
+ The last option allows the specification of parameter mapping sources
+ that reside inside a resource (for example an FMU) through relative
+ URIs.
diff --git a/schema/ssp/SystemStructureParameterMapping.xsd b/schema/ssp/SystemStructureParameterMapping.xsd
index f2c3447de..9992e374a 100644
--- a/schema/ssp/SystemStructureParameterMapping.xsd
+++ b/schema/ssp/SystemStructureParameterMapping.xsd
@@ -6,11 +6,11 @@
This is the normative XML Schema 1.0 schema for the MAP SSP
- SystemStructureParameterMapping 1.0 format.
+ SystemStructureParameterMapping 2.0 format.
- Version: 1.0
+ Version: 2.0
- Copyright 2016 -- 2019 Modelica Association Project "SSP"
+ Copyright 2016 -- 2024 Modelica Association Project "SSP"
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the
@@ -48,17 +48,20 @@
+
+
- Version of SSM format, 1.0 for this release.
+ Version of SSM format, 1.0 or 2.0 for this release.
-
+
+
diff --git a/schema/ssp/SystemStructureParameterValues.xsd b/schema/ssp/SystemStructureParameterValues.xsd
index 6c34bd895..7dce58267 100644
--- a/schema/ssp/SystemStructureParameterValues.xsd
+++ b/schema/ssp/SystemStructureParameterValues.xsd
@@ -6,11 +6,11 @@
This is the normative XML Schema 1.0 schema for the MAP SSP
- SystemStructureParameterValues 1.0 format.
+ SystemStructureParameterValues 2.0 format.
- Version: 1.0
+ Version: 2.0
- Copyright 2016 -- 2019 Modelica Association Project "SSP"
+ Copyright 2016 -- 2024 Modelica Association Project "SSP"
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the
@@ -50,17 +50,20 @@
+
+
- Version of SSV format, 1.0 for this release.
+ Version of SSV format, 1.0 or 2.0 for this release.
-
+
+
@@ -87,12 +90,64 @@
-
+
- This attribute gives the value of the parameter.
+ This attribute gives the value(s) of the parameter. Array
+ values are serialized in row-major order, as defined in FMI.
+
+
+
+
+
+
+
+ This attribute gives the unit of the parameter value and must
+ reference one of the unit definitions provided in the Units
+ element of the enclosing file.
+
+
+
+
+
+
+
+
+
+
+ This attribute gives the value(s) of the parameter. Array
+ values are serialized in row-major order, as defined in FMI.
+
+
+
+
+
+
+
+
+
+ This attribute gives the unit of the parameter value and must
+ reference one of the unit definitions provided in the Units
+ element of the enclosing file.
+
+
+
+
+
+
+
+
+
+
+ This attribute gives the value(s) of the parameter. Array
+ values are serialized in row-major order, as defined in FMI.
+
+
+
+
+
@@ -107,32 +162,181 @@
-
+
+
+
+ This attribute gives the value(s) of the parameter. Array
+ values are serialized in row-major order, as defined in FMI.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This attribute gives the value(s) of the parameter. Array
+ values are serialized in row-major order, as defined in FMI.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This attribute gives the value(s) of the parameter. Array
+ values are serialized in row-major order, as defined in FMI.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This attribute gives the value(s) of the parameter. Array
+ values are serialized in row-major order, as defined in FMI.
+
+
+
+
+
+
+
+
+
+
+
- This attribute gives the value of the parameter.
+ This attribute gives the value(s) of the parameter. Array
+ values are serialized in row-major order, as defined in FMI.
+
+
+
+
+
+
+
+
+
+
+
+ This attribute gives the value(s) of the parameter. Array
+ values are serialized in row-major order, as defined in FMI.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This attribute gives the value(s) of the parameter. Array
+ values are serialized in row-major order, as defined in FMI.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This attribute gives the value(s) of the parameter. Array
+ values are serialized in row-major order, as defined in FMI.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This attribute gives the value(s) of the parameter. Array
+ values are serialized in row-major order, as defined in FMI.
+
+
+
+
+
-
+
- This attribute gives the value of the parameter.
+ This attribute gives the value(s) of the parameter. Array
+ values are serialized in row-major order, as defined in FMI.
+
+
+
-
+
+
+
+
+ This element gives the value for one array element of the
+ parameter. If any Value element is present, then the value
+ attribute on the parent element MUST NOT be used.
+ Array values are serialized in row-major order, as defined
+ in FMI.
+
+
+
+
+
+
+
+
- This attribute gives the value of the parameter.
+ This attribute gives the value of the parameter, if it is a
+ scalar parameter. For array parameters requiring more than
+ one element, Value elements MUST be used. For scalar and one
+ element array parameters the Value element CAN be used. In
+ either case, if Value elements are used, then this value
+ attribute MUST NOT be present.
@@ -140,13 +344,39 @@
-
+
+
+
+
+ This element gives the value for one array element
+ of the parameter as the enumeration item name.
+ If any Value element is present, then the value
+ attribute on the parent element MUST NOT be used.
+ Note that the actual numeric value this value is
+ mapped to at run time will depend on the item mapping
+ of the enumeration type of the variables being
+ parameterized.
+ Array values are serialized in row-major order, as defined
+ in FMI.
+
+
+
+
+
+
+
+
- This attribute gives the value of the parameter as
- the enumeration item name. Note that the actual
- numeric value this value is mapped to at run time
- will depend on the item mapping of the enumeration
+ This attribute gives the value of the parameter as the
+ enumeration item name, if it is a scalar parameter. For
+ array parameters requiring more than one element, Value
+ elements MUST be used. For scalar and one element array
+ parameters the Value element CAN be used. In either case,
+ if Value elements are used, then this value attribute MUST
+ NOT be present.
+ Note that the actual numeric value this value is mapped to
+ at run time will depend on the item mapping of the enumeration
type of the variables being parameterized.
@@ -175,6 +405,22 @@
+
+
+
+
+ This element gives the value for one array element of the
+ parameter. If any Value element is present, then the value
+ attribute on the parent element MUST NOT be used.
+ Array values are serialized in row-major order, as defined
+ in FMI.
+
+
+
+
+
+
+
@@ -191,17 +437,33 @@
-
+
- This attribute gives the value of the parameter as a
- hex encoded binary value.
+ This attribute gives the value of the parameter as a hex
+ encoded binary value, if it is a scalar parameter. For
+ array parameters requiring more than one element, Value
+ elements MUST be used. For scalar and one element array
+ parameters the Value element CAN be used. In either case,
+ if Value elements are used, then this value attribute MUST
+ NOT be present.
+
+
+
+ This optional sequence of elements specifies the dimensions of
+ an array parameter. If no dimension elements are present in a
+ parameter, it is a scalar parameter. The number of dimension
+ elements in a parameter provides the dimensionality of the
+ parameter.
+
+
+
diff --git a/schema/ssp/SystemStructureSignalDictionary.xsd b/schema/ssp/SystemStructureSignalDictionary.xsd
index b03b05fbc..0577252ad 100644
--- a/schema/ssp/SystemStructureSignalDictionary.xsd
+++ b/schema/ssp/SystemStructureSignalDictionary.xsd
@@ -6,11 +6,11 @@
This is the normative XML Schema 1.0 schema for the MAP SSP
- SystemStructureSignalDictionary 1.0 format.
+ SystemStructureSignalDictionary 2.0 format.
- Version: 1.0
+ Version: 2.0
- Copyright 2016 -- 2019 Modelica Association Project "SSP"
+ Copyright 2016 -- 2024 Modelica Association Project "SSP"
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the
@@ -50,17 +50,20 @@
+
+
- Version of SSB format, 1.0 for this release.
+ Version of SSB format, 1.0 or 2.0 for this release.
-
+
+
@@ -72,6 +75,7 @@
+
diff --git a/src/OMSimulatorLib/Connector.cpp b/src/OMSimulatorLib/Connector.cpp
index 6db6ad034..a5a708491 100644
--- a/src/OMSimulatorLib/Connector.cpp
+++ b/src/OMSimulatorLib/Connector.cpp
@@ -181,7 +181,7 @@ std::string oms::Connector::getTypeString(const pugi::xml_node& node, const std:
{
return node.attribute("type").as_string();
}
- else if (sspVersion == "1.0")
+ else if (sspVersion == "1.0" || sspVersion == "2.0")
{
for(pugi::xml_node_iterator it = node.begin(); it != node.end(); ++it)
{
diff --git a/src/OMSimulatorLib/Model.cpp b/src/OMSimulatorLib/Model.cpp
index d9e3bbebc..da2de9fc8 100644
--- a/src/OMSimulatorLib/Model.cpp
+++ b/src/OMSimulatorLib/Model.cpp
@@ -335,7 +335,7 @@ oms_status_enu_t oms::Model::importSnapshot(const char* snapshot_, char** newCre
if (new_cref != getCref() && Scope::GetInstance().getModel(new_cref))
return logError("Renaming the model \"" + std::string(getCref()) + "\" to \"" + std::string(new_cref) + "\" failed because another model with the same name already exists in the scope.");
- if (ssdVersion != "Draft20180219" && ssdVersion != "1.0")
+ if (ssdVersion != "Draft20180219" && ssdVersion != "1.0" && ssdVersion != "2.0")
logWarning("Unknown SSD version: " + ssdVersion);
System* old_root_system = system;
@@ -892,7 +892,7 @@ oms_status_enu_t oms::Model::importFromSnapshot(const Snapshot& snapshot)
oms_system_enu_t systemType = getSystemType(*it, sspVersion);
if (oms_status_ok != addSystem(systemCref, systemType))
- return oms_status_error;
+ return logError("Unable to add System \"" + std::string(systemCref.c_str()) + "\"");
System* system = getSystem(systemCref);
if (!system)
@@ -939,7 +939,7 @@ oms_status_enu_t oms::Model::importFromSnapshot(const Snapshot& snapshot)
{
name = itAnnotations->name();
// check for oms_default_experiment from version 1.0
- if (std::string(name) == oms::ssp::Version1_0::simulation_information && sspVersion == "1.0")
+ if (std::string(name) == oms::ssp::Version1_0::simulation_information && (sspVersion == "1.0" || sspVersion == "2.0"))
{
resultFilename = itAnnotations->attribute("resultFile").as_string();
loggingInterval = itAnnotations->attribute("loggingInterval").as_double();
@@ -971,7 +971,7 @@ oms_system_enu_t oms::Model::getSystemType(const pugi::xml_node& node, const std
}
/* from Version "1.0" simulationInformation is handled in vendor annotation */
- if (name == oms::ssp::Draft20180219::ssd::annotations && sspVersion == "1.0")
+ if (name == oms::ssp::Draft20180219::ssd::annotations && (sspVersion == "1.0" || sspVersion == "2.0"))
{
pugi::xml_node annotation_node;
annotation_node = itElements->child(oms::ssp::Version1_0::ssc::annotation);
diff --git a/src/OMSimulatorLib/Scope.cpp b/src/OMSimulatorLib/Scope.cpp
index 867f6ed0f..bd72b641b 100644
--- a/src/OMSimulatorLib/Scope.cpp
+++ b/src/OMSimulatorLib/Scope.cpp
@@ -217,7 +217,7 @@ oms_status_enu_t oms::Scope::importModel(const std::string& filename, char** _cr
if (!model)
return oms_status_error;
- if (ssdVersion != "Draft20180219" && ssdVersion != "1.0")
+ if (ssdVersion != "Draft20180219" && ssdVersion != "1.0" && ssdVersion != "2.0")
logWarning("Unknown SSD version: " + ssdVersion);
// extract the ssp file
@@ -436,8 +436,8 @@ oms_status_enu_t oms::Scope::loadSnapshot(const oms::ComRef& cref, const char* s
return logError("failed to load snapshot, because it would change the model's name but it already exists in the scope");
std::string ssdVersion = node.attribute("version").as_string();
- if (ssdVersion != "Draft20180219" && ssdVersion != "1.0")
- return logError("Unknown SSD version \"" + ssdVersion + "\"; supported version are \"1.0\" and \"Draft20180219\".");
+ if (ssdVersion != "Draft20180219" && ssdVersion != "1.0" && ssdVersion != "2.0")
+ return logError("Unknown SSD version \"" + ssdVersion + "\"; supported version are \"1.0\" and \"2.0\" and\"Draft20180219\".");
oms_status_enu_t status = getModel(cref)->loadSnapshot(node);
diff --git a/src/OMSimulatorLib/Snapshot.cpp b/src/OMSimulatorLib/Snapshot.cpp
index 73c548c39..950d52596 100644
--- a/src/OMSimulatorLib/Snapshot.cpp
+++ b/src/OMSimulatorLib/Snapshot.cpp
@@ -190,7 +190,7 @@ pugi::xml_node oms::Snapshot::getTemplateResourceNodeSSD(const filesystem::path&
ssdNode.append_attribute("xmlns:ssb") = "http://ssp-standard.org/SSP1/SystemStructureSignalDictionary";
ssdNode.append_attribute("xmlns:oms") = "https://raw.githubusercontent.com/OpenModelica/OMSimulator/master/schema/oms.xsd";
ssdNode.append_attribute("name") = cref.c_str();
- ssdNode.append_attribute("version") = "1.0";
+ ssdNode.append_attribute("version") = "2.0";
return ssdNode;
}
@@ -201,7 +201,7 @@ pugi::xml_node oms::Snapshot::getTemplateResourceNodeSSV(const filesystem::path&
pugi::xml_node node_parameterset = new_node.append_child(oms::ssp::Version1_0::ssv::parameter_set);
node_parameterset.append_attribute("xmlns:ssc") = "http://ssp-standard.org/SSP1/SystemStructureCommon";
node_parameterset.append_attribute("xmlns:ssv") = "http://ssp-standard.org/SSP1/SystemStructureParameterValues";
- node_parameterset.append_attribute("version") = "1.0";
+ node_parameterset.append_attribute("version") = "2.0";
node_parameterset.append_attribute("name") = cref.c_str();
pugi::xml_node node_parameters = node_parameterset.append_child(oms::ssp::Version1_0::ssv::parameters);
@@ -214,7 +214,7 @@ pugi::xml_node oms::Snapshot::getTemplateResourceNodeSSM(const filesystem::path&
pugi::xml_node node_parameterMapping = new_node.append_child(oms::ssp::Version1_0::ssm::parameter_mapping);
node_parameterMapping.append_attribute("xmlns:ssc") = "http://ssp-standard.org/SSP1/SystemStructureCommon";
node_parameterMapping.append_attribute("xmlns:ssm") = "http://ssp-standard.org/SSP1/SystemStructureParameterMapping";
- node_parameterMapping.append_attribute("version") = "1.0";
+ node_parameterMapping.append_attribute("version") = "2.0";
return node_parameterMapping;
}
@@ -223,7 +223,7 @@ pugi::xml_node oms::Snapshot::getTemplateResourceNodeSignalFilter(const filesyst
{
pugi::xml_node new_node = newResourceNode(filename);
pugi::xml_node oms_signalFilter = new_node.append_child(oms::ssp::Version1_0::oms_signalFilter);
- oms_signalFilter.append_attribute("version") = "1.0";
+ oms_signalFilter.append_attribute("version") = "2.0";
return oms_signalFilter;
}
@@ -232,7 +232,7 @@ pugi::xml_node oms::Snapshot::getTemplateResourceNodeSSDVariants()
{
pugi::xml_node new_node = newResourceNode("ssdVariants.xml");
pugi::xml_node oms_variants = new_node.append_child("oms:Variants");
- oms_variants.append_attribute("version") = "1.0";
+ oms_variants.append_attribute("version") = "2.0";
return oms_variants;
}
diff --git a/src/OMSimulatorLib/System.cpp b/src/OMSimulatorLib/System.cpp
index edb3df7a6..aabdcc6fb 100644
--- a/src/OMSimulatorLib/System.cpp
+++ b/src/OMSimulatorLib/System.cpp
@@ -862,9 +862,16 @@ oms_status_enu_t oms::System::importFromSnapshot(const pugi::xml_node& node, con
// allow component type to be empty, as type is optional according to SSP-1.0 and default type is application/x-fmu-sharedlibrary
if ("application/x-fmu-sharedlibrary" == type || type.empty())
{
- if (getType() == oms_system_wc)
+ // read the modelDescription.xml in memory to detect the fmiVersion
+ std::string source = itElements->attribute("source").as_string();
+ filesystem::path modelDescriptionPath = filesystem::path(getModel().getTempDirectory()) / filesystem::path(source);
+ std::string fmiVersion = getFmiVersion(modelDescriptionPath.generic_string());
+
+ if (getType() == oms_system_wc && fmiVersion == "2.0")
component = ComponentFMUCS::NewComponent(*itElements, this, sspVersion, snapshot, variantName);
- else if (getType() == oms_system_sc)
+ else if (getType() == oms_system_wc && fmiVersion == "3.0")
+ component = ComponentFMU3CS::NewComponent(*itElements, this, sspVersion, snapshot, variantName);
+ else if (getType() == oms_system_sc && fmiVersion == "2.0")
component = ComponentFMUME::NewComponent(*itElements, this, sspVersion, snapshot, variantName);
else
return logError("wrong xml schema detected: " + name);
@@ -914,7 +921,7 @@ oms_status_enu_t oms::System::importFromSnapshot(const pugi::xml_node& node, con
name = itAnnotations->name();
// check for oms:simulationInformation from version 1.0
- if (std::string(name) == oms::ssp::Version1_0::simulation_information && sspVersion == "1.0")
+ if (std::string(name) == oms::ssp::Version1_0::simulation_information && (sspVersion == "1.0" || sspVersion == "2.0"))
{
if (oms_status_ok != importFromSSD_SimulationInformation(*itAnnotations, sspVersion))
return logError("Failed to import " + std::string(oms::ssp::Version1_0::simulation_information));
diff --git a/src/OMSimulatorLib/SystemWC.cpp b/src/OMSimulatorLib/SystemWC.cpp
index 5eb323809..266b1800c 100644
--- a/src/OMSimulatorLib/SystemWC.cpp
+++ b/src/OMSimulatorLib/SystemWC.cpp
@@ -133,7 +133,7 @@ oms_status_enu_t oms::SystemWC::importFromSSD_SimulationInformation(const pugi::
pugi::xml_node fixedStepMaster = node.child(oms::ssp::Version1_0::FixedStepMaster);
if (fixedStepMaster)
{
- if (sspVersion == "1.0")
+ if (sspVersion == "1.0" || sspVersion == "2.0")
{
solverName = fixedStepMaster.attribute("description").as_string();
FixedStepMaster = oms::ssp::Version1_0::FixedStepMaster;
@@ -150,7 +150,7 @@ oms_status_enu_t oms::SystemWC::importFromSSD_SimulationInformation(const pugi::
pugi::xml_node variableStepMaster = node.child(oms::ssp::Version1_0::VariableStepMaster);
if (variableStepMaster)
{
- if (sspVersion == "1.0")
+ if (sspVersion == "1.0" || sspVersion == "2.0")
{
solverName = variableStepMaster.attribute("description").as_string();
VariableStepMaster = oms::ssp::Version1_0::VariableStepMaster;
diff --git a/src/OMSimulatorLib/Values.cpp b/src/OMSimulatorLib/Values.cpp
index 868aceb49..cf1058b5d 100644
--- a/src/OMSimulatorLib/Values.cpp
+++ b/src/OMSimulatorLib/Values.cpp
@@ -820,7 +820,7 @@ oms_status_enu_t oms::Values::exportToSSD(pugi::xml_node& node) const
pugi::xml_node node_parameter_values = node_parameter_binding.append_child(oms::ssp::Version1_0::ssd::parameter_values);
pugi::xml_node node_parameterset = node_parameter_values.append_child(oms::ssp::Version1_0::ssv::parameter_set);
- node_parameterset.append_attribute("version") = "1.0";
+ node_parameterset.append_attribute("version") = "2.0";
node_parameterset.append_attribute("name") = "parameters";
pugi::xml_node node_parameters = node_parameterset.append_child(oms::ssp::Version1_0::ssv::parameters);
@@ -1129,7 +1129,7 @@ void oms::Values::exportParameterBindings(pugi::xml_node &node, Snapshot &snapsh
pugi::xml_node node_parameter_binding = node_parameters_bindings.append_child(oms::ssp::Version1_0::ssd::parameter_binding);
pugi::xml_node node_parameter_values = node_parameter_binding.append_child(oms::ssp::Version1_0::ssd::parameter_values);
pugi::xml_node node_parameterset = node_parameter_values.append_child(oms::ssp::Version1_0::ssv::parameter_set);
- node_parameterset.append_attribute("version") = "1.0";
+ node_parameterset.append_attribute("version") = "2.0";
node_parameterset.append_attribute("name") = "parameters";
pugi::xml_node node_parameters = node_parameterset.append_child(oms::ssp::Version1_0::ssv::parameters);
res.second.exportStartValuesHelper(node_parameters);
diff --git a/testsuite/api/addExternalResources1.lua b/testsuite/api/addExternalResources1.lua
index e1523520c..962e1587e 100644
--- a/testsuite/api/addExternalResources1.lua
+++ b/testsuite/api/addExternalResources1.lua
@@ -96,7 +96,7 @@ print(src)
-- xmlns:ssb="http://ssp-standard.org/SSP1/SystemStructureSignalDictionary"
-- xmlns:oms="https://raw.githubusercontent.com/OpenModelica/OMSimulator/master/schema/oms.xsd"
-- name="addExternalResources"
--- version="1.0">
+-- version="2.0">
--
--
@@ -227,7 +227,7 @@ print(src)
--
--
--
--
--
--
--
--
+-- version="2.0">
--
+-- version="2.0">
--
--
@@ -463,7 +463,7 @@ print(src)
--
--
--
--
--
--
--
--
+-- version="2.0">
--
+-- version="2.0">
--
--
@@ -225,7 +225,7 @@ oms_delete("import_parameter_mapping")
--
--
--
+-- version="2.0">
--
@@ -289,7 +289,7 @@ oms_delete("import_parameter_mapping")
--
--
+-- version="2.0">
--
+-- version="2.0">
--
--
@@ -543,7 +543,7 @@ oms_delete("import_parameter_mapping")
--
--
--
+-- version="2.0">
--
@@ -607,7 +607,7 @@ oms_delete("import_parameter_mapping")
--
--
+-- version="2.0">
--
+## version="2.0">
##
##
@@ -231,7 +231,7 @@
##
##
##
##
##
##
##
##
+## version="2.0">
##
+## version="2.0">
##
##
@@ -467,7 +467,7 @@
##
##
##
##
##
##
##
##
+## version="2.0">
##
+## version="2.0">
##
##
@@ -228,7 +228,7 @@
##
##
##
+## version="2.0">
##
@@ -292,7 +292,7 @@
##
##
+## version="2.0">
##
+## version="2.0">
##
##
@@ -546,7 +546,7 @@
##
##
##
+## version="2.0">
##
@@ -610,7 +610,7 @@
##
##
+## version="2.0">
##
+-- version="2.0">
--
--
@@ -105,7 +105,7 @@ oms_delete("addExternalResources")
--
--
--
+-- version="2.0">
--
@@ -169,7 +169,7 @@ oms_delete("addExternalResources")
--
--
+-- version="2.0">
--
+-- version="2.0">
--
--
@@ -213,7 +213,7 @@ oms_delete("deleteResources")
--
--
--
--
--
--
--
--
+-- version="2.0">
--
+-- version="2.0">
--
--
@@ -437,7 +437,7 @@ oms_delete("deleteResources")
--
--
--
--
--
--
--
--
+-- version="2.0">
--
+-- version="2.0">
--
--
@@ -210,7 +210,7 @@ oms_delete("deleteResources")
--
--
--
--
--
--
--
--
+-- version="2.0">
--
+-- version="2.0">
--
--
@@ -432,7 +432,7 @@ oms_delete("deleteResources")
--
--
+-- version="2.0">
--
+-- version="2.0">
--
--
@@ -233,7 +233,7 @@ oms_delete("import_parameter_mapping")
--
--
--
+-- version="2.0">
--
@@ -297,7 +297,7 @@ oms_delete("import_parameter_mapping")
--
--
+-- version="2.0">
--
+-- version="2.0">
--
--
@@ -551,7 +551,7 @@ oms_delete("import_parameter_mapping")
--
--
--
+-- version="2.0">
--
@@ -615,7 +615,7 @@ oms_delete("import_parameter_mapping")
--
--
+-- version="2.0">
--
--
--
--
--
+-- version="2.0">
--
--
@@ -100,7 +100,7 @@ print(src)
--
--
--
--
--
--
+-- version="2.0">
--
+-- version="2.0">
--
--
@@ -271,7 +271,7 @@ print(src)
--
--
--
--
--
--
+-- version="2.0">
--
--
--
##
##
--
--
--
--
+-- version="2.0">
--
--
@@ -101,7 +101,7 @@ oms_delete("model")
--
--
--
--
--
--
+-- version="2.0">
--
+-- version="2.0">
--
--
@@ -273,7 +273,7 @@ oms_delete("model")
--
--
--
--
--
--
+-- version="2.0">
--
##
##
##
##
---
+--
--
--
--
@@ -165,7 +165,7 @@ printStatus(status, 3)
-- status: [correct] ok
-- status: [correct] ok
--
---
+--
--
--
--
diff --git a/testsuite/api/test01.py b/testsuite/api/test01.py
index 37303ca81..094da537b 100644
--- a/testsuite/api/test01.py
+++ b/testsuite/api/test01.py
@@ -82,7 +82,7 @@ def printStatus(status, expected):
## error: [NewSystem] A WC system must be the root system.
## status: [correct] error
##
-##
+##
##
##
##
@@ -165,7 +165,7 @@ def printStatus(status, expected):
## status: [correct] ok
## status: [correct] ok
##
-##
+##
##
##
##
diff --git a/testsuite/api/test03.lua b/testsuite/api/test03.lua
index 3effae2c7..c4c992e23 100644
--- a/testsuite/api/test03.lua
+++ b/testsuite/api/test03.lua
@@ -66,7 +66,7 @@ oms_delete("test03lua")
-- Result:
--
---
+--
--
--
--
@@ -128,7 +128,7 @@ oms_delete("test03lua")
-- error: [getResourceNode] Failed to find node "resources/signalFilter.xml"
-- status: [correct] ok
--
---
+--
--
--
--
diff --git a/testsuite/api/test03.py b/testsuite/api/test03.py
index 6baa04adf..c25762082 100644
--- a/testsuite/api/test03.py
+++ b/testsuite/api/test03.py
@@ -60,7 +60,7 @@ def printStatus(status, expected):
## Result:
##
-##
+##
##
##
##
@@ -122,7 +122,7 @@ def printStatus(status, expected):
## error: [getResourceNode] Failed to find node "resources/signalFilter.xml"
## status: [correct] ok
##
-##
+##
##
##
##
diff --git a/testsuite/api/test_omsExport.lua b/testsuite/api/test_omsExport.lua
index 7e1901abd..b9b5f5ef7 100644
--- a/testsuite/api/test_omsExport.lua
+++ b/testsuite/api/test_omsExport.lua
@@ -64,7 +64,7 @@ printStatus(status, 0)
-- status: [correct] ok
-- status: [correct] ok
--
---
+--
--
--
--
@@ -91,7 +91,7 @@ printStatus(status, 0)
-- status: [correct] ok
-- status: [correct] ok
--
---
+--
--
--
--
diff --git a/testsuite/api/test_omsExport.py b/testsuite/api/test_omsExport.py
index 33c67518b..239a17e3a 100644
--- a/testsuite/api/test_omsExport.py
+++ b/testsuite/api/test_omsExport.py
@@ -65,7 +65,7 @@ def printStatus(status, expected):
## status: [correct] ok
## status: [correct] ok
##
-##