Journal of Circuits, Systems, and Computers

c World Scientific Publishing Company

SIMULINK-BASED CODESIGN AND COSIMULATION

OF A COMMON-RAILTM INJECTOR TEST BENCH

E. BELLEI, E. BUSSOLINO, F. GREGORETTI, L. MARI, F. RENGA, L.M. REYNERI

Dipartmento di Elettronica, Politecnico di Torino, C.so Duca degli Abruzzi, 24,
10129 Torino, Italy
e.mail: [email protected]

This paper describes how a complete test bench for a Common RailTM injection system
has been built by means of hardware/software codesign techniques. The test bench is
made up of two main components: a HW component running mainly onto an FPGA
device, interacting directly with the electromechanical components (namely, a high pres-
sure pump, six electrical injectors, an electrical discharge valve, two pressure sensors),
for high speed signal acquisition and generation, and for closed loop control; and a SW
component, written in Visual BasicTM , running on a PC, including a graphical user
interface for parameters setting and system characterization. An additional signal ac-
quisition board is also used for monitoring six load cells and for temperature control.
The two components communicate through the standard PC’s parallel port operated
in Enhanced Parallel Port mode. The test bench is totally designed, simulated and
implemented under the CodeSimulink hardware/software codesign environment, which
runs as a plug-in of The MathworksTM SimulinkTM design tool. A few other commer-
cial HW/SW codesign tools have also been considered, but none of them offered either
enough performance or flexibility or, more important, ease of use and compatibility with
existing Simulink simulation models of the various components of the test bench.

1. Introduction
In the latest years, electronics has made a considerable growth in the automo-
tive field. This requires building several new sophisticated instruments for testing,
servicing and troubleshooting.
Many such instruments are composed of a hardware (HW) and a software (SW)
component, strictly interacting together and with an external world and environ-
ment where several electromechanical components may also coexist. In particular,
embedded systems are those where the control electronics (both HW and SW) are
tightly integrated with a controlled electromechanical system (sometimes, also hy-
draulic or pneumatic), to improve its performance, reliability and availability, and
to significantly reduce its cost.
Before a variety of rapid prototyping tools were available, an embedded system
was initially split into at least a HW and a SW component and a number of mechani-
cal, electrical, hydraulic, etc. components (partition phase), each of which was then
designed, simulated and tuned separately from the other component. Each elec-
tronic component (either HW or SW) was described, simulated and compiled using
a different language (usually, C/C++ for the SW component and either schematic
Simulink-Based Codesign and Cosimulation of a Common-RailTM Injector Test Bench

or VHDL for the HW component), while mechanical, electrical and hydraulic de-
signs had to be carried out independently of each other and by as many independent
teams. No global simulation was affordable which lead to frequent incompatibilities,
very high design risks, and far from optimal designs. In addition, minor changes
during the design phase required the re-design of large components or sometimes
even the entire system.
HW/SW/mechanical partitioning required a lot of experience, as it significantly
affected the whole design phase. An incorrect partition impairs system performance,
therefore the design process required several consecutive re-partitions and re-design
steps. Each new partition requires a completely new design, and the whole process
is quite time and money consuming.
In the last years, several HW/SW codesign techniques 1,2,3,4,5 allowed an inte-
grated co-design and co-simulation of HW/SW embedded systems. Yet, most of
them (like VCC, Polis, Ptolemy) are best tailored to control-dominated systems
and require a lot of experience from an electronic engineer. Other tools like System
Generator 4 and DSP Builder 5 are more oriented to data-dominated, therefore they
are more suited to control and automotive problems, but they are mostly limited
to the design of the HW component alone. Instead, another tool like Real Time
Workshop only allows the design of SW systems. In addition, only a few tools
(like Ptolemy) also allow simulation of non-electronic components (in particular,
mechanical, hydraulic, pneumatic, etc.), allowing for an integrated co-simulation of
the whole system. Unfortunately, Ptolemy is not a widely known tool outside of
the electronic community, therefore it is a challenge for a mechanical or control or
automotive engineer to use it.
More recently, we have developed CodeSimulink, an improved HW/SW co-
simulation and co-design flow and and tool 6,7 , which is based on The Mathworks’
SimulinkTM and MATLABTM environments. Due to the widespread diffusion of
Simulink, the use of a co-simulation and co-design tool based on it allows nearly
any non-electronic engineer to easily and effectively describe, simulate, tune, com-
pile and debug any embedded system, and to verify the correctness of its interaction
with the external environment, the controlled plant and the user interface(s).
The CodeSimulink environment allows the designer to describe by means of
nearly standard Simulink blocks any system composed of, for instance: a controlled
system (usually, electrical, electromechanical, hydraulic, pneumatic, etc.), an ex-
ternal environment (usually a human user which generates commands and events),
a digital and an analog HW component, and a SW component, possibly including
the graphical user interface (when the SW component runs on a processor with
such facilities, like a PC running Windows). In practice, CodeSimulink blocks are
standard Simulink blocks with a few appropriate additional properties which de-
scribe the properties of the corresponding either digital HW or analog HW or SW
or non-electronic implementation)
By using CodeSimulink, the designer is able to quickly describe all the hard-
ware and software necessary to manage the entire system, and to drastically reduce
 Simulink-Based Codesign and Cosimulation of a Common-RailTM Injector Test Bench

time to market, while taking advantage of a reliable overall system simulation and
performance evaluation during every step of the design.
This paper describes in great detail a complete practical application of CodeS-
imulink, primarily to develop a commercial test bench for diesel Common RailTM
injection systems. The overall CodeSimulink model describes and contains informa-
tion about all the subsystems, either HW or SW or electrical or mechanical, etc.
and all details which are specific to each implementation choice. For instance, one
can choose:
• digital HW blocks, used to implement the high-speed component, like signal
generators, PID controllers, data acquisition, power PWM interfaces, high-
speed interfaces, etc.;
• analog HW blocks, used to implement some interfaces with esternal world, i.e.
sensors, actuators, signal acqisition, etc.;
• SW blocks, used to implement more complex functions, which often have to
run at a much lower speed than the HW components;
• user interface(s), for isntance, written in Visual Basic (with all its graphical,
data-base, networking capabilities), to interact graphically with the user of
the test bench. Although written in Visual Basic, it directly interacts with
the CodeSimulink environment, either during simulations or with the compiled
HW, transparently to the user;
• external blocks, which used to simulate electromechanical, hydraulic, pneu-
matic, etc. components of the system under test, like fuel pump, injectors,
load cells, etc.
Once the whole system has been described by means of CodeSimulink, it can
be accurately simulated (simulations are bit-accurate). At this stage, simulation
results can be used to tune all relevant parameters such as: controller parameters,
resolution of digital signals, sampling rates, vector sizes, filter taps, etc., in order to
solve trade-offs among performance, cost and size. Simulations also interact with
the same user interface which will be used in the final system, therefore they are
carried out with the same program and parameters which will be used in reality.
The interface itself, as a consequence, is already tested during the simulation phase,
shortening the debug and tuning phases.
Once simulations confirm that system operation satisfies all requirements, the
final implementation(s) can automatically be generated. The user interface remains
unchanged, except for the lower level routines which are changed (transparently to
the user), while the digital HW (respectively, SW) blocks are automatically compiled
into a VHDL (respectively, C) file to be subsequently compiled via Mentor Graphics’
Leonardo SpectrumTM environment (respectively, a standard ANSI-C compiler).
All external blocks are automatically removed as they are only used to simulate the
external environment.
Simulink-Based Codesign and Cosimulation of a Common-RailTM Injector Test Bench

