SOVD系列之三--SOVD架构

• 3 SOVD架构
  
  
• 3.1 利用场景
  随着无线毗连技术进入汽车市场，将会出现新的访问和利用车辆诊断的方法。从历史上看，车辆诊断一直专注于基于近距离的用例，即技术职员或工人位于车辆附近并毗连外部装备以实行诊断使命。Wi-Fi 和移动宽带网络接入 (4G、5G) 答应远程和 OTA 用例，例如远程诊断、配置和软件更新。随着 HPC 引入新的车辆架构，这也使得无需任何永世的外部毗连即可实行车载诊断使命。
  SOVD 为车载、近距离和远程诊断用例提供解决方案。该标准旨在满足基于 UDS（ISO 14229 [1]）、D-PDU API（ISO 22900-2 [18]）、ODX（也称为ISO 22901-1 [9] 或ASAM MCD-2D）和ASAM MCD-3D（也称为ISO 22900-3 [29]）的当前诊断堆栈未涵盖的用例的要求。
  
  
• 3.1.1 远程
  对于远程用例，假设操作员不在车辆附近，而是通过（移动）宽带网络（无线）远程访问车辆。远程用例不肯定需要人类最终用户，但也可以包括基于云的服务，例如车队管理、数据网络和分析，这些服务仅间接向人类用户提供信息。远程用例大概依靠于车载用例，例如，在网络不可用的情况下缓冲数据。
  远程诊断用例包括但不限于以下内容：
  
     
  
  • 信息检索（例如，燃油液位、电池健康查抄）   
    
  • 查抄运行状态   
    
  • 配置   
    
  • 排放查抄   
    
  • 车间维修预备   
    
  • 远程故障清除   
    
  • 远程激活车辆功能   
    
  • 软件更新   
    
  • 固件更新   
    
  • 车队管理   
    
  • 软件配置  
    
    
  
• 3.1.2 近距离
  对于近距离利用案例，假设技术职员或工人靠近车辆，并拥有毗连到特定车辆的测试装备（通过有线或无线）。
  近距离诊断用例包括但不限于以下内容：
  
     
  
  • 故障清除   
    
  • 实行功能查抄的启动或刺激   
    
  • 定期技术查抄   
    
  • 排放查抄   
    
  • 查抄运行状态   
    
  • 软件更新   
    
  • 固件更新   
    
  • 软件配置  
    
    
  
• 3.1.3 车载
  对于车载用例，假设这些用例可以在车辆内自主运行，而无需永世毗连到远程服务器或近距离测试器。但是，车载用例的结果也可以通过近距离或远程用例访问。
  车载诊断用例包括但不限于以下内容：
  • 车载监督器
  • 防备性/预测性维护
  • 车队监控场景（例如，定期网络车辆状态）
  
  
• 4.SOVD API根本概述
  
  
• 4.1 基于HTTP REST
  SOVD API 遵照 REST 原则 [16]。这意味着诊断内容以资源的形式提供。资源可通过其特定的资源路径访问。
  在 SOVD 中，资源路径由单个实体的路径（拜见 4.2）以及为该实体提供的标准化资源和资源集合（拜见 4.3）组成。
  单个诊断内容可用的操作利用 HTTP 方法表示。SOVD 利用以下 HTTP 方法：
  Table 1 HTTP methods used by SOVD
          HTTP method     Purpose                   GET     从资源中读取内容             PUT     更新资源内容（例如，通过写入新值）             POST     创建新的（暂时）资源             DELETE     删除已创建的资源，将内容重置为默认值    以下示例将简要分析 SOVD 利用的基于 REST 的方法。以下章节将详细先容如何构建资源结构。
  该示例展示了车辆中的软件应用步伐，它提供了控制窗户的功能，例如，它提供了有关“RearWindows”位置的信息。
  
  
  
  Figure 1 WindowControl example
  在 SOVD 方面，这是通过提供包含叶资源“RearWindows”的 SOVD 实体“WindowControl”来实现的，可以利用 GET 操作读取。以下示例中资源路径的路径元素“apps”和“data”将在后面的 4.2 和 4.3 章中表明。
  Example:
  Request:
  
  1. GET {base_uri}/apps/WindowControl/data/RearWindows HTTP/1.1

  复制代码
  
  
• 4.2 实体（Entities）
  SOVD API 定义了生存诊断内容的实体。要访问诊断内容，SOVD 客户端需要指定要与之交互的实体。本小节先容实体类型、层次结构以及如何在方法请求中引用实体。
  
  
• 4.2.1 实体类型
  SOVD 标准定义实体类型如图 2 所示。实体类型定义足够机动，可以支持各种拓扑和诊断策略。SOVD 实体将诊断内容作为资源生存。实体类型可用的资源集合在 4.3.1 中定义。
  
  
  
  Figure 2 Entity types overview
          EntityType     EntityCollectionType     Description                   SOVDServer     /     SOVDServer 代表 API 结构的入口点。该级别的资源仅与 SOVD 服务器自己相关，而不是从其他实体聚合而来。             Area     areas     地区代表逻辑视图，可用于描述各种车辆拓扑，例如域架构（车身控制、信息娱乐、动力系统）、地区架构（前部、后部）或逻辑架构（软件定义车辆）。             Component     components     组件是硬件或软件的代表。组件也可以代表两者的组合（例如，带有根本软件的 ECU）。代表硬件的组件的特点是具有 CPU 和实行软件。例如 HPC、ECU 和智能传感器。作为组件一部门的软件的特点是实行应用步伐所需的根本软件。根本软件的示例是操作系统或假造机管理步伐。只有软件组件或包含软件部门的组件才应链接到应用步伐。             App     apps     App 表示在组件上实行的应用步伐，例如 Advanced-Lane-Keeping 或 Window Control。             Function     functions     功能代表功能视图，答应 OEM 定义对诊断信息的访问，这些信息大概分布在多个组件中，例如车辆识别。留意：本标准未定义功能处置惩罚的更多细节。    从 API 角度来看，硬件和软件组件之间没有区别。但是，OEM 可以选择这样做，并在组件层次结构中表示这一点。
  
  
• 4.2.2 多个SOVD server环境
  本标准既不定义也不要求车辆内的特定架构。它旨在支持 OEM 定义的任何架构，包括单个车辆中的多个 SOVD 服务器。猛烈建议车辆中的每个实体都绑定到专用的 SOVD 服务器，并且只能通过该服务器举行访问（拜见 4.2.1）。
  
  
• 4.2.2.1 公共SOVD server
  每个 SOVD 服务器都可以通过毗连措施（远程或近距离）从外部直接访问。OEM 有责任为远程 SOVD 客户端提供公共 SOVD 服务器的标识。对于近距离客户端，应利用 4.9 中描述的标识方法。
  
  
  Figure 3 Public SOVD server
  
  
• 4.2.2.2 私
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。