CAN

HMS offers one of the largest product portfolios for Controller Area Network (CAN) based systems.


HMS products and services enable you to...

  • flexible and easily implement CAN and CAN-based higher layer protocols into your devices, either using ready-to-use modules or protocol stacks
  • connect CAN to any other industrial network
  • connect your PC to CAN, enabling PC based control, configuration and analysis
  • analyze and maintain your systems

CAN Technology Introduction

CAN Products and Services

PC Interfaces
 

Connect your PC to CAN

Ixxat PC CAN interfaces enable the easy connection of PC-based applications to CAN.

  • For control, analysis and configuration applications
  • Available in various form factors and for many PC interface standards
  • Powerful driver packages included for customer specific PC based applications 

PC CAN Interfaces

 
 CAN Infrastructure Components

Interconnect your systems and devices

For the interconnection of CAN-based systems, HMS offers a large portfolio of repeaters, gateways and bridges.

  • Cost savings due to simple wiring
  • Allows larger system expansion
  • Filter and conversion functionality
  • Increased system reliability and line protection by galvanic isolation
  • Bridging of large distances and easy system access using Bluetooth, Ethernet...

CAN Repeaters
CAN Bridges and Gateways

 
CAN Tools
 

Analyze and Configure

We offer a wide range of tools for your CAN development, system commissioning and for trouble-shooting.

  • canAnalyser – easily analyse, transmit and log your CAN and CAN FD messages and signals
  • CAN trouble-shooting – powerful mobile hand-held or PC based tools

canAnalyser
CAN Diagnosis and Trouble-Shooting


IO Modules for CAN, CANopen and EtherCAT
 

Connect digital and analog IO signals

For the connection of digital and analog IO signals to CAN and CANopen systems, HMS offers ruggedly built IO modules.

  • Supporting CAN and CANopen
  • Easy configurable digital and analog channels within one device

IO Modules

CAN – a short introduction

 

The "history" of CAN

The availability of low cost and high-performance microelectronic components allowed the automotive industry to introduce autonomous electronic control units (ECUs) for different functional areas, such as ignition, transmission control or antilock braking systems. 

It quickly became apparent that for further functional improvements – and thus a significant improvement in driving behavior – the synchronization of all processes distributed on the various control devices was necessary via controlled data exchange between the devices.

The introduction of digital communication systems in the automotive industry also was driven by the growing number of components for the body and convenience electronics which needed to be connected/linked such as: climate control, seat and mirror adjustment, electric windows, anti-theft systems, central light and locking mechanisms and so on.

In the automotive area, a digital communication system primarily should reduce the amount/length of wiring or mitigate neuralgic cabling points such as the grommet from the inside of the car to the front doors.

Due to the particularly high demands on the security of data transmission, in an environment full of electromagnetic interferences it was necessary to develop a suitable communication concept.

This was the initial point for the development of the Controller Area Network protocol (CAN) which was started by Bosch in 1983.

In the meantime – in addition to the use in cars – CAN is present in a wide range of application areas too

  • Utility vehicles (garbage and firefighting trucks)
  • Public transport (railways, trains, tramways, buses)
  • Agriculture & forestry (tractors, etc.)
  • Military
  • Aviation and Maritime
  • Buildings (elevators)
  • Construction (cranes, excavators, etc.)

 

Bus topology, number of participants

CAN networks are typically arranged in line structures with terminating resistors of 120 Ohm at each end of the line (see fig.). Stubs are permitted to a limited extend and also a star-type bus is possible (e.g. in automotive applications). The number of participants in each network is not limited by the protocol, but depending on the performance of the components used.

CAN repeaters are of multiple uses if CAN networks need to be extended:
They are used to establish a physical coupling of two or more segments of a CAN bus system, can be used to implement tree or star topologies or are of avail if it’s necessary to add long drop lines. In addition, network segments can be electrically decoupled using a galvanic isolated repeater. 

CAN-Technology-Line-Structure
Figure: Line topology of a CAN network

 

CAN telegrams

The communication on the CAN bus is done via "telegrams" which contain both “control bits” and “data bits”. The "standard" configuration of such a telegram is called a frame.

  • Data Frame: serves for the data transmission from a transmitter to one or more receivers at the initiative of the data source (transmitter)
  • Remote Frame: via a “remote frame” a bus subscriber (receiver) can request the sending of a certain message from a data source
  • Error Frame: The error frame signalizes all bus subscribers (transmitter or receiver) a detected error in the transmission
  • Overload Frame: via an Overload Frame the CAN controller may notify its overload; nowadays no longer implemented since the performance of the controllers is sufficient

 

