当前位置: 首页 > news >正文

AUTOSAR图解==>AUTOSAR_AP_EXP_SOVD

AUTOSAR服务导向车辆诊断详解

面向现代化车辆架构的诊断方案

目录

  • 1. 引言
    • 1.1 ASAM SOVD简介
    • 1.2 SOVD产生的动机
  • 2. SOVD参考架构
    • 2.1 SOVD网关
    • 2.2 诊断管理器
    • 2.3 SOVD到UDS转换
    • 2.4 后端连接
  • 3. SOVD用例
    • 3.1 SOVD和UDS的共同用例
    • 3.2 SOVD特定用例
      • 3.2.1 访问权限
      • 3.2.2 软件更新
      • 3.2.3 日志记录
      • 3.2.4 批量数据
      • 3.2.5 配置
  • 4. 总结

1. 引言

2022年,ASAM(汽车标准化协会)发布了新的诊断标准SOVD(Service-Oriented Vehicle Diagnostics,服务导向车辆诊断)的第一个版本。本文档旨在解释AUTOSAR如何实现SOVD标准,并提供面向用例的指导。本文档的范围超出了功能集群ara::diag,旨在提供更全面的视图,以便恰当地处理SOVD的整体性质。

1.1 ASAM SOVD简介

SOVD是一种全新的诊断协议标准,具有以下关键特性:

在这里插入图片描述

1.1.1 SOVD标准关键特性解析

上图展示了SOVD标准的关键特性和优势:

  1. 自解释协议:SOVD是一个自解释协议,不需要外部ODX数据描述进行解释。这解决了传统UDS协议的一大限制,即客户端对ODX文件的依赖。

  2. 支持多种诊断场景

    • 远程诊断:通过互联网进行远程诊断操作
    • 临近诊断:在车辆附近进行诊断
    • 车内诊断:直接在车内进行诊断
  3. 中央边缘节点通信:SOVD网关作为中央通信点,统一管理诊断请求的路由分发。

  4. 包含UDS作为子集:SOVD保留了与现有UDS功能的兼容性,可以被视为UDS的超集。

  5. 支持HPC用例:原生支持在高性能计算机(HPC)上的诊断需求,这是现代车辆架构的关键组成部分。

  6. 使用现代信息技术

    • 基于HTTP/HTTPS的通信
    • 使用REST API设计理念
    • 基于JSON的数据交换

1.2 SOVD产生的动机

截至2023年,汽车行业主流的诊断协议是UDS(统一诊断服务)。UDS最初于2006年作为ISO 14229标准化,主要针对具有严格ROM和RAM要求的微控制器进行诊断。由于该协议注重效率,数据的解释由客户端使用ODX文件处理。这带来了两个主要挑战:

  1. 客户端技术栈的复杂性:客户端必须能够解析和理解ODX文件
  2. 客户端ODX文件与诊断实现之间的强依赖:客户端ODX文件必须与车辆上的诊断实现精确匹配

SOVD通过以下方式解决这些挑战:

  • 自解释协议:不依赖外部ODX数据描述
  • 现代技术:使用当前信息技术的诊断API,如HTTP/HTTPS、JSON等

在当今的车辆架构中,高性能计算机(HPC)承担着核心功能,满足车辆端日益增长的需求。随着软件复杂性的增加,对诊断方法的新要求也随之出现,这正是SOVD标准旨在满足的需求。


2. SOVD参考架构

在分布式系统中提供中央SOVD边缘节点需要一些基础设施组件。为实现这一目标,AUTOSAR引入了一个将功能分为几个块的参考架构。这一架构如下图所示:

在这里插入图片描述

2.0.1 SOVD参考架构解析

上图展示了SOVD的参考架构,其主要组件包括:

  1. SOVD客户端:发起诊断请求的外部设备或系统
  2. 后端连接:处理远程诊断情况下的请求路由
  3. SOVD网关:作为中央节点,管理所有诊断请求的分发
  4. SOVD服务节点:包含诊断管理器,处理特定诊断请求
  5. SOVD到UDS转换:将SOVD请求转换为传统UDS请求,实现向后兼容
  6. ECU (UDS):使用传统UDS协议的电子控制单元

此架构通过明确的分层和模块化设计,实现了SOVD与传统UDS系统的无缝集成,同时为先进的诊断功能提供了基础。

2.1 SOVD网关

