In-Vehicle Network Architecture for the Next-Generation Vehicles SAE TECHNICAL PAPER SERIES

2005-01-1531 SAE TECHNICAL PAPER SERIES In- Network Architecture for the Next-Generation s Syed Masud Mahmud Department of Electrical & Computer Engineering, Wayne State University Sheran Alles Ford Motor Company Reprinted From: In- Networks and Software (SP-1918) 2005 SAE World Congress Detroit, Michigan April 11-14, 2005 400 Commonwealth Drive, Warrendale, PA 15096-0001 U.S.A. Tel: (724) 776-4841 Fax: (724) 776-5760 Web: www.sae.org

The Engineering Meetings Board has approved this paper for publication. It has successfully completed SAE s peer review process under the supervision of the session organizer. This process requires a minimum of three (3) reviews by industry experts. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, 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 Permissions 400 Commonwealth Drive Warrendale, PA 15096-0001-USA Email: permissions@sae.org Tel: 724-772-4028 Fax: 724-772-4891 For multiple print copies contact: SAE Customer Service Tel: 877-606-7323 (inside USA and Canada) Tel: 724-776-4970 (outside USA) Fax: 724-776-1615 Email: CustomerService@sae.org SN 0148-7191 Copyright 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 discussions will 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 the manuscript or a 300 word abstract to Secretary, Engineering Meetings Board, SAE. Printed in USA

2005-01-1531 In- Network Architecture for the Next-Generation s Syed Masud Mahmud Department of Electrical & Computer Engineering, Wayne State University Sheran Alles Ford Motor Company Copyright 2005 SAE International TRACT 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, driveby-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 "driveby-wire" systems that eliminate camshafts, powersapping 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 for different networks. Seat Gateway between two networks (e.g. Cluster) Powertrain SJB Medium Speed CAN or LIN High Speed CAN Restraints Figure 1: Schematic diagram of a current in-vehicle network. In this paper, we present various types of in-vehicle network topologies that could be used with various types of 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 have been using multiplexing networks in order to reduce wiring harness in vehicles [1-2]. The direct benefit of multiplexing is cost saving. Today s vehicles incorporate many different electronic modules, and have evolved into a distributed processing system. Serial buses are used 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 busbased 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 modules depending on function, feature or control location, further reducing cost by impacting the electrical distribution system and control signal (sensor/actuator) routing. In today s vehicles, two serial buses are used. One bus is used for the powertrain system and the other bus is used 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 of networks. But, future vehicles will need many partitions of the in-vehicle network to provide services for various features such as drive-by-wire, multimedia, fuel efficiency, active collision warning/avoidance, etc. Other Body s Entertainment Telematics Bluetooth/WiFi Gateway Low Speed Bus (LIN): L1 Bus High Speed Bus (Intellibus): L1 Bus Diagnostic Gateway Intelligent Switch Diagnostic and Global Connectivity Bus: L2 Bus TTCAN or FLEXRAY: L1 Bus Medium Speed CAN: L1 Bus Power Train X Y Z 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 an appropriate topology to interconnect various partitions of the in-vehicle network. Interconnection among all partitions of the in-vehicle network is necessary for

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 invehicle 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) a high-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 (). The intelligent switch will have a very low-cost microcontroller supporting two protocols: one for an L1 bus and another one for the L2 bus. An will act as a node on the L2 bus and also as another node on an L1 bus. The L2 bus, shown in Figure 2, has five nodes: four intelligent 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-vehicle networks. It s also scalable. The intelligent switches are also simple. The number of intelligent switches, in the system, is equal to the number of partitions in the invehicle 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 3 compared to four in Figure 2. But the switches of Figure 3 are more complex than those of Figure 2. The switches of Figure 3 make a star connection among three buses: the L2 bus and two L1 buses. Since the number of connections to the L2 bus is less in Figure 3 than 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 2 and 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: permanent faults 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. s Other Body s Entertainment Telematics Bluetooth/WiFi Gateway Low Speed Bus (LIN): L1 Bus High Speed Bus (Intellibus): L1 Bus Diagnostic Gateway Diagnostic and Global Connectivity Bus: L2 Bus Intelligent Switch TTCAN or FLEXRAY: L1 Bus Medium Speed CAN: L1 Bus Power Train X Y Z Figure 3: Schematic diagram of an in-vehicle network with four level-1 buses, one level-2 bus and two intelligent switches.

