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.

Disciplined process to evaluate

– application behavior

– performance

– robustness

What is Testing?

11/15/2004 Testing Embedded Systems 3

Testing Tools

• Rational Test Real Time

• VectorCAST

• Message Magic

• Reactis Tester

• TestQuestPro

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.

26

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.

27

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

28

Acceptance Criteria

– Functional Correctness and

Completeness

– Accuracy

– Data Integrity

– Data Conversion

– Backup and Recovery

– Competitive Edge

– Usability

– Performance

– Start-up Time

– Stress

– Reliability and Availability

– Maintainability and

Serviceability

– Robustness

– Timeliness

– Confidentiality and

Availability

– Compliance

– Installability and

Upgradability

– Scalability

– Documentation

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

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

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.

What is CANBUS?

CANBUS or CAN bus – Controller Area Network bus

• 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

Why CANBUS ?

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

Applications

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.

38

Before CAN

39

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.

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.

• CAN is a closed network

– – no need for security, sessions or logins.

– - no user interface requirements.

• Physical and Data Link layers in silicon.

CANBUS and the OSI Model

45

CANBUS Physical Layer

46

Conventional multi-wire looms CAN bus network

Physical medium – two wires terminated at both ends by resistors.

Differential signal - better noise immunity.

Benefits:

Reduced weight, Reduced cost

Fewer wires = Increased reliability

vs.

http://canbuskit.com/what.php

Body Control Module

Transmission Characteristics

47

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

Message Oriented Transmission Protocol

48

• 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

Message Format

49

• Each message has an ID, Data and overhead.

• Data –8 bytes max

• Overhead – start, end, CRC, ACK

Example of Message Transaction

50

Bus Arbitration

51

• 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

CAN bus © 2005 Microchip Technology Incorporated. All Rights Reserved.

Bus Arbitration

52

• 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.

56

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.

57

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

58

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.

59

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.

60

CAN Data Frames

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

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.

61

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.

62

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):

63

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 The Error Frame consists of an Error Flag, which 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.

64

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

65

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.

72

CAN (SAE J1939) Example: Caterpillar 797

73

Caterpillar example

74

Caterpillar example

75