标签: UDS

1、服务概述 汽车工业的很多领域都有严格的国际标准，其中针对车载诊断的ISO14229规定了车载诊断服务的通用需求(UDS)，UDS主要应用于OSI模型的应用层，UDS协议根据功能的不同定义了26种诊断服务。 为了应对网联汽车日益增加的安全风险，在ISO14229-1的2020版本增加了29服务。29服务英文名称为Authentication Service，译为认证服务。通过名称可以看出29服务的目的是为客户提供一种身份认证的方法。当客户想获取一些有访问限制的数据时来验证客户的身份，这些限制可能是由于安全或排放相关的原因。本文将详细介绍29服务。 29服务一般在如下场景中使用： 1. 需要读取特定内存地址的数据； 2. 上传或下载控制器数据； 3. 关于车身安全或者会影响车身控制器属性。 传统的27服务不能满足这些需求，因此新版本的ISO14229协议增加了29服务，来实现基于以太网的身份认证。 2、背景知识介绍 对称加密：加密和解密使用相同密钥的加密算法。 非对称加密：一对加密密钥和解密密钥，用户加密后所得的信息，只能用该用户的解密密钥才能解开。如果知道了其中一个，不能计算出另一个。公开的加密密钥为公钥，不公开的解密密钥为私钥。 PKI：PKI的全称是Public Key Infrastructure，译为公钥基础设施。PKI是包括硬件、软件、人员、策略和规程的集合，用来实现基于公钥密码体制的密钥和证书的产生、管理、存储、分发和撤销等功能。用来建立不同实体间的“信任”关系。 3、服务介绍 29服务支持两种认证方式，如下图所示： APCE: 采用非对称加密的基于PKI证书交换程序的认证 ACR: 采用对称或非对称加密的基于挑战确认（Challenge-Response）流程的认证 。 图1-29服务支持的两种认证方式 3.1 APCE认证流程 图2-APCE的认证流程图 上图是APCE的认证流程图，包括单向认证和双向认证。 3.1.1单向认证 Client通过V erifyCertificateUnidirectiona l(2) 向Server发送带有Client公钥的证书。 Server收到证书后会验证证书的有效性(3)，如果Client不合法，则停止流程，验证失败，返回否定响应，如果合法则继续之后的流程。 Server创建Challenge(4)，并向Client发送针对证书的Challenge消息(7)，请求Client对所发证书的所有权证明，消息中包含认证所需的随机数。 Client收到Challenge后使用私钥计算所有权证明客户端(10)，并且通过SubFunction ProofOfOwnership(11)发送所有权证明客户端。 Server使用来自Client的公钥验证所有权客户端(12)，与Challenge消息比较，如果验证成功，则根据访问权限(14)，授予对诊断对象的访问权限。并向Client发送相应的响应,表示认证成功。 3.1.2双向认证 Client创建Challenge客户端(1)，并通过SubFuntion Vertify Certificate Bidire- ntional向Server发送Challenge客户端和含有公钥的证书客户端。 Server验证证书是否有效(3)，如果无效，则验证失败，返回否定响应。如果有效，则进行后续的流程。 Server创建Challenge服务端，并且通过客户端发来的Challenge和自己的私钥计算出所有权证明(6)，并向Client发送Challenge服务端、服务端证书、服务端的所有权证明以及临时公钥(7)。 Client根据所得的临时公钥验证服务器证书和所有权证明是否有效(8)，有效之后根据服务端发来的Challenge和客户端私钥计算客户端所有权证明(10)，并通过ProofOfOwnership向Server发送客户端所有权证明(11)。 Server收到所有权证明后进行验证是否通过(12)，通过后发送访问权限(14)以及相应的响应(15)，认证成功。 图中(5)，(9)跟安全诊断通信有关，(16)，(17)，(18)跟创建会话密钥有关。 3.2ACR认证流程 图3-ACR的认证流程图 3.2.1ACR认证前提条件 非对称加密：具有客户端密钥对：客户端存在客户端私钥，服务器中存在客户端公钥。如果是双向认证的话，还需要在服务器端加个密钥对：客户端存在服务器公钥，服务器端存在服务器私钥。 对称加密：和27服务的流程相似，在客户端和服务端同时存在对称密钥。 3.2.2单向认证 Client通过RequestChallengeForAuthentication请求验证(1)。 Server创建Challenge数据(2)并发送Challenge数据(3)。 Client计算所有权证明(5)。 Client通过VerifyProofOfOwnershipUnidirectional发送所有权证明(7)。 Server验证所有权证明(8)，如果验证成功发送访问权限。 其中(14)，(15)，(16)是关于建立会话密钥使用的。 3.2.3双向认证 Client 通过SubFunction R equestChallengeForAuthentication请求验证 (1) 。 Server 创建Challenge数据(2)，并且发送Challenge数据(3)。 Client 创建Challenge数据(4)，并且计算 Client 所有权证明，并通过VerifyProofOfOwnershipBidirectional发送给服务器端(7)。 Server 验证所有权证明(8)。 如果验证成功， Server 计算所有权证明(9)，并且发送访问权限(11)。 Client 验证服务器的所有权证明(13)，如果验证成功，访问成功。 3.3子功能介绍（部分） 表1-29服务部分子功能 4、CANdelaStudio中配置29服务 在CANdelaStudio中打开CDDT文件，选择Protocol Service,在这里可以对29服务的请求和响应的格式进行编辑。 图4-29服务编辑 打开CDD文件，在Base Variant下选择Authentication，就可以对29服务的参数进行编辑。 图5-29服务参数编辑 在States下Dependencies可以配置每个服务在各个状态下的支持情况。 图6-服务状态编辑 5、CANoe中29服务的实现 以CANoe中29服务的Demo工程为例，来介绍29服务的认证过程。 图7-29服务Demo工程 在诊断控制台中可以看到关于29服务的一些子功能。每个子功能都有不同的作用，每个认证方法的区别在于发送的子功能不同。可以根据上面的流程来决定使用哪些子功能，例如要用APCE单向认证方法的话，发送29 01和29 03服务，APCE双向认证的话发送29 02和29 03服务。用哪一个认证方法是OEM自定义的。 图8-29服务子功能 Security Open Security Manager，在这里就可以导入关于29服务的文件（X.509）。 图9-29服务配置 在设置好29服务文件后，在Security Configuration就会显示刚才创建的文件，将证书和通道匹配好后就可以发送29服务。 图10-29服务证书和通道匹配 在Panel面板中，可以发送29服务，选择单向认证或者双向认证。发送之后在Trace中可以查看认证的过程。 图11-29服务Panel面板 6、总结 29服务和27服务的功能比较相似，都是为了防止ECU的数据和软件安全受到威胁，但是27服务提供的安全机制已经不能满足现在车辆诊断功能面临的新的安全威胁，29服务就是为了弥补这些缺陷而产生的。 由于27 服务 的安全访问控制手段缺乏灵活性，29 服务 引入了PKI和证书认证体系，可以灵活地给诊断的参与者分配权限 ,29服务还适用于多客户端，在车辆网联化共享化的趋势下很好的应对了这些新的安全威胁。 北汇信息专注于其汽车电子网络通信、诊断刷写、逻辑功能测试开发服务，期待进一步沟通交流、共享合作的机会。 参考文献：ISO14229-1(2020) 注：图片部分来源于ISO14229-1(2020)、CANoe16、CANdelaStudio18

