[AutoSAR] BSW模块的服务层，重点关注OS部分

BSW的结构
BSW又可以分成MCAL,ECUAL,SAL,CD四层

如下图所示每一层又提供不同的服务

看一下服务层

功能：

服务层是将下层的各种功能统一汇总到这里，即将所有与硬件相关的功能都抽象成一个个具体应用服务，比如服务层中的COM通信服务，就是将下层的CAN，LIN，串口通信抽象成更高层次的API，这样上层软件在调用API 时就不需要考虑具体的通信方式是CAN还是LIN等。

结构：

通信服务（Communication Services）

包括CAN、LIN、FlexRay在内的整车网络系统、ECU网络及软件组件内的访问进行了统一封装，模块则通过通信硬件抽象层进行通信：

对上层的应用软件层隐藏了协议以及报文属性

提供了统一的总线通信接口供应用软件层调用

提供了统一的网络管理服务

提供了统一的诊断通信接口

(存储器)内存服务(Memory Services)

将微控制器内外内存的访问进行统一封装，而NVRAM管理器提供了一个RAM镜像，来支持数据的快速读取。

以统一的格式为上层的应用软件层传输非易失性数据

抽象了内存地址以及属性

为数据的保存、加载、校验保护、验证以及安全存储提供了统一的机制

系统服务（System Services）

系统服务是一组可以由所有层次模块使用的模块和功能。例如实时操作系统（包括中断管理、资源管理、任务管理等）、错误管理器和库功能等。

包含下图所示功能：

AUTOSAR OS

AUTOSAR OS为实时应用提供了所有基本服务，即中断处理、调度、系统时间和时钟同步、本地消息处理，以及错误检测机制。所有服务都隐藏在良好定义的API之后。应用与OS和通信层的连接只通过API。

基本特征包括：

静态配置

能够推断实时系统性能

提供基于优先级的调度策略

提供运行时保护功能（存储、计时等）

可宿主在低端控制器上，并且不需要其他资源

AUTOSAR OS是在继承OSEK/VDK RTOS基础上建立起来的。

在嵌入式汽车ECU中的实时操作系统构成软件动态行为的基础。它管理

• 任务和事件的调度
• 不同任务间的数据流
• 提供监控和错误处理功能

在AUTOSAR的体系结构约束之下不可能把其他OS（例如，QNX、VxWorks和Windows CE等）的特征集合集成到整体的OS/通信/驱动结构中。因此，AUTOSAR OS只考虑核心特征。汽车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。新的需求作为功能扩展来集成。

静态定义的调度

在许多应用中需要静态定义一组互相关联的任务的活动。这用于在基于数据流的设计中保证数据一致性，与时间触发的网络同步，保证正确的运行时定相，等等。

时间触发的操作系统通常作为这个问题的解决方法。然而，时间只是简单的事件，所以任何事件触发的OS，包括OSEK OS，会在汽车电子控制单元实现一个用于静态调度实时软件的调度器。

监控功能

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

保护功能

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

计时器服务

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

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

BSW调度器

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

BSW调度器只是使用AUTOSAR OS。它与AUTOSAR OS调度器并不冲突。

模式管理

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

1、ECU状态管理器，控制AUTOSAR BSW模块的启动阶段，包括OS的启动；
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、通信管理器，负责网络资源管理；

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

通信管理器的目的是：

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

调整ECU上多个独立软件组件的通信栈（允许发送和接收消息）的可用性。

暂时禁止发送消息以阻止ECU（主动地）唤醒物理通道。

通过为每个物理通道实现一个状态机来控制ECU的多个物理通道。

可以强制ECU保持物理通道处于“silent 通信”模式。

分配所请求的通信模式需要的所有资源，简化资源管理。

通信管理器定义了“通信模式”，表示一个特定的物理通道对于应用是否可用，以及如何使用（发送/接收，只接收，即不发送也不接收）。

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

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

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

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

监督多个处于ECU的单独应用，这些应用有独立的计时约束并且需要特别监督运行时的行为和生存状态。

每个独立的受监控实体都有故障响应机制。

可以关闭对单独应用的监督，而不会违反看门狗触发（例如，对于禁止的应用）。

通过看门狗驱动触发内部或外部、标准或窗口，看门狗。（internal or external, standard or window, watchdog）对内部或外部看门狗的访问由看门狗接口处理。

根据ECU状态和硬件性能选择看门狗模式（Off Mode, Slow Mode, Fast Mode）。

附录 实时操作系统RTOS 和 非实时通用OS

我们操作系统分位：非实时，实时。
目前单片机主要用前后台OS和时间触发OS（参考：https://ishare.iask.sina.com.cn/f/bvd7DUrQBpL.html）

