usstmiracle的博客

DTC状态位，即StatusOfDTC，是用来指示DTC所对应的故障是否发生，是否被确认等状态。DTC状态位包含1个字节数据长度，每一位都有具体的定义，如下所示：但并不是每一位不一定都要使用，具体取决于各OEM的需求，在ISO14229-1中，除了bit3: ConfirmedDTC是强制约束外，其他都没有强制约束。首先了解几个概念：测试（test），操作循环（operation cycle）和老化（aging）

参数名称定义约束（Cvt）说明服务唯一标识M（强制）请求 SI 固定为0x22，肯定响应 SI 为0x62（请求 SI+0x40）数据标识符（DID）2 字节参数，唯一标识数据记录M（首个 DID）/U（后续 DID）格式为 “字节 1（MSB，高位字节）+ 字节 2（LSB，低位字节）”，如0x0123代表 ECU 软件版本数据记录（Data Record）DID 对应的具体数据M（首个 DID）/U（后续 DID）数据长度与格式由 DID 定义，如0x0123。

实例化规则：按 “每 1 个 DiagnosticContributionSet 对应 1 个诊断服务器实例” 创建，1 个 SoftwareCluster 可关联 1 个或多个 DiagnosticContributionSet（但通常 1 对 1），多个实例共享 UDS/SOVD 传输层（如 DoIP 端口、SOVD HTTPS 端口），但资源完全隔离（SWS_DM_00420）；核心定位。

合法性保障：通过多维度校验过滤无效请求，避免系统资源浪费；安全性防护：通过安全等级、认证、权限控制，防止未授权访问；有序性管控：通过会话机制、优先级调度，确保多客户端并发通信有序；兼容性支撑：生成标准化 UDS/SOVD 响应，确保不同客户端（诊断仪、车载 ECU）可解析。所有作用均需遵循 SWS_DM 系列要求（如 SWS_DM_00286 请求校验、SWS_DM_00390 请求分发、SWS_DM_01123 认证处理），确保 AUTOSAR 自适应平台诊断功能的兼容性与一致性。

双传输层并行：UDS（DoIP / 自定义 TP）面向传统诊断，SOVD（HTTP/REST）面向服务化诊断，覆盖不同诊断场景；资源隔离：诊断服务器按 SoftwareCluster 实例化，会话、DTC、安全状态独立，避免跨实例干扰；规范性强：所有功能均绑定 SWS_DM 系列要求（如 SWS_DM_00329 生命周期、SWS_DM_01369 SOVD 服务器），确保兼容性；安全性高：DoIP/SOVD 均支持 TLS 加密，UDS/SOVD 共享安全状态，严格的权限校验与认证机制；可扩展性。

除 DoIP 外，允许通过继承实现自定义传输协议（如 CAN TP），仅需适配管理器 API 即可接入（SWS_DM_00315）；传输层与应用层解耦：诊断服务器无需感知底层协议，仅通过管理器接收 / 发送消息。

标准化：严格遵循 ISO 14229-1 与 ASAM SOVD，确保不同厂商诊断工具与 ECU 的兼容；安全性：通过会话控制、认证、加密、权限校验，防止未授权诊断操作；灵活性：支持多 Software Cluster、多客户端并发，适配车载诊断的复杂场景；可靠性：标准化的请求验证、响应反馈与异常处理，确保诊断交互稳定可控。无论是车间诊断仪的故障排查、车载 T-BOX 的远程诊断，还是 ECU 的固件更新，均需依赖诊断通信管理实现规范化的交互，是自适应平台诊断功能不可或缺的核心模块。

SOVD是 Adaptive AUTOSAR 平台定义的一套面向服务的诊断框架。它旨在满足现代高性能汽车电子架构（如域控制器、中央计算单元）对诊断的新需求。这是其最核心的特征。它摒弃了经典AUTOSAR中基于信号（CAN/LIN）的点对点诊断通信方式，转而采用基于服务和方法调用的通信模式，这与Adaptive平台的SOA（Service-Oriented Architecture）理念一脉相承。SOVD 诊断通信通常运行在以太网等IP网络上，利用SOME/IP等中间件进行数据传输。

