400 Commonwealth Drive, Warrendale, PA 15096-0001 U.S.A. Tel: (724) 776-4841 Fax: (724) 776-5760 Web: www.sae.org

2005-01-1531

In-Vehicle Network Architecture for theNext-Generation Vehicles

Syed Masud MahmudDepartment of Electrical & Computer Engineering, Wayne State University

Sheran AllesFord Motor Company

Reprinted From: In-Vehicle Networks and Software(SP-1918)

2005 SAE World CongressDetroit, MichiganApril 11-14, 2005

SAE TECHNICALPAPER SERIES

The Engineering Meetings Board has approved this paper for publication. It has successfully completedSAE’s peer review process under the supervision of the session organizer. This process requires aminimum of three (3) reviews by industry experts.

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, ortransmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise,without the prior written permission of SAE.

For permission and licensing requests contact:

SAE Permissions400 Commonwealth DriveWarrendale, PA 15096-0001-USAEmail: permissions@sae.orgTel: 724-772-4028Fax: 724-772-4891

For multiple print copies contact:

SAE Customer ServiceTel: 877-606-7323 (inside USA and Canada)Tel: 724-776-4970 (outside USA)Fax: 724-776-1615Email: CustomerService@sae.org

ISSN 0148-7191Copyright © 2005 SAE International

Positions and opinions advanced in this paper are those of the author(s) and not necessarily those of SAE.The author is solely responsible for the content of the paper. A process is available by which discussionswill be printed with the paper if it is published in SAE Transactions.

Persons wishing to submit papers to be considered for presentation or publication by SAE should send themanuscript or a 300 word abstract to Secretary, Engineering Meetings Board, SAE.

Printed in USA

2005-01-1531

In-Vehicle Network Architecture for the Next-Generation Vehicles

Syed Masud Mahmud Department of Electrical & Computer Engineering, Wayne State University

Sheran Alles Ford Motor Company

Copyright © 2005 SAE International

ABSTRACT

The demand for drive-by-wire, telematics, entertainment, multimedia, pre-crash warning, remote diagnostic and software update, etc. will significantly increase the complexity of the future in-vehicle communication networks. New types of communication networks will also be necessary to satisfy the requirements of safety and fuel efficiency, and meet the demand for new features. Different sets of vehicle electronic modules will require different types of networks. For example, drive-by-wire and active collision avoidance systems need fault tolerant networks with time-triggered protocols, to guarantee deterministic latencies; multimedia systems need networks with high bandwidth to transfer video files; and body control electronics need low-bandwidth networks to keep the cost down. As the size and complexity of these networks increase, ease of integration has become a major challenge for design engineers. In today’s vehicles, there are mainly two networks: a high-speed network for the power train and a low-speed network for the body electronics. Since the complexity of the network is increasing and the demand for bandwidth is growing, future vehicles will require many partitioned networks. The partitioning of the networks will be done based on the locality as well as the functionality of the modules. One of the challenging issues will be the selection of topology to interconnect various in-vehicle partitions of the network. Interconnection among all in-vehicle partitions of the network is necessary for diagnostics and software updates in various modules. One logical approach for interconnecting various partitions of the network would be via a hierarchical bus. This paper shows various types of hierarchical connections among the partitions of in-vehicle networks. Different partitions may use different protocols. For example, one partition may use the CAN protocol, the second partition may use the TTCAN protocol, the third partition may use the LIN protocol, and so on. The hierarchical bus will be using intelligent switches to facilitate the translation of messages from one protocol to another protocol while the messages will be moving from one partition to another partition. This

paper discusses the advantages and disadvantages of various types of hierarchical connections in terms of cost, bandwidth, latency, fault tolerance, and many other features. The paper also presents simulation models that can be used to determine the performance of various types of partitions and network topologies.

INTRODUCTION

