Design Article
VSPs spur on-time delivery of embedded automotive systems software: Part 2
Elof Frank, <a href="http://www.vastsystems.com/">VaST Systems Technology Corp.</a>
10/24/2006 6:38 PM EDT
In developing for quality versus testing for quality, Schubert, Vitkin, and Winters note [Ref. 4], "In a traditional design approach, system requirements are verified at the conclusion of a design cycle, typically after the atomic subsystems have been integrated up through successive levels of abstraction until the system is complete. In some cases, for example when delivery schedules are compressed, the subsystems are often verified after the design, implementation and build process, not during."
"The obvious drawback of this approach is the late discovery of higher-level errors in either the derived requirements or the implemented design. In a traditional development, the algorithm is a passive component of test environment: It executes the functionality-based input stimulus and produces the output results. The problem is that those input stimuli are developed to verify the correctness of the requirements. They do not typically cover all 'abnormal' behavioral conditions."
"In model-based development, a model is an active component and a source for the generation of model-coverage test scenarios. The combination of functionality-based input stimulus and model-coverage based input stimulus create a complete test environment for rigorous validation of the model and verification of software implementation at each step of development."
The first example to be discussed here [from Ref. 5] is a virtual system prototype of a single-unit, rollover detection ECU, which displays remarkable results:
Benefits of using a virtual system prototyping approach for this rollover detection unit are:
Applicability to a multicontroller, distributed auto control platform
A VSP for a system comprised of multiple controllers on a distributed automotive control platform (below) differs almost completely from the above example in that it represents a network of automotive ECUs, each of which would resemble an architecture similar to the rollover example above. However, control and safety functions require specific hard real-time constraints on the communication protocols which need to be extremely well understood. To meet these requirements, the time-triggered protocols implemented on CAN-TT and FlexRay buses are increasingly being deployed.
The purpose of modeling such a system is to determine the required bandwidth and latency of the interconnect structure and the computation attributes and capabilities of the control units—under both extreme and average conditions. If the engine controller and the suspension controller each formed part of a distributed stability controller for a car, then safety, reliability, and the requirement to meet real-time schedules must be established under the harshest conditions.
It should be noted that experiments performed on the model are able to cover many more cases than testing using a physical artifact. This is a surprising result to most engineers. But the controllability of a model and the ability to configure extreme situations, as well as the ability to run data acquired from a physical artifact through the model, enable the undertaking of more comprehensive testing.
Often this testing on the VSP is in real time—sometimes even faster than real time-—because most subsystems in a car have relatively slow response rates to events. The exception is in power train which will require multi-host simulation capability.
The contrast between the two examples above provides an interesting insight into the modeling required of processor interconnects and devices, as well as the wide variety of characterization of objective functions and experimentation required to drive optimization.
One constant, however, remains. Models need to be timing-accurate and high-performance to be used for architectural experimentation and for developing software for real-time control systems. Software developed on inaccurate or incomplete models cannot be guaranteed to run on silicon; such models cannot guarantee anything about real-time capabilities such as meeting of hard schedules, power consumption, performance, bandwidth, and throughput.
|
|
|
|
|
