rCdednc
BSW的作用
我们知道引入AUTOSAR软件架构的目的是为了提供一套优秀的底层代码库，使OEM在开发上层应用层软件的时不应考虑下层繁多的不同ECU型号，从而使汽车软件开发更加标准化、规范化、安全化、快速化和经济化。为了实现该目标，需要把这些不同型号的ECU封装起来，对外提供统一的接口，供上层软件开发时调用，BSW就是起这个作用的。
BSW的结构
在上篇文章中我们知道BSW又可以分成MCAL,ECUAL,SAL,CD四层，如下图所示每一层又提供不同的服务，下面将依次来介绍。
包含MCU中内部外设的驱动（Microcontroller Drivers,Memory Drivers），以及使用MCU内存映射的外部设备的驱动（Communication Drivers,I/O Drivers），用来对MCU内部设备和映射了MCU外部设备的内存进行访问，是对MCU芯片的抽象和封装，从而使上层软件与微处理器型号无关。rCdednc
用于驱动模拟及数字I/O信号，如ADC, PWM，DIO。
通信驱动(Communication Drivers)
控制设备芯片内存（如片内Flash、EEPROM）及外部映射设备（外置Flash）。
微处理器驱动(Microcontroller Drivers)
驱动如看门狗（Watchdog）、时钟模块（Clock Unit）并负责RAM测试及对微控制器抽象层内部设备和映射的微控制器抽象层外部设备的内存访问等功能。
包含ECU板上外部设备的驱动，内部设备与外部设备的接口(I/O)，是对ECU上包括主芯片MCU在内的所有设备的封装，使上层软件与ECU硬件设计无关。
ECU上不光有主芯片，还有其他的一些设备（比如外置存储，外置看门狗等），这些设备其实也是要通过主芯片控制的，比如外置看门狗，就需要和主芯片相连接，由主芯片的接口去配置它。因此，其底层还是需要MCAL的支持。
I/O硬件抽象层(I/O Hardware Abstraction)rCdednc
-
通过I/O硬件抽象中的信号接口来访问不同的I/O设备rCdednc
-
对电流、电压、频率等I/O信号进行封装传输rCdednc
-
对上层的应用软件层隐藏下层的ECU硬件rCdednc
通信硬件抽象层(Communication Hardware Abstraction)
通信硬件抽象将微控制器及板上所有的通信信道都进行了封装，并对CAN、FlexRay、LIN、MOST等通信方式进行了抽象的定义。
内存硬件抽象层（Memory Hardware Abstraction）rCdednc
将片内、板上的内存资源进行统一封装，如对片内EEPROM和片外的EEPROM都提供了统一的访问机制。
车载设备抽象层(On-board Hardware Abstraction)rCdednc
对ECU上特殊的一些外设进行封装，如WatchDog以及时钟等。
服务层是将下层的各种功能统一汇总到这里，即将所有与硬件相关的功能都抽象成一个个具体应用服务，比如服务层中的COM通信服务，就是将下层的CAN，LIN，串口通信抽象成更高层次的API，这样上层软件在调用API 时就不需要考虑具体的通信方式是CAN还是LIN等。
通信服务（Communication Services）
包括CAN、LIN、FlexRay在内的整车网络系统、ECU网络及软件组件内的访问进行了统一封装，模块则通过通信硬件抽象层进行通信：
将微控制器内外内存的访问进行统一封装，而NVRAM管理器提供了一个RAM镜像，来支持数据的快速读取。
为数据的保存、加载、校验保护、验证以及安全存储提供了统一的机制
系统服务是一组可以由所有层次模块使用的模块和功能。例如实时操作系统（包括中断管理、资源管理、任务管理等）、错误管理器和库功能等。
包含下图所示功能：rCdednc
AUTOSAR OS为实时应用提供了所有基本服务，即中断处理、调度、系统时间和时钟同步、本地消息处理，以及错误检测机制。所有服务都隐藏在良好定义的API之后。应用与OS和通信层的连接只通过API。
AUTOSAR OS是在继承OSEK/VDK OS和吸收RTOS基础上建立起来的，下面分别介绍这两种操作系统和AUTOSAR OS的关系。
在嵌入式汽车ECU中的实时操作系统构成软件动态行为的基础。它管理任务和事件的调度，不同任务间的数据流，并且提供监控和错误处理功能。
但是，在汽车系统中，对操作系统的需求集中在特定领域。所使用的操作系统必须高效运行并且所占存储空间小。
在多媒体和远程信息处理应用中，操作系统提供的特征集以及可用计算资源有很大不同。在纯粹的任务管理之上，OS中还包含了复杂的数据处理（例如，流、快速文件系统等）、存储管理甚至图形用户接口。
汽车OS的典型领域涵盖了调度和同步的核心特征。在AUTOSAR中，上面讨论的附加特征在OS的范围之外，其他WP4.2.2.1工作包（例如SPAL）涵盖了这些特征。在AUTOSAR的体系结构约束之下不可能把其他OS（例如，QNX、VxWorks和Windows CE等）的特征集合集成到整体的OS/通信/驱动结构中。因此，AUTOSAR OS只考虑核心特征。
时间触发操作系统在汽车电子控制单元实现了一个用于静态调度实时软件的调度器。
另外，操作系统为实时应用提供了所有基本服务，即中断处理、调度、系统时间和时钟同步、本地消息处理，以及错误检测机制。
所有服务都隐藏在良好定义的API之后。应用与OS和通信层的连接只通过API。
对于特殊的应用，操作系统能够配置为只包含该应用需要的服务。因此操作系统的资源需求尽量少。
OSEK/VDK操作系统广泛应用于汽车工业，并且已经证明了可以在现代车辆的所有ECU类型中使用。OSEK OS引入的概念被广泛地理解，汽车工业领域在设计基于OSEK OS的系统方面有多年的经验。
OSEK OS是一个事件触发的操作系统。这为基于AUTOSAR的系统的设计和维护提供了高度的灵活性。事件触发使得可以自由地选择在运行时驱动调度的事件，例如角反转、局部时间源、全局时间源、错误出现等等。
由于这些原因，AUTOSAR OS的核心功能必须基于OSEK OS。OSEK OS特别提供了以下特性以支持AUTOSAR：
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如下表：rCdednc
在许多应用中需要静态定义一组互相关联的任务的活动。这用于在基于数据流的设计中保证数据一致性，与时间触发的网络同步，保证正确的运行时定相，等等。
时间触发的操作系统通常作为这个问题的解决方法。然而，时间只是简单的事件，所以任何事件触发的OS，包括OSEK OS，会在汽车电子控制单元实现一个用于静态调度实时软件的调度器。
监控功能在适当的执行阶段检测错误，不是在错误发生的时刻。因此，监控功能是在运行时捕捉失效，而不是预防故障。
AUTOSAR概念需要多来源的OS应用共存在同一处理器中。为了防止这些OS应用之间意想不到的交互，需要提供保护机制。
计时机制的核心已经由OSEK OS的计数器和闹钟提供。如果要提供通用的软件计时，一些补充特性需要添加到AUTOSAR OS。
BSW调度器是系统服务的一部分，因此它向所有层次的所有模块提供服务。但是，与其它BSW模块不同，BSW调度器提供了集成的概念和服务。BSW调度器提供方法用以：
集成者的任务是应用所给的方法（AUTOSAR OS提供的），在特定项目环境中以良好定义和有效的方式把BSW模块装配起来。
这也意味着BSW调度器只是使用AUTOSAR OS。它与AUTOSAR OS调度器并不冲突。
-
BSW模块的BSW模块描述rCdednc
-
BSW调度器的配置rCdednc
1、ECU状态管理器，控制AUTOSAR BSW模块的启动阶段，包括OS的启动；
ECU状态管理器是一个基本软件模块，管理ECU的状态（OFF、RUN、SLEEP），以及这些状态之间的转换（过渡状态：STARTUP、WAKEUP、SHUTDOWN）。详细地，ECU状态管理器：rCdednc
-
负责初始化和de-initialization所有基本软件模块，包括OS和RTE；rCdednc
-
在需要时与所谓的资源管理器（例如，通信管理器）协作，关闭ECU；rCdednc
-
管理所有唤醒事件，并在被要求时配置ECU为SLEEP状态。rCdednc
为了完成所有这些任务，ECU状态管理器提供了一些重要的协议：rCdednc
-
RUN请求协议，调整ECU是保持活动状态还是准备关闭，rCdednc
-
唤醒确认协议，从“不稳定的”唤醒事件中区分出“真正的”唤醒事件，rCdednc
-
时间触发的增多非工作状态协议（Time Triggered Increased Inoperation - TTII），允许ECU更多地进入节能的休眠状态。rCdednc
ECU状态管理器必须支持独立的预处理动作和过渡，以启动ECU或将其转换到低功耗状态（例如，休眠状态/备用状态）。通过良好使用ECU状态管理器的特性和能力，此模块能够用于执行电源消耗的预定义策略，因此提供了对ECU的有效能源管理。
ECU状态管理器的特性和优势包括：rCdednc
-
初始化和关闭基本软件模块。rCdednc
-
ECU主要状态的标准化定义。rCdednc
-
时间触发的更多非工作状态。rCdednc
2、通信管理器，负责网络资源管理；
通信管理器收集并协调来自通信请求者（用户）的访问请求。
通信管理器的目的是：rCdednc
-
简化通信协议栈的使用。包括通信栈的初始化，以及简单的网络管理。rCdednc
-
调整ECU上多个独立软件组件的通信栈（允许发送和接收消息）的可用性。rCdednc
-
暂时禁止发送消息以阻止ECU（主动地）唤醒物理通道。rCdednc
-
通过为每个物理通道实现一个状态机来控制ECU的多个物理通道。rCdednc
-
可以强制ECU保持物理通道处于“silent 通信”模式。rCdednc
-
分配所请求的通信模式需要的所有资源，简化资源管理。rCdednc
通信管理器定义了“通信模式”，表示一个特定的物理通道对于应用是否可用，以及如何使用（发送/接收，只接收，即不发送也不接收）。
3、看门狗管理器，基于应用软件的生存状态触发看门狗。
看门狗管理器是AUTOSAR（服务层次）的标准化基本软件体系结构的基本软件模块。它监控与计时约束有关的应用执行的可靠性。
分层体系结构方法使得应用计时约束和看门狗硬件计时约束分离。基于此，看门狗管理器在触发看门狗硬件的同时提供了对一些独立应用的生存监控。
看门狗管理器提供以下特性：rCdednc
-
监督多个处于ECU的单独应用，这些应用有独立的计时约束并且需要特别监督运行时的行为和生存状态。rCdednc
-
每个独立的受监控实体都有故障响应机制。rCdednc
-
可以关闭对单独应用的监督，而不会违反看门狗触发（例如，对于禁止的应用）。rCdednc
-
通过看门狗驱动触发内部或外部、标准或窗口，看门狗。（internal or external, standard or window, watchdog）对内部或外部看门狗的访问由看门狗接口处理。rCdednc
-
根据ECU状态和硬件性能选择看门狗模式（Off Mode, Slow Mode, Fast Mode）。rCdednc
通过提供复杂传感器和执行器的驱动，整合具有特殊目的且不能用MCAL进行配置的非标准功能模块，将该部分功能嵌入到AUTOSAR基础软件层中，从而实现处理复杂传感器以及执行器的特定功能和时间要求，使重要的应用模块可以直接访问硬件资源，例如: 喷油量控制, 胎压监测。
复杂驱动（CCD）层跨越于微控制器硬件层和RTE之间，复杂驱动程序跟单片机和ECU硬件紧密相关。其上层程序接口是根据AUTOSAR指定并且实施的；其下层程序接口受标准接口程序的限制。复杂驱动可以使用特定的中断或是复杂的微控制器外设（如PCP/TPU）来直接访问微控制器，从而实现对复杂传感器的评估和执行器的控制，利用中断、TPU、PCP等来实现实时性高的传感器采样、执行器控制等功能。
最后引用Vector资料中的一个例子，说明物理信号的变化如何在AUTOSAR软件中体现。
1-3步是信号在硬件中的“流动”情况：假设右门状态有变化，传感器会感知该变化，将检测到的电流信号通过ECU转换成电压信号，之后电压信号被微控制器外围设备感知，至此硬件传递完毕。反应在各硬件上的软件状态如4-6步描述，处在应用层的门控制模块会通过Rte-Read_DoorRight_IsOpen()、Rte_Read_Door_state()两个函数从RTE下层的BSW 读取数据，ECU抽象层通过ADC-get()从更底层读取数据。
rCdednc
最前沿的电子设计资讯
