CAN: Controller Area Network CAN Controller Area Network.

Présentation au sujet: "CAN: Controller Area Network CAN Controller Area Network."— Transcription de la présentation:

1 CAN: Controller Area Network CAN Controller Area Network

2 2 / Basica Liviu / 2009 © Continental AG For Internal Use Only INTRO

3 3 / Basica Liviu / 2009 © Continental AG For Internal Use Only What is CAN ? Controller Area Network (CAN) is bus standard for automotive applications, originally developed in the 1980s by Robert Bosch GmbH, for connecting electronic control units (ECUs): asynchronous; bidirectional half duplex; linear; with protocol: address + data + data check + signal information; multi-master: every node can start communication. Requirements to Automation and Automotive Bus Systems: The costs; Transmission in a area with Radio Frequency noise; Real-time behavior; Easy handling; Standardization.

4 4 / Basica Liviu / 2009 © Continental AG For Internal Use Only How it began? Engine control Transmission control Antilock Brakes Active Suspension Lighting Power Seats Air condition Power windows Instrument Cluster (Dashboard) High speed CAN Low speed CAN

5 5 / Basica Liviu / 2009 © Continental AG For Internal Use Only CAN Advantages Less wires; Less connections; Less weight; Less EMI problems; Less space required; Easier addition of new nodes; Lower assembly costs; Increased transmission reliability; Standardization: ISO 11898, 11519, 11992, SAE j1939... ISO DIN SAE CiA “The great thing about standards is that there are so many to choose from.”

6 6 / Basica Liviu / 2009 © Continental AG For Internal Use Only An ECU's CAN structure Application Layer Presentation Layer Session Layer Transport Layer Network Layer Data Link Layer Physical Layer ISO/OSI Model CAN bus CAN Transceiver Application Software CAN Controller CAN Subsystem on Host Controller HW SW ECU All People Seem ToTo Need Data Processing

7 7 / Basica Liviu / 2009 © Continental AG For Internal Use Only HARDWARE

8 8 / Basica Liviu / 2009 © Continental AG For Internal Use Only CAN Bus / Network double wire linear bus – basic termination ~~ ~ ~ Network Node 1: e.g. Engine Control CAN-H CAN-L 120  Network Node n: e.g. Airbag double wire linear bus – split termination R T /2 = 60  CgCg C g = 10.. 100nF CAN_H

9 9 / Basica Liviu / 2009 © Continental AG For Internal Use Only CAN Bus / Network CAN star bus R T = 180  The multiple termination concept is used when network architecture differs from linear structure e.g. the cable drop length of a few meters is needed. For such a topology a multiple termination concept with three branches needs about three times the total termination resistance: 180 .

10 10 / Basica Liviu / 2009 © Continental AG For Internal Use Only CAN Bus / Network Daimler-Chrysler Patented Star Topology 30  10  CAN node CAN node CAN_H CAN_L ferrite bead: 2 mH 44  10 pF TransceiverTransceiver TransceiverTransceiver Daimler-Chrysler have patented a star topology with a common termination. This topology avoids resonance problems, undesired harmonics and it's insensitive to incoming noise. All noise traveling towards the termination point will be absorbed there and never reflected.

11 11 / Basica Liviu / 2009 © Continental AG For Internal Use Only CAN Bus / Network The communication in a car may be classified into three classes. Related to the performance of different systems there are: Class A - used for low-speed data communication: up to 10 kbit/s; Class B - used for status and diagnostic data sharing: 10 to 125 kbit/s; Class C - is used for real-time application communication at high speeds of 125 kbit/s to 1 Mbit/s. CAN Transmission via Fiber Optic Cable Very high transmission rates are possible; Access to data in systems with very high electromagnetic noise; Data transmission of sensitive data in systems with very high security requirements is possible.

12 12 / Basica Liviu / 2009 © Continental AG For Internal Use Only CAN Bus / Network Recessive Dominant CAN-L CAN-H 3.5 2.5 1.5 Volts Time High-Speed definitions according to ISO 11898

