SOVD 和欧盟维修权：为 SDV 构建可扩展且合规的诊断访问架构

大多数在欧盟市场运营的原始设备制造商已经知道维修权的合规性。自1995年以来，《机动车集体豁免条例》（MVBER）要求独立维修商不受歧视地获得诊断。这不是一项压制该行业的新法规，它是塑造欧洲汽车市场三十年来运作方式的既定基准。

改变的是车辆。软件定义车辆——包括集中式 HPC、容器化应用程序、远程 OTA 更新和云连接服务工作流程——正在使传统诊断架构变得越来越脆弱。在独立 ECU 和物理车间访问时代，在技术上满足 MVBER 要求的方法难以扩展到 SDV 时代。

如今，OEM 面临的真正问题不在于是否提供诊断访问权限——他们已经有义务这样做了。这取决于随着车辆软件复杂性的加剧，他们的诊断架构能否真正以可管理、安全且具有运营价值的方式提供访问权限。SOVD 是架构方面的答案，其优势远不止于合规性，还包括 OEM 如何使其经销商和独立服务网络能够在越来越多的软件驱动汽车上运行。

合规基准：MVBER的实际要求

MVBER赋予汽车制造商不受某些欧盟竞争法要求的限制，包括运营特许经销商网络的权利，以换取一项明确的义务：独立维修商必须以公平的商业条件不受歧视地获得技术数据、诊断工具和维修信息。

这意味着原始设备制造商无法使用专有诊断架构来设置事实上的访问障碍，这种壁垒有利于授权经销商网络而不是独立维修商。访问必须在技术上是可行的，而不仅仅是理论上允许的。随着车辆越来越采用软件定义，“技术上可行” 的要求越来越高。

一个具体的例子： 一家主要的原始设备制造商一直在探索SOVD，特别是因为他们的专有诊断解决方案无法以目前的形式在欧盟部署。问题不在于法律意图，而是建筑现实。专为经销商网络设计的专有系统创建的访问模式无法完全映射到MVBER所需的非歧视访问权限，尤其是在诊断程序进入软件和远程域时。

MVBER 一览

自 1995 年起活跃，延期至 2028 年。要求原始设备制造商以与授权经销商网络相同的非歧视性条件向独立维修商提供车辆维修和技术信息。适用于所有在欧盟市场销售汽车的 OEM，无论其总部在哪里。

为什么 SDV 让架构问题变得更难

传统诊断是围绕稳定的分布式 ECU 架构设计的。每个 ECU 都有固定的标识符、静态描述文件和已知的 UDS 实现。合规性意味着发布这些接口——既复杂又不完美，但可以实现。

软件定义车辆在多个方面打破了这种模式：

• 动态软件配置： 现代 SDV 在 HPC 上运行容器化应用程序。每次 OTA 更新时，软件都会发生变化。发货的车辆不是六个月后在野外运送的车辆。静态描述文件和固定的 ECU 地图无法跟上步伐。
  
• 远程和基于云的服务工作流程： 诊断越来越多地发生在车辆到达车间之前——远程预分类、车队健康监测、OTA触发的维修警报。传统的物理访问诊断模型并不是为此而设计的，而连接到传统系统的专有远程隧道会造成碎片化。
  
• 多方利益相关者访问要求： MVBER 需要独立维修商的访问权限。舰队运营商也需要自己的访问权限。OEM 中央支持需要远程可见性。经销商技术人员需要店内工具。工程团队需要深度调试权限。通过专有的点对点集成来管理所有这些都是不可扩展的。
  
• 审计和合规证据： 像UN R156这样的法规要求提供结构化证据来证明如何管理软件更新。随着机队规模的扩大，从专有系统中分散的日志中组装合规包越来越站不住脚。

结果是，正是在服务和合规义务不断扩大的时候，构建了足以满足上一代汽车的诊断架构的 OEM 正面临着复杂的技术债务。

SOVD：可扩展接入的架构基础

SOVD（以服务为导向的车辆诊断）是一项ASAM标准（以ISO 17978的身份通过ISO 17978），它定义了基于HTTP/REST的车辆诊断API。传统诊断要求所有工具为每个车辆程序实现自定义通信逻辑，而 SOVD 提供了通用的 API 合同。诊断内容（故障代码、测量、配置参数、软件更新状态）通过使用 JSON 的标准化 REST 端点公开，功能可通过 OpenAPI 规范自行描述。

对于同时履行欧盟合规义务和 SDV 服务复杂性的 OEM 来说，SOVD 通过相同的架构投资来解决这两个问题。

适用于所有访问场景的单一接口

SOVD 定义了适用于远程（基于云的）、近程（店内）和车载场景的统一 API。在车间进行连接的独立维修人员、远程监控的车队操作员以及在服务访问之前进行预分类的 OEM 支持工程师都通过相同的逻辑接口进行交互——访问权限受基于角色的权限控制，而不是受他们碰巧拥有的专有工具堆栈的控制。

