标签：RTE Autosar SWC BSW 通信 解读 ECU Vector
基于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 来源： https://www.cnblogs.com/lsgxeva/p/16584642.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。