AP_PlatformDesign

目录

• 1. 背景

• 1.1 传统ECU

• 1.2 新一代ECU

• 1.3 CP,AP Non-Autosar

• 2. AP Autosar Architecture

• 2.1 支持的接口

• 2.2 支持的协议

• 2.2.1 Communication Management

• 2.2.2 diagnostic management

• 2.2.3 安全性feature

• 2.2.4 信息安全feature

• 2.3 Application launch and shutdown

• 2.4 Methodology

• 2.5 manifest

• 2.5.1 应用设计

• 2.5.2 执行Manifest

• 2.5.3 服务Instance Manifest

• 2.5.4 Machine Manifest

1. 背景

1.1 传统ECU

传统的ECU 数量在逐渐增加，功能与控制器深度绑定。主要的模型依赖于整车信号的输入，传感器的数据，进行计算，输出来控制执行机构。功能单一，针对性较强，安全性能要求较高。且可能在整个汽车生命周期不会改变。

1.2 新一代ECU

对于新的汽车ECU功能，传统的ECU 显得有些无力。比如高阶自动驾驶。

软件功能具有高度复杂喝计算资源的要求。必须满足严格的完整性和安全性。需要实现较为复杂的环境感知，行为规划等功能。并且将车辆集成到外部后端和基础设施系统中。    

在软件升级方面，在车辆的生命周期中，由于外部技术的更新，系统的更新改进，软件有多次升级改变的需求。

Classic Platform autosar 满足深度实时性ECU 的需求下，无法满足对高性能新功能。这里实际需求驱动的技术的进步。Autosar的第二个软件平台AP Autosar 诞生了。

AP autosar 主要提供高性能的计算和通信机制，并且提供灵活的软件配置，例如支持无限软件更新等。

1.3 CP,AP Non-Autosar

后面的车辆软件，控制器，从硬件的角度可能会走向大一统。但是软件设计，具体功能的角度，还是会多种理念共同协作。AP， CP 以及传统嵌入式相互 合作的关系。    

针对CP 与 AP 是如何合作，相互交互的关系 是什么样的。根据CP 的特点，高实时性，稳定性，可靠性的优点。对于传感器的接入，最小系统的实现，基本功能安全的保证，可以有一下的关系。

从这里可以看出来，C (Classic Autosar) 主要还是对传感器的一个抽象，驱动，获取。从上图可以分为

•基础通讯设施

•智能传感器

•位置信息传感器

C2C： 车车无线通信系统

C2I： 车路无线通信系统

车车无线通信系统（C2C）

一个车载无线通信单元（OBU）的C2C通信层结构如图1所示。C2C通信与传统无线通信技术的主要区别在于它的802.11p。传统无线局域网技术是基于IEEE 802.11a/b/g和其它无线电技术，如GPRS或UMTS等[5]。在特殊无线技术MAC和PHY层上，网络层基于地理位置和路径提供无线多跳通信，完成车辆间的特别通信功能，如塞车控制和分流车辆。最终，分散的MAC层可能合并，C2C网络也可以接入到其他无线网络中[6-7]。    

从OBU的C2C通信层结构可见，非安全类应用使用的是传统协议栈。它使用的是IPv6上的TCP和UDP或二者其一，并且可以接入无线多跳通信网络，与其它车内、路边单元或国际互联网节点通信。非安全类应用也能够跳过C2C通信网络层，通过IEEE 802.11a/b/g网络接口传输数据，例如与WiFi热点区域的直接通信。相对非安全类应用，安全类应用按照规则通过C2C通信传输和网络层通信，也可以通过IEEE 802.11p物理层和作为IEEE 1609系列标准的IEEE 1609.4 MAC扩展层的协议栈通信[8-9]。

车路无线通信系统（C2I）

路边设施一般由一些功能模块组成，包括道路设施的信息获取敏感器件。装载在车辆上的敏感系统，可以获取车辆的状况、速度等相关信息，同时负责与路边设施进行数据交换;还包括报警部件、数据处理、融合单元和当地动态地理信息系统等[10-11]。

