AutoSar架构学习笔记

1.AUTOSAR（Automotive Open System Architecture，汽车开放系统架构）是一个针对汽车行业的软件架构标准，旨在提升汽车电子系统的模块化、可扩展性、可重用性和互操作性。AUTOSAR的目标是为汽车电子控制单元（ECU）之间的软件开发提供统一的标准，以支持多种不同的硬件平台和操作系统，并促进供应商间的兼容性。

2.AUTOSAR Classic Platform架构如下图所示：

SWC（Application Software Components, 应用软件组件）：这些是ECU上运行的实际应用程序，执行车辆功能的核心任务。例如，发动机控制、车辆安全、空调控制等。应用层组件与硬件和其他软件组件之间通过接口进行通信，通常通过AUTOSAR定义的标准接口。
RTE（Runtime Environment，运行时环境）：RTE是AUTOSAR架构的核心部分，它是软件组件与基础软件层之间的中间件。RTE负责连接不同的应用软件组件，提供统一的通信机制，确保不同软件模块间的互操作性。RTE的作用是将应用软件与底层的硬件和服务隔离开，使得应用软件不依赖于具体的硬件平台和操作系统，增强了软件的可移植性。
BSW（Basic Software Layer，基础软件层）：该层主要是为应用层提供基础服务，具体又可分为以下几层：

Microcontroller Abstraction Layer（微控制器抽象层，MCAL）：该层是对MCU芯片的抽象和封装，由于Autosar CP是基于MCU的软件架构，所以该层主要是实现MCU外设驱动)比如I/O驱动、Flash驱动、CAN驱动、看门狗驱动、定时器驱动等等。这一层是需要和硬件打交道的，这一层高度依赖MCU硬件，如果项目换MCU芯片，只需要修改这一层代码适配驱动即可。
ECU Abstraction Layer（ECU抽象层）：该层是对ECU的抽象和封装，ECU上面除了主芯片MCU，还有很多外围设备，比如外置Flash，外置电源管理芯等。这一层就是实现了整个ECU所有设备的封装。外围设备也是MCU主芯片控制的，这一层会使用到MCAL的接口。作为抽象层，屏蔽了下层驱动实现细节，将统一接口API暴露给上层以实现功能。该层从上层抽象MCAL层，并提供用于访问外部和内部的驱动程序的API。
Services Layer（服务层）：该层是向应用层提供服务的，这一将底层提供的服务封装起来供应用层使用。比如通信服务、存储服务、os 操作系统服务等。
Complex Device Drivers（复杂驱动，CDD）：指的是有些模块不适用于Autosar协议栈，通过手写代码自己封装成CDD模块，在项目开发中会经常有一些模块直接作为CDD使用。

3.AUTOSAR Adaptive Platform是面向服务的架构，如下图所示：

4.汽车电子开发流程：下图是标准AUTOSAR流程，OEM从需求生成最终的文件(给到每一个ECU制造厂商)的主要流程。图中流程需要软件工具支持(比如Vector的PREEvision)，这样就能自动生成相应的描述文件了。图中绿色箭头的含义是：设计之初，需要反复修改，首先是列需求，通过三种文件描述这些需求：SWC描述文件、系统描述文件、ECU资源文件，然后将这三种文件导入到系统配置编辑工具中，生成系统配置描述文件。该文件就是整车描述文件最后将系统配置描述文件导入到系统配置提取工具中，导出每一个ECU相应的提取文件，该文件就包含每一个ECU需要用到的信息，比如通信矩阵、SWC信息。

上图中各个具体文件的作用是：

SWC描述文件：即应用层软件组件描述文件，包含的信息有：描述每个软件组件需要的资源（比如存储、CPU时间等），SWC直接的接口，运行机制
系统约束描述文件：主要是对整车公共资源的描述，包括网络拓扑、通信矩阵、总线波特率、各种协议等
ECU资源描述文件：描述每个ECU都需要实现什么功能，系统设计者通过该文件将不同功能的SWC分配到对应的ECU中，例如传感器、执行器、存储器、引脚分配
系统配置描述文件：上面3中文件的汇总
ECU提取文件：将系统配置描述文件信息分配给单个ECU，是单个ECU获取属于自己的信息

