See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/3215317

Electronic-system design in the automobile industry

Article in IEEE Micro · June 2003

DOI: 10.1109/MM.2003.1209462 · Source: IEEE Xplore

CITATIONS READS
33 1,473

1 author:

Alberto Sangiovanni Vincentelli

University of California, Berkeley
368 PUBLICATIONS 13,168 CITATIONS

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Metropolis View project

Real-Time Control Containers View project

All content following this page was uploaded by Alberto Sangiovanni Vincentelli on 01 April 2015.

The user has requested enhancement of the downloaded file.

 ELECTRONIC-SYSTEM DESIGN IN
THE AUTOMOBILE INDUSTRY
ELECTRONIC COMPONENTS ARE NOW ESSENTIAL TO CONTROL A CAR’S
MOVEMENTS AND CHEMICAL, MECHANICAL, AND ELECTRICAL PROCESSES;

TO PROVIDE ENTERTAINMENT AND COMMUNICATION; AND TO ENSURE

SAFETY. A NEW, PLATFORM-BASED METHODOLOGY CAN REVOLUTIONIZE THE

WAY A CAR IS DESIGNED.

With the advent of highly powerful parts such as injectors and throttle bodies.
microprocessors, the explosion of wireless These subsystems contain ICs from second-
communication, and the development of new tier suppliers such as Motorola, Texas Instru-
generations of integrated sensors and actua- ments, Hitachi, and ST Microelectronics.
tors, the way electronic products are con- They also contain intellectual property (IP)
ceived, designed, and implemented has from various second-tier suppliers such as the
undergone a revolution. In addition, the elec- WindRiver and ETAS software companies. In
tronics industry is undergoing a major restruc- general, the subsystem volumes are large, cost
turing that favors horizontal integration and being a major driving force.
vertical disintegration. In this framework, col- Once car manufacturers receive the subsys-
laboration among different industry segments tems, they must integrate them in the car and
Alberto Sangiovanni- is essential to bringing new products to mar- then test the overall system. If they detect
ket. In particular, system companies are shift- errors through extensive testing, which
Vincentelli ing electronic-component research and includes driving under extreme conditions,
development costs to semiconductor compa- they initiate a chain of engineering changes
University of California at nies, which therefore must significantly that often causes major delays in the design
increase their system design competence. process. The problems are traceable to soft-
Berkeley Recent International Business Strategies mar- ware errors, misunderstanding of the specifi-
ket studies show that more than 50 percent of cations, and unpredictable side effects of
design activities that move to the 0.09-micron interconnecting the subsystems. This design
technology node will be in software.1 Thus, process loop is particularly painful because it
the semiconductor design problem becomes a occurs when the car is almost ready for its
system solution problem. market launch.
Today, European automobile manufactur- Car manufacturers increasingly realize the
ers provide specifications to first-tier subsys- importance of electronics in their business.
tem suppliers such as Bosch, Siemens, and According to Daimler-Chrysler sources, more
Magneti-Marelli, which design software and than 90 percent of the innovation (and hence
hardware subsystems that include mechanical value added) in a car is in electronics. Accord-

8 Published by the IEEE Computer Society 0272-1732/03/$17.00  2003 IEEE

