Unit I

Embedded System
(Testing, CAN Bus)
Dr. P. H. Zope
Assistant Professor
““BT’s COET Bambhori Jalgaon
North Maharashtra University India
phzope@gmail.com
09860631040

Contact for Embedded System Training

 Testing/Verification
Test/Verification involves ensuring that functionality is correct.
Such assurance can prevent time-consuming debugging at low
abstraction levels and iterating back to high abstraction levels.

What is Testing?
Disciplined process to evaluate
– application behavior
– performance
– robustness
 Testing Tools

• Rational Test Real Time

• VectorCAST
• Message Magic
• Reactis Tester
• TestQuestPro

11/15/2004 Testing Embedded Systems 3

 Types of Testing
1. Black Box Testing
2. White Box Testing
3. Performance Testing
4. Gorilla Testing
5. Field Trial Testing
6. Acceptance Testing
7. Regression Testing
White Box vs. Black Box
Testing
 What is White Box testing
White box testing is testing where we use the
info available from the code of the component
to generate tests.
This info is usually used to achieve coverage in
one way or another – e.g.
• Code coverage
• Path coverage
• Decision coverage
Debugging will always be white-box testing
Coverage report. Example – 1
Coverage report. Example – 2
 What about loops
Loops are the great problem in white box
testing. It is common practice to test the
system going through each loop
• 0 times – loop code never executed
• 1 time – loop code executed once
• 5 times – loop code executed several times
• 20 times – loop ode e e uted a ti es
 Error messages
Since we have access to the code we should
1. Identify all error conditions
2. Provoke each identified error condition
3. Check if the error is treated in a satisfactory
manner – e.g. that the error message is
clear, to the point and helpful for the
intended users.
 What is Black Box testing
Black box testing is also called functional testing.
The main ideas are simple:
1. Define initial component state, input and
expected output for the test.
2. Set the component in the required state.
3. Give the defined input
4. Observe the output and compare to the
expected output.
 Info for Black Box testing
That we do not have access to the code does not
mean that one test is just as good as the other
one. We should consider the following info:
• Algorithm understanding
• Parts of the solutions that are difficult to
implement
• Special – often seldom occurring – cases.
 Clues from the algorithm
We should consider two pieces of info:
• Difficult parts of the algorithm used
• Borders between different types of solution –
e.g. if P1 then use S1 else use S2. Here we
need to consider if the predicate is
– Correct, i.e. contain the right variables
– Complete, i.e. contains all necessary conditions
 Black Box vs. White Box testing

We can contrast the two methods as follows:

• White Box testing
– Understanding the implemented code.
– Checking the implementation
– Debugging
• Black Box testing
– Understanding the algorithm used.
– Checking the solution – functional testing
Performance Testing
 Gorilla Testing
This testing is called as random tester.

Used for robustness.

It applies random input.

If the system withstands / tolerate such random inputs then
you can conclude that your product is robust
 Field Trial Testing
This testing is done at user place.

Used for environment matching.

 Acceptance Testing
• Acceptance testing is a formal testing conducted to
determine whether a system satisfies its acceptance
criteria
• There are two categories of acceptance testing:
– User Acceptance Testing (UAT)
• It is conducted by the customer to ensure that system satisfies the
contractual acceptance criteria before being signed-off as meeting
user needs.

– Business Acceptance Testing (BAT)

• It is undertaken within the development organization of the supplier
to ensure that the system will eventually pass the user acceptance
testing.

26
 Types of Acceptance Testing
Three major objectives of acceptance testing:

• Confirm that the system meets the agreed upon

criteria

• Identify and resolve discrepancies, if there is any

• Determine the readiness of the system for cut-

over to live operations

27
 Acceptance Criteria
• The acceptance criteria are defined on the basis of the following attributes:

– Functional Correctness and – Maintainability and

Completeness Serviceability
– Accuracy – Robustness
– Data Integrity – Timeliness
– Data Conversion – Confidentiality and
– Backup and Recovery Availability
– Competitive Edge – Compliance
– Usability – Installability and
– Performance Upgradability
– Start-up Time – Scalability
– Stress – Documentation
– Reliability and Availability

28
 Regression Testing
After testing the system for a considerable amount of time. If
a client find any problem then you will have to solve that
problem by modifying Hardware /Software.
But such modification should not hamper / affect the other
part of the system.
Test the system as per client satisfaction.
Introduction to
CANBUS
 What is CANBUS?
CANBUS or CAN bus – Controller Area Network bus

A controller area network (CAN) is an asynchronous serial bus

