Modern automobiles comprise anywhere between a few tens of Electronic Control Units (ECUs) to upwards of one hundred ECUs. These dedicated computing units are powerful devices by themselves, designed to handle specific functionalities. While many of their operations are independent, some have tight coupling — such as the BMS and the MCU. Units like IPU (Instrument Panel Unit) or ECU (Engine Control Unit) need to know the status of all ECUs in the system to help make informed decisions.
This data has to be communicated quickly, without any latency or errors, for seamless operation of the automobile. CAN bus is used for this data communication and a network of this complexity needs to be defined clearly. It calls for a protocol agreeable to all participating nodes. Since these ECUs come from different vendors, a common definition and communication mechanism is required — the Automotive CAN IVN Protocol. In this comprehensive guide, we will explore the various aspects of the Automotive CAN IVN Protocol, from its functionalities to its limitations, including the automotive CAN IVN stack and DBC file. Our digital transformation services help OEMs standardize and scale their in vehicle network implementations.
The Automotive CAN IVN Protocol, also known as the Inter Vehicle Network Protocol, is a communication protocol that enables different electronic control units (ECUs) within a vehicle to exchange information. It is the backbone of the in-vehicle network and facilitates seamless communication between various components such as sensors, actuators, and modules.
While the Automotive CAN IVN Protocol defines the format of data being transferred, the OEMs are open to specify the information coming out of each ECU.
The typical automotive CAN network is depicted below with multiple ECUs connected.
All these ECUs generate a vast amount of data that is to be known by their peers. One aspect of this is that there is not much two-way point-to-point communication but more of broadcasting. For example, it is mostly sufficient for the Instrument Cluster to receive information from other units. Even if the user performs an operation such as setting the drive mode, it is essentially a one-way request to the VCU/ECU. The VCU/ECU selects the most suitable mode based on factors such as current battery levels and communicates the selected mode. Thus, both these packets can be broadcasts.
As can be seen, the in vehicle network protocol mostly broadcasts information with clearly defined structure.
The data to be exchanged in an automotive in vehicle network is defined using a simple text file format called the DBC file. The DBC (Database Container) file serves as a dictionary that defines the structure and content of the data transmitted over the network. The DBC file contains information about the messages, signals, and other parameters necessary for decoding and encoding the data.
By using the Automotive CAN DBC File, engineers and developers can easily interpret the data exchanged between different ECUs. It provides a standardized format that ensures compatibility and interoperability across different vehicle platforms and manufacturers.
In the context of the Automotive CAN IVN Protocol, messages refer to the packets of data transmitted between different ECUs on the in vehicle network. These messages contain information about a specific event or command, such as the status of a sensor or an instruction to activate a particular component.
Messages in the Automotive CAN IVN Protocol are typically structured using the CAN (Controller Area Network) protocol. The CAN protocol defines the rules for message transmission, including the originator, message length, and the format of the data. This ensures reliable and efficient communication between ECUs, even in high-speed and high-load scenarios.
Signals are the building blocks of the data transmitted over the Automotive CAN IVN Protocol. They represent a specific parameter or measurement, such as the vehicle speed, engine RPM, or the state of a switch. Signals are encapsulated within messages and are used to convey information between different ECUs.
Signals in the Automotive CAN IVN Protocol are defined using a specific data format, such as binary, integer, or floating-point. They also have attributes such as scaling factors and offsets, which allow for accurate representation and interpretation of the measured values.
While the DBC file is itself simple, it is essential to configure the respective ECUs to properly handle the outgoing and incoming data packets. One of the key considerations is the selection of suitable hardware and software components that can efficiently handle the data transmission and processing requirements. This includes choosing the right microcontrollers, transceivers, and communication stacks.
With respect to the transmitted data, it is fairly simple that it has to be transmitted at defined intervals (cyclic or event with cyclic etc.). But the timing has to be strictly followed, without which the bus may be overloaded (in cases of faster transmission) or the receiving party times out (when slower).
Implementing the Automotive CAN IVN Protocol receiver requires careful consideration with a tight coupling of underlying hardware. As the number of messages in a vehicle can run into a few hundreds easily, it is practically impossible to receive all these messages and process them. Most of them may not be required for a given ECU. In this case, the CAN receive filter configuration has to be leveraged by setting up mailboxes based on periodicity. Multiple messages can be received by the same CAN mailbox using the Mask features of the CAN peripheral. The software can then use algorithms to route the messages to respective handlers.
Effective CAN programming is foundational to a well-functioning in vehicle network. CAN programming covers peripheral initialization, mailbox configuration, interrupt-driven reception, and cyclic transmission scheduling. On modern MCUs, CAN programming also involves configuring CAN-FD (Flexible Data-rate) modes to support higher data rates for bandwidth-intensive payloads. Robust CAN programming ensures the automotive CAN IVN protocol runs reliably even under peak bus loads.
CAN FD integration in automotive systems extends classic CAN to support data rates up to 8 Mbps and payload sizes up to 64 bytes per frame, addressing the bandwidth demands of next-generation in vehicle network designs. CAN FD integration in automotive systems is especially critical for domains such as ADAS, battery management, and high-throughput diagnostics where classic CAN's 8-byte limit is a bottleneck. OEMs adopting CAN FD must update their DBC-based automotive CAN IVN stack to handle both classic and FD frame types in the same network. Learn more in our automotive electronics overview.
While the Automotive CAN IVN Protocol offers numerous benefits, it is not without its limitations. One key limitation is the limited bandwidth available for data transmission due to the inherent CAN protocol. As the number of ECUs and the complexity of the data increase, the available bandwidth may become a bottleneck, leading to potential delays or performance issues.
Another limitation of the Automotive CAN IVN Protocol is the lack of built-in security features. The protocol primarily focuses on efficient data transmission and does not provide robust security mechanisms. This makes vehicles vulnerable to potential cyber-attacks, highlighting the need for additional security measures to protect the integrity and confidentiality of the data.
At Embien, we specialize in providing comprehensive services for the implementation and integration of the Automotive CAN IVN Protocol. Our team of experienced engineers and developers are well-versed in the intricacies of the automotive CAN IVN stack and can assist you in designing and developing robust and efficient in vehicle network solutions. We offer our RAPIDSEA automotive CAN IVN stack that is proven to handle even the most rigorous loads and environments.
Whether you need assistance with DBC file creation, message and signal definition, CAN programming, or overall network design, we have the expertise and resources to meet your requirements. Our automotive CAN IVN stack supports both classic CAN and CAN FD integration in automotive systems, making it ready for next-generation vehicle platforms. Services are tailored to your specific needs, ensuring a customized solution that aligns with your business goals.
The Automotive CAN IVN Protocol is a powerful communication protocol that plays a vital role in the modern automotive industry. Its features enable seamless communication between different ECUs on the in vehicle network, facilitating the integration of advanced technologies and enhancing the overall performance and functionality of vehicles. The entire communication in the vehicle can be defined using the Automotive CAN DBC File, and deployed efficiently through a well-designed automotive CAN IVN stack. While the protocol has its limitations, it continues to meet the ever-changing demands of the industry. With CAN FD integration in automotive systems, the Automotive CAN IVN Protocol will remain the preferred communication standard on the CAN bus for many years to come.
Embien's edge computing services support real-time in-vehicle network processing, enabling low-latency automotive CAN IVN protocol communication across connected ECUs.
From DBC file definition to CAN IVN stack integration, Embien's connected vehicle development services bring reliable in-vehicle network communication to production vehicles.
A complete connected vehicle solution featuring automotive CAN IVN protocol integration for a telematics control unit in a two-wheeler embedded system.