DID（数据标识符）是 2 字节十六进制编码，用于唯一标识一个 ECU 内部的数据项。通常由 OEM 定义于 ODX 文件中。提示：同一台车，不同 ECU 对应的 0xF190 返回值一致（都是VIN）有些 DIDs 只能在某些会话下读取，如 Extended SessionReadDataByIdentifier 是诊断工程师的“千里眼”，掌握它才能真正读懂ECU的状态与内在信息。UDS 测量值与状态量：如何读取 ECU 内部数据？

通过使用TLS，可以有效防御中间人攻击和其他形式的安全威胁，保障车辆诊断信息的安全传输。Secure diagnostic communication via TLS（通过TLS进行的安全诊断通信）指的是在车辆诊断过程中，使用传输层安全性（TLS）协议来保护客户端与服务器之间通信的安全性。在Client DoIP实体和Server DoIP实体开始通过TLS交换DoIP消息之前，首先在TLS握手中协商安全的TCP连接：双方就TLS协议的版本达成一致，选择通用密码套件，验证证书，并完成TLS会话密钥交换。

随着汽车行业的不断发展，特别是在电动汽车和智能网联汽车领域的快速进步，DoIP协议作为一种高效、灵活且安全的诊断通信方式，正逐渐成为行业标准。

首先，UDS（Unified Diagnostic Services，统一诊断服务）是ISO 14229标准的一部分，主要用于车辆诊断，定义了诊断服务的格式和通信机制。例如，当诊断请求来自远程服务器时，可能通过DoIP传输；它们的区别主要在于架构和传输方式：UDS是应用层协议，DoIP和DoCAN是传输层协议，而SOVD是面向服务的诊断框架，可能整合这些协议到其架构中。在Adaptive AUTOSAR中，SOVD可能更强调服务的动态性和灵活性，但底层仍可能使用UDS定义的服务，只是以SOA的方式实现。

UDS在传统车辆诊断中仍然具有重要地位，但其静态设计、有限的数据处理能力和缺乏对现代IT技术的支持，使其无法满足未来智能网联汽车的复杂需求。SOVD通过动态服务发现、现代通信技术和灵活的诊断框架，弥补了UDS的不足，为未来车辆的诊断需求提供了更加高效和灵活的解决方案。尽管UDS（统一诊断服务）在传统车辆诊断中发挥了重要作用，但随着汽车电子系统的复杂性和数据量的急剧增加，UDS逐渐显露出其局限性，无法完全满足未来智能网联汽车的需求。：现代车辆的软件架构日益复杂，UDS无法有效表示和交互这些复杂的软件结构。

本文主要介绍了面向服务的车辆诊断（SOVD）在AUTOSAR自适应平台中的实现，包括参考架构、关键组件以及具体用例等内容。首先，我需要确定文章的结构。通常，专业性文章需要包括引言、背景、主体部分（如架构、功能模块、用例等）、结论等部分。用户提供的文档已经有章节划分，可以参考这些章节来组织文章的结构。接下来，需要理解SOVD的核心概念和其与现有标准（如UDS）的区别。文档中提到SOVD是一个新的诊断标准，旨在解决UDS的一些局限性，例如依赖ODX文件和客户端技术栈的挑战。

传输协议管理器负责在两个方向上调度UDS消息：从诊断客户端接收到的UDS请求被转发到相应的诊断服务器实例，由诊断服务器实例创建的UDS响应被调度到负责处理与诊断客户端连接的传输协议处理程序（UdsTransportProtocolHandler类）。每个诊断服务器都有自己的诊断地址（如0x8E1/0x8E7）和诊断服务，因此不同的诊断服务器可以使用相同的DID（诊断标识符），但代表不同的含义，从而避免冲突。作为功能集群，诊断管理包括一个与自适应应用程序链接的库和一个实现诊断管理活动方面的守护进程。