However, the presence of a temporary fault will increase the message latency. High message latencies could be acceptable for non-safety critical messages, but not for safety critical messages. One network partition of Figures 2 and 3 uses a bus with time-triggered protocol, for vehicle dynamics, power train and systems. Since this network partition carries safety critical messages, on time delivery (within certain tolerance) of these messages must be guaranteed even if there are temporary faults. Basic Cycle 0 Reference Message Message A Basic Cycle 1 Reference Message Message A Basic Cycle 2 Reference Message Message C Basic Cycle 3 Reference Message Message C Arbitra. Message B Free Arbitra. Message B Arbitra. Message D Message D Free Free Arbitra. Free 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. Timetriggered 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 the arbitrating windows. The free windows are reserved for future expansion of the system. The sequential flow of messages in a TTCAN system is represented by a matrix 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 reference message. In a TTCAN system, there is a master node, which is responsible for maintaining a global clock. At the 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 critical message could not go through its Exclusive due to the presence of errors, it will have to wait until its next Exclusive. 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, then this 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 can compete for the bus during an arbitrating window after it failed 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 have fault tolerant mechanisms for the transmission of safety critical messages with deterministic latencies. One way of providing fault tolerant mechanisms is by maintaining additional paths among the nodes. Figure 5 shows a system that will tolerate permanent faults on L1 buses, but the system will work with degraded performance under such faulty conditions. Working with degraded performance may be acceptable for nonsafety related systems, but not for powertrain and active collision 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 the Level-2 bus. For example, if the TTCAN or FlexRay bus, shown in Figure 5, becomes faulty, then the, Powertrain and modules will have to use the L2 bus for communicating among themselves. The architecture 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 on the 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 fault tolerant capabilities for all modules, then Figure 6 shows a better way of connecting the modules at an expense of several three-port intelligent switches. In this architecture, the second port of every module of a cluster is connected by another L1 bus. Thus, every cluster 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. If degraded performance from a particular cluster (for nonsafety 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 buses can 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

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. This architecture is also scalable. Hence, the system can be easily expanded. Other Body Low Speed Bus (LIN): L1 Bus Entertainment Diagnostic Gateway Telematics Bluetooth/WiFi Gateway High Speed Bus (Intellibus): L1 Bus Diagnostic, Global Connectivity and Cluster Fault Tolerant Bus: L2 Bus Medium Speed CAN: L1 Bus Power Train TTCAN or FLEXRAY: L1 Bus X Y Z Figure 5: Schematic diagram of a fault tolerant in-vehicle network with four level-1 buses and one level-2 bus. Other Body Entertainment Telematics Bluetooth/WiFi Gateway Low Speed Bus (LIN): L1 Bus Medium Speed Speed Fault Tolerant Fault Tolerant Bus: L1 Bus B L1 B High Speed Bus (Intellibus): L1 Bus Very Low Speed Fault Tolerant Bus: L1 Bus Diagnostic Gateway Diagnostic and Global Connectivity Bus: L2 Bus TTCAN or FLEXRAY: L1 Bus Low Speed Fault Tolerant Bus: L1 Bus Power Train Medium Speed CAN: L1 Bus X Y Z Figure 6: Schematic diagram of a fault-tolerant in-vehicle network with eight level-1 buses, one level-2 bus and four intelligent switches.

The major drawback of the architecture shown in Figure 6 is the cost of dual-port modules and three-port intelligent switches. Since all modules are not safetycritical modules. We can use dual-ports only for the safety-critical modules, and one port for all other modules. 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 good bandwidth 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-port intelligent switches, as shown in Figure 8. Other Body Entertainment Telematics Bluetooth/WiFi Gateway Low Speed Bus (LIN): L1 Bus Diagnostic Gateway High Speed Bus (Intellibus): L1 Bus Diagnostic and Global Connectivity Bus: L2 Bus Low Speed TTCAN/FLEXRAY (Fault Tolerant Bus): L1 Bus Medium Speed CAN: L1 Bus Power Train TTCAN or FLEXRAY: L1 Bus X Y Z 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. Other Body Entertainment Telematics Bluetooth/WiFi Gateway Low Speed Bus (LIN): L1 Bus Diagnostic Gateway High Speed Bus (Intellibus): L1 Bus Diagnostic and Global Connectivity Bus: L2 Bus Low Speed TTCAN/FLEXRAY (Fault Tolerant Bus): L1 Bus Medium Speed CAN: L1 Bus Power Train TTCAN or FLEXRAY: L1 Bus X Y Z 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.

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 located close to each other can be put in one cluster. Each cluster will be provided with at least one Level 1 bus. If there 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 formed depending on the locality and functionality of the modules. Then several clusters can be joined together by a Level 2 bus. If the clusters are formed the way it is described here, then each cluster will need a lower speed bus compared to the bus that would have been required otherwise. Since the inter-cluster communications may not be as much as the intra-cluster communications, even a low speed bus can be used as a 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 a high-speed bus. PERFORMANCE ANALYS 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 the network architecture. Some of these requirements will include 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 generation vehicles. The next section of the paper describes how simulation models can be developed to study various performance parameters of different partitions of the invehicle 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 is associated 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 the case 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 eventbased simulation is computationally more expensive and accurate than the time-based simulation. But, for synchronous 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. The time-based simulation can be used to simulate timetriggered messages and the event-based simulation can be used to simulate event-triggered messages. Thus, a combination of both time- and event-based simulations is necessary to simulate a bus like TTCAN or Flexray. Various types of commercial tools are available to do different 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 a custom simulation tool from the scratch. Using a custom tool we can do simulation in whatever way we want to do. Event Scheduler (a stochastic process) Event Queue Event Dispatcher Event Processing Figure 10: Software model of an event-based simulation. DEVELOPING AN EVENT-BASED SIMULATION TOOL Here we explain how to develop a custom event-based simulation 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 in Figure 9. If the processor is busy or other events are waiting in the processor queue, then the event stays in the processor queue. Otherwise, the processor starts working on the event immediately. The event, queued in the processor queue, will stay in the queue until the previous 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 message through 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 previous messages 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 immediately process the message. Otherwise, the processor will first take care of other queued messages and then it will process this new message. Figure 9 shows the entire process 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 event occurs at a sensor or due to a driver s action, and the time an actuator takes an action. The latency has several components as shown by the following equation. latency = t + t + t + t + t + t (1) where, PQ ps TB bus t = delay at the processor queue PQ t = processing time at the source node ps t = delay at the transmit buffer of the source node TB t = transmit time through the bus bus t = delay at the receive buffer of the destination node RB t = processing time at the destination node pd In 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 ps, depends on the type of the processor. This time can be expressed as t = T k N (2) ps s + T s s RB pd t PQ Where is a constant time, which represents the constant overhead of the processor at the source node

in order to prepare a message. This constant overhead may 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 the transmission of a message is interrupt driven), The time needed by the processor to check some status bits and set/clear some control bits of the CAN controller, The time needed by the processor for some other house keeping operations. Thus, for a given processor, the value of T s can be calculated based on its clock frequency and the number of instructions the processor needs to execute to do the abovementioned operations. The parameter k s, shown in Equation 2, is another constant and N is the number of data bytes in the message. The value of t TB can be determined by monitoring the arrival and exit times of the message in the transmit buffer of the source node. The value of t bus can be expressed as M t bus = (3) S 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, the start 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 t RB can be determined by monitoring the arrival and exit times of the message in the receive buffer of the destination node. Like t, the t pd pd d + d T d value of can be expressed as t = T k N (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. d ps 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 scheduler generates this event based on some kind of realistic stochastic process. We can develop a stochastic model for 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 activity over a long period of time and collecting similar data from 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 the event 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 then placed 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 event processing 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 of the device that generates the event. A synchronous device, such as a time-triggered device, generates events after fixed interval of time. Hence, for a timetriggered system, the interarrival time is fixed. But, an asynchronous device doesn t generate events after fixed interval 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 the event. 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 eventtriggered bus (say CAN bus). Global Simulation Clock Event Scheduler (both deterministic and stochastic process) Event Queue Event Dispatcher Event Processing Figure 11: Software model of a combined time- and event-based simulation.

Since both TTCAN and Flexray support time- and eventtriggered 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 timeand 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 invehicle 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 nondeterministic 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. 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 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 timetriggered messages. 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