Automakers are scrambling to implement advanced safety and engine management systems to make vehicles safer and more fuel-efficient, as well as meet growing consumer and government demands. Continuous demands for fuel efficiency mandate "drive-by-wire" systems that eliminate camshafts, power-sapping belt drives and pumps, and a great deal of unnecessary weight. The goal of x-by-wire is to replace nearly every automotive hydraulic/mechanical system with electronics. Electric brakes will replace hydraulics, increasing safety, lowering operating cost and eliminating the use of environmentally hazardous fluids. Steering columns will disappear and will be replaced by electric steering, improving driver safety and making it easy to provide left-hand and right-hand drive models.

The demand for drive-by-wire and many new features such as telematics, entertainment, multimedia, pre-crash warning, remote diagnostic and software update, etc. will significantly increase the complexity of in-vehicle communication networks. New types of communication networks will also be necessary to satisfy the requirements of safety and fuel efficiency, and meet the demand for new features. Different sets of vehicle electronic modules will require different types of networks. For example, drive-by-wire and active collision avoidance systems need fault tolerant networks with time-triggered protocols, to guarantee deterministic latencies; multimedia systems need networks with high bandwidth to transfer video files; and body control electronics need low-bandwidth networks to keep the cost down. As the size and complexity of these networks increase, ease of integration has become a major challenge for design engineers. Major studies are

necessary to determine optimal topology for connecting all the in-vehicle networks; to figure out optimal bandwidth required from different types of in-vehicle networks for keeping latencies under certain bounds; and to select appropriate communication protocols fordifferent networks.

Figure 1: Schematic diagram of a current in-vehicle network.

In this paper, we present various types of in-vehiclenetwork topologies that could be used with various typesof networks and protocols to satisfy the requirements for safety, fuel efficiency, diagnostics, comfort and cost.

EVOLUTION OF IN-VEHICLE NETWORK ARCHITECTURE

For the last two decades, automotive companies havebeen using multiplexing networks in order to reducewiring harness in vehicles [1-2]. The direct benefit of multiplexing is cost saving. Today’s vehicles incorporate many different electronic modules, and have evolvedinto a distributed processing system. Serial buses areused for interconnecting the electronic modules of a vehicle. Serial buses have been selected due to many advantages of bus-based systems, over other interconnection systems [3]. The advantages of bus-based systems are low cost, lower complexity, greater reliability, better scalability, simpler communication protocols, ease of diagnostics, etc. Networks also enable the partitioning of the various electronic modulesdepending on function, feature or control location, further reducing cost by impacting the electrical distribution system and control signal (sensor/actuator) routing.

SeatModule

DoorModule SJB

Medium Speed CAN or LIN

Gateway between two networks

(e.g. Cluster)ABS

High Speed CAN

RestraintsPowertrainVehicleDynamics

In today’s vehicles, two serial buses are used. One busis used for the powertrain system and the other bus isused for body electronics, as shown in Figure 1. Each bus can be considered as a partition of the in-vehicle network. Thus, today’s vehicles have two partitions ofnetworks. But, future vehicles will need many partitionsof the in-vehicle network to provide services for various features such as drive-by-wire, multimedia, fuel efficiency, active collision warning/avoidance, etc.

Figure 2: An in-vehicle network with four Level 1 buses, one Level 2 bus and four intelligent switches.

One of the challenging issues will be the selection of anappropriate topology to interconnect various partitions of

the in-vehicle network. Interconnection among allpartitions of the in-vehicle network is necessary for

Other Body Modules

DoorModule

IS

Low Speed Bus (LIN): L1 Bus

Entertainment Telematics

High Speed Bus (Intellibus): L1 Bus

IS

Diagnostic and Global Connectivity Bus: L2 Bus IS

IS

VehicleDynamics

PowerTrain

ABS

TTCAN or FLEXRAY: L1 Bus

ModuleX

ModuleY

ModuleZ

Medium Speed CAN: L1 Bus

IntelligentSwitch

Bluetooth/WiFiGateway

Diagnostic Gateway

diagnostics and software updates. Since a bus-based system has many advantages over other interconnection systems, one logical approach would be to use another bus, a hierarchical bus, for connecting all other in-vehicle buses (partitions) together, as shown in Figure 2.