C2I通信的车载系统

车载单元是一个短距离无线收发系统，可以嵌入在汽车里或者作为一种便携系统安装在汽车上。车载单元能提供车辆与路边设施的通信或车辆间的通信，类似802.11无线收发机[13]。车载单元加上应用处理系统、人机交互界面、GPS车辆定位系统等构成车载应用系统。车载系统（OBE）的结构示意如图6所示。

车载系统包括车载单元的无线电接收装置。它用于连接车内的电子设备。车载单元不仅要由不同的制造商设定，而且不同的车型、不同的生产日期均有特有标记。任何希望连接到车辆间或车辆与路上设施的通信系统，首先要符合通信系统的体系结构，且均需通过简单网络管理协议（Simple Network Management Protocol）注册，并在管理信息中心（Management Information Base）的服务供应商平台（Provider Service Table）中存储使用者的相关信息[14]。车载系统负责获取GPS以及各种车辆传感器数据，当多个车辆要安全地通过一个交叉路口时，最低的数据传输响应时间不超过100 ms。数据至少包括一个临时的ID、信息种类、时间标记、地点等约定信息。数据传送的时间根据车辆的速度，行驶的区域等多种状态自行调整，如根据路边设施数据、导航辅助系统等[15]。

基于车车无线通信系统（C2C）和车路无线通信系统（C2I）的智能交通系统，可以有效降低交通事故发生率，从源头上控制交通安全隐患，这对于提升交通管理的实效性具有积极作用。因此，在后续发展中，有必要加强对智能交通系统的重视，将更多新兴技术应用于智能交通系统中，不断完善和创新系统功能。    

2. AP Autosar Architecture

ARA : Autosar Runtime for Adaptive applications

2.1 支持的接口

在AP 架构中，可以说所有的Application都是运行（需要）在 ARA 之上。ARA 提供了很多接口。这些接口来自于以下

•原生 POSIX 以及 C++ 接口，和操作系统绑定。可以说是通过AP 标准接口实现的功能，一般来说通过POSIX 的接口也可以实现。

•Functional Clusters

•Adaptive Platform Services

•Standard Application/interface

•Vehicle Services

这些接口来自于AP 定义好的标准功能接口。

2.2 支持的协议

2.2.1 Communication Management

对于通讯的不同要求，有着不同的通讯协议。面对服务，面对数据，对时间性能的要求等等衍生出不同的通讯协议。

•SOME/IP

SOME/IP全称Scalable service-Oriented Middleware over IP是目前汽车行业实现SOA架构最核心的通信协议。SOME/IP协议以服务为单位管理整车信息服务可以包含各种可调用方法Method和事件通知组EventGroup通过Service Interface将信息进行传递共享按需分配服务。SOME/IP位于OSI七层模型的5-7层需要运行于TCP/IP协议栈之上即所有的SOME/IP报文都是IP报文都是TCP/UDP报文。    

•DDS

DDS（Data Distribution Service）是一套通信协议和 API 标准；它提供了以数据为中心的连接服务，基于发布者-订阅者模型。这是一套中间件，它提供介于操作系统和应用程序之间的功能，使得组件之间可以互相通信。并且提供了低延迟，高可靠的通信以及可扩展的架构。    

从汽车软件的角度对比一下SOMEIP 与 DDS

•S2S signal 2 service

 S2S的功能模块有以下几种部署方式：

–部署在网关，所有的Signal to Service转换都在网关执行（基于CP）

–部署在（例如）分布在汽车前后左右的四个区域控制器中，区域控制器会连接CAN, LIN节点（基于CP）

–部署在使用了服务的ECU中，各自转换各自需要的Signal/Service（基于CP or AP）

S2S 有点类似于CP 中 跨核调用service的感觉。 把跨核的 服务调用 通过 SR 接口 来实现CS 接口的方式。

•zero-copy IPC    

