基于实例探究车载诊断功能实现全流程（干货版）

假期得空，坐下来码字总结下思路！
车载诊断功能作为车身控制器（不管是以前的分布式电子电器架构还是现在流行的中央计算器+域控制器架构），都是不可或缺的功能。本文通过诊断功能实例：
-> 诊断功能需求提出；
-> 诊断数据库（保证数据一致性）；
-> 配置生成代码，诊断功能实现；
-> 编译生成二进制文件（bin、Hex等）；
-> 上板测试（手动、自动、SIL）
如下流程属于汽车行业经典V模型

1、诊断需求规范制定
在定义新车型后，电子电子部门诊断方面系统工程师（或架构工程师）基于新需求定义该车型的诊断需求规范，比如所需要的诊断服务、DID、DTC，当然在这个过程中会有很多流程，毕竟车企这套已经玩转几十年，比如OEM会释放诊断需求调查表给供应商，如下格式举例：

填充完毕，OEM会形成最终规范，归档。
此内容伴随着车辆新四化的需求，也发生了许多变化：
A：电子电气结构从以往分布式变化成中央计算器＋域控制器模式，诊断规范定义必然出现变化；
B：车载以太网引入车载网络后，带来了很多诊断应用场景，近端Tester、远程Tester、车内Tester，访问车辆优先级怎么定义，抢占模式又是什么，都带来了新的挑战和变化；
C：ECU刷写策略也出现许多变化：A/B分区回滚策略、远程OTA刷写策略等等。
2、诊断数据库
为了保证需求提出->功能实现（代码配置）->后期测试诊断数据一致性，在汽车行业通常是使用诊断数据库流通于整个流程，这样做的好处是避免整个流程中工程师对诊断数据的主观解读，避免数据的不一致性。在使用上位机作为Tester发送诊断报文时，有数据库也可以对请求和响应进行报文实际含义解析。
另外在国外较为正规的开发流程是OEM编辑管控诊断数据库，并释放具体ECU数据库给相应的ECU供应商，方便OEM对诊断需求一致性管理和版本管控。不过相对比国内，大多数还是释放诊断需求调查表给ECU Supplier，做功能实现。
现阶段车载软件通过配置工具生成代码比重在逐年增加，诊断需求调查表就是到了ECU Supplier手里也是自己再编辑数据库，作为诊断模块的数据输入。
3、诊断功能实现
配置工具导入数据库生成代码
本文基于CAN总线，数据流：
CANIF->CAN TP->PDUR->DCM<-> RTE(SWC诊断功能实现)
CANIF中定义寻址方式（功能寻址、物理寻址）CAN ID

初始化
发送请求服务
发送确认服务
接待指示服务
控制器模式控制服务
PDU模式控制服务
CAN TP定义数据帧、填充位等
数据在传输方向的分割;
按接收方向重新组装数据;
控制数据流;
检测错误；
传输取消；
接受取消；
PDUR提供诊断模块与底层物理总线的隔离效果。
上层：COM模块与I-PDU多路复用器(IpduM)模块之间的通信（主要分享诊断范畴，其他模块俺也不精通）；
下层：IpduM模块与通信接口模块（CanIf、FrIf）之间的通信。
PduR模块的用户列表不是固定的。最常见的上层和下层的组合如下:
AUTOSAR DCM和Tp模块；
AUTOSAR COM和通信接口模块、传输协议模块或I-PDU多路复用器；
I-PDU多路复用器和通信接口模块；

DCM模块主要负责处理诊断数据流和管理诊断状态，包括诊断会话和安全状态，DCM模块能检查诊断服务的请求是否满足条件。

DSL用于确定诊断数据请求和响应的数据流；监控和确保诊断请求和响应的时序，管理诊断状态（特别是诊断会话和安全状态）；
DSD用于处理诊断数据流。将接收到的诊断请求转发给数据处理器；当数据处理器触发时，通过PDUR传输诊断响应；
DSP用于处理实际的诊断请求。
本文诊断需求规范中涉及到安全解锁Security Acces和数据读写功能Service 22/2E，这些是通过RTE交互SWC得到，在AUTOSAR规范中，在RTE中处需要定义对应功能的Port、Runnable、Event。这其中的对应功能包括：
GetSeed：DcmDspSecurityGetSeedFnc从此函数获取Seed值；
Compare key：Xxx_CompareKey对比ECU内部生成Key和上位机生成的Key值；
AttemptConuter：GetSecurityAttemptCounter定义Tester进行解锁尝试的次数；
SetSecurityAttemptCounter：设置尝试次数；
ReadDataByIdentifier/WriteDataByIdentifier



开发工程师在其中承担的责任是在项目中配置工具配置好工程，在RTE中会生成对应接口（基于Server-Client方式生成SWC），研发工程师在对应接口实现其对应功能，比如：
->当需要读取静态数据时，可以直接从一个内存地址直接读取；
->当读取动态数据（比如电压值），需要关联一个电压采样模块，实时读取。
整个代码配置思路可以简略为如下：
一、数据流配置
（1）基于诊断需求规范编辑诊断链路条，首先编辑诊断常用3个CAN ID：
物理请求CAN ID；
物理响应CAN ID；
功能请求CAN ID；
同样编辑三对关联Reference：
CanIf2CanTpPdus
CanTp2PdurPdus
Pdur2DcmPdus

（2）在CAN TP处也会对应新建这三个Channel
用如上链路Link关系实现关联（CanIf2CanTpPdus）



（3）在PDUR处关联CanTp和DCM，分清SourceAddress和DestinationAddress
使用如下关联关系：
CanTp2PdurPdus
Pdur2DcmPdus
通过上述关联关系，可以实现诊断数据流的设置。
二、诊断数据配置
在DCM模块，在DSD通过导入的诊断数据库，识别其包含的诊断描述内容:
->诊断服务（Service ID）：本例中包含Service 10/22/27/2E；
->诊断子服务（Service Subfunction）：本例中包含：Service 10 01/02/03，Service 27 01/02,09/0A；
->DID（Data Identifier）。
因为在数据库中已经配置了服务的执行权限（诊断会话模式状态机/诊断安全感访问状态机）。
因为该例子中包含与RTE交互获取的SWC内容，因此需要定义RTE Port/Runnable/Event。

在通过配置生成代码后，在RTE文件中（.c）,找到对应接口，编辑Seed-Key解锁功能，编辑DID读写功能。如上图，数据流如上图所示。
当DCM收到PDUR发送的Service 22 + DID时，DSD验证服务执行权限，DSP中处理响应内容，因为要获取DID数据信息，这个时候需要与RTE中SWC交互获取数据信息。
所有一切编辑完成后，在IDE中编译生成对应二进制文件，烧录ECU，待后续测试。
4、上板测试
测试目的是验证其功能是按照需求规范定义实现，
大致分为：
手动：通过上位机，在人机交互界面，手动点击需要发送的测试步骤（基于测试规范）；
自动：测试工程师自己编写测试脚本或者基于工具自行配置，自动生成诊断测试用例，用于测试。
注：
这里面还会有HIL、SIL、MIL等方式，不做过多追溯。另外诊断范畴还包括远程诊断、远程刷写、车辆产线下线配置（EOL）、售后诊断数据维护等场景，特别是伴随着数字化、智能化城市的推行，诊断功能跟车辆新四化的结合会有更多的应用场景待开发。