Part 1 dealt with the nature of the automotive software proliferation problem and leveraging modeling methods to solve it.
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:
The virtual system prototype (VSP) is capable of running the same compiled and linked target code as the physical hardware. In addition, the VSP is cycle accurate in order to analyze the real-time criteria associated with automotive electronic applications.
The virtual system prototype that was created for this project is capable of reading actual vehicle crash data into the simulation environment; it can be used to verify system-level serial communications performance; it allows for fault injection; and it provides a scripting environment used to enhance product level testing.
The peripheral models were all programmed to warn the software developers of incorrect usage in respect to specification. This is one of the many powerful features of VSPs that hardware prototypes simply cannot deliver. The table below shows some of the problems that were immediately exposed while developing the software.
Using the VSP also allowed the development team members to highlight several specification issues where the design needed to perform differently than the original requirements.
Finally, because VSPs are cycle-accurate for all portions of the virtual system, virtual system prototyping provided the capability to gather system performance data to enable product-level improvements.
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.
View a full-size image
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 unitsunder 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 timesometimes 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.