Open access

Automotive Networks Based Intra-Vehicular Communication Applications

Written By

Preeti Bajaj and Milind Khanapurkar

Submitted: 08 December 2011 Published: 01 August 2012

DOI: 10.5772/45792

From the Edited Volume

New Advances in Vehicular Technology and Automotive Engineering

Edited by Joao Paulo Carmo and Joao Eduardo Ribeiro

Chapter metrics overview

4,211 Chapter Downloads

View Full Metrics

1. Introduction

Intelligent Transportation System (ITS) includes eight wide areas of applications such as Advanced Traffic Information System, Advanced Traffic Management Systems, Automatic Vehicle Control System, Commercial Vehicle Operations, Advanced Public Transport Systems, Emergency, Infotainment Expectations, and Comfort to Drivers and Passengers, Safety, Electronic Payments etc. Safety, Mobility, Comfort are the three basic reasons for increasing the involvement of electronics in vehicles and in turn in Intelligent Transportation system.

Vehicular communication promises traffic management, efficient and easier maintenance, more fun and infotainment which ultimately lead to safer roads, enhanced comfort for driver and passengers (Safe Transportation). Categorically the Vehicular Communication can be classified as

  • Vehicle to Infrastructure (V2I) and Infrastructure to Vehicle (I2V)

In highway engineering, improving the safety of a roadway can enhance overall efficiency. Vehicle-Infrastructure communication targets improvements in both safety and efficiency. It is wireless communication catered by Vehicular Ad-Hoc Networks, which provides communication between vehicles and nearby fixed equipments, usually described as roadside equipments or infrastructure.

  • Inter-vehicular (V2V)

Inter Vehicle communication is governed by wireless communication and is catered by Mobile Ad-hoc Networks (MANETS) and Vehicular Ad-hoc Networks (VANETS). A Vehicular Ad-Hoc Network, or VANET, is a form of Mobile ad-hoc network, to provide communications among nearby vehicles.

  • Intra-Vehicular

Intra-vehicular communication describes as exchange of data within the ECUs of the vehicle, which are involved in vehicular applications. Major intra-vehicular communication is of wired type i.e. network based. There are some applications wherein wireless Intra-vehicular communication is accounted.


2. Automotive networks

One can visualize the complexities involved and the progressive advancements with around 8-10 ECUs in vehicle in early 90’s through around 50 microcontrollers at the beginning of this decade i.e. 2000, Today, in high-end cars, it is common to have around 100 ECUs exchanging up to 2500 signals between them. Automotive networks Eliminates Unwieldy Wiring Harnesses, Increases Vehicle Safety and Reliability, Future expansion easily possible, Uniformity and Standardization in operations, Fast, Reliable and Efficient Inter-communication, Organizes the information stream, Assurance of faithful communication. Some of the Automotive Network Controllers are

  • Local Interconnect Network (LIN)

The Local Interconnect network (LIN) is a serial communication protocol suited for networking sensors, actuators, and other nodes in real-time systems. It is 12 V Single wire, Universal asynchronous receiver-transmitter (UART), Single-Master, Multiple-Slave (up to 16 nodes), Up to 20kBits/s data rate automotive network protocol. LIN Bus Application Examples:

  • Steering Wheel: Cruise control, Wiper, Turning light, Climate Control

  • Seat: Seat Position Motors, Occupant Sensors, Seat Control Switch

  • Door: Mirror Switch, Central ECU, Power Window Lift, Door Lock

  • Safety and Investigation: Automotive Black Box.

  • Controller Area Network (CAN)

The CAN bus is used in vehicles to connect engine control unit and transmission, or to connect the door locks, climate control, seat control, etc. It is Asynchronous Multi-master communication protocol serial bus having data rate of up to 1 Mbps. CAN Bus Application Examples:

  • Safety Power Train: Electronic Parking Brake, Vacuum Leak Detection Automotive Black Box

  • Chassis: Watchdog, Motor Control, Electronic Throttle Control Body Control: Low-end body controller (Lighting, Network Communication) Power Door, Power Sunroof, Power Lift Gate

  • Flex-Ray network

Flex-ray networking standards work on the principle of TDMA and have Dual-channel Architecture. It has Host processor which controls the communication process via communication controller and bus driver. Each flex ray node has two physical channels A and B facilitating data rate of up to 10 Mbps through per channel. It can be employed as network backbone with CAN and LIN. Flex-Ray Network Bus Application Examples:

  • Data Backbone: for other buses (LIN, CAN, and MOST)

  • Safety-critical Applications: X- by- wire, Automotive Black Box

  • Distributed control system Applications: Power Train Applications,

  • Châssis applications requiring computations across various ECUs

  • Media oriented system transport (MOST)

