诊断功能在AUTOSAR中开发流程

背景信息
在实现诊断功能过程中，主机厂和供应商会使用多种不同的流程，并采用不同的数据交互格式（保证流程数据一致性）和工具。但是问题往往出现在多个开发者和工具之间交互诊断描述文件时。
为了保证数据的完整性、一致性和正确性，工程师在处理数据时面临很大的挑战。但新的AUTOSAR诊断数据文件格式（ARXML）给解决此问题提供了可能性。诊断相关的基础软件模块（DCM/DEM/FIM）根据主机厂统一配置，软件模块集成通过ARXML来实现。

数据库文件格式ARXML最初发布在AUTOSAR 4.2.1版本中。AUTOSAR 4.3.0在标准UDS协议之外，增加了OBD-II（商用车排放）、WWH-OBD（重型卡车排放）、FIM和SAE J1939（国内现阶段主要用于充电桩）的相关扩展内容。另外AUTOSAR标准没有重新定义诊断协议、诊断服务以及对应数据内容，而是直接复用UDS（ISO 14229）和OBD-II(ISO 15031)等。

解决流程
全球统一诊断数据库ODX文件可作为通用诊断仪的数据格式：
->描述诊断协议：适用于ISO 14229、ISO 15031、ISO 11898、ISO 13400、ISO 15765等；
->ECU和诊断仪间的数据传输：映射到OSI七层模型，从物理层到传输以及会话层表示层等具体定义；
->诊断仪解析数据的方法：在数据库中定义诊断请求和响应的内容以及具体含义，比如对DID数据的解析（电压值、电流值、软硬件版本号等）。
注：相应的ODX介绍可参看文末关于ODX的介绍。

对于诊断仪来说，待测车辆的数据库来自哪里其实并不关心，所关心主要是数据库必须描述清除诊断数据及其结构（通过ODX UML模型实现），以往需要工程师通过手动方式将诊断数据与ECU应用层关联（工作量大不说，还也别容易出错）。
ODX数据库用于故障存储数据描述时，与ECU Software功能实现策略还是有很大的不一样性，比如用于故障DTC检测的去抖算法（时间去抖和次数去抖），会定义DTC产生机制（比如次数，当Software检测到当前状态满足记录条件，在Counter会＋1，下一个周期检测不满足会-1，直到Counter值达到预定义的值，表示DTC产生并记录在ECU掉电非易失内存中）。但是ODX整个数据库架构中完全没有这部分信息（起初定义该数据库也是偏向用于售后使用场景，对于前期软件实现功能涉及不是很多）。再加上每一个主机厂的ODX企业级实现指南都存在不同，因此使得ECUC（ECU配置信息）的交互更复杂（信号交互）。
注：ODX企业级指南是主机厂定义ODX实现策略，比如对应每一个UDS服务名称、调用方式、DID调用策略等等。
AUTOSAR ARXML是专为满足BSW输入数据的需求而设计，如下图是AUTOSAR关于诊断功能实现示意图：

从物理层（车载总线类型CAN、LIN、FlexRay等）到传输层，通过PDUR传输给诊断模块（DCM/DEM等），若DCM可以处理接受到的诊断请求，单独处理。若需要跟RTE进行交互，比如从SWC获取应用层相关数据，例如DTC检测当前ECU电压值，就需要从SWC获取采样模块采样当前的电压值。
这个时候需要定义好与SWC交互的Link关系：

该数据Link关系从诊断模块DCM/DEM到SWC，需要在数据库中配置好，对应生成代码即可直接使用。
在AUTOSAR中，诊断功能对应协议UDS、OBD、WWH-OBD、J1939对诊断服务、子服务、DID以及DTC的选择；
-> 故障DTC路径和故障内存存储方式；
-> UDS/OBD诊断数据元素和相关的数据包内容；
-> 诊断数据元素与Software Application的映射关系；
-> 功能禁用模块（FIM）与功能降级策略。
若将上述内容实例化，比如ECU诊断DID实例解析关系包含16 bits的DID，其中映射一个或多个数据元素，在ECU诊断需求规范中会定义DID数据的Name和Type。在ODX数据库中数据类型建模，对于软件功能实现时，AUTOSAR相应代码配置工具可复用已存在的系统模板模型，抓取其中特征点，解析数据库模型关系，从应用层到物理层整个链路打通。