对于 MVBER 的合规性，这很重要，因为该架构本质上支持非歧视性准入。OEM 定义授权级别（谁能看到什么），但接口本身是标准化的，可供任何授权工具使用，不局限于 OEM 特定的 VCI 或工具链。

受控的、可审计的访问权限——OEM 保持控制权

值得强调的关键点是：SOVD 不会向任何人开放车辆诊断功能。原始设备制造商通过OAuth 2.0和OpenID Connect保留对授权的完全控制权，这些安全标准与企业软件中使用的安全标准相同。基于角色的访问控制确切地决定了每种客户机类型可以做什么。独立维修人员可以访问故障代码和定义的诊断例程。OEM 工程师可以更深入地访问校准和调试功能。车队运营商可以看到运行状况和状态数据。

改变的不是谁控制访问权限（OEM 仍然如此），而是访问权限的管理方式。一个标准化、记录在案、可审计的 API 取代了一组难以大规模管理的分散的专有集成。

桥接传统 ECU 和基于 HPC 的架构

SOVD 不需要更换现有的 ECU 基础设施。传统诊断适配器处理传统 ECU 的 SOVD 请求和 UDS 命令之间的转换，传统系统仍能正常工作。新的基于 HPC 的应用程序可以通过 SOVD 原生提供诊断信息。独立维修商的工具与一个接口通信；车辆在内部处理路线。这使得分阶段采用成为现实，无需实施翻新计划。

合规证据作为副产品

UN R156 要求原始设备制造商维护软件更新管理系统，为更新的规划、执行和验证提供结构化证据。SOVD 的标准化、记录的 API 交互会自然生成这些证据。软件清单、准备情况检查、更新后验证和审核日志是正常 SOVD 操作的产出，而不是在合规性审查时单独进行的取证工作。

经销商和服务网络的优势

除了合规性之外，SOVD 的更深层次价值在于它为经销商和为 SDV 服务的独立服务网络带来的价值。这就是运营投资回报率变得具体的地方。

参观研讨会之前进行远程预分类

OEM 中央支持人员可以在车辆到达维修之前通过 SOVD 对其进行访问——检索日志、识别故障模式、配置高分辨率数据采集，在许多情况下，无需实际访问即可解决问题。当需要访问车间时，技术人员到达时会提供背景信息，而不是一纸空白。首次修复率提高。减少了不必要的零件更换。保修成本下降。

与软件更新保持同步的经销商工具

在软件定义的车辆中，汽车的诊断配置文件可能会随着每次OTA更新而改变。SOVD 的自描述架构意味着经销商工具可以在运行时发现当前的车辆功能，而不是依赖可能已经过时的静态描述数据库。经销商研究的是当今存在的汽车，而不是六个月前的软件快照。

支持独立维修商，不会泄露 IP

维修权的核心紧张局势之一一直是：如何在不暴露专有校准软件、ECU代码和高价值算法的情况下提供有意义的诊断访问权限？SOVD 通过服务封装解决了这个问题。该API在不暴露底层软件实现的情况下，暴露了维修商诊断和维修车辆所需的内容——故障代码、测量值、定义的测试例程。OEM 定义诊断服务边界；SOVD 强制执行该边界。

为车队运营商提供可扩展的访问权限

车队运营商代表着一些最苛刻的服务场景：车辆数量多、正常运行时间关键型运营、地理位置分散的车队。SOVD 通过用于单个车辆诊断的相同 API 实现车队级别的运行状况监控——汇总故障模式、跟踪整个车队的软件版本，以及在主动服务需求出现故障之前将其呈现出来。

Sibros SOVD：从评估到生产
‍Sibros 已经建立了一个完整的 SOVD 产品 -涵盖车载服务器功能和云/后台工具-专为从架构评估到生产部署的 OEM 而设计。我们的产品包括：

• SOVD 客户端 和管理平台： 基于角色的访问控制、远程和近距离诊断工作流程以及贯穿车辆生命周期的结构化审计日志。
• 制造和售后整合： 相同的 SOVD 基础设施支持下线配置、经销商服务工具和远程车队监控，无需单独实施。
• OTA 和日志生态系统： SOVD 诊断和 软件更新管理 与 Sibros 一起使用统一的基础架构 深度记录器 和 OTA 功能。
• SOVD 咨询服务： 适用于 OEM 评估架构决策、确定供应商要求范围或计划在车辆项目中分阶段采用 SOVD。‍

‍三十年来，欧盟的维修权合规性一直是基准。正在发生变化的是车辆，随之而来的是跨软件定义车队大规模实现合规性的架构需求。围绕 SOVD 构建诊断基础设施的 OEM 现在不仅仅是在解决合规性问题。他们正在为 SDV 时代奠定服务运营基础。