ing to BMW, electronic components comprise the most short- to medium-term profits. Cus-
more than 30 percent of a car’s manufacturing tomers now often base buying decisions on
cost. The trend in the car manufacturing the infotainment environment more than
industry is to acquire more in-house elec- engine performance and handling. Hence, the
tronics competence to capture added value question arises: What will constitute a car
that previously went to subsystem suppliers. company’s core competence? Will the elec-
The strategy calls for software and hardware tronic components be the car and the
standards that will facilitate plug-and-play mechanical components an accessory?
subsystems, reducing the strategic importance For car manufacturers, system design is def-
of any single subsystem supplier. The Offene initely the most important technology they
Systeme und deren Schnittstellen für die Elek- must master to improve the quality and
tronik im Kraftfahrzeug (open systems and increase the value of their cars’ electronic com-
corresponding interfaces for automotive elec- ponents. Designers of automotive electronic
tronics), or OSEK, operating system require- systems need a methodology that focuses on
ments are an example of this policy.2 Clearly, two main principles: separation of concerns
however, without an overall understanding of and platform-based design.
the interplay of subsystems and the difficul-
ties of integrating highly complex parts, sys- Electronic-system design issues
tem integration is increasingly a nightmare for To support the electronic-design chain, sys-
car manufacturers. In addition, subsystem tem designers in the automobile industry
suppliers are trying to enlarge their perimeter must establish a new design flow. Clean inter-
of competence to capture more added value. faces and unambiguous specifications are
Automobile electronics comprises three essential parts of this design flow. In addition,
basic domains: the design flow must address the thorny issue
of IP protection. This is even more important
• power train management—for example, in the automotive domain than in other
electronic control units (ECUs) that con- industrial segments because the automotive-
trol ignition timing and the amount of supplier chain is deeper.
fuel injected into the cylinders; The following issues are likely to determine
• body electronics—for example, ECUs the preferred approaches to the design and
that control dashboard displays, suspen- implementation of complex embedded sys-
sion settings, and temperature; and tems in the automotive domain (and others):
• information processing, communication
with the outside world, and entertain- Reuse. Design time and cost will dominate sys-
ment (often called the telematics or info- tem designers’ decision-making process.
tainment system). Therefore, design reuse of all kinds, as well as
just-in-time, low-cost design debugging tech-
The first domain is typical of any trans- niques, will be highly important. Design flex-
portation system and is characterized by tight ibility is essential to mapping an ever-growing
safety and efficiency constraints. Its core com- functionality onto a continuously evolving set
petence is control algorithms, along with soft- of associated hardware implementation
ware and mechanical-electrical hardware options.
design and implementation.
The body control domain involves the High levels of abstraction. Designers must cap-
management of a distributed system that ture designs at the highest abstraction level to
increasingly resembles a network with proto- exploit all the available degrees of freedom.
cols likely to have different requirements than This abstraction level should not distinguish
standard communication protocols. Guaran- hardware from software, since this distinction
teed services are the essence of this domain. is the consequence of a design decision.
A car’s infotainment system is the product
of industrial domains that are progressing in Concurrency. The implementation of efficient,
the technology race at a faster rate than the reliable, and robust approaches to the design,
automotive domain. This domain can reap implementation, and programming of con-

MAY–JUNE 2003 9
 AUTOMOTIVE ELECTRONIC DESIGN

current systems is essential. Whether imple- flexibility. A platform has much wider applic-
menting the silicon as a single, large chip or a ability than an application-specific IC (ASIC),
collection of smaller chips interacting across a so design decisions are crucial. A less than
distance, designers must deal with concurrent excellent choice can result in an economic
processing and communication in a uniform debacle. Hence, design methods and tools that
and scalable manner. In any large-scale optimize the platform selection process are
embedded system, designers must consider very important.
concurrency a first-class citizen at all abstrac-
tion levels and in both hardware and software. Software programmability. Platforms will be
highly programmable at various granularity
Separation of concerns: communication and levels—at instruction level for microproces-
behavior. Concurrency implies communica- sors, at gate level for field-programmable gate
tion among design components. Communi- array (FPGA) blocks. Consequently, mapping
cation is too often intertwined with design an application into a platform efficiently will
component behavior, making it difficult to require a set of software design tools that
separate the two. Separating communication resemble logic synthesis tools. This will be a
and behavior is essential to handling system fruitful research area.
design complexity. It is difficult to reuse com-
ponents if their behavior depends on com- Current automotive system-level design
munication with other components of the Automobiles’ real-time and safety-critical
original design. In addition, because design- electronics systems are implemented as dis-
ers can describe communication at various tributed architectures that typically include
abstraction levels, they can potentially imple- several ECUs communicating via one or more
ment communication behavior in many networked broadcast buses. These buses are
forms according to the available resources. controlled by communication protocols such
Today, designers seldom exploit this freedom. as controller area network (CAN), time-trig-
gered protocol (TTP), local interconnect net-
Multple chips. Next-generation systems will work (LIN), and FlexRay.
probably use a few highly complex (Moore’s Each ECU includes
law–limited) part types, and many more ener-
gy- and power-efficient, medium-complexity • application and diagnostic software;
chips (with 10 million to 100 million gates in • base software—for example, real-time
50-nm technology). All these chips will work operating system (RTOS) and commu-
concurrently to solve complex sensing, com- nication layers;
puting, signaling, and actuating problems. • one or more microcontrollers with local
memories and bus controllers with one
Platform-based design. System developers will or more channels, to support redundan-
most likely develop these chips as instances of cy for fault-tolerant systems and complex
a particular platform. That is, rather than bus architectures such as constellations
assembling the chips from a collection of inde- and star couplers; and
pendently developed blocks of silicon func- • optional dual-ported RAMs for com-
tionality, system developers will derive them munications between bus controllers and
from a specific microarchitecture family, or microcontrollers and between CPUs
platform, possibly aimed at a particular class within the same ECU.
of problems. System developers can modify
(extend or reduce) these platforms. The plat- Automotive applications (such as control
forms will support extensibility mainly systems for steering and braking) have intro-
through the use of large blocks of functional- duced a new design dimension—the system’s
ity (for example, in the form of coprocessors), distributed nature—that adds complexity yet
but they will support extensibility in the mem- also provides the potential for optimizations
ory and communication architecture as well. such as reducing the number of ECUs needed.
When selecting a platform, designers must In fact, better use of each ECU potentially
consider cost, size, energy consumption, and reduces the number of ECUs in a distributed