实现的，主要用于故障检测、故障代码生成、诊断通信等功能。中，诊断模块是系统中非常重要的部分，它负责监控、检测和报告系统中的故障与异常情况。诊断功能规划：根据车辆的功能特性，设计相应的诊断功能，例如哪些模块需要支持自诊断、故障报告和通信。故障处理：系统可以基于诊断结果进行故障处理或执行相关的容错策略，确保系统的安全性和稳定性。提供了一种诊断管理框架，该框架包括诊断功能、故障管理、故障代码管理和健康监测等功能。诊断模块根据故障的严重性、类型和发生频率，将故障分为不同的等级。

RTA-VRTE Starter Kit 诊断使用 AUTOSAR Diagnostic Extract Template (DEXT) 进行配置。DEXT 是一种标准化的 AUTOSAR 交换格式，可以与系统描述（System Description）类似地使用和通信。DEXT 定义了诊断通信的所有方面（例如 UDS 服务、会话配置、安全级别配置等）和诊断事件管理（例如诊断故障代码（DTCs）、诊断事件、操作周期等）。

一、标准基本知识(1) 服务ID（SID，Service Identifier）ISO-14229标准定义了25种不同的诊断服务，为区分具体的诊断服务，使用1个字节的服务ID作为服务的唯一识别码。当我们想表达一个具体的诊断服务时，有时候直接说出它的服务ID比起全称会更加简洁有效。表1所示是ISO-14229标准定义的诊断服务汇总列表。当然，并不是所有的诊断服务需要支持，标注有*符号为常用诊断服务。

DTC（Diagnostic Trouble Code）是车辆ECU存储的故障代码，用于标识车辆的特定故障问题。

本规范描述了 AUTOSAR 自适应诊断管理 (DM) 的功能、API 和配置。DM 是一个符合 ISO 14229-1[1] 的 UDS 诊断实现，也是一个符合 ASAM SOVD v1.0.0 [2] 的 SOVD 实现，用于 Autosar 自适应平台。自 R19-03 版本起，引入了一个 C++ 接口，作为诊断的接口，用于替代之前基于 ara::com 的服务接口。AUTOSAR 诊断提取模板 (DEXT) [3] 是 DM 的配置输入。AUTOSAR 自适应平台可以通过添加新的软件包来进行扩展，而

总的来说，DoIP和DoCAN都是为了实现统一的诊断服务（UDS）而设计的，但它们在物理通信层面、数据传输速度和远程诊断能力等方面有所不同。DoIP，即基于IP的汽车诊断协议，由ISO 13400-2标准定义，它促进了使用IP、TCP和UDP的外部测试设备与汽车控制单元（ECU）之间的诊断相关通信。通过互联网协议（DoIP）的诊断开启了一种新的ECU诊断范式，该范式通过以太网运行，这是一个更快、更可靠的通信渠道。DoIP协议是基于TCP/IP协议的网络协议，允许通过网络传输车辆诊断数据。

通过互联网协议（DoIP）的诊断开启了一种新的ECU诊断范式，该范式通过以太网运行，这是一个更快、更可靠的通信渠道。DoIP协议是基于TCP/IP协议的网络协议，允许通过网络传输车辆诊断数据。DoIP协议将诊断数据封装在TCP/IP数据包中，并使用UDP协议进行传输。它还定义了一组标准的诊断服务，例如读取故障代码、清除故障代码、读取实时数据等。

在UDS（Unified Diagnostic Services）协议中，DID用于唯一标识车辆电子控制单元（ECU）中的特定数据项。UDS协议定义了一系列标准化的诊断服务，通过这些服务可以读取、写入或清除特定的DID数据。

TLS（Transport Layer Security）是一种广泛使用的安全协议，旨在确保互联网通信的隐私性和数据完整性。它是SSL（Secure Sockets Layer）的继任者，最初版本于1999年发布，最新版本是TLS 1.3。

ODX（Open Diagnostic Data Exchange）是一种由ASAM制定的开放标准，用于描述和交换ECU（电子控制单元）诊断数据，广泛应用于车辆诊断。ODX文件采用XML格式，包含通讯参数，如ISO15765-2/3时间参数。