network that connects devices, sensors and actuators for control
applications.

This multi–master communication protocol was first developed in

1986 for automotive applications needing data rates up to 1 Mbps
with high data integrity.

CAN is now standardized in ISO 11898, ISO 16845 and SAE J1939 for
automotive, industrial and general embedded communications.
 Why CANBUS ?
• CAN bus (for controller area network) is a vehicle bus standard designed to
allow microcontrollers and devices to communicate with each other within a
vehicle without a host computer.

• CAN bus is a message-based protocol, designed specifically for automotive

applications but is now also used in many other applications.

An automotive serial bus system developed to satisfy the following requirements:

 Network multiple microcontrollers with 1 pair of wires.
 Allow microcontrollers communicate with each other.
 High speed, real-time communication.
 Provide noise immunity in an electrically noisy environment.
 Low cost

32
 Applications
Industrial Machinery
Packaging Machines
Injection Molding Machines
Blow Molding Machines
Weaving Systems
Knitting Systems
Sewing, Folding, Packaging
Industrial Freezers
Printing machines
Semiconductor manufacturing
Blade Grinders

Railway
Las Vegas Monorail
Production/Switch Tamper
Light Rail Vehicles, Trams
Locomotives
MPV/CargoSprinter
Train Communication Network
Ticketing Machines
Specialty Vehicles
Police cars
Taxis
Turret Trucks
Fork Lifts
Mining Trucks
Rubber Tire Gantry Cranes
Telescopic mobile elevating platform
Construction machinery
Building Automation
Elevators
Medical
Process Optimized Operating Room
Hospital Beds
Blood dialysis

Maritime
Control by wire of ships

Restaurant Appliances
Coffee Machine by WMF
Laboratory Equipment & Research
Nuclear Research at CERN
Magnetic and Physical Property Measurement
by Quantum Design
Avionics
Electric Motorglider Antares
 Architecture

•CAN is a multi-master serial bus standard for connecting Electronic Control

Units [ECUs] also known as nodes.
•Two or more nodes are required on the CAN network to communicate.
•The complexity of the node can range from a simple I/O device up to an
embedded computer with a CAN interface and sophisticated software.
•The node may also be a gateway allowing a standard computer to
communicate over a USB or Ethernet port to the devices on a CAN network.
Each node requires a:
Central processing unit, microprocessor, or host processor
The host processor decides what the received messages mean and what messages
it wants to transmit.
Sensors, actuators and control devices can be connected to the host processor.

CAN controller; often an integral part of the microcontroller

Receiving: the CAN controller stores the received serial bits from the bus until an
entire message is available, which can then be fetched by the host processor
(usually by the CAN controller triggering an interrupt).
Sending: the host processor sends the transmit message(s) to a CAN controller,
which transmits the bits serially onto the bus when the bus is free.

Transceiver Defined by ISO 11898-2/3 Medium Access Unit [MAU]

standards
Receiving: it converts the data stream from CAN bus levels to levels that the CAN
controller uses. It usually has protective circuitry to protect the CAN controller.
Transmitting: it converts the data stream from the CAN controller to CAN bus
levels.
Before CAN

38
 With CAN
The solution to this problem was the connection of the control systems via a serial
bus system. This bus had to fulfill some special requirements due to its usage in a
vehicle. With the use of CAN, point-to-point wiring is replaced by one serial bus
connecting all control systems. This is accomplished by adding some CAN-specific
hardware to each control unit that provides the "rules" or the protocol for
transmitting and receiving information via the bus.

39
 Standard CAN: 11-Bit Identifier

•SOF–The single dominant start of frame (SOF) bit marks the start of a message, and is used
to synchronize the nodes on a bus after being idle.
•Identifier-The Standard CAN 11-bit identifier establishes the priority of the message. The
lower the binary value, the higher its priority.
•RTR–The single remote transmission request (RTR) bit is dominant when information is
required from another node. All nodes receive the request, but the identifier determines the
specified node. The responding data is also received by all nodes and used by any node
interested. In this way, all data being used in a system is uniform.
•IDE–A dominant single identifier extension (IDE) bit means that a standard CAN identifier
with no extension is being transmitted.
• r0–Reserved bit (for possible use by future standard amendment).
• DLC–The 4-bit data length code (DLC) contains the number of bytes of data being
transmitted.
• Data–Up to 64 bits of application data may be transmitted.
• CRC–The 16-bit (15 bits plus delimiter) cyclic redundancy check (CRC) contains the
checksum (number of bits transmitted) of the preceding application data for error detection.
•ACK–Every node receiving an accurate message overwrites this recessive bit in the original
message with a dominate bit, indicating an error-free message has been sent. Should a
receiving node detect an error and leave this bit recessive, it discards the message and the
sending node repeats the message after rearbitration. In this way, each node acknowledges
(ACK) the integrity of its data. ACK is 2 bits, one is the acknowledgment bit and the second is
a delimiter.
•EOF–This end-of-frame (EOF), 7-bit field marks the end of a CAN frame (message) and
disables bit-stuffing, indicating a stuffing error when dominant. When 5 bits of the same
logic level occur in succession during normal operation, a bit of the opposite logic level is
stuffed into the data.
•IFS–This 7-bit interframe space (IFS) contains the time required by the controller to move a
correctly received frame to its proper position in a message buffer area.
CAN Database Files
CAN databases define rules for conversion to engineering units. The following data is stored
in databases:

