ISO15765-2 道路车辆——通过控制器局域网（CAN）进行诊断通信 (翻译版)(万字长文)

ISO15765-2 道路车辆------通过控制器局域网（CAN）进行诊断通信 (翻译版)(万字长文)

文章目录

[ISO15765-2 道路车辆------通过控制器局域网（CAN）进行诊断通信 (翻译版)(万字长文)](#ISO15765-2 道路车辆——通过控制器局域网（CAN）进行诊断通信 (翻译版)(万字长文))
- 第二部分：传输协议和网络层服务
- - 前言Foreword
  - Introduction
  - [1. Scope](#1. Scope)
  - [2. Normative references 规范性引用文件](#2. Normative references 规范性引用文件)
  - [3. 术语、定义和缩写词](#3. 术语、定义和缩写词)
  - - [3.1 Terms and definitions](#3.1 Terms and definitions)
    - - [3.1.1 CAN frame data length--CAN_DL](#3.1.1 CAN frame data length--CAN_DL)
      - [3.1.2 transmit data link layer data length--TX_DL](#3.1.2 transmit data link layer data length--TX_DL)
      - [3.1.3 Received data link layer data length--RX_DL](#3.1.3 Received data link layer data length--RX_DL)
    - [3.2 Abbreviated terms 缩略语](#3.2 Abbreviated terms 缩略语)
  - [4 Conventions](#4 Conventions)
  - [5 Document overview](#5 Document overview)
  - [6. ISO 11898-1 CAN data link layer extension](#6. ISO 11898-1 CAN data link layer extension)
  - - [6.1 CLASSICAL CAN and CAN FD frame feature comparison 经典CAN与CAN FD帧特性比较](#6.1 CLASSICAL CAN and CAN FD frame feature comparison 经典CAN与CAN FD帧特性比较)
    - [6.2 Illustration of CAN parameters for transport protocol and network layer services CAN传输协议和网络层服务参数示意图](#6.2 Illustration of CAN parameters for transport protocol and network layer services CAN传输协议和网络层服务参数示意图)
    - [6.3 Additional requirements for CAN FD](#6.3 Additional requirements for CAN FD)
  - [7 Network layer overview](#7 Network layer overview)
  - - [7.1 General](#7.1 General)
    - [7.2 Services provided by network layer to higher layers](#7.2 Services provided by network layer to higher layers)
    - [7.3 网络层内部操作](#7.3 网络层内部操作)
  - [8 Network layer services](#8 Network layer services)
  - - [8.1 General](#8.1 General)
    - [8.2 Specification of network layer service primitives 网络层服务原语的规范](#8.2 Specification of network layer service primitives 网络层服务原语的规范)
    - - [8.2.1 N_USData.request](#8.2.1 N_USData.request)
      - [8.2.2 N_USData.confirm](#8.2.2 N_USData.confirm)
      - [8.2.3 N_USData_FF.indication](#8.2.3 N_USData_FF.indication)
      - [8.2.4 N_USData.indication](#8.2.4 N_USData.indication)
      - [8.2.5 N_ChangeParameters.request](#8.2.5 N_ChangeParameters.request)
      - [8.2.6 N_ChangeParameter.confirm](#8.2.6 N_ChangeParameter.confirm)
    - [8.3 Service data unit specification](#8.3 Service data unit specification)
    - - [8.3.1 Mtype, message type](#8.3.1 Mtype, message type)
      - [8.3.2 N_AI, address information](#8.3.2 N_AI, address information)
      - [8.3.2.1 N_AI description](#8.3.2.1 N_AI description)
        
        [8.3.2.2 N_SA, network source address](#8.3.2.2 N_SA, network source address)
        
        [8.3.2.3 N_TA, network target address](#8.3.2.3 N_TA, network target address)
        
        [8.3.2.4 N_TAtype, Network target address type 网络目标地址类型](#8.3.2.4 N_TAtype, Network target address type 网络目标地址类型)
        
        [8.3.2.5 N_AE, network address extension](#8.3.2.5 N_AE, network address extension)
      - [8.3.3 < Length >](#8.3.3 < Length >)
      - [8.3.4 < MessageData >](#8.3.4 < MessageData >)
      - [8.3.5 < Parameter >](#8.3.5 < Parameter >)
      - [8.3.6 <Parameter_Value>](#8.3.6 <Parameter_Value>)
      - [8.3.7 <N_Result>](#8.3.7 <N_Result>)
      - [8.3.8 <Result_ChangeParameter>](#8.3.8 <Result_ChangeParameter>)
  - [9 Transport layer protocol](#9 Transport layer protocol)
  - - [9.1 Protocol functions](#9.1 Protocol functions)
    - [9.2 SingleFrame transmission](#9.2 SingleFrame transmission)
    - - [9.2.1 SingleFrame transmission with TX_DL = 8](#9.2.1 SingleFrame transmission with TX_DL = 8)
      - [9.2.2 SingleFrame transmission with TX_D > 8](#9.2.2 SingleFrame transmission with TX_D > 8)
    - [9.3 Multiple-frame transmission](#9.3 Multiple-frame transmission)
    - [9.4 Transport layer protocol data units](#9.4 Transport layer protocol data units)
    - - [9.4.1 Protocol data unit types](#9.4.1 Protocol data unit types)
      - [9.4.2 SF N_PDU](#9.4.2 SF N_PDU)
      - [9.4.3 FF N_PDU](#9.4.3 FF N_PDU)
      - [9.4.4 CF N_PDU](#9.4.4 CF N_PDU)
      - [9.4.5 FC N_PDU](#9.4.5 FC N_PDU)
      - [9.4.6 Protocol data unit field description](#9.4.6 Protocol data unit field description)
      - [9.4.6.1 N_PDU format](#9.4.6.1 N_PDU format)
        
        [9.4.6.2 Address information (N_AI)](#9.4.6.2 Address information (N_AI))
        
        [9.4.6.3 Protocol control information (N_PCI)](#9.4.6.3 Protocol control information (N_PCI))
        
        [9.4.6.4 Data field (N_Data)](#9.4.6.4 Data field (N_Data))
    - [9.5 Transmit data link layer data length (TX_DL) configuration](#9.5 Transmit data link layer data length (TX_DL) configuration)
    - - [9.5.1 Definition of TX_DL configuration values](#9.5.1 Definition of TX_DL configuration values)
      - [9.5.2 Creating CAN frames based on N_TAtype and TX_DL](#9.5.2 Creating CAN frames based on N_TAtype and TX_DL)
      - [9.5.3 Verifying the correctness of received CAN frames](#9.5.3 Verifying the correctness of received CAN frames)
      - [9.5.4 Receiver determination RX_DL](#9.5.4 Receiver determination RX_DL)
    - [9.6 Protocol control information specification](#9.6 Protocol control information specification)
    - - [9.6.1 N_PCI](#9.6.1 N_PCI)
      - [9.6.2 SingleFrame N_PCI parameter definition](#9.6.2 SingleFrame N_PCI parameter definition)
      - [9.6.2.1 SF N_PCI byte](#9.6.2.1 SF N_PCI byte)
        
        [9.6.2.2 SF_DL error handling](#9.6.2.2 SF_DL error handling)
      - [9.6.3 FirstFrame N_PCI parameter definition](#9.6.3 FirstFrame N_PCI parameter definition)
      - [9.6.3.1 FirstFrame DataLength (FF_DL) parameter definition](#9.6.3.1 FirstFrame DataLength (FF_DL) parameter definition)
        
        [9.6.3.2 FF_DL error handling](#9.6.3.2 FF_DL error handling)
      - [9.6.4 ConsecutiveFrame N_PCI parameter definition](#9.6.4 ConsecutiveFrame N_PCI parameter definition)
      - [9.6.4.1 CF N_PCI byte](#9.6.4.1 CF N_PCI byte)
        
        [9.6.4.2 Transmitter requirements for last consecutive frame](#9.6.4.2 Transmitter requirements for last consecutive frame)
        
        [9.6.4.3 SequenceNumber (SN) parameter definition](#9.6.4.3 SequenceNumber (SN) parameter definition)
        
        [9.6.4.4 SequenceNumber (SN) error handling](#9.6.4.4 SequenceNumber (SN) error handling)
      - [9.6.5 FlowControl N_PCI parameter definition](#9.6.5 FlowControl N_PCI parameter definition)
      - [9.6.5.1 FlowStatus (FS) parameter definition](#9.6.5.1 FlowStatus (FS) parameter definition)
        
        [9.6.5.2 FlowStatus (FS) error handling](#9.6.5.2 FlowStatus (FS) error handling)
        
        [9.6.5.3 BlockSize (BS) parameter definition](#9.6.5.3 BlockSize (BS) parameter definition)
        
        [9.6.5.4 SeparationTime minimum (STmin) parameter definition](#9.6.5.4 SeparationTime minimum (STmin) parameter definition)
        
        [9.6.5.5 SeparationTime minimum (STmin) error handling](#9.6.5.5 SeparationTime minimum (STmin) error handling)
        
        [9.6.5.6 Dynamic BS/STmin values in subsequent FlowControl frames](#9.6.5.6 Dynamic BS/STmin values in subsequent FlowControl frames)
    - [9.7 Maximum number of FC.WAIT frame transmissions (N_WFTmax)](#9.7 Maximum number of FC.WAIT frame transmissions (N_WFTmax))
    - [9.8 Network layer timing](#9.8 Network layer timing)
    - - [9.8.1 Timing parameters](#9.8.1 Timing parameters)
      - [9.8.2 Network layer timeouts](#9.8.2 Network layer timeouts)
      - [9.8.3 Unexpected arrival of N_PDU](#9.8.3 Unexpected arrival of N_PDU)
      - [9.8.4 Wait frame error handling](#9.8.4 Wait frame error handling)
    - [9.9 Interleaving of messages](#9.9 Interleaving of messages)
  - [10 Data link layer usage](#10 Data link layer usage)
  - - [10.1 Data link layer service parameters](#10.1 Data link layer service parameters)
    - [10.2 Data link layer interface services](#10.2 Data link layer interface services)
    - - [10.2.1 L_Data.request](#10.2.1 L_Data.request)
      - [10.2.2 L_Data.confirm](#10.2.2 L_Data.confirm)
      - [10.2.3 L_Data.indication](#10.2.3 L_Data.indication)
    - [10.3 Mapping of the N_PDU fields](#10.3 Mapping of the N_PDU fields)
    - - [10.3.1 Addressing formats](#10.3.1 Addressing formats)
      - [10.3.2 Normal addressing](#10.3.2 Normal addressing)
      - [10.3.3 Normal fixed addressing](#10.3.3 Normal fixed addressing)
      - [10.3.4 Extended addressing](#10.3.4 Extended addressing)
      - [10.3.5 Mixed addressing](#10.3.5 Mixed addressing)
      - [10.3.5.1 29 bit CAN identifier](#10.3.5.1 29 bit CAN identifier)
        
        [10.3.5.2 11 bit CAN identifier](#10.3.5.2 11 bit CAN identifier)
    - [10.4 CAN frame data length code (DLC)](#10.4 CAN frame data length code (DLC))
    - - [10.4.1 DLC parameter](#10.4.1 DLC parameter)
      - [10.4.2 CAN frame data](#10.4.2 CAN frame data)
      - [10.4.2.1 CAN frame data padding (TX_DL = 8)](#10.4.2.1 CAN frame data padding (TX_DL = 8))
        
        [10.4.2.2 CAN frame data optimization (TX_DL = 8)](#10.4.2.2 CAN frame data optimization (TX_DL = 8))
        
        [10.4.2.3 Mandatory padding of CAN FD frames (TX_DL > 8)](#10.4.2.3 Mandatory padding of CAN FD frames (TX_DL > 8))
    - [10.4.3 Data length code (DLC) error handling](#10.4.3 Data length code (DLC) error handling)

第二部分：传输协议和网络层服务

前言Foreword

ISO（国际标准化组织）是一个由各国家标准机构（ISO会员机构）组成的全球联合体。制定国际标准的工作通常由ISO技术委员会负责进行。对于已经建立了技术委员会的主题，每个感兴趣的会员机构都有权在该委员会上代表自己。与ISO保持联系的国际组织、政府和非政府组织也参与其中。ISO与国际电工委员会（IEC）在所有电气技术标准化事务上密切合作。

本文件的制定程序以及用于进一步维护的程序在ISO/IEC指南第1部分中有所描述。特别需要注意的是，不同类型的ISO文件所需的不同批准标准。本文件是根据ISO/IEC指南第2部分的编辑规则起草的（请参阅www.iso.org/directives）。

注意到这份文件的某些元素可能涉及专利权。ISO不负责识别任何或所有此类专利权。在编写该文件期间，发现的任何专利权细节将在引言和/或ISO收到的专利声明清单上列出（请参阅www.iso.org/patents）。

本文件中使用的任何商标名称仅为用户方便提供信息，并不构成认可。

有关ISO特定术语和与合规评估相关的表达方式的解释，以及ISO在技术贸易壁垒（TBT）方面遵循世界贸易组织原则的信息，请参阅以下网址：前言-补充信息。

负责此文件的委员会是ISO/TC 22，道路车辆，子委员会SC 31，数据通信。

这第三版取消并取代了第二版（ISO 15765-2:2011），该版本已经进行了技术修订。

ISO 15765由以下部分组成，总标题为道路车辆-控制器区域网络（DoCAN）上的诊断通信)

第1部分：一般信息和用例定义 Part 1: General information and use case definition
第2部分：传输协议和网络层服务 Part 2: Transport protocol and network layer services
第4部分：排放相关系统的要求 Part 4: Requirements for emissions-related systems

ISO 15765-3 实施统一诊断服务（UDS on CAN）已被撤销，并由 ISO 14229-3 道路车辆 - 统一诊断服务（UDS） - 第三部分：CAN实现的统一诊断服务（UDSonCAN）取而代之。

Introduction

这部分ISO 15765的目的是为了定义在控制器区域网络（CAN）通信链路上实施的车辆诊断系统的共同要求，如ISO 11898-1所规定。尽管主要用于诊断系统，但它也满足其他需要网络层协议的基于CAN的系统的要求。

为了实现这一目标，它基于符合ISO/IEC 7498-1和ISO/IEC 10731的开放系统互联（OSI）基本参考模型，该模型将通信系统分为七个层次，如表1所示。

表1 - 适用于OSI层的增强和立法化的车载诊断规范。

ISO 14229-3所涵盖的应用层服务是根据ISO 14229-1和ISO 15031-5中建立的诊断服务进行定义的，但不仅限于与它们一起使用。ISO 14229-3还兼容大多数在国家标准或车辆制造商规范中定义的诊断服务。

对于其他应用领域，ISO 15765可以与任何CAN物理层一起使用。

1. Scope

ISO 15765的这一部分规定了一种传输协议和网络层服务，旨在满足基于CAN的车辆网络系统对控制器区域网络的要求，如ISO 11898-1所规定。它是根据ISO 14229-1和ISO 15031-5中建立的诊断服务定义的，但不仅限于与其一起使用，并且还兼容大多数其他车载网络通信需求。

ISO 11898-1规定了可变长度的CAN帧，其最大有效载荷大小取决于所使用的协议设备。传统CAN协议设备可以发送/接收每帧有效载荷大小从0字节到8字节不等。而CAN FD（灵活数据速率）协议设备可以发送/接收每帧有效载荷大小从0字节到64字节不等。同时，CAN FD协议设备也能够发送/接收传统CAN帧。

DoCAN (diagnostic communication over controller area network)协议支持ISO 14229-2 (UDS)规定的标准化服务原语接口。

ISO 15765的这一部分提供了传输协议和网络层服务，以支持不同的应用层实现，例如:

增强型车辆诊断（超出法定功能的排放相关系统诊断，非排放相关系统诊断），
根据ISO 15031规定的排放相关的车载诊断（OBD），
根据ISO 27145规定的全球统一车载诊断（WWH-OBD），
对车载火药装置进行报废激活（根据ISO 26021）。

运输协议规定了一种未经确认的通信。注意：ISO 15765的这部分并不确定其他参考ISO 15765的标准是否建议或要求实施CLASSICAL CAN、CAN FD或两者都实施。

2. Normative references 规范性引用文件

以下文件全部或部分在本文件中被规范引用，并且对于其应用是不可或缺的。对于有日期的引用，只适用所引述的版本。对于没有日期的引用，则适用所引文档（包括任何修订）的最新版本。

ISO/IEC 7498-1，信息技术 - 开放系统互连 - 基本参考模型：基本模型 - 第一部分。

ISO 11898-1:2015)，道路车辆-控制器局域网(CAN) -第1部分:数据链路层和物理信号

3. 术语、定义和缩写词

3.1 Terms and definitions

就本文件而言，适用ISO/IEC 7498-1、ISO 11898-1和以下文件中给出的术语和定义。

3.1.1 CAN frame data length--CAN_DL

CAN帧数据/负载的物理长度(以字节为单位)

注1:见表3。

3.1.2 transmit data link layer data length--TX_DL

为实现ISO 15765本部分定义的网络层的应用程序在发送器中配置数据链路层的最大可用有效负载长度(以字节为单位)

注1：TX_DL是发送端用于PDU传输的固定配置值。

3.1.3 Received data link layer data length--RX_DL

在实现ISO 15765网络层定义的应用程序中，接收器数据链路层的最大可用有效载荷长度（以字节为单位）被检索出来。

注1:RX_DL值是从分段PDU的FirstFrame (FF) CAN_DL中检索的，用于验证连续帧(CF)的正确数据长度。

3.2 Abbreviated terms 缩略语

为了ISO 15765的这一部分的目的，适用以下缩写术语。

缩略语	全称
BRS	bit rate switch
BS	BlockSize
CAN	controller area network
CAN_DL	CAN frame data link layer data length in bytes
CAN FD	controller area network with flexible data rate and larger payload as defined in ISO 11898-1
CLASSICAL CAN	controller area network with static data rate and up to 8 data bytes as defined in ISO 11898-1
CF	ConsecutiveFrame
CTS	continue to send
DLC	CAN frame data link layer data length code
DoCAN	diagnostic communication over CAN
ECU	electronic control unit
FC	FlowControl
FF	FirstFrame
FF_DL	FirstFrame data length in bytes
FMI	failure mode indicator
FS	FlowStatus
Mtype	message type
N/A	not applicable
N_AE	network address extension
N_AI	network address information
N_Ar	network layer timing parameter Ar
N_As	network layer timing parameter As
N_Br	network layer timing parameter Br
N_Bs	network layer timing parameter Bs
N_ChangeParameter	network layer service name
N_Cr	network layer timing parameter Cr
N_Cs	network layer timing parameter Cs
N_Data	network data
N_PCI	network protocol control information
N_PCItype	network protocol control information type
N_PDU	network protocol data unit
N_SA	N_SA
N_SDU	N_SDU
N_TA	network target address
N_TAtype	network target address type
N_USData	network layer unacknowledged segmented data transfer service name
NW	network
NWL	network layer
OBD	on-board diagnostics
OSI	Open Systems Interconnection
PCI	protocol control information
RX_DL	received data link layer data length in bytes
SF	SingleFrame
SF_DL	SingleFrame data length in bytes
SN	SequenceNumber
SPN	suspect parameter number
STmin	SeparationTime minimum
TX_DL	transmit data link layer data length in bytes
UDS	unified diagnostic services
WWH-OBD	world-wide harmonized OBD

4 Conventions

这个国际标准是基于在诊断服务中适用的OSI服务约定（ISO/IEC 10731）所讨论的规范。

5 Document overview

图1 展示了利用DoCAN协议的最适用的应用实现。

Figure 1 --- DoCAN document reference according to the OSI model

6. ISO 11898-1 CAN data link layer extension

6.1 CLASSICAL CAN and CAN FD frame feature comparison 经典CAN与CAN FD帧特性比较

ISO 11898-1经典CAN帧支持的有效载荷长度最大为8字节。ISO 11898-1 CAN FD帧支持的有效载荷长度最大为64字节。因此，需要使用FirstFrame（FF）、FlowControl（FC）和ConsecutiveFrame（CF）类型的帧来实现数据的分段传输，并且要具有可配置的变长有效载荷长度，而不改变原始协议概念。SF帧类型也已经适应了CAN FD帧所允许的增加有效载荷长度。

表2概述了ISO 11898-1提供的CAN帧类型的不同特征。

6.2 Illustration of CAN parameters for transport protocol and network layer services CAN传输协议和网络层服务参数示意图

图2显示了CAN参数映射到网络/传输层寻址信息N_AI。它说明了网络/传输层参数的有效性和适用性，以及对CLASSICAL CAN与CAN FD数据链路层的支持。图2描述了使用普通或固定寻址时的示例情况。对于扩展寻址和混合寻址，概念基本上也适用，但是N_AI参数映射到CAN帧的方式有所不同。

Key:

DLC值会得出一个CAN_DL值（n），该值表示CAN帧数据/有效负载的实际长度；在接收端，使用CAN_DL来确定发送方的TX_DL值。
所展示的N_AI映射仅为正常和固定寻址提供了一个例子。
在'格式'信息中，比特率切换（BRS）定义了数据阶段的传输速度。

Figure 2 --- Illustration of CAN parameters for network layer services

6.3 Additional requirements for CAN FD

如果使用CAN FD协议设备，ISO 15765的这部分可以配置为创建经典CAN或CAN FD类型的帧。当启用数据链路层的CAN FD类型帧时，需要支持两个新选项，如下所示。

BRS位是CAN FD帧的一部分，用于确定数据阶段是否以不同的比特率传输。数据阶段的比特率被定义为等于或高于仲裁比特率。比特率切换不会影响传输协议本身（见图2）。
最大允许的有效载荷长度（CAN_DL，8 ... 64字节）；请参见表3。

满足不同的最大有效载荷长度值需要在发送节点中添加一个新的配置变量"传输数据链路层数据长度"（TX_DL），如9.5节所述。

可配置的TX_DL值充当发送节点CAN帧数据长度（CAN_DL）的开关和上限。

TX_DL equal to 8:

该传输协议的行为与基于ISO 11898-1（具有8字节有效负载的经典CAN）的先前版本完全相同。请参见表2中的RefNo＃1。由该协议创建用于传输的CAN帧只能使用DLC值2到8。这适用于经典CAN和CAN FD类型帧。

TX_DL greater than 8:

只能使用ISO 11898-1 CAN FD类型的帧。允许DLC值为2到15。请参见表2中的RefNo #1和RefNo #3。

7 Network layer overview

7.1 General

ISO 15765的这一部分规定了一个未确认的网络层通信协议，用于在网络节点之间交换数据，例如从ECU到ECU，或者外部测试设备和ECU之间。如果要传输的数据无法适应单个CAN帧，则提供了分段方法。

为了描述网络层的功能，有必要考虑向更高层提供的服务以及网络层的内部操作。

7.2 Services provided by network layer to higher layers

服务接口定义了一组需要访问网络层提供的功能的服务，即数据的传输/接收和协议参数的设置。

定义了两种类型的服务。

a) 通信服务：

这些服务，其中以下是定义的，可以实现最多4,294,967,295字节数据的传输。

N_USData.request：该服务用于请求数据的传输。如果需要，网络层会对数据进行分段。
N_USData_FF.indication: 这个服务用于向上层信号分段消息接收的开始。
N_USData.indication: 这个服务用于将接收到的数据提供给更高层次的模块
N_USData.confirm: 该服务向上层确认所请求的服务已经被执行（无论成功与否）。

b) 协议参数设置服务：

这些服务，其中以下是定义的，使得协议参数能够动态设置。

N_ChangeParameter.request: 该服务用于请求特定内部参数的动态设置。
N_ChangeParameter.confirm: 该服务向上层确认特定协议的更改请求已经完成（无论成功与否）。

7.3 网络层内部操作

网络层的内部操作提供了分段、带流量控制的传输和重组的方法。网络层的主要目的是传输可能或不可能适应单个CAN帧中的消息。无法适应单个CAN帧的消息将被分割成多个部分，每个部分可以在一个CAN帧中进行传输。

图3显示了一个未分段的消息传输的例子。

图4显示了一个分段消息传输的示例。

FlowControl用于调整发送方对接收方的网络层能力。该 FlowControl方案允许使用诊断网关和子网。

8 Network layer services

8.1 General

所有网络层服务都具有相同的一般结构。为了定义这些服务，需要指定三种类型的服务原语，如下所示：

服务请求原语，由更高的通信层或应用程序使用，以传递控制信息和需要传输到网络层的数据；
一个服务指示原语，由网络层用于将状态信息和接收到的数据传递给上层通信层或应用程序；
一个服务确认原语，由网络层用于向更高的通信层或应用程序传递状态信息。

该服务规范并未指定应用程序接口，而只是一组与任何实现无关的服务原语。

所有网络层服务都具有相同的一般格式。服务原语以以下形式书写：

其中，"service_name"是服务的名称，例如N_USData，"type"表示服务原语的类型，"parameter A, parameter B [,parameter C, ...]"是作为服务原语传递的值列表。方括号表示参数列表中的这部分可能为空。

服务原语定义了服务用户（例如诊断应用程序）与服务提供者（例如网络层）之间的合作方式。本部分ISO 15765规定了以下服务原语：请求、指示和确认。

通过使用服务原语请求（service_name.request），服务用户向服务提供者请求一项服务。
通过使用服务原语指示（service_name.indication），服务提供者向服务用户通知网络层的内部事件或对等协议层实体服务用户的服务请求。
通过服务原语confirm（service_name.confirm），服务提供者向服务用户通知关于先前的服务请求结果。

8.2 Specification of network layer service primitives 网络层服务原语的规范

8.2.1 N_USData.request

该服务基本操作请求从发送方传输带有字节的到由N_SA、N_TA、N_TAtype [和N_AE]中的地址信息标识的接收方实体（见8.3节以获取参数定义）。

每次调用N_USData.request服务时，网络层应通过发出N_USData.confirm服务调用来向服务用户信号传输完成（或失败）的消息。

8.2.2 N_USData.confirm

N_USData.confirm服务是由网络层发出的。该服务原语确认由N_SA、N_TA、N_TAtype [和N_AE]中的地址信息标识的N_USData.request服务的完成情况。参数<N_Result>提供了服务请求的状态（有关参数定义，请参见8.3）。

8.2.3 N_USData_FF.indication

N_USData_FF.indication服务由网络层发出。该服务原语向相邻的上层指示从对等协议实体接收到的分段消息的第一个帧（FF）已经到达，这些实体通过N_SA、N_TA、N_TAtype [和 N_AE]中的地址信息进行识别（有关参数定义，请参见8.3）。在接收到分段消息的FF时，应进行此指示。

N_USData_FF.indication服务必须始终在网络层完成（或失败）消息接收后，跟随一个N_USData.indication服务调用。

只有在接收到正确的FF消息段时，网络层才会发出N_USData_FF.indication服务调用。

如果网络层在FF中检测到任何类型的错误，则网络层将忽略该消息，并且不会向相邻的上层发出N_USData_FF.indication。

如果网络层接收到一个数据长度值（FF_DL）大于可用接收缓冲区大小的FF，则应将其视为错误条件，并且不会向相邻的上层发出N_USData_FF.indication。

8.2.4 N_USData.indication

N_USData.indication服务由网络层发出。该服务原语指示<N_Result>事件，并将从通过N_SA、N_TA、N_TAtype [和 N_AE]中的地址信息识别的对等协议实体接收到的与字节传递给相邻的上层（有关参数定义，请参见8.3节）。

只有当<N_Result>等于N_OK时，参数和才有效。

N_USData.indication服务调用在接收到SingleFrame（SF）消息后发出，或作为分段消息接收完成（或失败）的指示。

如果网络层在SF中检测到任何类型的错误，则网络层将忽略该消息，并且不会向相邻的上层发出N_USData.indication。

8.2.5 N_ChangeParameters.request

服务原语用于请求在本地协议实体上更改内部参数的值。将<Parameter_Value>分配给（有关参数定义，请参见8.3节）。

参数的更改始终是可能的，除非在接收到FF（N_USData_FF.indication）之后，并且直到接收相应消息结束为止（N_USData.indication）。

这是一个可选的服务，可以通过实现固定参数值来替代。

8.2.6 N_ChangeParameter.confirm

该服务原语确认了一个应用于由N_SA、N_TA、N_TAtype [和 N_AE]地址信息标识的消息的N_ChangeParameter.confirm服务已完成（有关参数定义，请参见8.3）。

8.3 Service data unit specification

8.3.1 Mtype, message type

Type: enumeration

Range: diagnostics, remote diagnostics

描述：参数Mtype应用于识别服务调用中包含的地址信息参数的类型和范围。ISO 15765的这一部分规定了该参数的两个值范围。意图是让ISO 15765这一部分的用户可以通过指定其他类型和组合的地址信息参数来扩展值范围，以与本部分规定的网络层协议一起使用。对于每个新的地址信息值范围，都必须指定一个新值来标识该新地址信息。

如果Mtype = 诊断，则地址信息N_AI应包括参数N_SA、N_TA和N_TA类型。
如果Mtype = 远程诊断，则地址信息N_AI应包括参数N_SA、N_TA、N_TAtype和N_AE。

8.3.2 N_AI, address information

8.3.2.1 N_AI description

这些参数是指寻址信息。总体而言，N_AI参数用于识别消息发送者和接收者的源地址（N_SA）、目标地址（N_TA），以及消息的通信模型（N_TAtype）和可选的地址扩展（N_AE）。

8.3.2.2 N_SA, network source address

Type: 8 bits

Range: 00(16) to FF(16)

Description: The N_SA parameter shall be used to encode the sending network layer protocol entity.

8.3.2.3 N_TA, network target address

Type: 8 bits

Range: 00(16) to FF(16)

Description: The N_TA parameter shall be used to encode one or multiple (depending on the N_TAtype: physi cal or functional) receiving network layer protocol entities. N_TA参数应用于编码一个或多个（取决于N_TA类型：物理或功能性）接收网络层协议实体。

8.3.2.4 N_TAtype, Network target address type 网络目标地址类型

Type: enumeration

Range: see Table 4

描述：参数N_TAtype是对参数N_TA的扩展。它应该用于编码网络层通信实体使用的通信模型（参见图2）。必须支持以下要求。

网络层协议应能够同时传输不映射到相同N_AI的不同消息。
对于意外的PDU，错误处理仅适用于具有相同N_AI的消息。
- 经典CAN帧不会导致CAN FD消息终止，反之亦然。
- 这明确禁止在单个消息中混合使用CAN FD/经典CAN帧类型。

表4定义了N_TAtype通信模型的允许组合。

图5和图6展示了允许的N_TA类型通信模型的示例，并描述了涉及的具体参数。

图5显示了一个增强的诊断工具CLASSICAL CAN请求正常寻址（N_TAtype #2）的示例。

图6展示了一个增强型诊断工具CAN FD请求的正常寻址示例（N_TAtype #4）。

8.3.2.5 N_AE, network address extension

Type: 8 bits

Range: 00(16) to FF(16)

描述：N_AE参数用于扩展大型网络的可用地址范围，并对除了通信发生的本地网络之外的子网络的发送和接收网络层实体进行编码。只有当Mtype设置为远程诊断时，N_AE才是寻址信息的一部分。

8.3.3 < Length >

Type: 32 bits

Range: 0000 0001(16) to FFFF FFFF(16)

描述：该参数包括要传输/接收的数据长度。

8.3.4 < MessageData >

Type: string of bytes

Range: not applicable

描述：该参数包括高层实体之间交换的所有数据。

8.3.5 < Parameter >

Type: enumeration

Range: STmin, BS

描述：该参数用于标识网络层的一个参数。

8.3.6 <Parameter_Value>

Type: 8 bits

Range: 00(16) to FF(16)

描述：该参数被分配给协议参数，如9.6.5.3和9.6.5.4所示。

8.3.7 <N_Result>

Type: enumeration

Range: N_OK, N_TIMEOUT_A, N_TIMEOUT_Bs, N_TIMEOUT_Cr, N_WRONG_SN, N_INVALID_FS, N_ UNEXP_PDU, N_WFT_OVRN, N_BUFFER_OVFLW, N_ERROR

描述：该参数包含与服务执行结果相关的状态。如果同时发现两个或更多错误，则网络层实体在向更高层指示错误时应使用此列表中首先找到的参数值。

N_OK :这个值表示服务执行已经成功完成；它可以在发送方和接收方两边向服务用户发放。
N_TIMEOUT_A : 当计时器N_Ar/N_As达到其超时值N_Asmax/N_Armax时，该值将被分配给协议用户；它可以分配给发送方和接收方的服务用户。
N_TIMEOUT_Bs :当计时器N_Bs达到其超时值N_Bsmax时，该值将被分配给服务用户；它只能在发送方向上分配给服务用户。
N_TIMEOUT_Cr :当计时器N_Cr达到其超时值N_Crmax时，该数值将被发放给服务用户；它只能在接收方向上发放给服务用户。
N_WRONG_SN :该值在接收到意外的SequenceNumber（PCI.SN）值时发放给服务用户；它只能在接收方向上发放给服务用户。
N_INVALID_FS :当在FlowControl（FC）N_PDU中接收到无效或未知的FlowStatus值时，将向服务用户发出此值；它只能在发送方向上向服务用户发出。
N_UNEXP_PDU :这个值是在接收到意外的协议数据单元时发给服务用户的；它只能在接收方向上发给服务用户。
N_WFT_OVRN :当接收方连续传输了N_WFTmax个FlowControlN_PDUs，并且这些PDU的FlowStatus都为WAIT，随后无法满足以FlowStatus = ClearToSend传输FlowControl N_PDU的性能要求时，将向服务用户发出此值。该值只能在接收方向服务用户发出。
N_BUFFER_OVFLW :当接收到FlowControl (FC) N_PDU并且FlowStatus = OVFLW时，将向服务用户发出此值。它表示分段消息传输的接收方缓冲区无法存储FirstFrame中由FF_DL参数指定的字节数，因此分段消息的传输被中止。只能在发送方向上向服务用户发出该值。
N_ERROR :这是一般的错误值。当网络层检测到错误并且没有其他参数值可以更好地描述该错误时，应向服务用户发出此错误值。它可以在发送方和接收方都向服务用户发出。

8.3.8 <Result_ChangeParameter>

Type: enumeration.

Range: N_OK, N_RX_ON, N_WRONG_PARAMETER, N_WRONG_VALUE

描述：该参数包含与服务执行结果相关的状态。

N_OK :这个值表示服务执行已经成功完成；它可以在发送方和接收方两边向服务用户发放。
N_RX_ON : 该值是发给服务用户的，用于指示由于正在进行接收消息（由<N_AI>标识）而导致服务未执行；它只能在接收方向的服务用户处发出。
N_WRONG_PARAMETER :该值是发给服务用户的，用于指示由于未定义的<参数>而导致服务未执行；它可以在接收方和发送方都向服务用户发出。
N_WRONG_VALUE :该值是发给服务用户的，用于指示由于超出范围的<Parameter_Value>而导致服务未执行；它可以在接收方和发送方都向服务用户发出。

9 Transport layer protocol

9.1 Protocol functions

传输层协议应执行以下功能：

传输/接收消息高达4,294,967,295（2^32-1）个数据字节；
传输/接收完成（或失败）的报告。

9.2 SingleFrame transmission

9.2.1 SingleFrame transmission with TX_DL = 8

通过传输一个称为SF的唯一N_PDU（参见9.4.2），可以传输多达六个（在扩展或混合寻址的情况下为TX_DL - 2）或七个（在正常寻址的情况下为TX_DL - 1）数据字节的消息。

通过接收唯一的N_PDU来接收最多六到七个数据字节的消息。

9.2.2 SingleFrame transmission with TX_D > 8

通过传输一个称为SF的唯一N_PDU（见9.4.2）来传输多达TX_DL-3（在扩展或混合寻址的情况下）或TX_DL-2（在正常寻址的情况下）个数据字节。

通过接收一个唯一的N_PDU来执行对最多TX_DL - 3或TX_DL - 2个数据字节的消息的接收。

9.3 Multiple-frame transmission

较长的消息传输是通过将消息分段并传输多个N_PDUs来完成的。接收较长的消息是通过接收多个N_PDUs并重新组装接收到的数据字节（连接）来完成的。这些多个N_PDUs被称为FirstFrame（用于第一个N_PDU）和ConsecutiveFrame（用于所有后续的N_PDUs）。

多个N_PDU消息的接收者可以通过使用流量控制机制，利用流量控制协议数据单元（FC N_PDU），根据自身能力调整传输吞吐量。

超过所使用的TX_DL允许的最大SF_DL的消息将被分段。

一个FirstFrame协议数据单元（FF N_PDU），包含第一组数据字节。
一个或多个连续的帧协议数据单元（CF N_PDU），每个包含一系列连续的数据字节。最后一个（或唯一的）CF N_PDU包含最后一组数据字节。

消息长度在FF N_PDU中传输。所有的CF N_PDUs都由发送方编号，以帮助接收方按照相同的顺序重新组装它们。

流量控制机制（见图8）允许接收方向发送方提供有关自身能力的信息，而发送方必须遵守这些要求。

这些能力的定义如下。

BlockSize 块大小（BS）：接收方允许发送方在等待继续传输下一个N_PDU的授权之前发送的最大N_PDU数量。当接收方将BS设置为零时，发送方不需要等待授权即可继续传输。
分离时间最小值（STmin）：发送方在两个CF N_PDU传输之间应等待的最短时间。

由于每个接收到的流控制帧都提供了BS和STmin的值，因此对于分段消息的接收者，有两种不同的模式可用来采用这些值。

动态的：对于这条消息，BS和STmin将被更新以用于后续PDU通信；
静态：此消息的通信中使用了恒定的BS和STmin值。

请参阅9.6.5.6以获取车辆诊断的可能实施决策和要求。除最后一个块外，所有块都将由BS N_PDUs组成。最后一个块将包含剩余的N_PDUs（从1到BS）。

每当发送方/接收方等待来自接收方/发送方的N_PDU时，超时机制可以检测到传输失败（见9.8.2）。

通过使用FC N_PDUs，接收方有可能授权传输以下CF N_PDUs来延迟传输该授权或者在待传输的字节数超过接收缓冲区可存储字节数时拒绝接收分段消息。

FC.CTS：继续发送，授权继续。
FC.WAIT：继续等待的请求
FC.OVFLW：缓冲区溢出，指示分段消息的FirstFrame中指定的字节数超过了接收方实体缓冲区可以存储的字节数。

接收器允许连续发送的FC.WAIT命令有一个上限，称为N_WFTmax。这个参数是系统设计常数，并不在FC N_PDU中传输。

图8显示了发送端的分段和接收端的重组。

9.4 Transport layer protocol data units

9.4.1 Protocol data unit types

不同节点中网络层的对等协议实体之间的通信是通过交换N_PDUs来完成的。

ISO 15765的这一部分规定了四种不同类型的传输层协议数据单元，包括SingleFrame（SF N_PDU）、FirstFrame（FF N_PDU）、ConsecutiveFrame（CF N_PDU）和FlowControl（FC N_PDU），用于在对等网络层实体之间建立通信路径、交换通信参数、传输用户数据并释放通信资源。

9.4.2 SF N_PDU

SF N_PDU由单帧协议控制信息（SF N_PCI）进行标识。 SF N_PDU应由发送网络实体发送，并可被一个或多个接收网络实体接收。它应该被发送以传输通过单个服务请求可以传输到数据链路层的服务数据单元，并传输未分段的消息。

9.4.3 FF N_PDU

FF N_PDU由第一帧协议控制信息（FF N_PCI）进行标识。在分段消息传输的过程中，发送网络实体将发送FF N_PDU，并由唯一的接收网络实体接收。它用于标识由网络发送实体传输的分段消息的第一个N_PDU。接收网络层实体应在接收到FF N_PDU后开始组装分段消息。

9.4.4 CF N_PDU

CF N_PDU由连续帧协议控制信息（CF N_PCI）标识。CF N_PDU传输服务数据单元消息数据（）的分段（N_Data）。在FF N_PDU之后，发送实体发送的所有N_PDU都应编码为CF N_PDUs。接收实体在接收到最后一个CF N_PDU后将组装好的消息传递给网络接收实体的服务用户。在分段消息传输期间，发送网络实体将发送出CF N_PDU，并由唯一的接收网络实体接收。

9.4.5 FC N_PDU

FC N_PDU由流量控制协议控制信息（FC N_PCI）进行标识。 FC N_PDU指示发送网络实体启动、停止或恢复CF N_PDU的传输。在正确接收后，接收网络层实体应向发送网络层实体发送该消息，以表示准备好接收更多数据。

FF N_PDU，或
如果需要发送更多的连续帧，那么最后一个连续帧块的CF N_PDU。

FC N_PDU还可以通知发送网络实体在分段消息传输期间暂停CF N_PDUs的传输，或者如果发送实体传输的FF N_PDU中的长度信息（FF_DL）超过接收实体的缓冲区大小，则终止分段消息的传输。

9.4.6 Protocol data unit field description

9.4.6.1 N_PDU format

协议数据单元（N_PDU）使得在一个节点的网络层和一个或多个其他节点的网络层之间传输数据成为可能（对等协议实体）。所有N_PDUs都由三个字段组成，如表5所示。

9.4.6.2 Address information (N_AI)

N_AI用于识别网络层的通信对等实体。在接收到的N_SDU（包括N_SA、N_TA、N_TAtype [和 N_AE]）中，应将N_AI信息复制并包含在每个传输的 N_PDU 中。如果接收到的 N_SDU 中的消息数据（和）需要进行分段以便网络层传输完整消息，则应将 N_AI 复制并包含（重复）在每个传输的 N_PDU 中。

这个字段包含地址信息，用于标识交换的消息类型以及数据交换发生的接收者和发送者。

注意：有关地址信息的详细描述，请参见8.3.2。

9.4.6.3 Protocol control information (N_PCI)

该字段用于标识交换的N_PDUs类型。它还用于在通信网络层实体之间交换其他控制参数。

注意：有关所有N_PCI参数的详细规范，请参见9.6节。

9.4.6.4 Data field (N_Data)

N_PDU中的N_Data用于传输在N_USData.request服务调用中接收到的服务用户数据，如果需要，参数将被分割成适合N_PDU数据字段的较小部分，然后通过网络进行传输。 N_Data的大小取决于N_PDU类型、选择的地址格式和TX_DL值。

9.5 Transmit data link layer data length (TX_DL) configuration

9.5.1 Definition of TX_DL configuration values

传输数据链路层数据长度（TX_DL）配置了实现网络层的应用程序中数据链路层可使用的最大有效负载长度，如ISO 15765的本部分所定义。 TX_DL值被定义为以字节为单位的真实负载长度，以提供简单计算和对9.6中指定的N_PCI类型长度定义进行合理性检查。有效的TX_DL值是从8到15个数据长度代码（DLC）值得出的（参见ISO 11898-1:2015，DLC表）。

当TX_DL等于8时，ISO 15765的这部分协议与基于ISO 11898-1（具有8字节有效负载的CAN）的先前版本行为完全相同。表6描述了有效的传输数据链路数据长度（TX_DL）值。

9.5.2 Creating CAN frames based on N_TAtype and TX_DL

CAN帧是根据N_AI（参见8.3.2），给定N_AI的配置寻址格式（参见10.3.1），配置的TX_DL值以及要传输的消息大小生成的。

9.5.3 Verifying the correctness of received CAN frames

由于接收节点不知道发送节点的TX_DL配置，因此接收节点应始终适应发送者的TX_DL设置。

本地配置的N_TAtype允许检查接收到的CAN帧类型（经典CAN / CAN FD），并用于忽略错误的N_TAtype帧。一旦N_TAtype正确，可以检查不同的N_PCItype值，并对RX_DL（发送方TX_DL）进行假设。

请参见图9，以获取一个完整的状态流程图来处理传入的CAN帧。

Key:

如果对于除了最后一个（或唯一的）CF之外的所有CF，CAN_DL与RX_DL的值匹配，则CAN_DL应该是正确的；如果满足CAN_DL小于或等于RX_DL并且9.6.4.2中的要求得到满足，则最后一个（或唯一的）CF应该通过此检查；RX_DL来自FF，并且对于此PDU接收过程而言是固定的。

Figure 9 --- State flow --- Verifying received CAN frames

9.5.4 Receiver determination RX_DL

为了确定从接收到的第一个帧N_PDU中的RX_DL，使用字节长度（CAN_DL）作为载荷。
对于小于8个字节的CAN_DL值，RX_DL值无效。- 对于等于8个字节的CAN_DL值，RX_DL值应为8。
对于大于8个字节的CAN_DL值，RX_DL值等于CAN_DL值。

表7定义了接收的CAN_DL到RX_DL映射表。

9.6 Protocol control information specification

9.6.1 N_PCI

每个N_PDU都通过N_PCI进行标识。请参考表8和表9。表8定义了N_PCI类型的位值。

表9显示了N_PCI字节的汇总

注意：虚线并不用于PCI信息，但根据PDU的不同，它们可能用于承载数据。

9.6.2 SingleFrame N_PCI parameter definition

9.6.2.1 SF N_PCI byte

参数SingleFrame数据长度（SF_DL）用于在SF N_PDU中指定服务消息数据字节的数量。有效的SF_DL值范围取决于配置的传输数据链路层数据长度（TX_DL）和要传输的实际负载（参见表10和表11）。如果TX_DL>8且负载大小导致CAN_DL超过8，则第一个PCI字节（字节＃1）的位0到3设置为0，并将SF_DL嵌入第二个PCI字节（字节＃2）中；请参阅表9。

注意1：SF_DL被编码在第一个N_PCI字节（字节＃1）的低半字节值中。

9.6.2.2 SF_DL error handling

收到的CAN_DL小于或等于8：

如果网络层接收到一个SF，其中SF_DL等于0，则网络层应忽略接收到的SF N_PDU。
如果网络层接收到一个SF，其中SF_DL大于使用普通寻址时接收到的帧的(CAN_DL-1)，或者大于使用扩展或混合寻址时接收到的帧的(CAN_DL-2)，那么网络层将忽略接收到的SF N_PDU。
在CAN帧数据填充的情况下（参见10.4.2.1）：如果网络层接收到一个SF，其中CAN_DL不等于8，则网络层应忽略接收到的SF N_PDU。
在CAN帧数据优化的情况下（参见10.4.2.2）：如果网络层接收到一个SF，其中SF_DL的值与表12中显示的有效值不匹配，则网络层将忽略接收到的SF N_PDU。

收到的CAN_DL大于8：

如果网络层接收到的SF中，第一个PCI字节的低半字节不是00002，则网络层应忽略接收到的SF N_PDU。
如果网络层接收到一个SF，其中SF_DL的值不在表13中显示的有效范围内，则网络层应忽略接收到的SF N_PDU。

9.6.3 FirstFrame N_PCI parameter definition

9.6.3.1 FirstFrame DataLength (FF_DL) parameter definition

参数FF_DL在FF N_PDU中用于指定服务消息数据字节的数量。对于发送方而言，有效的FF_DL值范围取决于寻址方案和配置的传输数据链路层数据长度（TX_DL）。根据寻址方案和TX_DL，表14中指定了FF_DL的最小值（FF_DLmin）。

FF N_PDU的接收方不知道发送方的TX_DL。根据配置的寻址方案和从FF N_PDU的CAN_DL中检索到的RX_DL值，接收方确定FF_DL（FF_DLmin）在表14中的最小值（有关接收方如何确定RX_DL定义，请参见9.5.4）。

只有长度大于4,095字节的消息才能使用转义序列，其中第一个PCI字节（字节＃1）的低半字和整个第二个PCI字节（字节＃2）的所有位都设置为0。这告诉网络层根据第一帧中包含的32位值来确定FF_DL，该值从第三个字节（MSB）到第六个字节（LSB）。

9.6.3.2 FF_DL error handling

如果网络层接收到一个指示为FirstFrame且CAN_DL < 8的N_PDU，则网络层应忽略FF N_PDU。如果网络层接收到一个FF_DL大于可用接收缓冲区大小的FirstFrame，则应将其视为错误条件。网络层应中止消息接收并发送带有参数FlowStatus = Overflow的FC N_PDU。

如果网络层接收到一个FF_DL小于FF_DLmin的FirstFrame，网络层将忽略接收到的FF N_PDU并且不会传输FC N_PDU。

注意：只支持12位版本的FF_DL的传统设备，如果使用转义序列，则不会发送流控制帧，因为这些设备会将FF_DL解释为小于FF_DLmin，并且因此不会发送FC N_PDU。

如果接收到的第一帧具有转义序列（其中PCI字节1的低半字节和PCI字节2的所有位都设置为0），并且FF_DL =< 4,095，则网络层应忽略FFN_PDU并不传输FC N_PDU。

9.6.4 ConsecutiveFrame N_PCI parameter definition

9.6.4.1 CF N_PCI byte

接收到的CAN帧的有效数据长度CAN_DL必须与在接收第一帧（FF）过程中确定的RX_DL值相匹配。只有多帧传输中的最后一个CF可能包含少于RX_DL字节。

9.6.4.2 Transmitter requirements for last consecutive frame

一个多帧消息的发送器应该仅发送最后（或唯一）连续帧，并且字节数要符合要求。请参考以下示例以便理解（正常寻址）。

例1：最后一个CF应该发送9个数据字节，并填充为12个字节。

例2：最后一个带有3个字节数据的CF应该以CAN_DL为8或4发送（取决于使用CAN帧优化的情况，参见10.4.2.1和10.4.2.2）。

9.6.4.3 SequenceNumber (SN) parameter definition

参数SN在连续帧（CF）N_PDU中用于指定以下内容：

连续帧的数字升序排列；
对于所有分段消息，SN应从零开始；第一帧（FF）的值应为零；
N_PCI字段中不包括显式的SequenceNumber，但应被视为段号零；
紧随FF之后的第一个CF的SN应设置为1；每传输一个分段消息时，SN应递增一次；
SN值不受任何流控制（FC）帧影响；
当SN达到15时，它将循环回零以供下一个CF使用。

这将导致表16中给出的序列。

请参阅表17以了解SN值的定义。

9.6.4.4 SequenceNumber (SN) error handling

如果接收到一个带有与9.6.4.3中定义不符的意外SequenceNumber的CF N_PDU消息，则应中止消息接收，并且网络层应向相邻的上层发出一个N_USData.indication服务调用，参数为<N_Result> = N_WRONG_SN。

9.6.5 FlowControl N_PCI parameter definition

9.6.5.1 FlowStatus (FS) parameter definition

参数FlowStatus（FS）表示发送网络实体是否可以继续进行消息传输。发送网络实体应支持FS参数的所有指定（非保留）值。

表18定义了FS的取值范围。

9.6.5.2 FlowStatus (FS) error handling

如果接收到具有无效（保留）FS参数值的FC N_PDU消息，则应中止消息传输，并且网络层应向相邻的上层发出带有参数<N_Result> = N_INVALID_FS的N_USData.confirm服务调用。

9.6.5.3 BlockSize (BS) parameter definition

BS参数应编码在FC N_PCI的第2个字节中。BS的单位是每个块中CF N_PDU的绝对数量。例如，如果BS等于20，则该块将由20个CF N_PDU组成。只有分段数据传输中连续帧的最后一个块可以少于BS数量的帧。表19提供了FC N_PCI字节的概述。

9.6.5.4 SeparationTime minimum (STmin) parameter definition

STmin参数应编码在FC N_PCI的第3个字节中。该时间由接收实体指定。STmin参数值指定了两个连续帧网络协议数据单元（CFs）传输之间允许的最小时间间隔。参见表20。

STmin的测量从连续帧（CF）传输完成后开始，并在请求传输下一个CF时结束。例如，如果STmin等于10（0A16），则连续帧网络协议数据单元之间授权的最小ST为10毫秒。

9.6.5.5 SeparationTime minimum (STmin) error handling

如果接收到带有保留的STmin参数值的FC N_PDU消息，则发送网络实体应该使用ISO 15765的这部分规定的最长STmin值（7F16 = 127毫秒），而不是从接收网络实体接收到的值，用于正在进行中的分段消息传输的持续时间。如果分段数据传输（N_As + N_Cs）两个连续CF之间的时间小于接收方通过STmin命令的值，则不能保证接收方能正确地接收和处理所有帧。无论如何，分段数据传输的接收方都不需要监视对STmin值是否遵守。

9.6.5.6 Dynamic BS/STmin values in subsequent FlowControl frames

如果服务器是分段消息传输的接收者（即FlowControl帧的发送方），它可以选择在同一分段消息的后续FC（CTS）帧中使用相同的BS和STmin值，也可以从一个FC到另一个FC帧变化这些值。如果连接到符合ISO 15765标准的车载诊断网络的客户端是分段消息传输的接收者（即FlowControl帧的发送方），则应在同一分段消息的后续FC（CTS）帧中使用相同的BS和STmin值。如果客户端是分段数据传输的发送方（即FlowControl帧的接收者），则应根据每个相同分段数据传输期间接收到的每个FC（CTS）调整BS和STmin值。

注意：对于车载网关实现（即路由发生在OSI第4层；参见ISO 14229-2[8]），车辆制造商可以选择在单个分段消息传输过程中使FC参数BS和STmin变化，或者将这些参数设置为静态值。根据这个设计决策，车辆制造商需要确保服务器实现与相应的车载网关实现兼容。

9.7 Maximum number of FC.WAIT frame transmissions (N_WFTmax)

这个变量的目的是为了避免在故障情况下通信发送节点可能被连续等待，从而防止其被连接。该参数仅适用于通信对等体，并不传输，因此不属于FC协议数据单元的一部分。

N_WFTmax参数应指示接收方可以连续传输多少个FC N_PDU WAITs。
N_WFTmax参数的上限应在系统生成时由用户定义。
N_WFTmax参数仅在消息接收期间用于接收网络实体。
如果N_WFTmax参数值设置为零，则FlowControl将依赖于FlowControl continue仅发送FC N_PDU CTS。该网络实体不会使用FlowControl wait（FC N_PDU WT）

9.8 Network layer timing

9.8.1 Timing parameters

性能要求值是与规范相符的每个通信节点必须满足的绑定通信要求。某个应用程序可以在表21定义的范围内定义特定的性能要求。超时值被定义为高于性能要求的值，以确保系统正常运行，并克服无法满足性能要求的通信条件（例如高总线负载）。指定的超时值应视为任何给定实现的下限。真实超时时间不得晚于指定超时值+50%。

网络层在检测到错误条件时，应向网络层服务用户发出适当的服务原语。如果通过N_AI（详见8.3.2.1和9.4.6.2）标识的对等协议实体之间建立了通信路径，则为该通信路径静态分配一组网络层定时参数。选择网络层定时参数时，除了使用N_AI外不使用其他信息。如果不同的用例需要不同的网络层定时参数，则应使用不同的N_AI参数建立单独的通信路径，例如为每个需要不同网络层定时参数的个别用例定义不同的N_TA和/或N_SA。

图10显示了未分段消息的网络层时序参数，而表21定义了网络层时序参数值及其对应的起始和结束位置，基于数据链路层服务。

Key:

发送方N_USData.req：会话层向传输/网络层发出一个未分段的消息
发送方L_Data.req：传输/网络层将SingleFrame传输到数据链路层，并启动N_As计时器。
接收器L_Data.ind：数据链路层向传输/网络层发出CAN帧的接收通知
接收器N_USData.ind：传输/网络层向会话层发出未分段消息的完成通知
发送器L_Data.con：数据链路层向传输/网络层确认CAN帧已被确认；发送器停止N_As计时器
发送器N_USData.con：传输/网络层向会话层发出未分段消息的完成通知

Figure 10 --- Placement of network layer timing parameters --- Unsegmented message

图11显示了分段消息的网络层时序参数，而表21定义了基于数据链路层服务的网络层时序参数值及其对应的起始和结束位置。

Key:

发送方 N_USData.req：会话层向传输/网络层发出分段消息

发送方 L_Data.req：传输/网络层将 FirstFrame 传输到数据链路层并启动 N_As 计时器
接收方 L_Data.ind：数据链路层向传输/网络层发出 CAN 帧的接收；接收方启动 N_Br 计时器

接收方 N_USDataFF.ind：传输/网络层向会话层发出分段消息的 FirstFrame 的接收

发送方 L_Data.con：数据链路确认已经确认了 CAN 帧给传输/网络层；发送者停止 N_As 计时器并启动 N_Bs 计时器
接收器L_Data.req：传输/网络层将FlowControl（ContinueToSend和BlockSizevalue = 2d）传输到数据链路层，并启动N_Ar计时器。
发送者L_Data.ind：数据链路层向传输/网络层发出CAN帧的接收；发送者停止N_Bs计时器并启动N_Cs计时器。

接收器L_Data.con：数据链路层向传输/网络层确认CAN帧已被确认；接收器停止N_Ar计时器并启动N_Cr计时器。
发送方L_Data.req：传输/网络层将第一个ConsecutiveFrame传输到数据链路层，并启动N_As计时器。
接收器L_Data.ind：数据链路层向传输/网络层发出CAN帧的接收；接收器重新启动N_Cr计时器。

发送方L_Data.con：数据链路层向传输/网络层确认CAN帧已被确认；发送方停止N_As计时器，并根据前一个FlowControl的分离时间值（STmin）启动N_Cs计时器。
发送方L_Data.req：当N_Cs计时器到期（STmin），传输/网络层向数据链路层传输下一个连续帧，并启动N_As计时器。
接收器L_Data.ind：数据链路层向传输/网络层发出CAN帧的接收通知；接收器停止N_Cr计时器并启动N_Br计时器。

发送方L_Data.con：数据链路层向传输/网络层确认CAN帧已被确认；发送方停止N_As计时器并启动N_Bs计时器；发送方正在等待下一个流控制。
接收器L_Data.req：传输/网络层将流量控制（等待）传输到数据链路层，并启动N_Ar计时器。
发送方L_Data.ind：数据链路层向传输/网络层发出CAN帧的接收；发送方重新启动N_Bs计时器

接收方L_Data.con：数据链路层向传输/网络层确认CAN帧已被确认；接收方停止N_Ar计时器并启动N_Br计时器。
接收器L_Data.req：传输/网络层将流控制（ContinueToSend）传输到数据链路层，并启动N_Ar计时器。
发送方L_Data.ind：数据链路层向传输/网络层发出CAN帧的接收通知；发送方停止N_Bs计时器并启动N_Cs计时器。接收方L_Data.con：数据链路层向传输/网络层确认CAN帧已被确认；接收方停止N_Ar计时器并启动N_Cr计时器。
发送者L_Data.req：传输/网络层将ConsecutiveFrame传输到数据链路层，并启动N_As计时器。
接收器L_Data.ind：数据链路层向传输/网络层发出CAN帧的接收通知；接收器重新启动N_Cr计时器。

发送器L_Data.con：数据链路层向传输/网络层确认CAN帧已被确认；发送器停止N_As计时器，并根据前一个FlowControl的分离时间值（STmin）启动N_Cs计时器。
发送方L_Data.req：当N_Cs计时器到期（STmin），传输/网络层向数据链路层传输最后一个连续帧，并启动N_As计时器。
接收器L_Data.ind：数据链路层向传输/网络层发出CAN帧的接收；接收器停止N_Cr计时器。

接收器N_USData.ind：传输/网络层向会话层发出分段消息的完成。

发送器L_Data.con：数据链路层确认已经确认了CAN帧，发送者停止N_As计时器。

发送者N_USData.con：传输/网络层向会话层发出分段消息的完成。

Figure 11 --- Placement of network layer timing parameters --- Segmented message

9.8.2 Network layer timeouts

表22定义了网络层超时的原因和操作。

9.8.3 Unexpected arrival of N_PDU

意外的N_PDU被定义为在预期顺序之外被节点接收到的N_PDU。它可以是ISO 15765这部分定义的N_PDU（SF N_PDU、FF N_PDU、CF N_PDU或FC N_PDU），其接收顺序与正常预期不符，也可以是无法根据ISO 15765这部分给出的定义解释的未知N_PDU。

一般规则是，应忽略来自任何节点的意外N_PDU的到达，但SF N_PDUs和物理寻址的FF N_PDUs除外；功能性寻址的FirstFrames应被忽略。当指定动作为忽略意外N_PDU时，这意味着网络层不会通知上层其到达情况。

根据网络层设计决策来支持全双工或半双工通信，对于"意外"的解释会有所不同。

在半双工通信中，两个节点之间的点对点通信只能单向进行。
使用全双工通信，两个节点之间可以同时进行双向的点对点通信。

除了这个网络层设计决策之外，还需要考虑到可能正在进行与接收到的意外N_PDU中包含的相同地址信息（N_AI）相关的节点的接收或传输。表23定义了在接收到意外N_PDU时，根据实际网络层内部状态（NWL状态）和支持半双工或全双工通信的设计决策来确定网络层行为。只有当接收到的N_PDU包含与正在进行中的接收或传输同时具有相同N_AI时，表23才适用。如果接收到的N_PDU的N_AI与分段消息不同，则应继续进行正在进行中的接收/传输。

9.8.4 Wait frame error handling

如果接收方连续传输了N_WFTmax个流控等待网络协议数据单元（FC N_PDU WAIT），并且在此之后无法满足发送流控继续发送网络协议数据单元（FC N_PDU CTS）的性能要求，则接收方应中止消息接收，并向上层发出带有<N_Result>设置为N_WFT_OVRN的N_USData.indication。通过将<N_Result>设置为N_TIMEOUT_Bs，通知消息的发送者关于已中止的消息接收。（由于缺少来自接收方的流控N_PDU，导致发送方发生了一个N_Bs超时。）

9.9 Interleaving of messages

网络层协议应能够同时传输不映射到同一N_AI的不同消息。这是为了确保接收方能以一致的方式重新组装接收到的网络协议数据单元。该方案使得例如需要在不同子网之间并行处理不同消息传输的网关操作成为可能。

10 Data link layer usage

10.1 Data link layer service parameters

以下数据链路层服务参数在ISO 11898-1中定义：

: CAN帧数据;
: 数据长度代码;
: CAN标识符;
<Transfer_Status>: 传输状态;
: 帧格式（CAN，CAN FD，基本: 11位，扩展: 29位）（见表4）。

10.2 Data link layer interface services

10.2.1 L_Data.request

服务原语请求传输<数据>，该数据将被映射到由<标识符>选择的数据链路协议数据单元的特定属性中。 <标识符>应提供对用于传输<数据>的特定寻址格式的引用：

10.2.2 L_Data.confirm

该服务原语确认了特定<标识符>的L_Data.request服务的完成。

参数<Transfer_Status>提供了服务请求的状态。

10.2.3 L_Data.indication

服务原语指示一个数据链路层事件给相邻的上层，并传递由标识符所确定的：

10.3 Mapping of the N_PDU fields

10.3.1 Addressing formats

网络层数据的交换支持三种寻址格式：普通、扩展和混合寻址。每种寻址格式都需要不同数量的CAN帧数据字节来封装与要交换的数据相关联的寻址信息。因此，单个CAN帧中传输的数据字节数取决于所选择的寻址格式类型。根据ISO 11898-1中定义的数据链路层服务和服务参数，10.3.2到10.3.5指定了每种寻址格式基于映射机制。

10.3.2 Normal addressing

表24定义了N_PDU参数到CAN帧的映射，其中寻址格式

表25定义了N_PDU参数到CAN帧的映射，其中寻址格式是正常的，并且N_TAtype指示消息是功能性的。

10.3.3 Normal fixed addressing

正常固定寻址是正常寻址的一个子格式，其中将地址信息映射到CAN标识符中进一步定义。在上述一般情况下的正常寻址中，N_AI和CAN标识符之间的对应关系是开放的。对于正常固定寻址，只允许使用29位CAN标识符。根据目标地址类型（N_TAtype），表26和表27定义了将地址信息（N_AI）映射到CAN标识符中的方式。N_PCI和N_Data被放置在CAN帧数据域中。表26定义了当N_TAtype指示消息为物理时的正常固定寻址方式。

表27定义了正常固定地址分配，其中N_TAtype表示该消息是功能性的。

10.3.4 Extended addressing

表28定义了N_PDU参数到CAN帧的映射，其中地址格式是扩展的，并且N_TAtype指示消息是物理层的。

表29定义了N_PDU参数到CAN帧的映射，其中地址格式是扩展的，并且N_TAtype指示消息是功能性的。

10.3.5 Mixed addressing

10.3.5.1 29 bit CAN identifier

混合寻址是在Mtype设置为远程诊断时使用的寻址格式。根据目标地址类型（N_TAtype），表30和表31定义了地址信息（N_AI）映射到29位CAN标识符方案和第一个CAN帧数据字节的方式。 N_PCI和N_Data被放置在CAN帧数据字段的剩余字节中。

10.3.5.2 11 bit CAN identifier

混合寻址是在Mtype设置为远程诊断时使用的寻址格式。表32和表33定义了地址信息（N_AI）映射到11位CAN标识符方案中的方式。对于每个N_SA、N_TA和N_TAtype的组合，可以使用相同的CAN标识符。 N_AE放置在CAN帧数据字段的第一个数据字节中。 N_PCI和N_Data放置在CAN帧数据字段的其余字节中。

10.4 CAN frame data length code (DLC)

10.4.1 DLC parameter

DLC参数指定了CAN帧中传输的数据字节数。ISO 15765的这部分并没有对CAN帧中数据字段的长度提出任何要求，除非考虑到网络层协议数据单元大小所隐含的要求。根据ISO 15765这一部分定义实现网络层的应用程序可能会将所有CAN帧填充到其完整长度（参见10.4.2.1），或者优化DLC为适用于网络层协议数据单元长度（参见10.4.2.2）。符合ISO 11898-1标准（CAN FD帧类型）的CAN帧在DLC值大于8时可能需要强制填充（参见10.4.2.3）。

10.4.2 CAN frame data

10.4.2.1 CAN frame data padding (TX_DL = 8)

如果使用此解决方案，即使要传输的N_PDU短于8个字节，DLC始终设置为8。发送方必须填充帧中未使用的字节，例如在表34中所示。特别是对于SF、FC帧或分段消息的最后一个CF来说可能会出现这种情况。除非另有规定，默认值CC16应用于帧填充，以便最小化线上插入和位更改。

CAN帧的DLC参数由发送方设置并由接收方读取，以确定网络层要处理的每个CAN帧的数据字节数。不能使用DLC参数来确定消息长度；该信息应从消息开头处的N_PCI信息中提取出来。

10.4.2.2 CAN frame data optimization (TX_DL = 8)

如果使用这种解决方案，DLC不一定需要为8。如果要传输的N_PDU长度小于8个字节，则发送方可以通过缩短CAN帧数据来优化CAN总线负载，只包含N_PDU占用的字节数（不填充未使用的数据字节）。CAN帧数据优化仅适用于SF、FC帧或分段消息的最后一个CF。示例见表35。CAN帧的DLC参数由发送方设置并由接收方读取，以确定网络层要处理的每个CAN帧中的数据字节数。DLC参数不能用于确定消息长度；此信息应从消息开头处的N_PCI信息中提取出来。

10.4.2.3 Mandatory padding of CAN FD frames (TX_DL > 8)

根据ISO 11898-1标准，数据长度代码（DLC）从0到8指定了CAN帧有效负载的字节长度（一对一映射）。对于N_PDU长度，可以应用最多8个字节的数据填充（参见10.4.2.1）或DLC数据优化（参见10.4.2.2）。ISO 11898-1中将DLC值从9到15分配给非线性离散值，用于CAN帧有效负载长度达到64个字节。为了防止传输未初始化的数据，在N_PDU大小与ISO 11898-1:2015定义的离散长度值不相等时，必须进行CAN帧数据填充。表36中显示了一个示例。对于DLC值从9到15，只能使用强制填充。如果没有另外指定，默认情况下应使用CC16作为填充值，以最小化在传输线上插入和更改比特位数。

CAN帧的DLC参数由发送方设置，并由接收方读取，以确定每个CAN帧要由网络层处理的数据字节数。 DLC参数不能用于确定消息长度；此信息应从消息开头的N_PCI信息中提取出来。

NOTE ISO 11898-1:2015, DLC table value 9 leads to a CAN FD frame payload length of 12 byte.

10.4.3 Data length code (DLC) error handling

根据N_PCI值的不同，网络层可以计算接收到的CAN帧中CAN DLC参数的最小预期值。对于DLC值小于预期（对于填充CAN帧应小于8，或者对于使用数据优化实现时小于网络协议数据单元大小所暗示的）的CAN帧接收，网络层将忽略而无需采取任何进一步操作。详细信息请参见9.6中特定错误处理部分。