Aim – Validate the whole ECU, not the source code inside the ECU in a labbased environment
ECU is part of a closed-loop circuit where actuator output is constantly fed back
to the sensor input.
ECUs are real-time, and there is little to no time gap between receiving input
and producing output
A real-time embedded system (Scalexio) is required to simulate the conditions
of sensors, actuators and other relevant ECUs so that the target ECU believes it
is in an actual car.
The plant model for Scalexio is developed in MATLAB Simulink, and is made by
a developer or by HiL engineers. Control Desk is a GUI software used for
manual testing (wherein there are very few test cases involved). Automation
Desk is a GUI software used for automated testing (wherein there are a
plethora of test cases involved). Motion Desk provides a 3D animation of the
car, and allows a more graphical representation of the test cases.
Scalexio Processing Unit – All GUI software of host PC communicate with the
processing unit of Scalexio. In turn, Processing Unit communicates with the IO
cards, power supply, fault insertion units etc
Scalexio Programmable Power Supply – Used to supply power to the ECUs.
Power is one of the key inputs to the ECU, but that needs to be simulated as
well in our rigs.
IO Cards – The signals generated within Scalexio by the plant model need to be
interfaced to the external ECU, and this is done with the help of IO Cards (the
ones with 90 pins). CAN, LIN, Analog, Digital, PWM etc types of signals are
interfaced.
Fault Insertion Units – All ECUs follow standard ISO procedures for their codes
with respect to faults (known as DTCs). These DTCs can be tested by purposely
shorting 2 pins and checking if this has been logged inside the ECU. This is done
by virtue of the Fault Insertion Units, controlled by our GUI software on host
PC.
IOCNET – Communication protocol for each module inside Scalexio (between
processing unit and IO cards for example). In vital rigs, there exist master and
slave embedded systems (for vital 13, the powertrain system is the master,
while other adjacent systems are slaves) and their communication is also
governed by IOCNET. Even communication between host PC and the Scalexio
processing unit is governed by IOCNET
Structure of Scalexio
Additional
CAN/LIN/FlexRay
support channels
Load
To ECU
To ECU
To ECU
Connec
-tion
Scalexio Processing Unit
Power Supply
The I/O cards to ECU are connected using (hypertrack?) wires, and there are
around 90 pins (5 columns x 18 rows), and the kind of signal going through
each pin can be configured using Configuration Desk. Back of the Scalexio has
an ethernet cable that communicates with the host PC.
Connecting ECU to Scalexio
Just like how the embedded system has hypertrack cables, even the ECU has
counterpart hypertrack cables, and the cables from both meet at a common
point called local terminal block of the HiL rig.
Configuration Desk
Create a Simulink model first. Then open Configuration Desk and add the
Simulink model when creating your new project. Add Scalexio as hardware
(with static IP address). Configuration Desk allows us to generate different
types of signals, and map it to a particular hardware channel (I/O pin) of the
I/O card. Dspace generally shares documentation of which pin transmits which
signal.
Through Configuration Desk, we can control the amount of voltage passing in
each channel, mapping each channel to a pin, assigning a reference ground pin
(specific pin can have a specific ground, doesn’t have to be a generic ground)
If a certain block is created in Configuration Desk, but was not present in the
plant model, we can export it to the Simulink model from Configuration Desk.
Control Desk
The voltage assigned in control desk will not necessarily be exactly equal to the
voltage given by Scalexio power supply to the specified pin. We thus add a gain
block in the Simulink model between the voltage source block and the Scalexio
block (this block always contains an orange arrow symbol)
Power Supply Control and Power Switch
Power Supply Control provide the necessary voltage and current to power the
ECUs. The power is first provided to Power Switches (which act as relays) since
there are many ECUs that need to be powered on and off individually
Constant Blocks
After mapping the function to the model in Configuration Desk, the same is
mapped back to Simulink. We can control the inputs to the Scalexio blocks
through constant blocks.
Start Build Button (Configuration Desk)
Once the Start Build button in Configuration Desk is clicked, the Simulink model
is converted into a set of codes that gets flashed inside Scalexio.
Go Online Button (Control Desk)
Load the sdf file (saved in configuration desk or Simulink?) into Control Desk,
and assuming that Control Desk is already linked to the Scalexio system, click
on Go Online to activate the plant model inside the system.
CAN Simulation
Sending a CAN signal through a particular channel in Scalexio using a DBC file,
and receiving the same signal on another channel in Scalexio. Unlike other
signal types where we dragged and dropped signal chains in configuration
desk, we need to go to the plant model in Simulink and visit the library
browser. CAN requires 3 blocks (created in the following order) viz. general
setup (root directory et al.), controller setup (configuring CAN controller inside
Scalexio), and main block (browse DBC file and tell what messages and signals
must be simulated, and how to simulate them).
Each Simulink model can only have one general block, as many controller setup
blocks as number of channels, and a main block for each controller setup.
When a controller setup block is configured in Simulink, an S-function is said to
be created.
Main Block’s node selection allows us to select which ECU’s we want to
consider on our CAN communication protocol.
TX Message lists the corresponding messages of all our selected ECUs from
node selection (as stored in the DBC file) and these messages will be simulated.
CAN Bus Theory
Used for internal communication between ECUs inside cars. It is a multi-master
serial bus
CAN 2.0, introduced in 1991 by Bosch, introduced Standard CAN (11 bit
identifier) and Extended CAN (29 bit identifier)
CANFD 1.0 (CAN with Flexible Data Rate) was introduced by Bosch in 2012,
which increased speed of transmission by 5-8 times that of classic CAN.
ECUs are connected by 2 twisted pair wires (bus wires), and network is
terminated with 120-ohm impedance.
Bus Wire 1 is known as CANH (CAN High Voltage) and Bus Wire 2 is known as
CANL (CAN Low Voltage).
Differential voltage = CANH – CANL is used to identify if the network is to be in
dominant or recessive state.
If CAN High > CAN Low, this is considered to be a dominant state, and
interpreted as bit value 0
If CAN High <= CAN Low, this is considered to be a recessive state, and
interpreted as bit value 1.
ECU that sets CAN channel with dominant value first gets the channel. Other
ECUs will stop sending dominant value once they detect that another ECU is
sending dominant state before them.
2 types of CAN signals are high speed CAN (500 kbps to 1 mbps) and low speed
CAN (up to 125 kbps)
The message that one ECU sends to another one is called a CAN Frame. The
format of a CAN frame is shown below.
11-bit CAN FRAMES
SOF– Start of frame bit
Identifier – Gives a unique ID to each message, and also highlights the priority
of the message. Lower binary value implies higher message priority.
RTR – Remote Transmission Request is used to define if the frame is meant for
remote transmission or actual data transmission. Dominant – data
transmission. Recessive – remote transmission.
IED – Identifier Extension Bit identifies if the frame is a 11-bit frame or a 29-bit
frame. Dominant – 11 bit. Recessive – 29 bit.
r – Reserve bit which is always set to dominant
DLC – Data Length Code defines length of data sent on the frame.
Data Field – Contains the actual data to be transmitted
CRC – Cyclic Redundancy Check
CRC DEL – CRC Delimiter sets the boundary for CRC
ACK – Acknowledgement slot. Dominant – Data Receiver Mode. Recessive –
Data Transmitter Mode
ACK DEL – ACK Delimiter sets boundary for ACK
EOF – End of the CAN frame.
There also exists IFS (Inter Frame Spacing) to provide sufficient space between
CAN frames.
29-bit CAN FRAMES
Types of CAN Frames/Messages
Data Frame – Contains data for transmission from transmitting ECU to receiving
ECU.
Remote Frame – Data transmitted from receiving ECU to transmitting ECU. RTR
Bit is set to recessive. DLC = length of requested message and data field is
empty.
Error Frame – Transmitted when there is error in transmission. Contains Error
Flags (superposition of error bits contributed from different ECUs), Error
Delimiter.
Overload Frame – Sent when there is a delay required by receiver. Frame sent
after IFS bit. Contains Overload Flag and Overload Delimiter.
Bit Stuffing
When actual message contains a long chain of dominant or recessive bits, a
counterpart bit is stuffed in between the frame to convince the network that
the values are not sticking to dominant or recessive by default.
Types of CAN Errors
Bit Error – Identified by a transmitter ECU, when it sends a dominant bit to the
CAN network, but observes the opposite logical level on the CAN network.
Bit Stuff Error – Identified by a receiver ECU, when it receives 6 consecutive bits
of same logic without the bit stuffing.
Form Error – Identified by receiver ECU when there is invalid logical level
present in SOF/EOF fields or ACK/CRC delimiter fields (these fields have
predefined values)
ACK Error – Identified by transmitter ECU when transmitter sends all messages,
but ACK slot is not made dominant by receiver ECU.
CRC Error- Identified by receiver ECU when CRC calculated by receiver does not
match CRC transmitted in the message.
CAN Node Error Detection
Every CAN node controller in the CAN bus tries to detect errors within
messages as per CAN protocol. If a node detects errors, the node transmits
error flags and error delimiters and destroy bus traffic. CAN nodes use specific
error counters to detect faults and perform error confinement (Tx Error
Counter and Rx Error Counter).
CAN Error States
Error Active – This state is activated when Transmit Error Counter (Tx) is less
than 127 or Receive Error Counter (Rx) is less than 127. Node will send out an
error frame, containing active error flag indicating other ECUs that there is
error in the message and error delimiter. Error flag has 6-12 dominant bits, and
delimiter has 8 recessive bits.
Error Passive – 128 < (Tx Error Counter, Rx Error Counter) < 255 leads to a
passing error flag being generated. This means there could be an error in the
message, or in the ECU as well. Error flag has 6-12 recessive bits, and delimiter
has 8 recessive bits.
Bus Off – CAN node disconnects from the CAN bus for some amount of time.
Waiting time is for 128 occurrences of 11 consecutive recessive bits in the
network.
CANFD
FlexRay