Internal combustion engine control

1. Engine control unit software

The engine control unit (ECU), commonly referred to as the engine control module (ECM) or
powertrain control module (PCM), is one of the most important components in almost all modern
vehicles. It basically functions as the main computer for many vehicle engine performance and
handling functions.
There are many types of ECUs, and their functions vary. Some highly engineered cars may contain
as many as 100 ECUs (Figure 1). These perform various functions, including: Engine control,
Transmission control, Brake control, Speed assist, Park assist, Automatic climate control, Traction
control, Anti-lock brake system control.

Figure 1

Automotive Electronic Systems

[Source: https://cecas.clemson.edu/cvel/auto/systems/auto-systems02.html]

The ECU takes information from various engine sensors and uses that information to calculate and
tune engine spark and fuel for maximum power and efficiency. In many vehicles this controller also
regulates the electric power distribution, provides the on-board diagnostics, and communicates with
a number of other automotive systems to share information it obtains from various sensors.
Figure 2 shows some of the main sensors and actuators used by the ECU.
Often, the powertrain control unit is made up of the engine control unit and transmission control unit
subsystem. The engine control module controls a set of actuators and ensures proper engine operation.
The transmission control module ensures the fuel efficiency of the engine by taking input from the
engine sensors.
 Figure 2

An engine control diagram

[Source: https://cecas.clemson.edu/cvel/auto/systems/auto-systems02.html]

Brief on ECU hardware

It is an electronic card housed in a small box (aluminum or plastic). The material of the shell depends
on the location of the block. It is usually in a plastic case if it is located in the cabin and in a metal
case if it is under the hood of the car. A pair of connectors come out of the controller for CAN Bus
and Sometimes there is an extra connector for easy diagnostic and flashing.

The ECU generally uses 32-bit microcontrollers with a few megabytes of memory registered at speeds
between 32MHz and 100MHz. They generally communicate with other electronic units using one or
more CAN bus interfaces (FlexRay and/or LIN bus communications may also be employed). It is a
sort of a mini computer which has storage devices, namely:

 RAM - for processing the intermediate data of the vehicle;

 EPROM - read-only memory, stores the motor function parameters and other required
software;

 EEPROM - designed to store temporary information: lock and access codes, mileage,
temperature in engine, fuel consumption, etc.
[Source: https://gtshina.ru/en/uhod-za-avto/osnovnye-funkcii-elektronnogo-bloka-upravleniya-dvigatelem-v/]
For the record, here are some ECU manufacturers: Bosch, Continental, Delphi, Haltech, Hitachi,
Fujitsu Ten, Hyundai Kefico, Keihin, LifeRacing, Magneti Marelli, Mitsubishi Electric, Motec,
Performance Electronics, Pi Innovo, Visteon, Woodward, Westport.
1. Software development

The ECU is essentially an on-board computer in a car that has a microprocessor that receives,
interprets and reacts to sensor inputs as quickly as they occur. It is made up of hardware (a fairly
standard printed circuit board) encoded with software (a program that tells the car how to operate).

ECU programming is the process of taking a ROM file and placing it into permanent storage inside
a vehicle's engine management ECU. The ROM file is made by using a development interface like
ASCET-DEVELOPER and/or Matlab Simulink which are interfaces that help us to create embedded
software for almost all industries.

ASCET-DEVELOPER:
ASCET-DEVELOPER allows us then to program all the interactions and calculations that an ECU
has to perform in order to get a model that will be integrated in the ECU.
ASCET-DEVELOPER allows you to easily combine texts and graphics suiting your programming
needs. There are different possibilities for modeling your logic, enabling you to work as efficiently
as you like. Therefore you have four choices of specification (Figure 3):
 Graphic specification using Block Diagram
 Graphic specification using State Machine Editor
 Textual specification using C Code Editor
 Textual specification using ESDL Editor, Embedded Software Development Language.
[Source: https://www.etas.com/en/products/ascet-developer.php]

After having finished programming the operation of the ECU, we can easily generate the C-code
which will serve as a ROM file to be inserted later in the hardware. This program provided by ETAS
Company is configured to create embedded software for AUTOSAR 1 and non-AUTOSAR
applications.

Figure 3

ASCET-DEVELOPER IDE (Integrated Development Environment)

[Source: https://www.etas.com/en/products/ascet-developer.php]

1
AUTOSAR (AUTomotive Open System Architecture) is a development partnership of major automotive industry OEMs
and suppliers, as well as tool and software vendors worldwide. The goal of the partnership is to establish a global standard
for common software architecture, application interfaces, and methodology of embedded software for vehicle electronics.
Matlab SIMULINK:

Matlab Simulink also is used to develop embedded software using either hand coding or by
simplifying the task a little using blocks and gives access to the C-code (Figure 4).

Figure 4

Matlab Simulink interface

MATLAB Coder, Simulink Coder and Embedded Coder are extensions of Matlab for code
generation. The former is used to generate ANSI C/C++ code from MATLAB and is a pre-requisite
for Simulink Coder and Embedded Coder. The second does the same thing, but from Simulink. The
third (Embedded Coder) allows optimizing/ customizing the code generated by MATLAB Coder and
Simulink Coder for production use and facilitates software integration. Also Embedded Coder offers
built-in support for AUTOSAR.

2. Design cycle of electronic controllers

Software development methodology (V-model):

The V-model starts with Control targets phase in which the team or management tries to understand
the product requirements from customer perspective. This phase aims to establish a mutual
understanding that an ideal system has to perform. However, it does not deal with the low level details
of how this software will be designed. Requirement document will be then the output of this phase.
So, once we get clear and detailed product requirements it is time to analyze those requirements,
conduct feasibility study and design the complete system (functional design). The output of this phase
is the high-level system design document that will have the complete picture of various components
of the system such as user, software, hardware and interfaces and database. Now appears the role of
software architect who will analyze the functional design document and generate high level software
design. He will take all technical decisions in this phase like which controller will be suitable,
deciding on which programing language should be used, memory, communication protocols and
much more. Once the software blueprint is ready, software developer can start designing the
individual modules (control software) and generate low-level software design documents. Then
comes coding, where the actual construction of the software takes place (code implement) (Figure 5).

In V-model, the testing phases are also planned in parallel with its corresponding development phase.
So, before closing the control targets phase, review and validation tests should also be planned. Once
the software is ready, it will be tested by customer or system user for validation. Similarly, the system
testing and functional integration testing should be planned in parallel with functional design and
physical design. The System testing will be conducted just before the product delivery to test the
entire system functionality including all internal and external components. Also functional integration
test will be conducted to test the software internal modules and internal communications. The
software verification is the bench testing that can be described as a white-box testing which will be
conducted by individual developer to test the module functions.

Figure 5

Typical V-cycle for the controller design

[Source: Mahdi Shahbakhti, Jimmy Li and J. Karl Hedrick, Early Model-Based Verification of Automotive Control
System Implementation, American Control Conference, 2012.]

We notice that in the V-model at each level there are checks whose principle is to detect failures at
an early stage in order to avoid the accumulation of errors. In fact, this would save a lot of time during
development process of an electronic control unit as that time spent early in the software development
cycle can reduce cost at later stages.
Automotive controller design (ECU): Modeling and Design

This step concerns the Implementation of a program which will have the possibility of executing all
the functions that an ECU is supposed to do as shown in the Figure 6, from the reception of the inputs
with their processing, calculations and errors estimation to the results that are sent as information,
reminder or order.
 Figure 6

ECU operations
* EMI: filters that are an effective way to protect against the harmful impacts of electromagnetic
interference.
** ESD: Electrostatic Discharge control practices have substantially minimized the dangers from
unwanted electrical overstresses that are known to haunt semiconductors and other micro-electrical
devices at all stages of their manufacturing, handling and applications.

The program can be made through interfaces such as Matlab SIMULINK and/or ASCET developer
that allows us to make Physical software components modeling using Library with standard blocks,
Document generator, Simple integration from C-Code, library Functions.

Automotive controller design (ECU): Prototyping (INTECRIO)

INTECRIO is a software tool designed to integrate models of various physical and electronic systems
(using modeling tools such as Simulink) into a single executable. This executable can run on a
Windows desktop PC or in a real-time rapid-prototyping environment. In fact, INTECRIO enables
you to combine models and code from different sources—such as handwritten code and code
generated by Simulink Coder and ASCET DEVELOPER—into a single prototype (Figure 7).
An integrated OSEK-compliant real-time operating system (RTOS) from ETAS is included for
testing many different ECU models (Figure 7).
[Source: https://www.mathworks.com/products/connections/product_detail/intecrio.html]

Using prototyping it is possible to identify and correct errors at an early stage of the development
process. This significantly reduces the number of time-intensive and costly iterations during software
development.
Furthermore, AUTOSAR software components can be generated by Simulink using Embedded Coder
or by other code generation tools like ASCET. Finally, ETAS INCA tool makes it easy to perform
desktop calibration of Simulink models and code.
 Figure 7

Virtual and rapid prototyping of traditional and AUTOSAR software components

[Source: https://www.mathworks.com/products/connections/product_detail/intecrio.html]

Automotive controller design (ECU): Calibration (INCA tools)

INCA tools (INtegrated Calibration and Acquisition system) are used for ECU development and test
as well as for validation and calibration of electronically controlled systems in the vehicle, on the test
bench, or in a virtual environment on the PC.
Through the use of INCA, validation and calibration tasks can be shifted from the vehicle and the test
bench to the desktop computer, saving time and money.
Combined with ETAS rapid prototyping hardware (e.g., ES910 and ES1000), INTECRIO lets us
conduct real-time bypass experiments with an existing ECU using the CAN bus or ETAS high-speed
memory emulator probe (ETK) mounted on the ECU (Figure 8 and Figure 9). ETAS INCA tool can
be used to calibrate all model parameters and synchronize all measurements from the bypass model
as well as the ECU.
[Source: https://www.etas.com/en/company/news_archive_2012-
prototyping_intecrio_rlink_measurement_calibration.php]
 Figure 8

ETAS prototyping system example: ES910 module running the control function modeled in Simulink is connected to an
ECU through the ETK bypass interface and to sensor and actuator signals via the ES930 module in real time
[Source: https://www.etas.com/en/company/news_archive_2012-
prototyping_intecrio_rlink_measurement_calibration.php]
In fact, the ECU under development is not the same as the one produced because during this process
it is equipped with an additional calibration device which will be removed after the development
process is completed.

Figure 9

ECU emulators (also known as ETK) can be parallel (i.e. directly connected to the data bus) or serial (i.e. directly
connected to the microcontroller)
[Source: http://autoelexblog.blogspot.com/2013/11/]
There are two types of technology to exchange with the ECU, one is a simple CAN based interface -
with a calibration interface driver software installed (known as CCP - CAN Calibration Protocol) -
in this case, the ECU needs extra memory (compared to standard), to facilitate the online handling of
the measurement labels. The other type is to connect an emulator with the ECU. This device is
installed inside the ECU and has direct read-write access to the data bus inside the micro controller.
It also has additional memory and processing capability in order to directly handle communication
with the PC running the calibration tool software. Generally speaking, the emulator has superior
performance to the CAN solution, but is more complex and costly to implement.
Usually, the ECU flashed data is only readable and not writeable. That means the original data cannot
be directly changed. However, with additional hardware (ES59x, ES69x, ES910 or ES1000)
connected with INCA can be the ECU’s ROM with an extern RAM bridged. The flash data is from
the RAM run, so the original data can be changed, without changing the original content itself.
With this variety of hardware provided by ETAS, we can access the ECU during run-time, and make
changes, for example, changing ignition timing to give the best performance at any given engine
operating condition (speed, load). The ignition timing is held in a ‘map’ – the map covers all engine
operating conditions and provides an ignition timing demand value as a set point (Figure 10). Using
the calibration tool, the map can be adjusted during testing, optimizing to give the best performance.
Note that a map is considered as a single value (or label) to be calibrated.
During the development cycle, the calibration engineer will adjust and modify many values inside
the ECU in order to optimize and characterize the engine. In a modern powertrain, it can take teams
of people months or even years. Take an ECU, with 30,000 labels, which will equip 10 vehicle
variants. Each vehicle has a different calibration in order to differentiate it in the market. Every
vehicle needs to be calibrated for emissions, performance, fuel consumption, handling and on-board
diagnostics - each of these tasks is significant and all impact on each other. It is very common for the
calibration of a single ECU variant to be handled by large teams of engineers, often with specialist
knowledge of how a function works and how to calibrate it. For example, there may be a team of
engineers calibrating the emissions, which will include a specialized person or team who can look
after the start / stop system or the after treatment system. This complex environment creates masses
of data (calibration and measurement) that must be processed, analyzed, controlled and merged, to
create the final "master" calibration which will be approved by the chief calibration engineer. This is
the final version which will then be deployed on the production vehicle. This final calibration is
normally "flashed" into the ECU during the vehicle's production run. Before the final vehicle test, at
the factory before the vehicle is shipped.

Figure 10

Labels calibration during run-time

[Source: https://www.etas.com/en/products/inca.php]
The calibration engineer, with the calibration tool, can access all labels during the test, so he can set
the calibration labels and see the responses by observing the measurement labels. Additionally, the
engineer may wish to measure additional information. So it often happens that the calibration
instrument is used in conjunction with the measuring equipment, so that the physical values can be
measured with additional sensors, for example - the exhaust temperature can be measured using
sensors installed on the development vehicle, in order to calibrate the exhaust temperature pattern
inside the ECU, which is used in the production ECU to protect components (Figure 11).

Figure 11

Additional measuring equipment during testing

[Source: https://www.etas.com/fr/produits/compact_es400_measurement_modules.php]

3. Conclusion
With current technological advancements, this has gone a step further - a lot of development work
can now be done on a computer, with a simulated environment - and this applies greatly to ECU
development work. Electronic control unit software and functions can be easily developed and tested
in virtual environments. The entire electronic control unit can be simulated, with the vehicle, the
driver and the environment on a computer, and the simulation can run faster than in real time, this
means that a 20-minute trial run can be reduced to a few seconds (depending on the complexity and
the processing power of the PC) - providing results Simulation for analysis and development. A
typical next step is to make the ECU itself into a test environment - thus being able to test the actual
ECU code, which runs on the ECU hardware, with the physical connections to electrical stimulation,
but a complete virtual test environment (driver, vehicle, and environment).
There is no doubt that developing and calibrating the ECU is a complex task! Several tools and
techniques are available to help, and much will need to be developed to keep pace with the demand
for further development.