AUTOSAR图解==＞AUTOSAR_AP_EXP_AutomotiveAPI-优快云博客

本BLOG上原创文章未经本人许可，不得用于商业用途。转载请注明出处，否则保留追究法律责任的权利。

本文链接：https://blog.youkuaiyun.com/zhangkaidewd/article/details/148046010

AUTOSAR Automotive API 详解

基于AUTOSAR标准的车辆数据访问统一接口

概述
1.1 背景
1.2 目标
1.3 Automotive API定义
解决方案策略
2.1 引言
2.2 VSS: 通用车辆数据模型
2.3 VISS: 通信协议
2.4 组件概览
2.4.1 引言
2.4.2 Automotive API Gateway
2.4.3 VSS衍生服务接口定义
2.4.4 Gateway的服务接口
使用场景
3.1 远程客户端
3.2 车内客户端
3.3 接口数据提供者/消费者组件
3.4 时间敏感性
部署场景
4.1 云服务器请求VSS数据
4.2 车辆中的多个Automotive API Gateway
4.3 车内应用(非AUTOSAR平台)请求VSS数据
4.4 级联VISS服务器
总结与展望

1. 概述

1.1 背景

智能网联汽车的生命周期取决于能够远程诊断车辆及其功能，并更新其软件模块以保持车辆的适航性、安全性和安保性。汽车制造商还通过其专有API向特定服务提供商和政府机构提供对车辆数据和功能的访问。

同时，用户和客户已经采用了一种新的与其联网设备和数字化生活交互的方式。这种交互是通过智能设备中的应用程序，利用云服务访问和控制联网设备，以满足对个性化配置的信息、娱乐和舒适性的需求。这也越来越成为物联网时代车辆用户的默认用户体验标准。

AUTOSAR标准在车辆内部的E/E架构中为车内连接软件组件和汽车应用程序提供了良好的支持。AUTOSAR标准还支持车辆软件的可更新性。但目前标准中还没有支持安全、可靠地将AUTOSAR应用程序生成的数据和功能暴露给非AUTOSAR客户端的机制，无论是车载还是车辆系统边界之外的客户端。Automotive API正是为了在标准中提供这种支持。

1.2 目标

Automotive API的目标是建立一种标准化的访问方式，使车内和车外应用程序（如云服务器）能够读取和写入车辆数据，同时允许数据和服务在车内网络中保持其特定于项目、OEM的定义和表示形式。至关重要的是，新接口旨在供非AUTOSAR成员的个人和组织使用。这种方法将促进网联汽车生态系统的发展，推动创新、进一步发展以及使用新接口的所有车辆和应用程序之间的兼容性。

1.3 Automotive API定义

Automotive API是一个允许与车辆进行以数据为中心的通信的接口。它定义了其他系统如何使用标准化接口安全地访问选定的车辆数据，而不依赖于车内数据表示形式，实现跨车型和制造商的统一访问方式。支持这种通信的功能集群是Automotive API Gateway，它代表了Automotive API所需的所有Adaptive Platform功能。它作为一个新的功能集群被引入到Adaptive Platform的车辆服务功能集群组中。

在这里插入图片描述

图1.1: Automotive API Gateway作为Adaptive Platform架构中的新车辆服务功能集群

上图展示了Automotive API Gateway在AUTOSAR Adaptive Platform架构中的位置，作为一个新的车辆服务功能集群，它连接了外部客户端（远程客户端和车内客户端）与AUTOSAR平台内部组件。

2. 解决方案策略

2.1 引言

本章说明如何以标准化、独立于制造商和车辆的方式描述车辆数据。然后，使用此描述，定义用户如何使用Automotive API与车辆通信以访问所需数据。

本章还介绍了如何将传入请求转换为Adaptive Platform内部表示，即一组用于描述如何在车辆内访问所需数据的ARXML服务接口定义。实现者可以自由选择如何以及在何处访问所需信息并可能进行转换或处理。这种灵活性允许实现者连接到当前存在的各种数据源。

最后，本章还描述了如何高效配置从传入请求到内部表示的连接，以应对常见场景。

2.2 VSS: 通用车辆数据模型

在这里插入图片描述

图2.1: VSS数据模型结构示例

车辆数据模型定义了通过Automotive API访问的数据的语法和语义。该模型需要是通用的，以允许跨车辆和制造商与Automotive API进行统一交互，而不依赖于数据的内部表示。Vehicle Signal Specification (VSS)被选为通用车辆数据模型。VSS是由COVESA（Connected Vehicle Systems Alliance）发起的项目，基于MPL-2.0许可。它定义了一种用于以结构化方式描述单个信号的语法。使用这种语法，在VSS中创建了标准化的信号目录。这个VSS标准目录被用作Automotive API的通用车辆数据模型。通过这种方式，车辆内的数据可以完全独立于供应商和车辆进行描述。只有当它们部署的目录共享一个共同子集时，两个不同车辆的Automotive API才具有互操作性。因此，COVESA定义的标准目录在提供这个共同基础方面发挥着核心作用。

