Seamless Transition from Software in the Loop to virtual Hardware in the Loop with Virtualizer Studio

Introduction

With the increasing complexity of software running on next generation engine control units (ECUs), car manufacturers and their suppliers are confronted with the need to develop models of the electrical and physical parts of the car at different levels of abstraction. There are several phases of abstraction (Figure 1).

• ‘Model in the Loop’ (MiL) where the functional behavior is often described on a functional level, which is commonly designed in MathWorks Simulink.
• ‘Software in the Loop’ where blocks of the functional design are replaced by actual code that represents the behavior.
• ‘Processor in the Loop’ (PiL) where code is compiled for the actual target hardware. The target hardware communicates directly with the plant model in ‘non real time’.
• ‘Hardware in the Loop’ (HiL) is similar to PiL, but the target hardware communicates to a PC which is typically equipped with I/O boards to connect to the physical ports of the ECU. The plant model is compiled to execute on the real-time computer.

For all the phases, transitioning from one to the other requires manual work and time consuming validation and verification. On top of that, models of different time domains (known as multi domain simulation) need to be integrated when, for example, analog components are simulated with digital IP in the same environment which requires a flexible timing synchronization scheme. The traditional flow, following the V-model, has a gap at the component- and subsystem-integration phase as HiL-based verification is only available at the system integration phase, thus being late in the design cycle.

Synopsys Virtualizer offers a virtual Hardware in the Loop (vHiL) solution which allows simulation of the ECU and coupling it with external simulators. Typically, those simulators execute the physical/mechanical part of the plant model (e.g Mathworks/Simulink). On top of that, the platform assembly tool Virtualizer Studio supports seamless transitioning from MiL/SiL to vHiL. Parts of the Simulink model which are encapsulated in subsystems (hierarchical models in Simulink) can easily be migrated to the ECU while parts of the plant model (e.g. chassis or gearbox) still remain in the functional domain.  For electrical parts, simulation can be performed by integrating Synopsys Saber with Virtualizer while a restbus simulation is facilitated through the integration of Vector CANoe.

Transitioning from ‘Model in the Loop’ to ‘virtual Hardware in the Loop’

When transitioning from Model in the Loop to a simulation, where parts of the model are executed on a virtual model of the ECU (virtual Hardware in the Loop = vHiL), the designer transfers the control part of the plant model to the ECU simulator which are available for a broad set of platforms (Infineon, NXP/Freescale and Renesas). These ECU simulators, called Virtualizer Development Kits (VDKs) can interact with lots of automotive testing and simulation tools, offer an API for custom tool integration and integrate with a large variety of embedded software debuggers. The mechanical part of the plant model remains in -for example- Simulink. The transfer of parts of the plant model to the VDK will be described in the next section in more detail by looking at a simple example from the automotive domain, a transmission controller.

Extracting the Gearshift Logic from a Plant Model

Figure 2 shows a functional model of an automatic transmission controller with models for the engine, the transmission (green box) and the vehicle dynamics. On the functional level, the gear shift is modeled by a simple state machine sets the appropriate gear, depending on the ‘rounds per minute (rpm)’ value.

When migrating the transmission model from MiL to vHiL the following steps need to be performed:

1. Develop target code for the block that will be executed on the ECU. This can either be done by using the ‘embedded Coder’ from Mathworks or the designer writes code manually and compiles it for the desired target architecture.
2. Replace the transmission logic in the plant model by a stub model which connects the respective signals to the VDK. The underlying communication layer, which is provided by the Synopsys tools, is described in more detail in the Fast Communication Technology in Virtualizer Development Kits section.
3. Create an interface definition file which lists all input and output ports of the subsystem with their associated data types.

The transmission controller example which is used as a simple plant model for this article contains the ‘gear’ subsystem which represents the gearshift logic. While for this simple example, the above described steps can be done manually, this becomes an error prone process for large customer designs which have several hundreds of input and output pins if it’s not automated by a tool.

Simulink Integration to support MiL to vHiL migration

Synopsys VDKs support replacing subsystems created in Mathworks Simulink with corresponding blocks that stub the input and output pins and establish a communication layer to the ECU simulator at runtime. This is done by extending the context menus with two new commands:

1. Convert Subsystem to Connector Blocks
   This will remove all internal logic of the Simulink subsystem and insert ‘connector blocks’ to each pin. Those connector blocks establish a connection to the VDK during runtime and exchange data between the two simulators and synchronizing the simulation time between them.
2. Generate External Interface Definition File for Virtualizer Studio
   Virtualizer Studio is the integrated development environment which supports component creation, platform assembly and platform debug. VDKs are generated from Virtualizer Studio and can be extended with additional components during the assembly phase. Those additional components can be IP components or models that are actually executed on a different simulation platform (e.g. Simulink). To add the external Simulink model to the VDK, the interface definition file which is generated in Simulink is imported in Virtualizer Studio and the respective pins from the subsystem in Simulink are connected to pins on the actual ECU hardware.

Figure 3 shows the assistant in Virtualizer Studio, where the imported pins from the Simulink subsystem are shown (green circle). The RPM signal (rpm_digital) is listed as an analog signal output (as seen from the Simulink perspective), while the gear signals (gear_0 to gear_2) show up as input signals. A connection to the internal signals of the ECU is simply done by a double click on one of the signals. A dialog (‘Add Connection’) appears which allows establishing the link between the external Simulink pin and the ECU pin. Only pins on the ECU will be available for connection which have the same type as the external pin which significantly simplifies the connection process.

Fast Communication Technology in Virtualizer Development Kits

Virtual Hardware in the Loop involves at least two simulators that need to exchange data and synchronize their simulation time. For more complex setups where also analog components and busses (e.g. CAN, FlexRay, LIN or Ethernet) are involved, the number of involved simulators is even higher. There are also setups, where one part of a plant model is executed on one ECU while another part is transferred to a different ECU model. This demands a communication layer which supports:

1. High data throughput: The communication layer shall not limit the execution speed of the connected simulators. VDKs can execute at real time factors of up to 3. This means, that the ECU model is 3 times slower than the actual hardware which results in an overall simulation speed of roughly 30MHz. The traffic at the I/O boundary (e.g. A/D converters) is running at lower frequencies (typically in the MHz range) which sets the requirement for the communication layer. Inter-process communication between the simulators can be facilitated in many ways. The requirement for high simulation speed disqualifies distributed computing as the turnaround times (latency) are not acceptable. For simulations on a single host PC with multiple cores, ‘named pipes’ and ‘shared memory’ are available. While named pipes can only transfer ~50k 32bit integers back and forth between the simulators, shared memory allows a much higher throughput.
2. Synchronized simulation time: Even though shared memories provide sufficient data throughput the synchronization of the simulators is still an issue. The OS supported mechanisms like semaphores require between 6000 and 8000 assembly instructions to execute for a single access which results in 100-150k 32-bit data transfers per second which is still too slow. Using a VDK provides a dedicated synchronization algorithm which only requires a few hundreds of assembly instructions, resulting in 1M 32bit transfers. This is sufficient to execute a vHiL platform of several simulators at the native speed of the models and is not a limiting factor for the simulation.