车载基础软件——AUTOSAR AP技术形态

我是穿拖鞋的汉子！
今天是2023年2月11日，时间好快，疫情解封已好几个月，生活节奏也在逐渐恢复到三年前的节奏。可能是感觉疫情与自己距离变远了，大家也开始慢慢的不再恐惧！
老规矩分享一段喜欢的文字，避免自己成为高知识低文化的工科男：
我们都太迷恋结尾！这个世界有那么多伟大的生命和美好的爱可以见证和体验，但只要结果不尽如人意，我们立刻觉得这个是悲剧。或者正好相反，只要结局有一刻的救赎，一生的不公和痛苦都可以忽略不计。他妈的，都是狗屁！

Return to today's topic!
汽车电子行业在新四化：
-> 电动化;
-> 网联化;
-> 智能化;
-> 共享化.
等上述需求变革驱使下，汽车软件系统变得更加灵活。汽车软件既要安全又要可持续更新以反映新的功能特性或法规要求，为此需要新架构支持软件组件的动态部署以及与非车载系统之间的交互。
今天的汽车 E/E 架构可划分为信息娱乐、底盘、自动驾驶域和车身控制等不同域：
-> 信息娱乐系统通常使用 Linux 或商业化的通用操作系统（安卓）；
-> 车身控制则使用标准的 AUTOSAR CP。
随着未来新技术及深度嵌入式系统对计算能力需求的不断增长，急需第三种控制器——域控制器，用于集成特定领域的功能特性（如车辆动力域、车身域等 )，形成域集中或跨域集中式电子电气架构。
在未来，随着汽车电子及软件功能的大幅增长，E/E 架构最终可能向基于中央计算平台的整车集中式电子电气架构，以及车云协同控制发展。在这种趋势下，需要高度灵活、高性能且支持 HPC、动态通信等特性的新软件架构平台——Adaptive Platform AUTOSAR 平台（下文简称 AUTOSAR AP）。


一、软件分层架构
典型的域控软件架构如下图所示，整体可被分为四层，即操作系统层、基础平台层、原子服务层、应用组合服务层。
AUTOSAR AP 在基础平台层，这一层包含了 AUTOSAR AP、AUTOSAR CP、专用基础功能等，主要为整车提供基础运行环境。
原子服务层是实现数据融合和控制逻辑的功能模块，作为服务的最小单位与单一执行实体，通过 API为应用提供可按需编排的基础服务，实现一次开发多次复用，最大化提升开发效率。该层的设计目标是原子服务与平台解耦，提升软件复用性。
应用层基于原子服务实现对整车服务、应用、体验等进行定义和组合增强，构建差异化竞争力的业务应用，体现千车千面。

AUTOSAR AP在域控软件架构中位于中间件的位置，通过服务和API为上层服务提供功能，如图所示。

在 Non-AUTOSAR 环境中，系统已经实现了部分 AUTOSAR AP 标准组件，只需要实现剩余部分组件即可满足 AUTOSAR AP 的标准。比如在 Android Automotive OS 中，软件框架提供了进程管理、执行管理、Log、加密、生命周期管理等功能，基础软件供应商实现通信管理、诊断、升级、网络管理等功能，即可满足 AUTOSAR AP 的标准。

二、工具链
基于自适应平台的应用程序开发一般要经历三个阶段，分别是设计建模阶段、软件开发阶段、集成部署阶段，为了更好地支撑这三个阶段的活动，AP 工具链具备以下能力：
-> 设计建模阶段使用建模工具，用于生成 ARXML，完成 Adaptive Application、Service Instance、Executable、Machine 等设计开发，配置 SWC（Software Component）相关配置项，完成 SWC端口及框架设计 , 最终导出 AP 平台的 ARXML 文件。产品工具应具备支持导入导出、解析、编辑ARXML 文件的能力。
-> 软件开发阶段：使用 AP 产品生成工具，用于实现组件 API 代码及 Manifest 配置文件的生成。输入是标准的 ARXML 文件，生成源代码和 Manifest 配置文件，另外需要包含应用层的代码编辑器和代码库管理，实现源码编辑，编译链文件编写，代码库同步等功能。
-> 集成部署阶段：使用集成编译调试以及部署工具，包含编译工具、可视化调试工具、部署工具、资源监控等工具，支持编译、调试、部署等功能。


