Vehicle driving simulation on a virtual platform

frozenviolet

Vehicle driving simulation on a virtual platform [Copy link]

The complex electronic system of the car is equipped with a large number of multi-function ECUs ( electronic control units ) for internal communication through time-sensitive networks. Many automotive control systems use ECUs to implement single functions through network layer communication. A fashionable luxury car has up to 90 ECUs , and the weight of the wire harness required for all networking will exceed 50 kilograms. In order to reduce the weight of the wires, the ECU should be placed close to its control location.

New features require more flexible ECUs with large embedded software components . Telemetry and in-car entertainment require a combination of wireless connectivity, global positioning, Internet access via digital radio, and ready-to-go hands-free voice control.

Quantitative evaluation

Before defining the hardware and software system and preparing for in-depth development, it is necessary to quantitatively analyze and evaluate the possible structures within the network and ECU .

The traditional approach to developing automotive embedded software is to build a hardware board that reproduces all or part of the ECU and its external circuits, usually called a factory model. It is often not possible to perform all measurements with one setup, so many bench setups are required.

The performance requirements of the most powerful ECUs do not require expensive test boards for measurement. Limited testing of the ECU internals can avoid hardware debugging. Because the hardware does not generate error messages, simple errors, such as registers that are not initialized, take a long time to be discovered. Debugging software on a hardware prototype is difficult and time-consuming even with an in-circuit emulator.

Embedded systems must be fast enough to run large amounts of software, including real-time operating systems (RTOS) and network protocol stacks.

Figure 1 Changing the traditional method to a structural method using quantitative analysis

Combination of measurement methods

There are other approaches to bench testing, the host-based approach is "write once / move twice", where the software is first developed in a host PC with a test architecture using a simulator and then moved to the ECU . This approach can fail in an automotive environment because of the hard real-time constraints on the software and the inability to predict actual performance from the PC execution.

The ISS method uses a functional model of the processor, which is usually provided by the processor vendor. The problem is that sometimes the model does not match the cycle-to-cycle characteristics of the processor. Speed is another problem, because ISS is too slow, with typical values of 100~500kIPS (0.1~0.5MIPS) , to run large software for real applications, and become part of the daily edit-compile-debug cycle.

The new approach enables software developers to build system-level ECU models, or virtual platforms of ECUs ( or networked ECU subsystems ) , develop all software on the models before the final synthesis stage, and then port them to the real ECU hardware.

Virtual Platform

VaS Systems ' VaST virtual platform technology can simulate a 200MIPS embedded processor on a commercially available PC . Because the processor model is cycle-by-cycle accurate, engineers can measure all interactions with the hardware and perform detailed performance measurements on the software and hardware-software interface.

The virtual platform is completely transparent to the ECU internals and is much better than the hardware-based debugging environment. The following are customer design examples:

An ECU platform forms the core of the vehicle off-road detector. The platform uses the analog signal of the rotation accelerometer as input. If the vehicle starts to roll, the signal is mathematically processed to obtain the angular velocity and position of the vehicle. When the vehicle rolls too fast, the airbag is activated immediately, while when the vehicle rolls slowly, the activation of the airbag is delayed.

The role of peripherals

The platform is complicated by the presence of many peripherals, including clock generators, memories, timers, and interrupt controllers, as well as the aforementioned accelerometer and airbag release interface.

The processor is monitored by a "Computer Correct Operation" watchdog timer that asserts the reset line if the timer hangs, indicating that the processor has entered an undesired cycle. A "Low Voltage Inhibit" peripheral monitors the supply voltage to prevent airbag deployment during battery damage or engine start-up. Real-time operation ensures that the watchdog timer never hangs, allowing the sequence of actions to be executed at startup.

Using a virtual platform approach, engineers integrated the RTOS and all peripheral drivers and then tested the airbag deployment algorithm, saving an estimated six months compared to the factory model approach used in the past.

Virtual system simulation

The system architecture also enables many advanced simulations, using MATLAB , UML , SystemsC , or high-level C or C++ modeling languages to express abstract specifications. Once the basic characteristics are correct, the analysis software can distribute functions to multiple ECUs and examine the performance requirements of each ECU and the interconnection network. Each ECU can be networked with processor levels, buses, and peripherals, and functions can be moved between hardware and software.

Quantitative analysis allows the system architect to examine the performance of different partitions between different numbers and types of ECUs , evaluate the tradeoffs and determine the best implementation.

The virtual platform has the reusability of both hardware and software to integrate various existing functions.