MOST is a high-speed multimedia network technology usually includes up to 64 MOST devices having plug n play operations. MOST can operate up to 15 uncompressed stereo audio channels or up to 15 MPEG1 channels for audio-video communication.


3. Steps to design intra-vehicular communication applications

  • Depending upon the type of Intra-Vehicular Communication Applications network controller & host processor is to be decided.

  • The intra-vehicular communication application can be homogenous automotive controller based or it can be of heterogeneous type

  • Design and modification (after testing iterations) of interface Design prototype model (with suitable modeling tool / language like VHDL, LABVIEW, and MATLAB etc) of network controllers.

  • Downloading the prototype file created with design tool in to suitable programmable platform (like FPGA, CPLD etc) and result Validation.

  • Interfacing with electromechanical systems for simulation of real time data from sensors, actuators & experimenting for actions.

  • Installation and Commissioning

  • Testing the designed system in real time environment.


4. Intra-vehicular communication applications

In accordance with the steps mentioned above some of the intra vehicular communication applications governed categorically by various automotive controllers are listed as follows. LIN specifications implies that a LIN network can have single master and multiple (up to 16) Slaves. Figure 1 shows RTL view of LIN controller implemented on modelsim tool.

4.1. Master-slave local interconnect network for intra vehicular communication application

Figure 2 shows RTL view of the three node LIN network along with FSM and other components. The three transceivers are connected with the TXD and RXD of the respective three controllers. The transceivers have lin_bus signal forming LIN bus. The three lin_ bus signals are interconnected together to form a single wire LIN bus.

Figure 1.

Modelsim RTL view of LIN Controller

Figure 2.

RTL view of the three node Local Interconnect Network

FPGA implemented three node Local interconnect network is used for sensing the steering wheel angle and controlling two dependent vehicle parameters viz: changing the angle of front light for better illumination and vision and also informing the driver safe speed limit on dash board. Figure 3 shows the implementation using FPGA DE1 board of ALTERA. The data transfer is displayed on display of DE1 board which has LED indication for indicating active slave node and the data along with id and masking bits are displayed on four seven segment displays.

Figure 3.

Id transfer and Data Transfer for slave 1 and slave 2 from master node

4.2. CAN for intra vehicular communication (black box) application

The design methodology for black box application using FPGA hosted CAN controller is shown in figure 4. The digital signal thus derived from output of ADC is given as input to CAN host FPGA which holds Data frame and directs it to Black box Memory. The black box will store the frame and will make available as and when required.

Figure 4.

Block Diagram of Design Methodology

4.2.1. RTL – Schematic view of CAN host based black box

Prototype CAN is incorporated in designed Black Box application. Figure 5 shows the block diagram, schematic view of CAN controller used in FPGA based design of Black Box. The inputs and outputs are as explained above for RTL view and in addition to that Figure 5 also shows the details of schematic view of Data, Identifier, DLC, etc which constitute CAN frame. Input to system is output of ADC which is simulated signal of emergency situation in vehicle and the output is CAN Data frame containing data of parameter which gets stored in memory for revival and further referral analysis. The other inputs are clk (clock), rst (Reset) and tx_ctrl (transmission control).

The data frame that is to be transmitted by the CAN-Host will consist of the following fields: Identifier field, control field, data field and CRC field. The emergency situation in Vehicle i.e. output of sensor element from the Engine of a car can be simulated using ADC converter in which the Analog input is varied by potentiometer or the same can be simulated by operating DIP switches on XILINX FPGA Board. Then according to the input from the sensor the output of the ADC is needed to be interpreted or calibrated. This digital signal is given as input to CAN host FPGA which is employed to operate specific application in the vehicle. The instantaneous CAN Frame of that particular application is hold of and is stored in memory of intelligent vehicle black box.

The proposed design of black box as shown in figure 6 will record and store the multiple vehicle parameters through different automotive controllers and their networks hosting on different FPGAs. The diagram shows the black box memory and data retrieval system to retrieve data stored in system memory.

Figure 5.

Block Diagram and Schematic View of CAN host FPGA based Black Box

Figure 6.

Multi Network Controller based proposed design of black box for multi-parameters

4.3. Flex-Ray protocol for intra vehicular communication application

