Simulink-Based Codesign and Cosimulation
Simulink-Based Codesign and Cosimulation
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.
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
phase position and the air mass meter measures the quantity of induction air to
regulate according to the provisions about polluting gases emissions.
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;
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.
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:
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:
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:
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.
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).
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.
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)
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
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 ).
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
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.
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
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.
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.
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)
PWM waveform with duty cycle varying in the range between 0 and 1.
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
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).
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)
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
References