System Structure and Parameterization

---

System Structure and Parameterization

Developer(s)	Modelica Association]
Stable release	1.0.1 / August 10, 2022
Engine
Operating system	Multiple
Platform	Multiple
Type	System specification standard
License	CC-BY-SA (specification), BSD license (XML schema)
Website	ssp-standard.org

Search System Structure and Parameterization on Amazon.

System Structure and Parameterization (SSP) is a standardized, open file format to describe complex, hierarchical (technical) systems, that can be simulated. An SSP file contains definitions for system architecture, the interfaces of the system elements, and their connections and parameterization. The aim of SSP is to simplify the exchange and integration of system elements that are used in the distributed development of a system to be simulated using a wide variety of tools.

Description

SSP is being developed as a project of the Modelica Association and is based on the FMI standard. FMI enables the exchange of individual simulation components, while SSP enables the exchange of complete simulation systems, their variants and parameterization. The simulation components of a simulation system described in SSP can also be independent of FMI and map to other implementations. As part of the Modelica Association, the DCP Standard is also under development which focuses on distributed simulation and the interchangeability of complete system descriptions between different tools in all stages of a model development.

SSP is designed to support the simulation of systems from various domains. Domain-specific requirements can be mapped using existing extension mechanisms - a so-called layered standard. As an example for the simulation of autonomous vehicles, the OSI standard can be integrated into SSP. The OSI standard defines specific Interfaces between components that are relevant in a system model in the context of autonomous driving.

Basic features

SSP describes the system architecture and the elements of a complex system to be simulated; that includes component interfaces and the connection topology. This specification can be used and exchanged for communication of the overall design (architecture) and as a template for the implementation of system and individual components as well as for their integration into an overall system. Reuse of described systems in different models is possible via links or as a copy. Different system variants can be contained. The variants can be used for alternative system modeling, different parameterizations or to map a history in the design process.

SSP as an open data exchange format, acting as the basis for process support and enables process automation in the creation of simulation models and their simulation. Systems can be executed in different simulation environments. Continuous Modeling, Continuous Integration and Continuous Simulation in all phases of development (MIL, SIL, HIL) are supported.

SSP is extensible to support specific requirements or domain-specific extensions: e.g. OSI, documentation of requirements, traceability or process steps, etc. SSP is open with regard to the component formats. Although it was based on FMI, it can also be used with components specifications of any other format.

Essential functions in SSP are:

• Hierarchical structuring of the system model
• Structure of the systems from different system elements.
• Description of the various system elements with their specific properties.
• Description of their interfaces via connectors.
• Description of the coupling of system elements via connections.
• Transformation of data of connected connectors with different data types.
• Definition of master data used in the model (units, enumerations, mime types).
• Description of position, size and display of the elements in a coordinate system.
• Parameterization of the system elements via parameter sets and specification of parameter mappings, as one of several posibilities.
• Referencing any simulation logic to the simulation components.
• Specification and distribution of signals in the system model via a bus concept (signal library and reference).

Using SSP for building a system simulation process

SSP can be used in several phases in the development of a complex system.

• Draft of an initial system architecture in different variants. The system architect must build a structure of the system from hierarchically nested systems and individual components, and start a specification of the interfaces of the system elements. The architecture is defined by the connections between system elements.
• Distribute the system architecture or parts of the system architecture to those involved in the process (e.g. suppliers of individual components and their simulation models) in SSP format.
• Development partners will load the system architecture or parts of the system architecture into the tool landscape of the system component developers, in order to implement the simulation component (s) according to the interface specification defined in SSP.
• Partners provide the implemented simulation component(s) in SSP format. This allows a system integrator to validate all simulation components in SSP format using simulation.
• Distribute the overall system to be simulated to different simulation environments at different levels of development maturity ( MIL, SIL, HIL) incl. parameterization.

Automotive Examples

For this example we assume a scenario with preconfigured driving dynamics simulation networks, consisting of route models, control units, sensors/actuators, and remaining bus simulation between simulation platforms. The key stakeholders are:

• OEM (truck manufacturer) using a new gearbox.
• Supplier of components for autonomous driving.
• Gearbox supplier that provides components or transmission sub-systems.

Simulation of the driveline in a truck

Using a truck as example for a complex technical system.

SSP can be seen as a virtual construction manual, assembling the individual virtual components (e.g. FMUs). Another term used in this context is Virtual Twin. Example components used for simple cycle simulations are:

• Engine
• Transmission
• Shift function (control logic) for transmission
• Vehicle (longitudinal dynamics only)
• Driver model (executing a driving cycle)

The system architecture as building instructions for the virtual truck, allowing simple parameterization and functional FMUs for executable simulation. With SSP, all components can be parameterized consistently together and parameter sets can reused between different scenarios and vehicle models.

Validation of autonomous driving functions

For simulation of autonomous driving (ADAS) we need integration of models of sensors, sensor fusion, autonomous driving function and driving dynamics to create a composite traffic participant model in the sense of the OSI specification. Typical subsystems are:

• Fused sensor models are provided by the sensor suppliers.
• Sensor Fusion and Autonomous Driving Functions (logic) provided by the relevant specialist departments.
• Driving dynamics with a description of the remaining vehicle are provided by the vehicle department.
• Creation of the network system as an SSD description and parameterization using SSV (values) / SSM (name mapping) by the integration point.

The use of the traffic participant network model generated in this way can be used on simulation platforms with OSI & SSP support for simulative validation, for example scenario-based testing using OpenSCENARIO and OpenDRIVE. See also the German public funded project "SetLevel", especially the Mid-Term-Event about architecture

Aerospace Examples

Long-time archiving

LOng Time Archiving and Retrieval (LOTAR) of models is key to using the full capabilities of model-Based System Engineering (mBSE) in a system lifecycle – including certification. The LOTAR MBSE workgroup is writing the EN/NAS 9300-Part 520 to standardize the associated process, in the aeronautics industry, and suggests the usage of Modelica, FMI and SSP standards for its purpose.

Geometric system data

Another suggested application is to use SSP to represent system models together with geometric parameter data exported from a CAD system. This is an example where SSP is used as a common format for represeting advanced aircraft systems to serve a variety of modeling and simulation needs.

Related Standards

• Functional Mock-up Interface (FMI)
• Modelica
• Distributed Co-Simulation Protocol (DCP)
• Open Simulation Interface (OSI)
• Asset Administration Shell (AAS) of the Industrial Digital Twin Association references SSP in the "Submodel Template of the Asset Administration Shell"

See Also

• OMSimulator – Integrated FMI and TLM-based Co-simulation with Composite Model Editing and SSP, Modelica Conference 2019 ([1])
• Connecting system simulation to aircraft concept development, ICAS 2020 Conference ([2])
• A Graph-Based Meta-Data Model for DevOps in Simulation-Driven Development and Generation of DCP Configurations, Modelica Conference 2021 ([3])
• Collaborative Validation of Complex Products, Prostep IVIP symposium 2022 ([4])

External links

• ssp-standard.org
• SSP on Github
• fmi-standard.org
• dcp-standard.org

This article "System Structure and Parameterization" is from Wikipedia. The list of its authors can be seen in its historical and/or the page Edithistory:System Structure and Parameterization. Articles copied from Draft Namespace on Wikipedia could be seen on the Draft Namespace of Wikipedia and not main one.

📰 Article(s) of the same category(ies)

• Pixelorama
• Famingo Corporation
• Codewind
• HelloSign
• OneAPI Deep Neural Network Library
• Apex Launcher
• FlickRocket

---