VSS标准目录可以扩展和适应特定于供应商的需求，同时保持其核心与标准兼容。这在需要时提供了灵活性。

VSS目录由一系列定义的信号组成。VSS定义的单个信号是树状结构的叶子，可以通过其限定名唯一标识。

图2.1展示了VSS标准目录中Vehicle.Speed信号的定义。速度叶子具有sensor类型，是Vehicle分支（未显示）的子节点，完全限定名为Vehicle.Speed。可以通过使用VSS提供的附加属性进一步完善信号，例如最小和最大允许值或默认值。VSS还提供了各种受支持的数据类型，包括字符串、数组和结构体。

通过分支中组织的单个信号定义形成的层次树结构，VSS定义了一个广泛的标准目录。它为这些车辆信号提供了跨OEM和车型的通用词汇表。

2.3 VISS: 通信协议

为了便于访问Automotive API，需要网络接口和通信协议。该接口将使用VSS车辆数据模型。为此，选择了Vehicle Information Service Specification版本2 (VISS)。VISS最初由W3C开发，后来转移到COVESA。

VISS允许用户获取、设置和订阅VSS目录中定义的数据。VISS规范分为描述消息API的CORE部分和详细说明WebSocket、HTTP和MQTT协议绑定的TRANSPORT规范。这使得VISS在所需协议方面具有灵活性，并能够将来扩展支持的协议列表。

VISS通过TLS v1.2支持安全通信。这是所有VISS传输的强制性要求。VISS客户端和服务器之间的访问控制是VISS中的另一个强制性要求。访问控制可以通过基于访问令牌的方法提供。作为访问控制的扩展，VISS支持（非规范性地）外部概念框架(ECF)，VISS服务器能够执行同意结果。同意解析委托给ECF。VISS接口上的安全通信和访问控制都是安全、可靠和合法访问Automotive API数据的重要推动因素。Automotive API外部接口的安全性和访问控制如何提供，以及它们如何映射到AUTOSAR车内安全，超出了当前Automotive API标准的范围。

2.4 组件概览

2.4.1 引言

用户可以通过Automotive API Gateway使用VISS协议访问车辆。Gateway又使用ara::com与车辆内部通信，以访问用户请求的底层数据。在Automotive API的第一个版本中，重点是外部客户端。原则上，Automotive API可以同时服务车内和车外客户端。

由于车辆中的数据表示不是标准化的，并且在具体车辆之间可能差异很大，因此无法标准化提供实际数据的源Adaptive应用程序的ara::com接口的细节。相反，需要特定的解决方案。该概念旨在支持简单创建此类解决方案。（见第2.4.4节）

2.4.2 Automotive API Gateway

在这里插入图片描述

图2.2: Automotive API数据映射机制

Automotive API Gateway（以下简称Gateway）使用特定的VSS目录向Automotive API的用户提供VISS接口。为了回答VISS请求，它使用需要在AUTOSAR Adaptive Platform内提供的服务接口。如何访问驻留在AUTOSAR以外系统中的数据并将其连接到Gateway的功能不在本次版本范围内。

Gateway负责实现VISS服务器并将其提供给用户。VISS服务器预计将对请求执行访问控制职责，并提供所有必需的传输协议。尽管VISS服务器支持请求过滤，但ara::com服务接口中没有支持这一功能。

2.4.3 VSS衍生服务接口定义

VSS衍生服务接口是一组使用ARXML描述的、从VSS数据（“服务”）派生的服务接口。Automotive API Gateway提供了一个AUTOSAR兼容的接口，通过VISS提供VSS。实现者必须通过实现生成的Skeletons或在ARXML模型中创建声明性映射来实现提供的服务接口。

VSS衍生服务接口是Automotive API Gateway的稳定内部接口，只要提供的VSS目录没有变化。Gateway使用此接口为VISS请求定义对车辆数据的访问。

从VSS目录到VSS衍生服务接口的转换以可创建生成器的方式进行描述。因此，可以通过四个步骤创建完整的Gateway可执行文件：

将VSS目录导入ARXML
在ARXML中配置所需的映射
实现未在ARXML中建模的映射
生成Gateway

通常，每个VSS叶子都表示为Gateway接口的字段和方法。然后，VISS请求映射到字段和方法上的相应操作。

2.4.4 Gateway的服务接口

图2.3: Automotive API Gateway连接VSS数据到车内服务

这部分文档介绍了符合ARXML模型的方法，将Gateway的VSS衍生服务接口连接到已经存在的车辆内部数据。涵盖了一些常见场景。