The SW system is then ready to run onto a PC (or any other DSP whenever
Windows-based interface is not required), while the HW system may be downloaded
either onto an FPGA device or a programmable SoC (or even used to develop an
ASIC for very large quantities). Interfaces between HW and SW are automatically
implemented as specified into the block diagram.
In addition, CodeSimulink also supports co-simulation and co-design of multi-
board systems, for instance systems made of several FPGA’s, DSP’s, electromechan-
ical components, etc. (for instance, as many as eight FPGA’s, one PC, one A/D,
D/A board and a data acquisition board, in the test bench described here).
The paper is organized as follows: section briefly describes the CodeSimulink
environment; section describes the Common RailTM test bench; section describes
test metodologies and implementation choices; section describes the system de-
sign and implementation; section describes the graphical user interface and its
interactions with the remainder of the system; section gives some quantitative in-
formation about quality and usefulness of the CodeSimulink environment; finally,
section contains conclusions and final considerations about the whole project.

1.1. Common RailTM injection system

The necessity to reduce fuel consumption, exhaust gases emissions and engine
noise has led to new technologies that substitute the mechanical injection system.
For the most part, very high injection pressure, a proper progress of injection and
a very precise injected fuel quantity are needed to achieve these goals.
The Common RailTM injection system satisfies all these requirements thanks
to a particular high pressure fuel alimentation system and electronically controlled
injector devices.
As shown in figure 1, in the Common RailTM system pressure formation and
injection take place separately. Injection pressure (from 50 MPa to 160 MPa) is
generated by means of a high pressure radial pump, independently from the engine
rate and from the quantity of injected fuel and is then fed to a small tank continually
kept under high pressure, called rail. In the rail, fuel is always ready for injection
through 4 to 6 electrical injectors controlled by an electronic control unit (ECU).
The injection quantity is set by the ECU based on a predefined characteristic curve.
The ECU regulates fuel pressure via a control valve present on the pump. The fuel,
at a fixed pressure, is delivered to the rail through high pressure pipes.
Each electrical injector delivers an appropriate quantity of fuel (depending on
duration of excitation) and atomizes the mixture of air and fuel into the cylinder.
The ECU controls the quantity of injected fuel on the basis of a predefined char-
acteristic curve and an engine model. The ECU also applies appropriate current
waveform to the injectors to reduce energy consumption.
The ECU interprets the driver’s intentions (via the accelerator pedal) as well
as the instantaneous engine work conditions (engine speed, torque, temperature,
acceleration, etc.). More specifically, the camshaft position sensor returns piston
 Simulink-Based Codesign and Cosimulation of a Common-RailTM Injector Test Bench

Fig. 1. The Common RailTM electrical injection system.

phase position and the air mass meter measures the quantity of induction air to
regulate according to the provisions about polluting gases emissions.

2. The CodeSimulink Co-Simulation Environment

CodeSimulink is a HW/SW codesign environment for rapid prototyping of data-
dominated embedded systems previously developed by our group 6 . The name
derives from binding two words: codesign and Simulink. The former word indicates
the nature of the tool, while the latter word indicates that the tool is heavily
based on the well known Simulink tool from The MathWorksTM . More precisely,
CodeSimulink acts as an extension of the The Mathworks’ Simulink environment.
The choice of using the well-known Simulink tool as a user interface (which
has recently been used also by other codesign tools 4,5 ) allows most non-electronic
engineers and practitioners to approach the power and the capabilites of HW/SW
codesign techniques.
The elementary SimulinkTM design unit is the block (e.g. a gain, an integra-
tor, a non-linear function, etc.), whereas the CodeSimulink design unit is the ex-
tended block. Every extended block is equivalent to a block taken from the standard
SimulinkTM library. Each extended block also contains some additional parameters
to tune its final HW/SW implementation (like signal resolution, numeric represen-
tation, pipeline level, etc.).
To co-simulate hybrid systems, CodeSimulink extended blocks and standard
Simulink blocks can easily be mixed together, to describe and simulate, respec-
tively, HW/SW subsystems interacting with non-electronic subsytems.
Each extended block can be implemented indifferently in one of several possible
technologies: i) software, that is a piece of code running on the embedded CPU
Simulink-Based Codesign and Cosimulation of a Common-RailTM Injector Test Bench

core; ii) digital, that is a piece of hardware that can be either mapped onto an
(embedded) FPGA, or on a standard-cell based VLSI block; iii) analog, that is a
piece of hardware mapped on either an analog full-custom, or an analog standard-
cell block; iv) external, which merely emulates the component of the system external
to the chip/board (for instance, the system to be controlled), and therefore need
not be converted to either hardware or software. External blocks are inserted only
with the purpose of overall system-level simulations.
Digital technologies can be designed in one of several architectures. A few exam-
ples are: synchronous parallel, synchronous bit-serial (leading MSB), synchronous
bit-serial (trailing MSB), synchronous systolic, asynchronous parallel, adiabatic par-
allel, etc. (not yet all supported). Different architectures can also be chosen for
analog technologies, such as: single-ended voltage mode, differential voltage mode,
single-ended current mode, differential current mode, pulse width modulation, fre-
quency modulation, etc.
Interconnections between external and internal blocks are handled by means of
appropriate interface circuits (namely, appropriate extended blocks, like A/D, D/A
converters, PWM and encoder drivers), which are inserted between HW (sometimes
SW) and external blocks.
Signals can either be scalar, vectors or matrices. Vectors and matrices can either
be time-serial or parallel. Most other Simulink-based codesign tools support only
scalars. As for all other co-design tools, complex signals, although supported by
SimulinkTM , are not supported by our design flow and libraries. They must be
converted to a pair of real signals when necessary.
As numerical resolution in digital implementations entails, at present we only
support fixed point data of any length, whereas signal encoding can either be signed
or unsigned, or sign+modulus (and soon reduced numbering systems). For software
implementations, signals can use each data type supported by the chosen CPU. For
further details see 6 .
During functional simulation, each extended block simulates exactly the corre-
sponding HW or SW or external block, implementing that function with the selected
implementation parameters. For instance, this is useful to understand the effects of
limited data resolution or sampling time or representation on both system behavior
and implementation performance (like number of gates, power dissipation, speed,
etc).
The CodeSimulink developement environment is made of the following main
components:
1. a complete extended blocks library;
2. additional parameter inheritance capabilities for hierarchical systems;
3. a simulator (namely, the standard Simulink simulator)
4. a performance evaluation toolbox for fast feedback on designer implementation
choices;
 Simulink-Based Codesign and Cosimulation of a Common-RailTM Injector Test Bench

5. some utility functions, for instance for converting from standard Simulink
diagrams to extended block diagrams;

6. a SimulinkTM to structural VHDL compiler, made as a wide set of MATLABTM

m-file functions;

7. a Real-Time Workshop target for generating C source code, made up of a set of

Target Language Compiler (tlc) files, including files for S-Functions inlining
during Real-Time Workshop compilation. This target is an adaptation of
the Embedded Real-Time Target, part of the Embedded Coder MATLABTM
toolbox, and is called CS ert.

The environment is provided with a new parameter inheritance management

which extends the capability of the standard SimulinkTM environment, allowing
also parameters in popup menus and edit boxes to be inherited. As this is for-
bidden in the standard SimulinkTM environment, most other tools do not support
it, yet its capabilities are fundamental in the co-design of HW/SW systems). In
particular, an appropriate extended block, called hierarchical block, acts as an ”ad-
vanced” subsystem, from which parameters can be inherited. When a hierarchical
block is double clicked on, its mask dialog is dynamically generated upon the inher-
itance information obtained automatically from its underlying block diagram. The
designer shall therefore only specify the inherited parameters into the underlying
blocks, without having to explicitly create a mask for the hierarchical block, as
it occurs in standard SimulinkTM . To specify that a parameter is inherited, it is
enough to use an identifier beginning with the two characters ”I ”.
During the planning phase, the designer has been given the chance to specify
which kind of board he/she is targeting, selecting from a list of supported com-
mercial boards (for instance, Sundance SMT355, SIDSA HSDT100, custom boards,
etc.). For each supported board he/she also has to choose the one DSP and an
FPGA model, if the selected board supports more than one. If a board is not yet
supported, a custom target board can be selected, for which several DSP and FPGA
devices can be chosen. The environment also allows to target SW-only or HW-only
boards.
The target board, DSP and FPGA selection can be done through the dialog box
associated with an ad-hoc digital hardware interface block, which must be present
in every extended block diagram. By means of its mask, the designer also has to
set up the system clock frequencies, global reset signals, and interrupt periods.
The CodeSimulink environment also has two additional features. The first is a
performance evaluation framework, which allows for the evaluation of architectural
choices in terms of cost and performance (e.g. latency time, system throughput,
maximum clock frequency, energy dissipation, number of cells for digital HW im-
plementation, code size and clock cycles for SW implementation, etc.). Each ex-
tended block is associated with one or more performance models, which provide an
accurate performance estimation starting from functional and implementation pa-
Simulink-Based Codesign and Cosimulation of a Common-RailTM Injector Test Bench

