ISO 17978-32026 道路车辆 面向服务的车辆诊断(SOVD) 第3部分应用程序编程接口(API)标准立项发展报告

道路车辆面向服务的车辆诊断(SOVD)第3部分：应用程序编程接口(API)标准立项发展报告StandardizationDevelopmentReport:Roadvehicles—Service-orientedvehiclediagnostics(SOVD)—Part3:Applicationprogramminginterface(API)摘要随着汽车智能化、网联化进程的加速推进，传统基于控制器局域网（CAN）的诊断协议已难以满足软件定义汽车对诊断数据访问、远程升级及云端协同的实时性与灵活性需求。面向服务的车辆诊断（SOVD）作为新一代诊断范式，通过将诊断能力封装为标准化服务接口，实现了诊断功能在车载与云端之间的无缝集成。ISO17978-3:2026《道路车辆面向服务的车辆诊断（SOVD）第3部分：应用程序编程接口（API）》由国际标准化组织（ISO）于2026年3月17日正式发布，是SOVD系列标准中的核心技术规范。该标准定义了统一的API接口模型，涵盖服务发现、会话管理、数据访问、事件订阅及安全管理等核心功能模块，为整车厂、零部件供应商及诊断工具开发商提供了与传输层和协议实现无关的标准化接口契约。本报告系统梳理了该标准的立项背景、技术架构、核心内容及其产业应用价值，分析了其对现行诊断标准体系（如ISO14229、ISO13400）的互补与演进关系，并展望了该标准在智能网联汽车诊断领域的推广应用前景。该标准的发布将显著降低诊断系统集成复杂度，提升诊断数据互操作性，为下一代汽车诊断生态的构建奠定坚实基础。关键词：面向服务的诊断；应用程序编程接口；软件定义汽车；汽车诊断标准；服务化架构；智能网联汽车Keywords:Service-OrientedVehicleDiagnostics;ApplicationProgrammingInterface;Software-DefinedVehicle;AutomotiveDiagnosticStandards;Service-OrientedArchitecture;IntelligentConnectedVehicle1引言1.1标准化背景汽车产业正经历着从“机械产品”向“智能终端”的深刻变革。软件定义汽车（SoftwareDefinedVehicle,SDV）理念的兴起，使得车辆的功能迭代、故障诊断与远程维护越来越依赖于软件能力。在此背景下，传统基于信号的诊断方式——即通过UDS（统一诊断服务，UnifiedDiagnosticServices）协议在CAN或以太网链路上逐条读取故障码和参数——暴露出诸多固有局限：诊断数据模型缺乏语义标准化、诊断会话管理僵化、对车载以太网和云端的适配成本高昂、诊断功能的复用性与可扩展性不足等。为应对上述挑战，国际标准化组织ISO/TC22/SC31（数据通信分技术委员会）于2020年前后启动了面向服务的车辆诊断（SOVD）系列标准编制工作。SOVD将诊断能力抽象为一系列可调用的服务，通过RESTful风格的API对外暴露诊断功能，使诊断客户端（如维修站设备、云端服务器、车载诊断应用）能够以统一方式访问车辆诊断数据。ISO17978-3:2026作为SOVD框架体系中的第3部分，专门规范了API层的标准接口定义。1.2标准编制过程ISO17978-3:2026的编制历经了从工作组草案（WD）、委员会草案（CD）、国际标准草案（DIS）到最终国际标准（FDIS）的完整流程，历时约三十六个月。来自德国、中国、美国、日本、法国等主要汽车制造国的专家深度参与了标准文本的起草与评审，最终版本于2026年3月17日由ISO正式发布。1.3标准定位与适用范围ISO17978-3:2026适用于以下应用场景：-整车制造商的诊断系统设计开发；-汽车诊断工具（包括手持式诊断仪、PC端诊断软件、云诊断平台）的接口开发；-第三方服务提供商在维修保养、远程预警、二手车评估等领域构建诊断数据服务。该标准面向的对象包括整车企业诊断系统架构师、ECU软件工程师、诊断工具链开发人员、云端诊断平台开发者以及相关测试认证机构。2技术背景2.1现行汽车诊断标准体系现行国际汽车诊断标准体系以ISO14229（UDS）和ISO13400（DoIP）为核心。ISO14229-1定义了统一诊断服务，规定了诊断会话控制、数据读取、故障码管理等服务原语；ISO13400则定义了基于TCP/IP和以太网的诊断通信协议（DiagnosticoverIP,DoIP）。上述标准在设计之初主要面向物理层的有线连接和单ECU的请求-响应模式。然而，随着智能网联汽车的快速发展，诊断需求已发生根本性变化：第一，诊断对象从“单个ECU”扩展到“整车系统”甚至“车队”，需要诊断数据的聚合访问与跨ECU关联分析；第二，诊断场景从“线下维修”延伸至“远程诊断”和“预测性维护”，需要支持车载诊断客户端（Tester）位于云端或移动端；第三，诊断功能需要支持灵活的订阅/发布机制，而非仅限周期性轮询，以满足实时候诊数据监控的需求；第四，面对OTA（Over-The-Air）升级等场景，诊断协议需要与上层服务架构有效融合。2.2面向服务架构（SOA）在汽车领域的应用面向服务架构（Service-OrientedArchitecture,SOA）作为一种软件架构风格，强调将系统功能封装为可独立部署、可动态发现的服务。在汽车领域，AUTOSARAdaptivePlatform已将SOA作为核心设计原则，支持服务的动态发现、远程过程调用（RPC）和事件订阅。SOVD标准正是建立在SOA思想基础之上，将传统的诊断功能（如读取故障码、执行例程、读写数据标识符等）建模为RESTful服务，通过HTTP/HTTPS或类似传输协议对外暴露接口。2.3SOVD系列标准的整体架构ISO17978系列标准由多个部分构成。第1部分规定了SOVD的总体框架、术语定义和使用场景，第2部分则聚焦于SOVD的传输层与通信协议要求，而本次立项的ISO17978-3:2026则专注于API层——即为客户端访问SOVD服务提供统一、语言无关的接口规范。后续还可能包括测试一致性、安全扩展等部分。2.4API标准的必要性与紧迫性API作为SOVD体系中的“最后一公里”，决定了SOVD标准能否被产业界高效落地。如果缺乏统一API规范，各厂商将自行定义接口细节，造成接口碎片化、工具链割裂，最终削弱SOVD的互操作性价值。因此，ISO17978-3:2026的立项与发布，是SOVD标准化进程中不可或缺的关键环节。其意义在于为SOVD服务端与客户端之间确立了“契约”，任何符合该契约的实现均可无缝接入SOVD生态。3标准核心技术内容ISO17978-3:2026规定的API体系主要由接口模型、服务发现机制、核心服务定义、事件订阅机制和安全架构五个模块构成，其技术框架如图1所示。```┌─────────────────────────────────────────────────────────────┐│诊断客户端(TestClient)││(维修诊断仪/云端诊断平台/车载诊断应用)│└──────────────────────────┬──────────────────────────────────┘│HTTPS/HTTP┌──────────────────────────▼──────────────────────────────────┐│ISO17978-3:2026API层││┌───────────┬───────────┬───────────┬──────────────────┐│││服务发现│会话管理│数据访问│事件订阅/通知│││└───────────┴───────────┴───────────┴──────────────────┘││┌──────────────────────────────────────────────────────┐│││安全机制(TLS/证书/鉴权)│││└──────────────────────────────────────────────────────┘│└──────────────────────────┬──────────────────────────────────┘│┌──────────────────────────▼──────────────────────────────────┐│SOVD服务端(车载诊断服务网关)││(ECU诊断服务封装/整车诊断数据聚合)│└─────────────────────────────────────────────────────────────┘```图1ISO17978-3:2026API架构示意图3.1API接口模型ISO17978-3:2026采用RESTful架构风格，以资源为中心定义接口模型。标准明确规定了API的根路径结构、资源命名规则及HTTP方法语义。例如，/diagnostics/sessions用于管理诊断会话，/diagnostics/dids用于访问数据标识符，/diagnostics/dtcs用于读取和管理故障码。在数据格式方面，标准推荐使用JSON或CBOR（ConciseBinaryObjectRepresentation）作为数据编码格式，同时充分兼容MIME类型协商机制，允许客户端指定所需的数据格式。该接口模型对底层传输协议透明，可在HTTP/HTTPS或其他支持的传输协议上运行，无需依赖特定的编程语言或操作系统环境。3.2服务发现与注册服务发现是SOVD体系的核心基础能力。ISO17978-3:2026定义了标准的服务发现机制，使诊断客户端能够动态获取车辆上可用的诊断服务列表、服务版本信息、服务能力描述和访问入口地址。这为诊断工具提供了“即插即用”般的体验。标准规定了服务描述文档的格式要求（基于OpenAPISpecification3.x）和发现流程，支持直连发现与代理发现两种模式，同时明确定义了服务注册与注销的流程和约束条件，以保障多客户端并发环境下的信息一致性。3.3核心API功能模块会话管理：定义诊断会话的建立、保持和终止流程。标准将诊断会话划分为默认会话、编程会话、扩展诊断会话等类型，并引入会话超时机制。API规定了会话的状态机模型以及多客户端并发访问时的会话隔离策略。数据访问接口：规定了通过API读取和写入车辆诊断数据的方法，包括按数据标识符（DID）访问、按分组批量读取和周期性读取三种模式，并对数据格式的编码规则、数据类型定义进行标准化。故障码管理接口：定义了读取活动故障码、读取历史故障码、清除故障码和读取故障码快照等服务的API语义，明确了从故障码查询到故障环境数据获取的全流程接口要求。例程控制接口：规定了远程执行ECU内诊断例程（如执行部件测试、写入参数、校准程序等）的API定义，涵盖例程的启动、查询和终止三个控制动作，并对例程执行中的安全保护措施提出了明确要求。安全访问接口：定义了安全解锁、访问令牌的管理机制，规定API层基于TLS/HTTPS确保传输层安全，并通过标准的认证流程与授权模型实现访问控制。3.4事件订阅与通知机制针对诊断场景中常见的异步通信需求，标准提供了基于WebSocket或HTTP/2Server-Push的事件订阅机制。诊断客户端可订阅特定的诊断事件（如故障码变化事件、DID值越限事件、ECU状态变化事件等），服务端在事件发生时主动推送通知。标准定义了事件过滤规则、订阅生命周期的管理以及通知消息的格式与优先级。3.5安全架构与合规性ISO17978-3:2026在安全架构方面采用了纵深防御的设计理念，充分吸收了ISO21434（道路车辆-网络安全工程）的核心要求。标准强制要求传输层使用TLS加密，规定客户端身份认证的支持方式，并针对不同诊断操作引入细粒度的授权分级控制。同时，标准对API实现的数据隐私保护提出了要求，确保符合相关法规对个人数据和车辆数据保护的规定。4主要参与单位4.1主导编制单位ISO17978-3:2026由ISO/TC22/SC31（道路车辆技术委员会数据通信分技术委员会）归口管理。SC31下设的SOVD工作组（WGxx）具体负责标准文本的编制工作。工作组成员来自全球主要汽车制造商、零部件供应商、诊断工具开发商及学术研究机构。4.2代表性参与单位——罗伯特·博世有限公司罗伯特·博世有限公司（RobertBoschGmbH）是SOVD系列标准编制工作的核心贡献者之一。博世作为全球领先的汽车技术与服务供应商，长期深度参与ISO/TC22/SC31的标准化活动，并在SOVD标准的架构设计阶段发挥了重要的引领作用。博世的工程师团队在标准编制过程中，积极协调欧洲、亚洲和北美专家意见，促进了SOVDAPI规范在跨区域产业实践中的兼容性和可落地性。博世的深度参与，使得ISO17978-3:2026不仅具有理论上的先进性，更兼顾了大规模工业化实施的现实需求。5技术比较与产业影响5.1与现有标准的关系ISO17978-3:2026与现行诊断标准并非替代关系，而是互补与演进关系。ISO14229（UDS）仍将作为ECU内部诊断功能的基础协议继续使用，SOVDAPI充当了“顶层统一访问接口”的角色，将底层UDS/DoIP的诊断能力封装为标准化服务。对于已部署UDS/DoIP的系统，SOVDAPI可通过适配层实现向后兼容。5.2产业应用价值ISO17978-3:2026的发布将对智能网联汽车诊断产业链产生多方面深远影响：|应用领域|应用方式|预期效果||---------|---------|------