步入中年，不可避免会接触到所谓的中年危机，时刻在提醒自己提高自己的护城河，增强核心竞争力。但是这种事情也不是靠空想，还是要功夫下在平时。

自己是在2016年开始接触车载诊断方面，从事过诊断范畴的开发、测试、偏系统工程师等，因此本文也想粗略的总结下其内容——伴随着新技术引入到车载中，怎样做到一个不被淘汰的诊断工程。

一、车载诊断功能

车载诊断功能是通过技术手段快速定位车身发生故障部位，伴随着功能不断完善，诊断功能具体体现如下几个方面：

-> 通过UDS Servcie快速界定车身发生故障部位;

-> 读取车身控制器相关信息（比如软硬件版本号、电压值、电流值、温度等）；

-> 实现ECU软件更新。

业界常用的诊断协议是ISO 14229（UDS）和ISO 15031（OBD II），以协议中定义的服务为载体，实现上述功能。

二、诊断工程师职责

这里区分两个范畴：主机厂和供应商

1、对主机厂，诊断岗位可以细分为诊断系统工程师、样件工程师等。

对于诊断系统工程师（传统主机厂该职位属于电子电器架构E/E部门），需要：

定义基于车身总线的网络架构的诊断系统设计；定义整车所有部件CAN ID（车载CAN总线）、逻辑地址（车载以太网）；定义整车部件用到的DID、DTC、NRC触发条件以及优先级（保持符合ISO协议和内容一致性）；编辑制定企业级诊断需求规范、刷写规范，维护并管理；编辑企业对应的诊断数据库（ODX\CDD\ARXML），维护并管理；维护企业诊断需求调查表；

对于样件工程师，整车会因功能不同，分为多种控制器（ECU），接触过的几个主机厂内会有一个诊断Team，组内工程师会负责数量不等的ECU验收以及管理工作，在供应商提供样件时，验收其功能。其中常规操作是ECU验收过程中，工程师先基于公司技术积累已经编辑好的诊断测试用例校本库，先跑一遍测试用例（业界较常用是基于V公司工具CANoe+CAPL测试脚本配合CANoe.DiVa实现高覆盖度的测试），需要验收的内容：UDS协议功能实现；Bootloader刷写功能 排放功能检测

测试依据是测试工程师基于OEM诊断需求规范编写测试规范，再基于测试规范编写测试用例，从而验证功能实现是否是按照需求定义实现。

对应供应商，这里主要分为研发工程师和测试工程师

研发工程师需要基于OEM的诊断需求规范实现其功能，现阶段汽车电子行业手写软件代码比重在逐年降低，通过配制工具生成的协议栈实现其功能却在逐渐增加。其优势在于软件运行时的稳健性（这个时候需要看配制工具生成的协议栈优良程度，决定着稳健性的强弱）。研发工程师通过配制工具生成的整个软件工程协议栈，关于具体诊断功能，研发工程师基于其中的API接口实现其功能即可。

e.g. 比如定义一个DID 0x0102，用于读取ECU当前电压值。数据库、起作用、导入、采样模块等等

对应ECU诊断功能也可以分为：Application/Bootloader

Application关注于UDS应用层诊断功能，比如Service 22/2E/19服务等；Bootloader关注于ECU软件更新（Software update）功能实现

测试工程师待研发工程师完成软件功能后，研发工程师集成初步功能自测后，会转测试，这时基于公司技术积累，对ECU进行诊断范畴功能测试；

初步运行测试脚本的自动化测试（持续完善过程）； 

基于测试用例的手动测试（提高测试覆盖度）

三、新时期诊断工程师需要的职业技能（职业素养相比传统有哪些变化）

1、车载诊断仪的应用场景：

->现场/远程诊断（有线无线）；

->User Tester和专业级Tester；

->车载HUD（抬头显示系统增加人机交互界面）。

伴随着技术不断更新迭代，车载诊断也出现了不同的应用场景

（1）、现场远程 

随着以太网被引入到车载网络中，使无线以及远程诊断成为现实（以前通过3g/4g模块也有远程解决方案，通过T-box内嵌一个这样的模块，连接云端服务器，是远端工程师远程连接车辆实时获取车辆信息，达到远程诊断目的）。车载以太网的应用也使远端一个Tester连接多个车辆，或者多个Tester连接一个车辆成为了现实，只要网关或者域控制器具备无线功能即可。

（2）、User Tester & 专业级Tester

以往车辆去4S点保养时，工作人员会拿着专业级版的手持诊断仪检测车辆状况，伴随着无线功能（车载以太网）在车辆网络的应用，更加个性版或者定制化的Tester出现，比如通过手机App或者PC端直接获取车辆运行状态信息。不过这个时候为了不被外界恶意破坏，释放的权限会非常有限，可能只是查询状态信息以及DTC故障码功能。

 

（3）车内HUD或者其他人机交互界面

以往车辆故障信息在车辆具备提醒驾驶员（具备报警信息的故障类型）都是一些破坏车辆较为严重的故障，现阶段车身具备更多的人机交互，也给更多关于车载诊断信息显示带来了可能性，比如可以通过HUD（抬头显示系统）显示更多的数据交互：比如ADAS域各个模块状态信息，是否存在网络连接不良？是否有最新软件版本更新？

2、新需求下对诊断工程师的要求

随着车身电子电器架构从以前的分布式架构向局部域控制器架构（最后可能会过渡到中央处理器HPC或域控制器与HPC共存）。最近也出现了几个很火的域——智能座舱、ADAS域、整车车身等。

比如以ADAS域为例，简要说明出现该域后，对诊断工程师有了那些新的要求？

->首先该域需涉及毫米波雷达、激光类型、单目或多目摄像头；->域控制器上也需要运行不同模块—高清地图，规划控制（规控模块）。一般这些模块运行在高算力、高实时性的SOC芯片上。

如上内容都是与自动驾驶相关内容，对车驾驶员安全性有很高的关联性。因此关于故障界定排查及时性、发生故障后快速反馈给驾驶员、发生故障后怎么实现功能降级以保证车辆安全等等新的需求，都是对诊断工程师新的技术要求。

以往出现故障后，界定策略采用AUTOSAR中定义DTC策略：

• 时间消抖；

• 次数消抖。

而在ADAS域中除了定义界定DTC产生策略外，还需求定义故障产生后以何种方式实现功能降级处理，用于保证车主安全！

另外，现在车身有了更多的人机交互界面，因此在出现故障后，可以考虑使用触发式报文（当故障发生时，除了存储在芯片内容外，还触发报文将故障码对应的故障类型显示在交互界面中，用于提醒驾驶人员），显示故障信息。

反应系统故障点引发的故障，可以使用Snapshot形式来追溯故障引发点

这时候可定义多个故障点对应一个DTC故障码，具体是哪个Error case引起的故障，可以在Snapshot中进行定义区分。

刷写策略除了经典的UDS刷写ECU用于升级Software软件版本，现阶段还可以通过私有协议实现ECU刷写（OTA手段）：

HTTP/HTTPS传输数据，SOME/IP控制刷写流程。

 

要做到不被淘汰，需要自己根据新技术发展，与时俱进。提前一步做好准备，不再是一直吃老本。

愿你我相信时间的力量，

做一个长期主义者！