13 13 / Basica Liviu / 2009 © Continental AG For Internal Use Only CAN Bus / Network Recessive Dominant CAN-L CAN-H 3.25 1.75 1.0 Volts Time 4.0 Low-Speed definitions according to ISO 11519

14 14 / Basica Liviu / 2009 © Continental AG For Internal Use Only Physical Layer: CAN Transceiver The transceiver is able to convert a digital CAN controller signal in a symmetrical differential one and vice versa. Some of these transceiver offer special features like: slope control; bus short circuit protection to battery voltage and ground; single wire transmission in case of short circuit of bus lines; receive filter (low pass filter) against glitches (e.g. less 30 ns). ISO 11898, ISO 11992, ISO 11519.

15 15 / Basica Liviu / 2009 © Continental AG For Internal Use Only Physical Layer: CAN Transceiver GND TxD CAN_H CAN_L Rs CC CAN_H CAN_L PCA82C250 RxD V ref V CC V ref reference voltage output TxDtransmit data input RxDreceive data output GNDground Rsslope resistor input CAN_HHIGH level CAN voltage input / output CAN_LLOW level CAN voltage input / output V cc supply voltage e.g. High Speed Double-Wire Transceiver PCA 82C250 - ISO/DIS 11898 compatible - High Speed (up to 1 Mbit/s) - Standby Mode - Slope Control / Standby - Short circuit protection for - CAN_L and CAN_H

16 16 / Basica Liviu / 2009 © Continental AG For Internal Use Only Physical Layer: CAN Controller To be able to participate in the CAN communication, the micro-controller has to be connected to a CAN protocol controller. The CAN controller may be a different chip or be integrated into the microcontroller: Microcontroller CAN controller Transceiver Microcontroller Transceiver CAN controller CAN Bus

17 17 / Basica Liviu / 2009 © Continental AG For Internal Use Only Physical Layer: On-chip CAN Controller

18 18 / Basica Liviu / 2009 © Continental AG For Internal Use Only Physical Layer: Basic CAN There are two types of microcontroller with on-chip CAN module: Basic CAN Controller: Limited number of Rx and Tx Buffers; Reception of all CAN identifiers, all the time; High CPU load; Cheap implementation; CAN Controller memory area Tx Message Object 1 General Register Set Rx Message Object 1 Rx Message Object 2 Tx Message Object 2 opt. Message Object Register: - Data 0.. Data 7 - Message Configuration - Arbitration Mask - Message Control General Registers for: - CAN Controller Init - Handling of Status Information

19 19 / Basica Liviu / 2009 © Continental AG For Internal Use Only Physical Layer: Full CAN Full CAN Controller: Many Full-CAN controller provide a "Basic-CAN-Feature"; Large number of buffers for Rx and Tx; Buffers can be pre-defined for specific identifiers; All transmit frames in these buffers participate in arbitration; Less CPU load; More expensive; CAN Controller memory area Message Object Register: - Data 0.. Data 7 - Message Configuration - Arbitration Mask - Message Control General Registers for: - CAN Controller Init - Handling of Status Information Message Object 1 General Register Set Message Object n......

20 20 / Basica Liviu / 2009 © Continental AG For Internal Use Only Physical Layer: Bit timing Problem: Frequencies of the quartz oscillators of the CAN nodes usually differ; Re-synchronization of nodes during transmission is necessary; Solution: CAN Bit Timing CAN Bit Timing divides the bit time into several segments; Segments 1 and 2 can be lengthened or shortened during transmission; Re-synchronization of nodes during transmission is possible. Bit time tqtq Synch Segm Propagation Time Segment Phase Buffer Segment 2Phase Buffer Segment 1 sample point

21 21 / Basica Liviu / 2009 © Continental AG For Internal Use Only Physical Layer: The communication Transmission with Carrier Sense Multiple Access with Collision Avoidance CSMA/CA; each node monitors the bus; each node can start transmission; arbitration: dominant bits (low) win against recessive bits (high) on bus; the arbitration winner continues transmission; Node ANode B V+ Receive Node N V+ Receive dominant recessive 1 (high) 0 (low) Bus Line Transmit