The system shown in Figure 2 has four partitions of the in-vehicle network. Each partition of the network uses a Level 1 bus to interconnect various nodes of the vehicle.Thus, the system shown in Figure 2 has four Level 1 (L1) buses: 1) a low-speed bus for body electronics, 2) ahigh-speed bus for entertainment, telematics,multimedia, etc., 3) a bus with a time-triggered protocol for the powertrain system and 4) a medium speed bus for other modules of the vehicle. The four L1 buses are connected using a Level 2 (L2) bus. Every L1 bus is connected to the L2 bus using an intelligent switch (IS).The intelligent switch will have a very low-costmicrocontroller supporting two protocols: one for an L1 bus and another one for the L2 bus. An IS will act as anode on the L2 bus and also as another node on an L1bus. The L2 bus, shown in Figure 2, has five nodes: fourintelligent switches and a Diagnostic Gateway node.Dealers and mechanics can access different electronic modules of a vehicle via the Diagnostic Gateway module. The architecture shown in Figure 2 allows a very simple way of interconnecting various in-vehiclenetworks. It’s also scalable. The intelligent switches are also simple. The number of intelligent switches, in thesystem, is equal to the number of partitions in the in-vehicle network.

Though the system shown in Figure 2 is scalable, the number of connections on the L2 bus will be too many if there are too many partitions in the in-vehicle network.The speed of a bus decreases as the number of connections to the bus increases. The speed of a bus also decreases, when its length increases. Figure 3 shows another variation of the system shown in Figure 2. There are only two intelligent switches in Figure 3compared to four in Figure 2. But the switches of Figure3 are more complex than those of Figure 2. Theswitches of Figure 3 make a star connection amongthree buses: the L2 bus and two L1 buses. Since the number of connections to the L2 bus is less in Figure 3than in Figure 2, the speed of the L2 bus of Figure 3 will be higher than that of the L2 bus of Figure 2. However, one disadvantage of the architecture of Figure 3 is that it is not as scalable as the architecture shown in Figure 2.

The major problem with the architectures of Figures 2and 3 is that neither one will tolerate bus faults. If any bus (L2 or L1) fails, then the communication among a group of modules will be disrupted. As a result, the vehicle system will fail to do its intended operations. Communication faults could be of two types: permanentfaults and temporary faults. The breakdown of a bus is an example of a permanent fault. Temporary faults can occur due to the presence of momentary noise or high electromagnetic interference for a short time. The presence of a permanent fault will break down communications among many nodes.

Figure 3: Schematic diagram of an in-vehicle network with four level-1 buses, one level-2 bus and two intelligent switches.

OtherBody

ModulesDoor

Modules

IS

Low Speed Bus (LIN): L1 Bus

EntertainmentBluetooth/WiFiGateway

Bluetooth/WiFiGatewayTelematics

High Speed Bus (Intellibus): L1 Bus

Diagnostic Gateway IntelligentSwitch

ISDiagnostic and Global Connectivity Bus: L2 Bus

TTCAN or FLEXRAY: L1 Bus Medium Speed CAN: L1 Bus

ABS ModuleX

ModuleY

ModuleZ

PowerTrain

VehicleDynamics

However, the presence of a temporary fault will increase the message latency. High message latencies could beacceptable for non-safety critical messages, but not forsafety critical messages. One network partition ofFigures 2 and 3 uses a bus with time-triggered protocol,for vehicle dynamics, power train and ABS systems. Since this network partition carries safety critical messages, on time delivery (within certain tolerance) ofthese messages must be guaranteed even if there aretemporary faults.

Figure 4: The system matrix of a TTCAN system.

