AUTOSAR技术分析报告Word文件下载.doc
《AUTOSAR技术分析报告Word文件下载.doc》由会员分享，可在线阅读，更多相关《AUTOSAR技术分析报告Word文件下载.doc（36页珍藏版）》请在冰点文库上搜索。
缺少兼容的工具（供应商、OEM）
标准化的规范交换格式
对规范的改进（格式、内容）
提供无缝的工具链。
浪费在实现和优化组件上的努力，而顾客并不承认这些努力的价值。
基础软件核
软件质量的加强。
将工作集中在有价值的功能上。
微控制器模型缺乏可用性，很难适应现有软件。
（由新功能引起的）微控制器性能的扩展需求所导致的升级需要（如重新设计）。
微控制器抽象
微控制器能在不需要改变更高软件层的情况下调换。
重定位ECU之间的功能时需要做大量的工作。
功能重用时也需要做大量的工作。
运行时环境（RTE）
功能封装导致的通信技术的独立性。
通过标准化机制，使得通信更加简单。
使功能分区和功能重定位变得可能。
非竞争性功能必须适应OEM的特定环境。
因为需要从其它组件供应接口需要很多功夫，所以哪怕是很微小的革新，也需要做很多工作。
基础软件和模型生成的代码间缺少清晰的接口。
接口标准化
减少/避免OEM和供应商之间的接口。
通过使用通用接口目录，使独立于软件功能的硬件实现所耗费的工作量。
简化模型驱动的开发，允许使用标准化的AUTOSAR代码生成工具。
OEM间的模型的可重用性。
不同供应商之间模块的可交换性。
2．AUTOSAR软件结构
2.1AUTOSAR软件的组成与分层
AUTOSAR的软件组件可以用下图来表示：
对于上图所示的一些组件，可以根据功能及相互关系对其进行分层，如下图所示：
·
微控制器抽象层
这一层是基础软件中的最低一层。
它包含驱动，这些驱动是软件模块，用来对μC内部设备和映射了μC外部设备的内存进行访问。
ECU抽象层
这一层与微控制器抽象层进行对接。
它也包含了外部设备的驱动。
它为访问外设提供了API，不管这些外设的位置（μC内部或外部），也不管它们与μC的连接（端口针脚，接口类型）。
服务层
这层是基础软件中的最高层，而且它与应用软件之间有关联：
当对I/O信号的访问包含ECU抽象层中时，服务层提供：
l操作系统功能
l车辆网络通信及管理服务
l存储管理（NVRAM管理）
l诊断服务（包括UDS通信及错误内存）
lECU状态管理
2.2RTE
运行时环境RTE是AUTOSARECU体系结构的核心组成部分。
RTE是AUTOSAR虚拟功能总线（VirtualFunctionBus，VFB）的接口（针对某个特定ECU）的实现，因此，它为应用程序软件组件之间的通信提供了基本的服务，同时也便于访问包含OS的基本软件组件。
应用程序软件组件包含独立于CPU和所处位置的系统软件。
这就意味着，为了满足系统设计者所做的一些限制，应用程序组件能够在系统配置期间被映射到任何有效的ECU上。
RTE负责确保这些组件能够通信。
RTE和OS,AUTOSARCOM和其他的基础软件模块（BSW）是VFB（VirtualFunctionalBus）概念的实现。
RTE实现了AUTOSARVFB的接口，从而实现了AUTOSAR软件组件之间的通信。
RTE是AUTOSARECU体系的核心,它提供了在AUTOSAR软件组件间通信的基础服务，扮演了一些方法，通过这些方法AUROSAR软件组件能访问包括OS和通信服务在内基础软件模块的。
2.3系统服务
系统服务是一组可以由所有层次模块使用的模块和功能。
例如实时操作系统、错误管理器和库功能。
为应用和基本软件模块提供基本服务。
它包含下图所示功能：
2.3.1AUTOSAROS
AUTOSAROS为实时应用提供了所有基本服务，即中断处理、调度、系统时间和时钟同步、本地消息处理，以及错误检测机制。
所有服务都隐藏在良好定义的API之后。
应用与OS和通信层的连接只通过API。
AUTOSAROS的基本特征包括：
静态配置
能够推断实时系统性能
提供基于优先级的调度策略
提供运行时保护功能（存储、计时等）
可宿主在低端控制器上，并且不需要其他资源
它包含以下几个方面：
实时操作系统
在嵌入式汽车ECU中的实时操作系统构成软件动态行为的基础。
它管理任务和事件的调度，不同任务间的数据流，并且提供监控和错误处理功能。
但是，在汽车系统中，对操作系统的需求集中在特定领域。
所使用的操作系统必须高效运行并且所占存储空间小。
在多媒体和远程信息处理应用中，操作系统提供的特征集以及可用计算资源有很大不同。
在纯粹的任务管理之上，OS中还包含了复杂的数据处理（例如，流、快速文件系统等）、存储管理甚至图形用户接口。
汽车OS的典型领域涵盖了调度和同步的核心特征。
在AUTOSAR中，上面讨论的附加特征在OS的范围之外，其他WP4.2.2.1工作包（例如SPAL）涵盖了这些特征。
在AUTOSAR的体系结构约束之下不可能把其他OS（例如，QNX、VxWorks和WindowsCE等）的特征集合集成到整体的OS/通信/驱动结构中。
因此，AUTOSAROS只考虑核心特征。
核心操作系统
OSEK/VDK操作系统广泛应用于汽车工业，并且已经证明了可以在现代车辆的所有ECU类型中使用。
OSEKOS引入的概念被广泛地理解，汽车工业领域在设计基于OSEKOS的系统方面有多年的经验。
OSEKOS是一个事件触发的操作系统。
这为基于AUTOSAR的系统的设计和维护提供了高度的灵活性。
事件触发使得可以自由地选择在运行时驱动调度的事件，例如角反转、局部时间源、全局时间源、错误出现等等。
由于这些原因，AUTOSAROS的核心功能必须基于OSEKOS。
OSEKOS特别提供了以下特性以支持AUTOSAR：
固定的基于优先级调度
处理中断的功能
只有中断有高于任务的优先级
一些防止错误使用OS服务的保护措施
StartOS（）和StartupHook启动接口
ShutdownOS（）和ShutdownHook关闭接口
AUTOSAROS基于OSEKOS意味着应用程序是向后兼容的。
为OSEKOS编写的应用程序可以在AUTOSAROS上运行。
但是，使用AUTOSAROS引入的一些新特性需要对已存在的OSEKOS特性的使用有所限制。
例如：
为定时器回调实现定时和内存保护效率就会很低。
此外，AUTOSAROS扩展了一些已存在的特性，例如直接通过定时器驱动计数器。
AUTOSAROS提供的API向后兼容于OSEKOS的API。
新的需求作为功能扩展来集成。
AUTOSAROS对OSEKOS扩展的API如下表：
服务名
语法
GetApplicationID
ApplicationTypeGetApplicationID（void）
GetISRID
ISRTypeGetISRID（void）
CallTrustedFunction
StatusTypeCallTrustedFunction
（
TrustedFunctionIndexTypeFunctionIndex,
TrustedFunctionParameterRefTypeFunctionParams
）
CheckISRMemoryAccess
AccessTypeCheckISRMemoryAccess
ISRTypeISRID,
MemoryStartAddressTypeAddress,
MemorySizeTypeSize
CheckTaskMemoryAccess
AccessTypeCheckTaskMemoryAccess
TaskTypeTaskID,
CheckObjectAccess
ObjectAccessTypeCheckObjectAccess
ApplicationTypeApplID,
ObjectTypeTypeObjectType,
…
CheckObjectOwnership
ApplicationTypeCheckObjectOwnership
StartScheduleTableRel
StatusTypeStartScheduleTableRel
ScheduleTableTypeScheduleTableID,
TickTypeOffset
StartScheduleTableAbs
StatusTypeStartScheduleTableAbs
TickTypeTickvalue
StopScheduleTable
StatusTypeStopScheduleTable
ScheduleTableTypeScheduleTableID
NextScheduleTable
StatusTypeNextScheduleTable
ScheduleTableTypeScheduleTableID_current,
ScheduleTableTypeScheduleTableID_next
IncrementCounter
StatusTypeIncrementCounter
CounterTypeCounterID
SyncScheduleTable
StatusTypeSyncScheduleTable
ScheduleTableTypeSchedTableID,
GlobalTimeTickTypeGlobalTime
SetScheduleTableAsync
StatusTypeSetScheduleTableAsync
ScheduleTableTypeScheduleID
GetScheduleTableStatus
StatusTypeGetScheduleTableStatus
ScheduleTableTypeScheduleID,
ScheduleTableStatusRefTypeScheduleStatus
TerminateApplication
StatusTypeTerminateApplication（RestartTypeRestartOption）
DisableInterruptSource
StatusTypeDisableInterruptSource（ISRTypeDisableISR）
EnableInterruptSource
StatusTypeEnableInterruptSource（ISRTypeEnableISR）
ProtectionHook
ProtectionReturnTypeProtectionHook
StatusTypeFatalerror
静态定义的调度
在许多应用中需要静态定义一组互相关联的任务的活动。
这用于在基于数据流的设计中保证数据一致性，与时间触发的网络同步，保证正确的运行时定相，等等。
时间触发的操作系统通常作为这个问题的解决方法。
然而，时间只是简单的事件，所以任何事件触发的OS，包括OSEKOS，会在汽车电子控制单元实现一个用于静态调度实时软件的调度器。
监控功能
监控功能在适当的执行阶段检测错误，不是在错误发生的时刻。
因此，监控功能是在运行时捕捉失效，而不是预防故障。
保护功能
AUTOSAR概念需要多来源的OS应用共存在同一处理器中。
为了防止这些OS应用之间意想不到的交互，需要提供保护机制。
计时器服务
计时器服务为应用和基础软件提供软件计时器。
计时机制的核心已经由OSEKOS的计数器和闹钟提供。
如果要提供通用的软件计时，一些补充特性需要添加到AUTOSAROS。
时间触发操作系统
时间触发操作系统在汽车电子控制单元实现了一个用于静态调度实时软件的调度器。
另外，操作系统为实时应用提供了所有基本服务，即中断处理、调度、系统时间和时钟同步、本地消息处理，以及错误检测机制。
对于特殊的应用，操作系统能够配置为只包含该应用需要的服务。
因此操作系统的资源需求尽量少。
2.3.2BSW调度器
BSW调度器是系统服务的一部分，因此它向所有层次的所有模块提供服务。
但是，与其它BSW模块不同，BSW调度器提供了集成的概念和服务。
BSW调度器提供方法用以：
把BSW模块的实现嵌入AUTOSAROS上下文
触发BSW模块的主要处理功能
应用BSW模块的数据一致性机制
集成者的任务是应用所给的方法（AUTOSAROS提供的），在特定项目环境中以良好定义和有效的方式把BSW模块装配起来。
这也意味着BSW调度器只是使用AUTOSAROS。
它与AUTOSAROS调度器并不冲突。
BSW调度器的实现基于：
BSW模块的BSW模块描述
BSW调度器的配置
2.3.3模式管理
模式管理簇包括三个基本软件模块：
ECU状态管理器，控制AUTOSARBSW模块的启动阶段，包括OS的启动；
通信管理器，负责网络资源管理；
看门狗管理器，基于应用软件的生存状态触发看门狗。
2.3.3.1ECU状态管理器
ECU状态管理器是一个基本软件模块，管理ECU的状态（OFF、RUN、SLEEP），以及这些状态之间的转换（过渡状态：
STARTUP、WAKEUP、SHUTDOWN）。
详细地，ECU状态管理器：
负责初始化和de-initialization所有基本软件模块，包括OS和RTE；
在需要时与所谓的资源管理器（例如，通信管理器）协作，关闭ECU；
管理所有唤醒事件，并在被要求时配置ECU为SLEEP状态。
为了完成所有这些任务，ECU状态管理器提供了一些重要的协议：
RUN请求协议，调整ECU是保持活动状态还是准备关闭，
唤醒确认协议，从“不稳定的”唤醒事件中区分出“真正的”唤醒事件，
时间触发的增多非工作状态协议（TimeTriggeredIncreasedInoperation-TTII），允许ECU更多地进入节能的休眠状态。
ECU状态管理器必须支持独立的预处理动作和过渡，以启动ECU或将其转换到低功耗状态（例如，休眠状态/备用状态）。
通过良好使用ECU状态管理器的特性和能力，此模块能够用于执行电源消耗的预定义策略，因此提供了对ECU的有效能源管理。
ECU状态管理器的特性和优势包括：
初始化和关闭基本软件模块。
ECU主要状态的标准化定义。
时间触发的更多非工作状态。
2.3.3.2看门狗管理器
看门狗管理器是AUTOSAR（服务层次）的标准化基本软件体系结构的基本软件模块。
它监控与计时约束有关的应用执行的可靠性。
分层体系结构方法使得应用计时约束和看门狗硬件计时约束分离。
基于此，看门狗管理器在触发看门狗硬件的同时提供了对一些独立应用的生存监控。
看门狗管理器提供以下特性：
监督多个处于ECU的单独应用，这些应用有独立的计时约束并且需要特别监督运行时的行为和生存状态。
每个独立的受监控实体都有故障响应机制。
可以关闭对单独应用的监督，而不会违反看门狗触发（例如，对于禁止的应用）。
通过看门狗驱动触发内部或外部、标准或窗口，看门狗。
（internalorexternal,standardorwindow,watchdog）对内部或外部看门狗的访问由看门狗接口处理。
根据ECU状态和硬件性能选择看门狗模式（OffMode,SlowMode,FastMode）。
2.3.3.3通信管理器
通信管理器收集并协调来自通信请求者（用户）的访问请求。
通信管理器的目的是：
简化通信协议栈的使用。
包括通信栈的初始化，以及简单的网络管理。
调整ECU上多个独立软件组件的通信栈（允许发送和接收消息）的可用性。
暂时禁止发送消息以阻止ECU（主动地）唤醒物理通道。
通过为每个物理通道实现一个状态机来控制ECU的多个物理通道。
可以强制ECU保持物理通道处于“silent通信”模式。
分配所请求的通信模式需要的所有资源，简化资源管理。
通信管理器定义了“通信模式”，表示一个特定的物理通道对于应用是否可用，以及如何使用（发送/接收，只接收，即不发送也不接收）。
2.4诊断服务
2.4.1诊断事件管理器
诊断事件管理器DEM（DiagnosticEventManager）是一个子组件，如同AUTOSAR内诊断模块的诊断通信管理器（DCM）和功能禁止管理器（FIM）。
它负责处理和存储诊断事件（错误）和相关FreezeFrame数据。
DEM进一步提供故障信息给DCM（例如，从事件存储器读取所有存储的DTC（DiagnosticTroubleCode））。
DEM给应用层、DCM和FIM提供接口。
定义了可选的过滤服务。
2.4.2功能禁止管理器
功能禁止管理器FIM（FunctionInhibitionManager）负责提供软件组件和软件组件功能的控制机制。
功能由一个、多个或部分有相同权限/禁止条件的可执行实体构成。
通过FIM方法，对这些功能的禁止可以配置甚至修改。
所以，极大地提高了功能在新系统环境下的适应性。
FIM意义上的功能与可执行实体是不同并且独立的类型。
可执行实体主要由调度需求来区分。
与此相对的是，功能由禁止条件来分类。
FIM服务关注SW-C的功能，但是并不局限于此。
BSW的功能也能够使用FIM服务。
功能被指定了一个标识符（FID–functionidentifier），以及该特定标识符的禁止条件。
功能在执行之前获得它们各自的权限状态。
如果禁止条件应用于特定标识符，对应的功能将不再执行。
FIM与DEM密切相关，因为诊断事件和它们的状态信息作为禁止条件被提供给FIM。
如果检测到了失效，并且事件报告给了DEM，那么FIM禁止FID和对应的功能。
为了处理功能和关联事件的关系，功能的标识符和禁止条件必须引入到SW-C模板中（与BSW等价），并且在配置期间构造数据结构以处理标识符对于特定事件的敏感性。
这些关系在每个FIM中是唯一的。
RTE和FIM之间没有功能上的联系。
在AUTOSAR中，RTE按照接口和调度需求处理SW-C。
与此相对的是，FIM处理禁止条件并通过标识符（FID）为控制功能提供支持机制。
因此，FIM概念和RTE概念不互相干扰。
2.4.3开发错误跟踪器
开发错误跟踪器DET（DevelopmentErrorTracer）主要用于在开发期间跟踪和记录错误。
API参数给出了追踪源和错误类型：
错误所在的模块
错误所在的功能
错误类型
由软件开发者和软件集成者在特定应用和测试环境下为API功能选择最优的策略。
可能包括以下功能：
在错误报告API内设置调试器断点
计算报告的错误
在RAM缓存中记录调用和传递的参数
通过通信接口发送报告的错误到外部日志
DET仅仅是对SW开发和集成的辅助，并不一定要包含在产品代码中。
API已经定义，但是功能由开发者根据特定需求来选择/实现。
2.4.4诊断通信管理器
诊断通信管理器DCM（DiagnosticCommunicationManager）确保诊断数据流，并且管理诊断状态，特别是诊断对话期和安全状态。
另外，DCM检查诊断服务请求是否被支持，以及根据诊断状态判断服务是否可以在当前对话期中执行。
DCM为所有诊断服务提供连接到AUTOSAR-RTE的接口。
另外DCM也处理一些基本诊断服务。
在AUTOSAR体系结构中，诊断通信管理器（DCM）处在通信服务中（服务层）。
DCM是应用和PDU路由器封装的车辆网络通信（CAN、LIN、FlexRay和MOST）之间的中间层。
DCM与PDU路由器之间有一个接口。
在通信过程中，DCM从PDU（ProtocolDataUnit）路由器接收诊断消息。
DCM在其内部处理、检查诊断消息，并把消息传送到AUTOSARSW组件进一步处理。
根据诊断服务ID，将执行应用层中的相应调用。
DCM必须是网络无关的，所以协议和消息配置在DCM的下层。
这需要连接到PDU路由器的网络无关接口。
DCM由以下功能块组成：
DSP-DiagnosticServiceProcessing
DSP主要包含了完整实现的诊断服务，这些服务在不同的应用之中是通用的（例如，访问故障数据），所以不需要由应用实现。
DSD-DiagnosticServiceDispatcher
DSD的目的是处理诊断数据流。
这里的处理意味着：
通过网络接收新的诊断请求并发送到数据处理器。
当被应用触发时，通过网络传送诊断响应（AUTOSARSW-Component或DSP）。
DSL-DiagnosticSessionLayer
DSL保证数据流与诊断请求和响应有关。
DSL也监督和确保
升级会员 