工程中的SOVD——从ECU到车辆
SOVD标准正在改变诊断方式，特别是在互联网上当多个合作方进行交互时，其提供了很大的优势。在开发的早期阶段，需要使用附加的方法来利用这个标准，因为该标准并不是专为ECU诊断而开发的，而且还需格外注意数据的处理，因为这可能会导致并行系统中的大量额外成本。对于它们的平衡可使用诸如Softing SDE的诊断系统——这些系统专为广泛的应用场景而设计，且可通过SOVD API进行轻松扩展。在我们最新发布的文章“诊断系统 加速开发”中，可获取此主题更多信息。
诊断系统 加速开发
如果没有基于控制单元诊断的专家系统，则对使用了50~150个控制器、多个总线系统和分布式功能的当今车辆进行维修几乎是不可能的。而这也同样适用于生产：没有诊断仪就无法发现错误。为了使诊断充分发挥作用，在车辆开发方面就需要付出相当大的努力，且这一趋势还在不断上升。
近年来，ASAM e.V.定义了新的诊断标准以满足新的要求：面向服务的车辆诊断（SOVD）。API是为运行状态系统定义的编程接口，这使得诊断信息可直接应用于在车辆中运行的应用程序。为此，API基本上遵循表现层状态传输（REST）范式，且原则上，它可通过超文本安全传输协议（https）进行操作。SOVD中的“面向服务”是指读出整个信息块，而不是单个信息片段的事实，这是如今常见的，同时这也使设置远程应用程序变得更加容易，因为传输路径的质量已与执行诊断无关。
| 在工程领域的诊断使用
简单来说，诊断工程必须分为两个阶段，即机电一体化系统中的工程和集成。
在机电一体化系统的工程设计中，通信协议首先必须在诊断方面发挥作用。基于此，再在控制单元中创建实际的诊断功能：
• 监视导致错误内存条目的例程；
• 获取测量值；
• 诊断软件的参数化可能性，例如用于变体编码；
• 软件更新的编程可能性。
然后，在ECU测试中，通过模拟环境（如硬件在环等）、测试台与真实环境一起来验证这些功能。
因此，首先需将多个控制单元集成到总线中，并在交互中测试其通信和功能。然后，设置车辆原型，并最终在道路测试期间于真实车辆中释放诊断功能，如图1所示。
（图1 开发中不断变化的诊断要求）
从诊断应用程序的角度来看，这会导致两种完全不同的方案。SOVD服务器通常在组装好的车辆中可用，因此诊断也应通过该服务器进行，以确保制造和服务应用的足够成熟度。
| 对诊断系统的影响
诊断系统因此必须支持两种不同的路径：最初，诊断通过UDS进行，但现在随着成熟度的提高和整个系统的更大集成，诊断需通过SOVD服务器进行，且两个系统都需进行参数化。在当前的诊断工具中，可通过使用数据ODX来应对。ODX描述了不同的诊断功能，而SOVD服务器的情况与此类似——对配备不同的整车进行诊断。此外，这必须通过参数化来访问，并能够在操作过程中进行更改。由于目前许多功能都是在软件中实现的，因此可在售后进行调整（如图2）。
（图2 未来车辆功能将主要在软件中实现，因此必须能够在运行过程中更改参数）
通常，诊断系统具有两条路径：第一条是ODX系统通过UDS通过ECU进行诊断；第二条是以参数化的SOVD服务器为诊断基础的专有方法。当然，这两条路径也可并行使用。如果出现问题，则通过UDS路径直接访问ECU即可轻松查明原因。
| 理想化解决方案
在这种混合系统中，SOVD服务器可通过和MVCI服务器相同的方式来进行参数化：通过上述ODX数据。在实际系统中，它们很少以纯形式使用，而是在运行时格式使用。这样做的好处是，作为安全关键组件，其可更加轻松地保护数据，并能高度压缩和优化运行时的数据。此外，混合系统在两条路径上表现出的一致运行时行为，可使结果具有同等的可比性和可靠性。
因此，目标愿景可能如下所示：
• 在SOVD服务器中使用车辆中的运行状态系统；
• 运行时的系统可处理车辆特定和完整的数据；
• 对于ECU诊断，它可作为PC上的MVCI服务器运行；
• 对于工程中的车辆诊断，它可作为PC上的SOVD服务器运行。
结果将意味着一切：统一所有用例的运行时行为，优化每个用例的数据大小以及车辆中经过验证的诊断系统。
（图 3 MVCI服务器与运行时的环境相结合，根据ISO 13209标准化诊断流程，可应用整个诊断功能）
| 诊断运行时的环境
Softing SDE是一个基于ODX且独立于平台的诊断运行时环境，可应用于工程、制造和售后的众多领域。将MVCI服务器与ODX运行时环境（开放式诊断数据交互）相结合，可实现符合ISO 13209的标准化诊断序列，此外智能诊断API还提供了面向服务的接口，从而为应用程序提供了完整的诊断功能。
例如：读取错误存储器，它将多个UDS服务（读取每个ECU的错误，查询每个错误的环境数据）组合到了SDE上的一个函数调用中。然后，这些功能将独立于连接链路运行，如4G/5G：当连接无误时，则可检索结果，如图3和图4所示。
（图 4 SDE的SOVD作为REST接口）
该程序可实现从ECU工程和测试环境到制造和维修车间的连续诊断链。首先，诊断在ECU本地实施，并使用工程测试仪进行验证。然后，集成的SDE将继续用于具有完全相同数据和配置的测试台。在道路测试中，再使用基于SDE的SOVD，从而发布最终方法。反过来，在制造中，只要带有SOVD服务器的ECU尚未被安装或无法使用，Softing SDE便是您的最佳选择。
通过此诊断链，您不仅可随时实现远程场景，还可通过SDE随时远程操作测试台。且在道路测试中，这可同时使用专有方法和SOVD服务器来实现远程操作——毕竟，远程是SOVD的主要用例。
请点击此处，了解更多信息！
