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.TO PLACE A DOCUMENT ORDER: +1 (724) 776-4970 FAX: +1 (724) 776-0790SAE WEB ADDRESS http:
3、/www.sae.orgCopyright 2002 Society of Automotive Engineers, Inc.All rights reserved. Printed in U.S.A.SURFACEVEHICLE400 Commonwealth Drive, Warrendale, PA 15096-0001RECOMMENDEDPRACTICEJ2366-4ISSUEDMAR2002Issued 2002-03ITS Data BusThin Transport LayerTABLE OF CONTENTS1. Scope . 22. References . 32.1
4、Applicable Documents 32.1.1 SAE Publications 32.1.2 CAN Publication . 32.2 Related Publications . 32.2.1 SAE Publications 32.2.2 ISO Publication. 43. Definitions. 43.1 ACK 43.2 AMH . 43.3 AML 43.4 Bit . 43.5 Clear. 43.6 Dominant 43.7 Frame . 43.8 Frame Group 43.9 IDB . 43.10 ITS 43.11 NACK or NAK .
5、43.12 Node. 43.13 Octet . 43.14 OEM . 43.15 OSI . 43.16 Out Of Band . 43.17 PDU (Protocol Data Unit) . 43.18 Recessive . 43.19 Set 43.20 TTC 53.21 TTD 53.22 Time Intervals . 53.22.1 Frame Group Acknowledge Timer, TMaxAck . 5Copyright SAE International Provided by IHS under license with SAENot for Re
6、saleNo reproduction or networking permitted without license from IHS-,-SAE J2366-4 Issued MAR2002-2-3.22.2 Inactivity Timer, TInactivity 53.22.3 Frame Group Timer, TFrameGroup54. Protocol Overview .54.1 Basic Concepts.54.2 Frame Format Overview .64.3 Frame Elements .64.3.1 Data Frame Elements.64.3.2
7、 Control Frame Elements . 124.4 Frame Grouping, Acknowledgement, and Resynchronization 154.4.1 Frame Grouping 154.4.2 Positive Acknowledgement .164.4.3 Negative Acknowledgement . 174.4.4 Resynchronization 184.5 Data Frame Type Usage 184.5.1 Use of DATAFRAMESINGLE Frame .184.5.2 Use of DATAFRAMESTART
8、, DATAFRAMECONT, DATAFRAMEEND, and DATAFRAMERESYNC Frames . 184.6 Message Data Ordering 194.7 Transport Layer Primitives 194.7.1 Primitives Invoked by Upper Layers .194.7.2 Primitives Invoked by SAE J2366-4 204.7.3 Primitives Invoked by Lower Layers .214.8 Transport Level Diagnostics . 224.8.1 Brdca
9、stMsgErrCntr . 224.8.2 NAKRcvCntr . 224.8.3 NAKTxCntr 22Figure 1 Scope of SAE J2366-4 .3Figure 2 SAE J2366-4 Frame Formats .6Figure 3 TTL Frame Elements 7Figure 4 TTL DATAFRAMESTART Frame Elements 7Figure 5 TTL DATAFRAMECONT Frame Elements 9Figure 6 TTL DATAFRAMEEND Frame Elements10Figure 7 TTL DATA
10、FRAMESINGLE Frame Element . 11Figure 8 TTL DATAFRAMERESYNC Frame Elements .12Figure 9 TTL ACK Frame Elements 13Figure 10 TTL NAK Frame Elements 14Table 1 Frame Types.6Table 2 Transport Error Codes 15Table 3 NAKAddinfo, Additional information for NAKReasonCode. 151. ScopeThis SAE Recommended Practice
11、 details the Thin Transport Layer of the Intelligent TransportationSystems (ITS) Data Bus, which is generally intended for in-vehicle use.The Thin Transport Layer sits between SAE J2366-2 and J2366-7. It provides the handling of such activities asthe packetizing of long messages and message reassemb
12、ly. Design of the messages and headers hasstressed economy, in terms of bits within a CAN 2.0B frame.The ITS Data Bus (IDB) is a non-proprietary virtual token passing bus, designed to allow disparate consumer,vehicle, and commercial electronic components to communicate and share information across a
13、 standard,open data bus.This document describes the Thin Transport Layer of the IDB, as shown in Figure 1.Copyright SAE International Provided by IHS under license with SAENot for ResaleNo reproduction or networking permitted without license from IHS-,-SAE J2366-4 Issued MAR2002-3-FIGURE 1SCOPE OF J
14、2366-42. References2.1 Applicable PublicationsThe following publications form a part of this specification to the extent specifiedherein. The latest issue of SAE publications shall apply.2.1.1 SAE PUBLICATIONSAvailable from SAE, 400 Commonwealth Drive, Warrendale, PA 15096-0001, http:/www.sae.org.SA
15、E J2355ITS Data Bus Architecture Reference Model Information ReportSAE J2366-2ITS Data BusLink LayerSAE J2366-7ITS Data BusApplication Message Layer2.1.2 CAN PUBLICATIONAvailable from Robert Bosch GmbH, Postfach 50, D-7000 Stuttgart 1, GermanyCAN Specification, Version 2.02.2 Related PublicationsThe
16、 following publications are provided for information purposes only and are not arequired part of this document.2.2.1 SAE PUBLICATIONSAvailable from SAE, 400 Commonwealth Drive, Warrendale, PA 15096-0001, http:/www.sae.org.SAE J1760IDB Data Security Services (Under Development at time of this documen
17、ts publication)SAE J2366-1ITS Data BusPhysical LayerSAE J2590PMODE for In-Vehicle NetworksCopyright SAE International Provided by IHS under license with SAENot for ResaleNo reproduction or networking permitted without license from IHS-,-SAE J2366-4 Issued MAR2002-4-2.2.2 ISO P UBLICATIONAvailable fr
18、om ISOISO 7498:1990Information processing systemsOpen system interconnectBasic reference model3. Definitions3.1 ACKThis term is used to describe a positive acknowledgement or message indicating positiveacknowledgement. An ACK indicates that an amount of information has been verified as correctly rec
19、eived.3.2 AMHIDB Application Message Layer Header.3.3 AMLSAE J2366-7 Application Message Layer.3.4 BitA signaling unit or unit of data transmission of minimal length. It can hold either the value 0B or 1B.3.5 ClearThe word “clear” is used in referring to one or more bits to indicate that they each h
20、ave a value of 0B.This is also referred to as “dominant” in CAN 2.0B terminology.3.6 DominantA term defined in CAN 2.0B to indicate a data bit with a value of 0B.3.7 FrameAn ordered sequence of bits, used to communicate information between the Transport Layers of IDBNodes.3.8 Frame GroupAn ordered s
21、equence of up to 16 frames, grouped for purposes of acknowledgement.3.9 IDBThe ITS Data Bus. This document describes the Thin Transport Layer protocol for the IDB.3.10 ITS Intelligent Transportation Systems3.11 NACK or NAKThis term is generally used to describe a negative acknowledgement or message
22、indicatingnegative acknowledgement. A NAK indicates that an amount of information has been detected as incorrectlyreceived.3.12 NodeA Node is a device on the IDB with at least one physical Node ID. 3.13 OctetAn octet is a unit of data transmission that consists of 8 bits. On most commonly usedmicrop
23、rocessors, such an 8-bit quantity is commonly referred to as a “byte”. The bits within an octet may besubdivided and/or grouped, to provide specific meanings.3.14 OEMOEM is an acronym for Original Equipment Manufacturer. In this document it refers to the manufacturerof a vehicle.3.15 OSIOfficially k
24、nown as the “ISO Reference Model of Open System Interconnection”. It refers to a model, orway of thinking about communication protocols as being divided into (usually) seven distinct layers.3.16 Out Of BandThis term refers to a data transfer event that is occurring outside of the normal operation of
25、 theTransport Layer. An example of such an event is the transmission of an “Out Of Band” message from a senderto a receiver during the regular transmission of a standard message from the same sender to the samereceiver. It is also used to describe information that is passed between protocol layers w
26、ithout being encodedin the header or PDU. 3.17 PDU (Protocol Data Unit)Message packets exchanged between two protocol entities.3.18 RecessiveA term defined in CAN 2.0B to indicate a data bit with a value of 1B.Copyright SAE International Provided by IHS under license with SAENot for ResaleNo reprodu
27、ction or networking permitted without license from IHS-,-SAE J2366-4 Issued MAR2002-5-3.19 SetThe word “set” is used in referring to one or more bits to indicate that they each have a value of 1B. Thisis also referred to as “recessive” in CAN 2.0B terminology.3.20 TTCThin Transport Control message.3
28、.21 TTDThin Transport Data message.3.22 Time IntervalsSeveral critical time intervals are specified for the IDB SAE J2366-4 Protocol. Unlessotherwise noted, time intervals are significant to the nearest 0.1 mS. Each is defined as follows.3.22.1 FRAME GROUP ACKNOWLEDGE TIMER, TMAXACKThis is the amoun
29、t of time a sender shall wait for anacknowledgement of a point-to-point Frame Group from a receiver. The duration of this timer is 150.0 mS.Any acknowledgements (positive or negative) received after this timer has expired shall be discarded.3.22.2 INACTIVITY TIMER, TINACTIVITYThis is the maximum tim
30、e that is allowed to elapse between frame groups of amessage. Once the end of a frame group has been received that does not also end the message, no morethan TInactivity may elapse before the first frame of the next frame group of that same message is received.The duration of this timer is 500.0 mS.
31、If the time is exceeded, the receiving Node shall flush the incoming message from its buffers and queue aNAK frame for the message - see Table 1.3.22.3 FRAME GROUP T IMER, T FRAMEGROUPThis is the maximum time allowed to elapse for any given frame groupto arrive (first to last frame of the group). On
32、ce the first frame of a group is received, no more thanTFrameGroup may elapse before the last frame of that same frame group is received. (The end of the framegroup may or may not be the end of the complete message.) The duration of this timer is 500.0 mS.If the time is exceeded, the receiving Node
33、shall flush the incoming message from its buffers and queue aNAK frame for the message - see Table 1.4. Protocol OverviewThis protocol is designed to meet the varied and challenging requirements for in-vehicledata communications. Some noteworthy features of the protocol:a. The protocol provides a pa
34、cketizing and reliability layer, intended to sit between a Link Layer (e.g.,SAE J2366-2) and an Application Layer (e.g., SAE J2366-7).b. The protocol follows the OSI protocol layering concepts.c. It provides the capability to transmit an Application Layer PDU “payload” of up to 2051 octets (211 +4)p
35、lus 8 octets of Application header information, handling fragmentation required by a Link Layer andreassembly at the destination. NOTE Since a DataFrameStart Frame can specify a range of 2 to 255 frames, the maximum SAE J2366-4payload is actually 254*9+8=2294 octets. It is restricted to 2059 in this
36、 version since this is themaximum SAE J2366-7 message size.d. Each Node should provide a buffer to receive at least a 1 KB message from other Nodes.4.1 Basic ConceptsOne of the fundamental requirements is to make IDB-compliant devices and software “.easy to design and implement” (SAE J2355 Section 4
37、.1.2). Every attempt has been made to keep the basicconcepts encapsulated in this design simple. This simple design will allow for all of the Goals and Functionalrequirements (from the Applications perspective), as stated in SAE J2355, to be met.There are two primary types of SAE J2366-4 messages, C
38、ontrol and Data. Control messages provide thecapability of Positive Acknowledgement (ACK) and Negative Acknowledgement (NAK) to re-synchronize. Datamessages generally contain upper layer (e.g., SAE J2366-7) PDU “payload”.Copyright SAE International Provided by IHS under license with SAENot for Resal
39、eNo reproduction or networking permitted without license from IHS-,-SAE J2366-4 Issued MAR2002-6-On any given Node, there can be no more than one IDB SAE J2366-4 Transport Layer. However, other layersmay be specified for interface directly with SAE J2366-2, per its documentation.All field values or
40、bits that are not explicitly defined by this document, or explicitly referenced to otherdocuments are reserved for future definition by a later version of SAE J2366-4. They are not available forarbitrary use by specific implementations.4.2 Frame Format OverviewFigure 2 shows the formats of the two m
41、ain types of SAE J2366-4 frame. SomeTTL frames provide up to 64 bits of data, while others provide up to 72 bits of data. FIGURE 2SAE J2366-4 FRAME FORMATS4.3 Frame ElementsNOTE The TTL Frame diagrams in the following sections show bit ID16, the SAE J2366-2 ATID bit, as areminder that these frame de
42、finitions apply only when that bit is dominant, as specified by SAEJ2366-2. The ID16 bit is not strictly a part of this specification.Table 1 describes each of the Frame Types used by SAE J2366-4. Each FrameType value is given, along withthe name of the Frame to which it corresponds and an indicatio
43、n as to whether the frame is a TTD or a TTCtype.The basic TTL Frame format is shown in Figure 3.TABLE 1FRAME TYPESFrameType TTD/TTC Frame Namerrr TTD DataFrameStartrrd TTD DataFrameContrdr TTD DataFrameEndrdd TTD DataFrameSingledrr TTD DataFrameReSyncdrd TTC ACKddr TTC NAKCopyright SAE International
44、 Provided by IHS under license with SAENot for ResaleNo reproduction or networking permitted without license from IHS-,-SAE J2366-4 Issued MAR2002-7-FIGURE 3TTL FRAME ELEMENTS4.3.1 DATA FRAME E LEMENTSThere are five types of SAE J2366-4 Data Frame (TTD). Each has a header that ismade up of 16 bits,
45、divided among several elements. The first element is always a 3bit FrameType field, asdefined in Table 1. Following the FrameType, a TTD contains header elements defined by the FrameType.Succeeding paragraphs in this section detail each of the TTD header elements.4.3.1.1 DataFrameStart Frame Element
46、sAll SAE J2366-4 messages longer than 9 octets shall begin with aDATAFRAMESTART frame. This frame type is shown in Figure 4. FIGURE 4TTL DATAFRAMESTART FRAME ELEMENTSCopyright SAE International Provided by IHS under license with SAENot for ResaleNo reproduction or networking permitted without licens
47、e from IHS-,-SAE J2366-4 Issued MAR2002-8-4.3.1.1.1 FrameType FieldThis frame has a FrameType of recessive, recessive, recessive.4.3.1.1.2 OOBMsg FieldThis field identifies whether this frame belongs to a standard message (dominant) orto an Out Of Band Message (recessive). This field allows a sender
48、 to interleave 2 multiframemessages to the same receiving Node, or to insert single frame messages in the middle of a multiframemessage. This is desirable in cases where a physical Node is in the middle of transmitting a longmultiframe message to another Node, and is required to send an additional,
49、perhaps much shortermessage, to the same Node.NOTE There is no difference between a standard message and an Out Of Band message, other thanthe nomenclature, which is used to differentiate between normal message transmission andthe case when it is necessary for one Node to send a message to another Node while anothermessage is being transmitted to that same Node.The valid com
