是什么?
AUTOSAR(AUTO motive Open System ARchitecture),中文是“汽车开放系统架构”。
也是一个联盟,致力于制定汽车电子软件标准,他们制定了一套专门用于汽车的开放性的框架和行业标准,它将用作管理将来的应用程序和标准软件模块中功能的基本基础结构。
这是它们官网,感兴趣可以去悄悄~
https://www.autosar.org/
从哪来的?
准确的说,autosar诞生于二十一世纪初,作为汽车发源地的欧洲大地,准确地讲,德国,于2002年8月,有一群车企大佬(宝马、博世、大陆集团、戴姆勒克莱斯勒和大众汽车公司,后来西门子威迪欧也加入了)就共同的挑战和目标进行了讨论,成立一个联盟,制定标准,准备一统江湖。
很快啊,在2003年,他们就将AUTOSAR的“草稿”给整出来了,也就是AUTOSAR Classic Platform的Draft版。
之后,这个联盟如初生的太阳一样不停的发展壮大,吸纳着了无数车企和相关的设备厂商的加入,但却有着一个局限,Classic Platform玩来玩去都是只覆盖了低端的设备,都是基于微处理器的。
大家想一下如果你的手机没有界面,甚至没有终端,芯片和电路板在外面裸露着,是个什么样的状态,当时的autosar就是如此。
上面的更高端的系统和服务是没有滴。
所以在2017年,一个Adaptive Platform就这样诞生了。
是的,没错,AutoSar的历史就是这么短,但大家记住了:AutoSar面向的是未来!目标是星辰大海!
做了什么?
简单来讲,
AUTOSAR定义了三个文档组:Classic Platform(CP)、Adaptive Platform(AP)和Foundation(FO),基于CP和AP的ECU基于共同标准FO实现彼此连接;
AUTOSAR提倡“在标准上合作,在实现上竞争”原则; AUTOSAR核心思想是“统一标准,分散实现、集中配置”,即统一的开放平台、软件系统层次化模块化,降低应用与平台耦合性、统一格式的配置信息,集中配置生成系统; 一个汽车电子应用系统可包含多个相互关联的AUTOSAR组件。组件通过虚拟功能总线(VFB)提供标准通信机制与服务,实现平台无关性;
这些标准区别在哪?
Classic Platform(CP)
AUTOSAR CP 是 Classical Platform AUTOSAR 的简称,广泛用于对实时性、安全性要求高的动力域控、底盘域控、车身域控等方面,以达到软硬件解耦、提高开发效率、提升软件复用性等目的。
AUTOSAR CP 规范不仅提出了软件分层架构,而且定义了基于该规范的标准开发流程,即开发方法论。
下面从开发方法论、软件分层架构、工具链这三方面详细说明。
开发方法论
一、开发抽象系统描述和基于 VFB( 虚拟功能总线,它描述了系统中所有 SWC 之间的交互关系,与ECU 个数和网络拓扑无关)的系统描述。
该阶段首先基于功能提出对整个系统的技术要求和约束条件,并且从功能视角设计合理高效的系统架构。其次,工程师在车辆电子电气架构尚未确定之前就开始基于 VFB 进行系统架构设计,将功能视角的系统架构转为 VFB 视角的系统架构。
二、开发系统和子系统
该阶段将整车的电子电气架构作为输入,结合网络拓扑和硬件资源情况将 VFB 视角的 SWC 分配到各个 ECU,并且将 VFB 的接口转换成能够在通信总线上传输的数据,最后生成 System Extract 和 ECU Extract 供 ECU 软件集成时使用。
三、开发应用软件和基础软件
在 VFB 视角的系统架构设计完毕后,即可进行原子级 SWC 开发包括实现其内部行为,无需关心具体ECU信息。
另一方面,在系统和子系统设计完成后,即可进行基础软件开发。因为基础软件独立于 VFB,所以只要在 ECU 软件集成前完成开发即可。
四、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 规范中没有被标准化,统称为复杂驱动。
工具链
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方法论和开发流程,开发工具主要分为以下四类:
一、系统设计工具。
一般由OEM使用,主要用于完成软件组件框架(端口、端口接口、数据类型、运行实体、触发事件)的设计及框架代码生成;实现软件组件间通信端口的连接;导入DBC、LDF等传统网络描述性文件实现软件组件向ECU映射等工作。
二、软件组件设计工具。
一般由Tier1使用,主要用于软件组件框架的搭建,生成符合AUTOSAR规范的代码与软件组件ARXML文件。之后将ARXML文件导入Matlab Simulink后可继续进行控制算法模型开发,开发完成后通过自动代码生成获得的C代码将用于ECU软件集成。
三、MCAL/BSW配置及RTE代码生成工具。
MCAL配置工具主要用于底层驱动的配置与配置代码生成、BSW配置工具主要用于基础软件协议栈的配置与配置代码生成,生成后的配置代码需要与工具供应商提供的静态代码一同进行ECU软件集成。RTE代码生成工具以软件组件ARXML或基础软件配置ARXML为输入,生成符合AUTOSAR CP标准的RTE代码,向软件组件提供可靠的通信和调度服务。
Adaptive Platform(AP)
今天的汽车 E/E 架构可划分为信息娱乐、底盘和车身控制等不同域,信息娱乐系统通常使用 Linux 或商业化的通用操作系统,车身控制则使用标准的 AUTOSAR CP。随着未来新技术及深度嵌入式系统对计算能力需求的不断增长,急需第三种控制器——域控制器,用于集成特定领域的功能特性(如车辆动力域、车身域等 ),形成域集中或跨域集中式电子电气架构。
在未来,随着汽车电子及软件功能的大幅增长,E/E 架构最终可能向基于中央计算平台的整车集中式电子电气架构,以及车云协同控制发展。在这种趋势下,需要高度灵活、高性能且支持 HPC、动态通信等特性的新软件架构平台——Adaptive Platform AUTOSAR 平台(下文简称 AUTOSAR AP)。