analysis offline—for example, using rate monotonic analysis—or dynamic analysis online via interactive simulation. The analysis relies on time budgets (task periodicity and task execution times) provided by the designer.
Once the first-tier suppliers deliver their subsystems, the carmaker integrates them in the car. This step would be difficult without tools that help analyze a subsystem’s behavior and performance before a prototype car is available. Such tools are mainly company internal. For example, the BMW flow exports design data to a proprietary database, Board- net, a customized version of the Oracle data- base. Designers then use the Boardnet data to configure downstream tools for emulation and measurement of the communication protocols (for example, a TTP-cluster prototype board).
In the calibration phase, designers or engi- neers tune a subset, or calibration set, of the behavior IP’s control and regulation parame- ters (typically, control algorithms) to obtain the controlled system’s required performance. This phase also involves tuning the overall sys- tem functionality parameters. Designers define the calibration set by selecting the tun- able parameters (characteristic values, curves, and maps) during the control algorithm spec- ification phase.
Calibration performed on test cells (instru- mented benches) and test tracks (autodromes where drivers test prototype cars) is a very expensive process. Today, calibration engi- neers are more numerous than designers, an indication of the state of the design method- ology currently in use. Expensive tools to facil- itate calibration are available from companies such as ETAS and dSpace.
Problems This design flow poses several problems:
Lack of continuity. There is a communi- cations gap between requirements analy- sis and functional network definition, and between software development and overall architecture netlist definition.
Long turnaround time. Designers validate the solution only on the car or (at best)
with prototyping hardware very late in the design cycle. Software development can start only when a hardware prototype is available, and then only for a single ECU.
Suboptimal and overly conservative solu- tions. Because the flow supports a per- ECU design style, design exploration concentrates on different scheduling poli- cies, not on the overall distributed system, including communication protocols.
Obviously, these problems seriously affect development and production costs. Accord- ing to OSEK:
Vehicle manufacturers traditionally focus on production cost rather than on development cost—the sensors and the actuators, along with the bare ECU, represent almost the entire cost for electronics in the car. How- ever, although software does not have a “production” cost, it is not for free! The soft- ware development costs are skyrocketing: toda , they are about twice as much as the development costs for hardware.2
Overall system design exploration is possi- ble only if the integration step takes place at the virtual level, not on the car as is the cur- rent method. Indeed, the entire automotive industry is trying to move tests from cars to labs that can emulate or simulate real condi- tions at a much lower cost. (The cost of set- ting up an experiment on a car is $120 to $500 per hour. The setup time is about one hour. Engineers can perform about two tests each day.)
Using a virtual environment rather than prototyping hardware for design and test can significantly reduce development and pro- duction costs. If designers could simulate the distributed application on their host work- stations rather than a test track, they could repeat tests after every design change. Flexi- bility is another advantage: A virtual envi- ronment would more easily support derivative designs (variants), and waiting for the next hardware prototype to run the application software would become unnecessary. Hence, car manufacturers would achieve their time- to-market and cost reduction goals. According to a BMW management source in a personal communication: