Introduction to K-Line Protocol

K-Line Protocol is an essential tool for technical engineers, allowing them to quickly and easily transfer data
between different systems. With its wide range of features and capabilities, it’s no wonder that K-Line Protocol
has become a popular choice for many engineering projects. In this tutorial, we’ll take a look at what K-Line
Protocol is all about and how technical engineers can use it in their work. As a technical engineer, it is important
to understand the various protocols available for communication between devices. One such protocol is K-Line
Protocol, which stands for “K Line Local Interconnect Network”. This protocol was developed in the early 1990s
and has been widely used ever since. It is an open source serial bus standard that enables two or more devices to
communicate with each other via a single line of communication. In this blog post we will discuss what K-Line
Protocol is all about and its features, applications, working principle as well as advantages and disadvantages
associated with it. K-Line is a serial communication protocol used in automobiles to allow various systems within
the car, such as the engine management system, transmission control system, and airbags, to communicate with
one another. The protocol is typically used to send diagnostic data, error messages, and other types of information
between these different systems. The “K” in K-Line is thought to stand for “K-wire,” which is a reference to the
single wire that carries data in the protocol. K-Line is an older protocol, and has largely been replaced by more
modern diagnostic protocols, such as CAN (Controller Area Network) and LIN (Local Interconnect Network).
Despite this, many older vehicles still use K-Line for some of their diagnostic and control systems, so it is still in
use today.

History and Invention of K-Line Protocol

K-line protocol was created by the German company Bosch as a way to securely exchange information between
electronic devices such as computers or automotive components without having to rely on physical wiring
connections. It works by using two wires – one carrying data from the source device (the transmitter) while
another carries back information from the receiving device (the receiver). The connection between these two
devices is encrypted with digital signatures so that only authorized users can access the transmitted data. This
makes K Line protocol highly secure compared to other methods of communication like Bluetooth or WiFI which
have weaker security protocols in place making them vulnerable to hacking attempts or eavesdropping attacks.

The development of the original version (K1) started in 1991 by Dr Klaus Wobst at Siemens AG Automotive
Electronics Division in Germany . The first version was released under GPL license on March 1st 1992 . The second
version (K2) was released on November 28th 1993 , followed by an improved third version (K3). All three versions
were based on CAN BUS technology but adapted specifically for automotive use cases where low latency data
transmission over long distances are required .

Features of K-Line Protocol

The K-Line protocol has several features that make it well-suited for use in the automotive industry:

1. Single-Wire Design: K-Line uses a single wire to transmit data between systems, which simplifies
the wiring and reduces the cost of implementation.
2. Support For Multiple Devices: K-Line allows multiple devices to be connected to the same
communication line, which makes it easier for the various systems in a vehicle to communicate
with one another.
3. Error Detection: K-Line includes error detection mechanisms, such as checksums, to help ensure
the accuracy of the data being transmitted.
4. Diagnostic Capabilities: K-Line was originally designed to support diagnostic functions, and it
remains an important protocol for this purpose. It allows repair shops to diagnose problems with
a vehicle’s systems and to obtain diagnostic information from the vehicle’s onboard computer.
5. Low Cost: K-Line is a simple protocol to implement, and it requires only a single wire and a small
number of components. This makes it an economical choice for car manufacturers and keeps the
cost of the vehicle down for the consumer.
6. Widely Adopted: K-Line has been widely adopted by the automotive industry and is supported by
many car manufacturers. This makes it easier for repair shops to diagnose problems with vehicles
 from different manufacturers, as they only need to have a single diagnostic tool that supports the
protocol.
Applications of K-Line Protocol

The K-Line protocol is primarily used in the automotive industry for diagnostics and communication between the
various systems in a vehicle. Some of the specific applications of K-Line include:

1. Engine Management: The K-Line protocol is used to communicate with the engine control
module (ECM) to diagnose and control various aspects of the engine, such as fuel injection, ignition
timing, and emissions control.
2. Transmission Control: The K-Line protocol is used to communicate with the transmission control
module (TCM) to diagnose and control the transmission, including gear shifting and clutch
engagement.
3. Airbag System: The K-Line protocol is used to communicate with the airbag control module
(ACM) to diagnose and control the deployment of airbags in the event of a crash.
4. ABS System: The K-Line protocol is used to communicate with the ABS control module to
diagnose and control the operation of the anti-lock braking system.
5. Climate Control: The K-Line protocol is used to communicate with the climate control module to
diagnose and control the heating and air conditioning system in the vehicle.
6. Body Control: The K-Line protocol is used to communicate with the body control module (BCM)
to diagnose and control various functions, such as power windows, power door locks, and lighting.
K-Line Protocol Message Frame Format

The K-Line protocol uses a simple frame format to transmit data between devices. Each frame consists of a start
bit, data bits, a parity bit, and a stop bit. The following is a more detailed explanation of the structure of a K-Line
frame:

1. Start Bit: The start bit is a logic low signal that indicates the beginning of a new frame.
2. Data Bits: The data bits are the payload of the frame and contain the actual data being transmitted.
The number of data bits can vary, but 8-bit frames are common in the automotive industry.
3. Parity Bit: The parity bit is an optional bit that is used to perform a basic error check on the data
bits. The parity bit is set to either logic high or low in such a way that the number of logic high bits
in the frame is either odd or even, depending on the type of parity used.
4. Stop Bit: The stop bit is a logic high signal that indicates the end of the frame. The stop bit provides
a clear delimiter between frames, allowing the receiver to distinguish between the end of one
frame and the start of the next.
The timing of the bits in a K-Line frame is critical, and the protocol specifies the exact time intervals that must be
used for the start bit, data bits, parity bit, and stop bit. The baud rate (or speed) of the communication can also
vary, but common speeds in the automotive industry are 9600 or 10400 baud.

Working Principle of K-Line Protocol

The K-Line protocol works by transmitting data over a single wire between the various electronic control units
(ECUs) in a vehicle. The communication is half-duplex, meaning that only one device can transmit at a time.

Here’s a basic overview of how the K-Line protocol works:

1. A request is sent from one ECU to another over the K-Line. This request typically contains a
service identifier (such as “read this parameter”) and the address of the desired ECU.
2. The recipient ECU listens for a request on the K-Line. If it recognizes the request, it responds by
transmitting the requested data.
3. The transmitting ECU listens for the response on the K-Line. When it receives the response, it
processes the data and stores it for later use.
4. The process repeats as needed, with different ECUs sending and receiving data over the K-Line.
The K-Line protocol uses a simple frame format to transmit data, as described in the previous answer. The start
bit and stop bit delimit the frame, and the data bits contain the actual data being transmitted. The parity bit is
used for error detection, and is optional.
The K-Line protocol is well-suited for use in the automotive industry because it is simple to implement, reliable,
and cost-effective. It uses a single wire for communication, which simplifies the wiring and reduces the cost of
implementation. Additionally, it supports diagnostic functions, making it a useful tool for repair shops and
technicians.

Overall, the K-Line protocol provides a straightforward and efficient method for communication between the
various ECUs in a vehicle. This allows the various systems in a vehicle to work together seamlessly, and makes it
easier for repair shops to diagnose problems and perform repairs.

Advantages of K-Line Protocol

The K-Line protocol has several advantages that make it a popular choice for communication between electronic
control units (ECUs) in the automotive industry:

1. Simple and Easy to Implement: The K-Line protocol uses a simple frame format and a single wire
for communication, making it easy to implement and cost-effective.
2. Reliable: The K-Line protocol is designed to be robust and reliable, and has been widely used in
the automotive industry for many years.
3. Supports Diagnostic Functions: The K-Line protocol supports diagnostic functions, making it a
useful tool for repair shops and technicians. This allows them to diagnose problems and perform
repairs more efficiently.
4. Low Cost: The use of a single wire for communication reduces the cost of implementation, making
the K-Line protocol a cost-effective solution for the automotive industry.
5. Compatible With Older Vehicles: The K-Line protocol is widely used in older vehicles, and
continues to be supported by many car manufacturers. This makes it an important tool for repair
shops and technicians who work on older vehicles.
6. Efficient: The K-Line protocol uses a half-duplex communication model, which allows for efficient
communication between the various ECUs in a vehicle. This helps to ensure that the various
systems in a vehicle work together seamlessly.
Disadvantages of K-Line Protocol

The K-Line protocol, like any communication protocol, has its disadvantages. Some of the main disadvantages of
the K-Line protocol include:

1. Limited Data Transfer Rate: The K-Line protocol has a limited data transfer rate, which can be a
bottleneck in systems that require high-speed communication.
2. Limited Number of Nodes: The K-Line protocol can support only a limited number of nodes,
making it unsuitable for large networks with many nodes.
3. Half-Duplex Communication: The K-Line protocol uses a half-duplex communication model,
which means that only one device can transmit at a time. This can lead to delays in communication
and decreased overall performance.
4. Limited Functionality: The K-Line protocol has limited functionality compared to other
communication protocols, and does not support some of the advanced features and functions that
are available in other protocols.
5. Requires Additional Hardware: The K-Line protocol requires additional hardware to be
implemented, such as isolation circuits, which can increase the cost of implementation.
6. CAN Protocol Tutorial
7. This CAN Protocol Tutorial gives you an overview of the ISO 11898-1 and ISO 11898-2 standards. This
provides a thorough introduction to the basics of CAN protocol specifications and its application in
automotive design, industrial automation controls, aerospace design, and various other applications. After
that obviously, we will go deep to understand the real networking protocol as to how come it is possible
to connect so many ECU in a vehicle.
8. Even if you have any questions you can also comment below to which the team will reply with a great
quality answer and I don’t think so you will get these answers easily from google. Though you are designing
any project which is based on CAN or working in any company where you need any support you can
contact us at any time. Let’s go start instead of wasting time.
 9. The figure below illustrates the application of the CAN bus protocol in a vehicle, enhancing sophistication,
flexibility, and safety through automation control for humans. There are two CAN networks with high and
low-speed baud rates. Another ECU connects these networks of different data rates, communicating
through a Gateway ECU.

CAN network used in Vehicle

History of CAN Protocol

• In 1985, Bosch developed CAN, a high-integrity serial bus system, to network intelligent devices
and replace automotive point-to-point wiring systems.
• With the widespread adoption of vehicle electronics, the automotive industry replaced heavy,
expensive, and bulky complex wire harnesses with CAN.
• In 1993, CAN became the international standard known as ISO 11898.
• Since 1994, several widely used higher-level protocols, such as CANopen and DeviceNet, have been
standardized on top of CAN.
• In 1996, the On-Board Diagnostics OBD-II standard which incorporates CAN becomes mandatory
for all cars and light trucks sold in the United States.
• Today markets including surface transportation, industrial automation, maritime, and avionics
systems have widely adopted CAN.
• Today CAN is incorporated into many micro-controllers (our Embedded has two CAN ports).
Introduction to CAN Protocol

Initially, electronic devices, nodes, and ECUs in vehicles were connected through point-to-point wiring systems.
The Automotive Manufacturers (OEM) started using more and more ECU’s in-vehicle, which resulted in bulky wire
harnesses that were heavier and expensive too which increases the cost of the vehicle. Then the ROBOT BOSCH
introduced a specialized internal communication network called the vehicle bus that interconnects electronic
devices inside the vehicle.

The Vehicle bus reduced the wiring cost, weight, and complexity, etc. Now there are several types of network
types and protocols used in vehicles by various manufacturers for the interconnection of ECU in a network. The
most common vehicle bus protocols are the CAN, LIN, VAN, IEBUS, FlexRay, MOST, DC-BUS, J1850, ISO 9141-1/-
2, D2B-Domestic Digital Bus.

Among them the various bus protocols are available in the Automotive Industry, the CAN emerged as the standard
in-vehicle network due to its energetic features for safety and it became the international standard known as
ISO-11898. Bosch originally developed the Controlled Area Network (CAN) communication protocol, which has
gained widespread adoption in the automotive industry.
CAN has become the foundation for various higher-level protocols like CANopen and DeviceNet, widely applied
in industrial communications. Additionally, CAN is utilized in specific vehicle classes, such as J1939 for commercial
vehicles and ISO-11783 for agricultural vehicles.

Applications of CAN Protocol

The main advantages of the CAN as a serial bus lie in the reduction of expensive wiring, as well as an increased
performance by enabling a distributed processing system. CAN has been used in the following applications as still
now also it is increasing in different applications:

• Passenger Cars.
• Building Automation.
• Trucks and Buses.
• Industrial Machine Control.
• Lifts and Escalators.
• Trains.
• Maritime Electronic Systems.
• Aircraft & Aerospace Electronics.
• Medical Instruments etc.
What is CAN Protocol?

The Controller Area Network (CAN) protocol serves as a communication protocol in automotive and industrial
applications. Specifically designed for microcontrollers and devices, it facilitates communication within a
networked environment without requiring a host computer. The CAN protocol is based on a message-based
communication model where each device on the network can send and receive messages. It uses a two-wire bus,
consisting of a CAN High (CANH) and a CAN Low (CANL) wire, to transmit and receive data between devices. The
CAN protocol provides a highly reliable and robust communication system, capable of transmitting data at high
speeds over long distances. CAN is widely used in diverse applications, such as engine control, body control,
powertrain control, and more.

In conclusion, The Controller Area Network (CAN) is a multi-master, broadcasting, multi-casting, message-based,
Event-driven, Configuration Flexible, half-duplex, serial type asynchronous networking protocol.

Features of CAN protocol

There are distinct features in CAN that set it apart from other protocols, making it widely utilized in various
applications.

• Information Routing.
• System flexibility.
• Message Routing.
• BroadCasting.
• Multicasting.
• Data Consistency.
• Bit-rate.
• Priorities.
• Remote data requests.
• Multi-master.
• Arbitration.
• Data integrity.
• Error detection.
• Error Detection performance.
• Error signaling and recovery time.
• Fault confinement.
• Connection.
• Single-channel.
• Bus values.
 • Acknowledgment.
• Sleep mode/wake-up.
Information Routing In CAN Protocol

In CAN network systems, a node does not make use of the system configuration means of the node address. In
the Controller Area Network (CAN) protocol, information routing relies on a message-based communication
model. Each device has a unique identifier to address messages on the bus. When a device sends a message, it
includes its identifier and the message data in the message frame. This frame is transmitted on the bus, and all
devices on the network receive it.

System flexibility In CAN Protocol