10 IEEE MICRO
architecture. (Redistribution
is not always possible because Requirements Vehicle
some applications tie the soft-
ware to a specific ECU.) In a
nutshell, the design problem
for automotive applications Functional Calibration
consists of distributing a pool system analysis (lab car)
of functions over the target
architecture to satisfy cost,
safety, and real-time operating System design Communication
requirements. Because these partitioning subsystem
testing
applications are distributed,
designers must accurately
model the communication Software
Software design
protocol. A by-product of the specification
integration
testing
methodology described here
is that designers can experi-
ment with new protocol con-
figurations. Implementation
Figure 1 illustrates the typ-
ical “V” design flow for auto-
motive distributed systems. Figure 1. Typical “V” design flow for automotive distributed systems.
The development process
starts with the functional sys-
tem analysis phase, in which the system The first-tier suppliers analyze the specifi-
designer develops a functional network (the cations and negotiate the terms of the con-
overall system behavior). The system design tract. The car manufacturer’s specifications
partitioning phase determines the distribu- might also include implementation require-
tion of functions in an architectural network. ments, thus restricting the suppliers’ design
In the software design specification phase, the space. For example, sometimes the contract
system designer defines algorithms for each lists particular microcontrollers to use. In
functional component. The implementation addition, there is a growing trend for car man-
phase maps a composition of functional com- ufacturers to use internally developed software
ponents onto the target hardware. The instead of relying fully on first-tier suppliers.
upward part of the “V” design flow represents To ease integration, communication standards
the verification process, including testing the such as TTP and FlexRay provide clean
implemented architecture’s software integra- semantics and guaranteed behavior. An
tion, verifying the communication subsystem, OSEK-compliant operating system also eases
and calibrating the system in the car. integration.
Without a rigorous design methodology
Specification that can deal with heterogeneity, specifications
The car manufacturer is responsible for at different abstraction levels always cause
overall functionality, whereas the first-tier sup- problems. For first-tier suppliers, integrating
pliers deliver control algorithms and hardware. other suppliers’ software modules is a severe
The carmaker specifies system functionality problem, especially for hard real-time systems.
on the basis of an overall analysis of desired car
performance and features and decomposes this Algorithm development
functionality into subsystem specifications sent For safety-critical applications, the design
to first-tier suppliers. Expert designers perform of control algorithms that satisfy the func-
this decomposition, using their experience and tional requirements is a critical step for both
sometimes prototypes (lab cars). They almost car manufacturers and first-tier suppliers.
always write specifications informally in nat- Recently, manufacturers and first-tier suppli-
ural language in a contract. ers have developed control algorithms using

MAY–JUNE 2003 11
 AUTOMOTIVE ELECTRONIC DESIGN

Table 1. Characteristics of embedded software for automotive subsystems.

Characteristic Power train unit Body gateway Instrument cluster Telematic unit
Memory (Kbytes) 256 128 184 8,000
Lines of code 50,000 30,000 45,000 300,000
Productivity (lines per day) 6 10 6 10*
Residual defect rate (ppm) 3,000 2,500 2,000 1,000
Rate of subsystem change (years) 3 2 1 <1
Development effort (staff-years) 40 12 30 200
Validation time (months) 5 1 2 2
Time to market (months) 24 18 12 <12
* C++ code

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

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

