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

前言：

本文通过一个应用案例，将整体使用AP AUTOSAR的流程简单介绍。同时，读者将理解AP AUTOSAR的几个基本平台组件。基于这个案例，读者可以了解最基础的AP AUTOSAR开发流程。其中，重点介绍了AP AUTOSAR建模。

1

开发流程

AP AUTOSAR整体开发流程

AP AUTOSAR开发流程：

• 定义服务：输出ServiceInterface, 属于OEM工作范围。
• 生成基于Skeleton/Proxy 的Class。使用AUTOSAR供应商工具链。
• 实现SWC和使用目标软件平台工具链编译为可执行文件 Executables。

• 生成Machine Manifest。描述目标硬件和软件平台环境。将应用映射到进程。使用AUTOSAR工具链。

2

案例：服务定义

将车辆功能拆解为服务的部分在这里就不多讲了。我个人认为这个跟业务逻辑强相关，跟IT域的方法论没什么太大区别。

一个服务接口需满足SOME/IP的组成，里面包含3部分：Fields，Events，Methods。技术细节请参看SOME/IP介绍。

本文假设一个服务接口RadarFusion。

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

3

使用工具链生成Skeleton/Proxy

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

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

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

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

4

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认证。这部分一般由编译器供应商提供。

5

定义目标硬件平台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端口。

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

6

应用配置Application Manifest

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

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

定义应用到进程的映射

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

7

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端口都属于目标硬件层面。

8

建模总结

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