rameters chosen by the designer. Partial performance figures are then tied together
to compute the estimated global performance figures.
The second CodeSimulink feature is a mixed-technology compiler. If one consid-
ers to a CodeSimulink diagram as separated into various components, one for each
board (in a multi-board system) and for each allowed implementation technology,
the mixed-technology compiler translates every component of the diagram in source
code (either C or VHDL) suitable for describing each component of the system with
the chosen technology and for the chosen target system or board (e.g. C for SW,
and VHDL for HW, with board-dependent pinout selection). Source code is then
automatically compiled to obtain files in a format that can be immediately down-
loaded, for instance, onto a target board, thus obtaining a ready-to-operate system
working exactly as the designer has planned and simulated.
The capability of simulating together HW and SW subsystems, offers the de-
signer the chance to quickly trade-off between different HW/SW partitions, to reach
lowest costs and best performance. At present, partitioning is either manual or semi-
automatic but the tool offers quick performance evaluation figures, allowing quick
evaluation of each partitioning. An automatic partitioning tool is also under study,
yet for the class of applications for which this co-simulation and co-design tool is
intended, a real automatical partitioning does not really offer significant improve-
ments, as partitioning is often driven and constrained by other considerations.
Other functionalities like automatic resolution and sample time optimization,
the ease of hybrid simulation of the overall system (including electromechanical,
hydraulic components, etc.), or the capability of tuning several non-electronic per-
formance parameters (for instance, mechanical stresses, jerk, worst-case error, sig-
nal spectra, etc.) are all available in CodeSimulink, as they are usually much more
valuable than automatic HW/SW partitioning (see section ).
The design methodology in itself is not new; there have been recent commer-
cial offerings of hardware-only implementations of SimulinkTM libraries 4,5 . Our
approach, however, provides the designer a more flexible environment, open to new
improvements that the user can bring forth on his own, and allows the selection
of hardware/software trade-offs to achieve lowest costs and best performances, and
allows to target several kinds of platforms or boards of FPGA’s.

2.1. Interaction with Simulink and hardware

To develop a unique user interface able to interact (to exchange variables) with
either the Simulink simulation environment or the physical Common rail test bench
we used the object oriented programming language feature proper to Visual Basic.
We built two different Visual Basic objects:
SimulinkConnection (interacting with Simulink) and HardwareConnection (inter-
acting with HW via the EPP), which have the same properties as they have to
manage the same variables. Two methods (WriteValue and ReadValue) maintain
the same name in both objects, but they work in different ways: the first reads and
 Simulink-Based Codesign and Cosimulation of a Common-RailTM Injector Test Bench

writes Simulink signals during simulation, while the second reads and writes values
in the HW through parallel port.
Once the Visual Basic objects are defined, we can then declare the communica-
tion objects using either:

• Dim CommonRail As SimulinkConnection

• Dim Commonrail As HardwareConnection

The GUI code uses object properties and methods without really knowing how
methods treat properties.
The SimulinkConnection object uses a MatlabTM connection and writes instruc-
tions directly into the MatlabTM command line. The connection with Matlab is
made by the command:

Set Matlab = CreateObject("Matlab.Application")

The Execute property of that MatlabTM object enables to execute MatlabTM com-
mands, by passing them as arguments of the property itself. Using the MatlabTM
commands set param and get param it is then possible to start the simulation
(1), stop the simulation (2), write (3) and read (4) interface blocks parameters
of Simulink model. Respectively:

1. Matlab.Execute ("set param(gcs,’Simulationcommand’,’Start’)")

2. Matlab.Execute ("set param(gcs,’Simulationcommand’,’Stop’)")

3. Matlab.Execute ("set param(’InputBlock’,’Value’,’10’)")

4. Matlab.Execute ("x = get param(’OutputBlock’,’Value’)")

We used a direct access to block parameters rather than the MatlabTM Workspace
because this one isn’t refreshed during simulation, but only at the start and the end
of the simulation itself.
Instead, the HardwareConnection object implements an HW/SW data exchange
using EPP parallel port as communication channel. The operating system suitable
for this work is WindowsTM 98 as it allows for low level communications with HW
peripherals. Operating systems like WindowsTM 2000, NT or XP, need complex
drivers designed ad hoc in kernel mode.
We used a generic DLL (Dynamic Linked Library) which reads and writes values
on a parallel port (for instance WIN95IO.DLL): it is then possible to use the EPP
to exchange couples of memory address and data value with HW connected with
the port using an appropriate communication protocol.

3. Description of the Common RailTM Test Bench

Simulink-Based Codesign and Cosimulation of a Common-RailTM Injector Test Bench

Fig. 2. Common RailTM bench test blocks diagram

Figure 2 shows the block diagram of the common rail test bench, which is made
up of a mechanical and an electrical component.
The mechanical component is comprised of fuel tank, pumps, pipes at low and
high pressure, rail, injectors and all transmission devices. In the mechanical compo-
nents it is possible to distinguish two different circuits of fuel flow: the high pressure
circuit visible in figure 2 (thick lines) and the low pressure circuit (mid-thick lines).
High pressure circuit includes the rail, high pressure pipes and high pressure
injection pump where the maximum fuel pressure reaches 1600 bar. Because of high
pressure, solid and strong connection between the various components is required.
The pipes used for these connections have a big thickness and they are cabled
with nuts. The high pressure pump is assembled together with the discharge valve
(DRV). A 15HP electrical motor drives the pump shaft and the device generates
high fuel flux which generates high pressure inside the rail. The electrical discharge
valve is used to regulate the fuel flux that goes into the rail. It is driven by a PWM
power signal (0 − 3 V). The rail is a small tank used to stabilize the fuel pressure
when the injector gets fuel for engine injection. The pressure sensor is connected
at one side of the rail.
A low pressure circuit includes fuel tank, source fuel pump, fuel filter, fuel
heating and low pressure pipes. The low pressure circuit gathers all fuel returns
and carries them into the tank. The pipes which are made of rubber do not warrent
strong connections because very low pressure goes into them. The source fuel pump
is always active during every test. Its task is to carry the fuel from tank to high
 Simulink-Based Codesign and Cosimulation of a Common-RailTM Injector Test Bench

pressure pump. Fuel filter and fuel heating are together in only one device. The first
task of this device is to clean the fuel from impurities that could destroy the pump
and injector. The second task is to separate the water from fuel, if present, and
discard it. The last task is to heat the fuel during every test through an electrical
heater.
The first component of the electrical component is the PC, which is used to
control and monitor every event during the test. Through a parallel port (visible in
figure 2 as thick arrows) the PC communicates with a board bearing an FPGA and
an AD/DA system. Seven power interface boards are connected to the previous
board to manage injectors and the discharge valve. The PC communicates also
with another AD/DA National board to take information from six load cells used
to evaluate the quantity of fuel being injected. An electrical panel is assembled on
the left side of test bench. In this panel, there are all the electrical protection and
necessary systems to transform the line voltage to low power DC voltage to supply
electronic circuits and high power 60 V DC supply to drive electrical injectors. A
15HP electrical motor is placed in a test bench mechanically connected through two
pulleys with a 1:1 transmission ratio and a belt to the pump shaft. The motor is
controlled by a commercial inverter with a closed-loop speed control. The rotation
speed of the shaft (therefore of pump) is set via an analog voltage (0 − 10 V).
The motor has to operate mostly at a constant speed (speed may be changed,
according to the test parameters set by the user), therefore we have decided, that
the easiest and cheapest solution is to set the desired voltage via a commercial PCI
digital/analog converter board driven directly by the graphical user interface (no
real-time requirement).

