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 specication, implementation issues and architectural trade-o analysis.

INTRODUCTION

An embedded system is dened as A system designed to perform a single well dened function life-long. It is generally subject to real-time constraints[1]. Applications of embedded systems range from home to oce, 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 unied 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 specication, 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.

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 specications 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 aects the emissions since unburnt fuel is pushed out of cylinder as emission or pollution. The timing dierence 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-dened 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 eort was 8 man/year.[4]

POLIS - A framework for Hardware-Software Co-Design of Embedded 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 specication, synthesis, estimation and verication. 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 identied by its hierarchical name. / character is used to access modules down the hierarchy. 3

CFSM is not a speciaction language. Interconnections between CFSMs are specied 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 specication 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. Buering 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 buer, 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 Verication. 4. Design Partitioning. 5. Software Synthesis. 6. Hardware Synthesis. 7. Rapid Prototyping.

4
4.1

Design of the Engine Control Unit

High level functional specication

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 specications, without any changes. The specications were provided by Magneti Marelli. The top level specication 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 simplied 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 specication.

4.3

Architecture Selection and Mapping

One of the most important stages of the design methodology is the Architecture Selection step. In the architecture 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 ULTRASparc1, is described in Table 1. The performance obtained without the use of graphical displays is shown engine speed (RPM) 1000 6666 Cycles / Seconds Graphics 366 K 116K Cycles / Seconds No Graphics 433 K 216 K

Table 1: Simulation Performance

Source: [4]

under the coloumn labeled No Graphics. There is a relatively small dierence 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 dierent 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 specied 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 capabilities). The dierent components communicate among themselves via one-place buers. If at any time one of those buers 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 identication of the critical path and possible renements 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 verication 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 implementation 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 suciently 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 identied. 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.

Lessons learned and design guidelines

While developing the system, it was required to choose a method that could translate the existing formal functional specication into an executable specication using CFSMs. This requires solving a number of trade-os about the granularity of the CFSMs. 6

Function Acquisition Actuation

Code Size Manual 18 K 12 K

Code Size Synthesized 13 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 specication. This means that the control structure in the Esterel specication (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-os. 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].

Conclusion

Formal design methodologies are benecial 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.

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):5167, 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 804807, 1998. [5] POLIS Users 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.