仰晓芳，喻晓军，汪贵冬，周圣文，齐家军
（安徽海博智能科技有限责任公司，安徽 芜湖 241200）
引言随着“智慧矿山”概念的提出，矿山自动驾驶的研究和应用也日益增多。由于自动驾驶的功能越来越复杂，且需要融合多传感器信息，另AP（Adaptive）AUTOSAR 自适应汽车开放式架构的系统具有高性能、高运算、动态可扩展性的特点，因此，AP AUTOSAR 的架构未来被会广泛地应用在自动驾驶产品中[1-3]。其中诊断系统作为AP AUTOSAR 的重要组成部分，其开发是基于DoIP（Diagnostic Communication over IP）和UDS（Unified Diagnostic Services）协议，实现UDSonIP（UDS on Internet Protocol implementation）的诊断[4-9]。
以华为MDC300F 为平台，基于AP AUTOSAR 和UDS 相关标准，二次开发了矿车自动驾驶故障诊断系统，并深入介绍了AP AUTOSAR 诊断系统的整体框架和相关模块的设计。以华为的MCDTool 作为上位机，与控制器实现DoIP 通信进行诊断相关服务的测试，实验结果表明，该系统能准确判断出故障，并记录故障发生时的车辆信息，便于测试和维修人员定位故障[1-2]。
1 AP AUTOSAR 诊断简介AP AUTOSAR 标准定义了一套基于service 和APIs 两种接口类型的ARA（AUTOSAR Runtime for Adaptive Applications）运行环境，并由平台服务和平台基础为分组的多个功能集群组成。其主要特点有：面向服务的架构，实时性高，安全性高，动态可扩展等。
本文采用的AP AUTOSAR 架构如图1 所示。
AP AUTOSAR 诊断基于AP AUTOSAR，位于平台基础层，简称诊断管理（DM）。诊断管理模块可以支持多个ECU 的应用场景，且支持应用部署的动态可扩展[3]。诊断管理由UDS 传输层和诊断应用层组成，其中诊断应用层又包含诊断通信管理和诊断事件存储管理两部分，其结构框图如图2 所示。
2 AP AUTOSAR 诊断系统的开发2.1 诊断系统的传输层AP AUTOSAR 诊断系统支持标准的C++API，实现与UDS 传输层的连接。但是目前，AP AUTOSAR 的诊断只支持基于以太网的传输协议，将来的AP AUTOSAR 版本也将支持不同总线的传输协议，比如：CAN、CANFD 和Flexray 等[4]。
AP AUTOSAR 诊断系统的传输层主要实现的功能有：转发UDS 诊断请求和回复的消息；支持DoIP协议；通过UDS 诊断请求地址（物理寻址和功能寻址）调度不同的ECU，从而与ECU 建立通信。
2.2 诊断通信管理子集诊断通信管理子集实现了上位机与ECU 的诊断服务功能，类似于CP AUTOSAR 中的DCM 功能。目前，诊断通信管理子集只支持部分有限的诊断服务，后续将会扩展支持更多的诊断服务。
诊断通信管理中主要的功能有：诊断会话和UDS服务功能。其中，诊断会话既能响应不同的诊断ECU和client 的会话消息，即支持伪并行处理，又能在默认会话层支持client 端的全并行处理。本文中的诊断通信管理主要支持$10、$11、$14、$19、$22、$27、$2E等几种常见的诊断服务功能，其中0x22 和0x2E 服务支持调用外部函数实现诊断自适应应用功能，即通过二次开发矿车系统诊断DiagAPP 实现特有的DID（Data Identifier）读写功能。该二次开发读写DID 的功能主要是由DiagAPP 提供服务及callback 函数[5]，若诊断管理收到DID 请求，查询到服务后会调用DiagAPP的读/写callback 函数，将收到的返回值发送出去，其动态图如图3 所示。
2.3 诊断事件存储管理子集诊断事件存储管理子集主要负责故障码（DTC）的存储与管理。Diagnostic Event 是故障诊断和其相关数据存储的基本单元，每个故障码对应了一个Diagnostic Event。二次开发的DiagAPP 实时监测Diagnostic Event 的状态，在故障触发或者恢复时[6]，DiagAPP 会及时将Diagnostic Event 的状态信息上报到DM，同时DM会将该事件的状态信息、快照数据和扩展数据存储到非易失性存储区域，从而达到故障码的存储与管理。其中二次开发的DiagAPP 上报故障码的动态图见图4。
2.4 AP AUTOSAR 诊断平台搭建及实现以MDC300F 为平台并将其集成到矿车中，与上位机MCDTool 完成组网连接，通过上位机MCDTool远程访问MDC300F，对矿车系统进行诊断，见图5。
在上述硬件平台的基础上，华为需要基于矿车诊断系统的需求对AP AUTOSAR 的诊断管理模块进行配置，并可以提供二次开发故障诊断功能的C++API，包括DID 的读写和故障码的上报。本文主要基于AP AUTOSAR 开发自己的APP 实现DID 的读写和故障码的上报，达到开发矿车自动驾驶诊断特有功能部分，并将该诊断系统应用于矿车自动驾驶系统中。上位机和MDC 诊断服务管理以及二次开发APP间的关系如图6 所示。
3 测试及结果搭建测试台架，PC 端启动MCDTool 远程登录车辆，并将二次开发的APP 编译生成的可执行文件部署至车辆的MDC300F 产品中，其中MCDTool 远程登录车辆显示界面如图7 所示。本文以二次开发功能相关服务进行测试，具体测试服务有0x22、0x2E、0x19、0x14，其中测试的DID 有F189 -软件版本信息、F1A2-产品的生产日期以及不支持的F197，测试的故障码以矿车连接的惯导丢失故障码0xC03887 测试为例。诊断报文的发送和解析参照ISO13400-2 和ISO14229-5。
3.1 DID 读写数据服务测试软件版本和生产日期可以协助开发或者维修人员定位产品所支持的功能，以及当前产品是否存在问题，是车辆诊断必不可少的诊断信息，故本次测试以DID_F189 和DID_F1A2 为例测试。通过MCDTool 测试了二次开发的DID 读取，DID 写入，以及不在范围内的DID 读取和写入三种情况，具体解析的UDS 测试数据如表1 所示。
表1 DID 读写服务测试
由以上测试结果，可以验证DID 读写数据服务测试通过，该矿车自动驾驶系统DID 读写数据二次开发功能正常。
3.2 读取故障码测试惯导作为车辆定位数据的主要来源，是矿车自动驾驶不可或缺的一部分，以惯导丢失故障-0xC03887为例测试二次开发故障码的功能[7]。主要测试惯导丢失后故障码状态位变化、快照数据以及扩展数据的记录情况。MCDTool 解析的测试数据如表2 所示。
表2 读取故障码测试
由以上测试结果，可以验证读取故障码服务测试通过，且矿车自动驾驶系统上报故障码二次开发功能正常。
3.3 清除故障码测试基于上述惯导丢失故障测试，恢复惯导丢失状态，紧接着测试$14 服务清除故障码的测试。MCDTool解析的测试数据如表3 所示。
表3 清除故障码测试
由以上测试结果，可以验证清除故障码服务测试通过，该矿车自动驾驶系统二次开发上报的故障码能正常清除。
4 结论未来自动驾驶领域采用AP AUTOSAR 的架构会越来越多，通过搭载第三方成熟的软硬件平台，快速开发出符合自己产品的软件成为趋势。开发出的软件具有高可靠、一致性强、稳定性高的特点，还能大大降低产品开发成本，加快开发周期[8-9]。
本文以MDC300F 为平台，结合矿车自动驾驶需要读取和写入车辆相关状态信息，以及针对矿车实际的硬件和系统的故障监测进行二次开发，实现了基于AP AUTOSAR 的矿车自动驾驶诊断的应用，对矿车自动驾驶领域的研发有着积极意义。
