AUTOSAR-OS上层需求总结

        本文是《Requirements on Operating System》这篇官方文档的学习笔记，主要记录了一些AUTOSAR对操作系统(OS)相关的需求准则。

1 RTOS相关要求（Real-Time Operating System）

1.1 [SRS_Os_00097]

        操作系统（OS）的API需要向后兼容OSEK OS，这主要时为了兼容已有的软件，降低软件移植的工作难度。

1.2 SRS_Os_11001

        OS需要提供分区功能，以保证故障隔离和故障恢复功能。

        AUTOSAR允许在一个CPU上运行多个应用程序，而OSEK没有对其进行分区管控，也就无法有效进行有效的故障隔离。一个程序的故障，可能会连锁引发另一个程序的故障或崩溃。最简单的例子就是内存非法访问导致整个板级崩溃，所谓城门失火，殃及池鱼。

        OSEK关于OS的可操作对象，已有以下几个方面：

        ① 任务（Task)和中断服务函数（ISR)是受OS管控的可执行对象；

        ②在静态配置时，分配给Task和ISR的标准资源；

        ③事件（Event）可以由任何Task或ISR发起，但等待和清除该事件的任务或ISR由静态配置来限制；也就是说，事件的触发是全局的，不受限制；但事件的处理，必须在静态配置特定的任务或ISR中来进行；

        ④定时器(Alarms)可以由任何Task或ISR中来处理；

        AUTOSAR在此进出上进行了拓展，新增了调度表的概念。总的来看，OS需要管控的对象就包括任务（Tasks），中断服务函数（ISRs)， 定时器（alarms)，调度表（Schedule tables)以及其他资源。如果这些OS管控对象的权限都是全局的，那么牝鸡司晨、狗拿耗子等乌龙事件发生的可能性就会变大。

        所以，OS需要提供一种分组机制，使得特定的OS对象归属于同一组，这种分组被称为系统应用（OS-Application)。所谓分区，也是建立在这个分组的基础上的。这有点类似于进程与线程的概念。进程参与资源划分，并可以同时下辖多个线程，这些线程共享该进程从OS申请到的资源。      

        OS-Application的概念主打一个资源隔离，当一个OS-Application出现fault时，其故障处理可能需要停止其管辖下的所有OS对象的执行。谁犯错崩溃了自己倒霉，不会苦了其他兄弟。此外，这样也利于内存保护的开展。

1.3 [SRS_Os_11018]

        OS需要提供中断屏蔽功能，该功能StartOS()调用前和ShutdownOS()调用后都要可以使用。也就是说，中断屏蔽的功能的应用是全过程的，中断相关的初始化要早于OS，SPAL（Standard Peripheral Abstraction Layer)驱动在OS运行前中后都需要这个功能的支持。

1.4 [SRS_Os_11019]

        AUTOSAR OS的生成工具需要支持中断向量表的配置和自动生成，且中断向量表必须由该工具生成。

2 静态定义调度（Statically Defined Scheduling）

        在很多应用程序中，静态定义彼此相关的一组任务的触发(activation)很有必要。这有利于保证数据流的一致性，保证时序上的同步，以及准确的运行相位等。

        说直白点，就是希望可以有一种机制，可以按严格的时序来触发每个任务的运行，显然可以用一个时间相关事件来实现这个效果。其最终产物，就是静态任务调度表。

2.1 [SRS_Os_00098]

        OS需要提供基于时间表的静态可配置的调度表作为可选服务。调度表本身可以理解为一个大周期时间窗口，其内包含多个任务，在每一固定时刻触发特定任务的执行，这样既有效，也容易理解。直白来说，周期任务通过调度表的方式来实现，可以依据任务之间的关系来实现同步或错峰执行。

2.2 [SRS_Os_00099]        

         OS需要提供一种机制，以实现在不同调度表间切换执行。例如，程序的运行可能有多个状态(e.g. init, start-up, pre-start, normal operation,diagnosis, pre-sleep, shut down)，这些不同状态可能对应着不同的调度表，即对应着特定的一组任务。当状态机切换时，可能需要伴随调度表的切换。

2.3 [SRS_Os_11002]

        OS需要提供保证调度表的处理与全局系统时间保持同步的方式，并支持即时同步（immediate/hardsynchronization)和渐进同步（gradually adapting /smooth synchronization）两种同步方式。

        简单来说，就是调度表本身的时间窗口起点，需要具有和系统时间同步对齐的能力。这样就可以保证调度表中的每个任务都能和系统时间实现同步。

