Automotive Communication Protocols: Preparing for the Future

Changing automotive networking protocols results in increased bandwidth on LIN and CAN networks.

Automotive communication protocols are changing rapidly as users and systems are demanding more information to be available in-vehicle.  This dramatically increases bandwidth requirements to support new functionality, interaction between modules, and “hungry” signals such as multimedia. In designing with this trend in mind, automotive engineers face time limitations of 100 seconds during end of line programming, demand for increasing vehicle network bandwidth and cost challenges. Using an analysis of the existing automotive networks available, the opportunities for protocol improvements and vehicle network analysis, this article will outline how engineers can address these challenges.

————–

Vehicle communications have been growing at a steady rate since the first Electronic Control Modules (ECMs) started to “think outside” of their own box and interact with other ECMs. For years, the radio was the only electronic device in vehicle, but starting with regulations implemented to reduce automobile emissions and followed by the growth of the semiconductor industry, electronics made their way into almost every facet of the vehicle. Within the last decade (Figure 1) protocols such as Local Interconnect Network (LIN) and CAN (Controller Area Network), have grown in popularity even as higher bandwidth protocols such as MOST (Media Oriented Systems Transport), FlexRay, and Ethernet have become accepted standards in automotive communications design.  Furthermore, it is expected that LIN and CAN networks will continue to dominate vehicle communication over the next decade.   This article will discuss changes in these protocols and how engineers can continue to use these protocols given the increased bandwidth requirements.

130313_auto_1
Figure 1: Exponential growth in in-vehicle network protocols is forecast as bandwidth demands have increased. (Source: Strategic Analytics.)

LIN and CAN are amongst the most popular protocols in-vehicle and have existed as standardized communication protocols for some time. LIN, which emerged in the mid 1990s, is single master, single wire 12 Volt and transfers data up to 20 Kbit/s.  CAN proliferated in the late 1990s as a multi- master, typically dual wire (at higher frequencies) 5 Volt and up to 500 Kbit/s. These two protocols’ success has ensured that their use will continue to increase well into the 2020’s.

Local Interconnect Network (LIN)
LIN is going to be used in a new way to become the link between the intelligent control module and the remote actuators/sensors.  In these systems, high-speed communication is not required and allows power to be placed (routed) directly at the actuator instead of routed through the ECM modules. This has the advantage to provide reduced vehicle weight and cost by having fewer wires between the control module and the actuator. Furthermore, through daisy chaining, several modules or smart actuators can be placed on a single LIN BUS.  This further reduces the amount of wiring through the vehicle while at the same time offering flexibility for wiring engineers.  Use of LIN in this way will require engineers to change the vehicle network in two ways; 1) the control modules will increase the number of LIN channels and 2) more 8/16-bit micros will be incorporated into actuators and sensor modules.

For the past two generations of automotive semiconductors, body control modules (BCM), which control internal/external lights, power window, power doors, air conditioning, immobilizer, central locking and of course communicate on the vehicle bus, have required at most 8 LIN channels, whereas requirements for the next generation are doubling.  Adding more LIN channels is not a major cost adder to the microprocessor since the peripheral is relatively small, but with the demand for decreased current consumption in lower power modes, parts of the chip are being powered off and potentially not all the LIN channels are going to be powered in the sleep modes.  Engineers have to decide whether to use the external interrupt for LIN, group the LIN slave devices that require wakeup functionality or physically tie LIN channels together in sleep modes. Solutions of this issue vary by microprocessor implementation and may require some additional time to create the best system solution.

The second network change is incorporation of small 8- or 16-bit microcontrollers into actuators and sensor modules.  The hardware cost impact to these modules is rather small, but a larger cost is becoming software development, implementation, test and verification.  As simple software to control an actuator or measure a sensor, software costs are increasing the cost of vehicles, and engineers must implement tools and processes to reduce the software costs.  Some automotive manufacturers are promoting the Automotive Open System Architecture (AUTOSAR), and many third parties are developing tools to simplify the learning curve before quality software is created.  This time around, simulation is made standard in automotive designs to reduce the software development time and create safer software.