Virtual Flex-Ray environment is implemented for intra-vehicular communication applications using Flex Ray Protocol using LAB-VIEW. The design of various intra-vehicular applications for Driver and Passenger Doors, AC Control, Oil Temperature Control and External Weather sensing and controlling the activities inside vehicle has been implemented using flex-Ray utilities of LABVIEW platform. The algorithmic sequence of operation is as follows:

  • Status of input is pre-setted as true and false for respective vehicle parameter thus tool forms flex-Ray frame for both the conditions of particular vehicle parameter.

  • The parameter status is chosen as true or false which goes as input to module designed.

  • Module passes the parameter to evaluator and decides output controller action.

  • The output is the action taken by flex-Ray controller is displayed along with flexRay output graphic frame.

Figure 7, Figure 8, Figure 9 and Figure 10 shows the designed modules for intra-vehicular communication applications like four doors, AC, Oil Temperature and Weather Conditions.

Figure 7.

Door Module

Figure 8.

Air Conditioner Module.

Figure 9.

Oil Temperature Module

Figure 10.

Weather Condition Module

Figure 11 shows design for External weather sensing module. With external weather condition input as rainy to module, the module evaluates the condition and provides the flex-Ray frame for weather condition as true and the output action is taken to turn on the wiper.

Figure 11.

External Weather Sensing Module (input as rainy weather condition)

Figure 12 shows External weather sensing module with external weather condition input as hot, the module evaluates the condition and provides the flex-Ray frame for weather condition as false and the output action is taken to turn on the AC.

Figure 12.

External Weather Sensing Module (input as hot weather condition)

Figure 13 shows results of the designed applications with the possible input conditions and explains the remedial controlling action taken by flex-ray controller on LABVIEW simulation platform.

Figure 13.

Results for vehicle parameters for Flex-Ray based Design

4.4. SDSCS – AFS Interfacing: Intra-vehicular communication application

The most Versatile Intra-vehicular Communication Application using Automotive Network Controller is Automotive Black-Box. The design approach and implementation of automotive black box is described and discussed below. Automotive Black box is referred to storing of vehicle data at the time of accident and retrieving same for investigation purpose. The main problem while designing of Black Box is deciding the incidence at which vehicle met with accident. The Figure 14 shows the block diagram of prototype of System for Detecting Sudden Change in Speed (hence accident instance) (SDSCS) of Vehicle for Accident simulation and its interfacing to Adaptive Front Light System (AFS).

Figure 14.

Block Diagram of prototype of SDSCS – AFS Interfacing

Figure 15 shows the details of hardware of the developed prototype. The assembly provides the mechanism for simulation of vehicle speed in form of motor coupled with regulator and breaking –accelerator facility as shown in figure. This motor is in close vicinity of proximity sensor which senses the speed and the same is coupled to controller which calculates the difference at smallest possible interval, thus simulating the accident situation in the vehicle.

AFS- Adaptive Front Lighting System, the name suggests that it is front lighting system of an automobile which will adapt itself according to the need of the curvature of the road.

Once the instance of sudden change in speed of vehicle (instance of accident) is confirmed then the information regarding various activities of vehicle (Vehicle Parameters) can be passed on through automotive controller based system which will take care of recording and storing the vehicle parameters. Intra-Vehicular communication is established between AFS - SDSCS. The real time steering angle and the real time position of the front lights is available in electrical signal form in AFS. These two real-time output parameters are supplied as real-time inputs to System for Detecting Sudden Change in Speed of Vehicle for accident simulation (SDSCS) for storing purpose.

Figure 15.

AFS-SDSCS Interfacing

To make the simultaneous movement of the front light in the horizontal plane according to the movement of steering shaft, it needs some range on the movement of the front light. Mainly, the lights should turn to some specific angle and then it should stop moving. As the vehicle takes the steep turn on a road, the direction of the front light should move, if it takes more sharp turn, the front light should rotate deeper in the same direction as that of the steering movement. If in case, the vehicle takes a sudden ‘U’ turn, the lights should not move directly in the opposite direction, but should be at the extreme of the specified direction.

When steering angle 1300 the direction of the light system is in the front position as if the vehicle is moving in a straight direction. If Vehicle moves slightly towards the right direction on the curve, the lights system will also move directly from 1300 to 1350. If the vehicle takes sharper turn towards the right, let’s say from 1350 to 1450, the lights will also move in the same direction (extreme right). When the vehicle continues to moves on straight track, the lights will also move in opposite direction from 1450 to 1350 and from 1350 to 1300.

Range of steering Angle / VariablesX1X2X3X4
1250 < _ < 13500000
1350 < _ < 14500010
1450 < _0011
1350 < _ < 14500010
1250 < _ < 13500000

Table 1.

