AUTOSAR架构简述.docx
- 文档编号:11422877
- 上传时间:2023-03-01
- 格式:DOCX
- 页数:11
- 大小:311.92KB
AUTOSAR架构简述.docx
《AUTOSAR架构简述.docx》由会员分享,可在线阅读,更多相关《AUTOSAR架构简述.docx(11页珍藏版)》请在冰豆网上搜索。
AUTOSAR架构简述
请选择WebLayout浏览模式
1.总体概述
AUTOSAR汽车开放系统架构),整车软件系统可以通过
AUTOSA礫构对车载网络、系统内存及总线诊断进行深度管理,他的出现有利于整车电子系统软件的更新及交换,并改善系统的可靠性和稳定性。
目前支持AUTOSAR标准的工具和软件供应商都已经推出了相应的产品,提供需求管理,系统描述,软件构件算法模型验证,软件构建算法建模,软件构件代码生成,RTE(RuntimeEnvironment)生成,ECU配置以及基础软件和操作系统等服务,帮助OEM实现无缝的系统软件架构开发流程。
AUTOSAR^划目标主要有三个:
1)建立独立于硬件的分层软件架构;
2)为实施应用提供方法论,包括制定无缝的软件架构堆叠流程并将应用软件整合至ECU
3)制定各种车辆应用接口规范,作为应用软件整合标准,以便软
件构件在不同汽车平台复用。
2.分层概述
ApplicationLaye
Runtimeenvironj
Autosar
AUTOSAF体系架构分层标准
1)应用层(ApplicationLayer)
Basicsoftware^
MicrocontroLl
应用层中的功能由各软件组件SWC(software
component)实现,组件中封装了部分或者全部汽车电子功能,包括对其功能的具体实现以及描述,比如控制汽车大灯、空调等部件的运作,但是与汽车硬件系统没有连接。
1.1)软件组件(softwarecomponent)
软件组件SWC(softwarecomponent)是由Atomiccomponent(最小逻辑单元)组成。
Atomiccomponent最小逻辑单元有Application、Sensor/actuator(传感器/执行器)两种类型。
其中Application是算法实现了类型,能在ECU中自由
映射;Senso、Actuator是为Application提供的
I/O端口类型,用于与ECU绑定,但不可像
Application那样能在各ECU上自由映射。
数个
SWC的逻辑集合组合成Composition。
1.2)端口(ports)
端口Ports是用来和其他SWC通信的。
通信内容分别为Dataelement(数据元)与operations
(操作)。
其中,Dataelements用Sender/Receiver通讯方式;operations用Client/Server通讯方式。
通讯方式
发送-接收端口(Sender/Receiver)用来传
输数据,具有一个通信端口可以包含多种数据类型特点。
但如果一个数据类型要通过总线传输,那么它必须与一个信号对应起来,数据类型既可以是简单的数据类型(integer,float),也可以
是复杂类型(array,record)。
通信方式:
1:
n或n:
1。
Dataelement:
Light
Dimmer
X1
''mapping^
RTE
Dataelement:
DoorOpen
Signal:
DoorLeft^Open
xLight-Dimm
AUTOSARBSW
Microcontroller
客户端一服务器端口(Client/Server)用来
提供Operation服务,具有一个客户端一服务器端口可以包含多种Operation和同步或是异步通信特点,一个客户端一服务器端口可以包含多种Operations操作,Operations操作也可被单个调用。
通信方式:
1:
n或n:
1。
SWC1
SWC2
RteCal1DoorS
1.3)可运行实体(Runablesentities)
可运行实体简称Runnables。
可运行实体包
含实际实现的函数,可以是具体的逻辑算法或是
实际操作。
可运行实体由RTE周期性或是事件触
2)Runtimeenvironment层(RTE
中间件部分给应用层提供了通信手段,这里的通信
是一种广义的通讯,可以理解成接口,应用层与其他软
件体的信息交互有两种,第一种是应用层中的不同模块
之间的信息交互;第二种是应用层模块同基础软件之间
的信息交互。
而RTE就是这些交互使用的接口的集散
地,它汇总了所有需要和软件体外部交互的接口。
从某
种意义上来看,设计符合AUTOSA的系统其实就是设计
RTE
SW-C之间的通信是调用RTEAPI函数而非直接实现
的,都在RTE的管理和控制之下。
每个API遵循统一的
命名规则且只和软件组件自身的描述有关。
具体通信实现取决于系统设计和配置,都由工具供应商提供的RTE
Generator自动生成的。
在设计开发阶段中,软件组件通信层面引入了一个
新的概念,虚拟功能总线VFB(VirtualFunctional
Bus)。
它是对AUTOSA所有通信机制的抽象,利用VFB开发工程师将软件组件的通信细节抽象,只需要通过AUTOSA所定义的接口进行描述,即能够实现软件组件与其他组件以及硬件之间的通信,甚至ECU内部或者是与其他ECU之间的数据传输。
从图中可以看到,有三种接口描述,我们先从定义的角度来看这
三种接口有什么不同
2.1)StandardizedInterface(标准接口):
标准接口
是在AUTOSAR准中被标准化的接口,但是并没有使用AUTOSA接口技术,标准接口通常被用在某个ECU内部的软件模块之间的通讯,不能用于网络通讯。
2.2)StandardizedAUTOSAIRnterface(标准AUTOSAR接口):
标准AUTOSA接口是在AUTOSA标准中使用AUTOSAR接口技术标准化的接口,这样的接口的语法和语义都被规定好了,这样的接口通常使用在AUTOSA服务中,这样的接口是基础软件服务提供给应用程序的。
2.3)AUTOSAIRterface(AUTOSA接口):
AUTOSA接口定义了软件模块和BSV模块(仅仅是IO抽象和复杂驱动)之间交互的方式,AUTOSA接口是以port的形式出现的,AUTOSA将ECU内部的通讯和网络通讯使用的接口进行了统一。
从上边的定义中我们可以看出不同的接口使用的场景不同,及不同的模块交互会使用到不同的接口。
除了将接口归类以外,这样定义究竟有什么实际的意义呢?
从实际使用的角度来看,第一和第二类接口都是语法语义标准化的接口,即接口函数的数量、函数的名字、函数参数名字及数量、函数的功能、函数的返回值都已经在标准里边定义好了。
不同的公司的软件在实施这些接口的时候虽然内容算法不同,但是它们长相和功能是一致的,接口定义在AUTOSA规范文档里边是可以查得到的。
第三类接口呢,AUTOSA仅仅规定了简单的命名规则,这类接口高度的和应用相关,比如BCL控制大灯打开的接口可以是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交互。
AppHcatlon
Software
Component
Actuator
Software
Component
Sensor
Software
Component
AUIOSAR
IntarFaee
AUTOSAR
Inter4ac«
AUTOSAR
AUTOSAR
Software
Application
Software
Component
AUTOSARInterface
RTE
Standardized
Interface
Standardized
AUTOSAR
Interface
Standardized
Interface
AUTOSAR
interface
AUTOSAR
Interface
Operating
System
s|
Standardized
Interface
ECU
Abstraction
Standardized
Interface
Services
Sommuntcation
Standardizedinterface
Standardized
ECUHardware
3)Basicsoftware层(BSVV
Complex
DeviGe
Orivers
icrocofitroflaAbstraction
Ser
UnbHand
Mtcrwl)ri
虽然汽车中有各种不同的ECU它们具有各种各样的功能,但是实现这些功能所需要的基础服务是可以抽象出来的,比如
10操作,AD操作,诊断,CANS讯,操作系统等,无非就是不同的ECU功能,所操作的10、AD代表不同的含义,所接收发送的CAN消息代表不同的含义,操作系统调度的任务周期优先级不同。
这些可以被抽象出来的基础服务被称为基础软件。
根据不同的功能对基础软件继续可以细分成四部分,分别为服
务层(ServiceLayer),ECU抽象层(ECUAbstractLayer),复杂驱动(ComplexDriver)和MCAL(MicrocontrollerAbstractionLayer),四部分之间的互相依赖程度不尽相同。
3.1)服务层(ServiceLayer),这一层基础软件提供了汽车ECU非应用相关的服务,包括OS网络通讯,内存管理(NVRAM诊断(UDS故障管理等),ECU状态管理模块等,它们对ECU勺应用层功能提供辅助支持,这一层软件在不同领域的ECL中也非常相似,例如不同的ECL中的OS的任务周期和优先级不同,不同的ECL中的NVRAI的分区不同,存储的内容不同。
3.2)ECL抽象层(ECUAbstractLayer),这一层软件提供了ECU应用相关的服务,它是对一个ECU勺抽象,它包括了所有的ECU勺输入输出,比如ADDIO,PWM等,这一层软件直接实现了ECU勺应用层功能,可以读取传感器状态,可以控制执行器输出,不同领域的ECU会有很大的不同。
3.3)MCA(LMicrocontrollerAbstractionLayer),这一层软件是对ECL所使用的主控芯片的抽象,它跟芯片的实现紧密相关,是ECL软件的最底层部分,直接和主控芯片及外设芯片进行交互,它的作用是将芯片提供的功能抽象成接口,然后把这些接口提供给上边的服务层/ECU抽象层使用。
3.4)复杂驱动(ComplexDrivers),汽车ECL中有一些领域的ECU会处理相当复杂的硬件信号,执行相当复杂的硬件动作,例如发动机控制,ABS等,这些功能相关的软件很难抽象出来适用于所有的汽车ECU它是跟ECU勺应用以及ECU所使用的硬件紧密相关的,属于AUTOSA构架中在不同的ECU上无法移植的部分。
ServicesLayer
ECUAbstractionLayer
MicrocontrollerAbstractionLaver
4
Application
BSV层中各个子模块说明
4)Microcontroller层
底层驱动层是由芯片生产厂家提供。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- AUTOSAR 架构 简述