实时操作系统RTOS和非实时通用OS两者之间最显着的区别是它们如何处理任务。 通用操作系统专注于在最短的时间内进行尽可能多的计算，而实时操作系统强调具有可预测的响应时间

实时操作系统用于更专业的领域，它的任务响应时间比（在给定时间内处理指令的能力）更快。 例如扫描设备的任务处理就要用到实时操作系统，并且内部监视功能可以看到的任务的实时变化。

大多数通用操作系统使用时间共享架构，其中每个任务被分配一小段时间，在切换到另一任务之前执行其指令。 切换过程尽可能快，从而使用户感觉不到任务执行被延迟。

RTOS也使用这种设计，但是任务密度低得多，以确保处理器永远不会过载，从而可以增加响应时间。 用于RTOS的另一种设计是事件驱动架构。 在此设计中，系统仅在发生事件或中断时才切换任务。

相对来说，RTOS的代码结构更严格，因为代码需要始终一致地执行。 通用OS就不需要太专注于一致性，因为响应时间在其应用中不是非常重要。
总结

1、OS专注于计算吞吐量，而RTOS专注于快速的响应时间。

2、OS可以被广泛使用，而RTOS通常只嵌入在需要实时响应的设备中。

3、OS使用分时设计以允许多任务的同时运行；RTOS使用分时设计或者事件驱动设计。

4、与OS相比，RTOS的编码更严格

附录 事件触发（TaskTrigger）与时间触发系统（Time Trigger）

时间触发系统，当多个中断同时存在系统中时，会出现多个中断相互嵌套，会存在某种原因导致中断丢失 。当事件触发改为时间触发时，可以有效管理中断触发，使之有序进行。

时间触发操作系统在汽车电子控制单元实现了一个用于静态调度实时软件的调度器。
　
长期以来，在嵌入软件领域里，一直采用基于优先度的调度（Scheduling）方法。不仅限于汽车领域，μITRON平台操作系统以及VxWorks等目前在嵌入软件领域使用的实时操作系统也大多采用这种基于优先度的调度方法。这是在圈内很有名的事件，以前美国NASA的火星探测器“Mars Pathfinder”曾因软件的漏洞而一度无法进行控制。这是基于优先度的调度特有的问题（优先度逆转现象，Priority Inversion）所导致的。

优先度逆转现象在采用带有“优先度继承功能”的调度器（Scheduler）后即可避免。该功能目前已预装到嵌入式Linux中。

除了此前占主流的基于优先度的调度，对各任务分配一定时间间隙（Slot）的“时间触发器型调度”也越来越多地得到采用。如果在ECU之间的通信中出现了像FlexRay那样的时间触发器型操作系统，那么ECU内部的软件（任务）调度就将采用与TDMA型通信兼容性较好的时间触发器型。

理由不只是这一点。一个契机是ECU整合的潮流。ECU整合指的是，为了降低汽车的成本以及实现轻量化，采取减少ECU数、并予以整合的措施，但这种ECU整合化的趋势甚至开始对ECU内部的操作系统带来影响。

ECU的整合有多种方式，常见的是试图将多个不同供货商开发的ECU整合到单一ECU中。这种情况下，不同企业开发的任务将在单一ECU中工作。将多个系统结合在一起时，经常会发生单独工作时没出现过的新问题。如果采用时间触发器型的调度，很容易保证某个特定任务不在时间方面对其他任务带来不良影响。从道理上说，由于容易设置时间“间隔（Barrier）”，因此，ECU的整合也就容易推进。这种观点不是说“由于出现了FlexRay，所以操作系统采用时间触发器型”，而是“为了降低成本而导入时间触发器型”。

在车载软件的标准规格“AUTOSAR”中，以时间触发器型为代表的“时间保护功能（Time Protection）”已作为性能指标进行了规定。AUTOSAR操作系统中有“Scalability Class（SC）”这一概念，以往采用普通的基于优先度的调度的操作系统被规定为“SC1”。时间触发器型等时间保护功能为“SC2”。此外，使某个任务不能访问其他任务的存储区的“内存保护功能（Memory Protection）”被规定为“SC3”，具备时间保护及内存保护两种功能的操作系统被规定为别的“SC4”。这方面的技术被称为“分区（Partitioning）技术”，汽车的功能安全标准“ISO 26262”也参照了该技术。

在采用虚拟存储的操作系统中，当然内存保护功能会发挥作用，但像汽车控制系统ECU所采用的那种实时操作系统一般不是虚拟存储方式，CPU也不采用MMU以及配备TLB的微处理器。不过，要想让AUTOSAR的SC3那样的内存保护功能起作用，CPU只需具备MPU（内存保护单元）。

