诊断功能的实现在整个电子控制单元（ECU）的发展周期中处于后期阶段。合适配置的诊断系统经常是只有在生产启动前很短的时间内才能获得。现在，源源不断的阶段需求使得这种形势更加恶化。本文描述了一种能够克服这些恼人问题的前加载方法。

□ 恒润科技供稿

在复杂性日益增加的大环境下，诊断系统对于车辆来说变得越发重要。实际上，诊断功能理应早些实施，并且和功能开发同步。然而目前，它们经常被加载在整个ECU运行周期的后期，设置有适当参数的诊断测试系统只能在生产启动前很短的时间内才会有效。这些事实以及对产品和需求描述的曲解，经常会导致不利的经济后果、超强的工作负荷以及最后一刻更改事件的发生。为此，OEM供应商根据对ECU的需求制定了一条或者多条的规则。在诊断区域，特定的ECU规则常常会参考国际标准和适合所有特定交通工具型号的ECU诊断总规则。然而，这些标准和规则的解释自由性都很高。

Vector Informatik公司的解决方案在XML数据库中实现诊断需求，使得需求管理程序化，并能弥补使用OEM特定模板的需求规范和客户规范之间的不同。使用前加载的方法，实现诊断协议所需要的总投入可以被减小6到7倍，给供应商和OEM带来双赢。

通用诊断

供应商首先整理出诊断要求的规范，从他们的角度出发来阐述该如何实现这个规范。此角度和不同理解之间的空间导致一个相当和谐的状况。不过，一般来说这种和谐出现得太迟了。在很多状况下，它根本就不会发生或者只有当ECU已经上了测试台或安装在车上了并出现错误时才会出现。另外一个负面是赋予给新功能开发的高优先级与诊断功能性实现之间的比较，结果导致了高工作强度、高冲击的改变以及最后一刻变更的高出现率。

解决方案是利用可重用诊断部件。诊断的特点被归结为针对多种ECU（例如ECU的身份识别）的一般诊断数据，特定的ECU诊断数据和算法。这种途径可以显著削减响应时间，并且在提交请求前，诊断方案的前3个部分都可以准备完毕。那些交通工具的OEM将依次对每一个ECU供应商在车辆实现方面对是否拥有一般的诊断特征作出评估。OEM希望来自不同供应者的某一种ECU的特定诊断数据（仪表或者灯）能够尽可能的相近。而供应商则希望ECU特定诊断特征的实现性对于所有的OEM供应商来说能够尽可能的一致。然而不幸的是，关于诊断协议和数据的OEM特定的要求阻碍了这个设想。有没有一种方法能够让前加载成为可能，节省时间和费用，还能为所有的参与者创造出双赢的局面？

有用的咨询

在投标过程前提供的咨询服务中，从标准和规范中确定了OEM 的需求，同时也定义了其精确的实现。信息随后就被转化为机器可读的诊断XML模板。整个诊断的协议和总的诊断需求、特定车辆型号的数据在这个诊断模板中已经被描述。该模板还定义了供应商应该怎样按照诊断协议来布置特殊的ECU诊断需求，以及诊断性数据应该被客户怎样描述出来。实际的运行包括工具驱动数据的输入过程，自动源代码生成和测试系统的自动数据支持。

应该如何实现？对于所有ECU来说，应该怎样仅用一次典型性操作，并且使用Vector ToolCANdelaStudio 将它存在已经成形的模板上？这个模板已经通过添加特定的ECU诊断数据而被精细化。因为该模板已经被进一步延伸，供应商只需输入即将被测试的功能性描述和诊断数据就可以了。这种方法减少了需求和规范实现的曲解。需求和实现的规范就被通用的规范文档所代替，用于整个开发阶段，并描述需求和其实现。

缩短开发周期

因为在模板中对需求及其实现的清晰解释，实际的实现步骤很简单。一个有效的C代码生成器就可以将需求准确无误的映射到相应的ECU代码中。CANdescC代码生成器会为ECU生成OEM特定的诊断软件部分。在整个工程启动后很短的时间内，供应商就可以发布一个装载整个诊断协议和诊断系统综合基础特征的ECU。OEM方面和供应商方面都可以迅速地开发和配置他们的诊断测试系统。

与制造过程相关的诊断算法能够很早就得以进行仿真，或者他们可以和软件工具CANoe、CANape Graph 和 CANdito一起在ECU中被测试。结果，整个开发过程能够比传统的方法缩短大约6～18个月。

成功的原因是源于产品开发创新带来在开发方面大的改变（前加载）。各个汽车制造厂都会有自己合适的模板，这样ECU供应者就可以集中精力于ECU的特定数据和算法。对于不同的OEM或者相关的ECU产品而言，这些诊断特征的重新利用是通过由汽车制造厂特定的模板中分离出来的特定ECU的信息来实现的。这种方法允许在整个发展过程中实现前加载，提高了产品的质量，并为所有的参与者创造了双赢的局面，节省了大量的时间和成本。