Case study of design of an Engine Control Unit
Maunendra Sankar Desarkar
Mausoom Sarkar
Palak Agarwal
Varun Khaneja
Department of Computer Science and Engineering
Indian Institute of Technology Kanpur
Kanpur, India 208016
{msds, mausoom, palak, kvarun}@cse.iitk.ac.in
Abstract
Embedded System design has recently been the area of a lot of research. A lot of techniques and
software tools have been proposed and implemented but even today they are not being used extensively.
Embedded System design is done based on past experiences of the designers. To improve the state of the
art, it is important to bring to light, the usefulness of formal techniques by applying them on real-world
design problems and match the results.
We chose to study the re-design of an embedded system from the automotive industry, an Engine
Control Unit (ECU), to validate the formal design methodologies. We discuss the speciļ¬cation, imple-
mentation issues and architectural trade-oļ¬? analysis.
1 INTRODUCTION
An embedded system is deļ¬ned as āA system designed to perform a single well deļ¬ned function life-long.
It is generally subject to real-time constraintsā[1]. Applications of embedded systems range from home to
oļ¬ce, to automotive and avionics industries. Simple devices like calculator to complex devices like navigation
systems are all applications of embedded systems. Traditional design methodologies for designing embedded
systems are generally based only on past experiences of the designing team. Therefore, generally, these
approaches lack system vision and uniļ¬ed hardware/software representation. The hardware and software
components are designed in a manner that ignores the interdependence between them.
Hardware/Software Co-design and lately proposed embedded system design techniques advocate the use
of formal techniques for the design of the system. These techniques take decisions based on unbiased
speciļ¬cation, simulation-based validation, various forms of automated partitioning and module and interface
synthesis.
However, the resistance to the use of formal techniques comes from the designer community, which does not
want to take any risk because of the typical nature of embedded system applications, which are severely
constrained by safety concerns, cost factor, time to market, reliability, performance, time guarantees etc.
We chose to study and discuss the re-design of an Engine Control Unit (ECU) for a commercial vehicle and
demonstrate the usefulness of formal design techniques and software tools. This also provided us a measure
to compare the results obtained with the formal design methodology with the present implementation in
terms of performance and design time.
2 Description of the Engine Control Unit
āThe Engine Control Unit (ECU) is the brain of the engine. Inputs such as speed, temperature, pressure
and pilot throttle are used to ensure the required fuel ļ¬ow for the given set of inputs.āā?[2] Engine Control
1
Units control the operating parameters, to make sure that the engine gets proper inputs. Thus, they help
protect the engine against damage. The use of advanced micro-processors and comprehensive software helps
increase the engine life and ensure safety.
Figure 1: Components of an ECU
Figure taken from[3]
An ECU consists of a set of sensors, a processing unit and a set of actuators. The sensors periodically
measure the engine status and provide input to the processing unit which processes this data, takes some
decision and drives the actuators accordingly. The actuators execute the commands received from the control
unit. The processing unit operates upon a control strategy to optimize the fuel injection and ignition so
that it minimizes fuel consumption and emissions of pollutants and maximizes the torque and power. But
as these issues are usually competing, both of them can not be met simultaneously. So there is a trade-oļ¬?
between these issues, and the system tries to ļ¬nd the best compromise depending on the particular situation.
Various kinds of inputs parameters may be used. Some of the most important are
ā? Vehicle speed
ā? Vehicle acceleration or deceleration
ā? Temperature
ā? Air pressure
ā? Throttle position center
Controlling the injection and ignition of the fuel are the two main tasks of an ECU. These can be controlled
dynamically. The control speciļ¬cations of these tasks are described below:
ā? Injection : In order to burn the fuel completely and correctly, the ratio between air and the fuel which
go into the piston should be kept constant (approximately 14.7 for Gasoline). This ratio is maintained
by the ECU by controlling the opening time of each injector.
ā? Ignition : The fuel should get enough time to burn completely. To let this happen, the spark has
to be ļ¬red in advance with respect to the instant when the piston is at its highest point. Moreover,
this parameter also aļ¬?ects the emissions since unburnt fuel is pushed out of cylinder as emission or
pollution. The timing diļ¬?erence between fuel injection and ļ¬ring of spark is maintained by monitoring
engine RPM.
The control strategies are handled by the Control Layer in an optimal manner.
The Signal Acquisition Layer accepts data from the engine in raw format i.e. in the form of voltage levels,
pulse frequency or pulse width. It then transforms these signals into numerical values. During signal
2
Figure 2: Functional Architecture of ECU
Figure is taken from[4]
acquisition, open- and short-circuits may occur. These conditions are checked by accepting the input values
only within pre-deļ¬ned limits. In case any error is detected, a DAMAGE signal is generated. The Signal
Actuation Layer acts as directed by the Control Layer.
The Device Driver Layer acts as an interface between the acquisition and actuator layers. This helps in
achieving processor independence.
The RTOS Layer coordinates the overall functionality by managing time triggered (for example, ļ¬xed-rate
sensor sampling) and event-triggered (for example, injection triggered by the piston position).
āThe architecture of the embedded controller as implemented by Magneti Marelli contains a Motorola 68332
microprocessor (16 MHz), an ASIC implementing the PWM functions, 33 KB of used RAM and 194 KB of
used ROM. The software written for the micro-controller consists of 35,000 lines written in C. The design
eļ¬?ort was 8 man/year.āā?[4]
3 POLIS - A framework for Hardware-Software Co-Design of Em-
bedded Systems
āPolis is a software for Hardware/Software co-design of embedded systemā? [5]. The term Hardware/Software
co-design means creation of a mixed system that will have a hardware portion and a software portion. This
includes speciļ¬cation, synthesis, estimation and veriļ¬cation.
āThe object of design is a hierarchical netlist, whose leaves are CFSMs (Co-design Finite State Machines)
and intermediate levels are netlistā? [5]. Netlist and CFSMs are collectively known as Modules. Module
instances at any level can be identiļ¬ed by its hierarchical name.
ā?/ā? character is used to access modules down the hierarchy.
3
CFSM is not a speciļ¬action language. Interconnections between CFSMs are speciļ¬ed using a textual netlist
auxillary language or VEM, a graphical editor.
Signals are used as a synchronization and communication mechanism between CFSMs. They act as carriers
of events. They can carry both data and control information. The emission of each event can be detected
by many CFSMs.
POLIS uses a model called Co-design Finite State Machines(CFSMs). This is a globally asynchronous,
locally synchronous formal model of design.
This is based on:
ā? Extended Finite State Machines: Which operate on ļ¬nite valued variables by using arithmetic,
relational, boolean operators. Each transition in CFSM is an atomic operation.
ā? Interaction between CFSMs is asynchronous, so as to support āneutralā? speciļ¬cation of hardware and
software components.
Each transition in a CFSM has a set of preconditions and a set of postconditions. Preconditions are a set of
boolean functions of input variables and input events. Postcondition are a set of output events and values
assigned to output variables.
Buļ¬?ering is not done in POLIS, so there is a chance of losing events if the sender generates events faster than
the receiver can consume. To avoid the overwriting of critical events in the buļ¬?er, handshaking or proper
scheduling algorithms may be used.
3.1 POLIS Design Methodology
The main steps in POLIS design ļ¬ow[5] are:
1. High Level Language Translation.
2. System Co-simulation.
3. Formal Veriļ¬cation.
4. Design Partitioning.
5. Software Synthesis.
6. Hardware Synthesis.
7. Rapid Prototyping.
4 Design of the Engine Control Unit
4.1 High level functional speciļ¬cation
The POLIS environment was used to implement some of the relevant functionalities of the system. The ECU
that was implemented could manage the basic control operation of a four-cylinder Multi-point Injection and
Ignition System. Some of the secondary tasks were not taken in to consideration to keep the design small
and simple. One such secondary task is interaction with Catalytic Gas Sensor.
To demonstrate the usefulness of formal design techniques, the control algorithm itself was taken from original
speciļ¬cations, without any changes. The speciļ¬cations were provided by Magneti Marelli.
The top level speciļ¬cation of the system is partitioned into a hierarchical netowrk of functional blocks. There
are four main blocks:
ā? Acquisition of analog signals.
4
ā? Acquisition of frequency signals.
ā? Engine control strategies for the injection and ignition sub-systems.
ā? Control of the actuators.
The acquisition blocks, as mentioned earlier, can handle several types of sensors. The sensors accept signals
from the environment. The most important ones are the battery voltmeter, the intake manifold air pressure
sensor, the throttle position sensor, the air and water temperature sensor, the position sensor of the phonic
wheel and the camshaft position sensor. The system can detect faulty signals and adopt appropriate recovery
strategies, whenever possible.
Various system variables, such as RPM, air ļ¬ow, derivatives of input signals etc are calculated after measuring
and ļ¬ltering the above external signals. These variables are used by the control strategy layer.
4.2 Functional simulation
Once the functionality of the system has been modeled as a set of interacting Extended Finite State Machines,
POLIS can be used to verify the behavior of the overall algorithm.
The top level of the simulation model contains the testbench, using special functional blocks that model
(in a simpliļ¬ed manner, for performance) the engine and the sensors, thus providing inputs and monitoring
outputs of the ECU.
The output of the simulation, as well as the state of several internal variables for debugging purposes, is
monitored and compared with the expected data in order to determine thee functional correctness of the
speciļ¬cation.
4.3 Architecture Selection and Mapping
One of the most important stages of the design methodology is the Architecture Selection step. In the archi-
tecture selection step, the functional behavior is partitioned into hardware and software. The organization
of several software modules into tasks, to be executed together by the RTOS, based on expected input event
frequency and priority is also done in this stage. One last aspect is the selection of a scheduling algorithm
for tasks to execute on the processing unit (cyclic or priority-based, preemptive or non-preemptive, etc).
The performance of the simulation, in terms of simulated clock cycles per second on an unloaded ULTRA-
Sparc1, is described in Table 1. The performance obtained without the use of graphical displays is shown
engine speed Cycles / Seconds Cycles / Seconds
(RPM) Graphics No Graphics
1000 366 K 433 K
6666 116K 216 K
Table 1: Simulation Performance
Source: [4]
under the coloumn labeled āNo Graphicsā?. There is a relatively small diļ¬?erence between the cases with an
engine speed of 1000 RPM and 6666 RPM. This can be attributed to the fact that only some acquisition
tasks are triggered by the engine phase, while some are triggered by periodic timer interrupts.
The system facilitates an analysis of diļ¬?erent architectural choices. The choices can involve a number of
micro controllers. Here the Motorola 68332 micro controller (running at 16 MHz) was chosen, with an on-chip
Time Processing Unit (TPU [6]). Part of the TPU function was speciļ¬ed and simulated at the behavioral
level. However, the more complex functions implemented using the microprogramming capabilities of the
TPU were modeled in Esterel. The TPU enabled the designers to compare the performance of the ECU
designed with this architecture against that of the already available ECU.
5
Partitioning was performed by starting from the functional simulation model, in which every block has a
delay of 1 clock cycle, and thus corresponds to a maximally parallel hardware implementation. Then selected
groups of modules were moved to software, based on the timing constraints and feedback from the simulation.
POLIS models functional components as Finite State Machines (extended with integer arithmetic capabil-
ities). The diļ¬?erent components communicate among themselves via one-place buļ¬?ers. If at any time one
of those buļ¬?ers is overwritten, it indicates that there is a speed mismatch between the sender and receiver
components (FSMs). This often indicates the breaching of some deadline. Missed deadlines (in the form of
lost events) are logged to a ļ¬le, and can be used for diagnosis and as a guidance for system performance
analysis.
The system is composed of three main functional blocks, which in turn consist of several modules and
submodules. The partitioning process was started by changing the implementation of each unit as a whole.
Only after several experiments, the performance of each unit was analyzed, and identiļ¬cation of the critical
path and possible reļ¬nements in the strategy were made by looking more closely at the lower levels of the
hierarchy.
1. During the ļ¬rst experiment, the entire system was developed as hardware. This is equivalent to the
functional veriļ¬cation through simulation. Complete hardware implementation resulted in a very fast
system. At 16 MHz frequency, the system performs its task ļ¬awlessly. The results of this implemen-
tation were same as the expected results. However, the system included a large number of multipliers
and dividers, which made the implementation very expensive.
2. In the next step, the entire Analog Acquisition block was implemented as software. It decreased the
speed a little, but still it was suļ¬ciently fast. The simulation showed that even with a slower CPU
(i.e. 4 MHz), the results were correct.
3. As a third step, the driver blocks were implemented as software, both for injection and ignition. The
Frequency Acquisitions unit was left in hardware, whereas the low level counting task was assigned to
the TPU. The system was able to control the engine correctly, even when it was running at the highest
speed (6600 RPM). No event was lost, and the results were as expected.
4. In the next step, Frequency Acquisitions unit was moved to software. i.e except for the 68332 TPU,
a full software implementation was simulated. This time, the ECU failed to capture all the events. A
lot of events coming from the crankshaft position sensor were lost, even with the engine at a moderate
speed. Two critical modules were identiļ¬ed. These modules were scheduled at the highest frequency
in the entire system and were used to ļ¬lter the signals coming from the engine.
5. This time, one of the critical modules was implemented as hardware, and the other as software. But
this again missed a number of deadlines and hence did not produce the desired result. Comparison of
the plot of the task schedule with the missed deadline log revealed that the problem was due to the
Round Robin scheduler, which introduced high latency.
6. In order to do away with the latency, the acquisition of the signal coming from the engine was driven
through an interrupt. This approach made it possible to implement both the critical modules as
software routines, without losing any functionality.
The CPU load, due to the acquisition and actuation layer, is nearly 40% in the ļ¬nal partition. This ļ¬gure is
quite close to the corresponding value in the manual design, which indicates that the (estimated) performance
of the synthesized code is very close to that of hand-written code.
The total code size in bytes (for the 68332 micro controller) in the ļ¬nal partition is compared with the
manual design in the following table.
5 Lessons learned and design guidelines
While developing the system, it was required to choose a method that could translate the existing formal
functional speciļ¬cation into an executable speciļ¬cation using CFSMs. This requires solving a number of
trade-oļ¬?s about the granularity of the CFSMs.
6
Function Code Size Code Size
Manual Synthesized
Acquisition 18 K 13 K
Actuation 12 K 12 K
Table 2: Code Size comparison
Source: [4]
One main aspect of the compilation mechanism used by Esterel (and hence by the POLIS front-end) is
that it fully abstracts the user-given speciļ¬cation. This means that the control structure in the Esterel
speciļ¬cation (e.g. loop and await statements) is translated into a Finite State Machine. Each of these
CFSMs is then converted into a Binary Decision Diagram consisting of optimal sequence of control and
assignment statements. This optimization is very much sensitive to the module size. Small modules within
the code are easier to understand and generally get compiled very fast, whereas, large modules require
larger space in the memory to ļ¬t in and more time for compilation. However, they have more scope for
optimization. If, for example, similar large modules do not share code, then the implementation will be
comparatively fast but the code size (and, in turn, number of states) may become too large. On the other
hand if the common portions of such code are shared among similar modules, it leads to smaller code size
and lesser number of FSM states. However, it requires indirect access to some variables which increases the
execution time marginally.
POLIS, however, provides the designer with several techniques for exploring these trade-oļ¬?s. In particular,
it provides methods for
ā? Chaining the execution of several modules, without returning control to the Real Time Operating
System [4],
ā? Merging several CFSMs, by computing their synchronous product, into a single CFSM [4].
The ļ¬rst technique is relatively cheap, does not cause much increase in code size, and is most suitable for
data-intensive modules. The second technique is especially useful for control-dominated modules having a
high degree of interaction, since it abstracts all the internal communication between the merged CFSMs,
thus resulting in a much simpler implementation in many cases. For example, the ļ¬rst technique was applied
to the submodule Test Tens Batt, which consists of two cascaded CFSMs. The ļ¬rst CFSM checks the
value of the battery voltage and implements a recovery mechanism, and the other one computes the value
of internal variables. This helped in speeding-up the code by 11%, keeping the code size unchanged. It was
estimated that it is possible to apply such optimizations to almost 20% of the modules of the entire design.
The oppposite approach may also prove to be useful in some cases. In this case, there was a single module
which was updating a number of variables simultaneously. Upon splitting this CFSM into four cascaded
CFSMs, the total code size reduced from 11 KB to 1.5 KB [4].
6 Conclusion
Formal design methodologies are beneļ¬cial in the design of embedded systems due to various factors like
safety, cost, time-to-market and performance. Implementing parts of the system in software helps in meeting
cost constraints. While the use of hardware allows to satisfy the safety, time and performance parameters.
Therefore, partitioning the system into hardware and software is a critical step in designing of the system.
CAD tools help in taking the right decisions.
In this paper, through the example of the design of an Engine Control Unit, we have addressed the issues
related to partitioning of a system so as to get the best mix in terms of code size and execution time. The
results were obtained by designing a real-world embedded system, which suggests that the approach is very
promising.
7
ACKNOWLEDGMENT
We are thankful to Dr. Rajat Moona for his motivation and guidance in writing this paper. We would also
like to acknowledge all those people and organizations who have provided access to ECU related information.
Maunendra Sankar Desarkar
Mausoom Sarkar
Palak Agarwal
Varun Khaneja
References
[1] Massimiliano Chiodo, Daniel Engels, Paolo Giusto, Harry Hsieh, Attila Jurecska, Luciano Lavagno, Kei
Suzuki, and Alberto SangiovanniVincentelli. A case study in computer-aided co-design of embedded
controllers. Design Automation for Embedded Systems, 1(5):51ā?67, 1996.
[2] Goodrich Engine Control Systems.
http://www.enginecontrols.goodrich.com/large/ecu.shtml.
[3] STMicroelectronics.
http://www.st.com/stonline/books/pdf/docs/10674.pdf.
[4] Tullio Cuatto, Claudio Passeronge, Luciano Lavagno, Attila Jurecska, Antonino Damiano, Claudio Sanso,
and Alberto Sangiovanni-Vincentelli. A case study in embedded system design: an engine control unit.
In Proceedings of the 35th annual conference on Design automation, pages 804ā?807, 1998.
[5] POLIS Userās Manual.
ftp://ic.eecs.berkeley.edu/pub/hwsw/polis man.0.4.ps.gz.
[6] Motorla Inc. M68300 family. tpu time processor unit, reference manual, 1990.
[7] MTU Aero Engines.
http://www.mtu.de/en/glossar/d/dig engine cu.html.
[8] POLIS A framework for Hardware-Software Co-Design of Embedded Systems.
http://www-cad.eecs.berkeley.edu/respep/research/hsc/abstract.html.
8
|