One of the key advantages of the Controller Area Network (CAN) protocol is its system flexibility. CAN networks
offer easy expansion and modification, providing flexibility in system design. Standard hardware and software
interfaces enable the addition or removal of devices without impacting overall system performance.

CAN networks can be configured in different topologies, such as star, tree, or linear, depending on the specific
application requirements. The use of standard connectors and cables also makes it easy to connect devices to the
network, and allows for easy integration with existing systems.

Another key aspect of the CAN protocol’s system flexibility is its ability to support multiple data rates. This means
that devices on the network can transmit and receive data at different speeds, allowing for greater efficiency and
optimization of network performance.

Message Routing In CAN Protocol

In CAN, each message is distinguished by a unique identifier that doesn’t specify the message’s destination but
only defines the data’s significance within the message. All connected nodes in the network can decide, through
message filtering technology using this message ID, whether to receive the data or not.

In a Controller Area Network (CAN) protocol, message routing refers to the process of transmitting messages
between devices on the network. The CAN protocol uses a message-based communication model, where each
device on the network has a unique identifier that is used to address messages sent and received on the bus.

When a device sends a message on the network, it includes its identifier and the message data in the message
frame. The message frame is then transmitted on the bus, and all devices on the network receive it. Each device
on the network then checks the identifier of the message to see if it is the intended recipient of the message. If
the device is the intended recipient, it processes the message data, and if not, it ignores the message.

Broadcasting in CAN Protocol

Broadcasting in the CAN Protocol involves sending a message to all nodes on the network, rather than to a specific
node or group. CAN messages, transmitted as data frames, include an identifier (ID) and data bytes. When
broadcasting, the ID field uses a special value, the “broadcast address” or “global address,” signaling all nodes to
receive and process the message.

Broadcasting proves beneficial in specific scenarios, like when a message requires simultaneous delivery to
multiple nodes or when a node needs to notify all other nodes on the network of a particular event or status
change. However, because broadcasting sends a message to all nodes on the network, it can also result in
increased network traffic and potential collisions, which can impact overall network performance.

Multicasting in CAN Protocol

Multicasting in a Controller Area Network (CAN) protocol refers to the ability to transmit messages to multiple
devices on the network simultaneously. In a CAN network, multicasting is accomplished using a multicast
message—a single transmission sent to multiple devices with distinct node identifiers.

When a device wants to send a multicast message on the CAN network, it includes a special identifier in the
message frame that indicates that the message is a multicast message. The message data is then transmitted on
the bus, and all devices on the network receive the message. Each device on the network checks the identifier of
the message to see if it matches their node identifier. If the message identifier matches their identifier, the device
processes the message data, and if not, it ignores the message.

Multicasting in the CAN protocol provides several advantages in system design and implementation. For example,
it allows multiple devices on the network to receive the same data without the need for individual message
transmissions, which can reduce network traffic and improve system efficiency. Multicasting facilitates the
implementation of intricate systems with multiple devices and sensors. It enables the transmission of data to
specific groups of devices on the network.

Data Consistency in CAN Protocol

Data consistency in a CAN network ensures a message is accepted simultaneously either by all nodes or by none.
This property is achieved through the concepts of multicast and error handling in the system.

In a Controller Area Network (CAN) protocol, data consistency refers to the accuracy and reliability of the data
transmitted and received on the bus. Data consistency is a critical aspect of the CAN protocol, particularly in
applications where real-time data transmission and control are essential, such as in the automotive and industrial
industries.

Different Mechanism for Data Consistency in CAN Protocol

The CAN protocol includes several mechanisms to ensure data consistency across the network. One of the most
important mechanisms is the cyclic redundancy check (CRC), which is included in each message frame
transmitted on the bus. The CRC is a mathematical function that generates a checksum value based on the data
in the message frame. When a device receives a message on the bus, it calculates the CRC based on the received
data and compares it to the CRC included in the message frame. If the two values match, the data is considered
consistent and is processed by the receiving device. If the values do not match, the data is discarded, and an error
is reported.

In addition to the CRC, the CAN protocol also includes error detection and correction mechanisms to ensure data
consistency. For example, the protocol uses bit stuffing to prevent the occurrence of long sequences of identical
bits, which can cause synchronization errors. The protocol also includes mechanisms for detecting and correcting
errors in the transmitted data, such as by using ACK and NACK signals to confirm successful transmission of
messages.

Bit-Rate in CAN Protocol

In a Controller Area Network (CAN) protocol, bit-rate refers to the speed at which data is transmitted on the bus.
The bit-rate is the number of bits that can be transmitted per second and is typically expressed in bits per second
(bps).

The bit-rate in the CAN protocol is adjustable to meet specific application requirements. While the maximum
supported bit-rate is 1 Mbps, lower rates are commonly employed in applications where reduced speeds suffice
for data transmission needs.

Priorities in CAN Protocol

In a Controller Area Network (CAN) protocol, priorities refer to the relative importance of messages transmitted
on the bus. Priorities are used to determine which messages should be transmitted first in cases where multiple
messages are waiting to be transmitted.

In the CAN protocol, every message incorporates a priority field determining its relative importance on the bus.
Usually, represented as an 11-bit identifier, lower values signify higher priorities. Consequently, messages with
lower priority values take precedence over those with higher priority values.

In Conclusion, the message identifier defines a static message priority during the bus access in a CAN network.
Mostly each message is having a unique Identifier integer value and it is represented in a hexadecimal number
system for increasing the reading and programming flexibility for a developer. The OEM should select the message
or his ID as to how much priority it is. The highest is the priority, the lowest is the value of that message.

Remote Data Request in CAN Protocol

Remote Data Request (RTR) is a feature of the Controller Area Network (CAN) protocol that allows a node to
request data from another node on the bus without waiting for the other node to initiate communication.

In a CAN network, nodes can transmit data frames to other nodes on the bus. However, in some cases, a node
may need to request data from another node that is not currently transmitting data. Instead of waiting for the
other node to send the data voluntarily, the requesting node can send a Remote Data Request frame with a specific
identifier. When the other node receives the request, it responds with a Data Frame containing the requested
data.

Utilizing the RTR feature in a CAN network can diminish data exchange latency and enhance efficiency. It enables
nodes to request specific data on-demand, avoiding continuous broadcasting of data that might not be needed by
all nodes on the bus.

Multi-Master in CAN Protocol

Multi-master in Controller Area Network (CAN) protocol refers to the ability of multiple nodes (i.e.,
microcontrollers or other devices) on a CAN bus to act as masters and initiate communication with other nodes.
In a multi-master CAN system, any node can act as a master and initiate communication with any other node on
the bus without requiring explicit permission or coordination from other nodes.

This is in contrast to a single-master CAN system where only one node, typically a central controller or host, can
initiate communication with other nodes. In a single-master system, all other nodes are slaves and can only
respond to requests from the master.

Multi-master CAN systems are useful in situations where multiple nodes need to share control of the bus and
exchange data with each other without a central controlling node. However, multi-master systems can also be
more complex and require additional coordination and arbitration mechanisms to prevent conflicts and ensure
reliable communication.

Arbitration in CAN Protocol

Arbitration is a fundamental aspect of the Controller Area Network (CAN) protocol, which is used to manage
access to the shared communication bus by multiple nodes on the network.

