ISO/TC22/SC3/WG1/TF2 N 124 Date: 1998-06-24 ISO/WD 15765-2 ISO/TC 22/SC 3/WG 1 Secretariat: SMS, issue 0.7 Road Vehicle – Diagnostic systems – Diagnostics on CAN – Part 2: Network layer services Document type: International Standard Document subtype: Not applicable Document stage: (20) Preparatory Document language: E ISOSTD ISO Template Version 3.0 1997-02-07 Page: 1 of 30 ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - Network Layer Contents 1. SCOPE.....................................................................................................................................................................5 2. NORMATIVE REFERENCE(S) ..........................................................................................................................5 2.1 ISO PUBLICATIONS .............................................................................................................................................5 3. TERM(S) AND DEFINITION(S)..........................................................................................................................6 4. SYMBOLS (AND ABBREVIATED TERMS) .....................................................................................................6 5. OPEN SYSTEMS INTERCONNECTION (OSI) STANDARD REFERENCE MODEL................................7 6. SPECIFICATION SCOPE ....................................................................................................................................8 7. NETWORK LAYER..............................................................................................................................................9 7.1 OVERVIEW ..........................................................................................................................................................9 7.2 PROTOCOL LAYER SERVICES .............................................................................................................................10 7.2.1 Unacknowledged and Segmented data transfer........................................................................................10 7.2.2 Segmented message reception in progress ...............................................................................................11 7.2.3 Network layer error indication .................................................................................................................11 7.2.4 Change protocol parameters ....................................................................................................................12 7.3 PROTOCOL LAYER ENTITY .................................................................................................................................13 7.3.1 Addressing scheme....................................................................................................................................13 7.3.2 Protocol Data unit (PDU) ........................................................................................................................13 7.3.3 Protocol Control Information (PCI).........................................................................................................15 7.4 PROTOCOL LAYER TIMINGS AND ASSOCIATED ACTIONS .....................................................................................19 7.4.1 Monitored time interval (error detection).................................................................................................19 7.4.2 Consecutive frame (CF) transmission time...............................................................................................21 7.4.3 Wait frame (FC.WT) transmission time ...................................................................................................23 7.5 INTERLEAVING OF MESSAGES ............................................................................................................................24 7.6 DATA LINK LAYER INTERFACE...........................................................................................................................25 7.6.1 Services.....................................................................................................................................................25 7.6.2 CAN bus frame definition .........................................................................................................................26 7.6.3 Mapping of D_UUData.req onto L_Data.request service primitive ........................................................27 7.6.4 Mapping of L_Data.indication onto D_UUData.ind service primitive ....................................................28 8. DRAFT HISTORY...............................................................................................................................................29 9. ANNEXE ...............................................................................................................................................................30 9.1 TIME-OUT VALUES SETTING REQUIREMENTS .....................................................................................................30 Page: 2 of 30 ISO / WD 15765 - 2 : Diagnostics Systems - Network Layer Foreword ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization. International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3. Draft International Standards adopted by the technical committees are circulated to the member bodies for voting. Publication as an International Standard requires approval by at least 75 % of the member bodies casting a vote. International Standard ISO 15765 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3, Electrical and electronic equipment. ISO 15765 consists of the following parts, under the general title Road vehicles – Diagnostic systems – Diagnostics on CAN: — — — — — Part 1: Application layer and session layer services Part 2: Network layer services Part 3: Application layer services for enhanced diagnostics - Keyword Protocol 2000 Part 4: Requirements for emission-related systems Part 5: Requirements for truck & bus systems Annex X forms an integral part of this part of ISO 15765. Annex X of this part of ISO 15765 is given for information only. 1 Introduction ISO 15765 has been established in order to define common requirements for vehicle diagnostic systems implemented on a Controller Area Network (CAN) communication link as specified in ISO 11898 Road vehicles - Interchange of digital information - Controller area network (CAN) for high-speed communication and ISO 11519-2 Road vehicles - Low-speed serial data communication - Part 2 : Lowspeed controller area network (CAN). Although primarily intended for diagnostic systems, ISO 15765 has been developed to also meet requirements from other CAN based systems needing a network layer protocol. To achieve this, it is based on the Open Systems Interconnection (OSI) Basic Reference Model in accordance with ISO/IEC 7498 and ISO/IEC 10731 which structures communication systems into seven layers. When mapped on this model, the services specified by ISO 15765 are broken into: — diagnostic services (layer 7), — session layer services (layer 5) — network layer services (layers 3), — Controller Area Network (CAN) services (layers 1 and 2), in accordance with the table below. Page: 3 of 30 ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - Network Layer Table 1 — Applicability and relationship between international standards Applicability Vehicle manufacturer enhanced diagnostics Emission-related diagnostics Commercial vehicle diagnostics User defined ISO 15765-4 ISO 15765-5 ISO 15765-1, ISO 15765-4 ISO 15765-1, ISO 15765-5 Presentation layer Seven layers according to ISO 15765-1 ISO/IEC 7498 and Session layer ISO/IEC 10731 Transport layer ISO 15765-1, ISO 15765-4 ISO 15765-1, ISO 15765-5 Network layer ISO 15765-2 ISO 15765-2, ISO 15765-4 ISO 15765-2, ISO 15765-5 Data link layer ISO 11898, ISO 11519-2 ISO 11898, ISO 15765-4 ISO 11898, ISO 15765-5 Physical layer User defined ISO 11898, ISO 15765-4 User defined Diagnostic application User defined Application layer ISO 15765-1, ISO 15765-3 The application and session layer services have been defined in compliance with diagnostic services defined in ISO 14230-3 Road vehicles - Diagnostic systems - Keyword Protocol 2000 - Part 3: Application layer and ISO 15031-5 Road vehicles - Emission-related diagnostics - Communication between vehicle and external equipment - Part 5: Emissions related diagnostic services, but are not limited to be used only with these international standards. ISO 15765-1 will also be compatible with most diagnostic services defined in national standards or in vehicle manufacturer specifications. The network layer services have been defined to be independent of the physical layer implemented. A physical layer is only defined for emission-related systems. For other application areas, ISO 15765 can be used with any Controller Area Network (CAN) physical layer. Page: 4 of 30 ISO / WD 15765 - 2 : Diagnostics Systems - Network Layer Road Vehicle – Diagnostic systems – Diagnostics on CAN – Part 2: Network layer services 1. Scope International Standards ISO 15765 is applicable to vehicle diagnostic systems implemented on a Controller Area Network (CAN) communication network as specified in ISO 11898 or ISO 11519-2. Part 1: Application layer and session layer services, of ISO 15765, specifies diagnostic services specially tailored to meet the requirements of CAN based vehicle network systems. It has been defined in compliance with diagnostic services defined in ISO 14230-3 and ISO 15031-5, but is not limited to be used only with these international standards. ISO 15765-1 will be compatible also with most diagnostic services defined in national standards or in vehicle manufacturer specifications. ISO 15765-1 defines diagnostic services which in some cases already are defined in other International Standards. This is done when there are specific requirements for CAN based systems, and if so, the definitions in this International Standards shall be used. The application layer services establish means for controlling and retrieving information about the CAN network system. The session layer services gives guidelines and definitions on how to implement a safe, secure and powerful vehicle diagnostic system compatible with most vehicle manufacturer specific specifications for normal application communication. 2. Normative reference(s) The following standards contain provisions which, through reference in this text, constitute provisions of this International Standard. At the time of the publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on the International Standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. Members of IEC and ISO maintain registers of currently valid International Standards. 2.1 ISO Publications ISO 7498: ISO/DIS 11898:1993/Amd.1: ISO/DIS 14229: ISO/DIS 14230-3: ISO/WD 15031-3: ISO/WD 15765-1: ISO/WD 15765-3: ISO/WD 15765-4: Data Processing Systems, Open Systems Interconnection (OSI) Standard Reference Model (OSI Model) 1995(E) - Road vehicles, Interchange of Digital Information, Controller Area Network (CAN) for High Speed Communication 1996, Road vehicles - Diagnostic Systems - Diagnostic services specification. 1996, Road vehicles - Diagnostic Systems - Keyword Protocol 2000 Part 3: Implementation. OBD Connector Road Vehicles - Diagnostic Systems - Communication services Road Vehicles - Diagnostic Systems - Enhanced Diagnostic Services Road Vehicles - Diagnostic Systems - Requirements for Emission Related Systems definition Page: 5 of 30 ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - Network Layer 3. Term(s) and definition(s) 4. Symbols (and abbreviated terms) ADDR BSmax CAN CF CTS DL ECU FC FF FFL FS OSI PCI RBD Rx SF SN STmin Tx USDT WFTmax WT XDL Address information BlockSize (maximum) Controller Area Network ConsecutiveFrame ClearToSend DataLength Engine Control Unit FlowControl FirstFrame Fixed Frame Length FlowStatus Open System Interconect Protocol Control Information ReservedByDocument Receiver SingleFrame SequenceNumber SeparationTime (minimum) Transmitter Unacknowledged Segmented Data Transfer WaitFrameTransmission(s) (maximum) WaiT eXtendedDataLength Page: 6 of 30 ISO / WD 15765 - 2 : Diagnostics Systems - Network Layer 5. Open Systems Interconnection (OSI) Standard Reference Model The ISO Reference Model for Open System Interconnection (OSI) provides a common basis for the structuring of the communication software to provide reliable, data independent, communication services and to support a wide range of applications. The ISO/OSI Reference Model describes “Services and Protocols” without making assumptions concerning the: • Programming language bindings • Operating systems bindings • Application and user interfaces issues This standard specifies layer three (3) “Network Layer” of the OSI Model by providing scaleable and network-dependent means to support information exchange between equipment. Application Layer Encapsulation Presentation Layer Receiving Task Application Protocol Presentation Protocol Session Layer Session Protocol Transport Layer Transport Protocol TH Network Layer Network Protocol NH Data Link Layer Physical Layer PH SH Data Application Layer Data Presentation Layer Session Layer Data Transport Layer Data Network Layer Data DH Data DT Data Link Layer Physical Layer Bit Stream Actual Data Transmission Path AH SH NH DT Application Header Session Header Network Header Data Link Trailer PH TH DH Presentation Header Transport Header Data Link Header Figure 1: Open Systems Interconnection (OSI) Standard Reference Model (OSI Model) Page: 7 of 30 Decapsulation Sending Task ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - Network Layer 6. Specification scope The figure below depicts elements defined in this document : Protocol layer N+1 Protocol layer N+1 Interface services (2) (1) … Protocol layer entity N (4) PDU (3) Protocol layer N Interface services (5) Protocol layer N-1 Protocol layer N-1 Figure 2 : Detailed protocol layer model Element (1) : ISO 15765-2 defines the communication protocol that enables data exchange between equipments (ECU - ECU and ECU - Tester). Element (2) : Interface services (Layer N) defines the protocol layer interface services used to enable transfer of data. This section defines both services and parameters without hinting at any particular implementation scheme. Element (3) : Protocol Data Units defines the format of protocol data exchanged between the protocol entity of that layer and its corresponding peer protocol entity. Element (4) : Protocol Entity defines the data communication protocol, i.e. a set of rules known in a communication system, to enable consistent data exchange. Element (5) : Interface services (Layer N-1) defines the interface services of the underlying protocol layer used to enable transfer of data. This section defines both services and parameters without hinting at any particular implementation scheme. Page: 8 of 30 ISO / WD 15765 - 2 : Diagnostics Systems - Network Layer 7. Network layer 7.1 Overview The purpose of the network layer is to support the transfer of messages that may fit or not in a single CAN bus frame. Messages that do not fit in a single frame are transmitted in a way that is compatible with the operating capability of the receiver peer. The following pictures illustrate this concept. Frame format of UNSEGMENTED messages : An unsegmented message is transmitted within a single frame containing a complete request or response message of a diagnostic service. Sender Receiver DataLength = 2, DL=$2; SingleFra me(SF)[(P CI.DL=2,x x.. ] DataLength = 2 DL=$2 Figure 3: Example of UNSEGMENTED message Frame format of SEGMENTED messages : A segmented message is transmitted within a set of frames containing a complete (request or) response message of a diagnostic service. Sender Receiver FirstFrame(F F)[(PCI.XDL =$0, DL=$24 ,xx.. ] xx..] 3,FC.STmin, FC.BSmax=$ C)[ PCI.FS, FlowControl(F Multiple consecutive frames DataLength = 36 XDL = $0, DL=$24 Flow Control frame with implicit connection set-up Consecutive Frame(CF)[(P CI.SN=1,xx,x x,.. ] Consecutive Frame(CF)[(P CI.SN=2,xx,x x,.. ] Consecutive Frame(CF)[(P CI.SN=3,xx,x x,.. ] .STmin] FC.BSmax,FC C)[ PCI.FS, FlowControl(F The last consecutive frame include 2 valid user data bytes FlowControl frame because SN=BSmax Consecutive Frame(CF)[(P CI.SN=4,xx,x x,.. ] Consecutive Frame(CF)[(P CI.SN=5,xx,x x,.. ] End of multiple frame Figure 4: Example of SEGMENTED message Page: 9 of 30 ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - Network Layer 7.2 Protocol layer services This service specification does not specify any implementation requirements but provides abstract services prototypes to support data exchange. 7.2.1 Unacknowledged and Segmented data transfer Service name : N_USData Syntax : internal service Request : N_USData.req(<AI>, <AF>, <MessageData>, <Length>) Confirmation : N_USData.con(<Result>) Indication : N_USData.ind(<AI>, <AF>, <MessageData>, <Length>, <Result>) Parameter : AI : AS : MessageData : Length : Result : Description : Addressing Information, e.g. diagnostics target and source addresses. Addressing format, e.g. OBD, Trailer diagnostics, enhanced. Message data to be transferred Length of <MessageData> parameter (bytes) Result of the requested and indicated service The service primitive N_USData.req requests transmission of data <MessageData> having a length <Length> to the recipient(s) identified by the target address encapsulated in <AI>. The service primitive N_USData.con confirms the completion of its corresponding N_USData.req service. The parameter <Result> provides the status of the completed N_USData.req service. The service primitive N_USData.ind indicates to the adjacent upper layer availability of a received message from a sender identified by the source address encapsulated in <AI>. Results : E_NWL_OK : successful service completion Page: 10 of 30 ISO / WD 15765 - 2 : Diagnostics Systems - Network Layer 7.2.2 Segmented message reception in progress Service name : N_USData_FF Syntax : internal service Indication : N_USData_FF.ind(<AI>, <AF>, <Result>) Parameter : AI : AF : Result : Addressing Information, e.g. diagnostics target and source addresses. Addressing format, e.g. OBD, Trailer diagnostics, enhanced. Result of the indicated service Description : The service primitive N_USData_FF.ind indicates the arrival of a segmented message to the upper adjacent layer. This indication shall take place upon reception of a First Frame PDU. Results : E_NWL_OK : successful reception of a first frame. 7.2.3 Network layer error indication Service name: N_Error.ind Syntax: internal service Indication : N_Error.ind(<ErrorStatus>) Parameter : ErrorStatus : Error type. Description: The service primitive N_Error.ind indicates to the adjacent upper layer that an error has occurred. Results E_NWL_OK : E_NWL_TOUT_A : E_NWL_TOUT_B1: E_NWL_TOUT_B2 : E_NWL_TOUT_C : E_NWL_WRG_SN : successful service completion. Time-out A has occurred. Timeout B1 has occurred Timeout B2 has occurred Timeout C has occurred Received sequence number value SN is not consistent with internally made calculation of the receiver. E_NWL_UNEXP_FRM: Unexpected reception of a protocol data unit (PDU) that violates protocol rules. E_NWL_WFT_OVRN : Received number of flow control frames with wait state FC.WAIT exceeds maximum counter WFTmax. Page: 11 of 30 ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - Network Layer 7.2.4 Change protocol parameters Service name: N_ChangeProtocolParams Syntax: internal service Request: N_ChangeProtocolParams.req(<Parameter>, <Value>) Confirmation: N_ChangeProtocolParams.con(<Parameter>, <Result>) Parameter : ParameterName : Identifies the protocol parameter to be changed : • BS • ST Value : New value requested for the parameter Result : Result of the requested service Description: The service primitive N_ChangeprotocolParams.req is used to request the change of an internal parameter’s value as required by <Parameter>. If a reception or transmission is going on by request’s time, then the change is not allowed. - reception : a change is possible before transmission of the first FC and after reception of the last CF of a segmented message. - transmission : a change is possible before transmission of FF, and after transmission of the last CF. Network Layer on tester Change is possible Change is not allowed Change is possible Results E_NWL_OK : E_NWL_TX_ON : E_NWL_RX_ON : E_NWL_WRG_PARAM: E_NWL_WRG_VALUE : Subnet1 Network Layer on UCEs Change is possible Change is not allowed Change is possible successful service completion. non-permitted service execution, transmission taking place. non-permitted service execution, reception taking place. non-permitted service execution ,<Parameter> undefined. non-permitted service execution,<Value> out of range. Page: 12 of 30 ISO / WD 15765 - 2 : Diagnostics Systems - Network Layer 7.3 Protocol layer entity 7.3.1 Addressing scheme The protocol layer supports two address field lengths to transmit addressing information. The number of data bytes transported within a single bus frame is set given the type of addressing scheme chosen. The following schemes are defined : NORMAL addressing scheme : Addressing field : The CAN bus identifier field is provided to encapsulate the diagnostic application addresses. The addressing information (e.g. source address, target address) shall be fitted within the CAN frame identifier. Data field : 8 data byte per bus frame EXTENDED addressing scheme : Addressing field : st The CAN bus identifier and 1 data byte of the CAN data field are provided to encapsulate the diagnostic application addresses. The addressing information (source address, target address) shall st be fitted within both the CAN frame identifier and the 1 byte of the CAN bus data field as defined in the respective diagnostic ISO 15765 specifications, e.g. ISO15765-4 : OBD. Data field : 7 data byte per bus frame 7.3.2 Protocol Data unit (PDU) Purpose : The protocol data unit (PDU) enables the transfer of data between peer protocol entities. A PDUs consists of various fields whose intents are known to each peer protocol entities. Those fields enables each protocol entity to act in conformance with a set of communication rules as defined in this document. Description : The PDU consists of the following fields : Addressing information Protocol Control Information Data Figure 5 - PDU format 1) Addressing information (AI) : Purpose : This field contains addressing data that identify recipient(s) and sender between which data exchange takes place. The addressing information consists of the diagnostic target and source addresses. Size : NORMAL addressing scheme EXTENDED addressing scheme : CAN identifier field length st : CAN identifier field length + 1 data byte of data field frame. 2) Protocol Control Information (PCI) : Purpose : This field identifies the type of PDU’s exchanged. This enables a receiving protocol entity to select the appropriate protocol rule set to carry out the data transfer. Possible parameters can be associated with the PCI, i.e. BSmax, STmin, DL. The PCI identifies the following PDU’s : Page: 13 of 30 ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - Network Layer Table 1 - PCI type PCI type First Frame (FF) Consecutive Frame (CF) Flow Control frame (FC) Single Frame (SF) Description first frame of a segmented message frame that transports data only. frame that controls the arrival of consecutive frames (CF) blocks. frame that transports data which fit into a single bus frame. Size : 1 byte 3) Message data : Purpose : This field contains data to be exchanged and protocol control information parameters as applicable. Size : Table 2 - PDU data field length PCI type Length of PDU’s data field Normal addressing Extended addressing First Frame (FF) 7 bytes Flow Control frame (FC) 6 bytes 2 bytes Consecutive Frame (CF) 7 bytes 6 bytes Exception : The length of the data field of the last CF of a message depends on the message length Single Frame (SF) 1 to 7 bytes Page: 14 of 30 1 to 6 bytes ISO / WD 15765 - 2 : Diagnostics Systems - Network Layer 7.3.3 Protocol Control Information (PCI) Each PDU is encoded for identification by means of a PCI as defined below : Table 3: Encoding of Protocol Control Information (PCI) USDT PCI encoding PCI name PCI byte Mnemonic 7 6 5 4 SF 0 0 0 0 DL FirstFrame FF 0 0 0 1 XDL ConsecutiveFrame CF 0 0 1 0 SN Flow Control frame FC 0 0 1 1 FS SingleFrame ReservedByDocument RBD 3 2 1 $40 through $FF 7.3.3.1 SingleFrame (SF) For unsegmented message, the USDT protocol provides an optimised implementation of the network protocol with the message length embedded in the PCI byte only. 7.3.3.1.1 SF.DataLength (DL) Table 4: USDT Protocol Control Information (PCI) : SF.DL USDT PCI encoding PCI name PCI byte Mnemonic 7 6 5 4 SF 0 0 0 0 SingleFrame 3 data bytes 2 1 0 +1 … +6/7 xx … xx DL DataLength (DL) defined in a SingleFrame (SF) shall be encoded out of the PCI low nibble value. The PCI byte is not included in the data length calculation. The bit “3” shall always be set to zero (0) since CAN frames allow for a maximum of eight (8) data bytes (PCI byte included). 7.3.3.2 FirstFrame (FF) For segmented message, the first frame is encoded as a FirstFrame (FF). On receipt of a FirstFrame (FF) PDU the receiving network layer entity shall start to assemble the segmented message. 7.3.3.2.1 FF.EXtendedDataLength (XDL) Table 5: USDT Protocol Control Information (PCI) : FF.XDL USDT PCI encoding PCI byte PCI name Mnemonic 7 6 5 4 FirstFrame FF 0 0 0 1 3 data bytes 2 1 XDL 0 +1 +2 … +6/7 DL xx … xx The eXtendedDataLength (XDL) shall be encoded out of the data byte #1 which follows the PCI byte and the PCI low nibble value. This results into a twelve (12) bit eXtendedDataLength (XDL) value where the least significant bit (LSB) is specified to be bit “0” of the data byte #1 and the most significant bit (MSB) is bit “3” of the PCI byte. The eXtendedDataLength (XDL) can specify a maximum of four thousand and ninety five (4095) bytes of user data. The PCI byte is not included in the data length calculation. 7.3.3.2.2 FF.DataLength (DL) Page: 15 of 30 0 ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - Network Layer Table 6: USDT Protocol Control Information (PCI) : FF.DL USDT PCI encoding PCI byte PCI name Mnemonic 7 6 5 4 FirstFrame FF 0 0 0 1 3 data bytes 2 1 0 XDL +1 +2 … +6/7 DL xx … xx This field encodes the lower eight bits of the message data length. This field needs to be interpreted along with XDL for the receiver to determine the message length. 7.3.3.3 FlowControl frame (FC) The purpose of FlowControl (FC) is to prevent a sender node to overpower a receiver node. FlowControl (FC) frame shall be sent to the sender peer after correct reception of a) a FirstFrame (FF) and b) the last ConsecutiveFrame (CF) of a block of frame provided that further ConsecutiveFrame (CF) need(s) to be sent in a new block. 7.3.3.3.1.1 FC.FlowStatus (FS) Table 7: Definition of Protocol Control Information (PCI) : FC.FS USDT PCI encoding PCI name PCI byte Mnemonic 7 6 5 4 FC 0 0 1 1 FlowControl frame 3 data bytes 2 1 0 FS +1 +2 +3 … +6/7 BSmax STmin N/A The FlowStatus (FS) indicates to the sender whether it can proceed the message transmission. The flow status (FS) shall be encoded in the low nibble of the PCI byte of the FlowControl (FC) frame. The FlowStatus (FS) network protocol parameter is defined as follows : Table 8: Protocol Control Information (PCI) : FC.FS PCI FlowStatus (FS) lower nibble 3 2 1 0 0 0 0 0 Description of FlowStatus (FS) network protocol information ClearToSend (CTS) This parameter value is sent to the sender to resume message transmission. Flow control parameters (BSmax, STmin) shall be taken into account by the sender only upon reception of the FlowControl.ClearToSend (FC.CTS) frame that follows the FirstFrame (FF). 0 0 0 1 WaiT (WT) This parameter value is sent by the receiver during the reception of a multiple frame message to inform the sender to not resume transmission and wait for an FC.CTS. 7.3.3.3.1.1.1 FC.BlockSize (BSmax) Table 9: Definition of Protocol Control Information (PCI) : FC.BS USDT PCI encoding PCI name FlowControl frame PCI byte Mnemonic 7 6 5 4 FC 0 0 1 1 3 Page: 16 of 30 data bytes 2 1 FS 0 +1 +2 +3 … +6/7 BSmax STmin N/A ISO / WD 15765 - 2 : Diagnostics Systems - Network Layer The network protocol BlockSize (BS) parameter is used to request a data transfer in which a block of BlockSize (BS) Consecutive Frames (CF) can be sent without intermediate flow control frame (FC) from the receiving network entity. The BlockSize (BS) parameter shall be within the range of zero (0) to two hundred fifty five (255). Table 10: Definition of BlockSize (BS) BlockSize (BS) Description 0 If the BlockSize (BSmax) parameter value in the FlowControl (FC) frame (FC.BSmax) is set to zero (0) by the receiver no further flow control shall be performed during the transmission of ConsecutiveFrame(s) (CF). Only one (1) FlowControl (FC) frame is sent after the FirstFrame (FF) to inform the sender on how to proceed. 1 ≤ BlockSize (BS) ≤ 255 If the BlockSize (BSmax) parameter value in the FlowControl (FC) frame (FC.BSmax) is set to a value within the range of one (1) to two hundred fifty five (255) by the receiver then flow control shall be performed accordingly. 7.3.3.3.1.1.2 SeparationTime (STmin) Table 11: Definition of FlowStatus (FS) in the PCI byte USDT PCI encoding PCI name FlowControl frame PCI byte Mnemonic 7 6 5 4 FC 0 0 1 1 3 data bytes 2 1 FS 0 +1 +2 +3 … +6/7 BSmax STmin N/A The minimum SeparationTime (STmin) specifies the minimum time gap between the transmission of ConsecutiveFrames (CF). This time is specified by the receiver and kept by the sender for a particular message transmission. 7.3.3.3.1.1.3 Maximum number of FC.Wait frame transmissions (FC.WFTmax) This variable is defined at system generation time and indicates how many wait frames (FC.WT) can be consecutively transmitted. Note: This parameter is local to communication peers and is not transmitted hence not part of the FlowControl (FC) frame. The purpose of this variable is to avoid communication sender nodes being potentially hooked-up in case of a fault condition whereby the latter would be requested to wait continuously. Table 12: Definition of maximum number of FlowControl.WaitFrameTransmissions (FC.WFTmax) 1 ≤ FC.WFTmax ≤ 15 FC.WFTmax = 0 Flow control relies upon FC.CTS only. Wait flow control frame not supported. Maximum number of consecutive wait FC frame to be sent for a given segmented message. 7.3.3.4 ConsecutiveFrame (CF) When sending segmented data, all consecutive frames following the first frame (FF) are encoded as Consecutive Frames (CF). On receipt of a ConsecutiveFrame (CF) the receiving network layer shall assemble the received data bytes until the whole message is received. The receiving entity shall pass the assembled message to the adjacent upper protocol layer after the last frame of the message has been received without error. 7.3.3.4.1 CF.SequenceNumber (SN) Table 13: Definition of Protocol Control Information (PCI) : CF.SN Page: 17 of 30 ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - Network Layer USDT PCI encoding PCI name ConsecutiveFrame PCI byte Mnemonic 7 6 5 4 CF 0 0 1 0 3 data bytes 2 1 0 +1 … +6/7 xx … xx SN The SequenceNumber (SN) is used to detect duplication or loss of ConsecutiveFrame(s) (CF). The sequence counter shall use the PCI lower nibble bits for the SequenceNumber (SN) value only. SequenceNumber (SN) range : The SequenceNumber (SN) range is zero (0) to fifteen (15). Conditions to initialise SequenceNumber (SN) : • The SequenceNumber (SN) is initialised to zero (0) when a) starting transmission of a message and b) a wraparound of the SequenceNumber (SN) occurs within the transmission of a block of Consecutive Frames (CF). • The first consecutive frame (CF) following the FirstFrame (FF) shall be assigned the SN value = 1. SN's Sender Receiver FirstFrame(FF )[(PCI.XDL=$ 0F, DL=$FF,x x.. ] xx..] 3,FC.STmin, , FC.BSmax=$ FC)[ PCI.FS FlowControl( Multiple consecutive frames Flow Control frame with implicit connection set-up Consecutive Frame(CF)[(P CI.SN=1,xx, xx,.. ] Consecutive Frame(CF)[(P CI.SN=2,xx, xx,.. ] SN = 1 Consecutive Frame(CF)[(P CI.SN=3,xx, xx,.. ] ... Consecutive Frame(CF)[(P CI.SN= 15,xx, xx,.. ] Consecutive Frame(CF)[(P CI.SN=00,xx ,xx,.. ] ... Figure 6 : SN values Page: 18 of 30 SN = 15 SN = 0 ISO / WD 15765 - 2 : Diagnostics Systems - Network Layer 7.4 Protocol layer timings and associated actions 7.4.1 Monitored time interval (error detection) Network Layer of Sender sub-network Network Layer of Receiver D_UUData.req(FF) à As D_UUData.con(FF) ß à D_UUData.ind(FF) n ß D_UUData.req(FC.CTS) B1 Ar 5 D_UUData.ind(FC.CTS) ß à D_UUData.con(FC) n D_UUData.req (CF) à n C As 5 D_UUData.con (CF) ß 5 à D_UUData.ind(CF) D_UUData.req (CF) à D1 As D_UUData.con (CF) ß à D_UUData.ind(CF) n D_UUData.req (CF) à D1 As 5 D_UUData.con (CF) ß à D_UUData.ind(CF) n ß D_UUData.req(FC.WT) B2 Ar 5 D_UUData.ind (FC) ß à D_UUData.con(FC.WT) ß D_UUData.req(FC.WT) n D2 Ar 5 D_UUData.ind (FC) ß à D_UUData.con(FC.WT) n ß D_UUData.req(FC.CTS) D2 Ar 5 D_UUData.ind (FC) ß à D_UUData.con(FC.CTS) D_UUData.req (CF) à C As à D_UUData.ind(CF) Figure 7: Placement of time-outs Aforementioned time intervals shall be monitored (sender side : As, B1, B2, D2, Receiver side : Ar, C, D1). Page: 19 of 30 ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - Network Layer 7.4.1.1 Monitored time interval summary The following table summarise the monitored time intervals for a given message transfer : Table 14 - Error detection : monitored time interval Time interval name Location Tx As Ar B1 B2 C D1 D2 Start monitoring (n) Stop monitoring (5) Rx 4 4 4 4 4 4 4 DUUDATA_Req DUUDATA_Req DUUDATA_Con(FF) DUUDATA_Con(block’s last CF) DUUDATA_Con(FC.CTS) DUUDATA_Ind(CF) DUUDATA_Ind(FC.WT) DUUDATA_Con DUUDATA_Con DUUDATA_Ind(FC) DUUDATA_Ind(CF) DUUDATA_Ind(CF) DUUDATA_Ind(block’s next CF) DUUDATA_Ind(next FC) 7.4.1.2 Monitored time interval time-out values Table 15 : time-out values Monitored time interval time out value (ms) A B1 B2 C D1 D2 1000 1000 1000 1000 1000 1000 7.4.1.3 Action upon expiration of time interval Upon expiration of one of the monitored time interval, the following action shall be performed : Table 16 : Error handling Time interval Expiration cause A Frame not transmitted on time B1 Frame lost (overwritten) Receiver disconnected (line cut, timeout on A, ...) Frame lost (overwritten) Receiver disconnected (line cut, timeout on A, ...) Frame or preceding FC lost (overwritten) Sender disconnected (line cut, timeout on A, ...) Frame lost (overwritten) Sender disconnected (line cut, timeout on A, ...) Frame lost (overwritten) Receiver disconnected (line cut, timeout on A, ...) Preceding reception on the receiver is lasting longer than expected. B2 C D1 D2 Page: 20 of 30 Action Abort transmission Disconnect (Reset) Abort transmission Repeat WFTmax time Abort transmission Repeat WFTmax time Abort reception Abort reception Abort transmission ISO / WD 15765 - 2 : Diagnostics Systems - Network Layer 7.4.2 Consecutive frame (CF) transmission time Network Layer of Sender sub-network Network Layer of Receiver D_UUData.req(FF) à D_UUData.con(FF) ß à D_UUData.ind(FF) ß D_UUData.req(FC.CTS) D_UUData.ind (FC.CTS) ß à D_UUData.con(FC.CTS) D_UUData.req (CF) à D_UUData.con (CF) ß à D_UUData.ind(CF) n STmin s D_UUData.req (CF) à D_UUData.con (CF) ß à D_UUData.ind(CF) ß D_UUData.req(FC.CTS) D_UUData.ind (FC.CTS) ß à D_UUData.con(FC.CTS) D_UUData.req (CF) à D_UUData.con (CF) ß à D_UUData.ind(CF) Figure 8 - Transmission of FC.WT upon expiration of 'E' A flow control wait frame (FC.WT) shall be sent to the sender upon expiration (s) of a waiting time interval STmin . 7.4.2.1 Time interval summary The following table defines the time interval relating to the transmission of consecutive frames (CF). Table 17 - CF frame transmission : inter-transmission time Time interval name Location Tx STmin 4 Start waiting (n) Stop waiting (5) Rx D_UUData.con (CF.SN) and CF.SN is not the last consecutive frame of a block. STmin expiration Note: Various time-out values and combinations can lead to various implementation optimisations which are not hinted by this specification. No implementation restrictions nor hints are made in this specification document. Page: 21 of 30 ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - Network Layer 7.4.2.2 Time interval value This specification does not define any default separation time (STmin) between consecutive frames (CF). 7.4.2.3 Action upon expiration of interval time Upon expiration of the interval time as defined below, the following action shall be performed for a single message transfer : Table 18 : flow control wait frame handling Time interval STmin Expiration cause Sender waiting Action D_UUData.req(CF) Page: 22 of 30 ISO / WD 15765 - 2 : Diagnostics Systems - Network Layer 7.4.3 Wait frame (FC.WT) transmission time Network Layer of Sender sub-network Network Layer of Receiver D_UUData.req(FF) à D_UUData.con(FF) ß à D_UUData.ind(FF) n E1 s ß D_UUData.req(FC.WT) D_UUData.ind(FC.WT) ß à D_UUData.con(FC.WT) n 5 E1 ß D_UUData.req(FC.CTS) D_UUData.ind (FC.CTS) ß à D_UUData.con(FC.CTS) D_UUData.req (CF) à D_UUData.con (CF) ß à D_UUData.ind(CF) D_UUData.req (CF) à D_UUData.con (CF) ß à D_UUData.ind(CF) n E2 s ß D_UUData.req(FC.WT) D_UUData.ind(FC.WT) ß à D_UUData.con(FC.WT) n 5 D_UUData.ind (FC.CTS) ß E3 ß D_UUData.req(FC.CTS) à D_UUData.con(FC.CTS) D_UUData.req (CF) à D_UUData.con (CF) ß à D_UUData.ind(CF) Figure 9 - Transmission of FC.WT upon expiration of 'E' Page: 23 of 30 ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - Network Layer 7.4.3.1 Time interval summary The following table summarises the respective ‘E’ time intervals for a given message transfer : Table 19 - FC.WT frame transmission : monitored time interval Time interval name Tx E1 E2 E3 Start monitoring (n) Location Stop monitoring (5) Rx 4 4 4 D_UUDATA_Ind(FF) D_UUDATA_Ind(last CF of a block) D_UUDATA_Con(FC.WT) D_UUDATA_req(FC.CTS) D_UUDATA_req(FC.CTS) D_UUDATA_req(FC.CTS) A flow control wait frame (FC.WT) shall be sent to the sender upon expiration (s) of one of the time intervals [E1, E2, E3] and FC.WFTmax > 0, see 7.3.3.3.1.1.3. Note: Various time-out values and combinations can lead to various implementation optimisations which are not hinted by this specification. No implementation restrictions nor hints are made in this specification document. 7.4.3.2 Time interval value Table 20 : time-out values Monitored time interval time out value (ms) E1 E2 E3 TBD TBD TBD 7.4.3.3 Action upon expiration of time interval Upon expiration of one of the time interval, the following action shall be performed for a given message transfer : Table 21 : flow control wait frame handling Time interval E1 E2 E3 Expiration cause Receiver not ready to resume reception of new block of frame. Receiver not ready to resume reception of new block of frame. Receiver not ready to resume reception of new block of frame. Action D_UUData.req(FC.WT) (WFTmax time) D_UUData.req(FC.WT) (WFTmax time) D_UUData.req(FC.WT) (WFTmax time) 7.5 Interleaving of messages The USDT protocol shall be capable to carry out parallel transmission of different messages provided that they are not mapped onto the same address (NORMAL addressing mode : bus frame identifier; EXTENDED addressing mode : bus frame identifier and extended address byte) so that the receiving peer is able to reassemble in a consistent manner received frames to build-up a particular message as defined at system generation time. This scheme enables gateway operation which requires the ability to handle different message transmissions “in parallel” across distinct subnetworks. Page: 24 of 30 ISO / WD 15765 - 2 : Diagnostics Systems - Network Layer 7.6 Data link layer interface 7.6.1 Services Service name: D_UUData Syntax: internal service Request: D_UUData.req (<AI>, <AF>,<Data>, <Length>) Confirmation: D_UUData.ind (<AI>, <AF>, <Data>, <Length>, <Result>) Indication: D_UUData.con (<Result>) Parameter: AI : AF : Data Result Addressing information Addressing format Reference to the frame data Result of the requested service Description: The service primitive D_UUData.req requests transmission of the data <Data> over the network. This service maps the addressing information onto the CAN data frame according to the type of addressing format chosen. The service primitive D_UUData.con confirms transmission of <Data> onto the sub-network. The service primitive D_UUData.ind indicates to the upper adjacent layer arrival of <Data>. Result : E_DLL_OK : successful service completion Page: 25 of 30 ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - Network Layer 7.6.2 CAN bus frame definition This chapter provides an overview of the fitting of data to be transmitted within a single CAN frame. Two fittings are possible depending on the addressing scheme chosen. 7.6.2.1 CAN bus frame definition : CAN identifier (NORMAL addressing) The addressing information (AI), shall be encoded within the bus CAN identifier field, according to the addressing format (AF) used. Refer to the appropriate ISO 15765 specification for the detailed definition of the Addressing Format (AF). Table 22: CAN frame example with NORMAL addressing CAN frame data field Description Id byte 1 byte 2 byte 3 byte 4 byte 5 byte 6 byte 7 byte 8 SF AI PCI Data Data Data Data Data Data Data FF AI PCI DL Data Data Data Data Data Data CF AI PCI Data (Data) (Data) (Data) (Data) (Data) (Data) FC AI PCI BSmax STmin (-) (-) (-) (-) (-) 7.6.2.2 CAN bus frame definition : CAN identifier (EXTENDED addressing) The addressing information (AI), shall be encoded within the bus CAN identifier field, according to the addressing format (AF) used. Refer to the appropriate ISO 15765 specification for the detailed definition of the Addressing Format (AF). Table 23: CAN frame example with EXTENDED addressing CAN frame data field Description Id byte 1 byte 2 byte 3 byte 4 byte 5 byte 6 byte 7 byte 8 SF AI PCI Data (Data) (Data) (Data) (Data) (Data) FF AI PCI DL Data Data Data Data Data CF AI PCI Data (Data) (Data) (Data) (Data) (Data) FC AI PCI BSmax STmin (-) (-) (-) (-) 7.6.2.3 CAN bus frame definition : DLC Refer to the appropriate ISO15765 specification for the fixed frame length (FFL) requirements that define whether the bus frame length is constant or variable. Page: 26 of 30 ISO / WD 15765 - 2 : Diagnostics Systems - Network Layer 7.6.3 Mapping of D_UUData.req onto L_Data.request service primitive The following table summarises the mapping operation necessary to map the ISO 15765 D_UUData parameters within the IS0 11898 LLC service parameters. Table 24 - Mapping D_UUData.req onto L_Data.request service ISO 15765 service primitive parameters <AI> <AF> <Data> <Len.> Data Link Layer Mapping operations ààà A) Map Addressing information : ISO 11898 LLC service primitive parameters Header Data Field Id DLC 1 2 3 5 6 7 1. Id = Set_CAN_Identifier( <AI> ) st 2. 1 data byte = Set_FirstDataByte( <AF> ) • <AF> uses NORMAL addressing scheme • <AF> uses EXTENDED addressing scheme B) Map Length : 1. DLC = Set_DLC(<Length>, FFL) • <AF> uses NORMAL addressing scheme • <AF> uses EXTENDED addressing scheme C) Map Data : 1. Data_Field = Set_DataField(<Data>) • <AF> uses NORMAL addressing scheme • <AF> uses EXTENDED addressing scheme L_DATA.request service primitive parameters à Page: 27 of 30 ID DLC Data 8 ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - Network Layer 7.6.4 Mapping of L_Data.indication onto D_UUData.ind service primitive The following table summarises the mapping operation necessary to map the IS0 11898 LLC service parameters onto ISO 15765 D_UUData parameters. Table 25 - Mapping of L_Data.indication onto D_UUData.ind service ISO 15765 service primitive parameters <AI> <AF> <Data> <Len.> Data Link Layer Mapping operations ßßß A) Map CAN identifier : 1. <AI> = Set_AI( <CAN_Identifier> ) 2. <AF> = Set_AF(<CAN_Identifier>) • <AF> uses NORMAL addressing scheme • <AF> uses EXTENDED addressing scheme B) Map Length : 1. <Length> = Set_Length(DLC) C) Map Data : 1. <Data> = Set_DataField(Data, CAN_Identifier) • <AF> uses NORMAL addressing scheme • <AF> uses EXTENDED addressing scheme <AI> <AF> <Data> <Len.> à D_UUData.ind service primitive parameters. Page: 28 of 30 ISO 11898 LLC service primitive parameters Header Data Field Id DLC 1 2 3 5 6 7 8 ISO / WD 15765 - 2 : Diagnostics Systems - Network Layer 8. DRAFT History Version 0.1 Date 23.01/98 Change description Original issue based on Com13/1 v1.2 0.2 0.3 * 03/02/98 * Changes according to remarks received from OSEK/COM and ISO/TF2 – see OSEK/VDX/Com24/1 0.4 06/03/98 1. Add Network layer services 2. Update time-outs/timer chapter 3. Conditions for the sender to take into account BS, ST LucasVarity : Laurent Roy 0.5 16/06/98 1. Migrate draft in ISO template 2. Define the no flow control USDT protocol extension 3. Complete the time-out section for TF2 revision LucasVarity : Laurent Roy 0.6 24/06/98 Following comments from DB : W.Preuschoff 1. Remove Figure 4 2. Remove table 8/9 3. Correct Time-out B1 definition LucasVarity : Laurent Roy 0.7 21/09/98 Comments in meeting minutes 13 and 14 . th Page: 29 of 30 th Author GM : Gangolf Feiter Thomas Walter * LucasVarity : Laurent Roy LucasVarity : Laurent Roy ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - Network Layer 9. Annexe 9.1 Time-out values setting requirements Table 26 : time-out values settings requirements Timeout on the opposite side B1min B2min D2min Cmin D1min Constraint Internal CPU load > > > > > E1max + Armax E2max + Armax E3max + Armax Fmax + Asmax Gmax + Asmax Page: 30 of 30