•Channel name
•Location (start bit) and size (number of bits) of the channel within a given message
•Byte order (Intel/Motorola)
•Data type (signed, unsigned, and IEEE float)
•Scaling and units string
•Range
•Default value
•Comment
How CAN Communication Works
CAN is a peer-to-peer network.
This means that there is no master that controls when individual nodes have access to
read and write data on the CAN bus.

When a CAN node is ready to transmit data, it checks to see if the bus is busy and then
simply writes a CAN frame onto the network.
The CAN frames that are transmitted do not contain addresses of either the transmitting
node or any of the intended receiving node(s).
Instead, an arbitration ID that is unique throughout the network labels the frame.

All nodes on the CAN network receive the CAN frame, and, depending on the arbitration
ID of that transmitted frame, each CAN node on the network decides whether to accept
the frame.
If multiple nodes try to transmit a message onto the CAN bus at the same time, the node
with the highest priority (lowest arbitration ID) automatically gets bus access.

 Lower-priority nodes must wait until the bus becomes available before trying to
transmit again. In this way, you can implement CAN networks to ensure deterministic
communication among CAN nodes.
 CANBUS and the OSI Model
• CAN is a closed network
– – no need for security, sessions or logins.
– - no user interface requirements.
• Physical and Data Link layers in silicon.

45
 CANBUS Physical Layer
 Physical medium – two wires terminated at both ends by resistors.
 Differential signal - better noise immunity.
 Benefits:
 Reduced weight, Reduced cost

 Fewer wires = Increased reliability

Conventional multi-wire looms CAN bus network

vs.

http://canbuskit.com/what.php

Body Control Module

46
 Transmission Characteristics
 Up to 1 Mbit/sec.
 Common baud rates: 1 MHz, 500 KHz and 125 KHz
 All nodes – same baud rate
 Ma le gth: ’ to 5 ’ rate depe de t

47
 Message Oriented Transmission Protocol
• Each node – receiver & transmitter
• A sender of information transmits to all devices on the bus
• All nodes read message, then decide if it is relevant to them
• All nodes verify reception was error-free
• All nodes acknowledge reception

CAN bus

48
 Message Format
• Each message has an ID, Data and overhead.
• Data –8 bytes max
• Overhead – start, end, CRC, ACK

49
Example of Message Transaction

50
 Bus Arbitration
• Arbitration – needed when multiple nodes try to transmit at the same time
• Only one transmitter is allowed to transmit at a time.
• A node waits for bus to become idle
• Nodes with more important messages continue transmitting

© 2005 Microchip Technology Incorporated. All Rights Reserved.

CAN bus

51
 Bus Arbitration
• Message importance is encoded in message ID.
Lower value = More important
• As a node transmits each bit, it verifies that it sees the same bit
value on the bus that it transmitted.
• A o the us i s o er a o the us.
• Losing node stops transmitting, winner continues.

52
 The Can Protocol
• Specifies how small packets of data may be
transported from point A to point B using a
shared communications medium.
• It (quite naturally) contains nothing on topics
such as
– flow control
– transportation of data larger than can fit in a 8-byte
message
– node addresses
– establishment of communication, etc.

56
 Higher layer protocols
• Higher layer protocols are used in order to
– standardize startup procedures including bit rate
setting
– distribute addresses among participating nodes or
kinds of messages
– determine the layout of the messages
– provide routines for error handling at the system level
• Some high layer protocols
– Device net
– CANKingdom
– CANopen

57
 The CAN Standard
• The CAN standard defines four message types
– Data Frame – the predominantly used message type
– Remote Frame
– Error Frame
– Overload Frame
• The messages uses a clever scheme of bit-wise arbitration to
control access to the bus, and each message is tagged with a
priority.
• The CAN standard also defines an elaborate scheme for error
handling and confinement.
• CAN may implemented using different physical layers, and
there are also a number of different connector types in use.

