【汽车操作系统】Autosar和商用OS

什么是AUTOSAR?

CP AUTOSAR架构

CAN通信

AP AUTOSAR

背景

CP&AP

开发方面的不同：

WRLinux介绍

QNX介绍

什么是AUTOSAR?

随着汽车功能越来越多，导致ECU的数量越来越多。1993年的时候，奥迪A8才只有5个ECU现在典型的现代汽车上有超过50个ECU，有的车甚至有150个ECU。但是ECU可能是不同的供应商提供的，各厂家的标准、软件架构可能不同，OEM车厂要让这些ECU之间正常通信，是一件复杂和困难的事。供应商软件开发的工作量也很大，版本众多维护起来非常困难。在ECU中添加新功能，或者把ECU-A的功能移植到ECU-B中也不是一件简单的事。

AUTOSAR，全称Automotive Open SystemArchitecture，中文是“汽车开放系统架构”但它首先是一个组织，注意AUTOSAR不能写作AutoSAR，否则Open的含义就没有了，标志也用红色圆圈强调了开放的理念。

2003年，9家公司成立了AUTOSAR。截至2023年11月，已有350多家公司、机构加入，包括汽车制造商、部件供应商、电子和软件公司等。

CP AUTOSAR架构

传统ECU开发就相当于一个人，既要吃饭(软件)又要做饭(硬件)，可能还要洗碗(硬件，释放内存)，效率就比较低。而AUTOSAR像是一个食堂，硬件层就是食堂做菜师傅、锅碗瓢盆和食材，应用层相当于要吃饭的学生，中间的RTE层就相当于打菜的阿姨。学生(软件开发者)不需要关注食材(硬件，数据)是怎么洗净切好，怎么放到锅碗瓢盆(硬件，存储)中做熟，只需要和打菜阿姨(RTE上接口)说一下(通信)要什么菜(数据包)，阿姨就会打给你(提供数据)，如果没有菜了，阿姨就会喊(通过RTE下接口)做菜的师傅(硬件)，判断还有没有菜(提供相关数据)，如果没有就要赶紧做菜(执行某个操作)，或者告诉学生没有菜了(硬件报错，硬件损坏，兼容性问题等）

应用层:AppL或ASWL-ApplicationSoftware Layer，实现具体应用功能一个App包含多个软件组件(SWC，Software Component)。

Service服务层:给应用层提供后台服务，如存储管理、网络管理等。

ECU抽象层:ECUAL-ECUAbstraction Layer，标准化硬件的基础功能和接口，控制网关报文转发、存储器读写等。

硬件抽象层:MCAL-MicrocontrollerAbstraction Layer，硬件相关的驱动软件。

复杂驱动:CDD-ComplexDevice Driver，承接复杂的驱动，接口直接暴露给RTE。

硬件层:也称微控制器层，即控制器的硬件部分

官方CP AUTOSAR架构图

最下层

可以通过配置生成

，无需写代码，减少出现低级错误。

静态配置与代码生成

配置工具与静态代码生成：AUTOSAR工具链允许开发者通过图形化或XML配置文件来定义软件组件、ECU资源、通信接口等，随后自动生成对应的C代码。这确保了软件结构的标准化和代码的一致性，同时使得整个系统的行为在编译前即可被完全预测。

静态内存分配：所有任务、缓冲区、消息队列等所需的内存均在系统启动前静态分配完毕，避免了运行时的动态内存分配，提高了系统的确定性和效率。

任务管理与调度

周期性任务与优先级：每个任务根据其功能重要性和时间约束被赋予固定的执行周期和优先级。RTOS保证高优先级任务能够优先执行，并通过时间触发或事件触发机制确保周期性任务按时执行，如每5ms执行一次的控制循环。

任务栈：为每个任务独立分配栈空间，防止栈溢出导致的系统崩溃，同时确保任务间的数据隔离。

中断管理

CAN硬件中断：通过RTOS，CAN总线的硬件中断被高效地管理，确保数据的实时传输和处理。中断服务例程(ISR)快速响应中断，完成数据读取或发送的初步处理，随后快速返回，减少中断延迟。

CPU管理与抢占：RTOS监控CPU状态，管理任务上下文切换。快速中断（FIQ，Fast Interrupt Request）用于处理需要更快速响应的事件，相比普通中断（IRQ），FIQ享有更高的优先级和更快的处理路径。

核心工作与机制

核心功能：RTOS的核心工作包括但不限于任务调度、中断处理、同步与通信机制（如信号量、互斥锁）、内存管理和错误处理。这些机制共同确保了系统的实时性、稳定性和安全性。

功能隔离与模块化：通过AUTOSAR的分层架构和接口定义，不同的软件组件在逻辑上被隔离，促进模块化开发和测试，同时也便于软件复用和升级。

CAN通信

收集所有的CAN，分析优先级，由PDUR进行筛选，筛选之后发给CAN interface

LIN总线本质是一个串口

AP AUTOSAR

背景

为适应汽车的发展趋势(如辅助驾驶、V2X、OTA、远程诊断、动态部署等)，应对汽车E/E系统开发面临的新的挑战(高性能处理器的应用，实现ADAS，高带宽通信，E架构演变等)，AUTOSAR组织推出了AUTOSARAdaptive Platform(AP)。简单说，AP就是为高性能计算提出的解决方案

AP AUTOSAR架构

部署于linux系统上，本质还是属于中间件。

在Classic中虚拟功能总线VFB为RTE层，在Adaptive中VFB为ARA层，AUTOSARRuntime for Adaptive applications。 ARA层提供通讯管理、执行管理和日志跟踪等功能组件，并给App层提供API接口。AP构建在POSIXOS上，由不同功能模块组成，这些模块属于服务模块Service和基础模块Foundation。模块的通信是面向服务(SOA)的，并使用以太网与其它ECU通信。

AP：发展阶段，大部分都是C++代码，注重运算结果，高性能平台。

CP：应用层面，信号转服务，注重实时性。

CP&AP

开发方面的不同：

Classic Platform	Adaptive Platform
基于C语言面向过程开发	基于C++语言面向对象开发
FOA架构(function-oriented architecture )	SOA架构(service-oriented architecture
基于信号的静态配置通信方式	基于服务的SOA动态通信方式(SOME/IP、DDS)
硬件资源的连接关系局限于线束的连接	硬件资源的连接关系虚拟化，不局限于通信线束的连接关系(互联网)服务可根据应用需求动态加载，可通过配置文件动态加载，并进行单独更新公
静态的服务模块，模块和配置在发布前进行静态编译连接	应用加载到RAM执行
从ROM执行代码	每个应用都有直接的虚拟地址空间(支撑MMU)
基于OSEK操作系统	基于POSIX OS(Linux\QNX...)操作系统