AUTOSAR架构简述Word下载.docx
- 文档编号:18343748
- 上传时间:2022-12-15
- 格式:DOCX
- 页数:8
- 大小:1,007.02KB
AUTOSAR架构简述Word下载.docx
《AUTOSAR架构简述Word下载.docx》由会员分享,可在线阅读,更多相关《AUTOSAR架构简述Word下载.docx(8页珍藏版)》请在冰豆网上搜索。
2)为实施应用提供方法论,包括制定无缝的软件架构堆叠流程并将应用软件整合至ECU;
3)制定各种车辆应用接口规范,作为应用软件整合标准,以便软件构件在不同汽车平台复用。
2.分层概述
AUTOSAR体系架构分层标准
1)应用层(ApplicationLayer)
应用层中的功能由各软件组件SWC(softwarecomponent)实现,组件中封装了部分或者全部汽车电子功能,包括对其功能的具体实现以及描述,比如控制汽车大灯、空调等部件的运作,但是与汽车硬件系统没有连接。
1.1)软件组件(softwarecomponent)
软件组件SWC(softwarecomponent)是由Atomiccomponent(最小逻辑单元)组成。
Atomiccomponent最小逻辑单元有Application、Sensor/actuator(传感器/执行器)两种类型。
其中Application是算法实现了类型,能在ECU中自由映射;
Sensor、Actuator是为Application提供的I/O端口类型,用于与ECU绑定,但不可像Application那样能在各ECU上自由映射。
数个SWC的逻辑集合组合成Composition。
SWC组成实类
1.2)端口(ports)
端口Ports是用来和其他SWC通信的。
通信内容分别为Dataelements(数据元)与operations(操作)。
其中,Dataelements用Sender/Receiver通讯方式;
operations用Client/Server通讯方式。
通讯方式
发送-接收端口(Sender/Receiver)用来传输数据,具有一个通信端口可以包含多种数据类型特点。
但如果一个数据类型要通过总线传输,那么它必须与一个信号对应起来,数据类型既可以是简单的数据类型(integer,float),也可以是复杂类型(array,record)。
通信方式:
1:
n或n:
1。
客户端—服务器端口(Client/Server)用来提供Operation服务,具有一个客户端—服务器端口可以包含多种Operation和同步或是异步通信特点,一个客户端—服务器端口可以包含多种Operations操作,Operations操作也可被单个调用。
1.3)可运行实体(Runablesentities)
可运行实体简称Runnables。
可运行实体包含实际实现的函数,可以是具体的逻辑算法或是实际操作。
可运行实体由RTE周期性或是事件触发调用,如当接收到数据。
2)Runtimeenvironment层(RTE)
中间件部分给应用层提供了通信手段,这里的通信是一种广义的通讯,可以理解成接口,应用层与其他软件体的信息交互有两种,第一种是应用层中的不同模块之间的信息交互;
第二种是应用层模块同基础软件之间的信息交互。
而RTE就是这些交互使用的接口的集散地,它汇总了所有需要和软件体外部交互的接口。
从某种意义上来看,设计符合AUTOSAR的系统其实就是设计RTE。
SW-C之间的通信是调用RTEAPI函数而非直接实现的,都在RTE的管理和控制之下。
每个API遵循统一的命名规则且只和软件组件自身的描述有关。
具体通信实现取决于系统设计和配置,都由工具供应商提供的RTEGenerator自动生成的。
在设计开发阶段中,软件组件通信层面引入了一个新的概念,虚拟功能总线VFB(VirtualFunctionalBus)。
它是对AUTOSAR所有通信机制的抽象,利用VFB,开发工程师将软件组件的通信细节抽象,只需要通过AUTOSAR所定义的接口进行描述,即能够实现软件组件与其他组件以及硬件之间的通信,甚至ECU内部或者是与其他ECU之间的数据传输。
从图中可以看到,有三种接口描述,我们先从定义的角度来看这三种接口有什么不同。
2.1)StandardizedInterface(标准接口):
标准接口是在AUTOSAR标准中被标准化的接口,但是并没有使用AUTOSAR接口技术,标准接口通常被用在某个ECU内部的软件模块之间的通讯,不能用于网络通讯。
2.2)StandardizedAUTOSARInterface(标准AUTOSAR接口):
标准AUTOSAR接口是在AUTOSAR标准中使用AUTOSAR接口技术标准化的接口,这样的接口的语法和语义都被规定好了,这样的接口通常使用在AUTOSAR服务中,这样的接口是基础软件服务提供给应用程序的。
2.3)AUTOSARInterface(AUTOSAR接口):
AUTOSAR接口定义了软件模块和BSW模块(仅仅是IO抽象和复杂驱动)之间交互的方式,AUTOSAR接口是以port的形式出现的,AUTOSAR将ECU内部的通讯和网络通讯使用的接口进行了统一。
从上边的定义中我们可以看出不同的接口使用的场景不同,及不同的模块交互会使用到不同的接口。
除了将接口归类以外,这样定义究竟有什么实际的意义呢?
从实际使用的角度来看,第一和第二类接口都是语法语义标准化的接口,即接口函数的数量、函数的名字、函数参数名字及数量、函数的功能、函数的返回值都已经在标准里边定义好了。
不同的公司的软件在实施这些接口的时候虽然内容算法不同,但是它们长相和功能是一致的,接口定义在AUTOSAR规范文档里边是可以查得到的。
第三类接口呢,AUTOSAR仅仅规定了简单的命名规则,这类接口高度的和应用相关,比如BCU控制大灯打开的接口可以是Rte_Call_RPort_BeamLight_SetDigOut也可以是Rte_Call_RPort_HeaderLight_Output,公司可以自己定义,又比如仪表想要从CAN总线上获得车速,改接口可以是Rte_IRead_RE_Test_RPort_Speed_uint8也可以是Rte_IRead_Test_RE_RPort_Spd_uint8,这些接口必须通过RTE交互。
3)Basicsoftware层(BSW)
虽然汽车中有各种不同的ECU,它们具有各种各样的功能,但是实现这些功能所需要的基础服务是可以抽象出来的,比如IO操作,AD操作,诊断,CAN通讯,操作系统等,无非就是不同的ECU功能,所操作的IO、AD代表不同的含义,所接收发送的CAN消息代表不同的含义,操作系统调度的任务周期优先级不同。
这些可以被抽象出来的基础服务被称为基础软件。
根据不同的功能对基础软件继续可以细分成四部分,分别为服务层(ServiceLayer),ECU抽象层(ECUAbstractLayer),复杂驱动(ComplexDriver)和MCAL(MicrocontrollerAbstractionLayer),四部分之间的互相依赖程度不尽相同。
3.1)服务层(ServiceLayer),这一层基础软件提供了汽车ECU非应用相关的服务,包括OS,网络通讯,内存管理(NVRAM),诊断(UDS,故障管理等),ECU状态管理模块等,它们对ECU的应用层功能提供辅助支持,这一层软件在不同领域的ECU中也非常相似,例如不同的ECU中的OS的任务周期和优先级不同,不同的ECU中的NVRAM的分区不同,存储的内容不同。
3.2)ECU抽象层(ECUAbstractLayer),这一层软件提供了ECU应用相关的服务,它是对一个ECU的抽象,它包括了所有的ECU的输入输出,比如AD,DIO,PWM等,这一层软件直接实现了ECU的应用层功能,可以读取传感器状态,可以控制执行器输出,不同领域的ECU会有很大的不同。
3.3)MCAL(MicrocontrollerAbstractionLayer),这一层软件是对ECU所使用的主控芯片的抽象,它跟芯片的实现紧密相关,是ECU软件的最底层部分,直接和主控芯片及外设芯片进行交互,它的作用是将芯片提供的功能抽象成接口,然后把这些接口提供给上边的服务层/ECU抽象层使用。
3.4)复杂驱动(ComplexDrivers),汽车ECU中有一些领域的ECU会处理相当复杂的硬件信号,执行相当复杂的硬件动作,例如发动机控制,ABS等,这些功能相关的软件很难抽象出来适用于所有的汽车ECU,它是跟ECU的应用以及ECU所使用的硬件紧密相关的,属于AUTOSAR构架中在不同的ECU上无法移植的部分。
BSW层中各个子模块说明
4)Microcontroller层
底层驱动层是由芯片生产厂家提供。
Welcome!
!
欢迎您的下载,
资料仅供参考!
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- AUTOSAR 架构 简述
![提示](https://static.bdocx.com/images/bang_tan.gif)