SOVD标准正在改变诊断方式，特别是在互联网上当多个合作方进行交互时，其提供了很大的优势。在开发的早期阶段，需要使用附加的方法来利用这个标准，因为该标准并不是专为ECU诊断而开发的，而且还需格外注意数据的处理，因为这可能会导致并行系统中的大量额外成本。对于它们的平衡可使用诸如Softing SDE的诊断系统——这些系统专为广泛的应用场景而设计，且通过SOVD API可进行轻松扩展。在我们新发布的文章“诊断系统 加速开发”中，可获取此主题更多信息。

— 诊断系统 加速开发 —

如果没有基于控制单元诊断的专家系统，则对使用了50~150个控制器、多个总线系统和分布式功能的当今车辆进行维修几乎是不可能的。而这也同样适用于生产：没有诊断仪就无法发现错误。为了使诊断充分发挥作用，在车辆开发方面就需付出相当大的努力，且这一趋势还在不断上升。

近年来，ASAM e.V.定义了新的诊断标准以满足新的要求：面向服务的车辆诊断（SOVD）。API是为运行状态系统而定义的编程接口，这使得诊断信息可直接应用于在车辆中运行的应用程序。为此，API基本上遵循表现层状态传输（REST）范式，且原则上，它可通过超文本安全传输协议（https）进行操作。SOVD中的“面向服务”是指读出整个信息块，而不是单个信息片段的事实，这是如今常见的，同时这也使远程应用程序的设置变得更加容易，因为传输路径的质量已与执行诊断无关。

| 在工程领域的诊断使用

简单来说，诊断工程必须分为两个阶段，即机电一体化系统中的工程和集成。

在机电一体化系统的工程设计中，通信协议首先必须在诊断方面发挥作用。基于此，再在控制单元中创建实际的诊断功能：

• 监视导致错误内存条目的例程；

• 获取测量值；

• 诊断软件的参数化可能性，例如用于变体编码；

• 软件更新的编程可能性。

然后，在ECU测试中，通过模拟环境（如硬件在环等）、测试台与真实环境一起来验证这些功能。

因此，首先需将多个控制单元集成到总线中，并在交互中测试其通信和功能。然后，设置车辆原型，并最终在道路测试期间于真实车辆中释放诊断功能，如图1所示。

从诊断应用程序的角度来看，这会导致两种完全不同的方案。SOVD服务器通常在组装好的车辆中可用，因此诊断也应通过该服务器进行，以确保制造和服务应用的足够成熟度。

| 对诊断系统的影响

由此，诊断系统必须支持两种不同的路径：最初，诊断通过UDS进行，但现在随着成熟度的提高和整个系统的更大集成，诊断需通过SOVD服务器进行，且两个系统都需进行参数化。在当前的诊断工具中，可通过使用数据ODX来应对。ODX描述了不同的诊断功能，而SOVD服务器的情况与此类似——对配备不同的整车进行诊断。此外，这必须通过参数化来访问，并能够在操作过程中进行更改。由于目前许多功能都是在软件中实现的，因此可在售后进行调整（如图2）。

通常，诊断系统具有两条路径：第一条是ODX系统通过UDS通过ECU进行诊断；第二条是以参数化的SOVD服务器为诊断基础的专有方法。当然，这两条路径也可并行使用。如果出现问题，则通过UDS路径直接访问ECU即可轻松查明原因。

| 理想化解决方案

在这种混合系统中，SOVD服务器可通过和MVCI服务器相同的方式来进行参数化：通过上述ODX数据。在实际系统中，它们很少以纯形式使用，而是在运行时格式使用。这样做的好处是，作为安全关键组件，其可更加轻松地保护数据，并能高度压缩和优化运行时的数据。此外，混合系统在两条路径上表现出的一致运行时行为，可使结果具有同等的可比性和可靠性。

因此，目标愿景可能如下所示：

• 在SOVD服务器中使用车辆中的运行状态系统；

• 运行时的系统可处理车辆特定和完整的数据；

......

请点击此处，查看剩余30%精彩内容！

| 往期回顾

▶ 基于ODX/OTX诊断的整车扫描

▶ 成功案例分享 | 未来工程机械的智能诊断技术