8/12/2019 2010-01-0687

1/13

ABSTRACTThis paper is an overview of the current state (calendar year 2010) of in-vehicle multiplexing and what pertinenttechnologies are emerging. Usage and trends of in-vehiclenetworking protocols will be presented and categorized. The

past few years have seen a large growth in the number andtype of communication buses used in automobiles, trucks,construction equipment, and military, among others.Development continues even into boating and recreationvehicles. Areas for discussion will include SAE Class A, B,C, Diagnostics, SafetyBus, Mobile Media, Wireless, and X-

by-Wire. All existing mainstream vehicular multiplex protocols (approximately 40) are categorized using the SAEconvention as well as categories previously proposed by thisauthor. Top contenders will be pointed out along with adiscussion of the protocol in the best position to become theindustry standard in each category.

INTRODUCTION

CURRENT MULTIPLEX CATEGORIESThe multiplexing of automotive electrical data ontocommunication buses dates back to the late 1970s. It wasoriginally hoped that a single bus protocol could handle theneeds of any vehicle. Gradually that expanded to the SAE

categorization of Class A, B, and C and the realization that upto three protocols and/or networks may be necessary.

By 1995 the need for multiple buses per vehicle was becoming apparent [1]. The cost tradeoff, especially, wasstudied - do you put everything on one bus or split it up intoseveral buses? Which is more economical? Which is moreefficient?

This paper continues to discuss the idea that multiple in-vehicle networks will be necessary - mainly on high-end

vehicles in the coming years. These categories include

(besides the existing SAE classes) diagnostics, airbag, mobilemedia, X-by-Wire, and wireless. Each area needs its own protocol and one or more networks running that protocol.Sometimes this is for safety reasons, such as with airbags or X-by-Wire. Regardless of vehicle function partitioning, wenow have distinct classes of signals that will communicateover their own network, or networks (i.e. multiple sub-busesfor smart connector/actuator) [2].

Although not discussed at length in this paper, there is adistinction between protocol and network. Conceivably onemight have the same protocol running on several networks -say CAN for both a body bus and a powertrain bus. So even

though there could be eight or more networks, there mayactually be fewer protocols used. Also, not all protocols arecomplete - meaning they specify attributes of all seven layersof the OSI model [3]. Some are only physical layers (i.e. GMUART, J1708). Some are only higher layers (i.e. TTP).

BACKGROUNDMuch as changed in the area of in-vehicle multiplexing sincethe late 1970s. Incredible progress has been made, and muchwork remains to be done. Serial data communicationcontinues to be the glue that holds everything together for automotive electronics but cost has been and remains the

primary hurdle. Quite a few late model vehicles now havethree, four, or more serial data networks present.

CURRENT STATUS OF THE IN-VEHICLE CATEGORIESCLASS AUsage is for low-end, non-emission diagnostic, general-

purpose communication. Bit rate is generally less than 10 Kb/s and must support event-driven message transmission. Cost

In-Vehicle Networking Technology for 2010 and

Beyond

2010-01-0687Published

04/12/2010

Christopher A. LupiniDelphi Corporation

Copyright 2010 SAE International

8/12/2019 2010-01-0687

2/13

is generally about x adder per node. These days a veryrough estimate of $0.50 to $1 may be used for the value of x. This cost includes any silicon involved (i.e.microprocessor module or transceiver, etc.), software,connector pin(s), service, etc. The cost data discussed inthis paper is for estimate purposes and is only to be used tocompare with other categories.

There have been great strides in this area and LIN has become the defacto standard. Proprietary protocols continueto disappe ar. Figu re 1 illustrates a typical example of LINreducing the wire count into a door from dozens of wires to aminimum of three (LIN, p ower, gro und).

Figure 1. Multiplexed Car Door Example

Some examples of Class A protocols are listed in Table 1a.

Most of these Class A protocols are UARTs. UART is verysimple and economical to implement. Most microcontrollershave the necessary SCI module built-in, or it can beimplemented without a microprocessor. The transceiver issmaller and cheaper than those of other protocols. Thetransceiver IC may be a custom chip combining multi-