4. Tests and Implementation Choices

The test bench is intended to test the four majors components of a Common
rail system: the high pressure pump, the discharge valve, the pressure sensor and
the electrical injectors. The first operation of every test is to remove the device(s)
that will be tested from the car and place it/them in the common rail test bench.
It is possible to test all devices together or separately. If the test is for only one
device, it must use the other components supplied with the test bench.

4.1. High pressure pump and discharge valve test

The pump test consists of verifying that a desired pressure (user selectable from
100 to 1, 600 bar) can be obtained at different pump shaft speeds (user selectable
from 100 to 3, 000 rpm). Pump test relies on proper operation of pressure sensor.
To ensure that this is not defective, a second, calibrated, pressure sensor is mounted
on the same rail, to crosscheck that the main pressure sensor works within tolerance
limits.
The electrical discharge valve regulates the rail pressure by varying the flux of
fuel which returns to the fuel tank. The electrical valve is controlled by a simple PID
Simulink-Based Codesign and Cosimulation of a Common-RailTM Injector Test Bench

controller sampled at about 5 kHz and is actuated by a 12 V, 5 A PWM waveform.

The same control loop remains active during all the other tests in order to keep
rail pressure constant at the desired value.
As implementation entails we had at least three choices for the PID and the
PWM generation. The first one was to let a SW PID run on the same PC which was
supported the user interface, however this required the use of a real-time operating
systems, ruling out Windows and all the annexed user-friendly design environments
(i.e. Visual Basic).
The second choice was to let a SW PID run on an additional DSP or microcon-
troller, possibly with built-in PWM generators and analog/digital converters. This
choice increased the overall systems costs (because of the high performance DSP
required for this and all the other tests). It also increased design time and time-
to-market (as real-time systems are often cumbersome to design and debug), and
an additional interface and protocol had to be established between the PC (user
interface) and the DSP.
The third choice was to develop an ad-hoc HW PID with its PWM generator,
directly connected to the analog/digital converter chip, and interfaced to the PC
(user interface) via, for instance, the PC standard parallel port. This choice would
be the cheapest (as an FPGA and analog/digital converter chip are already present
in the system for other purposes) but it would normally require a much longer design
time and time-to-market. At the end we chose the third solution, as the use of the
CodeSimulink environment significantly reduced the design time and time-to-market
down to a value comparable with the second solution.
The latter choice also allowed to simulate the HW control loop by modeling the
whole system (user interface (setpoint), control loop (PID), pump + valve (valve
model), rail + injectors (rail model); see figure 3 which shows the CodeSimulink
diagram of the whole test) together in the same environment, prior to implementing
the different components. The PID controller is implemented with the CodeSimulink
digital HW technology, onto an FPGA device (see section ). Pressure sensor is read
via a 12-bit analog/digital converter.
The valve is tested by means of the same pump test described in this section.
The only difference is that, during valve test, the drive voltage of the pump is also
monitored and checked against tolerance limits.

4.2. Pressure sensor test

The rail pressure sensor is tested by comparing the measured pressure with that
of another pressure sensor, which is known to operate properly. The former sensor
is the sensor under test (the one removed from the engine), while the latter is part
of the test bench and is supposed to operate properly.
The pressure sensor test is always active in the background, as it continuously
monitors both sensors and compares measured values against each other, when rail
pressure varies between the lower and upper limits. If the error overpasses a given
 Simulink-Based Codesign and Cosimulation of a Common-RailTM Injector Test Bench

Fig. 3. Pressure control system.

threshold, an alarm flag is raised.

As the implementation entails, we had at least two choices. In the first choice,
the PC acquires both sensors’ voltages at a low rate (compatible with the presence
of standard Windows operating system) and a piece of SW compares the two values.
In the second choice, an ad-hoc HW acquires and compares the two signals via an
analog/digital converter. We have chosen this solution, since we had already chosen
a HW implementation for the pump and valve test, and this seemed to be the most
obvious choice, as it required barely any additional HW and design effort.

4.3. Electrical injectors test

Injectors can work under many different conditions with a wide range of fuel
pressures and opening interval duration. A so-called working point is the combina-
tion of rail pressure and injector opening time. For each working point, an injector
should atomize a given amount of fuel,
Electrical injectors must be driven with the current waveform shown in figure 4,
which ensures to keep the same functional conditions as in the engine (where this
is set by the ECU, depending on the accelerator pedal position). At first, a high
current pulse (I peak ) must be supplied to win the inertia of injector mechanics,
followed by a lower constant current (I hold ), which holds injector nozzle open for a
variable period.
Peak and hold values are in the order of 20 A and 10 A, respectively, while rising
and falling times (T1 , T3 and T5 ) are in the order of 100 − 500 µs. The duration
of the current plateau T4 depends on the working point, and may range between
500 µs and 10 ms. To guarantee such values, the supply voltage must be as high as
60 V.
First of all, typical injector working points and the corresponding injected quan-
tity are obtained with a golden sample and stored in a database. The evaluation of
Simulink-Based Codesign and Cosimulation of a Common-RailTM Injector Test Bench

Fig. 4. Injector current waveform

correct injector functionality is therefore obtained by comparing the injector under

test against the values stored in the database.
In the test bench, peak and hold current values and duration are set by the user
interface, which retrieves data from an injector database made of golden sample
data.
As implementation entails, here also we had a few different choices. The first
one was to control current with a closed loop, either HW or SW, while the second
one consisted of generating a predefined voltage waveform computed on the basis
of the required current waveform and the electrical model of the injector.
We selected the second implementation, as it was by far the simplest and offered
comparable performance (from simulations). At this point we again considered a few
different alternatives to compute and generate voltage waveforms and we selected
the following one, as it offered the best cost and time-to-market: the PC handles,
via the user interface, the injector data base from which the test working points are
retrieved. It then computes the current waveform and the corresponding voltage
waveform, on the basis of injector characterization (see section ).
We chose to compute waveform parameters in SW (see section ), as this handles
mathematical operations in a more straightforward way and no real-time operation
is required (waveform is computed only once at the beginning of each test). The
PC then communicates via the parallel interface to an ad-hoc HW signal generator
the waveform parameters, pulse repetition rate and test duration. The HW signal
generator is implemented on an FPGA and drives as many H bridges as there are
injectors. Injector are actuated on a rotation basis to avoid superposition of current
surges. The HW can easily handle a 60 kHz PWM rate and very short rising and
falling edges of the waveform, without requiring any intervention from the PC or
the user.
The design of such a complex system, with many interacting agents (user, data
base, parallel interface, waveform generator, PWM generator) has been feasible in a
limited time only thanks to the use of the CodeSimulink design environment, which
made the chosen alternative the optimal implementation.

4.4. Measurement of atomized fuel

 Simulink-Based Codesign and Cosimulation of a Common-RailTM Injector Test Bench

Fig. 5. R-L series step input response

Data-sheets of typical injectors specify that the nominal values of injection are
a few mm3 per stroke, a very small quantity to be sensed. To increase accuracy
with such low fuel volumes, expensive measurement instruments should be used. It
is therefore necessary to actuate a sufficient number of injections to weight the fuel
injected with cheaper load cells and obtain appreciable precision.
Test bench is able to test up to six electrical injectors simultaneously. Every in-
jector atomizes fuel in a small glass. Through the glass it is possible to immediately
view if the injector is totally damaged (no fuel in the glass) or if the atomization is
not homogeneous, whereas the fuel quantity is measured by means of as many load
cells, which are sampled at 10 Hz by a commercial analog/digital board plugged
into the PC, and directly displayed on the PC monitor.

4.5. Automatic injectors characterization

