Automotive Communication Protocols

This article gives a detailed introduction to automotive communication protocols for vehicles. It will illustrate the basics of communications in automotive systems and inform you about the types of language protocols available at this point. You’ll learn how protocols are selected for any new feature and read a case study elucidating that. 

Following those, you’ll learn about current trends in automotive communication, the state-of-the-art in-vehicle communication, and get a view of what the leading Protocol Stack companies are. 

Subsequently, this article will inform you of the career paths and job roles in the automotive communication protocol domain. If you are currently pursuing your Undergraduate or Post Graduate in Electrical, Electronics or Instrumentation engineering, then one of these could be a path or role for you.

 

Why is communication needed in automotive systems?

In the old days, automotive systems were concentrated on a few nodes. Now, they’re continuously evolving. 45 to 70 or 80 subsystems can exist in a car carrying out multiple functionalities. Communication between all these subsystems (for example ADAs, or telematics units) is essential for the overall implementation of the vehicle’s features. 

Right from vehicle startup till the driver leaves the car, all the subsystems continuously transmit their status to, as well as receive data from, other subsystems necessary to perform a task. This is what enables, for example, the hazard lights on the dashboard lighting up when a door is not properly closed.

 

What are the different communication protocols available at this time?

The different protocols available can broadly be categorized into 3 types:

 

• Datalink protocols: Datalink protocols take care of the physical layer implementation.  UART (serial port communication protocol), SPI (serial peripheral interface), I2C, LIN (Local Interconnect Network), CAN (Control Area Network, 90% of all vehicles use CAN for their communication), Flex-Ray and Ethernet. (which are used for higher bandwidth communication, used primarily in relationship with surround sound systems and dashcams)

 

• Application protocols: They use datalink protocols as the underlying layer. UDS (used for diagnostics, uses CAN as the data link), J1939, CAN-Open, MOST(used for media-related communication, used over CAN)

 

• Other protocols: Bluetooth, Wi-Fi, USB, 4G/5G (Vehicle2Network - V2X)

 

How does one select a protocol for a new feature? 

• Maximum ‘payload’ size: ‘Payload’ is the volume of data we want to transfer from one node to another node. Based on this, we have to pick an appropriate protocol. Therefore, the volume of data plays a key role.

• Bandwidth of the network: The bandwidth of the network is the maximum available speed for data transmission. We need to see at what speeds we want to transport the data.

• Maximum bus length supported: This is important mainly to resolve challenges related to wiring. For example, in terms of wiring, the distance between the rear-view camera and the parking assist system would need to be kept in mind.

• Network architecture: This would address the options we had of having multiple masters/slaves within the same protocol.

• Transfer Mode: This would determine whether the communication sending protocol is full-duplex (both the sender and the receiver can communicate simultaneously) or half-duplex (only one of either sender or receiver can communicate at a time), Simplex (only one node will be sending and the other node will be receiving). Another parameter that plays into the transfer rate is synchronous (a timestamp is sent along with the data to synchronize the data transmission) or asynchronous (data is sent with packets containing address Id where it will be sequenced sliced at the receiving node.)

• Fault tolerance: This answers the question of how sure we are that the data being sent by the sender is received by the receiving node accurately. Different protocols have different error-correcting mechanism.  

• Suitability for safety: More or less an add-on feature, nevertheless critical if we want to ensure that all the data is being received, where every frame of data is acknowledged being sent back by the receiver. 

• How easy it is to add or remove a node from a vehicle network: For example, with CAN one could do it with two lines, but many other protocols would require hardware changes.

 

Can you give me a concrete example to demonstrate how this stuff works?

To take an example, consider the case study of reverse parking. The moment the car is put in reverse, the rear-view camera will be activated and the camera module will start recording data. The camera module is connected to Park Assist ECU using Ethernet. Now, Park Assist provides the live video feed over Ethernet to Infotainment or Instrument Cluster for displaying to the driver. As part of this, it also provides an overlay to the live feed: “We are ten minutes away from crashing into the curb” or some such. 