Right Movement of AFS

The same logic has been applied for the left direction movement of the lights system. If the car slightly turns towards the left direction, the light slightly towards the left direction i.e. from 1300 to 1250. if the vehicle takes sharper turn towards the left, accordingly the lights will also move deeper i.e. from 1250 to 1150 and if again it moves to the straight direction from the extreme left, it will also make the simultaneous movements from 1150 to 1250 and from 1250 to 1300

Range of steering Angle / VariablesX1X2X3X4
1150 < _ < 12501000
_ < 11501100
1150 < _ < 12501000
1250< _ < 1350000
1150 < _ < 12501000

Table 2.

Left Movement of AFS

  • Movement of Front Lights in AFS for different steering positions

  • CASE I: Figure 16 shows position of steering angle is in between 1250 to 1350 there will no inclination of lights, the light will be in the neutral direction and the direction of light will be in the front direction.

Figure 16.

AFS (Case I)

  • CASE II: Figure 17 shows the light position for right turn. If the vehicle takes right turn and the steering angle is in range of 135 to 145 then the AFS makes lights to move in right.

Figure 17.

AFS (Case II)

  • CASE III: If the steering angle goes beyond 145 degrees for sharper right turns, Figure 18 shows the logic generated for AFS and the lights will be moved in rightmost.

Figure 18.

AFS (Case III)

  • CASE IV: Case III is the rightmost position for lightening system and the lights will again turn back to its original condition, similarly the rotations will take place in the left direction and the same condition will be achieved as in figure 19.

Figure 19.

AFS (Case IV)

  • CASE V: The lights will come back to centre position as in Figure 20.

Figure 20.

AFS (Case V)

  • CASE VI: If the steering moves in the left direction AFS will move the light towards the left direction, the logic will change as shown in figure 21.

Figure 21.

AFS (Case VI)

  • CASE VII: Figure 22 shows the left most condition and the vehicle lights will be moved towards extreme left direction.

Figure 22.

AFS (Case VII)

  • CASE VIII : Above mentioned was for left most direction now similarly the rotations will take place in the back to the right direction and the same condition will be achieved as it was achieved earlier as in figure 23

Figure 23.


  • CASE IX: The logic will change to shift the lights to bring them to straight position as shown in figure 24.

Figure 24.

AFS (Case IX)

Following result windows shows the real time clock for data recording, the set threshold value for deciding the change of sudden change of speed. It also shows the condition of locking. Through menu driven the value of threshold can be altered, re-setted and brakes can be applied for Electro-Mechanical assembly (as explained above). Every time the back history of the data is also recorded. This back history (pre-accident history) can be helpful for post accident analysis.

The parameters recorded and displayed are off line or virtual (i.e. programmable) are status of Wiper, Doors, Air Bags, Seat Belts, Fog Lamps, Side Indicator, Head Lights. In addition to these virtual programmable parameters two real time parameters are also recorded. These parameters are derived from Adaptive Front Light System (AFS) i.e. Range of Steering Angle and The positions of Head lights at the time of data recording. Figure 25 shows data non blocked state of the system.

Figure 25.

AFS-SDSCS Data not Locked

Figure 26.

Figure 27.

AFS-SDSCS Data Locked and Recorded

Figure 26 shows the blocking state of the system wherein the data is recorded for sudden change of speed that may lead for the unfortunate incident i.e. accident with the vehicle for three sets of virtual and real time parameters.


5. Conclusions

The chapter explains various intra-vehicular communication applications implemented through vehicular network controllers such as LIN, CAN, Flex-ray on tools like Modelsim, Xilinx, and Lab View and also some applications are implemented by hardware designing and development. The Applications such as black box, various parameters sensing and controlling respective corresponding actions are implemented and are presented in the chapter. Designed application systems are developed on simulation tools and also prototype is implemented and tested successfully with satisfactory results.


  1. 1. Multiplexed Networks for Embedded Systems CAN, LIN, FlexRay and Safe-by-Wire.Copyright 2007John Wiley & Sons Ltd.
  2. 2. FlexRay Communications System- Bus Guardian Specification, v2.0, FlexRay Consortium,June 2004
  3. 3. LIN Specification Package- revision0
  4. 4. CAN Specification, BOSCHGmbE 1991
  5. 5. FlexRay Communications System- Electrical Physical Layer Specification, v2.0, FlexRay Consortium, June2004
  6. 6. Publications by Automotive Network Controllers Consortiums

Written By

Preeti Bajaj and Milind Khanapurkar

Submitted: 08 December 2011 Published: 01 August 2012