3 监控功能

3.1 [SRS_Os_11003]

        OS需要支持堆栈溢出监测功能，监测对象包括Task和ISR所使用的堆栈。虽然OS提供的堆栈检测通常不是绝对安全（不能百分百地保证监测到堆栈溢出情况）。对于那些不支持硬件级别内存保护的产品来说，OS级的堆栈监测仍是一个相对有效的备选方案。

4 保护机制  

        AUTOSAR要求同一处理器上的多个OS-Application之间不得互相异常干涉，这就需要OS提供一种隔离机制。总的来说，主要分为两种情形：

        ① 对于一个安全关键型系统，如果单个OS-Application的安全用例（Safety-Case）开发可以集成到一个外界安全的环境下，则开发就会变的简单很多。这个安全环境，是指该环境中的一个OS-Application发生的故障不会波及到其他不相关的OS-Application；

        ② 对于每个OS-Application来说，都应保证其内部引发的故障，不会引发CPU全局的板级故障；

        简单来说，就是人人为我，我为人人，自己的故障自己消化，别苦了兄弟。当然，自己最好也别发生故障。

4.1 内存保护要求

4.1.1 [SRS_Os_11005]

        OS需要提供对OS-Application进行内存分区的功能，即保证一个OS-Application无法改写其他OS-Application的内存区域。

当多个 OS-Application驻留在同一CPU上时，如果这些OS-Application的内存区域可以被全局代码写入，则可能会遭到外来的故障影响，形成故障传播。例如，一个OS-Application的任务堆栈发生溢出，破坏了另一个OS-Application的静态数据，使得其发生崩溃。

        与堆栈溢出监测功能不同，内存保护要求在运行时防止这种内存非法访问的发生。显然，如果实现了内存保护，也即顺便满足了堆栈溢出监测功能的需求。而对内存区域的写保护，需要对应的硬件功能支持。

4.1.2 [SRS_Os_11006]

        OS需要支持在OS-Application内部的任务和ISR之间利用共享内存进行数据通信。

        共享内存具有很高的效率（例如全局变量），但无限制的全局访问也破坏了内存保护机的理念。所以，OS要提供 OS-Application级别的本地共享内存，以供其内部的任务或ISR进行数据交互。

        简单来说，就是将共享内存的范围限制在一个OS-Application内，该内存区域对于其他OS-Application来说是不可访问的。

4.1.2 [SRS_Os_11007]

        OS需要支持OS-Application执行共享代码段。这其实也就意味着，内存保护主要针对的是可写的数据段。对于只读的代码段，必要的全局共享可以减小代码空间占用，降低软件维护的难度。

4.1.3 [SRS_Os_11000]

        OS需要支持对特定内存段（memory section)级别的内存保护，以保证OS-Application的内存区域无法被另一个OS-Application访问。说白了，就是要限制任务和中断服务程序的访问范围，非其必要区域，就别访问，读也不行。

4.2 时间保护要求

4.2.1 [SRS_Os_11008]

        OS不允许任何一个OS-Application的超时故障传播到其他同核的OS-Application，超时故障主要包括两种：

        ① 程序执行启动超时；

        ②程序执行结束超时；

        大概类似，火车开点推迟了或火车晚点到站两种超时，而该火车的超时不应该影响到其他列次的运行。这就需要OS对系统中每个特定的任务或二类中断（category 2 ISR)进行时间管控和调度分析。这就涉及到任务/二类中断需要运行的频率、运行的时间以及其占用的资源和资源占有时间等相关的分析。

        时间保护的必要性主要体现在以下两个方面：

        ① 早发现早治疗，减少错误成本；

        ② 隔离故障传播，使其局限在当前故障发生的OS-Application范围内，不会影响到核上其他应用，还是那句话，别苦了兄弟。

4.3 系统服务保护要求

        程序运行时，OS必须保护其自身及受其调度的OS-Application的完整性。