Ethernet is chosen because a huge amount of data shall be sent continuously.

The network design has to be chosen with respect to the network packaging, how we want to send the data.

 

What are the current trends in automotive communication?

Traditional ECUs continue to use CAN, either 2A or 2B networks, using an 11 bit or a 29-bit identifier. Depending on whether one needs low speed (125 kbps) for normal networks or high speeds (500 kbps or 1 Mbps) for critical features. The two can coexist, and are interconnected using CAN gateways for exchange. LIN is used for less critical communication. CAN-LIN gateways are used for data exchange between CAN and LIN subnetworks. Nowadays one has CAN-FD, CAN-Flexible-Datarate, which has data speed up to 5 Mbps, or Flex-Ray which has data speed of up to 10 Mbps. The very latest applications like ADAS, Telematics Units use Ethernet or Wireless (4G or 5G) based communication because they have specific payload/bandwidth demands.

 

What is the state-of-the-art in-vehicle communication?

The following schematic renders an at-a-glance look at the state-of-the-art in-vehicle communication:

 

Figure 1.1: The state-of-the-art in-vehicle communication

 

What are the leading Protocol Stack companies?

The leading Protocol Stack companies are:

• Tier 1 firms-suppliers: These companies are responsible for implementing and testing a new product or feature for the complete product life cycle, manufacturing, and any service-related issues. Overall, they are responsible for the complete life cycle of the ECU. They include:

• Nippon Seikel

• Continental

• Magneti Marelli

• Visteon

• Aptiv

• Calsonic Kansei

• Pricol

• Robert Bosch

• Yazaki

• Harman

• Tier 2 firms-service providers: These companies act as technology service providers to the Tier 1 firms. They pitch in projects and implement a new feature, and deliver it as a service to the Tier 1 firms. The Tier 1 firms then take that deliverable and integrate or implement it and take that as part of the overall production. All the prominent names are based in India. These companies include:

• L&T Technology Services

• HCL Technologies

• Tata Elxsi

• Tier 3 firms-tool-chain providers: These companies deal with protocol implementation, and provide software packages. They include:

• Autosar

• Vector Informatik

• Electrobit

 

What are the career paths available to an engineer in the automotive communication protocol domain?

There are multiple career paths available to an engineer in the automotive communication protocol domain. They could be grouped under four broad categories:

• Software development: Such career paths include device driver development, boot loader, boot support package assister, board bring-up engineer, or operators helping with flashing protocol and flashing tools.
  Interested?
  Check out our software development courses

• Software testing: Testing is required for CAN protocols (in diverse subtypes such as CAPL scripting, CANalyzer, CANoe, CANOe.DiVa, VTEST Studio), and to be a software tester is the career path that deals with this work. One could also be protocol monitors for other protocols, or else engage with JTAG Debugging.

• Test Automation: CAPL scripting requires Python, C#, Excel Automation, XML Automation, Test Bench/Framework. 

• Network Design: These consist of vehicle features understandings, design messages, signals and data packaging. Check out our Mechanical Hybrid design Post Graduate Programme

 

What are the Job roles available in the automotive communication protocol domain?

As in most domains, job roles in the automotive communication protocol domain are segmented into entry-level roles, senior-level roles, and management level roles.

• Entry-level roles: These consist of Device Driver Software Engineer, Protocol Stack Developer, Protocol Stack Test Engineer, Board Support Package Developer, Board Bring-up Engineer, Bootloader Developer, or Flash Protocol Developer.

• Senior-level roles: These consist of software integrator, team leader, technical leader, solution architect, protocol stack development/test lead, project leader, BSP/Board bring-up lead, bootloader architect, flashing expert, onsite coordinator.

• Management level roles: These consist of a project manager, delivery manager, program manager, and account manager. If you find the prospect of ultimately ending up at one of these management level roles interesting, you really should check out all our courses.

 

Check out List of Job opportunities for your Engineering Domain