为了读、写或者重写DID，软件基础代码BSW需要与应用层软件交互（SWC），这时候会用到ARXML中存在的元素——诊断映射关系。诊断映射规定了BSW诊断内容之间的关系：
->Routine：诊断例程，可通过Routine ID定义用户需要实现的功能;
->DID数据：读取或写入ECU内部运行信息、状态信息；
->Event和Application的软件组件（SWC）。
为达到与AUTOSAR体系架构数据交互一致性，在定义SWC的接口时，需要遵循AUTOSAR定义的建模方法：
1、通过不同通信模式调用客户端/服务器的接口（Client/Server Port）；
2、通过收/发接口来读/写ECU数据（Provide /Require Port）。
以往工程师不得不手动配置BSW和应用层软件间端口的关联；当使用ARXML时，这一操作自动Map对应关系。因此会减少配置时间以及错误，并在提高Software质量的同时缩短开发时间。
诊断开发过程中应用场景和对应角色
在使用工具和数据交互之外，车载诊断功能开发流程的体现在OEM和Tier1的分工不同：
1、由OEM完成设计：
系统级将诊断功能、应用场景做系统级别设计并具体细化Map关系；
2、由OEM和Tier 1联合进行诊断开发：
主机厂和供应商共同设计开发，当然这些供应商都有较高技术积累；
3、由Tier 1独立完成开发：
对供应商能力要求更高，特别是软件开发能力。在互联网技术公司不如车赛道后，这个需求更加明显。
应用场景1：OEM主要完成诊断设计
-> OEM创建系统设计（功能、应用场景包括SWC的诊断接口）；
-> OEM提供ECU诊断规范：规定整车、ECU级别诊断需求规范，定义使用到服务、DID、DTC；
-> Tier1承接OEM的诊断规范并按照需求实现其功能。

应用场景2：Tier1扩充OEM诊断需求规范
-> OEM创建系统设计（包括SWC的诊断接口、调用Map关系、事件触发条件）；
-> OEM设计ECU诊断需求规范：整车级以及ECU级别，伴随着域控制器在整车电子电气架构使用增多，系统级设计彰显更加重要，包括DTC存储策略、功能降级策略；
-> Tier1扩展ECU诊断需求设计：供应商基于自身技术积累，将以往项目经验迭代到项目中，会根据实际情况增补ECU诊断需求设计；
-> OEM更新Tier1修改的诊断规范：供应商基于自身技术积累，扩展了ECU诊断需求后，主机厂审核后会将增补的内容更新至自己规范中，这样达到一个良性循环。

场景3：Tier1创建ECU诊断需求规范
->   Tier1创建SWC的诊断接口：具备很高技术积累的供应商，诊断系统工程师会设计SWC诊断接口与DCM、DEM等诊断模块的接口设计；
->   Tier1创建适用于SWC的诊断需求规范：创建规范、实现功能；
->   OEM接手Tier1的诊断需求规范：主机厂接受供应商需求规范，并更新至自己规范中。
为达到以上三种需求，AUTOSAR ARXML文件中的元素需是供工程师可选的。根据不同的流程，创建并丰富其内容（最好是通过系统级的工具，有良好的人际交互界面）。创建的数据是正确合规且可实现交互。

工具链相关的需求
诊断开发流程需要工具链的支撑。工具链的好处在于从需求端（在流程开始阶段），通过需求管理系统定义诊断需求点。由诊断需求规范解读获取应用层软件与诊断服务相关的需求。

注：其中重点是系统设计与ECU具体实现映射关系、ECU级别诊断设计和SWC口Map关系。
在自顶向下的开发流程中，最先开发的是诊断应用层Software。诊断数据源自需求和应用层软件的接口描述（为保证数据的一致性、有效性和正确性，通过业界常用数据库更合理）。
ARXML文件被创建编辑，同步创建ODX数据库。从同一源头生成ODX和ARXML数据，可以确保诊断仪与ECU的诊断软件相匹配，也能保证数据的一致性。
因此采用系统级设计工具，设计整车级别诊断需求内容管理和对应关系，采用具体ECU诊断数据编辑工具编辑单个ECU诊断描述内容，导入代码配置工具生成对应的Software，达到功能。最后将系统级设计工具与单个ECU链路打通，实现高效性和一致性要求。

总结和展望
AUTOSAR ARXML提供了诊断开发领域的新可能，包括数据的精确描述（包括BSW配置信息的获取），OEM和Tier1之间的分布式诊断开发，以及自顶向下自动集成ECU的诊断功能。
为达到我国汽车行业崛起，不再是国外主机厂代工厂，要求从系统级别到单个ECU级别都有整盘考虑。