Technology focus - Automotive ECU Development – a technology insight

We are all familiar with the fact that the complexity of modern vehicles is growing rapidly! With each new generation of vehicle, the sophistication of the power train, chassis and body control systems increases significantly. This is only possible due to the increasing number of electronic controllers around the vehicle (ECU's) and with each vehicle generation, they become more powerful (in terms of memory and processing power), and they are increasingly more 'connected' - sharing data and information during vehicle operation.

Having a complicated controller is now essential to achieve the required performance levels, as well as driver expectation – but have you ever considered the task of getting these control units to function and behave in the correct way. To set them up - fine tuning them for the application. This task is undertaken during vehicle and powertrain system development, and is known as 'calibration'!

Fig 1 - Typical ECU parameters needing to be adjusted in order to achieve the required targets for a modern diesel engine – this is ECU calibration!

What is ECU Calibration?

An ECU is a micro-processor based control unit that performs complex functions by running sophisticated control algorithms. The tuning of these to suit the application (e.g. engine, vehicle type etc.) is a task commonly known as CALIBRATION. The Calibration Engineer will adjust the parameters of the control function algorithms that are stored in permanent memory inside the ECU (maps, tables etc.) during development. This will allow optimisation the controller based on targets (good fuel consumption, good drivability) whilst keeping within boundary limits (noise, temperatures).

Fig 2 - The increasing complexity of the ECU calibration task

Within the ECU software, each physical data value is known as a 'label' - this could be a calibration value (i.e. a value that needs adjusting or 'calibrating') or a measurement value (i.e. an internal value used within the software, for example 'engine temperature' or ' desired ignition angle for spark advance'). The number of 'labels' has grown massively with increasing complexity - 10 years ago there were 3000 to 5000 labels to deal with, now, it is 40,000 to 50,000 labels. This shows what a massive task the overall calibration of an ECU is!

In order to 'calibrate' effectively, access to these labels is needed during ECU operation! Actually, that is not strictly true - in years gone by, the 'calibrations', which were much simpler, were held on memory chips. These chips could be replaced or re-written off line and re-installed into the ECU, thus providing a new calibration. There were (and are) many providers in the aftermarket doing this, providing updated calibrations that added horsepower (at the expense of other things, like fuel consumption and driveability) to boy racer types! The technical term for this approach is 'off line' calibration!

But this offline technology does not support an efficient calibration process in development - typically, there is a lot of 'round trip Engineering' when calibrating an ECU. For example, changing values, checking responses, comparing with measurement data on-line, and off-line. To support this task efficiently, 'on line' calibration technology is needed. That is, seeing and changing what is going on inside the ECU, during operation! Anyone who has used a scan tool to view and record data during a test drive will experience seeing on-line measurement labels. However, the calibrator needs to see all the labels for his task, including being able to change some of them, and test and measure the response immediately. For this, a suitable software and hardware tool chain is needed. Typically, this consists of application software running on a PC, in combination with an interface to the ECU.

Fig 3 - The calibration tool runs on a PC and connects to the ECU via an interface that allows changing of parameters during runtime (Source: ATI)

Fig 4 - ECU access methods and their relative performance

Read More

Technology focus - Engine Control Unit (ECU) - Torque based architecture explained

In older generation engine management systems, different internal control subsystems had conflicting demands on the overall control system, with no real co-ordination. This meant that there was an interdependence between these systems, which was difficult to handle during calibration and did not provide the optimum with respect to an overall engine control concept. The answer was a 'torque' based architecture in the ECU - that is, to focus on the driver demand for torque, rather than respond to the throttle pedal postion.

Fig 1 - Conflicting torque demands in an Engine control unit

The block diagram above shows the conflicting requirements - the answer was a torque based control architecture – an overall torque demand manager (TDM) co-ordinates all the overall torque and efficiency input values. Internal inputs are typically defined by the engine operating mode and protection limits, external inputs are driver demand, cruise control and vehicle dynamic control values (ABS, Stability control etc.). The TDM process the inputs, taking into account drivability optimisation factors (thus allowing ‘tuning’ of the vehicle behaviour with respect to vehicle type and driver expectation). The final output from the TDM is a required torque value, this is realised by the controller output stages and connected actuators which are available to influence the engine torque output – typically throttle angle, ignition timing (SI engine), injection parameters (SI and CI engine) and turbocharger control.

Fig 2 - Overview of the TDM function (Torque Demand Manager)

But how is engine torque measured? well it isn’t! it is derived from an internal model that takes into account cylinder air charge, lambda and ignition timing (SI engine). Combustion generates a cylinder based ‘internal’ torque, from this gas exchange and friction losses are estimated and subtracted, and this gives a final engine output torque. Clutch torque can then be derived by subtracting engine ancillary torque absorbers, for example, Electrical and HVAC loads.

Fig 3 - Virtual torque sensor function which forms the basis of a torque based ECU structure

Read More