In a CAN network, each node has the potential to transmit data onto the bus at any time. When two or more nodes
attempt to transmit at the same time, a collision occurs, and the data frames become corrupted. To prevent
collisions and ensure reliable communication, CAN uses a form of non-destructive arbitration based on the
priority of the message.
The arbitration process starts when a node wants to transmit data onto the bus. The node checks if the bus is idle
or if any other node is currently transmitting. If the bus is idle, the node immediately begins transmitting its
message. If the bus is busy, the node waits until the current message is finished and then begins transmitting its
message.

During the arbitration, every transmitter compares the level of the bit transmitted with the level that is monitored
on the bus. If these levels are equal the node may continue to the send. When a recessive level is sent, but a
dominant level is monitored (discussed in the introduction part), the node has lost arbitration and must withdraw
without sending any further bits.

Data Integrity in CAN Protocol

Data integrity refers to the assurance that the data transmitted over a Controller Area Network (CAN) is accurate,
complete, and free from errors or corruption.

In a CAN network, data integrity is essential to ensure the correct operation of the system. CAN uses several
mechanisms to ensure data integrity, including error detection, error signaling, and error handling.

CAN uses a form of cyclic redundancy check (CRC) to detect errors in the data transmitted over the bus. The
transmitting node calculates a CRC value based on the data in the message, and includes the CRC value in the
message frame. The receiving node also calculates a CRC value based on the received data and compares it with
the CRC value included in the message. If the two values align, the message is deemed error-free. In case of a
mismatch, the receiving node communicates an error to the entire network.

Upon detecting an error, the node transmits an error message to all other nodes on the network. This message
includes details about the detected error type, such as a CRC error or bit error, along with the identifier of the
message that triggered the error.

Error Detection in CAN Protocol

To detect errors in a CAN network, the following measures have been taken:

• Monitoring involves each transmitter comparing the detected bit levels on the bus with the
transmitted bit levels.
• Cyclic Redundancy Check (CRC).
• Bit-Stuffing.
• Message Frame Check.
Error Detection Performance:

In the CAN network system the error detection mechanism having the following properties are:

Error Detection or Monitoring in CAN Protocol

1. All global errors are detected.

2. All local errors at transmitters are detected.
• CRC Error in CAN Protocol
1. Up to 5 randomly transmitted errors within a sequence can be detected.
2. Burst errors of length less than 15 in a message can be detected.
3. Errors of any odd number of bits in a message can be detected.
The total residual error probability of the undetected corrupted messages is less than 4.7 x 1011.

Error Signalling and Recovery Time in CAN Protocol

Error signaling and recovery time are important aspects of the Controller Area Network (CAN) protocol, which
are used to detect and recover from errors in the communication network.
When a CAN network detects an error, the node identifying the error transmits an error message to all other
nodes. This message includes details about the error type, like a CRC error or bit error, along with the identifier
of the problematic message.

In addition to signaling errors, CAN includes mechanisms for error recovery. Upon detecting an error, the node
retries the transmission. If the error persists, it might transition to a different error handling mode, like error
passive or bus off, depending on the error’s severity.

The corrupted messages are flagged by any node detecting an error. Such messages are aborted and are
retransmitted automatically. The recovery time from detecting an error until the start of the next message is at
most 29 bit times, provided there is no further error.

Fault Confinement in CAN Protocol

The CAN nodes are able to distinguish between short disturbances and permanent failures. Defective nodes are
the switched off is nothing but the Bus-Off mechanism in the CAN network.

Connection in CAN Protocol

The CAN serial communication link is a bus to which a number of the nodes may be connected or disconnected.
This number has no theoretical limit. Practically, the total number of nodes will be limited by delay time and/or
electrical loads on the bus.

The CAN bus consists of a single bidirectional channel that carries the data bits. From this data, the re-
synchronization information can be derived. The way in which this channel is implemented is not fixed in this
specification, e.g. single wire (plus ground), two differential wires, optical fibers, etc.

Bus Values in CAN Protocol

The CAN bus can have one of the two complementary values as dominant or recessive. During the simultaneous
transmission of the dominant and recessive bits, the resulting bus value will be dominant. For instance, in a wired-
AND implementation on the bus, the dominant level is represented by a logical ‘0,’ and the recessive level by a
logical ‘1.’

Acknowledgment in CAN Protocol

All receivers in the CAN network verify the consistency of the received message, acknowledging a consistent
message and flagging an inconsistent one.

Sleep/Wake-up Mode in CAN Protocol

To minimize the system’s power consumption, a CAN device can enter sleep mode, ceasing internal activity, and
disconnecting the bus drivers. Sleep mode concludes with a wake-up triggered by any bus activity or internal
system conditions.

Upon waking up, internal activity restarts. The transfer layer waits for the system’s oscillator to stabilize and
synchronizes itself to bus activity (checking for eleven consecutive recessive bits) before setting the bus drivers
to the ‘on-bus state again. To awaken other sleeping nodes on the network, a special wake-up message with the
dedicated, lowest possible Identifier can be used.

Why CAN Protocol?

Whenever there was no CAN protocol available in the industry at that time also vehicles were running with ECU.
These ECUs are also were able to communicate with each other using some other older protocols such as PWM,
VPW, J1850 serial protocol, etc. But at that time the technology was not that much improved and so many demerits
were also like low speed, more noise, more accidents, etc were happening.

As gradually technology improved, user’s requirements also increased as autonomous vehicles so that so many
OEM and vehicle ECU suppliers started their investigation to satisfy the customer requirement. Then Robot
BOSCH did the proper investigation with their best R&D team and designed the first CAN controller chip with
CAN transceiver to communicate among the ECUs.

This method really works fine to get the 3 Mbps speed at 40 meters of length with all other advantage features
which I have explained above. before this, there was no such protocol as CAN which can give these features which
causes it boomed the industry as nowadays most of the industry trying to use the CAN protocol.

Different types of CAN Protocol

The CAN Protocol finds applications across various fields due to its unique and comprehensive features. Unlike
protocols such as Ethernet, it stands out for its cost-effectiveness. Therefore, it is classified into distinct types,
including:

As per ISO standard, CAN Protocol is categorized as:

1.ISO-11898 Standard: Road vehicles – CAN for high-speed communication

2.ISO-11519 Standard: Road vehicles – Low-speed serial data communication Low Speed CAN / VAN
3.ISO-11992 Standard: Road vehicles – Electrical connections between towing and towed vehicles.
4.ISO-11783 Standard: ISO-BUS is for “Tractors and machinery for agriculture and forestry—Serial
control and communications data network”.
5. EIA RS-485 Standard: Electrical Characteristics of Generators and Receivers for Use in Balanced
Digital Multipoint Systems (formerly used for CAN Physical Layer).
The CAN Protocol is categorized based on the number of wires used for the Physical Layer as:

1. SW CAN: Single Wire CAN used for low speed and less risk data transmission CAN network. Single
wire CAN interface has a lower data rate of up to 33.3 Kbits/s and also named SAE-J2411. The
devices that do not require high performance like seat and mirror adjuster use a Single wire CAN
interface.
2. DW CAN: Double Wire CAN used for high speed and fault-tolerant CAN network.
Categorization of CAN Protocol Based on Physical Layer Speed

1. Low-Speed CAN Physical Layer:

The Low Speed CAN basically be used for 40 kbps to 125 kbps CAN bus. This is also called a fault-tolerant CAN
bus. This kind of CAN bus also can run without a termination resistor. The Low Speed CAN bus voltage levels are:

• Dominant Voltage Level: CAN-L is 1.4 v and CAN-H is 3.6 v

• Recessive Voltage Level: CAN-L is 0 v and CAN-H is 5 v.
2. High-Speed CAN Physical Layer:

The High Speed CAN basically be used for 40 Kbps to 1 Mbps data rate. This kind of bus must be terminated with
a termination resistor from 108 Ohm to 132 Ohm as per bus system-specific. The High Speed CAN bus voltage
levels are:

• Dominant Voltage Level: CAN-L is 1.5 v and CAN-H is 3.5 v.

• Recessive Voltage Level: CAN-L is 2.5 v and CAN-H is 2.5 v.

CAN Generation Improvement in the CAN Protocol is categorized as:

1. Classical CAN: Normal CAN protocol having speed up to 1 Mbps with a maximum of 8-bytes of
Payload in a single data packet.
2. CAN-FD: CAN-FD(Flexible Data Rate) having speed up to 2 Mbps with a maximum of 64-bytes of
payload in a single data packet (CAN FD-SiC up to 5-8Mbit/s).
 3. CAN-XL: CAN-XL (Extra/Extended Length) having speed up to 20 Mbps with a maximum of 2048-
bytes of payload in a single data packet.
Categorization of CAN Protocol Based on Data Rate

1. Low-Speed CAN: Speed between 1 kbps – 125 kbps.

2. Medium-Speed CAN: Speed between 125 kbps – 500 kbps.
3. High-Speed CAN: Speed between 500 kbps – 1 Mbps.
4. Ultra High-Speed CAN (CAN-FD): Speed between 1 Mbps – 2 Mbps.
5. Extended Ultra High-Speed CAN (CAN-XL): Speed between 2 Mbps – 20 Mbps.
Categorization of CAN Based on Length

1. Class-A: 50 Kbps speed at 1 Kilo Meter (1000 meter) of CAN bus length.
2. Class-B: 125 Kbps speed at 500 Meters of CAN bus length.
3. Class-C: 1 Mbps speed at 40 Meters of CAN bus length.
As per Identifier, CAN is categorized as:

1. Basic/Standard CAN: Message Identifier is 11-bit (211 = 2048) which helps to create limited unique
messages or message identifiers for the lowest number of ECU with lowest data communications
in simple CAN networks.
2. Extended CAN: Message Identifier is 29-bit (229 = 536,870,912) which helps to create millions of
unique messages for data communications in complex CAN networks.
OSI Layer used in CAN Protocol

As we all know that each computer system follows the 7-layers of the OSI (Open System for Interconnection) layer
for communication between two or more computers. In the automotive field, each ECU’s are nothing but a
computer system that used the same OSI layer as shows in the below image:

General OSI Layer Design

Among all of the OSI layers, CAN protocol uses only two-layer since it is a part of an ECU for data or information
communication. So for communication purposes, it is sufficient for most of the protocol. These layers are:

1. Physical Layer.
• Physical Signalling Characteristics(PSC).
• Physical Medium Attachment (PMA).
• Medium Dependent Hardware (MDH).
2. Datalink Layer.
• Logical Link Control (LLC).
• Medium Access Control (MAC).
CAN Protocol Physical Layer

The physical layer of the Controller Area Network (CAN) protocol defines the electrical and mechanical
characteristics of the communication medium used to transmit data between nodes in the network. It defines the
CAN transceiver characteristics.

CAN Protocol OSI Layer Design

The Physical Layer divides into three types:

1. Physical Signalling Characteristics(PSC) of CAN Physical Layer

CAN uses a differential signaling scheme to transmit data over the communication medium. In differential
signaling, the voltage on one wire is higher than the voltage on the other wire. The voltage difference between
the two wires represents the transmitted data. The differential signaling scheme provides several advantages,
including noise immunity, signal integrity, and low power consumption. Physical Signalling Characteristics defines
the bit encoding/decoding, bit timing, synchronization.

2. Physical Medium Attachment (PMA) of CAN Physical Layer

CAN uses a twisted pair of wires to transmit data between nodes in the network. The twisted pair helps to reduce
electromagnetic interference and improve signal integrity. Implementing CAN is possible with alternative physical
media, like optical fiber or wireless communication. Physical Medium Attachment defines the CAN transceiver
characteristics.

3. Medium Dependent Hardware (MDH) of CAN Physical Layer

Medium Dependent Hardware (MDH) in the Controller Area Network (CAN) protocol refers to the hardware
components that are responsible for the physical transmission of data over the communication medium. The MDH
is a part of the physical layer of CAN and includes components such as transceivers, connectors, and termination
resistors. The main function of the MDH is to convert the digital signals from the CAN controller into the
appropriate signals for transmission over the physical medium as per CAN protocol voltage levels, such as a
twisted pair of wires or optical fiber. The MDH also accepts incoming signals from the communication medium
and transforms them into digital signals processed by the CAN controller.
 CAN Transciever Functionality Design Diagram

CAN Protocol Data-Link Layer

The data-link layer is the second layer of the Controller Area Network (CAN) protocol, which is responsible for
framing and transmitting data between nodes in the network. The data-link layer of CAN is divided into two sub-
layers.

CAN Protocol OSI Layer Detailed Design

The data-link layer is divided into two types:

1. Logical Link Control (LLC) Sub-Layer: This sub-layer is responsible for error detection and
correction, flow control, and message filtering. It receives messages from the higher layers and
adds a header and a trailer to each message to create a frame. The header contains information
about the source and destination nodes, as well as the message identifier, while the trailer contains
an error check sequence (ECS) to detect errors in the data.
2. Media Access Control (MAC) Sub-Layer: This sub-layer is responsible for arbitration and collision
detection. It controls access to the communication medium and ensures that only one node
transmits data on the bus at any given time. The MAC sub-layer uses a priority-based arbitration
scheme to resolve conflicts between multiple nodes trying to transmit data at the same time. The
node with the highest priority wins the arbitration and is allowed to transmit its message on the
bus.
The data-link layer of CAN also includes several error handling mechanisms, such as error signaling, error
detection, and error recovery. These mechanisms guarantee accurate and reliable data transmission between
network nodes, even in the presence of errors or interference.

What are the Types of CAN Protocol Frames

I hope you would have cleared about all the types of CAN protocol available but commonly one type which I missed
and going to explain here because it is common for each type of CAN which I have explained above.

As per CAN frames by which all the CAN standards are communicating among the ECU in a CAN network. There
are 5 types of CAN frames such as:

1. Data Frame: Used to send the data in a CAN network.

2. Remote Frame: Used to request the data in a CAN network.
3. Error frame: Used to send the error information in a CAN network.
4. Overload Frame: Used to notify the incomplete data reception.
5. Inter-Frame Space (IFS): Used to delay the next packet data transmission.
I hope we will not waste the time, Lets go to discuss each frame in detail below:

Data Frame Format In CAN Protocol

The data frame within the CAN protocol facilitates the transmission of data across the CAN network. It allows
others in the network to receive data based on their specific requirements. The data frame having consisted of 7
fields that are taking care of secure data transfer from transmitter to receiver successfully.

