标签: 汽车诊断

在汽车行业中，AR技术的应用正悄然改变着整个产业链的运作方式，应用涵盖培训、汽修、汽车售后、 PDI交付、质检以及汽车装配等，AR技术为多个环节都带来了前所未有的便利与效率提升。 安宝特AR将以系列推文的形式为读者逐一介绍在汽车行业中安宝特AR的解决方案，揭示AR技术如何助力汽车产业实现降本增效。本期我们将重点介绍AR在汽车培训领域中的各种应用。 远程培训 方案名称：安宝特AR远程培训解决方案 应用场景：汽车行业技术培训、维修培训教学、售后培训、教学素材拍摄等 一、方案介绍与优势 传统远程培训方式中，讲师利用视频或会议软件进行授课，由他人协助利用手机等移动设备拍摄培训实操或内容，向远端学员做展示，在这一过程中存在诸多不足，由此产生了如下急需解决的痛点： 痛点1：培训画面展示问题 ，讲师操作细节难呈现给学员，画面清晰度低，拍摄角度受限；培训操作流程整体性了解差 安宝特AR解决方案： -第一视角画面、4K超高清视频传输 讲师佩戴AR眼镜，可将第一人称、4K超高清画面实时投递给会议或直播（或现场大屏幕投放），并可通过屏幕共享、文件传输、IP相机推流等拓展方案丰富操作细节，提升培训质量。 -IP全景相机 在第一视角画面展示基础上，部分培训场景仍需对整体流程做展示方便学员全方位理解，此时利用IP全景相机完善培训视角，展现整体流程。 痛点2： 培训场景受限，现场培训成本高，远程培训效果差 安宝特AR解决方案： -跨地区高质量视频传输 支持多端登录， 解放培训场景 ，降低培训成本，提升培训灵活度与学员体验 痛点3： 汽车培训实际案例资料少，且对现场实际培训情况还原度低 安宝特AR解决方案： -音视频内容云录制 讲师佩戴AR眼镜进行实操，可以在 全程音视频交互基础上随时录制 重要细节与操作，完整记录培训过程，将录像转化为固有的 可复用的培训资料 ，便于学员重复观看学习，完善企业培训资料库。 ④讲师线上实操过程中，利用移动设备进行拍摄，占用双手 安宝特AR解决方案： -多种佩戴方式，仅68g超轻主机，解放双手 二、方案效益 1 提高培训效率及培训质量 2 降低培训成本，助力远程培训，提高远程培训效果 3 留存培训资料，丰富教学素材 4 解放双手，让培训更便捷 本期从传统培训方式面临的痛点、安宝特AR解决方案及方案所产生的效益这几个角度介绍了安宝特AR汽车行业解决方案系列的远程培训，为大家展示了AR在汽车远程培训中的巨大潜力。 下一期我们将为大家带来AR远程汽车维修的内容，请持续关注我们；同时，您还可以在评论区留言您对其他AR应用场景的了解需求，我们将为您提供详尽的介绍！

一、背景 作为行业内领先的汽车维修技术培训机构，Tech Gear汽车高级诊断学院致力于为学员提供行业领先的高质量车辆诊断培训，通常情况下，他们的培训采用 现场实操课程 或 线上直播 的形式为学员演示如何进行波形诊断及维修操作，在这一过程中，Tech Gear遇到了以下这些问题： 1 讲师培训操作细节展现难 2 波形诊断画面无法同步导致培训效果差 3 培训过程难以记录，培训操作教程难存档 4 远程培训讲师与学员互动效果沟通差 二 安宝特AR汽车培训方案 针对以上痛点，Tech Gear决定采用安宝特AR远程培训解决方案，展开全面的教学实践。 1 具体方案 ①第一人称视角、4K高清视频传输+IP相机展示全方位多视角培训画面 由讲师佩戴AR眼镜，将汽车诊断的第一视角、4K超高清实时画面传递给学员，展现操作细节；IP相机呈现培训全景，多视角展示培训画面 ②实时数据共享 通过屏幕共享、文件传输的方式，将汽车诊断设备的实时数据提供给学员观看。 ③音视频内容云录制 讲师佩戴AR眼镜，在进行汽车维修诊断时针对重点内容，可以进行画面、语音等内容的录制，记录诊断维修过程中的每个细节，并生成可供学员重复查看的、非常完善的多视角画面培训资料。 ④语音与标注等功能实现高效互动 讲师佩戴AR眼镜进行实操，远端学员可以利用AR眼镜的语音、视频通信、标注、冻结、缩放、对焦等功能，及时与讲师沟通，实时解决培训疑惑。 三、方案效益 根据降低培训时间30%，节约培训成本40%， ①多视角呈现培训画面，丰富的培训细节展现形式，诊断设备数据实时共享，提升了培训质量 ②留存并形成培训资料，供学员随时查阅，提高了培训效率 ③多种互动方式，增强了培训互动性与培训效果 ④无需到达现场即可完成高质量培训，降低了培训的成本 三 客户评价 “利用 AR眼镜，我们能更直接、高效、方便地指导学员进行示波器的操作 和故障的排查了，这大大提高了我们的培训效率，还降低了一定的成本，我们期待着未来AR与汽车诊断进一步有机结合，拥有更多创新应用。“ ——Tech Gear汽车诊断学院创始人戈华飞老师 四 结语 该案例证明，AR的介入对汽车行业相关培训活动有着降本增效的效果，同时，我们的方案在汽修、售后PDI交付、质检以及汽车装配等领域也有广泛应用，您可以关注我们，解锁更多AR场景解决方案！

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）