protocol capability with regulators, drivers, etc. Right nowthe leading candidate for a Class A world standard is LIN [4].

Table 1b compares some of the major attributes of the ClassA protocols from Table 1a.

CLASS BThe usage here is for the vast majority of non-diagnostic,non-critical communication. Speed is between 10 Kb/s andapproximately 125 Kb/s. Must support event-driven and some

periodic message transmission plus sleep/wakeup. Cost isaround 2x per node. Protocols used for Class B networks arelisted in Table 2a.

The world standard in this area is still CAN. In particular,ISO 11898-2 or ISO 11898-3 at around 80-125 Kb/s for car applications and J1939 at 250 Kb/s for Truck & Busapplications. Both of these use the same digital circuitry andtransceive r in man y cases. J1850 continues its usage and hasactually started a steep decline in volume. The usual

passenger 500 Kb/s CAN network s are more Class C thanClass B.

The ISO 11898-3 (old 11519-2) fault-tolerant low speed 2-wire CAN interface [5] found a niche in some car applications, but is still a small percentage of implementations. This CAN physical layer is slower andcosts more than an ISO 11898-2 interface, but the bus faultdetection capability is enticing. Table 2b compares some of the major attributes of the Class B protocols from Table 2a.

CLASS CUsage is for faster, higher bandwidth systems such as eng inetiming, fuel delivery, etc. Bit rate is between 125 Kb/s and 1Mb/s. Must support real-time periodic parameter transmission(perhaps in the few milliseconds range). Unshielded twisted

pair is the medium of choice instead of shielded twisted pair or fiber optics. Cost is about 3x to 4x per node, unless STP or

fiber optics is involved - which is typically necessary above500 Kb/s. Some example protocols used are listed in Table3a.

J1939 is commonly used for Class B and Class C applicationsfor truck & bus, construction, agriculture, marine, and other industries. Most passenger car applications run ISO 11898-2at 500 Kb/s for their Class C network. The big differencefrom CAN in Class B applications is the type of nodes thatare connected. Total CAN usage, according to CAN inAutomation (CiA) is in the hundreds of millions of nodesworldwide.

Table 3b compares some of the major attributes of the ClassC protocols from Table 3a. GMLAN is not shown due to itsconfidentiality to GM.

8/12/2019 2010-01-0687

3/13

EMISSIONS DIAGNOSTICSUsage is to satisfy OBD-II, OBD-III, E-OBD, Tier-2, etc. somust be a legally acceptable protocol. Protocols used todayare listed in Table 4a. There is overlap with some of the other categories.

Since this data link is only needed between the enginecontroller and the off-board connector, a simple approach issufficient. Most automakers and truck makers are usingKW2000 (ISO 14230) and this has been an emissionsdiagnostic standard. In the U.S., high-speed CAN was

phased-in as the OBD-III emissions test inte rface beginning in MY04 (Model Year 2004). This has been theonly legally acceptable protocol since MY07. SAE J2480 wasan initiative to develop a CAN emissions diagnostic interface,

but it was found to overlap with ISO 15765 so it has beenabandoned. General information on these protocols is shown

in Table 4b.

MOBILE MEDIAUsage is for PC-on-wheels applications. At least twodifferent networks and protocols may be necessary. Thesesub-categories will be referred to as low speed and highspeed. Beginning with this paper wireless i s now i n its owncategory. The necessary bit rate for mobile mediaapplications is between 1 Mb/s and 100 Mb/s+.

Example usage is illustrated by the Figure 2.

Low Speed Mobile Media - Usage is for telematics,diagnostics, and general information passing. Cost is around3x per nod e. IDB- C, a token-passing form of CAN at 250 Kb/s, has fallen out of favor. Most OEMs already have a mid-speed bus based o n CAN to handle low-end telematicscommunication functions. There has been recent interest in alower cost high-end network that can handle digital audiostreams, but not necessarily video. Toward that end, the D2Band MOST developers are working on copper-based