22 22 / Basica Liviu / 2009 © Continental AG For Internal Use Only Physical Layer: Arbitration The arbitration of messages on the CAN bus is a hardware implemented bit-wise process. If one node switches a “HIGH” and reads a “LOW” he loses the arbitration and stops his transmission immediately. The lowest address number (ID) will always win this arbitration without any information loss of his message Bus Level Node A Node B Idle Start Bit listening only dominant recessive

23 23 / Basica Liviu / 2009 © Continental AG For Internal Use Only Physical Layer: Bit Coding - Bit Stuffing CAN data is transmitted with NRZ (No-Return to Zero) bit coding; Problems when using NRZ coding: long sequences of bits of the same polarity; no changes in voltage level for a longer time; no falling edges for synchronization; synchronization between sender and receiver may be lost; Solution: Bit stuffing after five consecutive bits of same polarity, insert one bit of reverse polarity; CRC code is calculated before bit stuffing is done; bit stuffing is done by the sender directly before transmission; de-stuffing is done by the receiver directly after reception; CRC code check is done after de-stuffing the frame; bit stuffing is applied to part of the frame from SOF to CRC field

24 24 / Basica Liviu / 2009 © Continental AG For Internal Use Only Data Link Layer: The message – Data Frame Data frames: generated by a CAN node when a node wishes to transmit data; standard frame – 11bit identifier (also called CAN 2.0A); extended frame – 29bit identifier (also called CAN 2.0B);

25 25 / Basica Liviu / 2009 © Continental AG For Internal Use Only Data Link Layer: The message – Data Frame SOF: Start of Frame. SOF = 0; marks the start of any CAN frame; provides a falling edge for hard synchronization of transmitter and receivers IDE: Identifier Extension IDE = 0 – Standard Frame; IDE = 1 – Extended Frame; DLC: Data Length Code the bytes number of the data field Data Field: contains the actual information to be transmitted; number of data bytes may range from 0 to 8 in units of bytes; transmission starts with the first data byte (byte 0), MSB first

26 26 / Basica Liviu / 2009 © Continental AG For Internal Use Only Data Link Layer: The message – Data Frame CRC: Cyclic Redundancy Check 15 bit check sum generated by transmitter and controlled by receiver the CRC Field Delimiter (DEL) marks the end of the CRC field ACK: Acknowledge – on Tx is recessive and on Rx is dominant; the ACK Field Delimiter (DEL) marks the end of the ACK field EOF: End of Frame consists of seven consecutive recessive bits; marks the end of the Data Frame; IFS: Interframe space consists of at least three consecutive recessive bits; no transmission is allowed during the Interframe Space (IFS); is needed by controllers to copy received frames from their Rx buffers

27 27 / Basica Liviu / 2009 © Continental AG For Internal Use Only Data Link Layer: The message – Remote Frame Remote frames: Destination node is able to require data from another node: RTR = 1 standard frame; extended frame;