MAY–JUNE 2003 13
 AUTOMOTIVE ELECTRONIC DESIGN

Requirement specification

Algorithm specifications

Environment or
Algorithm analysis Algorithm design test bench modeling

Algorithms

Virtual prototyping
Behavioral modeling Architectural modeling

Architecture
Behavior Architectural IP
IPs IPs authoring

Mapping

Distributed
architecture analysis

ECU Synthesis
System
scheduling analysis export
model
Algorithm Physical protoyping
performance
Software Software Communication
platform tasks Load
protocol
configuration
Performance simulation

Compile, link, Physical

load prototype

Figure 2. Design flow of the new methodology.

One of the focuses and values of a system- embody the concept of virtual integration
level design methodology and tool set is platforms.5 (A functional network includes
that redundancy and fail-safe system tests the overall system functionality with the def-
can be repeated after every change in the inition of subsystems and their interfaces inde-
design. However, a valuable use of any pendent of the target architecture and
methodology and tool set is only possible hardware and software architectures.)
if interfaces to the approved and existing
BMW development methods and tool New design methodology
chains (from specifying functionality to Figure 2 illustrates a new design methodol-
implementing it onto an ECU) are sup- ogy developed by automotive and tool com-
ported by the flow. panies and academic institutions including
BMW, Cadence, ETAS, dSpace, the Project
This comment summarizes well why a design for Advanced Research of Architecture and
methodology must accommodate existing Design of Electronic Systems (Parades), Mag-
tools that have become de facto standards. neti-Marelli, and the University of California
Finding design errors and near-optimal at Berkeley.5 The methodology includes three
functional networks as early as possible in the main steps: algorithm specification, virtual
design process requires novel design method- prototyping, and physical prototyping. It
ologies and integrated tool environments that assumes that the designers, given an informal

14 IEEE MICRO
specification of the subsystems, can specify environment, of complex human-
the requirements in a semiformal language machine interactions, and of test bench-
such as the Unified Modeling Language es that provide stimuli to the system
(UML). The overall behavior (functional net- under test are also necessary. Designers
work) and architecture netlist of the distrib- either import these models from tools
uted system constitutes the output of this such as MathWorks Simulink or author
specification phase. them within the system.
This methodology supports the entire auto-
motive electronic design chain. Carmakers Advantages
specify the overall system to the first-tier sub- The new methodology makes a major shift
system suppliers, who develop algorithms and to an integrated design style in which design-
implementations in software and hardware ers model the entire ECU network along with
platforms. The second-tier suppliers, semi- the application and base software used to cus-
conductor and software companies, develop tomize the platform for a particular car series.
components of the hardware platform and Integration takes place at the virtual level.
software. Carmakers use the virtual platform of Automatic configuration of tools for protocol
the overall electronic system to validate their analysis and implementation is based on the
partitioning and specification, and subsystem results of simulations of the virtual model. For
suppliers use it to ensure that their compo- example, once a designer has decided how to
nents work as expected when integrated. distribute the pool of functions among the
In this methodology, the model-based soft- ECUs, a downstream code generation tool can
ware design approach is important. Through use this information (number of tasks needed,
synthesis export, a model described in func- scheduling policies, and so on) to generate the
tional terms migrates to an efficient software RTOS scheduler. At the same time, designers
implementation. The subsystem supplier configure the downstream tools for commu-
develops most of the software, but carmakers nication protocol analysis, using the configu-
are developing an increasing amount of criti- ration data determined at the virtual level
cal software and can benefit substantially from (type of protocol, frame packaging, commu-
this approach. nication cycle, and redundancy management
The new methodology’s key distinctions are policies). Thus, a step that is currently man-
its use of the following: ual or that requires intensive user intervention
(for example, the designer must explicitly
• Virtual platform. A virtual platform sup- specify messages sent over the network bus) is
ports system testing and prototyping automatic in the new flow.
(hardware-software architecture) via In the new methodology, timing estimation
simulation. takes place in the earliest design phases, before
• Virtual application models. Virtual mod- implementation. Typical estimates are for soft-
els of the application software and the ware task execution times and network com-
target hardware-software architecture munication latencies. These estimates might
(bus controllers, CPUs, RTOS sched- shorten algorithm and platform (single ECU
ulers, and communication protocols) let or network) exploration considerably. Estima-
designers create a virtual prototype of the tion models can be provided by the subsystem
entire distributed application. Designers supplier or developed by the system designer
import the application software models for use as a specification to the supplier.
from previous designs or write new soft-
ware for the system under development. Platform-based design paradigm
Designers develop the architectural mod- Figure 3 depicts the core of the new
els within the virtual models (for exam- methodology as an instance of platform-based
ple, a communication protocol model), design, a paradigm shift in design, verifica-
using a standard C++ application pro- tion, and testing. The platform-based design
gramming interface. paradigm is a meet-in-the-middle approach. It
• Other virtual models. Besides virtual leverages the power of top-down methods and
application models, virtual models of the the efficiency of bottom-up methods. The