The TTCAN protocol has three different time windows for messages: exclusive window, arbitrating window and free window [4], [5], as shown in Figure 4. Time-triggered messages, which require deterministic latencies, are sent through the exclusive windows. For example, Figure 4 shows that fixed windows (exclusive windows) have been reserved for messages A, B, C and D. Event-triggered messages are sent through thearbitrating windows. The free windows are reserved for future expansion of the system. The sequential flow of messages in a TTCAN system is represented by amatrix called the system matrix, as shown in Figure 4. A system matrix is divided into a number of basic cycles. The first window of a basic cycle is used for a referencemessage. In a TTCAN system, there is a master node, which is responsible for maintaining a global clock. Atthe beginning of every basic cycle, the master node sends the global time using a reference message. All other nodes synchronize their clocks after receiving a reference message.

In TTCAN systems, since a message must be delivered within the same time window in which it started,retransmission of the message is not allowed when errors occur within the message. Thus, if a safety criticalmessage could not go through its Exclusive Window dueto the presence of errors, it will have to wait until its next Exclusive Window. For example, if Message A could not

go through its exclusive window of Basic Cycle 1 (see Figure 4) due to the presence of a temporary fault, thenthis message can not go until the time of its exclusive window in Basic Cycle 0. Thus, Message A will be delayed by three basic cycles. However, Message A cancompete for the bus during an arbitrating window after itfailed to go through its own exclusive window, but there is no guarantee that Message A will get the bus during an arbitrating window. If Message A is a safety critical message and if it is delayed by too long, then vehicle’s safety will be compromised. Thus, it is desirable to havefault tolerant mechanisms for the transmission of safetycritical messages with deterministic latencies.

One way of providing fault tolerant mechanisms is bymaintaining additional paths among the nodes. Figure 5shows a system that will tolerate permanent faults on L1buses, but the system will work with degradedperformance under such faulty conditions. Working withdegraded performance may be acceptable for non-safety related systems, but not for powertrain and activecollision avoidance/warning systems. In this architecture, if a Level-1 bus connecting a cluster of modules becomes faulty, then the modules of that cluster will have to communicate among themselves using theLevel-2 bus. For example, if the TTCAN or FlexRay bus, shown in Figure 5, becomes faulty, then the Vehicle Dynamics, Powertrain and ABS modules will have to usethe L2 bus for communicating among themselves. Thearchitecture shown in Figure 5 is scalable and doesn’t require any external switches. But, this architecture requires that every electronic module must have two ports: one for the L2 bus and another one for an L1 bus. Since all electronic modules of a vehicle will be connected to the L2 bus, the capacitive loading effect onthe L2 bus will be much higher than that on the L1 buses. Thus, for the same communication media (single wire, dual wire, twisted pair, shielded twisted pair, etc.) using copper wire technology, the bandwidth available from the L2 bus will be much less than that available from an L1 bus. Another disadvantage of this architecture is that, since every module has two ports, the modules will be little bit more expensive than those modules that have only one port.

If two-port modules are going to be used to have faulttolerant capabilities for all modules, then Figure 6 shows a better way of connecting the modules at an expense ofseveral three-port intelligent switches. In thisarchitecture, the second port of every module of acluster is connected by another L1 bus. Thus, everycluster of modules has two L1 buses. Hence, if an L1 bus of a cluster of modules becomes faulty, then another L1 bus of that cluster can be used for communication. Ifdegraded performance from a particular cluster (for non-safety related cluster) is acceptable, then the second L1 bus and the corresponding port of each module of the cluster can be built using low-cost technology. But for safety critical modules, both ports and both L1 busescan be built using the same technology. The Level 2 bus (L2 bus) of the architecture shown in Figure 6 doesn’t have too many connections. The total number of

Basic Cycle 0

Reference Message

Message A

Arbitra. Window

Message B

Free Window

Basic Cycle 1

Reference Message

Message A

Message B

Arbitra. Window

Free Window

Basic Cycle 2

Reference Message

Message C

Free Window

Message D

Arbitra. Window

Basic Cycle 3

Reference Message

Message C

Arbitra. Window

Message D

Free Window

connections is equal to the total number of clusters plus another connection for the Diagnostic Gateway. Hence,the bandwidth of the L2 bus will not reduce significantly