4.3.1 [SRS_Os_11009]

        OS必须保证不会因为不恰当的系统调用而产生系统崩溃。由于同核上的各OS-Application都受控于同一个OS，OS自身若因系统调用引发故障，必将波及全核。

        所以，对于系统调用有以下两点要求：

        ① 每个系统服务的行为都必须是已定义的，即不可出现未定义的操作；

        ② OS要防止来自错误上下文中的错误的系统调用，这些不恰当的系统调用可能使得OS进入未知的状态；

        直白点来说，系统调用是OS给应用层调用的系统服务接口，OS既要保证这些系统服务本身行为正确，不会引起未知故障，也要阻止应用层在错误的上下文中调用相关的系统服务。

4.3.2  [SRS_Os_11010]

        OS必须禁止一个OS-Application非法修改不属于自己系统对象。例如，一个OS-Application通过系统调用不恰当地关掉了一个alarm，而这个alarm是用于触发另一个OS-Application的。为了从根本上杜绝这种可能，需要对一个OS-Application可修改的系统对象资源进行管控。

        这也就意味着需要在配置时，对OS-Application的资源访问范围进行明确定义，其目的在于保证各OS-Application之间的独立性。如果两个OS-Application之间存在共享资源，则需要在配置时明确定义。

4.3.3 [SRS_Os_11011]

        OS应禁止OS-Application修改受OS管控的控制寄存器。例如，OS-Application应被禁止访问MCU状态寄存器（MCU status registers)和内存保护寄存器（memory protection registers)，以免破坏OS内部的数据结构。

        该保护机制通常需要MPU的支持，而且还需要MCU本身支持特权/非特权的权限等级功能。

4.3.4 [SRS_Os_11012]       

        OS应提供可拓展的保护机制。保护机制应重复考虑到硬件的支持程度，例如在没有硬件MPU支持的情况下，其他的内存保护措施也是可以接受的；同时应考虑到用户本身的需求，保护措施可以有选择性地只用于那些评估后存在风险的应用程序。

        例如，通过静态分析，某应用程序的最坏执行时间都不会引发超时，那么就没必要一定使用时间保护措施。而对于那些用不执行的死代码（dead code)，其存在具有潜在风险，应予以删除。

4.4 错误保护

        OS需要可以识别违反保护条例的错误的发生，同时还应提供纠错的措施及渠道。但如何纠错，就不是OS的事情了。

4.4.1 [SRS_Os_11013]        

        系统运行时，OS必须能够识别出保护机制相关的错误，并通知给应用程序。

        这个保护相关的错误，主要包括：

        ①非法访问；

        ②超时错误；

        ③非法系统调用；

        ④软件错误陷阱，例如除零和非法指令等；

        OS负责错误侦擦和通知，应用程序则根据错误的类型和数量，对错误进行相关的具体处理。

4.4.2 [SRS_Os_11014]

        当保护机制相关错误发生时，OS需要提供OS，OS-Application及ISR级别的修复措施，而应用程序从中选择合适措施进行故障修复。

        故障的修复措施应该在整个系统层面来定义。例如，当一个任务发生故障时，有的人任务和可以继续执行并尝试修复，有的任务则必须终止执行以降低风险。因此，故障修复措施应根据具体情况来分析和定义。

4.5 定时器服务

        Timer Services主要指向应用或基础软件提供软件定时器服务。

        OSEK通过counters和alarms提供了类似的定时机制。在此基础上，AUTOSAR OS补充了一些要求，以实现更好的通用性。

4.5.1 [SRS_Os_11021]       

        OS应提供标准接口来驱动软件计数器（tick a software counter)

        OSEK没有定义counters和alarms之间的标准接口。AUTOSAR在此基础上统一了接口封装，以便于软件移植。

4.5.2 [SRS_Os_11021]        

        OS应提供一种在一个硬件定时器的基础上建立多个软件定时器的机制。

        由于硬件资源的有限性（硬件定时器的数量有限）或设计的非必要性（节省定时器中断资源、降低中断频率、减少中断干扰），可以通过高分辨率的计数器来驱动低分辨率的软件计数器。        

        例如，可以通过1ms的中断来产生1ms的软件计数器（software counter)，并由这个1ms的软件计数器来驱动产生一个100ms的软件计数器。

        这个需求也意味着必须支持多个counter，AUTOSAR OS SWS中规定了需要支持的counters的数量下限。

4.6 伸缩拓展性

        对于特定的应用程序，OS应该可配置，且只分配该应用需要的服务，从而将整个OS的资源要求压缩到最低。

