Network Topologies For In Vehicle Communication Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Abstract-Today's vehicles contain hundreds of circuits, sensors and around 80-120 Electronic Control Units(ECUs). Communication is needed among many circuits and functions of a vehicle. In earlier vehicle systems, this type of communication is handled via a dedicated wire through point-to-point connections. If all possible combinations of switches, sensors, ECUs and other electronic devices in fully featured vehicles are accumulated, the resulting number of connections and dedicated wiring is enormous. In-vehicle networking provides a more efficient method for today's complex in-vehicle communications. In this paper, we compare the performance of ring and star network topologies on the basis of bus load.


Today's premium cars contain more than ten distributed audio and video ECUs such as visual sensors driver assistance cameras, DVD player, DVB-T, and audio sources such as FM- and HD-radio systems. These in-vehicle devices are currently interconnected by different automotive specific network technologies such as Media Oriented System Transport (MOST), Controller Area Network (CAN), and Local Interconnect Network (LIN) [1] that provide limited transmission capacities. Point-to-point links realized by analogue color video blanking signal (CVBS) cables and low-voltage differential signaling (LVDS) wires are additionally used to transmit real-time video streams from driver assistance camera systems. The application of different network technologies and point-to-point links leads to an inflexible network architecture and a complex cable harness in the car which is expensive and requires a high validation and management effort. Due to the growing demand for new applications in the driver assistance and multimedia fields, the in-vehicle network will become even more complex and costly in the near future. Thus, traditional automotive network technologies are no longer suitable [1].

Network systems in vehicles represent very high complex systems. Hence, topologies typically become very complex and the layout criticality is a major topic to be considered. Analysis of almost one hundred different topologies of vehicle manufactures worldwide led to the conclusion that less than 50 % of these layouts had been non-critical, if tolerances of all the parameters involved had been considered in their realistic worst-case scenario. Current vehicle network systems consist of various communication protocol networks such as CAN high speed, CAN low speed, LIN, FlexRay, MOST and others. The major challenge that network developers, dealing with the physical layer implementation, are facing is related to the signal integrity of the communication system. Meaning even if the logical set up and evaluation of the network is fine, the physics can make enormous problems and destroy the complete communication. Since each protocol has its own specification with respect to the physical layer implementation, all of them have their individual issues that the developer must take care of when creating the network [2]. The paper is organized as follows. Section II gives an insight into the In-Vehicle Network. Section III explains the vehicle communication system. Section IV explains the different types of network topologies. Section V explains the CANoe tool. Section VI explains the CAPL language. Section VII explains the implementation. The paper is concluded in section VIII.


As automakers are incorporating more and more advanced features into vehicles, there is a growing need for enhanced processing power. S. Channon and P. Miller [6] estimate that the number of microprocessors per vehicle will increase exponentially and by the end of year 2010, the number of microprocessors in any high end vehicle will be 250 [5]. As today's vehicles contain hundreds of circuits, sensors and around 80-120 ECUs, communication is needed among many circuits and functions of a vehicle. In earlier vehicle systems this type of communication is handled via a dedicated wire through point-to-point connections. If all possible combinations of switches, sensors, ECUs and other electronic devices in fully featured vehicles are accumulated, the resulting number of connections and dedicated wiring is enormous. Networking provides a more efficient method for today's complex in-vehicle communications. In-vehicle networking, also known as multiplexing is a method for transferring data among distributed electronic modules via a serial data bus. Just as LANs connect computers, control networks connect a vehicle's electronic equipments. These networks facilitate the sharing of information and resources among the distributed applications [3]. Without serial networking, inter-module communications requires dedicated, point-to-point wiring resulting in bulky, expensive, complex and difficult to install wiring harnesses. Added wiring increased vehicle weight, weakened

performance, and made adherence to reliability standards difficult. For an average well-tuned vehicle, every extra 50 kilograms of wiring-or extra 100 watts of power-increases fuel consumption by 0.2 liters for each 100 kilometers traveled. Also, complex wiring harnesses took up large amounts of vehicle volume, limiting expanded functionality [3]. Eventually, the wiring harness became the single most expensive and complicated component in vehicle electrical systems. Today's control and communications networks, based on serial protocols, counter the problems of large amounts of discrete wiring. For example, in a 1998 press release, Motorola reported that replacing wiring harnesses with LANs in the four doors of a BMW reduced the weight by 15 kilograms while enhancing functionality. Applying a serial data bus reduces the number of wires by combining the signals on a single wire through time division multiplexing. Information is sent to individual control modules that control each function, such as anti-lock braking system, turn signals and dashboard display. As the electronic and electrical content of today's vehicles continue to increase the need for networking is even more evident. For example some high-end luxury would need more than three miles and nearly 200 pounds of wiring if point-to-point connection is used. The resulting number of connections creates a reliability nightmare. Fig1. shows the point to point connection between ECUs.

Fig1. Interconnection of ECUs using point-to-point connection

