基于案例解析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/ProxySkeleton/Proxy是在CM （Communication Management）选择的基本设计模式。这是软件设计模式里最常用的设计模式之一。AP基本上参考了GENIVI的CommonAPI设计。原因很简单，都是由BMW主导。做个和比较常见的Publisher/Subscriber模式比较：PublisherSkeleton提供服务SubscriberProxy请求（或消费）服务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 MachineService Instance可以理解为还在应用的层面，这步将会把一个服务实例映射到目标硬件层面。下表可以看出，ServiceInstance列以前属于应用层面，而Connector和TCP/UDP端口都属于目标硬件层面。
建模总结下图能比较直观的展示应用配置，目标硬件配置，服务实例配置的对应关系。