开放架构、可配置组件和统一交换格式的一个关键目标，是让开发人员更加关注创新和产品差异化功能的开发和重用。近年来，许多独立的标准被创建出来，而且已经影响到了诊断开发中的过程和工具，尤其是ODX和AUTOSAR。与此同时，对需求的系统获取、管理和跟踪控制，也对流程、方法和工具产生了重大影响。
有没有可能在没有一个或多个标准的情况下做到这一点？有超级标准吗？或者标准和方法是否能够更加有效地结合在一起？
需求工程
对一个系统的开发，开始于从用户视角的需求。对需求的获取标志着一个迭代过程的开始（图1），在这个过程中，系统的需求逐渐变得更加具体和精确。如果为满足需求的解空间仍然很大，后续对于各个子系统的规格描述就要精确并且不会含混不清。
图1：迭代开发过程
在实践中，需求在具体和精确的方面有所不同。基于文本的需求描述了一种以文本形式实现的系统属性，通常是不完整的、故意模糊的、短语或只是以笔记的形式。另一方面，规范要求是精确的，不仅描述了需求本身，而且还包括了解决方案，并且对规格的解释只留下很小的自由度。形式化语言通常用于描述规格，这些描述在文件中被附加到基于文本的需求后面。参考需求包含对规格的引用，例如“和以前的系统一样”。从技术上讲，这些参考需求实际上引用了在其它数据库或数据管理系统中的规格。
理想情况下，需求从一开始就尽可能准确地定义，这不只是必要的。不明确或含混的需求导致在开发的过程中大大增加了工作量，因为澄清意味着需要额外的协调，并且通常会导致规格变更。在最不利的情况下，甚至可能需要修改系统实现。另一方面，不必要的特定需求通常会阻碍通往最快和最有效的解决方案的道路。如果解决方案路径的各个方面在早期与需求混合在一起，这就不必要地减少了解空间。通常这也消除了重用的机会。特别是当需求在开发过程中发生变化时，重要的是要从早期解决方案的方法中分离出实质性的需求。
在开发过程中，对所有需求的总体实现进度，提供了对整个系统或子系统（成熟度等级跟踪）的实现进度的良好概述。
如果您希望系统地利用需求驱动过程的优点，那么上述过程必须应用于所有子系统，包括实际上独立的不同开发规程。当然，这也适用于诊断。
如今，面向电子表格的工具和数据库通常被用于管理需求。在这里，需求不是形式化描述的，或者只是部分地描述。这些工具必须足够灵活，能够获取和跟踪所有需求——甚至是那些非常模糊的需求。
关于规格，各种其它的工具已经在不同的领域中建立起来，例如建模和编写工具，这些工具通常会生成一个形式化的规格。与用户需求相比，对内容的精确定义是主要目标，而不是灵活性，而这一根本差异导致了不同的、专门的工具。因此，经典的需求管理工具只能在一定程度上使用。这也适用于诊断。
标准化的交换格式是专门为特定的规程设计的。例如，ODX指定了与诊断测试仪相关的数据。交换格式通常使用形式化的数据模型，确保在其详细信息中有一个一致的规格。另一方面，这些格式对于制定模糊的需求来说过于严格。经典的需求管理工具非常适合描述基于文本的诊断需求。与此同时，标准化数据交换格式ODX不适合描述或交换这些基于文本的需求，因为它过于形式化和精确。
ECU软件
现今，AUTOSAR（AUTomotive Open System ARchitecture 汽车开放系统架构）是ECU软件在汽车行业的参考架构。AUTOSAR对单个组件或车辆功能的描述和整个系统的描述进行标准化。
AUTOSAR的诊断软件由DCM、DEM和FIM三个基本软件模块组成。
DCM（Diagnostic Communication Manager 诊断通信管理器）根据UDS和OBDII实现诊断通信。DEM（Diagnostic Event Manager 诊断事件管理器）实现了一个故障存储，并管理故障状态和关于故障症状的补充信息。在故障发生的情况下，FIM（Function Inhibition Manager 功能抑制管理器）可以防止某些功能的执行，并抑制二次错误。
DCM、DEM和FIM由ECU配置描述（ECUC）来配置。通过说明需求如何与软件组件的配置相关联，可以更好地理解它们的内容。
在配置ECU软件时，必须避免模糊和可变通，这对获取需求是有利的。对于发生的所有操作条件，必须对软件进行精确和不含混的描述。
与软件配置相关的诊断数据的重要内容包括诊断服务，这些诊断服务由外部的诊断测试仪通过请求、响应及其参数（服务标识符、子功能和数据参数）进行调用。所有数据参数都有对应的长度和数据类型；常量参数也需要一个常量值。在UDS中，对某些数据包的访问可能仅限于某些会话或安全级别。这些信息也包含在配置数据中，以便软件能够确保符合规定的规则。
软件配置数据的第二个重要方面是它将诊断软件与应用程序连接起来。诊断服务传递的参数可以链接到应用程序软件的变量或函数。软件生成器可以生成相关的调用。
由于AUTOSAR诊断仅限于UDS和OBDII协议，因此这些协议的诊断服务的布局是隐式假设的，并且没有显式地在ECUC数据中描述。
AUTOSAR ECUC数据以标准化的XML格式存储，这使得它可以在代码生成器中进行处理。
向诊断测试仪提供数据
从诊断通信的角度来看，用于参数化通用测试仪的诊断数据，必须包含与车辆或其ECU相关的所有信息。与上面描述的配置数据相比，一个显著的差异是车辆范围。特别是在服务领域，单个诊断测试仪需要覆盖许多年内的大量不同的车辆、模型和变体。这使得需要有效的机制来避免数据量冗余，并实现必要数据的紧凑存储。
对于参数化的测试仪来说，配置所需的规格特性不是真正必需的；相反，它甚至可能有利于参数化，以包含多个等效的替代方案，因为在运行时可以自动选择适当的数据。当诊断测试仪连接到车辆时，通常不清楚在测试的车辆中安装了哪些ECU变种和软件级别。
在内容方面，诊断测试仪数据与配置数据不同，因为转换信息是一个重要组件。经过紧凑编码的总线消息和它们的部分，以其物理值和单位在测试仪中显示。
用于参数化诊断测试仪的已建立数据格式的示例，是来自Vector的cdd格式和ISO标准的ODX格式。
一个工具链的例子
在诊断开发期间执行的以下任务，由图2所示的工具链支持。
图2：诊断开发的工具链
定义、收集和协调需求
IBM DOORS作为获取和管理需求的工具，在汽车OEM中得到广泛的使用。
创建和协调规格
在这里，支持需求的获取和导入／导出的CANdelaStudio，可以无缝地集成到需求驱动的过程链中，作为指定ECU诊断的创作工具。根据已经被形式化描述了需求，通过按下界面按钮，就可以生成诊断对象（诊断服务、数据对象、DTC）。这些对象都与原始需求相关联。通过这种方式，用户可以自动调整和同步导入的需求，以匹配更新的需求，如果有必要还可以修改规格。紧密链接的需求和规格在典型的迭代过程中非常有利，因为它避免了创建和重新比较规格数据的重复工作。
完成的诊断规格作为过程链后续步骤的输入。CANdelaStudio以cdd格式保存原生诊断规格，并且可以按下按钮导出ODX文件。
生成和集成ECU软件
DaVinci Configurator Pro是一个用来配置和生成AUTOSAR基本软件和ECU的RTE的工具。用户导入诊断规格（ODX或cdd），并生成初始的ECUC配置。在这之后，用户逐步补充ECU的配置，使其更加具体和详细。如果诊断规格有了新版本，就很容易重新导入它，并且内容会自动与之前创建的配置合并。ECU的诊断软件是基于结果配置生成的。
ECU测试诊断软件
CANoe.DiVa用于测试在ECU中供应商和OEM的诊断实现。CANoe.DiVa根据ODX或cdd格式的ECU规格，生成大量的ECU相关的测试用例，然后在CANoe中自动执行。测试结果按详情显示，用户可以对任何测试用例进行备注，或者根据不同的标准对它们进行排序和筛选。
使用ECU诊断
根据应用场景的不同，可以使用CANoe、CANape或Indigo作为诊断测试仪。将CANdelaStudio规格作为测试参数化和ECU配置的公共源，确保测试人员和ECU软件彼此匹配。
总结
近年来出现在诊断领域的AUTOSAR和ODX标准相互补充，并继续有效地实现目标。虽然它们涵盖了相关的内容，但它们的关注点非常不同，重叠的范围也非常小（图3）。一个标准的操作区域不能被另一个标准覆盖。AUTOSAR方法也与ODX兼容。
图3：几个描述模型的相似点
然而，在实践中，仍然存在一个挑战，即确保在分布式和频繁的迭代开发过程中，对不同标准所描述的数据的一致性。这个挑战可以通过一个定义良好的过程、目标数据转移和市场上现有工具的支持来克服。
作者
Klaus Beiter博士
在斯图加特的公司Vector Informatik GmbH公司领导一个汽车诊断生产线的开发团队。他是ASAM/ISO ODX工作组的成员。
Christoph Rätz
他是位于斯图加特的公司Vector Informatik GmbH公司的诊断产品系列的负责人。
转载：
179
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