4.6.1 [SRS_Os_11016]

        应通过可生成工具进行配置，使得OS的实现具有可拓展性。

        OS应该支持以下几种配置：

Class1 : OSEK OS [4] + Planned Schedules         Class2 : Class1 + Timing Protection（时间保护）         Class3 : Class1 + Memory Protection（内存保护）         Class4 : Class1+ Class2 + Class3

        其中，class3和class4都需要硬件的支持，

4.7 应用程序错误处理

        有一些应用程序的内部错误，不会触发保护机制相关的错误，但会导致应用程序进入一个无法自愈的错误状态中。监测此类错误是应用程序本身的责任，但从此类错误中恢复需要与受OS管理的控制线程进行交互。

        因此，OS需要提供一种机制，使得应用程序可以在其上构建起内部恢复机制。

        OSEK对此提供了一些支持。例如，任务可以监测到其内部错误，并终止自身的执行；系统也可以使用定时器机制（alarm mechanism）进行超时控制，实现基于阈值的错误监测；当发现错误后，系统可以关闭运行。然而，OSEK没有提供由OS-Application定义的逻辑应用程序的错误恢复措施。

        以下将引入对OS-Application应用级别和系统级别的控制框架要求。

 4.7.1 [SRS_Os_11022]

         OS应提供终止（terminate）OS-Application运行的机制。

        终止一个OS-Application意味着要终止其所有的下属任务（Task）的运行，在终止该程序的同时，其使用的中断也应该被除能，还需要释放其占有的资源。

        总之是，关于该OS-Application的一切行为都被抹去，且同时不应该影响到该核上的其他OS-Application的正常运行。

 4.7.2 [SRS_Os_11023]

         OS应该提供一种机制，使得被终止的OS-Application可以重新启动。

         AUTOSAR的错误处理模块需要OS能够以一种受控的方式重启一个被终止运行的OS-Application，以便能重新初始化该应用程序。当一个OS-Application内部发生错误时，可能需要重启该应用程序以消除错误。

4.8 多核问题

4.8.1 功能要求

4.8.1.1 [SRS_Os_80001]        

        OS应该可以管理多个紧密相关核组成的CPU簇。当然，着并不意味着所有CPU核心都必须归OS管辖。

        让OS支持多核管理，主要有以下原因：

        ① 利于提高并行处理的效率，这将有利于提高计算性能以实现一些复杂的算法处理；

        ② 利于提高CPU核心的可拓展性，利于软件在不同核心的硬件上移植；

        ③ 允许将AUTOSAR Multi-Core 拓展在当前系统所有物理核资源的基础上建立一个子集，整个子集由OS管控，而其他核则可以运行其他OS实例；

4.8.1.2 [SRS_Os_80003]

        OS的多核拓展应该支持与单核相同程度的可预测性。

        直白点来说，多核环境下，OS应仍能保证系统的实时性，保证程序运行无死锁、无不受控的阻塞（unbounded blocking），这对于车机系统来说，至关重要。

4.8.2 关于AUTOSAR 单系统控制多核的补充描述       

        当谈论AUTOSAR多核环境时，需要有以下几点认识：

        ① OS应能感知到多个核心的存在；

        ② OS应负责多核任务调度；

        ③ 部分系统代码应额能够并发运行，例如使用可重入代码；

        ④ 所有的BSW IDs（例如任务、事件、定时器等的ID）都应是多核范围内全局唯一的；

        ⑤ 若非有保护机制限制，数据段、外设等资源应默认多核全局共享；

4.8.3 关于unbounded blocking的补充描述

        该术语描述的典型实例就是优先级反转（priority inversion），不受控的阻塞即使指该阻塞的发生不受控，无确定性，无法保证系统的实时性。

4.9 运行对象的计算核心分配

        定义多核系统的一个主要问题是运行时对象（runtime object是， 例如task和ISR）的载体是否可以在多核之间动态变化。这其实涉及到核间负载均衡问题，且会影响到代码大小、数据大小、处理速度、响应时间、实时能力等多个方面。

        为了降低复杂度、提高可靠性，AUTOSAR将OS-Application绑定到特定核上执行，或者在任务或ISR级别上定义核的绑定。