一般来说，可以假设大多数（如果不是全部）数据已经在车辆内部可用。这意味着已经存在具有OEM专有接口定义的车辆内部服务。它们必须连接到Automotive API Gateway的VSS衍生服务接口。这需要进行映射。由于车辆内部服务接口的定义是专有的，映射也只能是专有解决方案。然而，本概念旨在支持映射工作。这些方法可以混合使用，以便为每个信号选择合适的解决方案。

在车辆中可以部署多个Automotive API Gateway。

2.4.4.1 数据以相同格式存在

如果VSS衍生服务接口定义的字段或方法与现有Adaptive应用程序提供的服务接口定义的字段/方法相同，或者创建了兼容的Adaptive应用程序，那么Gateway可以配置为使用字段/方法的相同定义暴露Rport。然后可以使用简单的PassThroughSwConnector来连接两者。这样，可以轻松访问为Automotive API明确提供的数据或已在车辆内以相同方式存在的数据。目前预计这种情况很少发生。

2.4.4.2 数据以兼容格式存在

数据可能在车辆内以不同格式存在。例如，数据类型或单位可能不完全相同但兼容，或者数据可能具有不同的结构或名称。在这种情况下，可以利用PassThroughSwConnector的转换功能。通过这些功能，预计VSS目录定义的许多信号可以映射到已存在的OEM定义接口。

2.4.4.3 数据以不兼容格式存在

VSS衍生服务接口定义的所需数据可能在当前车辆系统中可用。然而，也预计数据的表示方式差异很大，以至于PassThroughSwConnector的功能不足。要解决这个问题，必须以另一种方式转换数据。例如，可能需要累积、分发、处理、过滤或平滑数据等情况。

由于这可能变得非常复杂，决定在代码中解决这些转换，而不是在ARXML中建模它们。然而，将来可能会根据需求添加更多的建模转换功能。

所需的适配可以在不同位置实现，取决于上下文：

转换可以作为Automotive API Gateway的一部分。为此，VSS衍生服务接口用于生成用于实现所需功能的C++ Skeletons。
所需的转换可以作为当前提供对未转换数据访问的Adaptive应用程序的一部分。该Adaptive应用程序只需在现有或新的服务接口中提供额外的字段/方法即可。
可以创建一个或多个单独的Adaptive应用程序，目的是根据需要转换数据。它们需要所有允许访问原始格式数据的接口，并提供按VSS衍生接口定义的数据接口。

2.4.4.4 数据存在于Classic Platform中

使用AUTOSAR的信号到服务转换功能，可以使Classic Platform环境中存在的数据对Adaptive Platform可用，然后像前面描述的场景一样连接到Gateway。

3. 使用场景

在这里插入图片描述

图3.1: Automotive API主要使用场景概览

本章解释了Automotive API的使用场景。我们可以从多个维度划分这些场景：

客户端类型 - 车内和远程设备（这对Automotive API Gateway的部署位置有进一步影响）
数据提供者/消费者接口类型 - AUTOSAR Adaptive Platform (AP)、AUTOSAR Classic (CP)和非AUTOSAR平台作为数据提供者
部署场景 - 完全车内部署、部分车内部署配合基于云的前端
时间敏感性要求

3.1 远程客户端

在远程客户端场景中，Automotive API Gateway的部署取决于客户端类型：

通过短距离通信技术连接车辆和远程设备

图3.2: 车辆与远程设备通过短距离通信技术连接

车辆和远程设备使用短距离通信技术连接是现今的现实。例如，使用蓝牙连接设备和车辆，或将车辆用作WiFi接入点。从智能设备直接访问车辆（不经过云服务器）可以减少延迟并改善用户体验。Automotive API Gateway提供了对车辆信号的访问，同时隐藏了所有汽车技术的特殊性，使移动应用开发人员更容易利用这种通信技术。

车辆作为联网设备通过云服务提供数据

车辆与智能设备或长距离数据处理器的连接需要基于云的基础设施。在这种情况下，Automotive API Gateway部分部署在车内，向云中的VISS服务器（基于云的Automotive API Gateway前端）提供数据。

3.2 车内客户端

在这种场景中，Automotive API Gateway完全部署在车内。客户端可以是：

Adaptive应用程序
车载E/E网络中的非AUTOSAR系统，如基于Android的信息娱乐系统

现代车辆是复杂的系统，不同的子系统共存，例如Android和基于AUTOSAR的平台。由于固有的不兼容性，连接这些生态系统可能具有挑战性。Automotive API可以被其他子系统用于获得对AUTOSAR子系统的简化统一访问。

3.3 接口数据提供者/消费者组件

可以区分以下接口领域：