58
 1. The Data Frame
• Summary: "Hello everyone, here's some data
labeled X, hope you like it!"
• The Data Frame is the most common message type. It comprises the
following major parts (a few details are omitted for the sake of brevity):
• the Arbitration Field, which determines the priority of the message when
two or more nodes are contending for the bus. The Arbitration Field
contains:
– For CAN 2.0A, an 11-bit Identifier and one bit, the RTR bit, which is dominant
for data frames.
– For CAN 2.0B, a 29-bit Identifier (which also contains two recessive bits: SRR
and IDE) and the RTR bit.
• the Data Field, which contains zero to eight bytes of data.
• the CRC Field, which contains a 15-bit checksum calculated on most parts
of the message. This checksum is used for error detection.
• an Acknowledgement Slot; any CAN controller that has been able to
correctly receive the message sends an Acknowledgement bit at the end
of each message. The transmitter checks for the presence of the
Acknowledge bit and retransmits the message if no acknowledge was
detected.

59
 CAN Data Frames
Note 1: It is worth noting that the presence of an Acknowledgement Bit on the bus does not
mean that any of the intended addressees has received the message. The only thing we know is
that one or more nodes on the bus has received it correctly
Note 2: The Identifier in the Arbitration Field is not, despite of its name, necessarily identifying
the contents of the message.
• CAN . A sta dard CAN -bit ID) Data Frame.

 CAN . B e te ded CAN 9-bit ID) Data Frame.

60
 2. The Remote Frame
• Summary: "Hello everyone, can somebody please produce
the data labeled X?"
• The Remote Frame is just like the Data Frame, with two important
differences:
– It is explicitly marked as a Remote Frame (the RTR bit in the Arbitration Field is
recessive), and
– there is no Data Field.
• The intended purpose of the Remote Frame is to solicit the transmission
of the corresponding Data Frame. If, say, node A transmits a Remote
Frame with the Arbitration Field set to 234, then node B, if properly
initialized, might respond with a Data Frame with the Arbitration Field also
set to 234.
• Remote Frames can be used to implement a type of request-response
type of bus traffic management. In practice, however, the Remote Frame
is little used. It is also worth noting that the CAN standard does not
prescribe the behaviour outlined here. Most CAN controllers can be
programmed either to automatically respond to a Remote Frame, or to
notify the local CPU instead.

61
 Remote Frame (contd.)
• There's one catch with the Remote Frame: the Data Length
Code must be set to the length of the expected response
message. Otherwise the arbitration will not work.
• Sometimes it is claimed that the node responding to the
Remote Frame is starting its transmission as soon as the
identifier is recognized, thereby "filling up" the empty
Remote Frame. This is not the case.
• A Remote Frame (2.0A type):

62
 3. The Error Frame
Summary: (everyone, aloud) "OH DEAR, LET'S TRY AGAIN"

Simply put, the Error Frame is a special message that violates the framing rules
of a CAN message. It is transmitted when a node detects a fault and will cause
all other nodes to detect a fault - so they will send Error Frames, too. The
transmitter will then automatically try to retransmit the message. There is an
elaborate scheme of error counters that ensures that a node can't destroy the
bus traffic by repeatedly transmitting Error Frames.

The Error Frame consists of an Error Flag, which The Error Frame
is 6 bits of the same value (thus violating the
bit-stuffing rule) and an Error Delimiter, which is
8 recessive bits. The Error Delimiter provides
some space in which the other nodes on the bus
can send their Error Flags when they detect the
first Error Flag.

63
 4 The Overload Frame
Summary: "I'm a very busy little 82526 device, could you please
wait for a moment?"
• The Overload Frame is mentioned here just for completeness.
It is very similar to the Error Frame with regard to the format
and it is transmitted by a node that becomes too busy. The
Overload Frame is not used very often, as today's CAN
controllers are clever enough not to use it. In fact, the only
controller that will generate Overload Frames is the now
obsolete 82526

64
ISO Physical Layer
One of the most common and
cheapest implementations is to
use a twisted wire pair. The bus
lines are then called "CAN_H"
and "CAN_L". The two bus lines
CAN_H and CAN_L are driven
by the nodes with a differential
signal. The twisted wire pair is
terminated by terminating
resistors at each end of bus
line, typically 120 ohms.

65
CAN (SAE J1939) Example: Caterpillar 797

72
Caterpillar example

73
Caterpillar example

74
75