车载基础软件——AUTOSAR CP

大家好，我是穿拖鞋的汉子。
今天是2023.02.04，年岁渐长，越发体会到“时间顺流而下，生活逆水行舟”。
作为弯道超车的国策，汽车行业在转变经济引擎的作用越发明显。鉴于自己的工作内容，想着写一个系列文章，汇总下国内行情。
AUTOSAR CP 是 Classical Platform AUTOSAR 的简称，广泛用于对实时性、安全性要求高的动力域控、底盘域控、车身域控等方面，以达到软硬件解耦、提高开发效率、提升软件复用性等目的。AUTOSAR CP 规范不仅提出了软件分层架构，而且定义了基于该规范的标准开发流程，即开发方法论。下面从如下三个方面进行展开：
1、开发方法论；
2、软件分层架构；
3、工具链。

软解解决方案开发方法论
AUTOSAR CP 为基于该规范的系统开发提供了一个通用的技术方法。它定义了从系统开发到单个ECU 开发的各个阶段，以及在各个阶段需要完成的工作内容、需要提供的成果物。开发一个系统可分解为以下四个阶段。
1、开发抽象系统描述和基于 VFB( 虚拟功能总线，它描述了系统中所有 SWC 之间的交互关系，与ECU 个数和网络拓扑无关）的系统描述，如图 2.1-1 所示。该阶段首先基于功能提出对整个系统的技术要求和约束条件，并且从功能视角设计合理高效的系统架构。其次，工程师在车辆电子电气架构尚未确定之前就开始基于 VFB 进行系统架构设计，将功能视角的系统架构转为 VFB 视角的系统架构。

2、开发系统和子系统，如图 2.1-2 所示。该阶段将整车的电子电气架构作为输入，结合网络拓扑和硬件资源情况将 VFB 视角的 SWC 分配到各个 ECU，并且将 VFB 的接口转换成能够在通信总线上传输的数据，最后生成 System Extract 和 ECU Extract 供 ECU 软件集成时使用。

3、发应用软件和基础软件。在 VFB 视角的系统架构设计完毕后，即可进行原子级 SWC 开发包括实现其内部行为，无需关心具体ECU信息。另一方面，在系统和子系统设计完成后，即可进行基础软件开发。因为基础软件独立于 VFB，所以只要在 ECU 软件集成前完成开发即可。
4、ECU 软件集成。当 ECU Extract、基础软件、原子级 SWC 都开发完成后即可进行 ECU 软件集成。在该阶段工程师定义好 Schedule Table，将 SWC Runnable 分配到 task 中、补充基础软件配置、生成 RTE 后即可编译链接生成可执行文件。
“
总结：该方法论将汽车嵌入式软件开发分为系统架构级、ECU 级和 SWC 级。系统架构级开发可进行整车级别的软件架构设计以及相关功能模块的定义。ECU 级开发则着重开发单片机底层软件。SWC级开发则主要开发具体控制算法。各级开发可以并行，不同的开发之间通过标准化的 ARXML 文件进行交互
”
软件分层架构
在 AUTOSAR CP 分层架构中，自上而下分别为应用软件层（Application Layer）、运行时环境（Runtime Environment）、基础软件层（Basic Software Layer）, 应用软件层包含若干个软件组件，软件组件间通过端口进行交互。每个软件组件可以包含一个或者多个运行实体，运行实体中封装了相关控制算法，其运行可由 RTE 事件触发。
运行时环境作为应用软件层与基础软件层交互的桥梁，为软硬件分离提供了可能，是 VFB 的具体实现。RTE 可以实现软件组件间、基础软件间以及应用软件组件与基础软件之间的通信。RTE 封装了基础软件层的服务、提供了标准化接口，使得应用软件层可以通过 RTE 接口调用基础软件服务。此外 RTE 抽象了ECU 之间的通信，即 RTE 使用标准化接口将 ECU 之间的通信抽象为软件组件之间的通信。基础软件层又可分为四层，包括服务层、ECU 抽象层、微控制器抽象层和复杂驱动。各层又由一系列基础软件组件构成，包括系统服务、存储服务、通信服务等，它们主要用于提供标准化的基础软件服务。

服务层提供了汽车嵌入式系统软件常用的一些服务，包括系统服务、存储服务以及通信服务三大部分。还提供包括网络管理、存储管理、模式管理和实时操作系统等服务。ECU 抽象层与 ECU 平台相关，但与微控制器无关，包括板级硬件抽象、存储硬件抽象、通信硬件抽象和 I/O 硬件抽象。该层将 ECU 结构进行了抽象，负责提供统一的访问接口，实现对通信、存储器或者 I/O 的访问，从而不需要考虑这些资源是由微控制器片内还是片外提供的。微控制器抽象层是实现不同硬件接口统一化的特殊层，包括微控制器驱动、存储驱动、通信驱动以及 I/O 驱动。通过微控制器抽象层可将硬件封装起来，避免上层软件直接对微控制器的寄存器进行操作。最后，由于对复杂传感器和执行器进行操作的模块涉及严格的时序问题，难以抽象，所以在 AUTOSAR CP 规范中没有被标准化，统称为复杂驱动。如上所述，AUTOSAR CP 良好的分层架构为软硬件之间解耦、软件模块之间解耦提供了坚实的保障。
工具链
V 模型是目前汽车电子软件开发过程中采用的主流开发模式，V 模型左侧统称为设计阶段，主要涵盖业务需求分析（Requirement Analysis）、系统设计（System Design）、架构设计（Architectural Design）、模块设计（Module Design）和编码（Coding）五个阶段。V 模型右侧统称为测试阶段，涵盖单元测试（Unit Testing）、集成测试（Integration Testing）、系统测试（System Testing）和验收测试（Acceptance Testing）四个阶段。在 V 模型左侧，当前主流商用工具链可以全面支撑 AUTOSAR CP 开发方法论中提到的系统架构级、ECU 级和 SWC 级开发，

参照 AUTOSAR CP 方法论和开发流程，开发工具主要分为以下四类：
A:系统设计工具。一般由 OEM 使用，主要用于完成软件组件框架（端口、端口接口、数据类型、运行实体、触发事件）的设计及框架代码生成；实现软件组件间通信端口的连接；导入 DBC、LDF 等传统网络描述性文件实现软件组件向 ECU 映射等工作。
B:软件组件设计工具。一般由 Tier1 使用，主要用于软件组件框架的搭建，生成符合 AUTOSAR 规范的代码与软件组件 ARXML 文件。之后将 ARXML 文件导入 Matlab Simulink 后可继续进行控制算法模型开发，开发完成后通过自动代码生成获得的 C 代码将用于 ECU 软件集成。
C:MCAL/BSW 配置及 RTE 代码生成工具。MCAL 配置工具主要用于底层驱动的配置与配置代码生成、BSW 配置工具主要用于基础软件协议栈的配置与配置代码生成，生成后的配置代码需要与工具供应商提供的静态代码一同进行 ECU 软件集成。RTE 代码生成工具以软件组件 ARXML 或基础软件配置ARXML 为输入，生成符合 AUTOSAR CP 标准的 RTE 代码，向软件组件提供可靠的通信和调度服务。
D:编译与调试工具。用于 ECU 软件集成时的编译与调试。由于 AUTOSAR CP 工程代码量十分庞大，所以对编译器和调试器的要求也相对较高。
此外，目前市面上的 AUTOSAR 工具链都是桌面应用程序，这使工具链的维护和升级都不方便，并且由于应用程序在各个电脑上都是独立的，所以其资源是不可共享的，使开发效率降低。而随着 5G 和千兆网络的普及，在未来，AUTOSAR 工具链由桌面应用程序发展为 Web 应用程序成为可能。具有超大带宽、超低时延、更加稳定可靠等特征的宽带网络结合超强性能的 Web 应用程序服务器，以及 Web 应用程序本身的优势，这使得工具链供应商可以更加方便的维护及更新工具，开发者们更加高效、友好的合作开发。