In-vehicle networking provides many system-level benefits: A decreased number of dedicated wires are required for each function and this reduces the size of the wiring harness. System cost, weight, reliability, serviceability and installation are also improved. Common sensor data such as vehicle speed, engine temperature etc is available on the network, so data can be shared, thus eliminating the need for redundant sensors.

Networking allows greater vehicle content flexibility as functions can be added through software changes. Existing systems require an additional module or additional I/O pin for each function added. Car manufacturers are discovering new features that are enabled by networking. For example the Lincoln Continental's memory profile system stores each driver's preference for ride firmness, seat positions, steering assist effort, mirror positions and even radio station presets. Fig2 shows the example of in-vehicle network in an automotive system using various buses.[9].

Fig2. Current network architecture at Volkswagen

Unlike a point-to-point connection a bus is a communication system that can logically connect several peripherals, i.e. bus controllers over the same set of wires. The consequential potential savings of cost and weight encourage the increasing application of bus systems as communication systems within the automotive area. Moreover busses are easy to implement and to extend, and the failure of one node should not affect others. However, since in a bus system all nodes share the same communication line, they need schemes for collision handling or collision avoidance, or require a bus master which controls access to the shared bus resource. Furthermore, bus systems have a limited cable length and a limited number of nodes. The performance of a bus communication degrades the more nodes are connected, whereas a cable break can disable the entire vehicular bus network [7]. From the point of view of the electrics/electronics, the complete vehicle system can be divided into four domains or functional areas, Driver train, Chassis, Interior and Telematics. In the domains " driver train" and "chassis", it is primarily real-time applications that are in the foreground. In the domain "interior", the focus of networking is on multiplex aspects. In the domain "telematics", it is primarily multimedia and infotainment applications that are networked [32].


A wide variety of vehicle communication systems exist in today's automotive system. [8]. Vehicle functions are divided into systems and sub-systems to provide for passenger entertainment, comfort, and safety, as well as to improve vehicle performance and enhance powertrain control. These systems must communicate with one another over a complex heterogeneous in-vehicle network (IVN). Each network typically contains multiple communication protocols including the industry standard Controller Area Network (CAN), Local Interconnect Network (LIN), FlexRay and MOST(Media Oriented System Transport). [10]. Popular Network Communication Protocols used are as follows

Local Interconnect Network: A low-speed master-slave time triggered protocol meant to connect on-off type loads to higher speed networks. Typical loads include door locks, sun roofs, rain sensors, and powered mirrors. A LIN network is used as a low cost alternative if the full functionality of the CAN protocol is not required.

Fig3 illustrates a typical example of LIN reducing the wire count into a door from dozens of wires to a minimum of three (LIN, power, ground).[11].

Fig3: Multiplexed Car Door Example

Controller Area Network: An event driven communication protocol used in applications such as engine management and body electronics. The maximum specified data rate is 1 Mbps, though the practical maximum is 500 Kbps. High-speed CAN is suitable for critical loads such as anti-lock braking systems and cruise control. Low-speed CAN is fault-tolerant and used for loads such as power seats and motorized windows.

FlexRay: A fault-tolerant high-speed communication protocol targeted toward safety-related applications. The protocol can be operated in single or dual channel mode, where each channel has a maximum data rate of 10 Mbps. Using a dual-channel configuration, a FlexRay network can operate at speeds 20x faster than the maximum CAN bus data rate specification. Along with enabling safety-related applications, a FlexRay network is well suited as a communication backbone connecting heterogeneous networks together.

Media-oriented systems transport: The applications of MOST, a fiber-optic network protocol with capacity for high-volume streaming, include automotive multimedia and personal computer networking. More than 50 firms-including Audi, BMW, Daimler- Chrysler, Becker Automotive, and Oasis SiliconSystems-developed the protocol under the MOST Cooperative.

Byteflight: A flexible time-division multiple-access (TDMA) protocol for safety-related applications, Byteflight can be used with devices such as air bags and seat-belt tensioners. Because of its flexibility, Byteflight can also be used for body and convenience functions, such as central locking, seat motion control, and power windows. BMW, ELMOS, Infineon, Motorola, and Tyco EC collaborated in its development. Although not specifically designed for X-by-wire applications, Byteflight is a very high performance network with many of the features necessary for X-by-wire.

Fig4 shows the major protocols used in the vehicles.

Fig4: Comparison of several in-vehicle network protocols with respect to data rate and communication cost [14].


The request for more new functions has significantly increased the number of ECUs. Up to 22 ECUs is not uncommon in today's high-speed CAN networks. When designing the networking topologies in terms of signal integrity however, several challenging issues should be considered beyond the number of ECUs [12]. The different network topologies are explained in the following section.

Star Topology: In this topology there is a central hub at which all devices are connected. Each device has its own line. If the central hub fails, the entire communication breaks down. Fig5 shows the star topology.





Fig5: Interconnection of ECUs using star topology

Bus Topology: Devices are connected by short branch lines to a main line. Every communication flows over this main line. If this main line is interrupted, two segments are formed which normally continue functioning. Line topology is also called "Linear topology" or "Bus topology" . The CAN bus also uses this topology.





