System Structure and Parameterization

From HandWiki
Revision as of 14:08, 1 May 2022 by imported>Importwiki (import)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
System Structure and Parameterization
Developer(s)Modelica Association]
Stable release
1.0 / March 5, 2019
Operating systemMultiple
PlatformMultiple
TypeSystem specification standard
LicenseCC-BY-SA (specification), BSD license (XML schema)
Websitewww.ssp-standard.org

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.[1] 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 [2] standard can be integrated into SSP. The OSI [3] 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
  • 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.

Application Examples

For these examples 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 an a complex technical system.

SSP can be seen 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 route 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 vehicles 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" [4], especially the Mid-Term-Event about architecture [5]

Related Standards

References

  • Architecture in SetLevel, Mid Term Event of German public funded project "SetLevel" ([1])
  • Enhancing the Model Integration Workflow in Aircraft System Simulation using FMI & SSP, Modelica Conference 2019 ([2])
  • OMSimulator – Integrated FMI and TLM-based Co-simulation with Composite Model Editing and SSP, Modelica Conference 2019 ([3])
  • Connecting system simulation to aircraft concept development, ICAS 2020 Conference ([4])
  • Engineering Domain Interoperability Using the System Structure and Parameterization (SSP) Standard, Modelica Conference 2021 ([5])
  • Modelica, FMI and SSP for LOTAR of Analytical mBSE models: First Implementation and Feedback, Modelica Conference 2021 ([6])
  • Efficient Parameterization of Modelica Models, Modelica Conference 2021 ([7])
  • A Graph-Based Meta-Data Model for DevOps in Simulation-Driven Development and Generation of DCP Configurations, Modelica Conference 2021 ([8])
  • On Standardized Model Integration : Automated Validation in Aircraft System Simulation, Linköping Studies in Science and Technology ([9])
  • Collaborative Validation of Complex Products, Prostep IVIP symposium 2022 ([10])

References


External links


Category:Computational science