工程中的SOVD——从ECU到车辆

发布时间:2024年01月11日

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

60ecbc31-fd59-4922-9a3f-8360874a72ca

— 诊断系统 加速开发 —

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

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

| 在工程领域的诊断使用

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

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

? 监视导致错误内存条目的例程;

? 获取测量值;

? 诊断软件的参数化可能性,例如用于变体编码;

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

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

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

be5664ca-f9a3-4f22-ae3f-63bf0327e425
(图1 开发中不断变化的诊断要求)

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

| 对诊断系统的影响

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

b2e4ad44-f362-4065-b8bf-4ad6a3c06514
(图2 未来车辆功能将主要在软件中实现,因此必须能够在运行过程中更改参数)

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

| 理想化解决方案

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

因此,目标愿景可能如下所示:

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

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

......

请点击此处,查看剩余30%精彩内容!

| 往期回顾

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

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

文章来源:https://blog.csdn.net/SoftingChina/article/details/135496242
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。