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 . 5SAE J2366-4 Issued MAR2002-2-3.22.2 Inactivity Timer, TInactivity 53.22.3 Fr
6、ame 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 Control Frame Elements . 124.4 Frame Grouping, Acknowledgement, and Resynchronization 154.4.1 Frame Grouping 154.4.2 Positive Acknowledgement .164
7、.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, DATAFRAMECONT, DATAFRAMEEND, and DATAFRAMERESYNC Frames . 184.6 Message Data Ordering 194.7 Transport Layer Primitives 194.7.1 Primitives Invoked
8、 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 BrdcastMsgErrCntr . 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 Ele
9、ments 7Figure 4 TTL DATAFRAMESTART Frame Elements 7Figure 5 TTL DATAFRAMECONT Frame Elements 9Figure 6 TTL DATAFRAMEEND Frame Elements10Figure 7 TTL DATAFRAMESINGLE Frame Element . 11Figure 8 TTL DATAFRAMERESYNC Frame Elements .12Figure 9 TTL ACK Frame Elements 13Figure 10 TTL NAK Frame Elements 14T
10、able 1 Frame Types.6Table 2 Transport Error Codes 15Table 3 NAKAddinfo, Additional information for NAKReasonCode. 151. ScopeThis SAE Recommended Practice details the Thin Transport Layer of the Intelligent TransportationSystems (ITS) Data Bus, which is generally intended for in-vehicle use.The Thin
11、Transport Layer sits between SAE J2366-2 and J2366-7. It provides the handling of such activities asthe packetizing of long messages and message reassembly. 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 vi
12、rtual token passing bus, designed to allow disparate consumer,vehicle, and commercial electronic components to communicate and share information across a standard,open data bus.This document describes the Thin Transport Layer of the IDB, as shown in Figure 1.SAE J2366-4 Issued MAR2002-3-FIGURE 1SCOP
13、E OF J2366-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.
14、org.SAE 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 Publicati
15、onsThe 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 d
16、ocuments publication)SAE J2366-1ITS Data BusPhysical LayerSAE J2590PMODE for In-Vehicle NetworksSAE J2366-4 Issued MAR2002-4-2.2.2 ISO P UBLICATIONAvailable from ISOISO 7498:1990Information processing systemsOpen system interconnectBasic reference model3. Definitions3.1 ACKThis term is used to descr
17、ibe a positive acknowledgement or message indicating positiveacknowledgement. An ACK indicates that an amount of information has been verified as correctly received.3.2 AMHIDB Application Message Layer Header.3.3 AMLSAE J2366-7 Application Message Layer.3.4 BitA signaling unit or unit of data transm
18、ission 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 have 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 bi
19、t 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 sequence of up to 16 frames, grouped for purposes of acknowledgement.3.9 IDBThe ITS Data Bus. This document describes the Thin Transport Layer
20、 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 indicatingnegative acknowledgement. A NAK indicates that an amount of information has been detected as incorrectlyreceived.3.12 NodeA Node is
21、 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 usedmicroprocessors, such an 8-bit quantity is commonly referred to as a “byte”. The bits within an octet may besubdivided and/or grouped, to provide s
22、pecific meanings.3.14 OEMOEM is an acronym for Original Equipment Manufacturer. In this document it refers to the manufacturerof a vehicle.3.15 OSIOfficially known as the “ISO Reference Model of Open System Interconnection”. It refers to a model, orway of thinking about communication protocols as be
23、ing 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 theTransport Layer. An example of such an event is the transmission of an “Out Of Band” message from a senderto a receiver during the regula
24、r 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 without being encodedin the header or PDU. 3.17 PDU (Protocol Data Unit)Message packets exchanged between two protocol entities.3.18 Recessive
25、A term defined in CAN 2.0B to indicate a data bit with a value of 1B.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 Contr
26、ol message.3.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
27、is the amount 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
28、 maximum time 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
29、is 500.0 mS.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 th
30、e group). Once 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 rec
31、eiving Node 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 p
32、rovides a packetizing 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 octe
33、ts (211 +4)plus 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
34、2059 in this 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 J23
35、55 Section 4.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
36、 messages, Control 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”.SAE J2366-4 Issued MAR2002-6-On any given Node, there can be no mor
37、e 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 bits that are not explicitly defined by this document, or explicitly referenced to otherdocuments are reserved for future definition by
38、 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 main 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 J
39、2366-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 definitions apply only when that bit is dominant, as specified by SAEJ2366-2. The ID16 bit is not strictly a part of this specification.T
40、able 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 indication 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 Fra
41、me Namerrr TTD DataFrameStartrrd TTD DataFrameContrdr TTD DataFrameEndrdd TTD DataFrameSingledrr TTD DataFrameReSyncdrd TTC ACKddr TTC NAKSAE 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 isma
42、de up of 16 bits, 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 DataFrameS
43、tart Frame ElementsAll 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 ELEMENTSSAE J2366-4 Issued MAR2002-8-4.3.1.1.1 FrameType FieldThis frame has a FrameType of recessive, recessive, recessive.
44、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 to interleave 2 multiframemessages to the same receiving Node, or to insert single frame messages in the middle of a multiframem
45、essage. 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, perhaps much shortermessage, to the same Node.NOTE There is no difference between a standard message and an Out Of Band message,
46、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 combinations of messages between two Nodes are as follo
47、ws: assume Node A is transmittingto Node B:a. Node A sends a multiframe point-to-point message with the OOBMsg flag dominant to Node B, andsends a second point-to-point message to Node B with the OOBMsg flag recessive, while the firstmessage is still in progress.b. Node A sends a multiframe broadcas
48、t message with the OOBMsg flag dominant, and sends a point-to-point message to Node B with the OOBMsg flag recessive, while the first message is still in progress.c. Node A sends a multiframe point-to-point message with the OOBMsg flag dominant to Node B, andsends a broadcast message with the OOBMsg
49、 flag recessive, while the first message is still inprogress.d. Node A sends a multiframe broadcast message with the OOBMsg flag dominant, and sends a secondbroadcast message, with the OOBMsg flag recessive, while the first message is still in progress.When taking advantage of this capability, the sending Node shall ensure that the OOBMsg flags in thetwo messages in progress are different. As described in 4.4, Node A may send a second Out Of Bandmessage while the first message is still in progress,
