Lines of code
Productivity (lines per day)
Residual defect rate (ppm)
Rate of subsystem change (years)
Development effort (staff-years)
Validation time (months)
Time to market (months)
AUTOMOTIVE ELECTRONIC DESIGN
Table 1. Characteristics of embedded software for automotive subsystems.
Power train unit
languages such as C or mathematical equa- tions. Typically, designing an algorithm requires modeling the relevant part of the environment—the part the algorithm will control—and abstracting the behavior of the remaining part of the system.
The result of the software design specifica- tion phase is an algorithm described as a sin- gle block or a hierarchical subnetwork. Algorithm development proceeds in either a top-down (designing new algorithms) or bot- tom-up (use of previously defined IP) fashion. Given the same system requirements, differ- ent algorithms can correctly implement the system functionality. Designers explore these different solutions during this phase. Using functional design tools such as the MathWorks toolset (Matlab and Simulink)3 to capture the algorithms and perform simulation on a math- ematical model is a growing trend.
Designers implement the algorithms in a selected architecture as software modules or hardware components. Architecture selection is often an ad hoc process based on experience and extrapolation from existing products. Selecting the ICs for an ECU involves a search among IC providers active in the automotive arena. The selection often depends more on commercial relations among companies than on a technical assessment of performance- price ratio.
If the architecture has problems meeting the constraints, designers can adjust it during the design phase. Developers provide new software needed for novel features by “growing” it over existing modules. Starting from an existing, proven module and tweaking it to provide the
new features limits the risk of malfunction. Extensive experimentation on rapid- prototyping systems or actual cars is the pre- ferred way to verify the system’s correctness.
Software architectures are often old- fashioned and difficult if not impossible to port from one platform to another. The soft- ware is not cleanly partitioned into applica- tion code, communication, design drivers, and basic I/O system (BIOS). The exponen- tially growing complexity of features for soft- ware implementation makes the problem of embedded-software design a serious obstacle to new car development. Table 1 presents a typical set of productivity and quality indica- tors for automotive embedded software.
The most advanced first-tier suppliers have restructured their code so that porting is no longer difficult and expensive, thus opening new possibilities for cost reduction and per- formance improvement. In addition, many of these companies are using capture tools such as Simulink, Statecharts, and ASCET-SD (Advanced Simulation and Control Engineer- ing Tool-Software Development)4 for auto- matic code generation from algorithmic specifications given in structured form, Although automatic code generation solves the problem of designing software that correctly represents a given functionality, it does not solve the timing problem. The code’s timing depends on the tasks to be handled by the RTOS, the scheduling polic , and the ECU’s performance. Several companies offer sched- uling-analysis tools, which compare different scheduling policies (for example, cooperative and preemptive versus preemptive only) to determine a usable software architecture. Designers can perform static scheduling-policy