AUTOSAR架构简述文档格式.docx
《AUTOSAR架构简述文档格式.docx》由会员分享，可在线阅读，更多相关《AUTOSAR架构简述文档格式.docx（11页珍藏版）》请在冰点文库上搜索。
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
DoorOpen
Signal:
DoorLeft^Open
xLight-Dimm
AUTOSARBSW
Microcontroller
客户端一服务器端口（Client/Server）用来
提供Operation服务，具有一个客户端一服务器端口可以包含多种Operation和同步或是异步通信特点，一个客户端一服务器端口可以包含多种Operations操作，Operations操作也可被单个调用。
n或n:
SWC1
SWC2
RteCal1DoorS
1.3）可运行实体（Runablesentities）
可运行实体简称Runnables。
可运行实体包
含实际实现的函数，可以是具体的逻辑算法或是
实际操作。
可运行实体由RTE周期性或是事件触
2）Runtimeenvironment层（RTE
中间件部分给应用层提供了通信手段，这里的通信
是一种广义的通讯，可以理解成接口，应用层与其他软
件体的信息交互有两种，第一种是应用层中的不同模块
之间的信息交互；
第二种是应用层模块同基础软件之间
的信息交互。
而RTE就是这些交互使用的接口的集散
地，它汇总了所有需要和软件体外部交互的接口。
从某
种意义上来看，设计符合AUTOSA的系统其实就是设计
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
Sensor
AUIOSAR
IntarFaee
AUTOSAR
Inter4ac«
Application
AUTOSARInterface
Standardized
Interface
interface
Operating
System
s|
ECU
Abstraction
Services
Sommuntcation
Standardizedinterface
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
BSV层中各个子模块说明
4）Microcontroller层
底层驱动层是由芯片生产厂家提供。
升级会员 