with the addition of new modules in the vehicle. Thisarchitecture is also scalable. Hence, the system can be easily expanded.

OtherBody

Module

Bluetooth/WiFiGatewayDoor

ModuleEntertainment Telematics

Low Speed Bus (LIN): L1 Bus

High Speed Bus (Intellibus):

L1 BusDiagnostic Gateway

Diagnostic, Global Connectivity and Cluster Fault Tolerant Bus: L2 Bus

Medium Speed CAN: L1 Bus

TTCAN or FLEXRAY:

L1 BusModule

ZModule

XModule

YABSVehicle

DynamicsPowerTrain

Figure 5: Schematic diagram of a fault tolerant in-vehicle network with four level-1 buses and one level-2 bus.

Figure 6: Schematic diagram of a fault-tolerant in-vehicle network with eight level-1 buses, one level-2 bus and four intelligent switches.

Other Body

Module

Door Module

Low Speed Bus (LIN): L1 Bus

Entertainment Telematics Bluetooth/WiFi

Gateway

IS

Diagnostic and Global Connectivity Bus: L2 Bus

IS IS

Vehicle Dynamics

PowerTrain

TTCAN or FLEXRAY: L1 Bus

ModuleX

Module Y

ModuleZ

Medium Speed

CAN: L1 Bus

Low Speed Fault Tolerant Bus: L1 Bus

Medium Speed Fault Tolerant B L1 B

IS Very Low Speed Fault Tolerant Bus: L1 Bus

Diagnostic Gateway

Medium Speed Fault Tolerant Bus: L1 Bus

High Speed Bus (Intellibus): L1 Bus

ABS

The major drawback of the architecture shown in Figure6 is the cost of dual-port modules and three-portintelligent switches. Since all modules are not safety-critical modules. We can use dual-ports only for thesafety-critical modules, and one port for all othermodules. Figure 7 shows another architecture where dual-port modules are used only for the powertrain bus.

The architecture shown in Figure 7 is also scalable and doesn’t have too many connections on the L2 bus. Thus,the system can be easily expanded, and goodbandwidth can be obtained from the L2 bus. The number of intelligent switches, shown in Figure 7, can be reduced from five to two if we use three- and four-portintelligent switches, as shown in Figure 8.

OtherBody

Module

Figure 7: Schematic diagram of a partial fault-tolerant in-vehicle network with five Level 1 buses, one Level 2 bus and five intelligent switches.

Figure 8: Schematic diagram of a partial fault-tolerant in-vehicle network with five Level 1 buses, one Level 2 bus and two intelligent switches.

DoorModule

Low Speed Bus (LIN):

L1 Bus

EntertainmentBluetooth/WiFi

GatewayTelematics

High Speed Bus (Intellibus): L1 BusDiagnostic GatewayIS IS

Diagnostic and Global Connectivity Bus: L2 BusISIS IS Low Speed TTCAN/FLEXRAY

(Fault Tolerant Bus): L1 Bus Medium Speed CAN: L1 Bus

ModuleX

ModuleY

ModuleZ

TTCAN or FLEXRAY:

L1 BusABSPowerTrain

VehicleDynamics

OtherBody

ModuleDoor

Module

Low Speed Bus (LIN):L1 Bus

EntertainmentBluetooth/WiFi

GatewayTelematics

High Speed Bus (Intellibus): L1 Bus

Diagnostic Gateway

IS ISDiagnostic and Global Connectivity Bus: L2 Bus

Low Speed TTCAN/FLEXRAY (Fault Tolerant Bus): L1 BusMedium Speed CAN: L1 Bus

TTCAN or FLEXRAY:

L1 Bus

ModuleX

ModuleY

ModuleZ

ABSVehicleDynamics

PowerTrain

FORMING CLUSTERS (GROUPS) OF ELECTRONIC MODULES

