车载诊断---闲思 / 开普饭

2021年8月3日，上海天气：阵雨。

明天是儿子一周岁生日，愿小家伙快快乐乐、平平安安的长大。

真应了那句话，在男人这个年纪，时间就真的是一个数字，慌慌张张、匆匆忙忙应对着各种事宜，如同洪流，裹扎着、不由自己的向前走。

也就在此刻，偷得浮生半日闲，真真切切由自己把控。

惯例，分享一段喜欢的文字：

你可以阴郁，可以懒散，可以不适时的计较，过分敏感，可以有些不知足、暴躁、嫉妒、小气，但要记得拷问自我，必须追求善良，尽力坦荡，永远正直。

希望自己能够保持所有的炙热和真实，去庆祝每一个值得坦荡的日子。

本文分享如下三个方面内容：

DTC故障码优先级
OTA刷写数据传输方式
电子电气架构走势（HPC和域控制器）

1、DTC故障码优先级

对于Supplier，量产级的项目，芯片价格和质量永远是一对无法逃避的争论点。原理上为了满足各种需求，芯片性能越高越好。但是作为公司层面，是为了盈利，追求的芯片价格更低。一般情况下（预研不算）会在满足所有项目需求前提下，选择最便宜那款芯片。

而对于车载诊断范畴，当ECU自身代码判定DTC对应的故障已经产生，会将该DTC以及DTC Status存储在ECU内存上。有些情况下，ECU掉电非易失内存内容分给DTC储存的空间不是很多的时候，这个时候需要在需求规范中定义DTC的优先级。

当优先级级别高的DTC产生时，可以覆盖低优先级的DTC。这样可以实现对车身影响大的DTC可以在芯片内存有限的情况下实现写入操作。

若DTC4判定已经产生，并且在需求规范中优先级比已经存储在内存中的DTC故障码高，就会将原有的内容覆盖。

初步达到要求。

以上是DTC优先级判定策略。

另外，考虑到HPC以及域控制器引入到车载网络，DTC也带来了需要变化内容。

如下以域控制器为例：

鉴于域控制器的存储能力，可以将域控制器下挂的节点产生的DTC记录在域控制器芯片内存上。

2、OTA刷写数据传输方式

全称“Over-The-Air technology ”，即空中下载技术，通过移动通信的接口实现对软件进行远程管理，传统的做法到4S店通过整车OBD对相应的ECU进行软件升级

汽车OTA升级就好比电脑的Windows系统升级，或者也可以理解为手机系统的升级，每次升级都可以得到改善、修复漏洞或者获得更多的功能、性能提升，又或者是视觉效果的改善，且这种更新是通过联网后在线检测、匹配版本、下载新的代码到本地进而执行安装、校验等程序。

如上图是自己简略画的一个架构图。OTA是在线升级，因此首先需要一个云服务器，车载端需要一个支持无线功能的节点模块（e.g.T-box）。

以下是个人很窄的观点，欢迎留言补充。

1、首先具备无线功能的车载节点接收云端以HTTP传输协议传输数据（本质还是TCP/IP）；

2、将下载的数据在GW存储，该节点具备Flash Manager、Security Manager（保护数据安全）等策略，这里面有如下注意事项：

A：若具备无线能力的节点存储够大，可以将下载的数据全部存储在该节点；

B：通过无线功能将整车需要升级的APP数据全部下载到具备无线能力的车载节点（e.g.T-box）；

C：若具备无线能力的节点存储不够大，可以将数据传输给域控制器，来分担存储压力；

D：车载节点内部传输协议可以使用UDS协议也可以使用自定义的私有传输协议。

3、作为人机交互端，中控屏可以显示出车身具备升级的可能性以及是否升级的主动权（由驾驶员控制）。

升级安全是OTA的最基础的要求。车辆上ECU的软件运行状况直接会影响到车辆上的人员的生命安全。从升级包制作，发布，下载，分发，刷写等环节，OTA需要从云，网络，车端来保证安全。在云端通过证书，签名和加密机制保证升级包的不会随意被制作和发布，升级包内容不会被恶意获取。通过冗余设计保证整车的功能可靠性，通过安全启动来保证可信的软件在ECU上加载启动运行。

防变砖等异常处理。在OTA传输过程中，外界干扰或者其他因素导致刷写异常或者中断，车载ECU必须支持软件回滚、断点续传、丢失重传等处理机制。比如通过A/B分区实现软件回滚。当刷新软件不可用或者失败时，回滚到分区中备份的旧软件版本，保证控制器正常运行。

3、电子电气架构走势（HPC和域控制器）

如下是新一代电子电器架构的网络拓扑图。