AUTOSAR（AUTomotiveOpenSystemARchitecture）是一种针对汽车电子领域的开放式软件架构，旨在提高软件的可管理性、可移植性和质量。其核心组件包括微控制器抽象层、ECU抽象层、服务层、RTE（运行时环境）和系统服务，如操作系统、诊断服务等。AUTOSAR通过标准化接口和分层结构，使得软件组件能更好地适应不同硬件和应用需求，同时提供了如实时操作系统、通信管理、模式管理、诊断服务等功能，以支持复杂的汽车电子系统需求。
1
．
AUTOSAR
简介
汽车电子领域的软件主要属于嵌入式软件。因此，其发展阶段类似于其他嵌入式系统的
软件发展。由于受限于嵌入式硬件本身资源的匮乏，各种硬件产品的种类繁多和各自差异，
以及整体嵌入式系统软件的逐步发展，起初的软件设计开发主要是封闭式的。这样有助于开
发针对于特定硬件体，充分优化利用资源而特定设计的软件系统。这样的软件系统，是针对
于特定硬件和特定应用而设计，其对于硬件资源的充分应用，以及软件本身的执行效率无疑
是非常高。
然而，随着硬件本身的逐步发展，其可用资源已经十分充分。另一方面，汽车电子领域
应用需求也日趋复杂，软件本身也变得越来越复杂。因此，无论汽车厂还是部件商都感到软
件的标准化问题。软件的可管理性，可重复使用性，可裁减性，以及质量保证等等问题被提
上了议程。
AUTOSAR
的提出正是基于以上一些软件发展的要求，由几大主要汽车厂商以
及部件提供商联合提出的，其中包括
BWM, DaimlerChrysler, Ford Motor, PSA Peugeot,
Toyota Motor, Volkswagen AG, Bosch, Continetal, Siemens VDO
等。
AUTOSAR
是针对特定的汽车电子这一领域，提出的一套开放式软件结构。其主体思
想是使得软件设计开发更易于管理，软件系统更易于移植、裁剪，以及更好的维护性和质量
保证。
AUTOSAR
组织所提出的目标以及它所关注的功能领域在下表中列出：
为了实现上述的项目目标，针对在汽车电子行业中面临的一些挑战，
AUTOSAR
所采
用的解决方案及其好处可以概述如下：
2
．
AUTOSAR
软件结构
2.1 AUTOSAR
软件的组成与分层
AUTOSAR
的软件组件可以用下图来表示：
对于上图所示的一些组件，可以根据功能及相互关系对其进行分层，如下图所示：
·
微控制器抽象层
这一层是基础软件中的最低一层。它包含驱动，这些驱动是软件模块，用来对
μC
内部设备和映射了
μC
外部设备的内存进行访问。
·
ECU
抽象层
这一层与微控制器抽象层进行对接。它也包含了外部设备的驱动。它为访问外设提
供了
API
，不管这些外设的位置
(μC
内部或外部
)
，也不管它们与
μC
的连接
(
端口
针脚，接口类型
)
。
·
服务层
这层是基础软件中的最高层，而且它与应用软件之间有关联：当对
I/O
信号的访问
包含
ECU
抽象层中时，服务层提供：
操作系统功能
车辆网络通信及管理服务
存储管理（
NVRAM
管理）
诊断服务（包括
UDS
通信及错误内存）
ECU
状态管理
2.2 RTE
运行时环境
RTE
是
AUTOSAR ECU
体系结构的核心组成部分。
RTE
是
AUTOSAR
虚
拟功能总线（
Virtual Function Bus
，
VFB
）的接口（针对某个特定
ECU
）的实现，因此，
它为应用程序软件组件之间的通信提供了基本的服务，同时也便于访问包含
OS
的基本软件
组件。
应用程序软件组件包含独立于
CPU
和所处位置的系统软件。这就意味着，为了满足系
统设计者所做的一些限制，应用程序组件能够在系统配置期间被映射到任何有效的
ECU
上。
RTE
负责确保这些组件能够通信。
RTE
和
OS,AUTOSAR COM
和其他的基础软件模块（
BSW
）是
VFB
（
Virtual Functional
Bus
）概念的实现。
RTE
实现了
AUTOSAR VFB
的接口，从而实现了
AUTOSAR
软件组件
之间的通信。
RTE
是
AUTOSAR ECU
体系的核心
,
它提供了在
AUTOSAR
软件组件间通信的基础服
务，扮演了一些方法，通过这些方法
AUROSAR
软件组件能访问包括
OS
和通信服务在内
基础软件模块的。
2.3
系统服务
系统服务是一组可以由所有层次模块使用的模块和功能。例如实时操作系统、错误管理
器和库功能。为应用和基本软件模块提供基本服务。它包含下图所示功能：
2.3.1 AUTOSAR OS
AUTOSAR OS
为实时应用提供了所有基本服务，即中断处理、调度、系统时间和时钟
同步、本地消息处理，以及错误检测机制。所有服务都隐藏在良好定义的
API
之后。应用
与
OS
和通信层的连接只通过
API
。
AUTOSAR OS
的基本特征包括：
·
静态配置
·
能够推断实时系统性能
·
提供基于优先级的调度策略
·
提供运行时保护功能（存储、计时等）
·
可宿主在低端控制器上，并且不需要其他资源
它包含以下几个方面：
·
实时操作系统
在嵌入式汽车
ECU
中的实时操作系统构成软件动态行为的基础。它管理任务和事
件的调度，不同任务间的数据流，并且提供监控和错误处理功能。
但是，在汽车系统中，对操作系统的需求集中在特定领域。所使用的操作系统必须
高效运行并且所占存储空间小。
在多媒体和远程信息处理应用中，操作系统提供的特征集以及可用计算资源有很大
不同。在纯粹的任务管理之上，
OS
中还包含了复杂的数据处理（例如，流、快速文件
系统等）、存储管理甚至图形用户接口。
汽车
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
如下表：
·
静态定义的调度
在许多应用中需要静态定义一组互相关联的任务的活动。这用于在基于数据流的设
计中保证数据一致性，与时间触发的网络同步，保证正确的运行时定相，等等。
时间触发的操作系统通常作为这个问题的解决方法。然而，时间只是简单的事件，
所以任何事件触发的
OS
，包括
OSEK OS
，会在汽车电子控制单元实现一个用于静态
调度实时软件的调度器。
·
监控功能
监控功能在适当的执行阶段检测错误，不是在错误发生的时刻。因此，监控功能是
在运行时捕捉失效，而不是预防故障。
·
保护功能
AUTOSAR
概念需要多来源的
OS
应用共存在同一处理器中。为了防止这些
OS
应
用之间意想不到的交互，需要提供保护机制。
·
计时器服务
计时器服务为应用和基础软件提供软件计时器。
计时机制的核心已经由
OSEK OS
的计数器和闹钟提供。如果要提供通用的
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