Controller Area Network (CAN)
CAN will remain the main communication connection to pass data between modules, but with the growing need for more bandwidth, CAN is getting a makeover with protocol modifications to become CAN FD (CAN with Flexible Data Rate).  The CAN base frame is divided into two parts, the arbitration phase and the data transmission phase (Figure 2).  Two main improvements have been proposed for the data transmission phase: 1) increase maximum bit rate from 1 Mbit/s to 15 Mbit/s; and 2) increase payload from 8 bytes to 64 bytes. 

130313_auto_2
Figure 2: A suggested CAN base frame improvement involves increasing maximum bit rate and increasing payload in data transmission phase. (Source: Bosch Semiconductors Spec Sheet¹ )

Bit rate
CAN’s new name comes from the data transmission phase’s new flexibility.  The arbitration phase of CAN FD messages is not modified, so it can run on CAN transceivers and cables currently used in-vehicle but the bit rate of the data transmission phase is increased.  Although the data transmission phase bit rate in-vehicle implementation may not be used at the maximum 15 Mbit/s, plenty of bus time can be freed up with only 2 Mbit/s as shown in the example use cases in Figure 3.

130313_auto_3
Figure 3: Eight bytes with faster data rate only takes half the time whereas combining four CAN messages into one CAN FD message (8 by 4 for 32 bytes) and the increased data rate is reduced to less than a quarter the time. (Source: Renesas Electronics America Inc.)

Payload
Increasing the data transmission phase from 8 bytes to 64 bytes obviously allows more information to be sent with only a few more header and footer bits.  The bandwidth improvements increase the standard CAN 2.0 bus efficiency from the max of 58% (standard ID and 8 data bytes) to CAN FD’s efficiency of 90% (standard ID and 64 data bytes). 

Architecture implementations
Programming is the easiest place for engineers to quickly take advantage of CAN FD’s improvements since faster production line flash programming time equals dollars in savings.  Data can be sent from a programming tool to the main gateway module using 64 byte payload and a faster data transmission phase can be relatively easy to implement and get a return for the investment.  Normal network message use of CAN FD will require more effort where changing CAN network message IDs and packets may take a little longer with the tear-up to the CAN message architecture. 

Getting concurrent data over the CAN bus is one particular network message change that will make the most sense.  For example, wheel speed sensor information can be grouped into a single CAN FD message instead of sent in four CAN messages. 

The North America market trend appears to be adopting CAN FD with GM publically committing and planning to be the first to use CAN FD to speed up factory programming in 2017. “Two or three years later GM plans to begin using CAN FD for communications between ECUs”.²  Some groups are conservative with concerns GM will be able to achieve this goal, but if GM implements per schedule, many OEMs may quickly follow their lead.

Summary:
Examining two of the existing automotive networks, the opportunities for protocol improvements and the vehicle networks themselves, we have seen how engineers can effect these changes that make possible some key automotive improvements like better fuel efficiency and safer vehicles.

¹http://www.bosch-semiconductors.de/media/pdf_1/canliteratur/can_fd_spec.pdf

²The Hanson Report on Automotive Electronics; Vol. 25, No. 10

 


miller_gary

Gary Miller has 16 years of experience working on embedded systems, five of which he has spent at Renesas Electronics America in various positions. He is currently in Technical Marketing in the automotive business unit, where he is responsible for the development of Renesas products in addressing the needs of automotive (and other) customers, and for providing in-depth expert support for both the products and the solutions developed based on those products, including the development of presentations, application notes, training material, contributed articles and other associated technical collateral. Gary holds two patents for inventions used in automotive electronics, and has a Bachelor of Science in Electrical Engineering from the University of Michigan.

 

Share and Enjoy:
  • Facebook
  • Google
  • TwitThis