MAY–JUNE 2003 15
 AUTOMOTIVE ELECTRONIC DESIGN

design process is the stepwise refinement of a

Application space specification into a lower-level abstraction
Application instance chosen from a restricted library, or platform,
of available components. Components are
computational blocks and interconnections.
In this view, a platform is a design family,
Platform not a single design. A platform defines the
mapping
explorable design space. Once we select a par-
ticular collection of platform components, we
System platform obtain a platform instance. As Figure 3 shows,
(hardware and software)
Platform
we can obtain multiple platform instances in
design space refining a platform. The choice of the plat-
export form instance and the mapping of the speci-
fication components defining the application
of interest into the platform instance compo-
nents constitute the top-down process. This
Platform instances process maps constraints accompanying the
Architectural space specification into constraints on the platform
instance components. Platform mapping
Figure 3. Platform-based design. often involves budgeting because we might
have to distribute a global constraint among
a set of components.
Stepwise refinement continues by defining
Application the selected platform instance as a specifica-
tion and using a lower-level platform to march
Programming model: Kernels or toward implementation. When a component
models or estimators benchmarks is fully instantiated, stepwise refinement stops,
because the designer then has an implemen-
tation for that component.
Architecture(s) In selecting a platform instance and map-
ping constraints using budgeting, it is impor-
Articulation point Architectural platform
tant to guide the selection with parameters that
Microarchitecture(s) summarize the platform component charac-
teristics. Delay, power consumption, size, and
cost are examples of such parameters. When
Functional blocks, selecting a platform instance, the designer must
Cycle speed, power, area
interconnect quickly and accurately evaluate the design’s
potential performance. Thus, the selection of
the guiding parameters is a critical part of plat-
Circuit fabric(s) form-based design. In Figure 3, this process is
Articulation point Silicon implementation platform
called platform design space export.
It is possible to automate the selection of
Manufacturing interface components and the verification of consisten-
cy between the specification behavior and the
platform instance behavior. To do so, design-
Delay, variation, Basic device and ers must find a common semantic domain
Spice models interconnect structures
between the behavior and the platform so that
the selection process becomes a covering prob-
lem—that is, the selection of platform com-
Silicon implementation
ponents is an effort to cover the entire design
functionality with one or more platform ele-
Figure 4. Platform stack. ments. The concepts of platform-based design
can apply to the entire design process, even