The electronic modules of a vehicle can be divided into several groups or clusters. The clusters can be formed based on functionality and locality. This means that the modules that do similar type of work and are locatedclose to each other can be put in one cluster. Eachcluster will be provided with at least one Level 1 bus. Ifthere are similar electronic modules both at the front and rear of a vehicle, then the front modules can be put in one cluster and the rear modules can be put in another cluster. This way, other clusters can be formeddepending on the locality and functionality of the modules. Then several clusters can be joined togetherby a Level 2 bus. If the clusters are formed the way it isdescribed here, then each cluster will need a lowerspeed bus compared to the bus that would have been required otherwise. Since the inter-cluster communications may not be as much as the intra-clustercommunications, even a low speed bus can be used asa Level 2 bus to connect the clusters. This approach of forming the clusters will save cost due to the fact that for the same length, a low-speed bus costs less than ahigh-speed bus.

PERFORMANCE ANALYSIS OF IN-VEHICLE NETWORK ARCHITECTURE

The performance of various partitions of the in-vehicle network as well as the entire network can be determined by developing simulation models. After executing the simulation models on computers, one can determine the minimum requirements for different partitions of thenetwork architecture. Some of these requirements willinclude minimum processing powers needed from various electronic modules, minimum bandwidth needed from various buses, minimum size of buffers needed in various switches, etc. Computer simulations will also allow us to select the optimal network topology needed to meet the requirements of the next generationvehicles. The next section of the paper describes how simulation models can be developed to study various performance parameters of different partitions of the in-vehicle network.

TYPES OF SIMULATIONS:

Computer simulations can be divided into two types [7]:i) time-based simulation and ii) event-based simulation.In a time-based simulation, the program control loop isassociated with time.

Processor Queue

Sensor Processor

Transmit Buffer of CAN node

CAN Bus

Receive Buffer of CAN node

Processor Actuator

Figure 9: A diagram of information flow from a sensor to an actuator.

For each execution of the main control loop, the simulation clock advances by a fixed time unit. In thecase of an event-based simulation, the execution of the main loop represents a single event. The simulation clock is simply advanced by the amount of time since the last event. For asynchronous systems, the event-based simulation is computationally more expensive andaccurate than the time-based simulation. But, forsynchronous systems, the time-based simulation is as good as the event-based simulation, and it is computationally less expensive than event-based simulation. CAN protocol is an event-based protocol. Thus an event-based simulation tool will be the most appropriate tool for analyzing various performance parameters of a CAN bus. Buses that use time-triggered protocols, such as TTCAN [4], [5] and FlexRay [6], carry both time-triggered and event-triggered messages. Thetime-based simulation can be used to simulate time-triggered messages and the event-based simulation can be used to simulate event-triggered messages. Thus, acombination of both time- and event-based simulationsis necessary to simulate a bus like TTCAN or Flexray.

Various types of commercial tools are available to dodifferent kinds of simulation. However, there could be some problems with commercial tools. For example, using commercial tools, it may not be possible to tune some of the simulation parameters the way we want to tune them. Thus, it might be a better idea to develop acustom simulation tool from the scratch. Using a custom tool we can do simulation in whatever way we want todo.

Figure 10: Software model of an event-basedsimulation.

DEVELOPING AN EVENT-BASED SIMULATION TOOL

Here we explain how to develop a custom event-basedsimulation tool to meet the requirements of our specific need for the next generation vehicles. In a vehicle

system, an event is triggered by a sensor or by the driver’s action such as pressing the brake or gas paddle. The event then goes to a processor queue, as shown inFigure 9. If the processor is busy or other events arewaiting in the processor queue, then the event stays in the processor queue. Otherwise, the processor startsworking on the event immediately. The event, queued inthe processor queue, will stay in the queue until theprevious events are taken care of by the processor. The processor spends some time (processing time) on an event. After that, the processor tries to send a messagethrough the bus (say CAN bus) connected to the processor. If the bus is available, then the message is immediately sent to the bus. Otherwise, the message is queued in the transmit buffer of the CAN node. The message will go through the bus after the previousmessages have been transmitted. After a certain time (transmit time), the message is queued to the receive buffer of the destination CAN node. If the processor at the receiving node is free, then it will immediatelyprocess the message. Otherwise, the processor will first take care of other queued messages and then it willprocess this new message. Figure 9 shows the entireprocess of information flow from a sensor to an actuator.