日前，笔者就法国政府下属研究机构CEA LIST与美国德尔福（Delphi）的法国法人联手开发的车载用实时操作系统“PharOS”进行采访时了解到，这种PharOS不仅在时间保护功能等方面支持AUTOSAR的SC1～SC4，甚至还提出了更高的“SC5”的新SC方案（参阅本站报道）。

虽然目前在实时操作系统中基于优先度的调度成了主流，但据说其基础技术“RMS（Rate Monotonic Scheduling）”实现实用化以前的实时系统（Real Time System）却是“以时间触发器型的调度为主流”（名古屋大学教授高田广章）。

OSEK OS

What is OSEK

A specification for an RTOS

•With standard software interfaces (OS API)

•Including intertask & interprocessor communication (COM)

•Including network management (NM)

•Including the language used to statically declare OS elements used in an application – OSEK Implementation Language (OIL)

在1995年召开的研讨会上，众多的厂商对OSEK和VDX的认识达成了共识，产生了OSEK/VDX规范(1997年发布)，本文简称OSEK规范。它主要由四部分组成:操作系统规范(OSEK Operating System,OSEK OS)、通信规范(OSEK Communication , OSEK COM )、网络管理规范( OSEK Net Management, OSEK NM)和OSEK实现语言(OSEK Implementation Language,OIL)。此后，各软件生产厂商都相继推出了符合OSEK规范的产品，比较典型的有WINDRIVER公司的OSEKWorks,ETAS公司的ERCOSEK,MOTOROLA的OSEKturbo和美国密西根大学的EMERALDS-OSEK等。随着该规范应用的不断深人，其结构和功能不断完善和优化，版本也不断升级和扩展。目前OSEK OS2. 2 , OSEK COM2. 3 , OSEK NM2. 3和OIL2. 3已经提交ISO审议，即将成为一个国际标准。

参考：https://blog.csdn.net/m0_37891624/article/details/122699268

1 OSEK/VDX标准：实时操作系统（OSEK OS），通讯子系统（OSEK-COM），网络管理系统（OSEK-NM）。

2 OSEK是静态的操作系统，不支持在运行过程中动态改变，不需要进行动态的内存管理。

3 OSEK OS中重要的资源包括任务，时间，中断。

OSEK定义了三种处理层次：中断，调度器，任务。
调度器分为非抢占式，全抢占式，混合抢占式；其实任务包括基本任务和扩展任务；优先级遵守上图所示。

1）任务分类
BCC1：基本任务，所有任务有不同的优先级，每个任务仅仅可以激活一个需求。

BCC2：BCC1+每个优先级可以实现多个任务，多任务的需求激活被允许。

ECC1:BCC1+扩展任务。

ECC2：ECC1+每个优先级可以实现多个任务，多任务的需求激活被允许。

2）任务的状态机
扩展任务状态机：Running State运行结束之后，会跳到Suspended State；Running State 被高优先级的task打断之后，进入 Ready State；Running /waiting/ready state 转换通过系统的EVENT实现。

基本任务状态机：Running State运行结束之后，会跳到Suspended State；Running State 被高优先级的task打断之后，进入 Ready State。

3）中断类型

  ISR 1 : 这个类型中断不支持操作系统的服务。

  ISR 2：这个类型的中断支持操作系统的服务，调用API。

4）EVENT 机制

  该机制是同步，提供扩展任务状态机转换的条件（wait和release）。

5）Resource 管理

   A）两个task在同一时间不能占用相同的资源。

   B） 优先级不能翻转。

   C)   死锁不能发生。

   D）在等待的状态访问资源是没有结果。

6）天花板协议可以解决资源翻转和死锁的问题

A) Task T1和Task T4占用相同的信号S1，T4先执行，由于T1的优先级比T4高，T4进入ready 状态，T1进行running状态，由于T1获取S1时被拒，T1会进入waiting状态，直到T4执行完成之后，释放S1之后，T1才会被执行，这样就造成了task的优先级翻转。

B）Task T1获取S1，等待event触发，在此期间T2获取S2，T1的event发生了，T1获取S2被拒，T1进入waiting状态，T2获取S1被拒，T2也进入waiting状态，T1和T2产生死锁结果。

C）天花板协议：在系统初始化之后，每个资源都拥有静态的天花板优先级，天花板优先级比所有的task优先级都高，如果task获取了一个资源，这个task的优先级上升到这个资源的优先级，在系统中运行，当这个task释放了该资源时，优先级会复位到本身的task的初始化定义的优先级。
7） 系统启动流程
8）API服务的应用

参考

https://www.eet-china.com/mp/a70185.html
http://www.360doc.com/content/17/0704/13/37015604_668684790.shtml
https://www.cnblogs.com/iable/p/4206843.html
https://blog.csdn.net/m0_37891624/article/details/122699268