SOVD网关作为HTTP反向代理,在接收到SOVD客户端的请求后,将请求路由到相应的内部SOVD端点。路由是基于SOVD请求URI中的实体部分进行的。SOVD网关必须提取URI的这一部分,并将请求路由到相应的端点。潜在内部SOVD端点的设置可以通过静态配置或使用mDNS动态发现。

转发本身发生在应用层,这意味着SOVD网关会提取URI的实体部分并路由到相应的端点。

对于SOVD网关的配置,在TPS_Manifest中引入了SOVDGatewayInstantiation。这一清单允许配置面向SOVD客户端的外部SOVD连接以及内部转发目标。

2.2 诊断管理器

在SOVD引入之前,诊断管理器的主要目的是根据ISO 14229-1处理诊断服务和故障存储器。随着SOVD的引入,诊断管理器也旨在原生支持SOVD,因此作为SOVD服务器。

SOVD引入的主要指导原则之一是尽可能重用UDS的现有功能,同时不限制SOVD的原生支持。在结构层面,诊断管理器允许多个诊断服务器实例,旨在保持各个软件集群的独立性。DEXT中的每个诊断贡献集代表具有单独诊断地址的诊断服务器实例。这一寻址原则被SOVD采用。

诊断管理器本身代表一个SOVD组件,而每个诊断服务器实例由一个SOVD子组件表示。不过,诊断管理器仍作为SOVD服务器,内部路由由诊断管理器处理。对于此SOVD服务器的配置,在TPS_Manifest中引入了SOVDServerInstance。

2.3 SOVD到UDS转换

这一功能块允许基于预定义的ODX定义将SOVD命令转换为UDS请求。SOVD到UDS转换的细节由ASAM定义。该功能块应被视为一个车载测试客户端,它将向目标诊断地址发送UDS请求,并将翻译后的UDS响应发送给SOVD客户端。

尽管从实现角度看,这一功能块的复杂性很高,但由于ASAM已经定义了这些细节,AUTOSAR将仅引用ASAM标准。

2.4 后端连接

SOVD旨在支持临近、远程和车内诊断。SOVD通过引入mDNS,对临近和车内访问进行了相当精确的标准化。而由于对后端基础设施的依赖,标准化远程访问相对困难。AUTOSAR保持这一自由度。

尽管如此,通过抽象后端连接的功能块将SOVD请求路由到SOVD网关,是一种直接的解决方案。后端连接功能块可以使用mDNS发现SOVD网关,而路由可以通过HTTP转发实现。


3. SOVD用例

本章描述了SOVD用例在AUTOSAR车辆架构层面的设计和实现方式:

在这里插入图片描述

3.0.1 SOVD用例图解析

上图展示了SOVD支持的各种用例,分为两大类:

  1. SOVD和UDS共同用例:这些用例在传统UDS协议中已存在,在SOVD中得到了保留和映射

    • 会话管理
    • 诊断通信管理
    • DTC信息(故障码)
    • 诊断服务
    • 数据传输
    • 例程控制
  2. SOVD特定用例:这些是SOVD新增的功能,专为现代车辆架构设计

    • 访问权限(包括接近性挑战)
    • 软件更新
    • 日志记录
    • 批量数据处理
    • 配置

图中还展示了不同用例与参与者的交互关系:

  • 诊断客户端可以访问所有用例
  • 传统ECU (UDS)仅支持共同用例

3.1 SOVD和UDS的共同用例

SOVD用例的很大一部分可以直接映射到现有的UDS用例。诊断管理器中这种映射的实现方式在SWS Diagnostics中有详细说明。对于与UDS (ISO 14229-1)匹配的情况,引入了一个主要原则:重用与相应UDS服务相同的端口实例。

这对应用设计特别方便,因为不需要集成具有冗余功能的额外端口。此外,这些实现遵循与UDS相同的关于重入性和并行执行的规则。某些用例的SOVD处理可能与其UDS对应物有足够的差异,需要差异化的要求和机制。

在方法论上,这些SOVD方法采用了现有的配置机制,使用DEXT并仅在需要的地方扩展DEXT。

3.2 SOVD特定用例

除了与UDS共享的用例外,SOVD还引入了一些特定的用例,这些用例专为满足现代车辆架构的需求而设计。

3.2.1 访问权限

访问权限管理是SOVD的一个重要方面,特别是在远程诊断场景中。接近性挑战是其中一个关键功能,用于验证客户端是否实际位于车辆附近,这是某些诊断功能的安全前提。