ara::com接口
- 现有的车载服务接口通过AUTOSAR Adaptive Platform提供
- 可以利用VSS衍生服务接口
其他接口
- Adaptive Platform和Classic Platform之间的交互需要额外的适配。Adaptive AUTOSAR已经将这种适配定义为Signal2Service转换。
- 自定义接口：这是一个非常通用的用例，通常涉及专有协议，本文档中不详细介绍。
原始数据流接口
- POSIX套接字API
- 直接网络或基于内存的通信

3.4 时间敏感性

VISS作为基于文本的协议，绝非针对时间关键用例优化。即使是VISS协议的一部分的时间戳，目前也不能支持车辆内部原始捕获值的时间，而只能支持VISS网络绑定的捕获时间。使用VISS的任何时间关键用例都应通过基准测试进行验证。

这意味着对于高实时性要求的应用场景，可能需要考虑其他解决方案或确保网络传输性能满足应用需求。

4. 部署场景

图4.1: Automotive API部署场景概览

在任何部署场景中，使Automotive API可用于客户的实际安排，例如希望通过Automotive API与车辆交互的非汽车服务提供商，最终是OEM的任务，本文档不做进一步介绍。例如，客户需要知道如何连接API（例如，Automotive API"接入点"的FQDN，所需凭证等）。网络接口预计将符合VISS传输要求。ISO TR 20077-3可作为适用流程的参考。

4.1 云服务器请求VSS数据

这是一个典型的"IoT场景"，终端用户访问云中的服务，而服务本身需要通过Automotive API公开的特定车辆数据。跨模型范围和OEM标准化的车辆数据访问API为服务提供商提供了规模经济优势，并支持服务生态系统的发展。这适用于汽车服务提供商和非汽车服务提供商。潜在的服务包括用于监控、定制、与车辆交互的售后服务、车队管理、汽车保险和共享出行服务。

尽管Automotive API提供了基于标准的车辆数据接口，服务提供商仍然需要与相关OEM或数据市场运营商建立业务关系和合同，以获得对车辆数据的访问权限。ISO技术规范20077-3"道路车辆 - 扩展车辆(ExVe)方法论 - 第3部分：开发服务的上游流程"尝试正式化流程，以启动和促进服务提供商与OEM之间的沟通。

如何安排终端用户与持有相关数据的车辆应用程序之间的连接各不相同，也将取决于服务提供商与OEM之间的关系。对于某些服务场景，适用ISO扩展车辆框架的Web服务接口[ISO 20078系列标准]，而对于某些其他场景，可能需要更实时的交互。

4.2 车辆中的多个Automotive API Gateway

车辆提供不同类型的数据。数据可以根据预期的客户及其角色、安全关键性、敏感性等分组为数据集。

诊断站需要比数据中心的遥测数据更多关于车内硬件的洞察。Automotive API集成商可以按域、严重性和/或功能集合分离数据，并将其集成到多个不同的Automotive API Gateway中。在这个用例中，Automotive API服务提供商对客户进行身份验证和授权，最终将请求转发到具体的车内端点。VISS代理服务器可以执行额外的过滤，例如，由于业务模型或安全原因，某些客户只能访问有限的VSS分支。另一个好处是减轻了带有Automotive API Gateway的ECU的工作负荷，因为更复杂的授权和身份验证在车外执行。

4.3 车内应用(非AUTOSAR平台)请求VSS数据

当车内应用（如基于Android的信息娱乐系统）需要访问AUTOSAR平台中的数据时，它可以使用Automotive API Gateway作为统一接口。这简化了异构系统间的通信，提供了一致的数据访问方式。

4.4 级联VISS服务器

多个VISS服务器可以级联形成Automotive API Gateway。例如，在汽车服务提供商(ASP)的云中可能有一个服务器，它回答VISS客户端的请求，但实际上会将这些请求转发到实际车辆中的另一个VISS服务器，该服务器持有实际数据。

这种级联部署支持更复杂的数据管理模式，允许在云端和车内分别部署VISS服务器，提高系统的扩展性，并支持更灵活的数据访问控制策略。

5. 总结与展望

Automotive API为车联网生态系统提供了标准化的解决方案，使得车辆数据能够以安全、可靠的方式被内部和外部应用程序访问。通过本文详细介绍的组件、使用场景和部署模式，我们可以看到Automotive API的几个主要优势：

5.1 核心价值

标准化接口：基于VSS数据模型和VISS通信协议，Automotive API提供了跨车型和制造商的标准化接口，降低了开发和集成成本。
灵活的数据映射：支持多种数据格式映射方式（相同格式、兼容格式、不兼容格式和Classic Platform数据），使得现有车辆数据能够灵活地与新接口集成。
支持多种部署场景：可以适应云服务场景、多Gateway部署、车内应用访问和级联服务器部署等不同需求，提供了极大的灵活性。
生态系统促进：通过向非AUTOSAR成员开放接口，促进了更广泛的服务生态系统发展，推动创新和市场发展。