solutions. Depending on the EMC performance, 10 Mb/s, 25Mb/s, or even 50 Mb/s bit rates are being used. Table 5a listssome possible low-speed mobile media protocols.

High Speed Mobile Media - Usage is for real-time audio andvideo streaming. Cost is around 15x to 25x, mainly due tofiber optic s. Fiber optics will be necessary due to the highspeed required to pass real-time video streams from multiplesources to multiple outputs. Sometimes has been compatible

with industry-standard systems such as Connected Car PC or AutoPC. D2B has seen the first usage (Mercedes 1999 S-class) but MOST appears to be the top contender at this time.One of the better choices in this area is Firewire via an effortled by the IEEE 1394 Automotive working group. Ethernet is

beginning to be discussed as one of the candidates. Table 5blists some possible high-speed mobile media protocols. Table5c is a summary of details on these methods.

WirelessUsage is quite pervasive, but a single standard has notemerged. Will be necessary (initially) for cell phones and

palm PCs (PDAs). Eventual use may include cameras, pagers, etc. Cost target is around 5x per node. Figure 3 is justan idea of the type of products that could be connected via

RF.

Figure 3. Wireless Devices in a Vehicle

Much of the advertisement attention has been with Bluetooth.However, 8 02.11 als o has its proponents, so many groups andsuppliers are studying co-location so that products containingeither standard can exist near each other. Ultrawideband(UWB) is still seen as a possibility for future in-car communication. Approved by the U. S. Federal

Communications Commission (FCC) in February 2002, it isessentially white noise communication. Using preciseclocking, tiny amounts of information are transported acrossa very wide range of frequencies at very low power (perhaps1/10000 that of a cell phone). Compared with spreadspectrum which uses a small range of frequencies one at atime, UWB uses a wide range of frequencies all at once.Leading wireless protocols are listed in Table 6.

8/12/2019 2010-01-0687

4/13

SAFETYBUSUsage is for airbag systems. There may be two, or more,

buses such as one for firing and one for sensing. Must supportat least 64 nodes consisting of squibs, accelerometers,occupant sensors, seatbelt pretensioners, etc. Cost is (hopedto be) 1x to 2x per node. The USCAR SafetyBuscommittee was attempting to standardize on a suitable

protocol, but degraded into separate, independent, camps.The two main ones are Safe-by-Wire and BST. Byteflight isin production in at least one BMW vehicle. Table 7a is thelist of current airbag network protocols.

Many issues here involving packaging constraints, existingmechanical envelop, legalities, etc. The winning protocolmay well be a hybrid of several existing proposals. In fact,BST and Safe-by-Wire are actually hybrids of earlier

protocols. For now there is no clear industry direction. Table7b compares some of these protocols.

DRIVE-BY-WIREUsage is for brake-by-wire, throttle-by-wire, steer-by-wire,etc. applications. Bit rate is between 1 Mb/s and 10 Mb/s.Fiber optics will be necessary due to the increased speed. Theutmost in reliability, performance, and real-time capability isrequired. Cost is around 15x+ per node.

Some possible candidate protocols are given in Table 8a.

TTP had the momentum during the 1990s, but CAN wasusually implemented to avoid the costs of time-triggered

protocols). FlexRay continues to win support and went into

production with BMW for 2007 model year. A major issue ishow much fault tolerance is really required. Any scheme willrequire dual bus interfaces, dual microprocessors, buswatchdogs , timers , etc. Cost is a big problem. The level of fault-tolerance needed requires a lot of silicon and softwarewhich, of course, is expensive. The consortium TTAgroup(www.ttagroup.org) was trying to standardize on a protocol.Table 8b is a comparison of these protocols' details.

ISSUES

More networks brings more cost. Obviously the number of ECUs per vehicle can't increase forever. An interesting wayto cut down on the number of ECUs is to bundle functionsinto something called domain controllers. This is a conceptthat has been talked about for awhile - sometimes calledregional computing or generic electric and electroniccontrollers (EECs). More progress needs to be made invehicle electronic architectures. The industry has quite of experience in gateways, but not in routers, backplanes, or

backbones.