接近性挑战通过要求诊断客户端提供仅在物理接近车辆时才能获得的信息,来防止未授权的远程访问。这增强了诊断系统的整体安全性。

3.2.2 软件更新

SOVD为软件更新提供了专用的用例支持,包括软件包的下载、安装和验证过程。与传统UDS相比,SOVD的软件更新功能更加强大和灵活,特别适合高性能计算机(HPC)上的复杂软件架构。

这一用例支持增量更新、版本回滚和更新过程中的状态报告等先进功能。

3.2.3 日志记录

日志记录用例提供对系统日志的访问,允许诊断客户端检索、过滤和分析车辆系统生成的日志信息。这对于故障排除和系统监控至关重要。

SOVD的日志记录功能支持多种日志级别、格式和过滤选项,使诊断更加高效和精确。

3.2.4 批量数据

批量数据用例支持大量数据的高效传输,这在处理大规模诊断数据、系统日志或软件更新时非常重要。

SOVD采用现代数据传输技术和压缩方法,确保批量数据处理的高效性和可靠性。

3.2.5 配置

配置用例允许远程配置系统参数,实现车辆功能的定制和优化。这包括修改系统设置、更新配置参数和调整功能行为。

配置用例结合了强大的验证机制,确保只有授权的更改才能被应用,从而保障系统的安全性和稳定性。


4. 总结

SOVD(服务导向车辆诊断)代表了汽车诊断领域的重大进步,特别适合当今的高性能计算机(HPC)和分布式架构。通过引入自解释协议、现代通信技术和丰富的用例支持,SOVD解决了传统UDS面临的一系列挑战。

AUTOSAR的SOVD实现提供了一个全面的参考架构,包括SOVD网关、诊断管理器、SOVD到UDS转换和后端连接等核心组件。这一架构不仅保持了与现有UDS系统的兼容性,还为先进的诊断功能和用例提供了坚实的基础。

SOVD特别适合以下场景:

  1. 高性能计算机(HPC)诊断:利用现代技术如HTTP/HTTPS和JSON,SOVD为HPC提供了更适合的诊断解决方案
  2. 远程诊断:通过标准化的接口和安全机制,SOVD简化了远程诊断操作
  3. 分布式系统:SOVD的中央边缘节点通信模型完美适应现代分布式车辆架构
  4. 高级用例:访问权限、软件更新、日志记录、批量数据和配置等特定用例满足了现代车辆的先进需求

随着车辆架构和功能的不断发展,SOVD将继续发挥重要作用,为汽车行业提供强大、灵活且面向未来的诊断解决方案。

http://www.lqws.cn/news/563473.html

相关文章:

  • 关于ubuntu 20.04系统安装分区和重复登录无法加载桌面的问题解决
  • 力扣 刷题(第七十一天)
  • 可观测性的哲学
  • 学习使用dotnet-dump工具分析.net内存转储文件(2)
  • 求区间最大值
  • 软件项目管理期末考试大题
  • 逆向入门(22)程序逆向篇-TraceMe
  • 【纯干货】调整word目录中的行距以及右对齐页码
  • 高端电影色调人像风光大片摄影后期调色Lightroom预设,手机滤镜下载!
  • Linux软连接和硬连接
  • 从 “慢如蜗牛” 到 “风驰电掣”:中欧跨境网络专线加速方案
  • spring-ai-alibaba DashScopeCloudStore自动装配问题
  • 论文阅读 Align before Fuse (ALBEF)
  • EXISTS 和 NOT EXISTS 、IN (和 NOT IN)
  • 每日算法刷题Day40 6.27:leetcode前缀和3道题,用时1h20min
  • 1.2 基于蜂鸟E203处理器的完整开发流程
  • 【大模型】Query 改写常见Prompt 模板
  • 【转】PostgreSql的镜像地址
  • InfluxDB 3 Core最后值缓存深度实践:毫秒级响应实时数据的核心引擎
  • Mysql架构
  • c++学习(五、函数高级)
  • 大事件项目记录11-文章分类接口开发-删除文章分类
  • Qt:QCustomPlot库简介
  • Vue基础(18)_收集表单数据
  • debian国内安装docker
  • 【经验】bitsandbytes安装-LLAVA-1.5库调试
  • 【数据标注师】分类标注
  • AD 学习笔记——第一章 系统的安装及参数设置
  • 一个简单测试Deepseek吞吐量的脚本,国内环境可跑
  • 印度和澳洲的地理因素