1、SAE Technical Standards Board Rules provide that: “This report is published by SAE to advance the state of technical and engineering sciences. The use of this report is entirelyvoluntary, and its applicability and suitability for any particular use, including any patent infringement arising therefro
2、m, is the sole responsibility of the user.”SAE reviews each technical report at least every five years at which time it may be reaffirmed, revised, or cancelled. SAE invites your written comments and suggestions.QUESTIONS REGARDING THIS DOCUMENT: (412) 772-8512 FAX: (412) 776-0243TO PLACE A DOCUMENT
3、 ORDER; (412) 776-4970 FAX: (412) 776-0790Copyright 1997 Society of Automotive Engineers, Inc.All rights reserved. Printed in U.S.A.SURFACEVEHICLE400 Commonwealth Drive, Warrendale, PA 15096-0001INFORMATIONREPORTJ2355ISSUEDOCT97Issued 1997-10ITS DATA BUS ARCHITECTURE REFERENCE MODEL INFORMATION REPO
4、RTForewordThis SAE Information Report represents a proposed reference model for an in-vehicle ITS Data Bus(IDB). The IDB will enable OEMs, dealers, and vehicle owners to reliably and safely install a wide range ofelectronics equipment in their vehicles at any time during the vehicles life cycle. The
5、 primary audiences for thisdocument are SAE members and automotive engineering and consumer electronics professionals.This document is based on the results of two workshops led by the SAE ITS Data Bus committee in 1995 and1996. The goal of the reference model is to describe an ITS Data Bus for ITS,
6、entertainment, and security devices(modules). Without this document, current vehicle design cycles will involve the installation of technology which isthree or four (or more) years old by the time the customer takes delivery. A reference model with open industrystandard interfaces will allow auto co
7、mpanies to offer state-of-the-art entertainment, traveler information,communications, and security devices to their customers. Vehicle OEM and third party electronics companies willbe able to design automotive electronics for use across multiple car platforms and across vehicle manufacturers,using a
8、 standard communications interface.This document introduces the IDB reference model and describes its overall concepts. Details of the IDBspecification will be covered in SAE J2366, J2367, and J2368.TABLE OF CONTENTS1. Scope . 22. References . 22.1 Applicable Publications. 23. Rationale for this Inf
9、ormation Report 23.1 The Need 23.2 The Problem. 23.3 The Solution . 34. Functional Requirements of the ITS Data Bus . 34.1 Overall Goals 34.2 Functional Requirements 4SAE J2355 Issued OCT97-2-5 ITS Bus Architecture: Reference Model 75.1 Functional Elements .75.2 Interfaces and Protocols .86. Future
10、Plans .91. ScopeThis SAE Information Report describes a reference model for an in-vehicle data bus for IntelligentTransportation Systems (ITS). It introduces the ITS Data Bus (IDB) reference model and describes overall IDBconcepts. 2. References2.1 Applicable PublicationsThe following publications f
11、orm a part of this specification to the extent specifiedherein. Unless otherwise indicated, the latest issue of SAE publications shall apply.2.1.1 SAE PUBLICATIONSAvailable from SAE, 400 Commonwealth Drive, Warrendale, PA 15096-0001.SAE J2366ITS Data Bus StandardSAE J2367ITS Data Bus Gateway Referen
12、ce Design Recommended PracticeSAE J2368ITS Data Bus Conformance Testing StandardIn-Vehicle Electronics for IVHS - Workshop Results - SAE, December 1995In-Vehicle Electronics for Intelligent Transportation Systems II - Workshop Results - SAE, July 19963. Rationale for This Information Report3.1 The N
13、eedVehicle OEMs would like to be able to offer state of the art entertainment, traveler information,communications and security devices (modules) to their customers, but are hampered by the current designcycle of new vehicles. OEM and third party electronics companies would like to be able to design
14、 automotiveelectronics for use across multiple vehicle platforms and across vehicle manufacturers, but there is currently nosingle standard interface. Drivers would like to be able to install a variety of state of the art electronics devicesin their vehicles even after purchase, but installation can
15、 be complicated and expensive, and rarely results inintegrated systems.3.2 The ProblemMost modern computing paradigms embrace the concepts of network and distributedcomputing. It is natural therefore to consider these concepts as one addresses the requirements of thevehicle. Although vehicle manufac
16、turers are indeed using multiplex buses (the automotive equivalent of a localarea network), there remain a number of problems. For a variety of reasons vehicle companies are notconverging on a single standard. As a result, device manufacturers must design and build multiple versions oftheir products
17、 to attach to the various buses, raising the cost. A device (electronic module) connected to thevehicles multiplex bus must be qualified through the normal design cycle of the vehicle, which does not easilyallow unplanned-for electronics to be added by the manufacturer, the dealer, or the customer.
18、For warranty,safety, and liability reasons, electronic devices must not be allowed to interfere in any way with the operation ofthe vehicle or of any of its subsystems, so they cannot be easily retrofitted to the vehicles multiplex bus.SAE J2355 Issued OCT97-3-FIGURE 1DUAL BUS ARCHITECTURE3.3 The So
19、lutionA dual-bus architecture, as shown in Figure 1, is proposed as the basis for a family of SAEstandards, in which an IDB is connected to the vehicles multiplex bus through a gateway. This allowselectronic device manufacturers to build a single, automotive version of their product that plugs into
20、the IDB onany vehicle. In addition, the IDB is independent of all vehicle systems, except for power, eliminating the needfor a full electrical bench qualification (of course, maximum power drain in ignition-on and ignition-off states willhave to be specified and EMC specifications will have to be me
21、t by IDB devices). The gateway, under controlof the vehicle company, acts as a “firewall“, allowing only authorized message traffic to pass between thevehicles multiplex bus and the IDB devices. This “firewall“ has significant safety benefits, as it prevents ITSbus message traffic from interfering w
22、ith basic functions of the vehicle.4. Functional Requirements of the ITS Data BusThese requirements were developed through an iterativeconsensus process. Evolutionary changes to these requirements, the technical details of implementation, andperformance specifications will be dealt with in SAE J2366
23、 and related documents.4.1 Overall GoalsThe overall goals describe the design philosophy of the IDB rather than quantifiablespecifications.SAE J2355 Issued OCT97-4-4.1.1 SAFETY & SECURITYThe IDB shall provide an environment in which devices can be plugged, unplugged,and operated in a vehicle in a ma
24、nner which does not threaten the integrity of the vehicle or the devices thatare being used. While not itself providing security and authentication services, the IDB shall not preclude theimplementation of suitable security for transactions involving the exchange of money and/or proprietaryinformati
25、on.4.1.2 MANUFACTURABILITYIDB-compatible devices and software shall be easy to design and implement. Thisimplies minimal specifications and unambiguous requirements. Ease of manufacture helps to assure thewide adoption of the standard, and contributes to lowering the cost of the manufactured items.4
26、.1.3 EASE OF USEThe addition or removal of IDB-compatible devices shall be easy enough for a consumer toaccomplish the task, with little or no expert assistance required.4.1.4 OPEN STANDARDThe IDB shall be an open standard to ensure that all vehicle and electronic productmanufacturers have equal acc
27、ess to the standard and to the market. Such accessibility helps assure lowercost, through competition and mass manufacturing.4.1.5 MINIMAL STANDARDThe IDB standard shall be extensible and capable of migration to future technologiesand different physical media with no impact on application software.4
28、.1.6 SUPPORT FOR FUTURE APPLICATION SCENARIOSThe scope of applications for the IDB is enormous. Everyeffort shall be made to ensure that the widest possible range of applications can be supported.4.1.7 LOW COSTThe incremental direct material cost to implement an IDB interface in a device shall be ve
29、rysmall, e.g., less than $1 (1996).4.2 Functional RequirementsEach functional requirement specified in this document will translate into one ormore measurable specifications in other documents (SAE J2366, J2367, and J2368). Each item in the IDBstandards must track back to one of the functional requi
30、rements. The list of functional requirements will evolveas the work progresses and more issues arise.4.2.1 GRACEFUL DEGRADATIONThe IDB physical layer shall be designed such that shorts to vehicle ground,shorts to vehicle battery, shorts across the IDB wiring, and open circuits, shall not cause any d
31、amage to thewiring, the vehicle, or any attached devices. Functional operation under any of these conditions may cease,but shall resume within the boot/discovery time after the fault is removed. The IDB design shall be such thatno single failure, other than a fault in the physical layer as described
32、 above, or the loss of primary power,shall cause the entire IDB to fail.4.2.2 HOT PLUG AND PLAYIt shall be possible to attach devices to and remove devices from the IDB at any time,whether power is on or off.4.2.3 SELF-IDENTIFICATIONDevices attached to the IDB shall be able to identify themselves to
33、 other IDB devicesand shall self configure to obtain unique addresses on the IDB. No user intervention shall be required tocomplete this configuration, other than the provision of the appropriate application software.4.2.4 SHORT BOOT/DISCOVERY TIMEThe IDB and all attached devices (modules) shall com
34、plete initialization andself-configuration within 2 s after power is applied to the devices. When a new device (module) is added tothe IDB while it is operating, detection of the new device and reconfiguration of the IDB to include it shall becompleted within 2 s.SAE J2355 Issued OCT97-5-4.2.5 PEER-
35、TO-PEER COMMUNICATIONSThe set of devices that is likely to be attached to the IDB is unpredictable,and no single device is guaranteed to be present always. Therefore, a device on the IDB shall be able tocommunicate directly with any other device on the IDB and the vehicle without need for any additi
36、onal device.An application that is implemented across multiple devices may choose to implement a “master controller“ forthat application, but this shall not be a requirement for all applications.4.2.6 AUTOMOTIVE PHYSICAL AND ELECTRICAL SPECIFICATIONSThe IDB physical layer shall meet automotiveenviro
37、nmental (temperature, vibration, shock, EMI, etc.) and electrical specifications (reverse voltage, loaddump, etc.) for the environments in which the devices are installed, e.g., passenger compartment, trunk, etc.NOTEDevices connecting to the IDB will be required to comply with the appropriate regula
38、tory standardsfor product safety, susceptibility, and emissions.4.2.7 EXTENSIBILITYThe IDB shall be extensible to accommodate evolving technologies and new applications. Alayered approach to the protocol is required to guarantee minimum impact on existing designs as newphysical layers and new applic
39、ations are developed.4.2.8 SECURITY AND AUTHENTICATION SERVICESThe IDB protocol shall not directly provide security andauthentication services, but shall not preclude the implementation thereof. It is anticipated that theseservices will be developed as needed to support applications that require the
40、m, including transactions thatrequire billing, authentication, confidentiality, confirmation, non-repudiation, etc.4.2.9 CONFIRMATION OF MESSAGE DELIVERY, IF REQUIREDA device sending a message to another device shall beable to explicitly request confirmation of error-free delivery of that message fr
41、om the receiving device.4.2.10 UNDETECTABLE BIT ERROR RATEThe bit error rate shall be less than 1 x 10-6. Applications requiring betterthan this shall be able to implement appropriate measures at higher layers of the protocol.4.2.11 TIME-CRITICAL DELIVERY OF PACKETS - DETERMINISTIC LATENCYSome appli
42、cations may require thatmessages be transmitted within a given time period. The IDB protocol shall be deterministic, and it shall bepossible to determine the maximum latency for any message in a given system configuration. The maximumlatency in any configuration shall not exceed 40 ms.NOTEThe maximu
43、m latency for a given message is calculated under normal operating conditions, withno transmission errors occurring in that particular message. In other words, transmission errorsin any message should not affect the maximum latency of any other, functionally independentmessage.4.2.12 PRIVATE MESSAGE
44、 SERVICEEquipment manufacturers wish to be able to develop applications that spantheir own suite of products, and provide competitive functions and features not achievable when productsfrom different manufacturers are interconnected. The IDB protocol shall support the implementation ofprivate messag
45、es that will allow such applications to be developed.4.2.13 BUS LOADINGThe IDB shall support from 2 to 16 devices.4.2.14 POWER LOADINGThe IDB gateway shall make power available for all devices connected to the IDB. Thetotal operating current drain of all devices connected to an IDB shall not exceed
46、the capacity of the gateway,unless additional power is routed directly to the device from another source. To guarantee that the vehiclebattery is not depleted when the vehicle ignition is turned off, the total time-averaged quiescent current drainfrom all devices attached the IDB shall not exceed 1
47、mA. Since the IDB can accommodate up to 16 devices,the time-averaged quiescent current drain from a single IDB device over a 24-h period, shall not exceed 60A.SAE J2355 Issued OCT97-6-NOTEThe IDB physical layer provides for power distribution via the gateway. The maximum allowablecurrent through the
48、 gateway is likely to be in the range of 5 A. However, there is no requirementfor IDB devices to derive their power from this source, and power may be derived from anyavailable source, including device batteries. If the IDB device derives its power from the IDBwiring (i.e., the gateway), then it sha
49、ll meet the requirements of this section4.2.15 INTERNETWORKINGIt is anticipated that wireless access to and from the Internet will be required for manydevices attached to the IDB. The IDB protocol shall not preclude the future implementation ofinternetworking services across multiple gateways or bridges between the IDB and other subnets.4.2.16 EXPLICIT DEVICE ADDRESSABILITYIt shall be possible to send a message from a device to a specific otherdevice. It shall be possible for the sender to determine and use the desired recipients unique IDB addre
