AUTOSAR技术分析报告(2)

汽车OS的典型领域涵盖了调度和同步的核心特征。在AUTOSAR中，上面讨论的附加特征在OS的范围之外，其他WP4.2.2.1工作包（例如SPAL）涵盖了这些特征。在AUTOSAR的体系结构约束之下不可能把其他OS（例如，QNX、VxWorks和Windows CE等）的特征集合集成到整体的OS/通信/驱动结构中。因此，AUTOSAR OS只考虑核心特征。 · 核心操作系统

OSEK/VDK操作系统广泛应用于汽车工业，并且已经证明了可以在现代车辆的所有ECU类型中使用。OSEK OS引入的概念被广泛地理解，汽车工业领域在设计基于OSEK OS的系统方面有多年的经验。

OSEK OS是一个事件触发的操作系统。这为基于AUTOSAR的系统的设计和维护提供了高度的灵活性。事件触发使得可以自由地选择在运行时驱动调度的事件，例如角反转、局部时间源、全局时间源、错误出现等等。

由于这些原因，AUTOSAR OS的核心功能必须基于OSEK OS。OSEK OS特别提供了以下特性以支持AUTOSAR：

? ? ? ? ? ?

固定的基于优先级调度 处理中断的功能

只有中断有高于任务的优先级 一些防止错误使用OS服务的保护措施 StartOS()和StartupHook启动接口 ShutdownOS()和ShutdownHook关闭接口

AUTOSAR OS基于OSEK OS意味着应用程序是向后兼容的。为OSEK OS编写的应用程序可以在AUTOSAR OS上运行。但是，使用AUTOSAR OS引入的一些新特性需要对已存在的OSEK OS特性的使用有所限制。例如：为定时器回调实现定时和内存保护效率就会很低。此外，AUTOSAR OS扩展了一些已存在的特性，例如直接通过定时器驱动计数器。

AUTOSAR OS提供的API向后兼容于OSEK OS的API。新的需求作为功能扩展来集成。

AUTOSAR OS对OSEK OS扩展的API如下表：

服务名 GetApplicationID GetISRID CallTrustedFunction 语法 ApplicationType GetApplicationID (void) ISRType GetISRID (void) StatusType CallTrustedFunction ( TrustedFunctionIndexType FunctionIndex, TrustedFunctionParameterRefType FunctionParams ) CheckISRMemoryAccess AccessType CheckISRMemoryAccess ( ISRType ISRID, MemoryStartAddressType Address, MemorySizeType Size ) AccessType CheckTaskMemoryAccess ( TaskType TaskID, MemoryStartAddressType Address, MemorySizeType Size ) ObjectAccessType CheckObjectAccess ( ApplicationType ApplID, ObjectTypeType ObjectType, … ) ApplicationType CheckObjectOwnership ( ObjectTypeType ObjectType, … ) StatusType StartScheduleTableRel ( ScheduleTableType ScheduleTableID, TickType Offset ) StatusType StartScheduleTableAbs ( ScheduleTableType ScheduleTableID, TickType Tickvalue ) StatusType StopScheduleTable ( ScheduleTableType ScheduleTableID ) StatusType NextScheduleTable ( ScheduleTableType ScheduleTableID_current, ScheduleTableType ScheduleTableID_next ) StatusType IncrementCounter ( CheckTaskMemoryAccess CheckObjectAccess CheckObjectOwnership StartScheduleTableRel StartScheduleTableAbs StopScheduleTable NextScheduleTable IncrementCounter CounterType CounterID ) SyncScheduleTable StatusType SyncScheduleTable ( ScheduleTableType SchedTableID, GlobalTimeTickType GlobalTime ) StatusType SetScheduleTableAsync ( ScheduleTableType ScheduleID ) StatusType GetScheduleTableStatus ( ScheduleTableType ScheduleID, ScheduleTableStatusRefType ScheduleStatus ) StatusType TerminateApplication(RestartType RestartOption) StatusType DisableInterruptSource (ISRType DisableISR) StatusType EnableInterruptSource (ISRType EnableISR) ProtectionReturnType ProtectionHook ( StatusType Fatalerror ) SetScheduleTableAsync GetScheduleTableStatus TerminateApplication DisableInterruptSource EnableInterruptSource ProtectionHook

· 静态定义的调度

在许多应用中需要静态定义一组互相关联的任务的活动。这用于在基于数据流的设计中保证数据一致性，与时间触发的网络同步，保证正确的运行时定相，等等。 时间触发的操作系统通常作为这个问题的解决方法。然而，时间只是简单的事件，所以任何事件触发的OS，包括OSEK OS，会在汽车电子控制单元实现一个用于静态调度实时软件的调度器。 · 监控功能