Basically, there are two types of data frames according to the frame as the standard frame (11-bit ID) and the
extended frame (29-bit ID). First, let’s go discuss the standard CAN frame after then we will discuss the Extended
CAN frame.

Standard or 11-bit CAN Protocol Frame Format

The standard CAN was initially developed by BOSCH, allowing a maximum of 2^11 (2048) unique messages to be
generated and utilized in a CAN network for data communication. The entire frame is segmented into seven
typical fields, aiding in the identification, detection, correction, and validation of a CAN message within the CAN
network. Please refer to the figure below for illustration:

11-bit CAN Standard Frame

CAN Protocol Frame Field Explanation

A Data frame consists of seven distinct bit fields: Start of the frame, Arbitration field, Control field, Data field, CRC
field, ACK field, and End of the frame. The Data field has the flexibility to be of length zero. Each field is elaborated
below:
SOF Field in CAN Protocol Data Frame

The Start of frame marks to the beginning of Data frames and remote frames. It is consists of a single dominant
bit. A node is only allowed to start transmission when the bus is idle. All nodes must synchronize to the leading
edge initiated by the node commencing the transmission at the start of the frame.

Arbitration Field in CAN Protocol Data Frame

The Arbitration Field is vital in the Controller Area Network (CAN) protocol, resolving conflicts when multiple
nodes attempt simultaneous data transmission on the shared medium. Positioned in the header of a CAN message,
the Arbitration Field is integral to the Data Link Layer of the CAN protocol.

1. 11-Bit Identifier: The Identifier field is the heart of the CAN data frame. There are two main
purposes of this identifier field is:
• To determine which node needs to gain the bus access whenever more than one node
trying to send the messages on the same can bus.
• To identify the type of message it is. That means in can protocol it is message-based
so there is nothing like an address for any ECU. It will broadcast whoever interested
they will receive it. Now you tell how it will get to know which data he needs to receive
or not? Yes for this in CAN protocol, each identifier is unique and it will be assigned to
a message. These data including some more data will create a database called a CAN
database.
2. Remote Transmission Request (RTR): It is extended for the purpose of Remote Transmission
Request. The main objective of this bit is to identify either a data frame or a remote frame. If the
RTR bit is 1, it is a remote frame else it is a data frame.
Control Field in CAN Protocol Data Frame

The Control field consists of six bits. It includes the Data length code and two bits reserved for the future of the
expansion. The reserved bits must be sent as dominant. Receivers accept dominant and recessive bits in all the
combinations.

1. IDE: If the Identifier Extension bit is Dominant then it is a standard (11-bit ID) CAN and if the IDE
bit is recessive then it is an Extended (29 bit ID) CAN.
2. R0: This is a reserved bit for future use. It might be used in the future CAN standard amendment.
It is always recessive in the CAN data field.
3. DLC: The Data length code, which is 4 bits wide, is transmitted within the Control field. The DLC
bits can code data lengths from 0 to 8 bytes.If the DLC exceeds 8, it is considered a “don’t care”
condition and will be rejected by the Transmitter ECU.
Data Field in CAN Protocol

Within the Controller Area Network (CAN) protocol, the Data Field resides in the Data Link Layer, encompassing
the actual data transmitted among nodes on the network. The Data Field follows the Arbitration Field and the
Control Field in the CAN message frame.

In the CAN protocol, the Data Field can accommodate up to 8 bytes of data. It serves as a conduit for conveying
information like sensor readings, control signals, and status updates among network nodes. The actual length of
the Data Field depends on the length of the message being transmitted.

CRC Field in CAN Protocol Data Frame

The CRC field contains the 15-bit CRC Sequence followed by 1-bit CRC Delimiter.

Cyclic Redundancy Check (CRC) in CAN Protocol Data Frame

The CRC field is nothing but an algorithm or a polynomial function you can say. This function will be implemented
in all available ECUs within the CAN network. If you will give the same input, then the output will be the same for
all.
When a transmitter sends a data frame, it inputs the SOF, Arbitration, Control, and data field data. Afterward, it
generates a 15-bit CRC data, subsequently added to the CRC field within the CAN data field. When a transmitter
sends a data frame, it inputs the SOF, Arbitration, Control, and data field data, generating a 15-bit CRC data added
to the CRC field within the CAN data field.

Then the Transmitter ECU will generate the total frame and it will send it over the CAN bus. Then the receiver
ECU will receive it. The receiver ECU also has the same CRC algorithm. It will also give the received SOF,
Arbitration, Control, and data field as input to that algorithm. Then it will generate a 15-bit CRC field and the
controller will compare both the received CRC and generated CRC. If both the CRC is the same it will receive the
data or else it will generate the CRC error.

CRC Delimiter in CAN Protocol Data Frame

In the Controller Area Network (CAN) protocol, the CRC Delimiter resides in the Data Link Layer, specifically the
Logical Link Control (LLC) sub-layer. Positioned after the data field and preceding the ACK field in a CAN message,
the CRC Delimiter is a bit sequence. It serves two key functions: marking the end of the data field and providing a
checksum for error detection.

The CRC Delimiter consists of a delimiter bit, six recessive bits, and two dominant bits, forming a fixed bit
sequence of “01111110“. This bit sequence is known as the CRC Delimiter or End of Frame (EOF) sequence. The
delimiter bit is always recessive, while the six recessive bits and two dominant bits are fixed.

The CRC Delimiter enables error detection in the CAN protocol by providing a checksum of the data field, which
can be used to detect errors introduced during transmission. The CRC Delimiter is also used to indicate the end
of the data field and to synchronize the receiving nodes in the network.

ACK Field in CAN Protocol Data Frame

When a node transmits a message on the CAN bus, it waits for an acknowledgment from the receiving node. The
acknowledgment signal indicates that the message has been received correctly and that the receiver is ready to
receive the next message.

The acknowledgment mechanism in CAN works as follows:

1. When a node transmits a message on the bus, it monitors the bus to detect any errors or
interference.
2. If the transmission is successful, the node waits for an acknowledgment signal from the receiving
node.
3. The receiving node sends an acknowledgment signal by transmitting a dominant bit on the bus
immediately after receiving the message.
4. If the transmitting node detects the dominant bit, it knows that the message has been received
correctly and that the receiving node is ready for the next message.
5. If the transmitting node does not receive an acknowledgment signal, it assumes that the message
was not received correctly, and it may retransmit the message after a short delay.
The ACK mechanism in CAN ensures that messages are reliably transmitted and received, even in the presence of
errors or interference. It enhances the reliability and safety of the system, which is critical in many applications
of the CAN protocol, such as automotive and industrial control systems.

ACK Delimiter Bit in CAN Protocol Data Frame

In the Controller Area Network (CAN) protocol, the ACK Delimiter bit is a single bit that follows the ACK Field in
a CAN data frame. The ACK Delimiter bit serves as a delimiter between the ACK Field and the End of Frame (EOF)
bit.

The ACK Delimiter bit is always recessive, meaning that it has a value of 1 and does not interfere with the dominant
state of the bus. The recessive state of the ACK Delimiter bit allows for seamless transition from the ACK Field to
the EOF bit, without any interference or corruption of the data.