一、背景介绍 在车载诊断中常用的诊断协议有ISO 14229等，在协议中主要定义了诊断请求、诊断响应的报文格式及ECU该如何处理诊断请求的应用。其中ISO 14229系列标准协议定义了用于行业内诊断通信的需求规范，也就是UDS。UDS主要应用于OSI七层模型的第七层——应用层，它支持的汽车总线包括：CAN、LIN、FlexRay、Ethernet及K-LINE。UDS中的服务根据其功能分为6大类，共26种。其中包含的0x19服务（ReadDTCInformation）则是UDS中的重中之重。那么我们今天就一起进入到19服务中，感受其中的奥秘。 服务介绍 19服务（ReadDTCInformation）用于读取ECU的DTC故障信息，此服务允许客户端从服务器读取诊断故障代码（DTC）的相关信息。此服务包含28个子服务(Subfunction)，常用的5种子服务如下： 0x01 reportNumberOfDTCByStatusMask（读取客户端定义状态掩码匹配的DTC数量） 0x02 reportDTCByStatusMask（读取客户端定义状态掩码匹配的DTC） 0x04 reportDTCSnapshotRecordByDTCNumber（检索客户端定义DTC掩码的快照数据） 0x06 reportDTCExtDataRecordByDTCNumber（读取某个DTC及其相关的扩展数据，扩展数据包括DTC状态，优先级，发生次数，时间戳，里程等。） 0x0A reportSupportedDTC（读取ECU支持的所有DTC的状态，包含支持的各个DTC编号以及相关状态） 今天主要解析19服务中的04子服务，也就是检索客户端定义DTC的快照号对应的快照记录数据，在AUTOSAR中也叫冻结帧。 04子服务介绍 1、快照数据概念介绍 前面讲19服务常用子服务的时候，提到了Subfunction为04的子服务，使用04子服务对服务端进行请求，可以获取DTC发生时记录的快照数据。那04子服务是如何获取快照数据的呢？首先我们需要理解什么是快照数据。从ISO 14229-1协议可知，快照数据为发生某一故障时记录的DTC的电压、发动机转速、时间戳等，从而使工程师在ECU出现故障时能及时了解车辆的历史和实时故障信息。 2、报文格式介绍 接下来通过介绍19 04子服务请求和响应的报文格式，分析报文中各个字节的相关定义。 请求格式 图 1 从图1中可知，19 04的请求报文包括四个部分，其中服务ID和Subfunction就不用过多解释了。DTCMaskRecord表示某个故障的DTC，当系统检测到一个故障发生时，则会存储其对应的故障数值，这个故障数值就是DTC。通过读取DTC可知一个故障发生时的具体位置以及原因和类型。通常UDS中DTC占3个字节，OBDⅡ占2个字节，在ISO 15031-6中定义的DTC由两个字节根基和一个字节的故障类型组成。我们通常用到的DTC格式都是由ISO 15031-6中定义的。图2是ISO 15031-6中定义的DTC的两个字节根基，图中很详细地解释了每一个Bit的含义。 图2 SnapshotRecordNumber需要提前定义，可以有多个。如SnapshotRecordNumber设置为FF，则表示读取所有的快照数据组。 响应格式 图3 图3为响应报文格式，当使用19 04对ECU进行请求时，ECU给出的肯定响应的报文格式由七部分组成。此时的DTCAndStatusRecord由三个字节的DTC和一个字节的StatusOfDTC组成，StatusOfDTC表示DTC的状态。假设现在的DTC状态为0x09，则Bit0和Bit3置1。如某个DTC一直存在并且确认，则在ECU响应的报文中的StatusOfDTC为0x09。如图4 图4 SnapshotRecordNumber这个字节表示DTC快照记录的组号；DTCSnapshotRecordNumberOfldentifiers表示快照DID的个数，占一个字节；Dataldentifier这部分由两个字节组成，表示快照数据对应的DID，DTCSnapshotRecord表示快照DID对应的具体数据。 3、实例分析 前面介绍了19 04子服务请求和响应的报文格式。掌握了理论知识，那么现在我们就到实例中去具体分析，从而加深对19 04子服务如何读取快照数据的过程的理解。 客户端对服务端发起一个读取DTC快照的请求。当前DTC为 0x123456 ，可以假设这是一个转向灯的故障码， 0x02 为快照记录组号。请求报文如图5所示。 图 5 服务端端对客户端回复了一个肯定响应。从图6中可知，当前的DTC状态掩码为 0x24 ， 0x01 表示只有一个快照DID，当然也可以包含多个快照DID，可以分别表示车速、电压等。如果有两个快照DID，此时DTCSnapshotRecordNumberOfldentifiers这个字节为0x02。快照DID为 0x4711 ，如果此时记录的是转向灯故障时当前车速的数据，那么这个 0x4711 则表示此时快照数据的名称——车速。DTCSnapshotRecord为具体的快照数据 0xA666075020 ，以16进制数值表示，通过数据类型解析后就可以得到具体的车速等信息。 图 6 在CANdelaStudio中如何设置 接下来我们看看在CANdelaStudio中如何设置19 04服务的请求及响应参数，步骤如下： ①配置DTC信息 在这个界面如图7，可以进行“DTC Code”的新增与删减，点击现有的信息可进行编辑改动； 图 7 ②设置服务 在左侧目录切换到“Base Variant”下的“Supported Diagnostic Classes”，点击“Fault Memory”； 图 8 点击图9上面标签页中的“DTCs”，然后会跳转到图9所示界面，将我们前面配置的DTC信息更新到这里来，如图9所示，当前DTC为0x123456。 图 9 点击图10上面标签页中的“Snapshot Records”，然后会跳转到图10所示界面，在这里设置快照记录组号。 图 10 ③设置肯定响应参数 首先根据客户的需求设置ECU支持的DTC状态位DTCStatus，如图11； 图 11 然后在“DTCs”页面选中名为0x123456的DTC，在“Individual for DTC P123456”下设置快照数据。例如图12中现在定义的快照DID为4711，具体的快照数据是当前车辆的Wheel Speed FR等。快照DID可以在“DIDs”中提前定义。到这里，在CANdelaStudio中关于19 04服务的请求及响应参数就设置完成了。（软件界面截图来源于CANdelaStudio 16.0版本） 图 12 总结 19 04服务的目的是读取对应DTC的快照数据，从而使工程师在进行诊断时更加快速了解故障发生时的车辆状况信息。除此之外，19服务还有其他4个常用的Subfunction，大家可以根据ISO 14229-1中的相关解释和实例进行知识扩展。 北汇信息专注于汽车电子网络通信、诊断刷写、逻辑功能测试开发服务，期待进一步沟通交流、共享合作的机会。 参考文档：ISO 14229-1（2020）