监控功能在适当的执行阶段检测错误，不是在错误发生的时刻。因此，监控功能是在运行时捕捉失效，而不是预防故障。 · 保护功能

AUTOSAR概念需要多来源的OS应用共存在同一处理器中。为了防止这些OS应用之间意想不到的交互，需要提供保护机制。 · 计时器服务

计时器服务为应用和基础软件提供软件计时器。

计时机制的核心已经由OSEK OS的计数器和闹钟提供。如果要提供通用的软件计时，一些补充特性需要添加到AUTOSAR OS。 · 时间触发操作系统

时间触发操作系统在汽车电子控制单元实现了一个用于静态调度实时软件的调度器。

另外，操作系统为实时应用提供了所有基本服务，即中断处理、调度、系统时间和时钟同步、本地消息处理，以及错误检测机制。

所有服务都隐藏在良好定义的API之后。应用与OS和通信层的连接只通过API。 对于特殊的应用，操作系统能够配置为只包含该应用需要的服务。因此操作系统的资源需求尽量少。 2.3.2 BSW调度器

BSW调度器是系统服务的一部分，因此它向所有层次的所有模块提供服务。但是，与其它BSW模块不同，BSW调度器提供了集成的概念和服务。BSW调度器提供方法用以：

? ? ?

把BSW模块的实现嵌入AUTOSAR OS上下文 触发BSW模块的主要处理功能 应用BSW模块的数据一致性机制

集成者的任务是应用所给的方法（AUTOSAR OS提供的），在特定项目环境中以良好定义和有效的方式把BSW模块装配起来。

这也意味着BSW调度器只是使用AUTOSAR OS。它与AUTOSAR OS调度器并不冲突。

BSW调度器的实现基于：

? ?

BSW模块的BSW模块描述 BSW调度器的配置

2.3.3 模式管理

模式管理簇包括三个基本软件模块：

· ECU状态管理器，控制AUTOSAR BSW模块的启动阶段，包括OS的启动； · 通信管理器，负责网络资源管理；

· 看门狗管理器，基于应用软件的生存状态触发看门狗。 2.3.3.1 ECU状态管理器

ECU状态管理器是一个基本软件模块，管理ECU的状态（OFF、RUN、SLEEP），以及这些状态之间的转换（过渡状态：STARTUP、WAKEUP、SHUTDOWN）。详细地，ECU状态管理器：

· 负责初始化和de-initialization所有基本软件模块，包括OS和RTE； · 在需要时与所谓的资源管理器（例如，通信管理器）协作，关闭ECU； · 管理所有唤醒事件，并在被要求时配置ECU为SLEEP状态。 为了完成所有这些任务，ECU状态管理器提供了一些重要的协议： · RUN请求协议，调整ECU是保持活动状态还是准备关闭，

· 唤醒确认协议，从“不稳定的”唤醒事件中区分出“真正的”唤醒事件， · 时间触发的增多非工作状态协议（Time Triggered Increased Inoperation - TTII），允许ECU更多地进入节能的休眠状态。

ECU状态管理器必须支持独立的预处理动作和过渡，以启动ECU或将其转换到低功耗状态（例如，休眠状态/备用状态）。通过良好使用ECU状态管理器的特性和能力，此模块能够用于执行电源消耗的预定义策略，因此提供了对ECU的有效能源管理。

ECU状态管理器的特性和优势包括： · 初始化和关闭基本软件模块。 · ECU主要状态的标准化定义。 · 时间触发的更多非工作状态。 2.3.3.2 看门狗管理器

看门狗管理器是AUTOSAR（服务层次）的标准化基本软件体系结构的基本软件模块。它监控与计时约束有关的应用执行的可靠性。

分层体系结构方法使得应用计时约束和看门狗硬件计时约束分离。基于此，看门狗管理器在触发看门狗硬件的同时提供了对一些独立应用的生存监控。

看门狗管理器提供以下特性：

· 监督多个处于ECU的单独应用，这些应用有独立的计时约束并且需要特别监督运

行时的行为和生存状态。 · 每个独立的受监控实体都有故障响应机制。

· 可以关闭对单独应用的监督，而不会违反看门狗触发（例如，对于禁止的应用）。 · 通过看门狗驱动触发内部或外部、标准或窗口，看门狗。（internal or external,

standard or window, watchdog）对内部或外部看门狗的访问由看门狗接口处理。 · 根据ECU状态和硬件性能选择看门狗模式（Off Mode, Slow Mode, Fast Mode）。 2.3.3.3 通信管理器

通信管理器收集并协调来自通信请求者（用户）的访问请求。 通信管理器的目的是：

· 简化通信协议栈的使用。包括通信栈的初始化，以及简单的网络管理。

百度搜索“77cn”或“免费范文网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读，免费范文网，提供经典小说综合文库AUTOSAR技术分析报告(2)在线全文阅读。