基于Vector的Autosar基础解读
https://www.autosar.org/
https://zhuanlan.zhihu.com/p/473204205
Autosar 基础
对于致力于从事软件开发和质量相关工作的同学，Autosar是绕不过的一个系统，它包括基本工具、方法和思维，对整个软件开发有完整的诠释。Autosar出现的背景也是软件工作量的增大，如下原因：1.电子系统的复杂性不断增长。2. 软件代码量急速上升。3. 生命周期差别：整车的生命周期往往长于ECU的生命周期。4. 嵌入式系统不支持硬件抽象。5. 有限的软件模块化。6. 重用性差：当硬件更换后，软件往往要推到重写。7. 五花八门的硬件平台。
本文将基于Vector的培训材料从几个方面对Autosar做入门级的解读：
1. Autosar简介（introdution）
1.1 SWC软件单元
1.2 BSW分层
1.3 运行环境RTE
2. Autosar方法论(Methodology)
3. Autosar 实时环境（RTE）
3.1 VFB的具体实现
3.2 Runnables的触发
3.3 Sender/Receiver通信
3.4 Server/Client通信
3.5 AUTOSAR的接口定义
4. Autosar 基础软件（BSW）
4.1 通信流
4.2 Mode Manager
4.3 Memory Services
4.4 Diagnostic Services
4.5 Hardware IO
4.6 操作系统OS
5. 基于Vector的Autosar实现
1. Autosar简介
Autosar的作用就是减少重复开发，软件模块可以在不同的车型之间进行复用。如图舒适系统中的座椅调节、灯光控制、座椅加热、空调的调节等模块可以在不同的车型之间进行复用，只需要把这些SWC功能模块分配到不同的系统中进行配置，无需再重新针对单个车型进行代码开发，从而减少了完全重新开发的工作量。
下面以舒适系统的车灯和门控制系统为例，1. 车灯和门联控系统软件的功能组件：左门、右门、门开关；门触点，开关显示，灯光。
2. 整个控制系统逻辑：按下车门开关（左或右）->门控制器（左或右）信号->门触点开关->Dimmer显示车门开启状态->车内灯开启。单按Switch开关->Dimmer显示车门开启状态->车内灯开启。
基于以上的逻辑框图完成Autosar配置，系统的框图如下所示，针对该框图完成右侧的分布式的软件组件。分为Roof ECU和Front ECU, 控制器和开关共同组成SWC模块，该模块可复用，Switch\Dimmer\Light 共同组成Roof ECU模块，其模块也可进行复用。
1.1 SWC软件单元
SWC为最小的软件基本单元
1.Atomic component为最小软件逻辑单元，包括应用层、Sensor传感器/actuator执行端，Application为实现算法端，可以在各个ECU上进行映射复用。Sensor和Actuator与ECU进行绑定，同步为应用层提供IO口变量
2. Composition 为数个SWC的逻辑集合。
3. Door contact 和Dimmer 为两个最小的Appl. Component，两个集合在一起完成Composition Component, 两个共同组成SWC集成模块，该模块可复用，Switch sensor 和 Light Actuator为独立的软件块，依赖ECU使用。
SWC组成之一Port口
Ports口为SWC的组成之一：SWC最小的逻辑单元中Ports口的目的就是打通SWC之间的通信，通信内容分为：数据元素（S/R）与操作方式（C/S）。
SWC的Ports口S/R传输方式：
一个Ports口可以包含多种Data element, DE是数据类型既可以是简单和也可是复杂的。Dimmer(Send)->Light(Receiver), 如Light_Dimm为复杂的数据 , 触发信号为DoorLeft_Open, 输入ECU DoorOpen DE，Dimmer输入Light_Dimmer。
DE必须与信号Siganl进行一一对应。
通信的方式可以是1:N，也可以N:1。
SWC的Ports口C/S传输方式：
通过Operation服务进行传输，其通信方式可以是：1：1或n:1
一个C/S Port口包含多种operations, SWC3中Rte_call_Doors_State()对SWC1\SWC2可以是开或是关的两种 Operations.
SWC组成之二：可运行实（Runnables）
Runnable 包含实际实现的函数，主要为具体的逻辑算法或者操作，Runnables由RTE周期性、或事件触发调用。
SA_Door_left ( )函数接收到数据Door open，对应的为Rte_write_<Port><Data>, Port为指定的I/O口，Data为Door open.
1.2 BSW分层
BSW可抽象分三个层面：服务抽象层、MCAL、ECU抽象层&复杂设备驱动
1. MCU抽象层：使上层软件与微处理器型号无关，包含MCU内部外设的驱动&内存映射的外部设备的驱动。
2. 服务抽象层：提供给应用程序可用的服务，包含诊断\NVM\OS\通信\内存\ECU管理。
3. ECU抽象层：使上层软件与ECU硬件设计无关、包含ECU板上外设驱动、外设和内设的接口
复杂设备驱动：提供复杂传感器和执行器驱动、重要应用模块可之间访问硬件资源，如喷油量控制、胎压监测等
1.3 运行环境RTE
确保SWC和ECU的映射无关，提供通信服务的中间层（ECU内部/间通信）
信号传输过程：Right Door显示Data status(开\关\半锁\全锁等)-> Sensor 检测电流 I （0-200mA）->ECU检测电流转换为电压（0-5V）->MCU 外设->MCU抽象层驱动->ECU抽象层->Right Door DE ->Door Contact Application(SWC)
2. Autosar方法论
Autosar的方法论，可以对比做菜的方式，Autosar对应的动机\工具\数据\集成等。
方法论的全局包括：内容包含System Configuration description 系统配置描述，ECU configuration description ECU配置描述，ECU Extract of system configuration Description ECU目录的系统配置描述。
Autosar方法论概览如下，针对ECU的应用层、底层、通信方式，其中针对SWC完成应用层SW组件描述、针对ECU资源完成描述（仅针对HW）、针对系统完成系统限制描述，随后进行系统的配置描述、ECU配置描述，生产执行ECU代码。基于软件组件描述完成组件合入到ECU中。
SWC软件组件描述：该SWC用到或被用到的Operation和Data, SWC对软件架构和硬件的要求，SWC使用的内存和CPU时间，运行机制和软件接口等。
SYS限制描述：网络拓扑的限制、协议限制、通信矩阵限制，波特率限制，定时限制，ECU的限制要求。
ECU资源描述：Sensor\Actuator传感器、执行器，存储器，处理器，通信外部设备，引脚分配。
系统配置：基于SWC描述、SYS限制描述、ECU资源描述，系统配置编辑将端口数据映射到通信矩阵，将SWC映射到ECU。编辑完成后形成SYS配置描述，提取系统配置点形成不同的ECU。
ECU配置：将Runnable映射到ECU的task里，将ECU配置生成，包括 SWC集成清单，RTE的配置文件，OS操作系统配置文件，底层BSW的配置文件。从而生成ECU集成RTE的配置、OS的配置、BSW的配置、MCAL配置。基于以上形成的ECU配置进行实现，对配置好的文件进行SWC的编译，链接至ECU实现。
SWC开发流程：ECU的Code生成，SWC的描述h文件，生成零件API, 完成API文件，实施零件。零件实施的C文件，对文件进行编译，生产代码.xml文件和编译文件.obj。
3. AUTOSAR 实时环境（RTE）
RTE类似餐厅的服务员，在SWC和BSW之间进行数据通信，在SWC之间进行通信，将整个ASW和BSW运作起来。
3.1 VFB的具体实现
SWC1\SWC2…SWCn通过RTE进行交互。RTE中I/O口配置，Services, 交流的堆栈，OS的操作系统。VFB的通信可以通过CAN\LIN\FlexRay
例如：把runnables对应到OS的tasks中去、通过RTE的事件触发Runnables的运行、生产调用Runnables的task代码、配置OS的一部分（如Task Event, alarms）、实现SWC之间的通信、每个ECU的RTE因SWC的需求而异。
3.2 Runnables的触发
Runnables的触发条件：定时时间（周期型）、数据接收事件（事件型）、异步服务调用返回事件、操作调用事件、数据接收错误事件、数据发送完毕事件、状态切换事件。
RTE是SWC和BSW之间的通信机构，通过VFB实现，其能保证通信数据一致性，并支持简单数据及复杂数据。
3.3 Sender/Receiver通信---ECU之间
Sender/Receiver通信---不使用队列（直接访问）
ECU之间通过RTE进行通信，RTE直接访问数据地址，通信方式可以是1：n, 初始值为默认值，适用于实时性要求高的数据。Rte_Read_<port>_<d>(out) , Rte_Write_<Port>_<d>(in).
在进入Runnable之前RTE为数据建立副本，在Runnable运行结束之后RTE把副本数据拷贝到实际数据地址，在Runnable运行过程中只操作副本，实际数据不会改变，适用于有一致性要求的数据组。
Sender/Receiver通信---使用队列
”event“ 查询接收或等待接收，RTE从队列中读取数据，等待接收有超时处理。
无效数据元素表示Sensor发送的数据无效，针对无效的数据应不能使用队列，属性设为“Invalid Value”：RTE_Invalidate_<p>_<d>()，接收方应对无效值进行处理，处理的方式可以是：回调函数Rte_Feedback_<p>_<d>(), Rte_Read_<p>_<d>()的返回值为RTE_E_INVALID,
也可以通过收到无效值来激活Runnable的运行。
3.4 Server/Client通信
SWC1 ->SWC3通信方式是：n:1, 服务调用：Client调用Sever端操作，Sever端SWC中的操作一般是Runnables, 采用同步/异步调用的方式，Sever端的Runnables没有分配Task中（直接被调用），分配到Task的通过Task调用。
同步方式通过等待Sever端响应（Client在等待过程中停止）。一步方式：Client不会停止运行，Client通过Rte_Result…获得Sever端响应。RTE 可以通过接收到响应来激活Client端的runnable。
3.5 AUTOSAR的接口定义
AUTOSAR定义三种类型的接口：
AUTOSAR接口
标准AUTOSAR接口
标准接口
AUTOSAR接口是通用接口，源自任意SWC的端口。AUTOSAR接口由RTE提供，用于SWC之间或SWC与ECU固件（IoHwAb、复杂设备驱动）之间的接口。例如，SWC可以通过这些接口读取输入值并写入输出值。
标准AUTOSAR接口是由AUTOSAR标准预定义的特殊AUTOSAR接口。SWC使用这些类型的接口访问由服务层的BSW模块（例如ECU状态管理器或诊断事件管理器）提供的AUTOSAR服务。
标准接口是AUTOSAR标准用C语言预定义的API接口，用于连接BSW模块、RTE与操作系统，或RTE与Com模块
4. Autosar 基础软件（BSW）
Autosar BSW概览如下所示
Autosar BSW包括
COM: 信号接口，分析和设置PDU，信号网关
PDU Router:PDU Router在ECU通讯中的作用和网络里的路由器的功能很类似, 可以理解数据包（ Protocol Data Units）,连接通信服务层与ECU抽象层。
CAN-TP: 数据分包传输
Bus Interface: 与硬件无关，定义每种总线特定的功能，收发队列、组帧、管理时间触发总线的调度表
Driver: 硬件相关的操作，如初始化、填充Buffer、实现ISE
Transceiver: 收发器的操作。
4.1 通信流
以CAN报文为例（可以周期型或事件型），发送报文通过ECU进行控制，首先通过COM写入PDU Router, 而后被PDU Router立刻发送或按周期发送，每一个PDU都有一个ID。PDU Router会辨认总线种类，并把PDU发向不同的下级模块。Interface根据不同的通道，把报文写入不同的队列。而Driver根据报文的优先级立刻发送报文。
接收报文的数据流，以中断为例，由Driver发出Rx中断，通过RxIndication, 数据被传递到Interface, 而后传递到PDU Router, 而后传递到COM，如果SWCs使用Data Reception Trigger, 就通知RTE，否则存储在Buffer中，随后被RTE读取。
4.2 Mode Manager
模式管理：ECU的状态机，收集和验证唤醒事件，如钥匙唤醒事件，协调控制器开机启动和关机休眠。通信管理：包含抽象的总线状态机和通信的Startup/shutdown。网络管理：具体的总线状态机，如果ECU需保持工作状态，则周期性发送NM报文。
ECU的Startup 在ECU启动代码中调用ECUM模块，在OS启动前首先进行硬件的初始化，而后启动OS, OS启动后进行另一部分硬件的初始化，而后初始化ComM(初始化通信模块、初始化网络管理)。
4.3 Memory Services
内存服务的目的是抽象内部或者外部存储设备，对内部或外部存储设备采用同样的操作方式，其结构包括NVRAM的管理、内存抽象接口、内存驱动。
将诊断快照写入NVRAM的过程：按照Block-ID写入，写入特定地址，而且在NVRAM管理中不关心存储器类型。访问的权限必须通过NVRAM才可以访问Memory Abstraction.其即可访问到内部储存器也可以访问到外部储存器。访问完后会有回调函数通知Memory抽象层，抽象层再通知NVRAM管理器。
4.4 Diagnostic Services
诊断服务包括：DCM 实现诊断通信协议；DEM 做故障储存，记录诊断事件；FIM 条件的使能SWC层，诊断事件取决于故障储存内容。
检测错误状态并储存故障，如保存快照，错误与事件关联，写相关的非易失性储存器；出现错误后关闭部分功能模块，当出现某些错误后DEM会通知FIM, 一旦出现错误，SWC可以通过以下方式得知，如回调函数，其结果由SWC查询。
4.5 Hardware IO
包括可抽象I/O类的外部硬件设备及无法抽象的传感器/执行器设备，其操作I/O接口信号，有条件的读取输入信号，如信号的消抖。硬件接口还包括硬件驱动，如ADC\DIO\PWM.
DIO驱动对微控制器硬件管脚的访问进行了抽象，还可以对管脚进行分组。ADC驱动对微控制器内部模数转换单元进行初始化和控制。
PWM驱动为微控制器PWM模块提供初始化和控制服务，可生成周期和占空比都可变的脉冲。
4.6 操作系统OS
OSEK主要由四部分组成:操作系统规范(OSEK Operating System,OSEK OS)、通信规范(OSEK Communication , OSEK COM )、网络管理规范( OSEK Net Management, OSEK NM)和OSEK实现语言(OSEK Implementation Language,OIL)。OS
操作系统可以分为4个等级
SC1: 包含标准OSEK OS标准，除此之外还定义了标准的计数器接口和轮询式的调度表
SC2: 为SC1提供了时间保护，SC2同时定义了时间监控
SC3：包含内存保护
SC4：同时包含时间保护和内存保护
5. 基于Vectord的Autosar实现
Vector的解决方案：设计配置工具、仿真测试工具、BSW模块，DaVinci Network Designer进行系统设计和ECU软件设计。
ECU配置
ECU代码生成
============ End
标签：RTE,Autosar,SWC,BSW,通信,解读,ECU,Vector From： https://www.cnblogs.com/lsgxeva/p/16584642.html