As shown in figure 5, electrical injectors behave as resistive-inductive (R − L)
loads, which are only approximately known. Since we chose an open-loop generation
of current waveform, based on the generation of an appropriate voltage waveform
(see section ), we must rely on accurate electrical parameters.
To obtain a good measurement of electrical parameters of each injector (namely,
Rj and Lj ), we have applied a 10 V voltage step to every injector, and we have
measured the current flowing into it by means of an appropriate current sensor.
The current waveform in the j th injector should be (see figure 5):


R
VP − Ljj (t − t0 )
ij (t) ≈ 1−e (1)
Rj

where V P is the step input voltage, t0 is the edge time. By measuring the asymptote
and the derivative of the measured current waveform in t = t0 , one may infer the
resistance and inductance of the injector.
Unfortunately, the above formula is only approximate, for four reasons: the
inductor is slightly non-linear, the sampling frequency cannot be too high, the
measurement is noisy, and the drive voltage is a PWM waveform (60 V, 16 % duty
cycle), therefore characterization of Rj and Lj is not straightforward.
Simulink-Based Codesign and Cosimulation of a Common-RailTM Injector Test Bench

Our aim was to find a simple test that allows an accurate measurement of the
resistance and the inductance of each injector. Subsequently we decided to use a
neuro-fuzzy approach to estimate of the injector electrical parameters. This choice
was derived from the good results obtained with these techniques applied in many
different fields; the neuro-fuzzy methodologies have been used to characterize noisy
curves with a limited number of parameters 9 . The extraction of the electrical
parameters from each injector current waveform, is done by using a two-layer feed-
forward neural network WRBF (Weighted Radial Basis Function) 8 .
This network has only one input which represents time t, one output that is the
current i(t), one exponential hidden neuron with zero-order and one linear output
neuron with the same order.
The free parameters of the first layer are null center (c1 ) and threshold (s1 )
while the synaptic weight (w1 ) is equal to the inverse of the time constant τ ; for the
output layer we chose a unit center (c2 ), a null threshold (s2 ) and a synaptic weight
(w2 ) that represents the ratio between the step input voltage Vp and resistance Rj .
We could estimate Rj and Lj directly by the free parameters of the trained neural
network with a negligible error.
Mathematical expressions of this neural network are 8 :
−z
h(t) = H0e (t; c1 , w1 , s1 ) (2)

i(t) = y = H0linear (h(t); c2 , w2 , s2 ) (3)

where h(t) is the output of the hidden layer. Since c1 = 0, s1 = 0, c2 = 1, s2 = 0:
 
i(t) = w2 c2 − e−w1 t (4)

To train the network we have used a back propagation algorithm with a few
hundred cycles and with an adaptive training rate for the hidden synaptic weight.
We have tested this technique on different current waveforms that span a good
range of resistance - inductance values.
The results obtained are very good, particularly regarding the estimation of the
resistance, while the value of the inductance is higher; this is due to the limited sam-
pling rate. This conclusion has been reached comparing Rj and Lj estimated values
with measurements of the same magnitudes by means of high precision laboratory
equipment. Those measurements appear in the first two columns of table 1. The
WRBF-n neural network estimates Rj with an average error of about 0.6 %, while
Lj mean estimation error rises to about 3.8 %. The results in table 1 are obtained
with an hidden center training rate equal to 10−11 , an initial hidden weight training
rate equal to 2 and an output weight training rate 0.0025.
As the implementation of the system entails, we analyzed a few alternatives,
then we decided to use the FPGA and its 8-channels analog/digital converter to
sample the six injector currents at about 20 kHz sample rate, then to store measured
 Simulink-Based Codesign and Cosimulation of a Common-RailTM Injector Test Bench

Table 1. Results of Injector Characterization.

R (Ω) L (mH) Rstim Lstim Error R (%) Error L (%)

0.11 0.0825 0.1103 0.084 0.28 1.76
0.11 0.11 0.1098 0.111 0.18 0.49
0.11 0.99 0.1099 1.00 0.068 2.92
0.11 1.3 0.1102 1.3 0.22 0.38
1.32 0.0825 1.315 0.0711 0.33 13.81
1.32 1.32 1.356 1.3 2.75 3.44

Fig. 6. Controlled pressure step response: parameters of the measured curve

values on a FIFO and then to transfer the measured values at a lower rate via the
parallel interface to the PC, where the neural network is run as a piece of SW. The
results of characterization are then used on the PC itself to compute the voltage
waveform accurately (see section ).

4.6. Automatic PID tuning

The pressure control system is regulated by a PID controller, which is character-
ized by four parameters: integrative, derivative, proportional gains and an additive
constant (respectively ki , kd , kp , kc ). The better the chosen PID parameters, the
higher the performance of the control. In fact, the choice of these parameters deter-
mines the pressure waveform which must be as similar as possible to the set pressure
step.
To estimate the quality of the control, we computed three parameters for each
curve: pressure overshoot (ov), static error (es) and settling time (ts), (see figure 6).
As an alternative to a manual choice of the PID gains set through the user interface,
we also used a WRBF-n neural network to create an automatic model. The building
of the appropriate network for this problem has followed sequential steps: first of
all we have created a two-layer neural net to learn the relationship between the PID
gains and the parameters describing the pressure waveform (ov, es and ts).
The neural network WRBF has four inputs (the PID gains ki , kd , kp and kc )
and its outputs are the estimated performance figures (overshoot, settling time and
static error). The hidden layer contains about 70 Gaussian neurons of the second
Simulink-Based Codesign and Cosimulation of a Common-RailTM Injector Test Bench

Table 2. A few results of PID Neural Network Validation.

ki kd kp kc Real ov Estimated ov Error (%)

0.01 0.1 10 5 9.35 9.67 3.4
100 0.1 100 5 7.46 7.55 1.2
1 0.01 0.01 3 2.04 2.9 42
10 0.01 100 2 7.71 7.83 1.5
10 1 0.01 2 0.81 1 23

order, while the output has one linear neuron of zero-order for each of the three
performance figures.
The network has been trained with a back-propagation algorithm; we have col-
lected a set of model simulations and 80 % of them is the training set while the
remainder is used for validation.
The standard error between the real parameters of the pressure waveform and
the neural network answer on a large number of cycles, is near 5 %. Table 2 contains
some results of overshoot system validation:
The next step was to reach the optimal values of PID parameters; this is done
with a gradient descent algorithm, using a sensitivity layer associated with the
neural network described above. With this system we can find the best PID gains
from the parameters obtained by the analysis of the real rail pressure waveform.
At present we are still developing the automatic PID tuning feature.
Another valid approach would be to directly use a neural controller in place of
a standard PID controller. Such a controller could guarantee even better perfor-
mances, but unfortunately it would require a hardware system much larger than
the one we used implementing a simple PID, hence requiring a bigger FPGA chip.

5. System Implementation
As explained earlier, the whole system has been designed, simulated and finally
implemented under the CodeSimulink environment. After the design phase, every
block in the diagram contains all the information about its final implementation.
This allows automatic diagram compilation to obtain an operational system.
We chose HW implementation for high-speed calculations (e.g. pressure con-
trol system), power drivers control management and high rate signal sampling, as
detailed in section .
On the other hand we chose the SW implementation for complex calculations,
such as calculation of time slots (T1 to T6 ) and relative voltages (V1 to V6 ), R and L
of each injector, etc. All these parameters are calculated once for each test session
and then passed to the HW, or just once in a while. The SW implementation is
also used for the user interface management (data input and presentation).
As we can see in figure 7, the interface between HW and SW is implemented by
an Enhanced Parallel Port (EPP).
The PC supervises all the test bench operations. The parallel port transfers
 Simulink-Based Codesign and Cosimulation of a Common-RailTM Injector Test Bench

Fig. 7. The test bench CodeSimulink block diagram (top level).