2.2.2 diagnostic management

•DoIp diagnostic over IP 13400-2

•UDP unified diagnostic services 14229 -1

•SOVD Service Oriented Vehicle Diagnostic

2.2.3 安全性feature

2.2.4 信息安全feature

2.3 Application launch and shutdown

应用程序的整个生命周期都是被EM (Execution Management) 模块管控的。应用程序的加载 启动都属与EM 的一个功能，前期的系统部署配置。

事实上所有的FC 里面的application 从EM 的角度，都是被EM 管控的，除了EM 自身。当然在AP Autosar中有不同种类的application 如下图。

注意 application在什么时候，什么条件下启动，终止不是由EM 决定的。EM 是execution. 决定的是一个FC 里面特殊的Application， 叫做SM(state management)。 状态管理。通过系统设计抽象出不同的状态，来根据不同的状态控制EM。 EM 在来执行对应的application 的运行状态。这个SM 模块应该只调用ARA 的接口，这样才能保证在AP 协议栈下的可移植性。    

2.4 Methodology

对于应用程序的部署分布，独立以及依赖关系，敏捷开发流程等需要一套标准的方法方法，autosar AP 平台提出了一种方法论。

涉及到工作产品的标准化。

描述工作内容本身。如服务，应用程序，machine, 以及他们的configurations.

通过系统描述座位出发点，最终落实到具体的machine.

从系统的设计角度来说，我们需要一个服务，例如这个服务是车灯亮度调节。具体的调节内部的逻辑这里不需要配置，只需要在具体生成的代码框架里面去实现。所以在系统设计的阶段只需要定义该服务的interface.

有了接口就可以通过开发工具进行配置，生成代码框架，也就是这个服务的main 函数已经获得了。

但是从SOA 的角度来说，我们还需要进行服务本身的配置，服务部署等。这里就需要对开发平台进行配置，具体这个服务部署到哪个machine 上面。这里就衍生出了Machine 的manifest. 配置完成之后 这里有个服务本身的代码，和对应的machine 框架下面服务的代码。进行集成。    

然后与其他的ARA 进行配合，实际就是前面起到的任何的application 都需要被execute management 来管理。这里就需要把该application 配置到EM 里面进行部署。

基础的框架完成之后。实现内部的逻辑就可以使用前面提到的 接口。

2.5 manifest

Manifest代表一段AUTOSAR模型描述，该描述是为了支持AUTOSAR AP产品的配置而创建的，并且会上载到AUTOSAR AP产品中，并可能与其他包含Manifest文件的可执行代码的工件（如二进制文件）结合使用。

Manifest的使用仅限于AUTOSAR AP。但是，并不是说在针对AUTOSAR AP的开发项目中生成的所有ARXML都会自动被视为清单。

一辆典型的汽车很可能还配备了许多在AUTOSAR CP上开发的ECU，因此，整个汽车的系统设计必须同时涵盖两个方面——在AUTOSAR CP上构建的ECU和在AUTOSAR AP上创建的ECU。

在应用程序设计时，有必要将术语Manifest的定义细分为三个不同的分区：

应用设计 这种描述指定了所有与设计相关的方面，这些方面适用于为AUTOSAR AP创建应用程序软件。不一定需要将其部署到自适应平台Machine，但是应用程序设计有助于在执行Manifest和服务 Instance Manifest中定义应用程序软件的部署。

执行Manifest 这种Manifest用于指定在AUTOSAR AP上运行的应用程序的与部署相关的信息。执行Manifest与实际的可执行代码捆绑在一起，以支持将可执行代码集成到计算机上。

服务Instance Manifest 此类Manifest用于根据基础传输协议的要求指定如何配置面向服务的通信。服务Instance Manifes与实际的可执行代码捆绑在一起，该可执行代码实现了面向服务的通信的相应用法。

