Support of system models with bus communication

[UKiffmeier]

Network communication is becomming a more and more important aspect for system simulation in many areas: automotive, robotics, aerospace, and many more. Therefore, the SSP standard should support system models with network communcation.

The following figure shows the typical structure of a network of ECUs in a vehicle. The system contains different types of buses, including high speed buses (Ethernet), and low-speed buses (CAN, LIN) for peripheral ECUs / sensors. A simulation application may cover the whole vehicle, or parts of it, depending on the device under test. In addition to the ECUs, there will also be environment models and residual bus models.

SSP shall support the following features for network communication:

• Support for typical bus types, like CAN, LIN, Ethernet, FlexRay and maybe other field bus systems.

  • It is not necessary to describe the details of the bus. Mainly the interconnection of components in one or more communication clusters (buses) has to be described in SSP.

• Support for different types of components accessing the bus:

  • FMUs with fmi-ls-bus
  • Other vendor-specific formats (having special CommunicationConnectors for accessing a bus, i.e. not based on fmi-ls-bus).

• Hierarchical systems with network communication:

  • Use Case 1: Subsystem with a local CommunicationCluster.
  • Use Case 2: Common CommunicationCluster which is accessed from multiple system levels, i.e. from components in the top-level system and also from components in inner subsystems.

• Some basic validations of the network structure should be possible, for example, "Same baud rate for all components in a CAN cluster".

There are different use cases for the simulation of the bus behavior:

1. The bus behavior simulation is a built-in feature of the simulator. No extra component is needed to simulate the bus behavior. This is the main use case addressed by this issue.

   

2. The bus behavior is simulated by an own component. The participants are connected to this component, e.g. by means of FMU ports as defined in fmi-ls-bus.

   

   This use case is already possible with version 2.0 of the SSP standard, because it uses only standard input connectors, output connectors, and clock connectors as described by fmi-ls-bus. The remaining part is to provide a formal description that certain input/output/clock connectors together represent a CommunicationConnector for a bus at a component (see TerminalsAndIcons in fmi-ls-bus) and that the 'Bus Simulation FMU' represents the behavior simulation of a CommunicationCluster.

3. Two components sending and receiving bus messages are connected directly, e.g. by means of FMU ports as defined in fmi-ls-bus

   

   This use case is also already possible with version 2.0 of the SSP standard, see 2.).