control and data signals in both directions (from the PC to the HW system and
vice versa). Control signals are used for sub-systems activation and deactivation,
for instance to start up the electrical motor, to start and stop acquisition through
the A/D converters. Data from PC to FPGA carry information either inserted by
the user or elaborated by SW (e.g. time slots and voltages, gain values for manual
PID controller set up, injector characterization step voltage, pressure set point and
so on), whereas data from FPGA to PC substantially carry acquired data (e.g. for
injector characterization and for PID gains automatic neural tuning).
For waveform data acquisition we adopted the maximum sampling frequency
allowed by our A/D - D/A board, that is 15 KHz (60 µs sample period for eight
channels), about 6 times the cut-off frequency of the fastest R-L injector model.
With the chosen sampling frequency, the SW system cannot start conversion or
read data acquired by the A/D converters in real-time through the parallel port,
due to long SW processing times. To sample current waveforms at the established
frequency, the digital HW system (FPGA system) performs the whole acquisition
(150 samples at 15 KHz), storing the data into onboard RAM. Only at the end of
acquisition is the data transferred at a slower rate through the parallel port from
FPGA to SW which is where the elaboration begins.
Regarding PID automatic characterization, we sampled the pressure sensor out-
put voltage at 1 KHz, storing six thousands samples (6 s acquisition time at 1 kHz)
of acquired data into RAM and transferring it to the SW system after the acquisi-
tion. To drive each PWM power driver (H MOS bridge), we need two CodeSimulik
Simulink-Based Codesign and Cosimulation of a Common-RailTM Injector Test Bench

A. B.
Fig. 8. Switching waveform generator: (A) CodeSimulink block diagram; (B) generated waveforms

PWM interface blocks, one for each bridge branch, generating two complementary
PWM waveforms, as shown in figure 8. PWM waveforms are obtained comparing
a sawtooth waveform (blocks sim constant1, sim constant2, sim unit delay) with
amplitude varying from -1 to 1 with a threshold (normalized in the -1 to 1 interval)
representing the signal to be applied to the load (threshold). This way we can drive
the load with positive and negative voltages, and the output waveform could vary
its duty cycle from -100% to 100%. We chose a PWM frequency 128 times lower
than system clock frequency, that is

Fsystem 8 M Hz
FP W M = = = 62.5 KHz (5)
128 128
This frequency is sufficiently higher than the maximum frequency of the current
waveforms driving the injectors (see section ).
The sawtooth waveform is generated as an increasing ramp signal which wraps-
around its value to -1 each time it reaches +1. This is simply obtained connecting
a unit delay block in closed loop with a sum block (see figure 8). Signal wrap-
around is ensured by setting the option wrap-around for the output signal overflow
management of the unit delay block.

5.1. Hardware/software platform

The test bench has been designed as a CodeSimulink block diagram (see figure 7)
and then implemented on the following platforms:

1. one Windows 98TM PC for the SW component (PC + EPP);

2. one FPGA + A/D - D/A custom board (8 channels, 150 kS/s) with an AlteraTM
Flex 10K130 FPGA and 512K×8 flash RAM (FPGA system), developed at tha
Politecnico di Torino;

3. six power interface boards (part in FPGA system, part in Common Rail System),
one for each injector, developed at the Politecnico di Torino for the PWM sig-
nal generation (H MOS bridges);
 Simulink-Based Codesign and Cosimulation of a Common-RailTM Injector Test Bench

4. one National InstrumentsTM A/D DAQCardTM -AI-16XE-50 (16 single ended/8

differential inputs, 200 kS/s) for load cells data acquisition.

The A/D - D/A custom board is clocked at 32 MHz, while we chose to clock the
system implemented onto the FPGA at a 8 MHz, by prescaling the 32 MHz clock.
The six power interface boards are connected directly to one of the FPGA ex-
pansion connectors through a flat cable. Each power board mounts four BUZ22
power MOS transistors (H MOS bridge) driven by a IR2130 power driver, and a
EPM7032SLC44 AlteraTM FPGA, programmable to manage the board input sig-
nals according to each specific application.

5.2. Chosen hardware/software Partition

The test bench system must return test results to the user, hence we need to
interface the physical system with a user friendly interface. For these reasons we
planned to build the test bench in two slices, a hardware and a software sub-system,
interacting with each other, as shown in figure 7.
The SW sub-system (Personal Computer) runs onto a WindowsTM 98 PC. This
system manages the user interface, through which the user is able to set all the
parameters required by the test bench (e.g. test set points and system characteriza-
tion parameters). Another task assigned to the SW sub-system is the visualization
of the data collected during the various test phases, and some other very expensive
calculation if implemented in HW technology, such as the automatic parameters
tuning of a PID on the basis of neural network algorithms. Finally, the PC has to
read the data coming from the six load cells.
The HW sub-system (FPGA system) is responsible for high speed data process-
ing, signal generation, data acquisition and commands the electrical motor shaft
rotation speed through a D/A converter driving an inverter. The high speed data
processing component, which among other things include a PID controller and wave-
form generators, is mainly made of digital HW logic circuits implemented onto
an AlteraTM FPGA. That system interacts with six H MOS bridge power drivers
(PWM), and with A/D devices (ADC) for the data acquisition.
The communication between these two main sub-systems occurs through the
parallel PC port (EPP), driven in Enhanced Parallel Port (EPP) mode, which
automatically assures simple management of protocol and high speed data commu-
nication rate.
The whole test bench has been designed and simulated as a CodeSimulink model
(see figure 7). CodeSimulink allows the designer to set, simulate and tune all the
implementation choices for each single component of the system during the planning
phase, making it possible to evaluate the effects of all the choices by simulation,
and consequently, to fine tune the system before the final implementation.
As the CodeSimulink model holds all the information about the way in which
every component of the system is implemented, the generation of the whole test
bench occurs automatically through a compilation of the CodeSimulink model. The
Simulink-Based Codesign and Cosimulation of a Common-RailTM Injector Test Bench

software system is then ready to run onto a PC while the hardware system may be
downloaded onto an FPGA device. Interfaces between hardware and software are
automatically implemented as specified into the block diagram.

5.3. A detailed example: signal generation

Common RailTM system devices that have to be controlled are the following:
discharge valve, electrical injectors and electrical motor.
The electrical motor driving the high pressure pump is driven by an inverter
with internal closed loop speed control. This inverter is actuated by a direct current
signal produced by means of a digital to analog converter driven by the digital HW
system running onto the FPGA.
Discharge valve and electrical injectors, on the other hand, are actuated by
means of PWM signals produced by proper PWM power drivers. The digital HW
system generates all PWM signals and drives them by means of various parametric
signal generators. Parameter values are written by the SW system through the
EPP interface according to user friendly parameters set through the graphical user
interface.
Signal generator parameters have been chosen to reduce HW complexity. This
way the system comprises only of reset/enabled counters, comparators and mul-
tiplexers. All the calculations of the parameter values starting from user friendly
parameters are made by the SW.

5.4. Pressure set generation and control actuation

To test the discharge valve and the pressure sensor we decided to generate a ramp
pressure reference signal, which drives the pressure control. The ramp is comprised
of a sequence of steps, i.e. height (positive or negative), duration and number
of which can be varied. As the pressure sensor returns a voltage proportional to
the measured pressure (according to the sensor transfer function), the output of
the pressure reference generator is also a number expressed in V, to be directly
compared to the sensor output signal. For this reason, the three magnitudes which
express initial pressure, final pressure and pressure step are converted by the user
interface into equivalent voltages.
To state valve defectiveness, we have to sample the pressure sensor output signal
in the steady state (constant pressure value) which is at the end of every pressure
step and immediately before the pressure reference changes to the next value. In
order to sample that signal, we have to enable an analog to digital converter at a
precise moment and store the data coming from it.
The user sets how many pressure samples to store for data analysis, acquired
through an analog to digital converter at a frequency of 10 Hz.
Figure 9 shows the CodeSimulink macro-block diagram of the pressure reference
generator. Each box is a hierarchical block built with primitive CodeSimulink blocks
(e.g. integrators, derivatives, unit delays, sums, constants, etc.)
 Simulink-Based Codesign and Cosimulation of a Common-RailTM Injector Test Bench

Fig. 9. Pressure reference generator; CodeSimulink macro-block diagram (all HW blocks)