三、开发方法论
为了支持 AP 平台下应用程序独立、敏捷、分布式的开发，需要在开发方法论上有一套标准化的方法。AUTOSAR AP 开发方法论涉及工作产品的标准化，用于描述工作产品（如服务、应用程序、机器及其配置）、工作产品应如何交互、以实现自适应平台产品开发过程中不同角色之间所需的信息交换。如下图简要展示了 AP 平台的开发工作流，总体来说需要经历三个阶段七个步骤，最终将开发的软件集成入车辆中。
（1）、架构设计阶段
服务接口设计（Define Services）：主要是定义服务接口及数据类型，包括定义服务所包含的method、event、field、trigger 等通信元素以及数据类型详细说明等；
机器配置设计（Configure Machine）：定义和配置机器的网络通信属性，包含网络连接配置，服务发现配置等信息；
（2）、软件开发阶段
定义与配置可执行实例及通信方式，定义可执行实例如何访问软件集；
定义软件集群所提供的服务实例、配置服务实例和可执行实例的映射；
服务实例接口框架源码生成；软件集群源码开发及测试等；
（3）、集成与部署阶段
软件集群集成 (Integrate Software)：配置可执行实例和进程的映射、定义和配置应用程序配置清单、定义和配置服务实例部署信息；
ECU 集成 (ECU(Machine) Integrate)，定义应用程序执行清单 (Execution Manifest)、定义平台程序的配置清单、诊断和进程之间的映射配置；


四、AP与CP比较
两个软件架构主要有如下区分：
1、架构设计原则不同
CP AUTOSAR架构设计原则为：
1）CP AUTOSAR将于硬件相关的以及通用系统功能定义为BSW模块
2）应用功能定义为独立的软件组件SWC
3）RTE分离SWC和BSW
4）BSW可配置，并且可以被多个产品线的ECU重复使用
5）不开源

AP AUTOSAR架构设计原则为：
1）遵循面向服务的架构SOA设计范式（理念）
2）充分利用其他领域软件成熟技术，重用软件市场成熟组件，缩短开发周期
3）充分利用各种开源软件

2、通信方式
CP AUTOSAR是基于信号的通信，主要包括CAN、Lin、FlexRay等。
AP AUTOSAR是面向服务的通信，支持基于以太网的SOME/IP、IPC、DDS、RPC等。
CP AUTOSAR虽然可以支持SOME/IP，但是CP AUTOSAR中SOME/IP只不过是把Sender-Receiver的CAN通信转换成了Client-Server的以太网通信，整个通信链路仍是静态配置的，并不是真正的面向服务的通信。
这也是为什么AUTOSAR官方说AP AUTOSAR是SOA，但从来不会说CP AUTOSAR是SOA。

3、芯片需求
CP AUTOSAR一般运行在8bit、16bit、32bit的微控制器（MCU）中，如英飞凌的TC3xx，瑞萨的RH850等。
AP AUTOSAR可以运行在64bit的高性能处理器（MPU）、CPU等中，如瑞萨的H3，英伟达的Xavier等。除此之外，AP AUTOSAR也可以运行在虚拟硬件上。
PS：有些公司可能会将某种POSIX OS移植到如TC3xx中，进而在TC3xx中使用AP，这种例子很少见，且不推荐，所以这里不做细究。
运行CP AUTOSAR 的芯片算力一般低于1000 DMIPs
AP AUTOSAR可以运行在算力高于20000 DMIPs的芯片上
这里的算力是指逻辑算力DMIPs，还有另一种TOPS，一般是指AI芯片的指标，一般是指矩阵运算算力。

搁笔打停！
愿你我相信时间的力量，
做一个长期主义者！