28 28 / Basica Liviu / 2009 © Continental AG For Internal Use Only Data Link Layer: The message – Faults Fault Types in a CAN Bus System: Global Faults: lead to a breakdown of the system wide communication (e.g. short circuits or interrupts of the line, deadlock of the bus due to a permanent transmitting node; Local Faults: are limited to malfunctions of a node ore node components (e.g. interrupts in a bus connector, transmit problems of a transmitter, etc.); Temporary Faults: disturb the CAN bus system for a limited time; Permanent Faults: disturb the CAN bus system all the time, they are not reversible.

29 29 / Basica Liviu / 2009 © Continental AG For Internal Use Only Data Link Layer: The message – Error Frame Error frames: Each CAN node detecting an transmission error sends an “Error Frame” (Sequence of 6 bit with the same level): The bit actually appearing on the bus is different from the one transmitted More than five bits of equal polarity inside of a frame are detected until the ACK field CRC code calculated by receiver does not match received CRC code Fixed-form bit field contains one ore more illegal bits. e. g. violation of end of frame EOF format, CRC- or ACK-delimiter Acknowledge (ACK) bit is recessive IFS/IDLESOFMessage IDControl Data ACK IDLE CRCIFSEOF /SOF Bit Error Monitoring Area Bit Error Stuffing Monitoring Area IFS/IDLESOFMessage IDControl Data ACK IDLE CRCIFSEOF /SOF CRC Error Monitoring Area IFS/IDLESOFMessage IDControl Data ACK IDLE CRCIFSEOF /SOF Form Error Monitoring Area IFS/IDLESOFMessage IDControl Data ACK IDLE CRCIFSEOF /SOF ACK Error Monitoring Area IFS/IDLESOFMessage IDControl Data ACK IDLE CRCIFSEOF /SOF

30 30 / Basica Liviu / 2009 © Continental AG For Internal Use Only Data Link Layer: Error Frame – Status of the node For each detected error there is generated an active error flag (queue of six consecutive dominant bits) The error management unit uses two error counters: a receive error counter REC a transmit error counter TEC CAN node status after reset: TEC = REC = 0. For each detected error there is generated an passive error flag (queue of six consecutive recessive bits) If to many errors are detected by one node, this node is automatically disconnected from the bus. Error active node : 6 dominant bits Error condition Error passive node : 6 recessiv bits Error condition Error Passive Bus Off Error Active REC > 127 or TEC > 127 REC < 128 and TEC < 128 TEC > 255 HW reset

31 31 / Basica Liviu / 2009 © Continental AG For Internal Use Only Data Link Layer: Error Frame – Superposition of error flags In the case of one node detects a local error it will send an error flag. Other nodes may detect an error because of this error flag. They send also an error flag; After receiving/sending an error flag all nodes cancel the message; Each node which detects an error increments its error counters; Overlapping error flags result in a queue of 6 up to 12 active error bits followed by an error delimiter (queue of 8 recessive bits) Error condition Superposition of Error Flags Up to 6 bit error flag Node X IFS 3 bit IFS SOF / Idle Bus Idle or Start of Frame Error Flag 6 bit error flag Node A 8 Bit Error Delimiter 8 bit error delimiter Node X

32 32 / Basica Liviu / 2009 © Continental AG For Internal Use Only Data Link Layer: The message – Overload Frame Unit sends Overload Frame when at present it cannot receive frames any more due to high workload; Transmission of an Overload Frame is started during the first two bits of the Interframe Space (IFS) of the preceding frame; Other units react immediately by also transmitting Overload Frames Overload Flags overlap, resulting in up to 12 consecutive dominant bits; Implemented in very few (mostly older) controllers, though controllers must still be able to interpret correctly Overload Frames they receive; Overload Frames do not influence the error counters (TEC and REC) Overload Flag Bus Idle recessive Overload DelimiterInterframe Space Bus Idle dominant 3 bitsBus Idle6 dominant bitsBus Idle 8 recessive bits

33 33 / Basica Liviu / 2009 © Continental AG For Internal Use Only Data Link Layer: Transmitter / Receiver A unit originating a message is called “TRANSMITTER” of that message. The unit stays TRANSMITTER until the bus is idle or the unit loses ARBITRATION. A unit is called “RECEIVER” of a message, if it is not TRANSMITTER of that message and the bus is not idle. The message is valid for the transmitter, if there is no error until the end of END OF FRAME. If a message is corrupted, retransmission will follow automatically and according to prioritization. In order to be able to compete for bus access with other messages, retransmission has to start as soon as the bus is idle. The message is valid for the receivers, if there is no error until the last but one bit of END OF FRAME.

34 34 / Basica Liviu / 2009 © Continental AG For Internal Use Only SOFTWARE

35 35 / Basica Liviu / 2009 © Continental AG For Internal Use Only CAN subsystem: Vector solution Application Layer Presentation Layer Session Layer Transport Layer Network Layer Data Link Layer Physical Layer ISO/OSI Model CAN bus CAN Transceiver Application Software CAN Controller CAN Subsystem CCL IL TP DIAG NM Calibr CAN Driver GENy Tool

36 36 / Basica Liviu / 2009 © Continental AG For Internal Use Only Data Link Layer: CAN driver The generic CAN Driver code is independent of the Application. Functional scope: Initialize the CAN controller; Transmit a single CAN message: CanTransmit( ); Receive a single CAN message; Handle Bus-Off; Support sleep mode; Support special services. A CAN controller is said to be in "bus off" state if it's not participating in the bus traffic Some CAN Controller are supporting a so called sleep mode with reduced power consumption. 1.Interrupt control; 2.Assertions; 3.Support OSEK; 4.Multiple channels; 5....

37 37 / Basica Liviu / 2009 © Continental AG For Internal Use Only Generic precopy means that a common function ApplCanGenericPrecopy() is called for all identifiers. In case IL component is used the generic precopy is mandatory and it will be: IlCanGenericPrecopy() Data Link Layer: CAN driver – Rx HW Acceptance Filters The function ApplCanMsgReceived() is called by the CAN Driver on every reception of a CAN message after the hardware acceptance filter is passed. Receive Function SW Acceptance Filters DLC Check For a Basic-CAN Controller or the Basic-CAN object of a Full- CAN Controller the hardware acceptance filtering provided by the CAN Controller is not sufficient. Therefore a software acceptance filtering has to be supported by comparing the incoming message identifier with the complete list of all relevant message identifier. If a CAN message has passed the hardware acceptance filtering but is rejected by the software acceptance filtering (in case of a Basic CAN receive object) a special callback function will be called (if configured). Generic PreCopy Function PreCopy Function Copy DATA in Rx Reg. After the generic precopy (if configured) a precopy function separate for each message according to the entry in the description data is called. In the next step the data is copied to the global data buffer. Indication Flag Indication Function Then the indication actions defined for this message are performed. This means the indication flag is set and/or the indication function is called. The Application has to reset the indication flag before or after data processing. End Rx CAN ISR CAN message received CAN BUS Normally, the CAN Driver is informed by the CAN Controller via interrupt of the reception of a CAN message. That means the received CAN identifier has passed the hardware acceptance filtering of the CAN Controller and the entire message is stored in a receive register. In case of a Basic-CAN object, the message has to be retrieved and processed as fast as possible.

38 38 / Basica Liviu / 2009 © Continental AG For Internal Use Only Data Link Layer: CAN driver – Tx Queue MessagePreTransmit FunctionCopy DATA in Tx Reg. Tx Observe Confirmation Function/FlagCheck Queue SW Appl: CanTransmit(msg) Start Tx End Tx CAN ISR Confirm Tx ObserveCommon Confirmation Function CAN BUS First the CAN Driver checks whether the transmit path is switched to online state. If not the function returns with an error code. CAN Driver checks the availability of a hardware transmit object. If no object is available the transmit request is stored in the transmit queue. Within this user specific function the Application may copy the data to be transmitted directly to the CAN Controller hardware registers. This functionality is used to check the transmit path of the CAN Driver.The prototypes for the functions 'ApplCanTxObjStart', 'ApplCanTxObjConfirmed', 'ApplCanInit' are generated. A confirmation function for all messages is called: ApplCanTxConfirmation() The message-specific confirmation function is called. Afterwards the confirmation flag is set. If the CAN Driver is configured to use a transmit queue, after the processing the confirmation actions the CAN Driver checks whether the transmit queue is empty. If so the transmit interrupt routine is finished. CAN online ? no

39 39 / Basica Liviu / 2009 © Continental AG For Internal Use Only Network Layer: Network Management (NM) Functional scope: Controls the transition to Sleep Mode; enter the BusSleep mode simultaneously; Determine and monitor the Network Configuration; network nodes that are currently active; Provide status information of the NM node and the network itself; Bus Off Handling and Recovery; Interaction with CAN driver; Multiple ECUs Multiple ECUs are control units which are assembled several times within the CAN network with the same software. Example: Seat in the front on the left hand side and on the right hand side The NM ensures that all active ECUs within a network will enter the BusSleep mode simultaneously. This is required because an ECU will be woken up by any message on the CAN bus. That is the reason why a transition of a single ECU into the BusSleep mode only makes sense, if all the other ECUs are also ready for BusSleep mode and will not send further messages. NM decides when the CAN channel must be activated or deactivated.

40 40 / Basica Liviu / 2009 © Continental AG For Internal Use Only Network Layer: OSEK Network Management (OSEK-NM) Direct node monitoring requires a network-wide synchronization of NM messages. For this purpose a logical ring is used. In a logical ring the communication sequence is defined independently from the network structure. Therefore each node is assigned a logical successor. Address related communication has to take into account receiver and emitter. Each node has a unique identification which is known in the network. The network can enter different states like: NMOff, NMOn( NMAwake, NMBusSleep, NMActive ), NMShutDown

41 41 / Basica Liviu / 2009 © Continental AG For Internal Use Only Transport Layer: Transport Protocol (TP) A TP is needed if the data length exceeds 8 bytes. In this case, the sender must divide up the data into a number of CAN messages with the same identifier. Additional information is necessary for the recipient to put the data back together again. Functional scope: Message construction: unsegmented / segmented; Addressing modes: normal / extended / normal fixed / mixt; TP classes: single / static multi / dynamic multi; Error detection; e.g.: ISO 15765, SAE j1939, Bosch McNet... The CAN ID contains the complete addressing information (to each source and target address combination a unique CAN ID is assigned) The receiver is informed of the length of the whole message in the First Frame by the sender. The receiver answers with a Flow Control. The receiver gives the Block Size and the Separation Time to the sender in this Flow Control. The sender transmits the maximum Block Size Consecutive Frames after the reception of the Flow Control. The receiver does not answer it with a Flow Control, if all data has been transmitted. Unsegmented messages are transmitted by a Single Frame message. Single Frame messages can have a length of 7 data bytes at a maximum (normal addressing) respectively 6 data bytes (extended addressing). There is no Flow-Control. The CAN ID contains only the source address and the first data byte contains the target addressing information. The extended CAN ID contains the complete addressing information according J1939 Additionally to the extended CAN ID, according J1939, the first data byte contains a second target address information. Since ISO15765-2: 2003 the additional addressing mode mixed addressing on 11- bit CAN IDs is defined. The address extension is stored in the first byte followed by the TPCI information. In a Single TP class only one connection is possible, which is using the only available TpChannel. While using Static TP classes every connection is fixed assigned to a TpChannel The idea of dynamic TP classes is to use the circumstances that not all connections are used at the same time. Therefore a connection is necessary allocating a TpChannel at run-time. - single frame; - first frame; - flow control; - consecutive frame; - DLC.

42 42 / Basica Liviu / 2009 © Continental AG For Internal Use Only Presentation / Session Layer: Interaction Layer (IL) Functional scope: Interface between application layer and data link layer; Access macros and functions; Guarantees the consistency of any transmitted or received data and relieves the application of this area of responsibility; Multiple channel support; Receive messages: Signal oriented access to data: signal value, indication, firstvalue, data changed, timeout. Transmit messages: Signal oriented access to data to be sent; Tx modes for signals and messages (e.g. cyclic, on request, if active); Notification: confirmation, timeout.

43 43 / Basica Liviu / 2009 © Continental AG For Internal Use Only Communication Control Layer (CCL) The Communication Control Layer component is designed to simplify the use of the CAN in ECU’s by covering all CAN communication components like CAN Driver, Interaction Layer, Network Management, Transport Protocol etc.. Now the application has a simplified and smaller API to handle the CANbedded components (e.g. initialization, task handling, transceiver handling, network management handling etc.). main integration interface

44 44 / Basica Liviu / 2009 © Continental AG For Internal Use Only Generation Process Tools: GENy; CANdrGen (GENy) Static files(GENy) Configuration CAN data base (GENy) SW Tool (GENy) Generated files Own ECU All the above parameterization is considered here: CCL, IL, NM, TP etc. The.dbc file normally is designed by the vehicle manufacturer and distributed to all suppliers that develop an ECU. It contains information about all CANbedded components (e.g. network management type, messages and signals etc.). Every supplier uses the SAME dbc file for one type of vehicle to guarantee a common basis for development. SW Application SW Project A Windows program were you configure the Software Components of CANbedded. GENy generates configuration files for each software component Truck other ECU These file are the output of the execution of the generation tool. They are reflecting the project specific configuration. These files are available together with the tool directly from the tool supplier (Vector). These files will remain unchanged and are independent from the project specific configuration. Other project related files Compiled and linked project which will be loaded into the ECU HW, SW and Mechanical ECU.

45 45 / Basica Liviu / 2009 © Continental AG For Internal Use Only HIGH LEVEL PROTOCOLS

46 46 / Basica Liviu / 2009 © Continental AG For Internal Use Only j1939 standard The particular characteristics of J1939 are: 29-bit identifier; Peer-to-peer and broadcast communication; Transport protocols for up to 1785 data bytes; Network management; Definition of parameter groups. Interpretation of the CAN Identifier PDU = Protocol Data Unit Prio 3 bits Rez 1 bit 0x0 Data page 1 bit PDU Format 8 bits PDU Specific 8 bits Source Address 8 bits

47 47 / Basica Liviu / 2009 © Continental AG For Internal Use Only j1939: PGN Parameter groups Parameter groups combine similar or associated signals. In the specification SAE J1939-71 the parameter groups are defined with the signals they contain. Global PGNs for parameter groups that are sent to all (broadcast). Here all 16 bits of the PGN are used; the value of the upper 8 bits (PDU format) must be greater than 239 (0xF0); Specific PGNs for parameter groups that are sent to particular devices (peer-to-peer). With these PGNs, only the higher-value 8 bits (PDU format) are valid and the value must be smaller than 240. The lower value byte (PDU specific) is always 0. Each parameter group is addressed uniquely via a number (Parameter Group Number): PGN = DP + PDUF + PDUS Sample of a parameter group definition: Name: Engine temperature Transmission rate: 1 s Data length: 8 bytes Data page:0 PDU format: 254 PDU specific: 238 Default priority: 6 PG Number: 65262 (FEEE 16 ) Description of data: Byte: 1 Engine coolant temperature 2 Fuel temperature 3,4Engine oil temperature 5,6 Turbo oil temperature 7 Engine intercooler temperature 8 Not defined

48 48 / Basica Liviu / 2009 © Continental AG For Internal Use Only j1939: NM Network management: On a J1939 network, each device has a unique address. Each message that is sent by a device contains this source address. There are 255 possible addresses: 0..253 – Valid addresses of an ECU 254 – Zero 255 – Global

49 49 / Basica Liviu / 2009 © Continental AG For Internal Use Only j1939: BAM + DT For broadcast transmission, the BAM (Broadcast Announce Message) protocol is used. Here, after a BAM- PG the transmitter sends all data PGs at a minimum interval of 50ms.

50 50 / Basica Liviu / 2009 © Continental AG For Internal Use Only j1939: BAM + DT 1 st message: BAM (Broadcast Announce Message) -> data field 2 nd message: DT (Data Transfer) -> data field Control Byte 0x20 Byte Size 2 Bytes No. of Packets 1 Byte Rez 0xFF PGN 3 Bytes Sequence Number 1 Byte Data 7 Bytes - - - last message frame: DT (Data Transfer) -> data field Sequence Number 1 Byte Data n Bytes Reserved: 7-n Bytes 0xFF

51 51 / Basica Liviu / 2009 © Continental AG For Internal Use Only TESTING

52 52 / Basica Liviu / 2009 © Continental AG For Internal Use Only Simulation: CANoe, CANalyzer Own ECU Truck other ECU During development of own ECU the rest of the CAN network nodes (the truck with the other ECUs) might not be available. (CANoe) PC simulation Simulated ECU For development, testing and analysis purposes a (CANoe) simulation that runs on PC will simulate the behavior of the rest of the network. This simulation must be as accurate as possible in order to avoid the appearance of differences between the simulated network and the physical network. In this simulation the tester can send and receive messages from the data base and observe the behavior of his ECU. In the simulated CAN network and the physical CAN network the same CAN data base will be used (dbc). The CAN subsystem software will also be the same in both cases. CAPL (CAN Application Programming Language) programmed: -timers; -reaction at messages; -reaction at keyboard; -environment variables... CANoe features: -simulated network nodes; -normal and interactive generator blocks; -replay blocks; -interface panels; -trace windows, filters and logs; -statistics, graphs...

53 53 / Basica Liviu / 2009 © Continental AG For Internal Use Only CANoe: Simulation setup window Generator Block: - can output frames: data, remote, error - can be triggered via key press, time arrival of another message - can interact with the CAN data base Interactive Generator Block: - can output frames: data, remote, error - can be triggered via key press, time - can manipulate during simulation runtime - can display and manipulate signals inside message Network Node: - can be programmed in CAPL language in order to interact in all aspects with the CAN bus - can interact with the CAN data base Replay Block: - can output messages that are stored in a log file ( e.g.: CANOE.asc file) Simulated CAN bus - can be switched to real time mode Associated CAN data base

54 54 / Basica Liviu / 2009 © Continental AG For Internal Use Only CANoe: Measurement window Statistics window: - can graphically show the bus load with data and error frames Bus statistics window: - can show the bus load with data and error frames - can show the CANoe error state: active, passive, bus off Trace window: - shows the content of the bus: timing, channels, message ID, name, direction, length and data field Data window: - shows the values of various CAN signals in raw value or/and physical value Graphics window: - shows graphically the values of various CAN signals in raw value or/and physical value Logging window: - allows the user to record the content of the CAN bus into a log file Filters: - all windows can have applied filters: pass filter, stop filter, channel filter

55 55 / Basica Liviu / 2009 © Continental AG For Internal Use Only CAN data base ECU configuration: -source address; -received and transmitted messages and signals Message configuration: - ID, name, length, receiving and transmitting ECU, signal layout, transmission type and cycle time - etc; message list signal list CAN channel name Signal configuration: - length, bit ordering, unit, factor, offset, min and max, send type, timeout time, receiving ECUs, - etc.

56 56 / Basica Liviu / 2009 © Continental AG For Internal Use Only CANoe: Hardware configuration Channel information: -hardware equipment for connecting to CAN bus; -baudrate; -CAN controller and transceiver used Channel synchronization configuration: -baudrate -bit timing settings

57 57 / Basica Liviu / 2009 © Continental AG For Internal Use Only Vector Hardware Configuration: Windows driver The Vector Hardware Configuration utility enables you to configure installed Vector hardware. Besides the real hardware items in the tree view, two virtual (simulated) CAN channels for testing purpose (Vector applications) are available. For this purposes no hardware is necessary. Each hardware channel can be configured to work together with different applications like CANoe and CANalyzer depending on the purchased license. Vector Hardware Driver can be found in Windows Control Panel

58 58 / Basica Liviu / 2009 © Continental AG For Internal Use Only LITERATURE ISO 11519 - Road vehicles — Low-speed serial data communication ISO 11898 - Road vehicles — Controller area network (CAN); ISO 11992 - Road vehicles — Interchange of digital information on electrical connections between towing and towed vehicles; ISO 14229 - Road vehicles — Unified diagnostic services (UDS) - Specification and requirements; ISO 14230 - Road vehicles — Diagnostic systems - Keyword Protocol 2000; ISO 15765 - Road vehicles — Diagnostics on Controller Area Networks (CAN); ISO 16845 - Road vehicles — Controller area network (CAN) - Conformance test plan; SAE j1939 - Recommended Practice for a Serial Control and Communications Vehicle Network; http://www.semiconductors.bosch.de/en/20/can/index.asp http://www.vector-informatik.com/vi_index_en,,9656.html