16 IEEE MICRO
with an ASIC design style. The framework is Our first task was to extract the precise func-
the same; the platforms are different. The tionality from the implementation. To do this,
number and location of platforms in the we used a representation based on the Code-
design abstractions, the number and type of sign Finite-State Machine network, the com-
components that constitute a platform, and putation model used in the Virtual
the choice of parameters to represent the com- Component Codesign (VCC) development
ponents are critical aspects of this method. environment,7 resulting in 89 CFSMs and 56
As Figure 4 shows, platforms form a stack timers. We completely rewrote the behavior
from the design specification defined in the of the actuators and some of the sensors in the
application domain to implementation. Some formal model. For the ignition and injection
platforms demark boundaries critical in the control law, we encapsulated the legacy C code
electronics supply chain. These articulation into 18 CFSMs representing concurrent
points warrant particular attention. We call an processes. We redesigned the software to make
architecture platform the articulation point mapping into different microarchitectures rel-
between system architecture and microarchi- atively easy. In particular, we tested three dif-
tecture. Microarchitecture is a platform whose ferent CPUs and, for each, two different
components are architectural elements such as software partitionings, to verify functionality
microprocessors, memories, and interfaces. and real-time behavior. In addition, we
This articulation point is where the application explored three different architectures for the
engineer maps a design into a physical struc- I/O subsystem: one with a full software imple-
ture. To find a common semantic domain, the mentation, one that used a peripheral (pro-
application engineer must abstract these com- vided by the CPU vendor) for timing
ponents via an operating system, device drivers, functions, and one with a newly designed,
and a communication mechanism. The hard- highly optimized full-hardware peripheral.
ware components support the execution of the Performance estimation based on VCC
specification behavior. Another essential plat- resulted in an error of only 11 percent, com-
form is the one that corresponds to the layer pared with a prototype board containing real
between design and manufacturing—the hardware. We implemented functionality on
implementation platform. three platforms, resulting in software reusabil-
ity of more than 86 percent. We also used the
Application example functionality captured in semiformal terms to
Fellow researchers and I are testing the new design a new dual-processor architecture being
methodology in advanced industrial environ- sampled at STMicroelectronics.8 MICRO
ments. For example, consider an ECU design
carried out in collaboration by Parades, Mag-
neti-Marelli, and STMicroelectronics.6 This
design has a strong control component and
I n considering the future of electronic
devices and infrastructures as they affect the
car manufacturing and design world, the
tight safety constraints. In addition, the appli- issues related to choice and design of inte-
cation contained a large portion of legacy grated platforms are crucial. A rigorous design
design. The electronic engine control subsys- methodology based on separation of concerns
tem’s functionality comprises the following (function and architecture, function and com-
elements: munication) and platforms is essential. The
challenges ahead are great, but the opportu-
• failure detection and recovery of input nities are enormous. The automobile industry
sensors; is on the edge of a revolution in the way it
• computation of engine phase, status, and conceives and designs a car. MICRO
angle; crankshaft revolution speed; and
acceleration; Acknowledgments
• injection and ignition control law; and I thank the Parades researchers and the
• injection and ignition actuation drivers. Cadence Automotive Tiger Team—in particu-
lar, A. Ferrari, M. Chiodo, P. Giusto, L.
The existing implementation had 135,000 Lavagno, and J.Y. Brunel—for their contribu-
lines of C source code without comments. tions to the vision presented here. This research

MAY–JUNE 2003 17
 AUTOMOTIVE ELECTRONIC DESIGN

was supported in part by Parades, the Gigascale nent Codesign (VCC), www.cadence.com.
Silicon Research Center, and the IST Columbus 8. A. Ferrari et al., The Design and
Project of the European Community. Implementation of a Dual-Core Platform for
Power-Train Systems, SAE Tech. Paper
References 2000-01-C050, Society of Automotive
1. H. Jones, Monthly Report on Semiconductor Engineers, 2000.
Industry, Jan. 2003, International Business
Strategies, Inc. Alberto Sangiovanni-Vincentelli is a guest
2. OSEK, www.osek-vdx.org. editor of this issue. His biography appears on
3. MathWorks/Simulink, www.mathworks.com. page 9.
4. ETAS ASCET-SD Homepage, www.etas.de.
5. P. Giusto et al., “Automotive Virtual Integra- Direct questions and comments about this
tion Platforms: Why’s, What’s, and How’s,” article to Alberto Sangiovanni-Vincentelli,
Proc. Int’l Conf. Computer Design (ICCD 02), University of California at Berkeley, 515 Cory
IEEE CS Press, 2002, pp. 370-378. Hall, Berkeley, CA 94720-1770; alberto@
6. G. Bombarda, G. Gaviani, and P. Marceca, eecs.berkeley.edu.
Power-Train System Design: Functional and
Architectural Specifications, SAE Tech.
Paper 2000-01-C049, Society of Automotive For further information on this or any other
Engineers, 2000. computing topic, visit our Digital Library at
7. Cadence Design Systems, Virtual Compo- http://computer.org/publications/dlib.

Computer IT Professional
Agile Software Development Financial Market IT
Piracy & Privacy IEEE Micro
IEEE Computer Graphics & Applications Hot Chips 14
3D Reconstruction & Visualization IEEE MultiMedia
Computing in Science & Engineering Computational Media Aesthetics
The End of Moore’s Law IEEE Software
IEEE Design & Test Software Geriatrics:
Clockless VLSI Design Planning the Whole Life Cycle
IEEE Intelligent Systems IEEE Security & Privacy
AI & Elder Care Digital Rights Management
IEEE Internet Computing IEEE Pervasive Computing
The Semantic Web Smart Spaces

18 IEEE MICRO

View publication stats