Fig6: Interconnection of ECUs using star topology

Ring Topology: The point-to-point connections between devices are representative of ring topology. All connections are arranged in a closed chain. The communication can be done in only one direction. If a section of line fails, the entire system no longer functions [13].





Fig7: Interconnection of ECUs using star topology


CANoe is an all-round tool suite for the development, testing and analysis of networks and ECUs. It allows the user to analyze, simulate, and test an entire CAN network in a user friendly, highly configurable environment. It provides the user with various diagnostic and analysis features. Due to it's open architecture, CANoe is able to solve complex tasks and be tailored for special application. Models both graphic and text based as well as evaluation windows are provided for simulating and analyzing the entire distributed networks. Institutive user control panels can be created for monitoring and controlling tasks, e.g. in the production or assembly context It has a built-in COM interface. COM is a standard defined by Microsoft for the communication between different software components. Different programming and scripting languages can be used to access the COM server functionality of CANoe. All used scripts must be based on Microsoft's window script software components. Scripting languages such as VB script or Jscript which are the parts of Microsoft windows 98 and above packages, can be used as scripting languages. Programming languages such as Microsoft Visual Basic, Microsoft Visual C++ and Borland Delphi, CAPL can be used to create user specific applications. Included with the product is the CANdb++ editor and the Panel editor. CANoe has several interfaces to simulate and test networks of ECUs. [15].


Based on the C programming language, CAPL, or CAN Access Programming Language, is the programming language used exclusively within the PC-based tool environments of CANoe. The original design intent behind CAPL (which is pronounced "kapple") was to meet the CAN-based distributed embedded system developer's requirements. The creation of CAPL and its programming environment became the implementation to meet these requirements. Using CANoe in combination with CAPL makes it possible to create custom tool applications with user defined behavior. Potential applications are limited only by imagination, available communication hardware limitations (if applicable), and the speed of the PC.

Why use a database with CAPL?

The use of one or more databases to write CAPL programs is highly recommended. Having a database gives you the following advantages:

• Quicker CAPL program development

• Ability to share the database among all personnel involved in all project phases.

• High level of data consistency - everyone uses the same names for variables and messages.

• Elimination of case sensitivity, spelling, and memory issues.

• Easier interpretation of bus data.

Distribution and reusability is also a major advantage when a database is used, since many specifications are contained in one easily to manage database. [3]. Many companies that use the database platform made for CANoe use system design groups to develop their database files. Database files (*.dbc) can also be output as a document or sent by email, and are, therefore, easily distributed globally if desired. Once associated with a database, the CAPL program can access the information defined within the database. This eliminates the burden of defining messages in the CAPL program itself.


In order to see the effect of topologies on the performance of the network , a software simulation was done and the results were compared. For instance, a simulation of two such topologies: ring and star was done and the results and observations are given below. The performance attribute compared here is the bus load. The simulation was done using CANoe software.

The simulated network consisted of four nodes(equivalent to four ECU's) . Each node transmits two messages. In case of ring topology, each node receives only messages from its adjacent node. Whereas in case of star topology, each node receives from every other node. With this setup, the bus load was observed in the data measurement. It was observed that, after the same duration of time , the bus load with the ring topology was higher by about 3.93% than that in the star topology. A similar simulation can be done for different topologies and the effects can be compared. It is also possible to actually connect real ECU's to the network and then measure the load. This would give a better estimate of the performances of the different topologies. The simulation setup for ring and star topologies are shown below.

Fig9: Implementation of ring topology

Fig10: Implementation of star topology

Fig11:Bus load measurement in ring topology

Fig12:Bus load measurement star topology

CANoe allows the simulation of a vehicle network by creating a software equivalent of ECU's which are termed nodes. Multiple nodes can be connected to a central bus. For the node to behave like an ECU , it should participate actively in the network by means of transmitting messages & signals, and in turn respond appropriately to those that it receives. This 'intelligence' is given to the node by CAPL programs. CAPL(Communication Access Programming Language) allows for event based as well as timed execution that makes it suitable for this purpose.

For the simulation here, the demo version of the software has been used. The only limitation was with respect to the number of nodes that could be simulated, which is four. In the full version, a simulation of more than four nodes is possible either by connecting directly to the bus or via a gateway which is a link to another similar network.


In this paper, the network topologies used for in-vehicle communication has been explained. The star and ring topologies were simulated using CANoe software and it was found that the star topology performs better than the ring topology. The only limitation in the simulation was the number of nodes that could be connected to the network was limited to four. The real ECUs could be connected to the simulated network to measure the load. This would give a better estimate of the performances of the different topologies. To implement this, ECU could be connected to the simulated bus via a CanCase box or CanCard and the ECUs could be powered so that it starts transmitting and receiving the messages and the load is measured in the same manner. The other simulated nodes should be modified to simulate the actual ECUs that are available in the network. This is done by writing the appropriate CAPL code so that the required messages are transmitted and the received messages are suitably acted upon.