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 specification, imple-
mentation issues and architectural trade-off analysis.

1 INTRODUCTION
An embedded system is defined as “A system designed to perform a single well defined function life-long.
It is generally subject to real-time constraints”[1]. Applications of embedded systems range from home to
office, 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 unified 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
specification, 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 flow 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-off
between these issues, and the system tries to find 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 specifications 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 fired in advance with respect to the instant when the piston is at its highest point. Moreover,
this parameter also affects the emissions since unburnt fuel is pushed out of cylinder as emission or
pollution. The timing difference between fuel injection and firing 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-defined 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, fixed-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
effort 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 specification, synthesis, estimation and verification.
“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 identified by its hierarchical name.
‘/‘ character is used to access modules down the hierarchy.

3
CFSM is not a specifiaction language. Interconnections between CFSMs are specified 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 finite 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” specification 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.
Buffering 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 buffer, handshaking or proper
scheduling algorithms may be used.

3.1 POLIS Design Methodology

The main steps in POLIS design flow[5] are:

1. High Level Language Translation.

2. System Co-simulation.
3. Formal Verification.
4. Design Partitioning.
5. Software Synthesis.
6. Hardware Synthesis.
7. Rapid Prototyping.

4 Design of the Engine Control Unit

4.1 High level functional specification

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
specifications, without any changes. The specifications were provided by Magneti Marelli.
The top level specification 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 flow, derivatives of input signals etc are calculated after measuring
and filtering 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 simplified 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
specification.

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 difference 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 different 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 specified 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 different components communicate among themselves via one-place buffers. If at any time one
of those buffers 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 file, 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 identification of the critical
path and possible refinements in the strategy were made by looking more closely at the lower levels of the
hierarchy.

1. During the first experiment, the entire system was developed as hardware. This is equivalent to the
functional verification through simulation. Complete hardware implementation resulted in a very fast
system. At 16 MHz frequency, the system performs its task flawlessly. 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 sufficiently 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 identified. These modules were scheduled at the highest frequency
in the entire system and were used to filter 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 final partition. This figure 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 final 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 specification into an executable specification using CFSMs. This requires solving a number of
trade-offs 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 specification. This means that the control structure in the Esterel
specification (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 fit 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-offs. 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 first 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 first technique was applied
to the submodule Test Tens Batt, which consists of two cascaded CFSMs. The first 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 beneficial 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.