CSCI 3426 15 credit module -- Telematics
August 2012
1 INTRODUCTION
A short introduction to why we need telemetry can be found here. It is recommended as background reading.
2CANBUS
We will start our discussion of wired telematic systems by an in-depth analysis of CANBUS (Controlled Area Network). CANBUS was originally developed by Bosch, for use in vehicles; it has now been adopted by a wide range of vehicle manufacturers and is widely used in industry.
ISO 11898 – ‘Road Vehicles – Interchange of Digital Information’ is now a definitive standard for layer 1 of the CAN protocol. SAE J1939, from the Society of Automotive Engineers overlays a MAC and LLC protocol for use with CAN, and goes on to define a complete 7 layer model that we will explore in depth.
A number of microprocessors include a CAN interface as standard. One example is the CC03 from Atmel. Their data sheet has a reasonable description of CAN, and is worth reading. See CC03
Another family of CAN devices are produced by Microchip. The data sheet for the device used in the labs can be found here
Look up the CAN section
2.1 Physical Layer
The electrical standard defines two wires CAN-HIGH and CAN-LOW. These two lines have a nominal voltage of 2.5V when they are in the ‘recessive’ state; that is the voltage difference between CAN-HIGH and CAN-LOW is zero. In the ‘dominant’ state CAN-HIGH rises to a nominal 3.5V, and CAN-LOW falls to a nominal 1.5V.
The recessive state represents a logic level 1, and the dominant state represents a logic level 0.
If two ECUs (Electronic Control Units) attempt to pull the CAN cables to a 1 and 0 simultaneously then the ECU offering the dominant state will win. Thus a 0 will defeat a 1. The value of this will be seen when we examine the MAC protocol layer.
Each data bit is split into 4 fields known as
SYNC
PROPOGATION SEGMENT
PHASE SEGMENT 1
PHASE SEGMENT 2
SYNC SEG
This part of the bit time is used to synchronise the various ECUs on the bus. An edge is expected within this bit segment.
PROP SEG
This part of the bit time is used to compensate for the physical delay times within the network. These delay times are caused by the propagation time of the bus line and the internal delay time of the ECUs.
PHASE SEG1, PHASE SEG2
These Phase-Buffer-Segments are used to compensate for phase-errors and can be lengthened or shortened by resynchronization.
SAMPLE-POINT
The Sample-Point is the point of time at which the bus level is read and interpreted as the value of that respective bit. Its location is at the end of PHASE_SEG1.
When initialising a CAN device the programmer is required to set the length of each of these phases.
For example.Assume that we are using a 6MHz system clock, how do we set up our CAN device to transmit data at a rate of 250kHz?
First we have to divide down our system clock to give as a System Clock. With experience you will be able to determine suitable system clocks, in this instance 2MHz will work very well. So we set our CAN Baud Rate Divider to 2 – WHY TWO?? Because it is usual procedure that the CAN controller adds 1 to all division ratios, so a divider of 2 actually divides by 3.
Our System Clock will be 6/3 = 2MHz
To obtain 250kHz we need to divide this down by 8
2MHz/8 = 250Khz
To achieve this we need to partition up the 8 available bits between the 4 segments that make up a data bit. The SYNC segment always takes up 1 system clock, leaving 7 bits. A rough rule of thumb is to split the remaining bits across the remaining phases. If we allow 3 system clocks for the PROP PHASE and 2 system clocks each for each of the PHASE segments our system will work OK. To achieve this we will programme up our PROP PHASE divisor to be 2, and our PROP PHASE divisors (1 and 2) to be 1.
So our partition will be
SYNC 1 system clock
PROP 3 system clocks
PHASE ONE 2 system clocks
PHASE TWO 2 system clocks
Making a total of 8 system clocks per data bit.
2.2 Medium Access Control (MAC) Layer Protocol
In order to understand the MAC protocol we must consider the Link Level Control (LLC) as well.
An LLC frame consists of a header and a data section. The header can be either 2 bytes long for CAN A systems, and 4 bytes long for CAN B systems.
CAN A defines 11 bits for the address, one bit as the response bit, and 4 bits to define the length of the data section. The bit total is 16 bits, spread over two bytes. The first byte transmitted contains the upper 8 bits of the address, sent most significant bit first. The second byte transmitted sends the lower 3 bits of the address first, most significant bit first; then it sends the response bit followed by the data length (MSB first).
Bit 15 / Bit 14 / Bit 13 / Bit 12 / Bit 11 / Bit 10 / Bit 9 / Bit 8 / Bit 7 / Bit 6 / Bit 5 / Bit 4 / Bit 3 / Bit 2 / Bit 1 / Bit 0Add 10 / Add 9 / Add 8 / Add 7 / Add 6 / Add 5 / Add 4 / Add 3 / Add 2 / Add 1 / Add 0 / Response / Len 3 / Len 2 / Len 1 / Len 0
CAN B extends the header field by 16 bits to give a 29-bit address field. These new bytes are transmitted MSB first. Bit 2 of the last byte is the Remote transmission request bit; bits 1 & 0 are reserved. An additional byte is inserted that includes the data length data.
Bit 31 / Bit 30 / Bit 29 / Bit 28 / Bit 27 / Bit 26 / Bit 25 / Bit 24 / Bit 23 / Bit 22 / Bit 21 / Bit 20 / Bit 19 / Bit 18 / Bit 17 / Bit 16Add 28 / Add 27 / Add 26 / Add 25 / Add 24 / Add 23 / Add 22 / Add 21 / Add 20 / Add 19 / Add 18 / Add 17 / Add 16 / Add 15 / Add 14 / Add 13
Bit 15 / Bit 14 / Bit 13 / Bit 12 / Bit 11 / Bit 10 / Bit 9 / Bit 8 / Bit 7 / Bit 6 / Bit 5 / Bit 4 / Bit 3 / Bit 2 / Bit 1 / Bit 0
Add 12 / Add 11 / Add 10 / Add 9 / Add 8 / Add 7 / Add 6 / Add 5 / Add 4 / Add 3 / Add 2 / Add 1 / Add 0 / Response / reserved / reserved
The data section then follows and can be any length from 0 to 8 bytes long.
Some additional bits are inserted into the LLC frame by the MAC layer, but these are beyond the scope of this module. They are automatically inserted by the CAN controller, and are not the responsibility of the programmer.
So how does an ECU gain access to the transmission medium?
The MAC protocol uses a Carrier Sense Multiple Access (CSMA) technique, similar to ETHERNET, but unlike ETHERNET is guaranteed to be collision free. That is because two nodes are incapable of transmitting their messages onto the bus at the same time. This is because a dominant bit (0) will defeat a recessive bit (1). Before a node transmits it listens to the bus to see if it is free. If the bus is in use it waits for the other ECU to finish transmitting. If it is free it starts to send out its’ message onto the bus, transmitting its’ address first. Whilst transmitting it simultaneously listens to what it is sending. If another ECU starts to transmit at the same time, then the ECU with the lower address will win. The ECU with the higher address will ‘see’ that when it attempts to send a ‘1’ the other ECU overwrites that address bit with a dominant ‘0’. As soon as an ECU sees its’ own address overwritten it ceases to transmit, leaving the bus free for the higher priority unit. The higher priority unit is unaware of what has happened and simply sends its’ message in the normal way. Thus we have achieved collision free arbitration.
There is a penalty with this concept. The propagation delay within the complete network must be substantially less than bit rate, to ensure that a competing bit from the opposite end of the network arrives in time arbitrate with all nodes.
2.3 LLC Layer
In the discussion of the MAC layer it will be seen that an address relates to a message, not to an ECU. It is in this way that CANBUS differs so clearly from other protocols. It is the data frames that are ‘addressed’. Each ECU can broadcast as many messages as it wishes onto the BUS, each of which can be given different addresses. Thus it is the data entity that has an address.
As ECUs are not assigned addresses, as in a traditional network, it follows that they can listen in to any message that they wish.
CANBUS IS NOT A POINT TO POINT NETWORK, it is better thought of as a knowledge base.
ECUs are responsible for generating data, which is broadcast onto the BUS, usually at regular intervals. Each ECU can broadcast as many messages as is required. It is advisable not to allocate the same message address to more than 1 ECU.
ECUs can then listen to any, or all, of the messages that are available on the BUS. So it is possible to have multiple ‘listeners’ that all ‘tune-in’ to the same message.
At least one listening ECU must acknowledge receipt of every message (this is automatically done at the MAC layer), otherwise the ECU that is sending that message will repeat it until someone acknowledges receipt. Eventually an unacknowledged ‘talker’ will go into error and stop all transmissions.
WHAT YOU NEED TO KNOW ABOUT CANBUS
HOW A BIT IS MADE UP OF 4 SEGMENTS
HOW A FRAME IS FORMATTED
WHY A LOW ID DEFEATS A HIGH ID - THUS WHY CAN IS A COLLISION FREE NETWORK
HOW TO DERIVE A DATA RATE
2.4 J1939
J1939 is a 7-layer protocol published by the Society of Automotive Engineers. It defines a common messaging structure for a range of measurands that are to be found on cars and trucks.
Also have a look at the Kvaser web-site -Kvaser
The 29 bit CANBUS address field is divided down as follows (most significant bit first).
3 bits MESSAGE PRIORITY LEVEL
1 bit UNUSED
1 bit PAGE SELECT
8 bits PDU FORMAT
8 bits PDU SPECIFIC
8 bits USER DEFINED
Bit 28 / Unused
Bit 27 / Page Select (usually 0)
Bits 26/25/24/23/22/21/20/19 / 8-Bit PDU Format
Bits 18/17/16/15/14/13/12/11 / 8-Bit PDU Specific
Bits 10/9/8/7/6/5/4/3 / 8-Bit user defined
Bits 2/1/0 / unused
Note that the priority level uses the most significant bits, thereby defining a priority groups. If two messages from the same priority group attempt to gain access to the bus at the same time, then the message with the lower FORMAT/SPECIFIC fields will win.
Each message always includes 8 data bytes, but they are not always defined. Each message has a recommended repetition rate
For example consider entry 5.3.7. in the specification ELECTRONIC ENGINE CONTROLLER #1: or just EEC1
(Note this is offered as an example and will not be examined)
Transmission repetition rate: engine speed dependent (see 5.1.7.2)
Data length: 8 bytes
Data page: 0
PDU format: 240
PDU specific: 4
Default priority: 3
Parameter group number: 61 444 (00F004 16 )
The 'parameter group number' consists of the 16-bit value obtained by concatenating PDU Format & PDU Specific.
240 = F0 HEX and 4 = 04 HEX thus a parameter group number of F004 HEX
The standard then goes on to define the meaning of the following 8 data bytes
Byte: 1 Status_EEC1
Bit: 8-5 Not defined
Bit: 4-1 Engine/retarder torque mode 5.2.2.1
Byte: 2 Driver’s demand engine - percent torque 5.2.1.4
Byte: 3 Actual engine - percent torque 5.2.1.5
Byte: 4,5 Engine speed 5.2.1.9
Byte: 6 Source address of controlling device for engine control 5.2.5.298
Byte: 7-8 Not defined
Taking the data fields in turn
BYTE 1 STATUS_EEC1
Bits 8-5 are undefined (note that bits and bytes are numbered from 1 not 0)
Bits 4-1 are defined by section 5.2.2.1 – Shown below is an extract from that part of the specification. It will be seen that these 4 bits are used to inform other ECU’s of the current ‘torque mode’
TABLE 7
ENGINE/RETARDER TORQUE MODES
Bit States Engine/Retarder Torque Mode
0001 / Accelerator pedal/operator selection
0010 / Cruise control
0011 / PTO governor
0100 / Road speed governor
0101 / ASR control
0110 / Transmission control
0111 / ABS control
1000 / Torque limiting
1001 / High speed governor
1010 / Braking system
1011 / Remote accelerator
1100 / not defined
1101 / not defined
1110 / Other
1111 / Not available
BYTE 2 DRIVERS DEMAND ENGINE TORQUE
This is a single byte that gives us the % torque that the driver is demanding. In effect it is a measure of rotational force. The definition of this byte is given elsewhere in the specification, part of which is reproduced below.
5.2.1.4 Driver’s Demand Engine - Percent Torque
The requested torque output of the engine by the driver. It is based on input from the following requestors external to the power train: operator (via the accelerator pedal), cruise control and/or road speed limit governor. Dynamic commands from internal power train functions such as smoke control, low- and high-speed engine governing; ASR and shift control are excluded from this calculation. The data is transmitted in indicated torque as a percent of the reference engine torque. See 5.3.17 for the engine configuration message. Several status bits are defined separately to indicate the request which is currently being honoured. This parameter may be used for shift scheduling.
Data Length: 1 byte
Resolution: 1%/bit gain,
125% offset (00 = -125%, 125 = 0%, 250 = +125%)
Data Range: -125 to 125%
Operating Range: 0 to 125%
Type: Measured
Suspect Parameter Number: 512
Reference: 5.3.7
Note the way that the value is expressed. It consists of a scale and offset. The offset is –125, and the scale is defined a 1% per bit. So a data byte of 125 = 0%. This is typical of most numerical values defined by J1939.
BYTE 3 ENGINE TORQUE
This has the identical format to byte 2, and is a measure of the torque that the engine really delivering.
BYTES 4&5 ENGINE SPEED
Better known a RPM or Revolutions Per Minute.
This is an integer variable defined in section 5.2.1.9 of the specification.
5.2.1.9 Engine Speed
Actual engine speed which is calculated over a minimum crankshaft angle of 720 degrees
divided by the number of cylinders.
Data Length: 2 bytes
Resolution: 0.125 rpm/bit gain, 0 rpm offset (upper byte resolution = 32 rpm/bit)
Data Range: 0 to 8031.875 rpm
Type: Measured
Suspect Parameter Number: 190
Reference: 5.3.7
Integers are transmitted lower byte first, so byte 4 holds the least significant byte and byte 5 holds the most significant byte. Note again that there is an offset and a scaling factor. To obtain the engineering value if RPM the integer variable must first be multiplied through by the scaling factor, and then the offset is subtracted. In this instance the offset is defined as zero so the subtraction is not necessary.
BYTE 6 SOURCE ADDRESS
The user can assigns an 8-bit address to the ECU that broadcasts the EEC1 data frame.
BYTES 7&8
These are unused
WHAT YOU NEED TO KNOW ABOUT J1939
THE FORMAT OF A J1939 MESSAGE
AN OUTLINE OF HOW DATA IS INTEPRETED – i.e. I do not expect you to know the example given above, but you should be able to propose a way of encoding a data parameter
2.5 CAN IDENTIFIERS & MASKS
Whatever application layer is used for a CAN network, a node is required to selectively accept only those data messages that it is interested in. This is achieved using the CAN identifier and mask registers. Let us assumed that we are using CAN B, with a 29-bit address. The address data is carried in the 32-bit header of the CAN message, of which we are only interested in examining the upper 29 bits. If the protocol if J1939, then only some of those bits are used to identify the message type. If we want to capture only EEC1 then consider how the address is defined >
3 bits MESSAGE PRIORITY LEVEL Unknown
1 bit UNUSED Unknown
1 bit PAGE SELECT 0
8 bits PDU FORMAT F0
8 bits PDU SPECIFIC 04
8 bits USER DEFINED Unknown
So the address that we are looking for is
XXXX 0111 1000 0000 0010 0XXX XXXX XXXX
The CAN receiver has a set of registers know as the identifier registers, into these you should write the address of the message that you wish the device to capture. There are also a set of mask registers, into these you must write which bits of the identifier registers are to be used.
In this case –
Identifier = 0000 0111 1000 0000 0010 0000 00000000
Mask = 0000 1111 111111111111 1000 0000 0000
Which means that the incoming message must contain a 0 in bit position 27, a 1 in bit position 26 and so on.All the other bits can be anything.
Consider a simpler example, to capture all messages with the pattern 1010 in the top 4 bits of the address
1010 0000 000000000000000000000000 IDENTIFIER
1111 0000 000000000000000000000000MASK
Here are some more notes on the use of MASKS and IDENTIFIER filters
WHAT YOU NEED TO KNOW ABOUT IDs & MASKS
YOU MUST BE ABLE TO FULLY DESCRIBE HOW THESE REGISTERS ARE USED TO SELECT SPECIFIC MESSAGES ON A CANBUS NETWORK
2.6 DEVICE NET
Device Net is a protocol that is used in industrial applications, and operates over a CAN network. It uses 11-bit addressing and runs at 125kHz, 250kHz or 500kHz.By definition the CAN protocol does not support point-to-point messaging. The Device Net protocol overlays CAN with a higher layer protocol that creates a point-to-point messaging structure supporting up to 64 nodes. This is achieved by defining fields within the 11-bit identifier and the 8-byte data packet.Device Net subdivides the 11-bit identifier field into 4 separate categories known as Group 1, Group 2, Group 3 and Group 4.