Components of the latency of an event:

There is a delay (latency) between the time an eventoccurs at a sensor or due to a driver’s action, and thetime an actuator takes an action. The latency has several components as shown by the following equation.

pdRBbusTBpsPQ ttttttlatency +++++= (1)

Event Queue where,Event Scheduler

(a stochastic process)

=PQt delay at the processor queue

=pst processing time at the source node

=TBt delay at the transmit buffer of the source node

Event Dispatcher =bust transmit time through the bus

=RBt delay at the receive buffer of the destination node

=pdt processing time at the destination nodeEvent ProcessingIn the simulation model, the value of the delay, , at the queue of the source processor can be determined by monitoring the arrival and exit times of the event in the processor queue. The value of the processing time, t ,depends on the type of the processor. This time can beexpressed as

PQt

ps

NkTt ssps += (2)

Where is a constant time, which represents the constant overhead of the processor at the source node

sT

in order to prepare a message. This constant overheadmay include

• The time needed by the processor to get out of the main program,

• The time needed by the processor go to the interrupt service routine (assuming that thetransmission of a message is interrupt driven),

• The time needed by the processor to checksome status bits and set/clear some control bitsof the CAN controller,

• The time needed by the processor for someother house keeping operations.

Thus, for a given processor, the value of T can be calculated based on its clock frequency and the numberof instructions the processor needs to execute to do theabovementioned operations. The parameter k , shown

in Equation 2, is another constant and is the number of data bytes in the message. The value of can be determined by monitoring the arrival and exit times of the message in the transmit buffer of the source node. The value of can be expressed as

s

s

TBtN

bust

SMtbus = (3)

Where, M is the total number of bits in the message, and S is the speed of the bus in bits/sec. For example, if the message is a CAN message, then M will include, thestart bit, arbitration bits, RTR bit, control bits, data bits, stuff bits, CRC bits, all delimiter bits and the end of frame bits. The value of can be determined by monitoring the arrival and exit times of the message in the receive buffer of the destination node. Like t , the

value of can be expressed as

RBt

ps

pdtNkTt ddpd += (4)

Where is a constant time, which represents the constant overhead of the processor at the destination node in order to prepare a message, and k is the additional overhead per byte of data in preparing the message.

dT

d

Simulation Model: Figure 10 shows the block diagram of an event-based simulation model. In an event-based simulation model,an event is generated by a scheduler. The schedulergenerates this event based on some kind of realisticstochastic process. We can develop a stochastic modelfor a particular event by collecting a large set of real data for that event. For example, the stochastic model of the brake event (pressing the brake paddle by the driver), can be developed by logging the driver’s brake activityover a long period of time and collecting similar datafrom many vehicles.

After generating an event, the scheduler keeps that event in the event queue, as shown in Figure 10. When an event is dispatched from the event queue, another event is generated. This new event is then sent to theevent queue. When a new event enters into the event queue, it is sorted within the event queue using the event-time as the sorting key. The new event is thenplaced at an appropriate point in the event queue. After dispatching an event from the event queue, the event is then sent to the event processing unit. The eventprocessing unit then simulates the event in exactly the same way as a real system would process it.

The stochastic model of an event determines the interarrival time of the event, based on the behavior ofthe device that generates the event. A synchronous device, such as a time-triggered device, generatesevents after fixed interval of time. Hence, for a time-triggered system, the interarrival time is fixed. But, anasynchronous device doesn’t generate events after fixedinterval of time. Most physical asynchronous systems behave like a Poisson process. Thus, we can assume that a non time-triggered device will behave like a Poisson process. The stochastic model of an event will have the appropriate values of the parameters that define the characteristics of the Poisson process of theevent. As mentioned earlier, these parameters of the stochastic model for an event can be determined by collecting a large set of field data for that particular event. The model shown in Figure 10 can be used to simulate an event-triggered system with an event-triggered bus (say CAN bus).