当供应商获取到OEM厂商提供的单个ECU的配置文件之后，可以进行具体的ECU软件开发，流程如下：

EB用来配置Mcal驱动，生成arxml导入到DavinciConfigurator（用来配置操作系统和协议栈）中生成代码。
Davinci Developer是用来配置App层框架的（对应AUTOSAR Classic Platform架构中的RTE部分），然后导入到Davinci Configurator中生成代码。
Davinci Developer生成的arxml还会给一份到应用工程师（导入到MATLAB）然后通过MATLAB自动生成软件框架，应用工程在里面添加模型代码即可。
做EB、DaVinci Developer、DaVinci Configrator和Simulink工程师可以同步开发，最终集成一下即可。
开发可以从上到下也可以从下到上，就是说可以在Developer中设计好AppL框架导入到Matlab做代码填充，也可以在Matlab中直接搭建好符合AutoSAR规范的代码，然后导出arxml，再导入到Developer中，也能自动生成框架

静态代码：不会改变的源码。动态代码：配置工具配置出来的代码xx_cfg.c、xx_cfg.h。

5.CAN通信：

从图中可以看出，CAN总线通信需要CPU、CAN控制器、CAN收发器参与。从CAN收发器引出两根线CAN_H_CAN_L，所有节点都挂接到这两根线上，就形成了CAN的网络结构。图中有两路CAN总线，带有终端电阻120欧的是高速CAN，没有带终端120欧的是低速容错CAN。

6.高速CAN总线的总线设计如图所示，仅支持总线型拓扑结构，当前汽车领域用的最多的是CAN控制器集成到MCU中，使用外置CAN收发器，也就是图中右边这种设计：

CAN总线信号由CAN_H_CAN_L两根线的差分信号，也就是通过CAN_H和CAN_L的电压差来决定0、1信号。总线规定隐性电平为信号1（即CAN不工作时），显性电平为信号0（即CAN工作时），其中隐形电平的时候CAN_H和CAN_L都为2.5V，此时电压差就是0V，而显性电平的时候CAN_H为3.5V， CAN_L为1.5V，此时电压差就是2V。高速CAN，总线长度最大为40m，也就是当总线长度超过40m之后，总线的速率会受到影响，支线长度(节点和总线之间的距离)最长为0.3米，节点距离长度最大也是40m。

7.低速CAN：低速容错CAN总线信号也是由CAN_H和CAN_L两根线的差分信号，也就是通过CAN_H和CAN_L的电压差来决定0、1信号。总线规定隐形电平为信号1显性电平为信号0。其中隐形电平的时候CAN_H为0V，CAN_L为5V，此时电压差就是-5V，显性电平的时候CAN_H为3.50V，CAN_L为1.5V，此时电压差就是2V。低俗容错CAN除了支持总线型还支持星型。

8.相关概念：

ECU（Electronic Control Unit）：是电子控制单元的缩写，它是现代汽车、工业自动化、航空航天等领域中广泛使用的电子设备。ECU 主要用于控制和管理车辆或设备的各种电子系统，通过接收来自传感器的信号并执行相应的控制操作来提高设备的性能、可靠性和安全性。
OTA（Over-the-Air）：是一种无线远程更新技术，主要用于通过无线网络（如Wi-Fi、蜂窝网络、蓝牙等）远程向设备推送软件、固件或配置更新。OTA 更新通常用于智能手机、汽车、物联网设备、嵌入式系统等领域，以便无需物理接触或连接外部设备的情况下，远程升级、修复漏洞、优化性能或增加新功能。
OEM（Original Equipment Manufacturer）：指的是“原始设备制造商”，即生产原始设备的公司，它设计并制造产品或组件，并将其作为品牌产品的一部分提供给其他公司进行销售。OEM 通常指的是一个制造商生产的产品或部件，最终由另一家公司销售并以其品牌名推出市场。
BswM：管理整个BSW的模块
EcuM：管理ECU上下电等功能。