Machine Manifest 这种Manifest应该描述与部署相关的内容，这些内容仅适用于运行AUTOSAR AP的基础计算机（即，该计算机上没有运行任何应用程序）的配置。Machine Manifest与用于建立AUTOSAR AP实例的软件捆绑在一起。    

不同种类的Manifest的定义（和用法）之间的时间划分得出这样的结论：在大多数情况下，将使用不同的物理文件来存储这三种Manifest的内容。

除了应用程序设计和不同种类的Manifest外，AUTOSAR方法论还支持系统设计，它有可能在一个单一模型中描述将在系统中使用的两个AUTOSAR平台的软件组件。

不同的AUTOSAR平台的软件组件可以以面向服务的方式相互通信。但是也有可能描述信号到服务的映射，以在面向服务的通信与基于信号的通信之间建立桥梁。

2.5.1 应用设计

应用程序设计描述了所有与设计相关的建模，这些建模适用于为AUTOSAR AP创建应用程序软件。应用程序设计侧重于以下方面：

1) 用于对软件设计和实现的信息进行分类的数据类型

2) Service Interface是面向服务的通信的关键要素

3) 定义应用程序如何访问面向服务的通信

4) Persistency接口是访问持久性数据和文件的关键要素

5) 定义应用程序如何访问持久性存储

6) 定义应用程序如何访问文件

7) 定义应用程序如何访问加密软件

8) 定义应用程序如何访问平台运行状况管理

9) 定义应用程序如何访问Time Base

10) 序列化属性，用于定义如何序列化数据以在网络上传输的特征

11) REST Service Interface是通过REST模式与Web服务进行通信的关键要素

12) Client 和Server 功能的描述

13) 对应用程序进行分组，以简化软件的部署。

在应用程序设计中定义的工件独立于应用程序软件的特定部署，因此可以简化针对不同部署场景的应用程序实现的重用。    

2.5.2 执行Manifest

执行Manifest的目的是提供将应用程序实际部署到AUTOSAR AP所需的信息。

总体思路是保持应用程序软件代码与部署方案尽可能独立，以增加应用程序软件可以在不同部署方案中重用的几率。

通过执行Manifest，可以控制应用程序的实例化，因此可以：

1) 在同一台计算机上多次实例化同一应用程序软件，或者

2) 将应用程序软件部署到多台计算机上，并在每台计算机上实例化应用程序软件。

执行Manifest集中于以下方面：

1) 启动配置，定义应如何启动应用程序实例。启动包括启动选项和访问角色的定义。每次启动可能取决于Machine状态和/或Function Groups状态。

2) 资源管理，尤其是资源组分配。

2.5.3 服务Instance Manifest

在网络上实现面向服务的通信需要特定于所使用的通信技术（例如SOME / IP）的配置。由于通信基础结构在服务的提供者和请求者上的行为相同，因此服务的实现必须在双方上都兼容。

服务Instance Manifest集中于以下方面：

1) Service Interface部署，用于定义如何在特定的通信技术上表示服务。

2) Service Instance 部署，以为特定的提供和所需的服务实例定义通信技术所需的凭据。

3) E2E保护的配置

4) Safety保护的配置

5) 日志和跟踪的配置

2.5.4 Machine Manifest

Machine Manifest允许配置运行在特定硬件（机器）上的实际自适应平台实例。

Machine Manifest 集中于以下方面：

1) 配置网络连接并定义网络技术的基本凭据（例如，对于以太网，这涉及设置静态IP地址或定义DHCP）。

2) Service Discovery技术的配置（例如，对于SOME / IP，这涉及要使用的IP端口和IP多播地址的定义）。

3) 使用的Machine状态的定义

4) 使用的Function Group的定义

5) 自适应平台功能集群实现的配置（例如，操作系统提供具有特定权限的OS用户列表）。

6) 加密平台模块的配置

7) 平台健康管理的配置

8) 时间同步的配置

9) 可用硬件资源的文档（例如，可用的RAM数量；可用的处理器核数量）    

原文始发于微信公众号（汽车与基础软件）：AP_PlatformDesign