The ACK Delimiter is the second bit of the ACK field and has to be a recessive bit. As a consequence, the ACK Slot
is surrounded by the two recessive bits (CRC Delimiter, ACK Delimiter).

End Of Frame (EOF) in CAN Protocol Data Frame

In both the Data and Remote frames, each frame’s data is separated by a flag sequence comprising seven recessive
bits. The 7 recessive bits are constant, confirming the idle state of the CAN BUS. The EOF (End of Frame) bit holds
significance in the CAN protocol, marking the conclusion of a CAN message frame and signaling to the receiving
node the successful reception of the message. Additionally, the EOF bit provides time for the bus to transition
back to the intermission period, preparing for the transmission of the next message.

Extended or 29-bit CAN Protocol Frame Format

There are two types of CAN protocol defined in ISO 11898-1 standard. Both standards are designed by Robot
BOSCH. You would have thought why there are two types of CAN? Yes obviously, let me explain this. Basically,
the main difference is the CAN data frame. In this data frame, the Arbitration and control field is having some
change, except this, there is no more change in between them.

The primary advantage of the 29-bit CAN over the 11-bit CAN is its ability to accommodate a greater number of
unique CAN messages. This becomes essential when dealing with increased functionality and data requirements
in a vehicle, which may not be feasible with an 11-bit CAN. In such cases, the 29-bit CAN proves valuable. The
image below illustrates the 29-bit CAN frame format.

29-bit CAN Frame Format

The above figure, it is showing each and every bit field with clear visibility. As I have already told you except for
the arbitration and Control field, others are the same, we will only discuss these fields.

Substitute Remote Request (SRR) in Extended CAN Frame

The SRR, or Substitute Remote Request, consistently holds a recessive position in the extended frame format. In
the context of our CAN system, which supports both 11-bit and 29-bit IDs in the CAN-2.0B standard, the question
arises: why utilize this bit? The significance becomes apparent when considering a scenario where both an 11-bit
ID as a data frame and a 29-bit ID as a remote frame attempt to transmit messages simultaneously. In such
instances, the arbitration technology comes into play to efficiently manage bus access and resolve potential
conflicts.

In 11-bit Identifier, the RTR bit resides in the 12th position, while in a 29-bit ID, it occupies the 30th position. The
challenge arises during arbitration, where the remote frame gains precedence in violation of CAN rules. To
address this, we introduce the SRR bit, consistently setting it to a recessive state. Its purpose is to ensure that the
11-bit Identifier gains bus access, preventing any violation of the BUS access rule during arbitration.

R1 and R0 in Extended CAN Frame

The Extended frame is having two reserve bit in the control field like R0 bit in the 11-bit CAN.

CAN Protocol Remote Frame Format

In CAN, there are two types of communication. One is the sender and receiver and the second one is client-server
communication.
The sender-receiver concept involves the Transmitter ECU sending updated data on the CAN bus, and any
recipient in need will receive it. In the case of a Client-server, when an ECU needs any data like the vehicle speed
in Instrument cluster ECU, it will send a remote frame to the CAN bus.

Then the ECU suppose VMCU ECU who is having this data will receive by checking the RTR bit of that remote
frame. After then the VMCU ECU will read the vehicle speed from the sensor and put it in the data field of the
same frame and makes the RTR bit 0. Then the VMCU will send it again back and the Instrument ECU will receive
it.

A node acting as a RECEIVER for certain data can stimulate the relevant source node to transmit the data by
sending a Remote the Frame. A Remote frame consists of six distinct bit fields: Start of the frame, Arbitration field,
Control field, CRC field, ACK field, and End of the frame.

Why RTR bit is always recessive in CAN Protocol?

The RTR bit of a Remote the frame is always recessive (cf. Data frames where the RTR bit is dominant). In a Remote
frame, there is no Data field, regardless of the Data length code’s value. The Data length code corresponds to that
of the associated Data frame and can be assigned any value within the permissible range of 0-8.

CAN Protocol Remote Frame Format

The polarity of the RTR bit indicates whether a transmitted frame is a Data frame (RTR bit dominant) or a Remote
frame (RTR bit recessive).

CAN Protocol Error Frame Format

The error frame is used to notify an error that has occurred during the transmission. The error frame consists of
an error flag and an error delimiter. The Error frames are transmitted by the hardware part of the CAN controller.

This Error Frame in CAN protocol having consists of an Error Flag, which is having 6 bits of the same value, and
an Error Delimiter, which is 8 recessive bits. The Error Delimiter provides some space so that the other nodes on
the bus can send their Error Flags when they detect the first Error Flag.

CAN Protocol Error Frame Format

The CAN protocol error frame is having two fields:

1. Error Flag
2. Delimeter Flag
Error Flag in CAN Protocol Error Frame

The error flag bits are the minimum of 6 bits which generates whenever any error will occur in the CAN network
at the time of data transmission. There are two types of error flags: the active-error flag and the passive-error
flag.

• Active-Error flag: 6-12 consecutive dominant bits.

• Passive-Error flag: 6-12 consecutive recessive bits.
Active Error Flag in CAN Protocol Error Frame

In the Controller Area Network (CAN) protocol, an Active Error Flag is a bit that is transmitted in the Error Frame
to indicate the presence of an error on the CAN bus. The Active Error Flag consists of six consecutive dominant
bits bit that is sent by a node when it detects an error on the bus.

When a node detects an error, it sends an Error Frame, which contains the Active Error Flag and other bits that
provide information about the type of error that occurred. The Active Error Flag serves as a warning to all nodes
on the bus that an error has occurred and that they should take appropriate action.

When a node receives an Error Frame with the Active Error Flag, it acknowledges the error by sending an
Acknowledge Error Frame, which consists of six recessive bits. The Acknowledge Error Frame is sent to all nodes
on the bus and signals that the node has received the Error Frame and is ready to resume normal communication.

Passive Error Flag in CAN Protocol Error Frame

In the Controller Area Network (CAN) protocol, a Passive Error Flag is a bit that is transmitted in the Error Frame
to indicate the presence of an error on the CAN bus. The Passive Error Flag is a recessive bit that is sent by a node
when it detects an error on the bus.
When a node detects an error, it sends an Error Frame, which contains the Passive Error Flag and other bits that
provide information about the type of error that occurred. The Passive Error Flag serves as a warning to all nodes
on the bus that an error has occurred and that they should take appropriate action.

If a node receives an Error Frame with a Passive Error Flag, it does not acknowledge the error by sending an
Acknowledge Error Frame. Instead, the node enters an error state and stops transmitting data on the bus until
the error has been resolved.

What is the need of Passive Error Flag in CAN Protocol

The Passive Error Flag is used in cases where a node detects an error, but it is not severe enough to warrant a
dominant Active Error Flag. The Passive Error Flag allows the node to signal that an error has occurred while
maintaining the integrity of the bus and minimizing the impact on other nodes.

In summary, the Passive Error Flag is a recessive bit that is transmitted in the Error Frame in the CAN protocol to
indicate the presence of an error on the bus. The Passive Error Flag serves as a warning to all nodes on the bus
that an error has occurred and that they should take appropriate action. The Passive Error Flag is used in cases
where a node detects an error that is not severe enough to warrant a dominant Active Error Flag, allowing the
node to signal that an error has occurred while maintaining the integrity of the bus and minimizing the impact on
other nodes.