Message exchange according to the producer-consumer principle

In contrast to a "node-oriented" transmission, in which a message is exchanged between two specific subscribers, the transmission of CAN messages is based on the "Producer-Consumer principle". A message sent by a subscriber (producer) can be read by all other participants (consumers). To this end, messages are not marked on a destination, but a unique "message identifier". Sending messages to all subscribers of a network is also called "Broadcasting". 

CAN-Technology-Format
Figure: 11 bit Identifier (standard format, CAN specification 2.0A)

  • SOF: Start of Frame = one dominant Bit
  • RTR: Remote Transmission Request –  if RTR-Bit is set it defines a Remote-Frame
  • IDE: Identifier Extension, 1 Bit
  • r0: reserved Bit
  • DLC: Data Length Code = 4 Bit (Number of bytes in data field, 0 to 8 Bytes, values 9 to 15 are not supported)

 

 

The (message) identifier denotes the content of the CAN message, not the device. In a measurement system, for example, a separate identifier may be assigned to the parameters temperature, voltage and pressure. However, several parameters also can be united under a single identifier, as long as the sum of the data does not exceed the maximum length of the data field.

The receiving devices decide on the basis of the identifier whether a message is relevant to them or not, and then filter them out of the message stream available on the bus.

The standard format of a CAN identifier usually is 11-bit; thereby 2.048 different messages per system are distinguishable. This number is sufficient for most applications. However, using 29-bit identifiers (Advanced Format) make possible the definition of up to 512 million different messages for special applications (e.g. Trucks, SAE J1939).

 

Message format

The beginning of a message (see image) is signaled by a leading dominant bit, followed by the 11-bit long message identifier and a further bit which distinguishes between a data message and data request telegram (remote frame).

Via a remote frame, a network node may cause the transmission of a particular message by another node in the system. The Control field specifies the transmission format (standard/extended) of a message and the number of subsequent data bytes.

The data field of a CAN message may contain zero to eight data bytes. The data field is followed by the 15-bit CRC segment; this segment allows the receiver to verify the received message. In the acknowledge field the transmitter of a message expects the confirmation of error-free reception of the transmitted message from at least one receiving network node. This confirmation – exclusively used for fault isolation on transmitter side – is given by all error-free receiving nodes on the network by sending a dominant bit in the acknowledge slot.

The end-of-frame field (EOF) ultimately denotes the completion of a completely error-free transmission of a CAN message.

 

CAN-Technology-Data-Frame

Figure: Format of a standard CAN message (Data Frame)

  • Start of Frame (SOF) = one dominant Bit
  • Arbitration field, consisting of an identifier segment (11 bit or 29 + 2 bits) plus an RTR bit (Remote Transmission Request)
  • Control field (CTRL) = 6 Bit
    • Identifier Extension (IDE) = 1 Bit
    • reserved = 1 Bit
    • Data Length Code (DLC) = 4 Bit (number of bytes in data field, 0 to 8 Bytes, values 9 to 15 are not supported)
  • Data field  (DATA) = 0 to 8x8 Bit
  • Checksum (CRC) = 15 bits followed by a recessive CRC Delimiter bit
  • Acknowledgment field (ACK) = 2 bits, consisting of an ACK slot plus a recessive ACK delimiter
  • End of Frame (EOF) = 7 Bit (recessive)
  • Intermission (IFS – Intermission Frame Space) = 3 Bit; min. Number of bits separating consecutive messages

 

Multimaster-capable, event-oriented message transmission

Each participant (node) of a CAN network can start sending a message as soon as the bus is free. It may happen that more than one network node begins sending a message at the same time. Thus a selection process (bus arbitration) is required which ensures that only one node actually continues with the transmission of its message.
Because each node can initiate a message transfer, a direct information transfer between all participants of the network is possible. The result is a much lower bus load or reduced requirement according to the data transmission rate compared to a cyclic message transmission.

Lossless, bitwise arbitration

The "arbitration" guarantees a smooth/proper message transfer on the CAN bus. During an "arbitration phase" it is determined which of the simultaneously transmitted messages has the highest priority. Only the network node sending this message, may proceed with the transmission of its message after the arbitration. The message with the lowest value of the message identifier has the highest priority.