Global Simulation Clock

Figure 11: Software model of a combined time- and event-based simulation.

Event Scheduler (both deterministic and

stochastic process)

Event Queue

Event Dispatcher Event Processing

Since both TTCAN and Flexray support time- and event-triggered messages, we can develop the simulation models of these buses by building another layer on the top of the event-based simulation model. Figure 11 shows a software simulation model of a combined time- and event-based system. Here, the event scheduler is a deterministic as well as a stochastic process. In this case, a global simulation clock is maintained to keep the time-triggered events in sync. The frequency of this global simulation clock (software clock) should be at least equal to the highest frequency clock used in the in-vehicle network architecture. This requirement on the software clock will allow us to determine the latency and other performance parameters at a very high resolution (within a clock cycle of the highest frequency clock of the real system). At every global simulation clock pulse, the event queue must be checked. If the event-time of the event at the head of the event queue is less than or equal to the current value of the global simulation clock, then the event will be dispatched from the event queue. The dispatched event will then be checked to determine whether it is a deterministic event or a non-deterministic event. If it is a deterministic event, then the deterministic scheduling process will be used to schedule the next deterministic event. Otherwise, stochastic scheduling process will be used to schedule the next non-deterministic event. The scheduled event, whether deterministic or non-deterministic, will then be sent to the event queue. The event will be placed in the event queue after sorting it with other events in the event queue. The event-time will be used as the key to sort the events in the event queue.

By developing a simulation model, one can determine various performance parameters of the in-vehicle network. These parameters will include, but not limited to are the latency of different types of message, busload, bandwidth, and throughput.

CONCLUSION

In this paper, we discussed various types of topologies and protocols that could be used in the future in-vehicle networks. Due to the complexity of the future in-vehicle networks, many partitions of the network will be required. These partitions must be interconnected together for better diagnostic and software upload purposes. Since safety critical messages need fault tolerant mechanisms, we proposed how such mechanisms can be provided to the safety critical messages. The cost-effective way to compare the advantages and disadvantages of various types of topologies and protocols is by doing realistic simulations. This paper explains, how simulation models can be developed to determine the performance of in-vehicle network systems that will deal with both event- and time-triggered messages.

REFERENCE

1. R. K. Jurgen, "Coming from Detroit: Netwoks on wheel," IEEE Spectrum, pp. 53-59, June 1986

2. J. W. Tuska, "Multiplex wiring with microcomputer control," International Congress & Exposition, SAE paper 840495, Detroit, MI, Feb. 27 - March 2, 1984

3. C. R. Das and Laxmi Bhuyan, “Bandwidth availability of multiple-bus multiprocessors,” IEEE Transactions on Computers, Vol. 34, No. 7, pp. 918-926, Oct. 1985.

4. Thomas Fuehrer, Bernd Mueller, Florian Hartwich and Robert Hugel, “Time-Triggered CAN (TTCAN),” Proc. of the SAE 2001 World Congress, Detroit, Michigan, March 5-8, 2001, paper number: 2001-01-0073.

5. Holger Zeltwanger, “Time-Triggered Communication on CAN,” Proc. of the SAE 2002 World Congress, Detroit, Michigan, March 4-7, 2002, paper number: 2002-01-0437.

6. Christopher Temple, “Protocol Overview,” Notes of FlexRay International Workshop, Detroit, Michigan, March 4, 2003.

7. Michael K. Molloy, “Fundamentals of Performance Modeling,” Macmillan Publishing Company, 1989.

CONTACT

Syed Masud Mahmud, Ph.D. Associate Professor Department of Electrical and Computer Engineering Wayne State University Detroit MI 48202 Phone: (313) 577-3855 Fax: (313) 577-1101 Email: smahmud@eng.wayne.edu

Sheran Alles, Ph.D. Technical Specialist ECC Building 20600 Rotunda Dr., Ford Motor Company Dearborn, MI 48124 Phone: (313) 594-0553 Email: salles@ford.com