Beruflich Dokumente
Kultur Dokumente
MARK BARTISH
MARK BARTISH
TRITA-CSC-E 2011:065
ISRN-KTH/CSC/E--11/065--SE
ISSN-1653-5715
KTH CSC
SE-100 44 Stockholm, Sweden
URL: www.kth.se/csc
Abstract
This diploma project was performed at Scania CV AB in Södertälje.
The goal was to investigate embedded powertrain control systems with
respect to their startup and shutdown processes which are extra sensi-
tive phases in these systems. That is due to the fact that these control
systems, which are called Electronic Control Units (ECUs), interact
through a communication bus called a Controller Area Network (CAN).
A unit that sends faulty data may affect other ECUs on the same com-
munication bus. All ECUs on the same bus do not start simultaneously
and the variation in startup times must be taken into account. Dur-
ing shutdown, the sensitive process of saving of Non-Volatile Memory
(NVM) data is initiated. Should something go wrong during this pro-
cess the result may be corruption of operational data and End-Of-Line
configuration (EOL). Also misleading error codes may be built.
Scania therefore wanted to have one or several test cases for system
test of the powertrain ECU software focused specifically on these areas.
The author of this report performed a technical analysis of the “problem
areas” of the ECUs as well as failure report analysis in order to deter-
mine what the areas of greatest risk are. Based on this analysis, the
system functional requirements on the ECUs were identified and test
cases were developed. The work resulted in a total of two test cases
each of which is related to an identified problem area. The test cases
are divided into test flows which are a set of direct instructions how the
tests should be performed. Each test case verifies one or more system
functional requirements and are meant to be implemented as scripts for
the test automation rigs. The actual implementation in test automation
scripts has not been done as part of this diploma work, only a manual
conduction of the test flows in a laboratory environment. Also a theo-
retical study of different techniques for software testing was performed.
The result of this study is presented in the theory chapter of the report.
Referat
Analys och systemtest av inbyggda drivlinestyrsystem i
tunga fordon under uppstart och nedstängning
Detta examensarbete utfördes vid Scania CV AB i Södertälje. Syftet var
att undersöka inbyggda drivlinestyrsystem i lastbilar och bussar med av-
seende på problem i samband med uppstart och nedstängning som är
extra känsliga moment hos dessa styrsystem. Detta på grund av att sty-
renheterna kommunicerar genom CAN (Controller Area Network) och
en styrenhet som eventuellt skickar felaktig data påverkar alla andra på
samma kommunikationsbuss. Alla system på nätverket startar inte ex-
akt samtidigt därför måste hänsyn tas till variationer av uppstartstider.
Vid nedstängning kan sparande av NVM-data1 i EEPROM vara ett pro-
blem, en oväntad avstänging av ett styrsystem kan resultera i korrupt
data. Ovanstående problem kan leda till att missvisande felkoder bildas.
1
NVM = Non Volatile Memory
Contents
1 Introduction 1
3 Theory 15
3.1 CAN - Controller Area Network . . . . . . . . . . . . . . . . . . . . . 15
3.2 Theory behind CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1 Real-time System . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.2 Differential bus . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.3 Data transmission . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.4 Bit stuffing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.5 Bit arbitration . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 Software Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.1 Module Testing (also called Unit Testing) . . . . . . . . . . . 21
3.3.2 Function Testing . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.3 Integration testing . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.4 System testing . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.5 Acceptance Testing . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4 Other Types of Testing . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.1 Regression testing . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5 Software Development and Testing Procedures . . . . . . . . . . . . 22
3.5.1 The V-model . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.6 Test Techniques: Black Box Testing . . . . . . . . . . . . . . . . . . 23
3.6.1 Decision Tables and Decision Trees . . . . . . . . . . . . . . . 23
3.6.2 State Transition Testing . . . . . . . . . . . . . . . . . . . . . 24
3.6.3 Equivalence Class Partitioning and Boundary Value Analysis 26
3.7 White Box Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.8 Gray Box Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.9 Smoke testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.10 Non Functional Testing . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.11 How far should we test? . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.12 Formal Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4 Methods 31
4.1 Technical Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Failure Report Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3 Requirement Identification . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4 Test Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.5 Developing the Test Cases . . . . . . . . . . . . . . . . . . . . . . . . 32
5 Results 33
5.1 Technical Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1.1 CAN messages and signals . . . . . . . . . . . . . . . . . . . . 33
5.1.2 Signal and Component Statuses . . . . . . . . . . . . . . . . . 33
5.1.3 Start Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1.4 Cranking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1.5 Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3 Test case 1: EMS – EEC Communication, CAN timeouts detection . 37
5.3.1 Requirement Identification . . . . . . . . . . . . . . . . . . . 37
5.3.2 Test Techniques . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3.3 Test Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3.4 Testing the Test Case . . . . . . . . . . . . . . . . . . . . . . 45
5.4 Test case 2: EMS Shutdown . . . . . . . . . . . . . . . . . . . . . . . 46
5.4.1 Requirement Identification . . . . . . . . . . . . . . . . . . . 47
5.4.2 Test Techniques . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.4.3 Test Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.4.4 Detect an Abnormal Shutdown and Set a DTC and Internal
Event (INTE) . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.4.5 Possibility to Cancel a Shutdown in Progress . . . . . . . . . 52
5.4.6 Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6 Conclusions and Suggestions for Future Work 57
6.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2 Future Work Suggestions . . . . . . . . . . . . . . . . . . . . . . . . 58
Bibliography 61
Nomenclature
E2 See EEPROM
J1939 The SAE standard for CAN communication defining some of the signals
that are sent between control units
OPC Opticruise
S8 A version of EMS
U15 An input signal used for wake up of the ECUs. It is 0 V if ignition key is
OFF and the same level as U30 if ignition key is ON (DIN 72552)
U30 An input line for the main power source to the ECUs (DIN 72552)
Introduction
Today, electronic control systems are used in almost all motorized vehicles. Elec-
tronic controllers consist of computer hardware and software that constantly reads
input signal values from the sensors connected to it and based on these values cal-
culates the output signals to the actuators, in other words controls the system.
They are called Electronic Control Units (ECUs) – a denotation that will be used
throughout the report.
The ECUs control different parts of a vehicle’s function, from the most vital, like
fuel injection in the engine, to less important like radio and cab heating system.
As the complexity of every vehicle’s electrical and electronic system grows, so does
the need to systematize the ECUs. It is not possible neither would be desirable to
have one single control unit for the whole vehicle. For the ability to modularize
there needs to be several ECUs, one for each function. This of course leads to a
need for ECUs to be able to communicate with each other. A standard, named
CAN1 was developed for this purpose.
This master thesis project was performed at the System Test group within the
department for development of powertrain control systems at Scania Research and
Development. The objective was to analyze operation of powertrain ECUs during
their start-up and shutdown phase, memory initialization, non-volatile data man-
agement (EEPROM data), file handling and communication establishment as well
as sensor/actuator signals and CAN-signals with signal statuses and related DTCs
(Diagnostic Trouble Codes). After this analysis a list of software SFRs (System
Function Requirements) was made which consists of the requirements already de-
fined by other documents at the department as well as the test developer’s own
1
CAN = Controller Area Network
1
CHAPTER 1. INTRODUCTION
defined requirements. The latter may be requirements that are parsed out of SFDs
(System Function Descriptions) but not explicitly stated there. The ultimate aim
was to develop one or several test cases that cover SFRs, a process which included
choosing of test techniques and test platform.
2
Chapter 2
As mentioned in the introduction digital electronic controllers really made their way
into the automotive domain during the last decades. A considerable part of Scania
Research and Development (R&D) is involved in development of these control sys-
tems, commonly known as embedded systems.
Embedded systems have similarities to the desktop computers in the sense that
they also have a microprocessor and surrounding hardware, such as motherboard
and memory chips. However unlike desktop computers they are not general purpose
machines. They are designed, both in hardware and software, to perform a very
specific task, like controlling the operation of an engine. Hardware resources like
CPU and memory are often much more limited in embedded systems compared
to desktop computers. Also the operating systems in embedded applications does
usually not contain such services as virtual memory management which puts much
stronger requirements on memory management in application software in such sys-
tems. Another dissimilarity with the desktop computers is the human interaction.
Some embedded systems lack direct human interaction of any kind while others
have a different kind of communication with the user than a desktop computer.
There may be light emitting diodes (LEDs), small displays, relays and switches and
similar devices used for user interaction.
3
CHAPTER 2. BACKGROUND AND PROBLEM STATEMENT
Figure 2.1. ECUs in a Scania truck. For the meaning different colors see fig. 2.2
Not all of the ECUs used in Scania vehicles are developed by Scania. Some are
purchased from external suppliers but many of the ECUs shown in fig. 2.1 are de-
veloped by Scania and this applies to all of the powertrain ECUs which are named
GMS1 , EMS and EEC (not shown in fig. 2.1).
4
2.2. EMS - ENGINE MANAGEMENT SYSTEM
- Powertrain ECUs
Figure 2.2. Topological view of a CAN network in a typical Scania vehicle. The
three different communication buses (red, yellow and green) make a logical division of
ECUs in three groups. ECUs on the same bus communicate with each other directly
while any communication between ECUs on different buses are controlled by the
Coordinator ECU. Each one of the buses may operate at different bit rates. The
red bus interconnects the most critical ECUs for a vehicle’s function and operation
safety. The yellow contains less critical but still important ECUs and the green is
for systems which does not have any impact on the operational safety of a vehicle
(however some ECUs on the green bus are responsible for providing information to the
driver that may be considered safety critical). Not all ECUs are directly connected
to one of the three buses, an example of the one that is not is the EEC which directly
communicates only with the EMS.
hardware versions of EMS over past years. The current one is named S8. The differ-
ences from the previous S7 is mostly in software. The largest software modification
with respect to S7 is that S8 is now based on what is called Common Platform
5
CHAPTER 2. BACKGROUND AND PROBLEM STATEMENT
2.2.1 Hardware
EMS S8 has 140 connector sockets pins to sensors and actuators including four
CAN-pairs, one for the red CAN bus, one for the EEC sub-bus, one for internal
development use only and one that is currently unused. [Scania Internal Documen-
tation]
2.2.2 Software
From the software point of view the EMS consists of different components (or layers).
Common Platform (ComP) which may be seen as the lowest level software
(i.e. closest to the hardware). ComP contains software for direct signal I/O, signal
processing a part of non-volatile memory (NVM) management and interacts closely
with the LLAP. ComP also contains code that translates physical signals (measured
in Volts) into engineering units. ComP can be seen as the “foundation” and is used
in multiple ECUs (all powertrain ECUs).
6
2.2. EMS - ENGINE MANAGEMENT SYSTEM
Low Level Application software (LLAP) responsible for transmission and re-
ception of CAN messages, encoding and decoding CAN messages from signals ac-
cording to Scania CAN specifications and timeout diagnosis. It also is responsible
for some hardware checks, AD conversion and diagnosis of sensors and actuators.
Since this layer contains parts that are directly involved in the start-up and shut-
down process, this one is analyzed quite thoroughly.
High Level Application software (APPL or HLAP) contains managers (which
in turn contain modules) that control and monitor fuel injection, combustion, gas
exchange, after-treatment and so on. These are of limited relevance to this thesis.
Virtual Sensors (VSEN) Irrelevant to the project. Will not be described.
File manager (FILE) is responsible for non-volatile data reading and writing
to/from EEPROM as well as the RAM mirror which is a mechanism to make data
normally residing in EEPROM to be read into RAM during execution for faster
access. During shutdown the data is written back to EEPROM.
Run-Time Database (RTDB) manages signals that are cross-layer accessible
within the unit.
Commonly used utilities (UTIL) is not relevant to the report and will therefore
not be described
7
CHAPTER 2. BACKGROUND AND PROBLEM STATEMENT
• Manual gearbox
• Comfort shift
The manual gearbox is purely mechanical which means that the driver manually
controls shifting of the gears by moving the shift stick into right position. The
automatic gearbox obviously needs some sort of controller but since it is developed
outside Scania, it is outside the scope of this description. The Opticruise and
Comfort Shift on the other hand are developed by Scania and will be described in
greater detail below.
Scania Opticruise and Scania retarder are controlled by a control unit named OPC
(a logical controller within the physical GMS unit) which currently (year 2011) is
at version OPC5.
8
2.4. EEC - EXHAUST EMISSION CONTROL
Figure 2.5. An illustration of the more and more restrictive emission tolerance from
heavy road vehicles in the EU.
9
CHAPTER 2. BACKGROUND AND PROBLEM STATEMENT
Figure 2.6. An illustration of the SCR process. The SCR unit is controlled by
EEC3.
contains urea and is injected into the exhaust system of a vehicle where it undergoes
a catalytic reaction and is degraded into water and nitrogen.
A separate ECU called Exhaust Emission Control system, EEC is responsible for
controlling this process. The EEC is located on a sub-bus to the EMS on CAN,
meaning it can only communicate to EMS directly. Communication to other ECUs
on the red CAN-bus must go through EMS (see fig. 2.2).
Figure 2.7. A VCI unit that is used to connect a computer to the diagnostic port
on a Scania vehicle
OBD is present on every modern vehicle, this is a legislation requirement for diesel
vehicles sold in the European Union since 2004 [WPCAN]. OBD is a generic term
referring to a vehicle’s self-diagnostic and reporting capability [OBD]. OBD-II is a
connection interface standard for a 16 pin connector that enables an external device
10
2.6. THE PROBLEM
11
CHAPTER 2. BACKGROUND AND PROBLEM STATEMENT
ECU that does not wake up properly within the required time limit will make other
ECUs degrade signal statuses for the signals that are contained in CAN messages
expected from the failing ECU. During cranking (starter engine operation) a lot of
electrical current is consumed by the starter engine and this causes a temporary
decrease in supply voltage which may make some ECUs shut down, or even worse,
entering an undefined state. When ignition key is switched to OFF position the
powertrain ECUs are expected to perform a well defined and controlled shutdown
which includes saving some operational data, adaptations, diagnostic information
and similar data to non volatile memory (NVM). The problem is to investigate
which areas are the most problematic during start-up and shutdown and how can
test cases be developed to perform a system test of the powertrain ECUs developed
at Scania with the focus on correct start-up and shutdown.
12
2.7. TEST PLATFORMS
awake, or for any other purpose. Also manipulation of signals is possible through
the break-out box. The ECU COO provides a diagnostic port for connecting a com-
puter to the vehicle and perform operations like DTC reading and programming of
some parameters. It is also possible to connect a PC to the CCP4 port allowing
real-time logging of internal variables in the ECU. Logging of signals sent on CAN
is also possible by connecting a listening device to CAN_L and CAN_H contacts
on the break-out-box and using appropriate PC software. The one used at NE is
XCom, an internally developed application used for diagnosis and programming of
parameters by KWP2000 protocol (see 2.5.1). Logging and manipulating of ECU
internal variables and CAN signals is done with the help of ATI Vision (Accurate
Technologies Inc). Since reading of internal variables is done by reading specific
memory addresses in the ECU, a database which contains a mapping between vari-
able names and memory addresses is loaded into Vision.
4
CCP = CAN Calibration Protocol
13
Chapter 3
Theory
The increased demands in the automotive industry drove the development of a com-
munication bus system adapted to embedded microcomputer systems that would
fulfill high transmission rate demands, have good real-time properties and be robust
and cheap. By the beginning of 1990’s many vehicle manufacturers developed their
own bus concepts and it became difficult for the suppliers to support the different
systems. Each large manufacturer attempted to make their own solution become
an international standard. A couple of these bus system solutions continued to be
used in the mid-90’s. One of them was CAN. CAN - Controller Area Network is a
standard developed by Bosch in the 1980’s in order to fulfill the increasing demands
of European automotive industry. It was later also accepted by the American au-
tomotive industry due to successful use in the Europe. CAN was officially released
in 1986 by SAE - Society of Automotive Engineering as a Recommended Practice.
CAN data link layer and some aspects of physical link layer is ISO-standardized,
ISO-11898.
15
CHAPTER 3. THEORY
In figure 2.2 we can see a typical ECU network in a Scania vehicle. There are
three buses: red for vital and safety critical ECUs, yellow for not so critical but
still important ECUs and finally green for comfort function controllers. These three
buses are interconnected through a coordinator ECU (COO). Coordinator acts as
a gateway for messages that need to travel between ECUs on different buses since
the buses typically operate at different bit-rates. Currently (year 2011), the red bus
is operated at 250 kbit/s as do the yellow and the green buses.
One can find many examples of both hard and soft real time applications in auto-
motive industry. A so called drive-by-wire systems which have some use in trucks
and buses do use communication networks (like CAN) to control the throttle. A
late response of such system may result in an uncontrollably accelerating vehicle
(at least until the driver reacts and activates the brakes) which can be directly dan-
gerous.
16
3.2. THEORY BEHIND CAN
CAN is a system that clearly is hard real-time. A late response of a CAN controller
(unit within an ECU that is responsible for physical layer CAN communication)
can be damaging to a vehicle.
Figure 3.1. CAN differential bus. In a differential bus, there are two states: domi-
nant (logical 0) and recessive (logical 1). The states are based on voltage difference
between the CAN_L and CAN_H lines. As can be seen in table 3.1 recessive state
is given by CAN_L and CAN_H at the same voltage level and dominant otherwise.
The sequence given in the figure is 0101
Recessive Dominant
Min Nominal Max Min Nominal Max
CAN_H 2.0 2.5 3.0 2.75 3.5 4.5 Volt
CAN_L 2.0 2.5 3.0 0.5 1.5 2.25 Volt
Table 3.1. Voltage levels of the differential bus that gives recessive resp. dominant
logical state on bus in a transmission.
A dominant bit “wins” over a recessive bit if a conflict of two simultaneous trans-
missions is arisen. See 3.2.5
17
CHAPTER 3. THEORY
Control CRC
Arbitration Field Data
Field
32 Bits Field Delimiter
6 Bits
S S I R E
Identifier
O Identifier R D T r r DLC Data Field CRC ACK O
Ext.
F R E R 1 0 Field F
Bits 1 11 1 1 18 1 1 1 4 0 - 64 15 1 2 7
No Bit
Bit Stuffing
Stuffing
Data frame
A frame that contains ordinary data of up to 8 bytes in length. This type of frame is
referred to later in this report as CAN-Message. The format for this type of frame
is given below:
18
3.2. THEORY BEHIND CAN
Remote Frame
CAN messages may be either periodical or sent only on request. In the latter case
a request must be made by the node that desires to receive information. In this
case the requesting node sends a remote frame, which looks as a data frame but
with two differences from it: RTR bit is recessive in a remote frame and there is no
data field in a remote frame. The fact that RTR bits is recessive in a remote frame
makes, in case a data frame and a remote is sent simultaneously, the remote frame
to lose arbitration so that data frame is transmitted first on bus and the remote
frame must be resent.
Error Frame
A node that detects a fault may send a message that violates bit stuffing rules. By
sending 6 bits of the same polarity, either dominant or recessive a node notifies the
other nodes on network that it discovered the fault. Other nodes will transmit error
frames also. An error frame consists of a 6 consecutive either dominant or recessive
bits and 8 recessive bits that are an error delimiter. Dominant 6 bits indicate an
active error flag and is sent by a node that detects an error while 6 recessive bits is
sent by a node that detects an active error flag on the bus.
Overload Frame
Overload frame is a way for a receiving node to indicate to the sending node that it is
busy at the moment. The overall layout is very much like to that of an error frame.
Figure 3.3. A data field of a CAN Message containing 64 bits of data. In this
example it consists of 5 signals each using 12 bits. We see bytes on the vertical axis
and bits on the horizontal. Bits are given from right to left. A part of each signal
name is hidden since they have information class ’Internal’. We see five different
temperature signals in the depicted CAN message.
19
CHAPTER 3. THEORY
A CAN message contains up to 8 bytes (64 bits) of data which contains one or
more signals. A signal can range from one bit to 64 bits in size and different signals
within the same message can have different length in bits. In fig. 3.3 we see how a
layout of signals within a message can look. In this particular case all signals have
the same lengths. The layout of each CAN message must be known by both the
sending and the receiving node on network.
The last ten bits of a frame in fig. 3.2 i.e. CRC delimiter, ACK-bits and End-
of-Frame-bits are not subjected to bit stuffing. Neither are the three inter-frame
bits. Bit stuffing implies that there may be more bits to send over bus than the
frame contains. The worst case number of bits to send over bus is given by
n−1
ns(n) =
4
where n is number of bits in the stream and ⌊x⌋ means to floor x (giving the largest
integer smaller than or equal to x). [CANTIMING, eq. 13.1]
20
3.3. SOFTWARE TESTING
21
CHAPTER 3. THEORY
The model in 3.4 is simplified. The points are generalized and the exact ones are de-
fined depending on the application. Also, software development (as well as testing)
is an iterative process. Testing is performed continuously during the development
22
3.6. TEST TECHNIQUES: BLACK BOX TESTING
Code
at module level and system level. Acceptance level testing is done immediately prior
to a release often together with the customer.
The concepts described below will be referred to later in the report therefore a
brief presentation of the most important software testing types and techniques are
given in the subsequent section.
The technique basically means that all variables in a set of rules are listed and
combined. An example of a decision table is given in tab. 3.2 The first quadrant
lists all the conditions and condition entries in the second quadrant. In the third
or fourth quadrants we have actions and action entries respectively. A condition is
something that is easy to qualify as either fulfilled or not, i.e. engine output torque
within [200 1000] Nm, gearbox in neutral or not, functional degradation due to a
DTC enabled or not and similar. An action is something that should or should
23
CHAPTER 3. THEORY
1 2 3 4
Condition 1 T T F F
Condition 2 T F T F
Action 1 Y Y N Y
Action 2 N N Y Y
Action 3 N Y N Y
Table 3.2. Decision table example. T = True, F = False
not be done when a set of conditions is fulfilled. In tab. 3.2 we have a complete
list of all possible combinations of two conditions which are 22 = 4, in general 2n
condition combinations are possible given n conditions. The strategy is then to
rule out inconsistent combination of conditions which are often present. It may
also be the case that one condition rules all other out. After simplifying the table
to only contain valid combinations of conditions we can use heuristics to choose
which cases to test. Generally each column in the table is a test case. However
there is an exponential explosion on the number of columns with increasing number
of conditions. NEVS made a summary of pros and cons of decision tables which are:
Pros Cons
Good survey Exponential growth with the num-
ber of conditions
Test cases directly from the table Difficult to identify all the condi-
tions
Easy to limit number of test cases Important test cases may disappear
during simplification
24
3.6. TEST TECHNIQUES: BLACK BOX TESTING
E8
Transaction request correct
Perform transaction, eject card
E2 E6 S3
Correct card, Correct PIN, Waiting
S1 S2
Ask for PIN Ask for transaction for
Waiting Waiting
for a Card E3 for PIN transacti
Wrong PIN 3 times, on
Block Card
E4 E7
E1 E5
Cancel Wrong transaction
Wrong Card inserted,
Transaction, Wrong PIN entered, Request,
Eject card Ask for PIN again
Eject card Ask again
E9
Cancel
Transaction,
Eject card
Figure 3.5. Here we see a simplified picture of an ATM transaction process. Here
we see 3 states and 9 transitions in this finite automaton model.
7. All events that should not trigger a transition: this verifies system robustness
[TDP]
25
CHAPTER 3. THEORY
-∞ 0 3000 ∞
class 1 (invalid) class 2 (valid) class 3 (invalid)
Figure 3.6. Illustration of equivalence class partition and boundary value analysis.
Here we have three intervals. ω < 0 rpm, 0 ≤ ω ≤ 3000 rpm and ω > 3000 rpm.
As an example we see in fig. 3.6 that a continuous numerical variable such as the
engine speed is divided into three equivalence classes. In order to test an engine
controller software, how it reacts to different sensor values we may manipulate the
sensor to give any value we want in order to test the software reaction. We can
choose these values wisely so we only have to test a few values in each equivalence
class and have a very high probability to discover a deviation (error) instead of
testing all possible values (this number is finite since the measurement resolution is
limited). Experience shows that tests of values on the boundaries usually have the
highest probability to discover an error (boundary value analysis).
26
3.8. GRAY BOX TESTING
However, modifying a data repository does qualify as gray box, as the user would
not normally be able to change the data outside of the system under test. Grey box
testing may also include reverse engineering to determine, for instance, boundary
values or error messages.
The above points are important to bear in mind during the development process. It
is also important to let the experts in respective area to perform these assessments.
As for an example, usability is in focus at an early stage of the system design and
should be done by the experts in usability. It is not a good idea to let test developers
without specialized knowledge to handle the questions concerning it. [TDP, p.96]
27
CHAPTER 3. THEORY
2. The number of discovered deviations (errors) are less than a limit value we
define.
3. The cost of finding more errors is larger than the estimated value loss due to
undiscovered errors.
[TDP, p. 269]
Each of the above mentioned criteria on its own has its weaknesses. The fact that
we do not find any more errors may mean that we are not doing the tests right and
not that there are no errors. The decision that the cost is higher than the gain from
performing more tests is a subjective assessment that is difficult for a test developer
to perform. The 5th criteria is a deadline that is decided outside the testers domain
and is not related to quality of the tests but a business assessment on when the
product shall be released. Several of the mentioned criteria together shall be used
in order to decide when the product is ready for a release.
Sufficient Quality
As mentioned, it is often not the testers that decide when a product is released.
However a tester should be prepared to answer the question what opinion he/she
has about the quality. The answer should be well founded. According to James
Bach’s view, what he calls a good enough quality, it can be summarized in four
points (it refers to the product).
• Further testing would, the current situation and all parts considered, do more
harm than help.
28
3.12. FORMAL METHODS
[BACH]
The bottom line here is that several criteria must be taken into consideration to-
gether before deciding that testing is finished and the product is release-ready.
29
Chapter 4
Methods
The overall aim of this project is to contribute to the work aimed at making the
powertrain ECU software less prone to problems during start up and shutdown.
A natural first step in this work is to investigate what makes the ECUs prone to
start up and shutdown problems. By using technical analysis and completing the
investigation with an analysis of failure reports we identify a number of areas that
are considered to be the most high risk areas for the ECUs during start up and
shutdown. The work process itself was largely based on the steps described below.
31
CHAPTER 4. METHODS
database often contained more detailed information that is usable in order to find
the actual cause of the problem.
1
CAN Communication Manager in the LLAP layer
2
Non Volatile Memory Manager
32
Chapter 5
Results
In EMS, LLAP1 is responsible for monitoring CAN messages and indicating a time-
out when a signal fails to be received by EMS when it is expected. This indicating is
done by setting a signal status, that is traveling along with the signal from LLAP to
APPL through RTDB. The signal value itself should be set to some pre-programmed
default value.
1
See 2.2
33
CHAPTER 5. RESULTS
• is flawless
• is possibly affected by an error that is present in the system
• is affected by an electrical or non-electrical error
• does not exist in the current configuration
A signal is a software variable that is transferred between different parts of
software which most of the time are physical quantities like Volt, Bar, Kelvin etc.
A signal is usually transfered together with a signal status. Signal status is encoded
using 8 bits and is contained in the same C-struct as the signal value. Signal status
are indicating whether the signal
• is flawless
• is possibly affected by an error that is present in the system
• value is a good replacement value
• value is possibly a bad replacement value
• value has a plausibility error
• is not available or based on a nonexistent component
At the ECU start up, the signal status is initialized to INIT meaning that the signals
are not classified as good or bad at all until a specified amount of time has passed
since power up of the ECU.
5.1.3 Start Up
A measurement of start up times of two ECU was performed. A measurement device
(Ipetronik M-SENS) was connected to the S8 U15 signal through a break-out-box
along with the CAN1 channel which made it possible to record the U15 signal in
the same graph as all the CAN signals sent by EMS on the red CAN bus, using
ATI Vision. The difference between the time point where U15 becomes high (24 V)
and when the first CAN signal is sampled is considered the start-up time. This was
performed on a live vehicle. Five iterations of this measurement was performed and
the result is that an average start up time was 0.2733 s with a standard deviation
of 0.0017. See fig 5.1.
Further, a number of failure reports from different kinds of test vehicles indicate the
resetting of duty cycle data when starting with a low battery voltage as a problem
area. These problems should be handled at module level and/or ComP level. Other
reports point out possibly false or misleading DTCs with a variety of causes at start
up. Some of the reported problems are nearly impossible to test at the system level
and should be investigated by the developers at module level. Others seem to be a
result of a previous incorrect shutdown or file saving.
34
5.1. TECHNICAL ANALYSIS
U15 is turned on
5.1.4 Cranking
It is a known phenomenon that engine start causes a short drop in the supply voltage
from the battery since the starter engine in a heavy vehicle requires a massive
amount of electrical current. Technically a driver must first turn the ignition key
to ON position which gives U15 signal to all the system ECUs. Only after that
can the engine be turned on by turning the key to the START position. Also, the
engine management system EMS must be fully up and running in order for it to
be possible to start the engine. This diploma project is not focused on the engine
start up but more on the ECU start up, however this phenomenon is still interesting
since it may affect the ECU behavior due to the voltage drop.
5.1.5 Shutdown
When the driver turns off the ignition key, the U15 signal is broken and the software
of the ECUs detects it which makes the software initiate the shutdown process of
the ECU. However the ignition key turn-off is one of the several conditions for ECU
shutdown. Just to mention a few examples: the engine controller, EMS must ensure
that the engine is standing still, the gearbox controller, GMS must check that the
neutral gear is in and the SCR system controller EEC must sometimes perform a
regeneration process which may take some time during which the controller must
be running. Also, most of the ECUs have a set of data that is saved to non-volatile
memory during shutdown so it can be read at the next start up. This includes but
35
CHAPTER 5. RESULTS
Figure 5.2. A starter motor does require a lot of electrical current from the battery.
Batteries in heavy trucks normally give 24 V DC. But as we see, the heavy current
consumption during engine start may make the voltage level to drop significantly
below 24 V. This may affect the ECU software. Here we see the U15 signal level
(which is the same as U30 provided ignition is ON and 0 V otherwise. The step
at 4.3 s is due to ignition key turn to on. At 5.2 s the ignition key is turned to
ENGINE START position and the engine starts. Later when the engine is started -
the generator produces about 28 V.
is not limited to duty cycle data, DTC and freeze-frame2 data, adaptation data etc.
This data is saved at shutdown and an ECU must not power itself down until the
saving process is complete. Also there are kinds of data that is not allowed to be
written to NVM areas at shutdown. An example of the latter is End-of-Line (EOL)
configuration data. This data is critical for the system function and therefore is
written only during a reprogramming session initiated by a KWP request. During
the system runtime a copy of this data resides in RAM and there is, at least in
theory, a possibility that it may accidentally be modified in RAM and then written
back to NVM at shutdown and in such way be corrupted. A test case (denoted as
Test Case 2) in this report is focused on these issues with the EMS.
5.2 Definitions
Before we continue to describe the results that were achieved during this project we
must make a clear definition of the concepts test case and test flow. A test case is
a system function test specification document that is a complete and detailed de-
scription of the tested function, system requirements, prerequisites, post-requisites,
limitations, used test design techniques, used heuristics and finally test flows.
2
Freeze Frame is a set of state variable whose values, at the moment when a DTC is set, is
saved
36
5.3. TEST CASE 1: EMS – EEC COMMUNICATION, CAN TIMEOUTS DETECTION
A test flow is a set of direct instructions to the implementer of the test. The
instructions describe what to do, when to do it and how to do it. A test flow typi-
cally covers a requirement or a number of them. In some cases, several requirements
are best combined in a single test flow. A test flow may be conducted directly in a
vehicle or a test rig and it can also be implemented as a script for a test rig.
A total of two test case were developed in this project. Although the complete test
case documents are not presented here since they contain some information that
is not allowed to be published, parts of these documents that are considered most
interesting and does not reveal internal information are given below. Test flows are
presented as completely as possible with some modifications in order not to reveal
internal information. The main principles should however be clearly readable.
We decided that a test case should be developed to detect this kind of errors.
This test case is to be based on the requirements:
2. S8 LLAP must detect a missing CAN message after 5 missing instances (i.e.
if tmessage ≥ 5 · Tmax
3. Results of timeout test for message must not be reported until at least 2
seconds + 5 · Tmax has passed since ECU on
37
CHAPTER 5. RESULTS
4. Timeout must not be reported outside ’Operating voltage mode’, in this case
22V – 32V
Requirement 1
The rationale behind this requirement is that fault codes (DTCs) indicating com-
munication error with an ECU should not be set too early. This is because such
a fault code may be misleading and make a user or a repair workshop mechanic
think that there is a faulty ECU that should be replaced when in fact a CAN
message was just delayed a little because high load on the CAN bus. Therefore
each ECU that receives CAN messages from other ECUs must be tolerant to a de-
lay on the messages that are expected to be received within a certain period time
from other ECUs. System architects at Scania have decided that a delay up to 5
times a nominal message period time should be acceptable and not result in a DTC.
Requirement 2
The signals that are contained within CAN messages often contain valuable real
time data. There are cases where closed control loops over CAN are based on the
signals. Therefore it is critical that application layer of the ECU software knows
whether a signal value is reliable or not. LLAP indicates this by altering the signal
status. The signal status is a 8-bit variable that travels from LLAP to APPL via
RTDB in the same C-struct and is used by APPL to decide whether to rely on the
signal value, make some degradations to some functions of the vehicle/engine or to
3
ATI Vision (or just Vision) is a computer software used to perform measurements of internal
state variables in an ECU, CAN monitoring etc.
4
CCP = CAN Calibration Protocol which is a way to monitor internal ECU variables with a
100Hz sampling rate.
38
5.3. TEST CASE 1: EMS – EEC COMMUNICATION, CAN TIMEOUTS DETECTION
set a DTC. In case where a CAN message that is expected to be received with a
certain period time discontinues to arrive, the LLAP must degrade its signal status
after 5 times the period time and set the signal value itself to a pre-defined default
value. There are many levels of signal statuses however for this test case we are
dealing with only three of them: FLAWLESS, NOTAVAILABLE and BADREPLACEMENT.
In fig. 5.3 we see actual measurements (through CCP) that shows how signal status
is degraded for two messages each of which are sent with cycle time of 6 times their
respective nominal cycle time. As the CAN message with nominal cycle time of 50
ms is received (each 6*50 = 300 ms), the status for its signals is set to FLAWLESS
and continues to be FLAWLESS for a time of 5*50 = 250 ms. After that the signal
status is degraded to NOTAVAILABLE and holds that status for a 50 ms after which
a new instance of the message is received and the signal status is again restored
to FLAWLESS. The same applies to a message with cycle time of 200 ms. This
measurement was performed in a single EMS S8 unit connected to a DC power
source. A VCI2 unit was connected (see fig. 2.7) to the S8 units CAN2 and CAN3
port. The software used to program the S8 unit and read DTCs/DECs was XCOM
(internal Scania Software) that can send and receive diagnostic information from
the ECU through its CAN3 channel. The software that was used to monitor the
internal ECU status variables, including signal statuses, was ATI Vision. Vision
also allows us to send simulated CAN messages so they would appear to come from
the EEC3 unit that is not present. The CAN messages were sent this way.
Requirement 3
39
CHAPTER 5. RESULTS
Figure 5.3. We see how signal status (no engineering unit) jumps between the
FLAWLESS (upper line) to NOTAVAILABLE (lower line) for two CAN messages
traveling from EEC3 to S8. The messages are sent with a cycle time 6 times the
nominal cycle time. In the upper graph the signal belongs to a signal that is contained
in a message with cycle time of 200 ms, and in the lower graph corresponding cycle
time is 50 ms.
Requirement 4
Taking these requirements as a set of rules we can now formulate a decision ta-
ble which is used to decide which set of conditions are to be covered by the test,
see tab. 5.1.
40
5.3. TEST CASE 1: EMS – EEC COMMUNICATION, CAN TIMEOUTS DETECTION
Requirement 1
Tested using equivalence class partitioning and boundary value analysis in the time
domain for all diagnosed messages using their respective testcom-struct. Equiva-
lence classes are
2. tmsg,act ≥ 5 · tmsg
where tmsg is the message maximal period time for each of the message tested tmsg,act
is the period at which a manipulated message is sent during the test process.
Requirement 2
Tested using equivalence class partitioning and boundary value analysis in the time
domain in a similar way as for the previous requirement. In this case we use signal
statuses specified in the system function specification.
Requirement 3
Tested using boundary value analysis in the time domain (testcomstruct). Equiva-
lence classes are
2. tECU on ≥ 2 s + 5tmsg
Requirement 4
According to [TBENV] the Operating Voltage Mode is 22V to 32V. This should be
tested by equivalence class partitioning and boundary value analysis.
We have three equivalence classes
41
CHAPTER 5. RESULTS
1. Uop < 22 V
2. 22 V ≤ Uop ≤ 32 V
3. 32 V < Uop
A note about the use of boundary value analysis is that we are using somewhat
relaxed version of it by not analyzing signal data exactly on the boundaries since
the system requirements does not define them clearly and it is not deemed necessary.
42
5.3. TEST CASE 1: EMS – EEC COMMUNICATION, CAN TIMEOUTS DETECTION
Test Flow 1
This test flow covers requirement 1 and 3.
43
CHAPTER 5. RESULTS
Test Flow 2
This test flow covers requirement 2. Note that the “appendix” mentioned here refers
to the appendix in the internal test specification document. Fig. 5.5 in this report
is its close correspondence.
44
5.3. TEST CASE 1: EMS – EEC COMMUNICATION, CAN TIMEOUTS DETECTION
Test Flow 3
This test flow covers requirement 1, 3 and 4 and involves manipulating system
supply voltage.
45
CHAPTER 5. RESULTS
Figure 5.4. Signal status variation, the higher line indicates FLAWLESS signal
status, the lower is NOTAVAILABLE signal status. This one is faulty
Figure 5.5. Signal status variation, the higher line indicates FLAWLESS signal
status, the lower is NOTAVAILABLE signal status. This one is OK
46
5.4. TEST CASE 2: EMS SHUTDOWN
stored from the time data was saved. A mismatch indicates corrupt data area and
it should be replaced by pre-defined default values.
The technical analysis shows that S8 in a road vehicle (truck or bus) is powered by
the vehicles battery or generator when the engine is running. Besides U30 power
supply, S8 (like almost any other ECU) has a U15 input signal, which is defined as
(
U30 if ignition is on
U15 =
0 otherwise
When ignition is turned from on to off, the ECU detects the loss of U15 signal and
initializes its shutdown sequence. During this sequence the ECU presumes to have
full U30 voltage supply. If U30 is lost while the shutdown phase is in progress the
ECU may enter an undefined state and/or corrupt the EEPROM data. This sce-
nario is fully realistic in a truck because trucks are equipped with a master battery
switch, usually located outside the cab, near the battery or in some special purpose
vehicles inside the cab. This switch turns off all of the vehicle’s electrical systems
(with a very few exceptions). If this switch is turned off while ignition is on then
S8 will lose power at the same moment as the U15 signal is switched to 0. In worst
case, the ECU may initialize the EEPROM saving process which it does not have
a chance to complete due to sudden voltage loss.
The above illustrates a rationale behind developing a test case that tests correctness
of a shutdown process. As with previous test case we begin the development process
with a requirement identification.
Requirement 1: The EMS should turn itself off if and only if the
following conditions are fulfilled
47
CHAPTER 5. RESULTS
48
5.4. TEST CASE 2: EMS SHUTDOWN
Table 5.2. Decision table for the S8 shutdown test case. Majority of combinations
of the four conditions was excluded from the test case heuristically based on the
assumption that it is unlikely that two conditions in combination would give a failure
while they would not if tested separately. This way we test whether the EMS does
shut down when all conditions are fulfilled and does not when one condition at a time
is not fulfilled.
decision table we get a good overview of all possible scenarios. Their number is
reasonably small in this case. One should be careful with decision tables as one or
many important condition combinations may be excluded while they should not be.
To verify other requirements no special test technique was used since the test data
set and the number of execution flows is limited and verified directly.
Note that variable names are modified in order not to disclose internal
information. The real variable names are different. Also note that u15
in this case is a boolean variable that can either be 0 or 1 indicating
whether ignition is off or on respectively. During this test flow we assume
that the EEC3 unit does not request stay-alive. Also we assume that the signal
status of the EEC3 stay-alive request is FLAWLESS at all times. Note: the variable
u15_allow_shutdown is used to determine whether the U15 condition for shutdown
is fulfilled. u15 is 1 when U15 is on and 0 when U15 is off. In order for U15 condition
to be fulfilled u15 must be 0 for 100 ms.
49
CHAPTER 5. RESULTS
In this test flow we test that the EMS does not turn off when the engine is running.
S8 is not allowed to turn itself off until there is no engine movement for some time.
In this test flow we verify that the EMS stays turned on for as long as the engine is
on. There is no timeout so EMS may theoretically stay up for an unlimited amount
of time as long as the engine is running but since we cannot test for an unlimited
time we must define a time limit. We set 60 seconds as it appears to be a reasonable
time limit. It is reasonable to assume that EMS either shut itself down soon after
all conditions for shutdown except engine movement has been fulfilled (which would
mean that this test case fails) or it will stay up as long as the engine is moving.
Even if it would happen the consequences are not deemed as severe.
50
5.4. TEST CASE 2: EMS SHUTDOWN
adaptation_shutdown_halt
ADAPTATION_TIMEOUT
ADAPTATION_TIMEOUT
51
CHAPTER 5. RESULTS
adaptation_shutdown_halt
52
5.4. TEST CASE 2: EMS SHUTDOWN
time a file saving process takes and then perform the scenario again but with half
the measured time. Since variations in file saving time of more than ±50% seems
very unlikely we consider that the system behaves not according to requirement if
it is not possible to interrupt a shutdown after half the measured time.
Test Flow 6
53
CHAPTER 5. RESULTS
Test Flow 1
Figure 5.6. Vision recording of the scenario given in test flow 1 in this test case.
The recording was stopped after the ECU (EMS) stopped to respond to CCP and
we assume that it powers itself down directly after that. This means that the last
samples in this recording is the last samples of the ECU before shutdown. At ap-
prox 23.5 s time the ignition (U15) is turned off and approx 100 ms after that the
u15_allow_shutdown condition becomes true. At approx 25.5 s the engine stops mov-
ing and the eec_allow_shutdown conditions become true and after approx 1.2 s the
EMS stops responding to CCP. This 1.2 s can be explained by the time it takes to
save the NVM data.
Test Flow 2 – 4
The behavior in these test flows are very similar to the one in the test flow 1 result.
The difference is only in details and variable names.
Test Flow 5
By inspection with XCOM it was found that the INTE code was set when a U30
switch was shut off during running ECU in the HIL lab. Also after one shutdown
by cutting off U30 to the control unit a DTC 0xF001 Incorrect EMS shutdown was
set.
54
5.4. TEST CASE 2: EMS SHUTDOWN
Test Flow 6
Please observe that in the following plots the units on the y-axis are different for
each line. There are boolean variables, u15 and e2saving_in_progress and the
time counters which have the unit second, mixed in the same plot.
Figure 5.7. The U15 is turned off at approx 6.1 s and then turned back at approx
7.3 s. As we see the counter that counts the time since ECU was turned on did not
reset. This means that the ECU went back to fully operational state without being
turned off first.
55
CHAPTER 5. RESULTS
Figure 5.8. This is the scenario where the EMS actually does turn itself off as we see
by the run time counter. The time period where the counters (ecuon_time_counter
and e2saving_time) are at a constant is the time when the EMS is down and Vision
is not receiving any samples from CCP.
56
Chapter 6
6.1 Conclusions
In general, many things can go wrong during an ECU or vehicle start up and shut-
down. To be able to classify the areas of highest risk one needs to have an experience
in developing or testing the ECU software (preferably both) and a great knowledge
of the internal structure of the ECU software. The author’s communication with
platform software developers was of great help to be able to get somewhere and to
realize some high-risk problem areas.
• Shutdown problems that comprises all cases where an ECU is turned off unex-
pectedly due to either a deliberate or non-deliberate U30 cut off or unexpected
ECU reset due to software (or hardware) problems. A common denominator
for these scenarios is that the ECU has little chance of saving its data to
NVM. It can be compared to typing a document in a word processor on a
57
CHAPTER 6. CONCLUSIONS AND SUGGESTIONS FOR FUTURE WORK
desktop computer and then make the computer suddenly lose power without
previously saving the document.
The assignors requirement was to develop several test cases related to identified
problem areas within the start-up and shutdown of the ECUs and if time and/or
resources allows also implement the test cases in either a test automation rig or a
live vehicle. At the time point when the first test case was developed (test speci-
fication was produced) in the end of march 2011 it was clear that there is no time
to go on with the implementation phase. The natural step for a future work (a
recommendation to Scania) is therefore to implement the test case EMS-EEC CAN
Timeout as well as part of the EMS Shutdown test case as a HIL-script.
One of the main conclusions of this work is that there is no simple solution to
the start up and shutdown problems. Also the system test as an approach to attack
these problems is not sufficient. Many things happen “under the surface” during the
start up and shutdown which requires a more white box approach. Also many prob-
lems discovered are not because of software bugs. This mainly applies to problems
that arise due to battery voltage or system electrical supply interruption. There-
fore other ways, such as module testing and possibly hardware redesign, must be
considered.
Failure report analysis show that a lot of problems in the development or field
test vehicles is due to battery/electrical problems and supply voltage variations.
58
6.2. FUTURE WORK SUGGESTIONS
One of the problems is that it is possible to shut down an ECU in an improper way
by switching off the master battery switch while ignition is on. An intuitive thought
is that this problem can be solved by introducing a backup battery in each ECU
independent of the main battery. When U30 is turned off the ECU then can use
the backup battery power to perform a proper shutdown which would reduce the
number of misleading fault codes significantly. This would however require a major
hardware redesign of the ECUs. The author of this report is unable to make the
decision of whether it is worth the effort. There is a recommendation to investigate
the matter.
59
Bibliography
61
BIBLIOGRAPHY
http://msdn.microsoft.com/en-us/library/aa292167
Accessed 2011-03-31.
[MYERS] Myers, Glenford
The Art of Software Testing.
John Wiley and Sons,
2004
[OBD] OBD
KMB Systems
http://www.kbmsystems.net/obd_tech.htm
Accessed 2011-03-21.
[RTOS] Giorgio Buttazo
Real-Time Operating Systems: Problems and Novel Solutions.
University of Pavia,
Vol. 2469 of Lecture Notes in Computer Science, Springer-Verlag, pp. 37-51
2002.
[SDS8] System description EMS S8.
Scania CV AB (Internal Document),
2008.
[TBENV] Technical Regulation - Requirements and verification methods for electri-
cal factors in a 24V system
Scania CV AB (Internal Document)
2010.
[TBJ1939COM] Technical Regulation - Data communication requirements, control
units connected to a SAE J1939 network segment
Scania CV AB (Internal Document),
2010.
[TDP] Torbjörn Ryber,
Testdesign för programvara.
No Digit Media,
ISBN 91-976062-1-9
2006.
[WPCAN] Controller Area Network
Wikipedia article
http://en.wikipedia.org/wiki/Controller_area_network
Accessed 2010-11-27.
[WPEMSTD] European Emission Standards
Wikipedia article
http://en.wikipedia.org/wiki/European_emission_standards
Accessed 2010-11-27.
62
TRITA-CSC-E 2011:065
ISRN-KTH/CSC/E--11/065-SE
ISSN-1653-5715
www.kth.se