During the arbitration phase – it includes the sending of the message identifier and the so-called RTR bit ("remote transmission request" bit) – each node monitors the signal level on the bus.

If a network node – himself having a recessive level (a recessive bit) – detects a dominant bus level (a dominant bit) it interrupts its transmission process immediately and switches into the receiving state. As with every bus arbitration, a message is sent, the procedure ensures "lossless" bus access.

 

CAN-Technology-Arbitration

Figure: Principle of lossless, bit-wise bus arbitration

Node 1, 2 and 3 start an arbitration process at the very same time. At time 2 node 2 detects that the bus doesn't have the recessive level he sent and completes its arbitration process. At time 3 node 1 resigns. At time 4 (end of the arbitration process) node 3 sends its data.

 

Priority-oriented communication

The arbitration process described above guarantees at all times that the message with the highest priority is sent as soon as the bus is free.
The principle of priority-oriented communication allows a very efficient utilization of the bandwidth available for data transmission. It allows that low-priority messages use the bus 100% without delaying the transmission of high priority messages significantly. For the highest-priority message with a transfer rate of 1 Mbit/s, the resulting maximum latency is 130. On the other hand when designing a CAN system one must take care that high-priority messages do not permanently occupy the bus. This is possible by introducing so-called "transmission blocking times" (CANopen: "Inhibit Time").

 

Bitrate and bus length

The principle of bit-wise arbitration used with CAN requires a comparison of the local bit levels of all nodes distributed over the bus network within a bit time interval.

Since the signal propagation time – required for the signal dispersion (propagation) over the bus – is proportional to the length of the bus, the required duration of a bit interval prolongs according to the increasing bus length.
The maximum possible network size is determined essentially only by the signal propagation time required on the bus medium: at 1 Mbit/s, for example a network span of 40 m is possible, at 80 kbit/s the network size may exceed 1000 m.


CAN-Technology-Data-Rate
Figure: Ratio of data rate to cable length
The dashed line shows the rule of thumb for data rates < 400 kbit/s and for line lengths > 100 m. The green area shows the permitted use without consideration of electrical transit times or other restrictive parameters. 

Maximum bus length (bus expansion) and maximum bit rate thus behave inversely. For a bus length of more than 100 m the following "rule of thumb" can be used:

Baud rate (in Mbit/s) x bus length (in m) = 60

 

Error detection and fault isolation

One of the main features of the CAN protocol is its high ability to detect transmission errors. Thereby CAN is able to cope with the very high standards for the networking of control devices within vehicles.
The high capability of error detection is achieved by combination of several measures. One of the most effective measures is to monitor the bus level by the sender of a message ("Bit monitoring"). In this way, all globally effective errors are already detected. In addition each message receiver also checks each received message using the CRC segment as well as fixed format elements. In this way also only locally effective errors are likely to be detected.
In addition, to the detection of transmission errors the CAN protocol also includes a mechanism for detecting and disconnection of defective nodes. This ensures that defective network nodes do not constantly interfere the message transfer.

 

Error signaling

Unlike communication concepts with a subscriber-oriented transmission, CAN - as a message-oriented protocol – is following/using the “Principle of error signaling” where each node checks each message transmitted on the bus for accuracy.
Once a sending or receiving node detects an error, it signals this to all other nodes by sending an error message (Error Frame).  This message contains an (otherwise invalid) bit combination of six bits of the same polarity, normally as a dominant bit sequence. All nodes detect the error signal and discard the already received part of a message. In this way a consistent dataset for all subscribers of the network is ensured.
Once a sending node has sent or received an error frame, he immediately attempts to send the previously sent message again by further bus arbitration.
The mechanism of error signaling ensures that the message exchange is accurate and consistent with all operational subscribers of a network.
As error signaling takes place immediately after an error is detected, very short error recovery times are guaranteed. The fact that the bus is only additionally occupied when an error has been detected, has the advantage - over acknowledging methods - of a much lower additional busload.

 

Higher layer protocols

The above-described CAN protocol standardized in ISO 11898 standard corresponds to layer-1/2 protocol of the OSI model of data communication. However, further functions are required for the realization of networks.
Two standards are available for applications in embedded systems and industrial automation: CANopen and DeviceNet. CANopen is the dominant standard for applications in embedded networks, DeviceNet is mainly used in industrial automation in the field of Rockwell Automation. In the field of commercial vehicles also the standard SAE J1939 is applied.