Another question is what networks will be needed to supporthybrid and full electric vehicles? Many of the same protocolswill suffice, but connecting dozens of battery packs or cellstogether, for example, is a new challenge.

SUMMARY/CONCLUSIONSMultiple buses per vehicle have been a reality for som e time.Primarily this has been because of re-use, and carryover of existing networks and protocols. However, in the near futurenew functions such as smart connectors, drive-by-wire, andmobile multi media enhancements have been forcing the needfor additional protocols and networks and the means to route

http://www.ttagroup.org/

8/12/2019 2010-01-0687

5/13

data between them. Despite the best intentions of OEMs, thiswill continue. There is no one bus fits-all. Instead, there aredifferent buses for different things.

REFERENCES1. SAE 950293 - Aspects and Issues of Multiple Vehicle

Networks Emaus2. SAE 2001-01-0072 LIN Bus and its Potential for Use inDistributed Multiplex Systems Ewbank, Lupini, Perisho,DeNuto, Kleja

3. ISO 7498 - Data Processing Systems, Open SystemsInterconnection Standard Reference Mode.

4. www.lin-subbus.org

5. A CAN-Based Architecture for Highly ReliableCommunication Systems Hilmer, Kochs, Dittmar.Proceedings from 5th ICC 1999

6. A Double CAN Architecture for Fault-Tolerant ControlSystems Ferriol, F. Navio, Pons J. Navio.. Proenza, Julia.Proceedings from 5th ICC 1999

7. Automakers Aim to Simplify Electronic ArchitecturesMurray Charles, Electronic Design News July 2009

CONTACT INFORMATIONChristopher A. Lupinichristopher.a.lupini@delphi.comwww.del phi.com765-451- 3207

http://www.delphi.com/mailto:christopher.a.lupini@delphi.comhttp://www.delphi.com/mailto:christopher.a.lupini@delphi.comhttp://www.lin-subbus.org/http://www.sae.org/technical/papers/2001-01-0072http://www.sae.org/technical/papers/950293

8/12/2019 2010-01-0687

6/13

Figure 2. Possible Mobile Media Entertainment Network

Table 1a. Some Class A Protocols

8/12/2019 2010-01-0687

7/13

Table 1b. Comparison of Class A Protocols

Table 2a. Some Class B Protocols

8/12/2019 2010-01-0687

8/13

Table 2b. Comparison of Class B Protocols

Table 3a. Some Class C Protocol

8/12/2019 2010-01-0687

9/13

Table 3b. Comparison of Class C Protocols

Table 4a. Some Emission Diagnostics Protocols

8/12/2019 2010-01-0687

10/13

Table 4b. Comparison of Emission Diagnostics Protocols

Table 5a. Some Low-Speed Mobile Media Bus Protocols

Table 5b. Current High-Speed Mobile Media Bus Protocols

8/12/2019 2010-01-0687

11/13

Table 5c. Comparison of Mobile Media Protocols

Table 6. Current Wireless Mobile Media Bus Protocols

Table 7a. Current SafetyBus Protocols

8/12/2019 2010-01-0687

12/13

Table 7b. Comparison of SafetyBus Protocols

Table 8a. Current Drive-by-Wire Protocols

8/12/2019 2010-01-0687

13/13

Table 8b. Comparison of Drive-by-Wire Protocols

The Engineering Meetings Board has approved this paper for publication. It hassuccessfully completed SAE's peer review process under the supervision of the sessionorganizer. 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 aretrieval system, or transmitted, in any form or by any means, electronic, mechanical,

photocopying, recording, or otherwise, without the prior written permission of SAE.

ISSN 0148-7191

doi:10.4271/2010-01-0687

Positions and opinions advanced in this paper are those of the author(s) and notnecessarily those of SAE. The author is solely responsible for the content of the paper.

SAE Customer Service:Tel: 877-606-7323 (inside USA and Canada)Tel: 724-776-4970 (outside USA)Fax: 724-776-0790Email: CustomerService@sae.orgSAE Web Address: http://www.sae.orgPrinted in USA

http://dx.doi.org/10.4271/2010-01-0687