Summarizing, the parameters which customize the pressure reference signal are
the following (see figure 9): initial value of pressure ramp (initialoutput - Volt),
final value of pressure ramp (finaloutput - Volt), pressure step (stepheight -
Volt), number of steps (nstep), time duration of each step (T) in multiple of 1 s,
delay before sampling pressure (T1)
Time durations are compared with the output of a counter (STEP WIDTH COUNTER).
Once the counter clock frequency is set (1 Hz) the maximum step duration is given
by the counter output data width; with 8 bits, in our case, each step can last
(28 − 1) s = 255 s, namely more than 4 minutes.
In order to avoid high pressure pump stress, the pressure reference ramp is then
filtered by a low pass filter (LOW PASS FILTER). The output of this filter is the
pressure reference signal which drives the PID controller.
Other than the pressure reference output set, the generator has two other out-
puts. The first one is the enable signal for the AD converter (AD trigger). The
second one is another signal (envalve) used to enable the PWM driver driving
the valve and the PID input, in order to avoid the uncontrolled rise or fall of the
integrative control component which can cause damages to the electrical valve.
Figure 10 shows an example of pressure reference expressed in bar units; the
generator is enabled at 5 s, and generates a pressure ramp from 500 to 1500 bar
with pressure steps of 250 bar lasting 10 s each. After four steps, the pressure falls
to 0 bar exponentially; at the same time envalve signal goes low (not shown).
The PID controller feeds a single phase PWM driver which, in its turn, drives
the valve. The CodeSimulink PWM block generates a TTL compatible switching
waveform feeding a PWM power driver. That waveform is obtained by comparing
a 5 kHz sawtooth waveform between 0 and 1 with a threshold normalized with
respect to the PWM power driver supply voltage (12 V). The output signal is a
Simulink-Based Codesign and Cosimulation of a Common-RailTM Injector Test Bench

Fig. 10. Pressure reference signal stepping from 500 to 1500 bar, in 250 bar pressure steps, 10 s
duration per step (plotted using the Scope Simulink block)

Fig. 11. Engine rate generator CodeSimulink macro-block diagram

PWM waveform with duty cycle varying in the range between 0 and 1.

5.5. Generation of injector high-current waveform

As we saw in section , an injector behaves as a R - L series circuit which reacts

to a constant input voltage with an exponential current (see figure 5). Given Tk the
time slots in figure 4, for k = 1, 2, ..., 5, if the time constant of the R - L circuit is
either much lower or much higher than Tk for every k, the injector works into the
linear region within each time slot, so we can obtain the current waveform shown in
figure 4 by applying a constant input voltage to the injector during each time slot
as shown in figure 13.A. These voltages are called V1 , V2 , V3 , V4 and V5 respectively.
Since the current must be null before each injector stroke (i.e. during last time
slot T6 ), the last voltage value V6 also must be null. Note that T1 to T5 and V1 to
V5 depend on the desired injector working point, while V6 is always null. The only
 Simulink-Based Codesign and Cosimulation of a Common-RailTM Injector Test Bench

magnitude that depends on engine rate is T6 , which is

6 1
Tk = (6)
k=1 f engine
where f engine is the engine rate, in Hz ( RPM/60). From figure 4 referred to the
j th injector we have:

dij (t) Vk − VR
≈ (7)
dt Lj
hence if

L
Tk  (injector time constant) for k = 1, 2, ..., 5 (8)
R
we can approximate the current function within each time slot as

Vk − R · i0k
ik (t) ≈ · (t − Tk−1 ) + i0k for k = 1, 2, ..., 5 (9)
L
where t is the time, while i01 = 0, i02 = I peak , i03 = I peak and so on. Known the
current waveform, that is the values of T1 (i.e. slope of the linear pieces), Ipeak , T2 ,
Ihold and T4 , we can calculate the voltage values V1 to V5 , action performed by the
SW system.
Every voltage Vk must be applied to the injector with the correspondent time
slot Tk . As the time ramp generator is clocked at f PWM , the time slot durations
are given in terms of number of sample steps at that frequency (Tk f PWM ).
The time ramp generator in figure 11 feeds six voltage function generators
(only one of them is shown in figure 11), each one designed as in figure 12, which
drive the six electrical injectors through as many PWM power drivers.
The function generators are made such that their input t, coming from the time
ramp generator, is compared with the five time slots T1 to T5 assembled together
into vector ttest (while V1 − V5 are assembled into vector vtest). Said t and Vo
respectively the input and output signals of the function generator, when t ≤ T1 ,
then Vo = V1 , when T1 < t ≤ T2 , then Vo = V2 , and so on until t > T5 , when
V6 = 0. In figure 12, Relational operator blocks are used to give an output 1 when
the value of their first input (t) is higher than the value of the second (Tk ). The next
injector stroke begins when the time ramp generator is reset (T6 ), and Vo repeats
its waveform.
The five voltages V1 to V5 are normalized with respect to the PWM power drivers
supply voltage, which is 60 V (see section ). The output of each function generator
drives a PWM H-MOS bridge, as shown in figure 8.
Figure 13 shows the normalized voltage waveform needed to obtain a current
waveform with T1 = 200 µs, Ipeak = 20 A, T2 = 400 µs, Ihold = 10 A and T4 =
800 µs, which are typical values. As we set fengine = 3000 RPM, that waveform
repeats every 20 ms, but figure 13 shows only one waveform pulse to keep it well
visible.
Simulink-Based Codesign and Cosimulation of a Common-RailTM Injector Test Bench

Fig. 12. Voltage function generator: CodeSimulink block diagram.

6. Graphical User Interface

We implemented the Common RailTM test bench GUI using MicrosoftTM Visual
Basic 6.0 language.
As previously described, the design of Common RailTM test bench consists of
two consecutive steps:

• the simulation of the system in the SimulinkTM environment

• the subsequent implementation of the whole system.

During the design of the user interface we aimed at developing a single GUI able
to interact with both simulation and system implementation, by simply changing
the low level communication protocol module. In this way we were able to rate
GUI’s strength and gaps directly from simulation (the simulation graphic interface
is essentially the same one the user will use in the final system).
The MicrosoftTM Visual Basic environment adequately met ours needs: it per-
mitted the straightforward implementation of well-constructed graphical user inter-
faces; its object oriented programming language allows also to quickly modify the
communication protocols with external applications (objects) (see section for more
details).

6.1. The graphical user interface

 Simulink-Based Codesign and Cosimulation of a Common-RailTM Injector Test Bench

A. B. C.
Fig. 13. (A) Simulated voltage waveform (T1 = 200 µs, Ipeak = 20 A, T2 = 400 µs, Ihold = 10 A
and T4 = 800 µs); (B) Simulated current waveform (Simulink scope); (C) Measured injector current
(through a Tektronik current sensor and scope)

The Common RailTM test bench GUI is displayed in figure 14.

It is divided into different frames: Main Setup, Database Editor, Test Functions,
Enabled Injectors, Load Cells, Status Flags and Sensors.
The buttons contained in the Main Setup frame let the user set up the test
bench (selecting injector, sensor and pump type, enabling or disabling injectors,
setting the test function parameters, etc.). By pressing the buttons in the Database
Editor frame it is possible to add or delete an injector, a sensor or a pump from
a database, as well as to modify parameters of each database record. The Test
Functions frame contains buttons that start the Common RailTM test functions
described in section .
The remaining frames are system monitoring frames. The Enabled Injectors
frame contains six LEDs displaying connected and enabled injectors. The six
progress bars in the Load Cells frame display the fuel amount sprinkled by each in-
jector. Finally the Status LED is used to show the system status (busy or stand-by),
while the STOP button breaks in a running test function. We decided to implement
the interaction between user and application using push buttons rather than tradi-
tional WindowsTM application menus: in this way we can emulate the real aspect
of a standard control console, incrementing the user-friendly characteristic of the
application also.

6.2. Interaction with the database

