如何从0到1设计诊断系统

引言

       在整车电子电气体系中，诊断系统的设计扮演着至关重要的角色，负责支持整车的刷写、故障排查和EOL(End of Line)等关键操作。这一重要性在于这些操作的实现都依赖于诊断系统的全面支持。因此，在设计诊断系统时，必须确保系统具备全面性、安全性和高效性。

       诊断系统设计主要涵盖了诊断方案设计、诊断需求定义和诊断数据库开发。本文会逐一介绍这些环节，以便更好地理解和把握诊断系统设计的全貌。

诊断方案设计

       在进行具体的需求定义前，首先需要确定诊断方案，主要内容包括明确本地诊断、远程诊断、OTA (Over The Air)、车内诊断的诊断路径。这里以本地诊断为例进行介绍，常见诊断方案包括隔离方案和透传方案。

• 隔离方案

         隔离方案是指将车内和车外划分为不同的网段，诊断仪发送的诊断信息必须通过边缘节点进行路由映射后，再转发至车内的目标节点。

         采用这种方案的优点很明显： 

          因为车内外的网段隔离，可以更好的进行安全防护。

          网关统一进行转发，可以由网关进行不同诊断路径的管理。

         当然此方案也有一定的缺陷，最明显的就是如果网关的转发性能不足，则诊断路由的延时会较长，会影响一些场景（如刷写）的效率。

• 透传方案

         透传方案是将车内和车外划分在同一个网段，诊断仪可以直接与车内节点建立以太网诊断链接，无需经过边缘节点进行路由。

         透传方案的优点有以下两点：

          诊断仪可与车内以太网节点直接建立链接，无需中间节点路由，传输大数据时效率高。

          对网关的路由性能要求较低，做好不同传输协议（如DoIP-CAN）的路由即可。

         其缺点一是不方便网关做统一的管理，其次就是安全性方面有更高的要求。

诊断需求定义

       当确定了诊断方案后，就可以着手进行具体的诊断系统设计工作。以下是一些常见且关键的环节。

• 诊断拓扑图定义

          根据整车拓扑和诊断方案，确定每个控制器诊断、刷写的路径。

          绘制诊断网络拓扑图，以清晰展示各个节点之间的关系。

•  诊断ID分配

          为诊断节点分配合适的诊断ID地址。

          为车内/车外诊断设备、物理寻址和功能寻址分配合适的地址。

          分配CAN请求响应ID（参考ISO 15765-4）。

          分配以太网DoIP逻辑地址 (参考ISO 13400-2)。

• 整车配置字

          如果诊断平台包含多个车型或者不同配置，开发整车配置字是必要的。

          确保配置字能够正确标识车型和配置，方便在诊断平台中进行正确的配置切换。

• 诊断需求规范

          包含了平台可能会用到的诊断服务和基础需求。

          针对不同的总线需要考虑其对UDS诊断的影响，例如：会话层时间参数的值的差异。

          由于车内包含各种传输协议，所以需要注意诊断对底层协议的需求约束。这里以以太网为例子，包括doip需求定义、tcpip相关参数定义、物理层定义等。

• 刷写需求规范

         在进行刷写需求规范的开发时，需注意不同种类的控制器会使用不同的刷写流程。一般可以将控制器分为：嵌入式系统控制器、带有文件管理系统的控制器。

          嵌入式控制器：这类控制器基于BootLoader进行刷写，一般需要先执行擦除例程，再使用0x34、0x36、0x37服务请求进行文件写入。

          带有文件管理系统的控制器：一般为使用OS操作系统的控制器，先使用0x38、0x36、0x37服务进行程序的下载，再由文件管理系统通过安装例程进行安装操作。

          如果有并行刷写、静默刷写等特殊的需求，也需要在刷写需求规范中进行明确定义。

• 网关路由规范与网关路由表

          根据诊断方案和拓扑图，明确路由方案，制定网关路由规范。

          当路由方案确认后，需要进行网关路由表的开发，以确保每个路由节点能够选择正确的路由路径。

         以上是诊断需求定义中的一些重要环节，这些内容都对诊断具体参数的开发和诊断功能的实现起着指导性的作用。

诊断数据库开发

         诊断调查问卷和诊断数据库的开发是一个长期持续的工作。在这个过程中，我们需要整合企业标准的定义，各方向专业工程师的建议以及供应商反馈的信息，并持续完善和优化。诊断调查问卷中的内容将应用于研发、生产、售后等各个阶段。

          ECU DATA: 控制器信息

             对每个ECU进行详细的描述，包括CAN ID、逻辑地址等信息。

          Service: 诊断服务定义

             列出每个ECU支持的服务、子功能、否定响应、支持的安全等级等信息。

          DID (Data Identifier): 数据ID

             包括系统DID和供应商自定义DID；静态DID和动态DID。

             对每个DID的功能进行描述，包括其示例、范围和用途。

          Routine: 例程

             包括刷写相关的例程、EOL相关例程以及功能相关例程等。

             提供每个例程的详细说明和执行步骤。

          DTC (Diagnostic Trouble Codes): 诊断故障码

             包括基本通信相关、信息安全相关和功能相关的DTC。

             对每个DTC提供详细的描述，包括使能条件、记录条件和恢复条件等。

          Snapshot: 快照数据

             通常会管理最近一次和第一次的快照信息，包括车辆的基础数据和状态。

          梳理交互逻辑及信息

             通常会记录发生计数器和老化计数器。

          其他内容

             如时间参数、28服务的通信配置、2F服务的定义等，这里不再详细赘述。

         在完成诊断调查问卷的开发之后，我们需要将问卷转换成诊断数据库，以便进行诊断数据交换。在此过程中，需要注意诊断数据库的格式以及适用的工具链的选择，以确保在进行优劣取舍时能够做出明智的决策。在数据库格式的选取方面，鉴于ODX格式的开源属性，该格式能够较好地适应整车开发、生产及售后各阶段的需求，因而是一种较为推荐的数据库格式。

总结

       在当今汽车电子电气架构逐渐完善的背景下，诊断系统设计已不仅仅是纯粹的诊断问题，而需要对整车的通信、功能和安全性进行综合考量。例如，在设计诊断方案时，需要考虑到诊断路径的安全性和可靠性。在进行诊断需求定义和数据库开发时，需要思考到不同诊断场景下的差异化要求。综合各方面需求的诊断系统会为整车从研发生产到售后都提供强有力的支持。

       了解更多：请致电 010-64840808转6116或发送邮件至[email protected]（联系时请说明信息来源于博客园）