【原】基于案例解析AP AUTOSAR开发流程

AP最重要的是给产业链带来了标准化。这个标准化包含应用接口标准化和AP平台本身标准化。

对于AP平台使用方（OEM，Tier-1）来讲：

1、 开发应用可以标准化，允许应用快速移植到不同的AP平台，减少重复开发。

2、 因为AP标准对平台本身有要求，安全要求，架构要求等等，那么平台使用方在采购时不用重复在RFQ里定制需求，可以直接引用标准里的要求。

对于比如在自动驾驶领域，拥有核心算法公司只需要将算法做成AP应用，提供给Tier-1/OEM做集成就可以。

AP标准里定义了所有系统中间件，面向应用的接口。哪些中间件你可以参考autosar主页AP部分。都可以免费下载。网上也有很多对标准的中文翻译。AP标准每年更新2次。

跟CP不同的是，AP不会标准化系统中间件之间的交互。那么，哪个公司号称自己开发了一部分AP中间件，应该是不可信的。因为，

1、AP平台供应商不会开发中间件之间的内部接口, 自己开发的AP中间件甚至无法和AP平台供应商的中间件集成。

2、即使能够集成，那针对不同的AP供应商，自己开发的中间件需要重新适配。效率太低。

我认为使用AP只有下列几种情况：

1, 使用一个AP供应商的工具链和AP平台，包括所有系统中间件。

2, 采用了一部分AP中间件，比如ara::com (通讯管理）和Execution Manager（ EM，进程管理）。其他部分没有使用AP组件。

下面通过一个实际的应用案例，从AP AUTOSAR的整体使用流程进行简单的介绍，重点介绍了AP AUTOSAR建模。同时，读者将理解AP AUTOSAR的几个基本平台组件。

01

开发流程

AP AUTOSAR整体开发流程

AP AUTOSAR的开发流程(如上图所示)：

1、定义服务：输出所需的ServiceInterface, 这属于OEM工作范围。

2、基于AUTOSAR供应商(Vector、ETAS等)的工具链，生成基于Skeleton/Proxy 的Class。

3、实现SWC和使用目标软件平台工具链编译为可执行文件。

4、基于AUTOSAR工具链生成Machine Manifest，描述目标硬件和软件平台环境，并将应用映射到进程。

02

案例分析

1、服务定义

将车辆功能拆解为服务的部分暂不展开，个人认为其跟业务逻辑强相关，跟IT域的方法论没什么太大区别。

一个服务接口需满足SOME/IP的组成，里面包含3部分：Fields，Events，Methods。SOME/IP的详细技术细节请戳(SOME/IP协议-科普帖、深入浅出理解SOME/IP)。

首先假设一个服务接口为RadarFusion，如下图所示。

对于一个SOA服务接口，肯定至少得有一个Provider和至少一个Consumer。

基于AP工具生成Skeleton/Proxy

Skeleton/Proxy是在CM （Communication Management）选择的基本设计模式。这是软件设计模式里最常用的设计模式之一。AP基本上参考了GENIVI的CommonAPI设计。原因很简单，都是由BMW主导。

做个和比较常见的Publisher/Subscriber模式比较：

Publisher	Skeleton	提供服务
Subscriber	Proxy	请求（或消费）服务

Skeleton/Proxy的代码由AUTOSAR工具链自动生成，跟应用相关的主要是一个头文件，如下图所示。

SWC定义和实现

在本案例中，两个SWC分别对应一个可执行文件。

服务接口为ap/radar。

RadarService提供输出接口radar_PPort， Fusion提供输入接口radar_RPort。

接下来，怎么去实现RadarService和Fusion两个SWC。

几个关键点需要注意：

• SWC里只允许使用POSIX PSE51接口。

• SWC一般用C++14代码规范。注意遵循AUTOSAR标准文档Guidelines for the use of the C++14 language in critical and safety-related systems。

• SWC与其他SWC或者平台模块只能通过CM接口。

注解：

• 标准里没有文件系统接口，只有Persistency平台模块。所以严格来讲，直接访问文件系统是不允许的。

• 和CP不同，对通常的外围定义了标准接口。而AP没有定义访问外围的BSP接口。严格来讲，AP需要把外围的访问抽象为服务。

功能安全：

值得注意的是，如果一个SWC是ASIL，其所依赖的POSIX PSE51库也必须是通过ASIL认证。一般来讲，这是由OS供应商提供。另外，一部分C++14的标准库也必须通过ASIL认证。这部分一般由编译器供应商提供。

定义目标硬件平台Machine Manifest

对应于流程里步骤3。用于定义目标环境。

从外看，我们可以把机器看做一个抽象的硬件+软件平台和通讯接口。硬件包括一个N核CPU。软件平台可以定义为具体OS。通讯接口如上图，可以有一个以太网接口连接在一个以太网上。

1、定义机器状态

比如，我们有如下7种状态定义：

    "name": "Driving"

    "name": "Leaving"

    "name": "Off"

    "name": "Parking"

    "name": "Restart"

    "name": "Shutdown"

    "name": "Startup"

目的是：每一种机器状态里，可能会激活不同的应用。

2、网络配置

在我们这个RadarFusion案例里，我们假定最简单情况：一个Provider和一个Consumer。

在这里案例里，他们分别部署在不同的ECU上，通过以太网通讯。

首先配置服务发现（Service Discovery，SD）用来交换SD消息。一般是一个multicast地址和UDP端口。

然后是两个应用本身的网络配置：

应用配置Application Manifest

应用除了代码本身外，还包含应用配置。

这个案例比较简单，每个应用只有一个进程。每个进程对应自己的可执行文件。

3、定义应用到进程的映射

如上图所示，一个Machine可以有N个进程。每个进程都会对应可执行文件。

ServiceInstance定义

这里主要定义SOA通讯怎么映射和部署到transport传输层协议，比如SOME/IP。

1、服务接口部署

这里定义对于一个接口的SOME/IP Service ID, 每个Method ID，Event ID。应该非常清晰。

2、服务实例Service Instance 部署

定义一个服务实例是提供方还是消费方。

3、从服务实例映射到目标硬件Mapping from ServiceInstance to Machine

Service Instance可以理解为还在应用的层面，这步将会把一个服务实例映射到目标硬件层面。

下表可以看出，ServiceInstance列以前属于应用层面，而Connector和TCP/UDP端口都属于目标硬件层面。

建模总结

下图能比较直观的展示应用配置，目标硬件配置，服务实例配置的对应关系。

---