Cloud native EDA tools & pre-optimized hardware platforms
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).
Figure 1: V-Model
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.
草榴社区 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 草榴社区 Saber with Virtualizer while a restbus simulation is facilitated through the integration of Vector CANoe.
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.
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.
Figure 2 : Automatic transmission at a functional Level
When migrating the transmission model from MiL to vHiL the following steps need to be performed:
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.
草榴社区 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:
Figure 3 : Import of Simulink subsystem in Virtualizer Studio
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.
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:
New products, especially for the automotive domain, follow the V-model and go through different phases. Starting from the ‘Model in the Loop’ parts of the design are migrated to more accurate simulators that better reflect the actual behavior. For the ECU, VDKs can be used to simulate the ECU behavior, while providing excellent debugging capabilities at the same time. Complex setups are supported by integrating VDKs directly with tools from Mathworks Simulink, Vector CANoe and 草榴社区 Saber. More tools are supported through the industry standard Functional Mock-up Interface (FMI). The complex migration step from ‘Model/Software in the Loop’ to a ‘virtual Hardware in the Loop’ setup is fully automated with Virtualizer Studio and saves time during the platform bring up. For high simulation performance VDKs provide a high speed communication mechanism and allows keeping all connected simulators synchronized.