The descriptive parameters of the Common RailTM injectors, sensor and pump
do not need to be manually re-inserted each time we replace a test bench component:
the GUI lets us select the component brand and model directly form database and
provides an automatic evaluation of the needed parameters. The database consists
of three different tables (Injectors, Sensors, Pumps and Car) containing brand,
model, descriptive parameters and working points.
We choose MicrosoftTM Access Database format to store such parameters: it is
easily accessible from Visual Basic environment using MicrosoftTM Jet 4.0 OLE DB
Provider.
Simulink-Based Codesign and Cosimulation of a Common-RailTM Injector Test Bench

Fig. 14. Common Rail test bench Graphical User Interface

6.3. Interaction with the neural networks

The Injector Characterization and Pid Tuning Neural Networks described in
section and section respectively, were initially described in terms of a MatlabTM
function. MatlabTM functions cannot work outside the MatlabTM environment, so
we compiled them with the MatlabTM compiler and translated them into C code.
After a few modifications we compiled the generated code with MicrosoftTM Visual
C++ 6.0 in order to obtain a description of the MatlabTM function in terms of a
DLL that can be directly plugged into Visual Basic code. We can use those Neural
Networks both in simulation and in the final system without any modification.

7. Tool Performance
This paper has described one of the first complete and complex commercial
applications of the proposed CodeSimulink tool. The development of this application
has therefore been a thorough test and performance estimation bench.
Although there is no widely accepted performance figure for a co-design tool,
table 3 tries to give an idea of the capabilities of CodeSimulink environment. It
is clear that, although hand-written VHDL code may lead to a smaller count of
gates when compared with any co-design tools, the preliminary optimization phase
(mainly, finding out optimal resolution) is more complex, therefore a far from opti-
mal design has to be accepted, which increases the actual gate count.
On the other hand, a hand-written code on DSP is faster to develop, although
performance may not be sufficient, except if a much more expensive DSP is used; the
 Simulink-Based Codesign and Cosimulation of a Common-RailTM Injector Test Bench

Table 3. Performance results of CodeSimulink was applied to the proposed Common RailTM
test bench. DT stands for design time, in person-days (including simulation of overall system,
parameter tuning, performance evaluation, etc.); G stands for the number of gates (only for HW);
NA stands for Not Applicable (meaning that the method does not allow that function). Cost only
includes FPGA+DSP+PC; costs in brackets refer to solutions which do not meet specifications,
either because of insufficient speed, or for the lack of graphical interface.

Design method model press. contr. wavef. gener. injec. charac. sensor test Graphical I/F
developm.
DT G DT G DT G DT G DT US$
Hand-written VHDL NA 10 2,520 20 3,250 NA 1,250 1 120 NA (500)
code on FPGA
Hand-written C 10 2 - 5 - 10 - 1 - NA (400)
code on DSP
Hand-written C 10 5 - 7 - 8 - 1 - 90 3,500
code on PC
DSP Builder 3 7 - 12 - 8 - 1 - NA (500)
System Generator 3 7 - 10 - 10 - 1 - NA (500)
CodeSimulink 3 3 2,130 5 1,750 8 1,530 1 150 40 1,500
Post-CodeSimulink - - 1,850 - 1,530 - 1,270 - 120 NA 1,500
optimization

major limitation of a DSP is the need to generate 14 independent PWM waveform

(namely, 2 per each injector and for the pressure control valve, to account for
dead and switch-off times of MOS transistors). Any inexpensive DSP has as many
PWM timers, and none of them can generate the waveform with the desired 100 ns
resolution. In addition, DSP do not allow for the straightforward development of a
graphical interface (including data-base and internet access of results).
Similarly, hand-written code on a PC is slightly slower to develop than the DSP
code (due to the real-time requirements), but it allows for a straightforward de-
velopment of a graphical interface. Unfortunately, any PC cannot generate PWM
waveforms with the desired resolution, unless appropriate add-on boards are in-
cluded, which significantly increases the cost.
The last three design methods listed in table 3 all refer to Simulink-based design
tools; among all the three, only the CodeSimulink tools allows complete design
and simulation of the whole system, including interactions with the real graphical
interface and the model of the electromechanical components of the test bench. A
gate count is not provided for the other two tools (namely, DSP Builder and System
Generator), as only a demo version of the tool has been used and only a limited
effort was placed to evaluate them.
It is clear from that table, that the CodeSimulink design environment allows for
a very quick design time and generates a near-optimal design; the final system cost
is the lowest among all solutions analysed. If an optimal system were required, a
post-CodeSimulink VHDL optimization phase can be carried out manually, which
would reduce overall gate count. This last phase is meaningful only for very large
production quantities, where a 20% reduction in gate count can (slightly) impact
cost.
Simulink-Based Codesign and Cosimulation of a Common-RailTM Injector Test Bench

8. Conclusions and Final Considerations

This paper has introduced CodeSimulink, a novel HW/SW codesign tool based
on Simulink and Visual Basic for graphical interfaces. The tool has successfully been
applied to the design, simulation, tuning, compilation and testing of a commercial
test bench for Common RailTM automotive components under development at the
Politecnico di Torino.
The test bench has been fully described and manually partitioned into a HW, a
SW and an external component (where the SW component also includes a graph-
ical user interface), simulated (including models for the electromechanical compo-
nents) and compiled onto an FPGA board (for the HW component), which in-
cludes AD/DA converters, a PC running Windows (for the SW component) and a
few programmable PWM power drivers (with a small on-board FPGA each), plus
a commercial AD/DA board plugged into the PC. The whole system is therefore
composed of eight programmable modules (seven HW plus one SW), all of which
have been described as a single CodeSimulink model, all of which have been auto-
matically compiled by the built-in compiler.
The use of CodeSimulink has drastically reduced the design time of the whole
system from twelve man-months (estimated) down to 2.5 man-months (total time),
therefore reducing time-to-market correspondingly. The reliability of the designed
system has also been significantly improved, thanks to extensive simulations of the
overall systems (instead of separate HW and SW simulations). In addition, docu-
mentation and maintenance of the manufactured system is also made much easier,
as the whole system is both specified and compiled within a single environment.

References

1. T. Zhang, K. Chakrabarty and R. B. Fair, “Microelectrofluidic Systems: Modeling

and Simulation”, CRC Press, Boca Raton, FL, 2002.
2. T. Zhang, K. Chakrabarty and R. B. Fair, “Integrated hierarchical design of micro-
electrofluidic systems using SystemC”, Microelectronics Journal, vol. 33, pp. 459-470,
May 2002.
3. T. Zhang, K. Chakrabarty and R. B. Fair, “Design of reconfigurable composite mi-
crosystems using hardware/software co-design principles”, IEEE Transactions on
Computer-Aided Design of Integrated Circuits & Systems, vol. 21, August 2002, to
appear.
4. Xilinx. The Xilinx System Generator for SimulinkTM , 2002.
http://www.xilinx.com/xlnx
5. Altera. DSP Builder, 2002. See http://www.altera.com/products
6. L.M. Reyneri, F. Cucinotta, A. Serra, L. Lavagno, “A hardware/software Co-design
Flow and IP Library Based on Simulink”, in Proceedings of the Design Automa-
tion Conference, Las Vegas, June 2001
7. L.M. Reyneri, M. Chiaberge, L. Lavagno, B. Pino, E. Miranda, “Simulink-Based
HW/SW Codesign of Embedded Neuro-Fuzzy Systems”, in Int’l Journal on Neural
 Simulink-Based Codesign and Cosimulation of a Common-RailTM Injector Test Bench

Systems, June 2000

8. V. Colla, L.M. Reyneri, M. Sgarbi, Neuro-wavelet parametric characterization of
Jominy profiles of steels, Integrated Computer-Aided Engineering 7 (2000) 217-228
9. E. Bellei, D. Guidotti, R. Petacchi, L.M. Reyneri, I. Rizzi, “Evaluation, Classification
and Clustering with Neuro-Fuzzy Techniques in Integrated Pest Management”, in
Proceedings of the IWANN Conference, Granada, Spain, June, 2001