4.9.1 [SRS_Os_80005]

        OS-Application（包含task和ISR）应被静态地分配在固定的核心上运行。

        主要有以下几个原因：

        ① 如果任务和ISR可以在运行时切换核心载体，可能会破坏实时性能；

        ② 如果单个OS-Application可以绑定到不同的核心上，则关闭该应用程序的难度将变大；

        ③ 为了满足[BSW00009]和 [BSW00010]的要求，应可以访问各OS-Application的EVENTS和TASKS；

        ④ 多核环境下，OS-Application的开发应避免影响到拓展性（例如不同硬件下核心数目的变化）；

4.10 多核启动系统（Startup of Multi-Core systems）

        多核启动的情形通常如下：

        ① 全局唯一的主核（master core）首先完成启动，其他的核（从属核，slave cores）保持在停止状态（halt state)，等待被主核启动；

        ② 也可以不设主核，所有核在复位后并发启动；

       由于加载（load)和存储（store)操作的时间与总线仲裁及其他硬件环境强相关，不同核心上的启动代码是不可复制的。所以，每个核的boot启动代码都是独立设计的，这就要求在启动过程中进行核间同步。

4.10.1 系统初始化/启动的同步功能

        为了提高硬件的兼容性，有必要在恰当的时间点进行核间同步，以保证软件执行的正确时序。例如，当一个核已开始执行任务，而另一个核还在进行初始化，这显然是不合理的。

        该需求的实现将涉及到诸多依赖条件，包括OS规范、ECU的状态机、硬件环境等。

4.11 多核系统的关闭（Shutdown of Multi-Core systems）

        在系统运行时，若"ShutdownOS"被调用，整个多核系统都应保证能集体关闭。

4.11.1 [SRS_Os_80007]        

        关闭程序应可以由任何核触发。

        如果发生了错误，相关的处理程序可能需要关闭整个系统，每个核都应该拥有该权限。

4.12 多核系统的配置

4.12.1 [SRS_Os_80008]

        OS的配置应该是通用的，多核的。如果需要进行跨核的对象寻址，则必须生成对象ID，且该ID必须具有唯一性。例如，当跨核激活一个任务或触发一个事件时，必须通过该任务或事件的全局唯一ID来实现。

4.12.2 [SRS_Os_80011]

        OS管控的核心数应该支持离线配置，这将有利于在不同核心数量的硬件环境间进行软件移植。

4.13 多核系统的系统服务   

4.13.1 [SRS_Os_80013]

        多核系统调用的行为应与单核系统保持一致。直白点说，就是系统调用接口在多核系统上的表现应该与单核系统上的表现一致。

        例如，在一个多核系统中，一个任务被绑定到其中一个核上，启动该任务的系统调用应该与单核环境保持一致。

4.13.2 [SRS_Os_80015]

        多核环境下，应该提供一种机制来激活不同核心上、不同OS-Application中的任务。

        该机制使得不同项目（例如低成本和高端车辆）的核间任务离线迁移（offline relocation)成为可能。

4.13.3 [SRS_Os_80016]

        事件机制（Event mechanism）应跨核全局有效，即应支持跨核心、跨OS-Application给一个任务发送事件（event）。

        如果一个任务被离线迁移到另一个核心，该机制使得事件机制仍能正常使用。

4.13.4 [SRS_Os_80018]

        应该支持多核间的任务同步机制。

        有多种实现方法可以实现跨核的任务同步，如通过alarm激活跨核任务，或通过同步计数器，或通过使用共享硬件计时器。

4.13.5 [SRS_Os_80020]

        应该提供一种核间数据交换机制，保证独立于硬件的数据一致性，以减少RTE使用该机制时对硬件的依赖性。

4.13.6 [SRS_Os_80021]

        应支持task和ISR级别的核间互斥机制，且该机制不应导致死锁。

4.13.7 [SRS_Os_80022]

        当一个特定的核心无任务执行时，OS应支持该核执行用户选择的操作，例如睡眠等。

        这使得单个核心可以独立于其他核心进入睡眠模式，并可以通过软中断（由OS触发）或硬中断唤醒该核，这对于系统低功耗优化有着极大的意义。

4.13.8 [SRS_Os_80023]

        当某个核心即将无任务需要调度运行时，OS应支持在运行时（runtime)执行可选择的操作，而这些操作可有多种定义，包括预定义的NO_HALT模式，以及供应商自己定义的使得该核心进入HALT状态的软硬件选项。该机制的目的仍是为了低功耗优化。

4.14 Debugging and Tracing

        略。