Depending on the timing at which an error is detected by each unit connected to the bus, error flags may overlap
one on top of the other, up to 12 bits in total length. This is called an overlapping of the error flag.

Error Delimeter in CAN Protocol Error Frame

Error Delimiter is an important part of the CAN (Controller Area Network) protocol. It is used to indicate that a
transmission error has occurred in the network, allowing for corrective action to be taken. The error delimiter
consists of 8 recessive bits.

The purpose of Error Delimiter is to detect when errors occur during data transmission over a CAN bus system.
When an error occurs, such as bit stuffing or bit-level corruption, the transmitting node sends out an “error
frame” with special bits set aside as delimiters that signal all other nodes on the network about this occurrence
so they can take appropriate steps towards correcting it or avoiding further damage from occurring due to
corrupted data being sent across the wire.

When these delimiters are received by another node in receipt of this message, they know there was some sort
of issue with its delivery and should take preventative measures like dropping any subsequent frames until things
have been cleared up again or re-transmitting if needed – depending upon what type of application layer protocol
you may be using at higher levels within your stack architecture.

To learn more about the CAN Protocol Error frames and their types, you can follow this Types of Error in CAN
Protocol.

There are also an Error Triangle in CAN Protocol. Please select this Link to learn about the CAN Bus Error
Handling.

CAN Protocol Overload Frame Format

The overload frame is used by the receiver unit to notify that it has not been prepared to receive frames yet. It
consists of the overload flag and an overload delimiter. There are three kinds of the Overload condition which
lead to the transmission of an Overload flag:
 • Where the internal conditions of the receiver are such that the receiver requires a delay of the
next Data frame or Remote the frame.
• On detection of a dominant bit during the INTERMISSION.
• If the CAN node samples a dominant bit at the eighth bit (i.e. the last bit) of an Error Delimiter or
Overload Delimiter, it will start transmitting an Overload frame (not an Error frame). The Error
Counters will not be incremented.

CAN Protocol Overload Frame Format

An Overload frame resulting from the Overload condition 1 is only allowed to start at the first-bit time of an
expected INTERMISSION, whereas Overload frames resulting from Overload conditions 2 and 3 starts one bit
after detecting the dominant bit.

Overload Flag in CAN Protocol Overload Frame

It consists of 6 dominant bits. The overload of the flag is structured the same way as the active-error flag of the
error frame. The Overload flag’s form destroys of the fixed form of the INTERMISSION field. As a consequence, all
other nodes also detect an Overload condition and each starts to transmit an Overload the flag. In the event that
there is a dominant bit detected during the third bit of the INTERMISSION, then it will interpret this bit as the
Start of a frame.

Overload Delimiter in CAN Protocol Overload Frame

It consists of 8 recessive bits. The overload delimiter is structured in the same way as the error delimiter of the
error frame. The Overload Delimiter is the same form as the Error Delimiter. After the transmission of an Overload
flag, the node monitors the bus until it detects a transition from a dominant to a recessive bit.

At this point of time, every bus node has finished sending its Overload flag, and all the nodes start transmission of
the seven more recessive bits in coincidence.

Inter-Frame Space In CAN Protocol

The IFS frame is used to separate the data frame and the remote frames. The data and the remote frames,
whichever the frame (data, remote, error, or overload frame) may have been transmitted prior to them, are
separated from the preceding frame by an inserted inter-frame space. However, no inter-frame spaces are
inserted preceding overload and error the frames.

CAN Protocol Working Principle

The CAN bus is an inexpensive, robust vehicle bus standard designed for multiple CAN device communications
with one another without a host computer connection. The CAN is also called a multi-master serial bus and the
CAN devices on the bus are referred to as nodes.
Two or more nodes are required on the CAN network to communicate. All nodes are connected to each other via
a two-wire bus (CAN H and CAN L) and the wires are 120 ohms nominal twisted pairs. Termination resistor
commonly 120 ohms is a must in each node in order to suppress the reflections as well as return the bus to its
recessive or idle state.

CAN Working principle

Each node in the CAN bus requires the below modules to work together in a CAN network.

Different Components of CAN Protocol Communication System

1. Microcontroller (Host): It decides what the received messages mean and what messages it wants
to transmit.
2. CAN controller: They are often an integral part of the microcontroller that handles framing, CRC,
etc. like the Data Frame, Remote Frame, Error Frame, Overload Frame, and Inter-Frame Space
generation.
3. CAN Transceiver: The CAN transceiver transforms data between the CAN controller and bus
levels. It converts data from the CAN controller to CAN bus levels and vice versa. In essence, the
CAN transceiver’s role is to convert Microcontroller TTL voltage levels (High/Low) into CAN Bus
protocol voltage levels (Recessive/Dominant) and vice versa.
Functions of Transceiver in CAN Bus communication

The transceiver drives or detects the dominant and recessive bits by the voltage difference between the CAN_H
and CAN_L lines. The nominal dominant differential voltage is between 1.5V to 3V and the recessive differential
voltage is always 0V.

The CAN transceiver actively drives to the logical 0 (dominant bits) voltage level and the logical 1 (recessive bits)
are passively returned to 0V by the termination resistor. The idle state will always be in the recessive level (logical
1).
Individually, CAN_H will always be driven towards supply voltage (VCC) and the CAN_L towards 0V when
transmitting to the dominant (0). But in a practical case, supply voltage (VCC) or 0V cannot be reached due to the
transceiver’s internal diode drop. CAN H/L will not be driven when transmitting a recessive (1) where the voltage
will be maintained at VCC/2.

The following figure depicts the block diagram and real-time capture of the CAN signals.

CAN have different physical layers which classify certain aspects of the CAN network such as signaling scheme,
cable impedance, maximum data rates, electrical levels, etc. The following are the most commonly used physical
layers.

How CAN Communication Works?

As mentioned early, CAN is a Peer-to-Peer network in which there is no master that controls the transmission
between nodes. When any CAN node is ready to transmit data, it should undergo a process called message
arbitration. In this process, the CAN node will check to see if the bus is idle and starts the transmission once it is
idle.

This will also trigger other CAN nodes in the bus and hence results in two or more nodes starting a message at
the same time which results in a conflict. The conflict is resolved in the following methods,

While transmitting data, the sender monitors the bus. If it detects a conflicting signal (logical 0), it fails in
arbitration, shifts to receiving mode, and relinquishes control. CAN frame arbitration occurs in the ID field,
ensuring the highest-priority node (lowest arbitration ID) successfully completes transmission.

Then the node which has won the arbitration will continue message transmission as if nothing had happened.
Other receiving nodes can decide if a message is relevant or if it should be filtered using a combination of
hardware and software filters. This process is continuous and other nodes will transmit their messages when the
bus has become available.

Operation of the CAN Network

• Each node is then assigned a unique identification number called the Physical Address of the ECU.
• All the nodes are interesting to transmit compete for the channel by transmitting a binary signal
based on their identification value.
• A node will drop out of the competition if it detects a dominant state while transmitting a passive
state.
• The node with the lowest identification value wins the bus network, initiating the message
transmission.
• If an error is detected by either the transmitter or receiver, it halts Data Frame transmission and
initiates the sending of an Error Frame. The error is having an error states to handle the error in
CAN Protocol called Error Handling in CAN Protocol. There are 5 types of error in CAN
protocol that can occur.