AUTOSAR Multi-Core OS

[想发财想自由]

本文来自知乎大佬 https://zhuanlan.zhihu.com/p/86074247

0. 多核硬件假设

0.1 CPU核特征

同一片硅上有多个磁芯；
硬件提供了通过软件识别核的方法；
硬件支持固定字节长度的原子级别的读写操作；
硬件支持一些原子级别测试和设置或类似功能，可用于构建核心之间共享的关键区域。
多核拥有共同的指令集；
多核拥有相同的数据表示方法；例如，相同的整型字节尺寸。
如果存在每个核上的缓存，AutoSar要求在硬件或软件上支持RAM缓存的一直性。
为了通知，可以在任意一个核上触发中断/Trap。
0.2 内存特性

所有的核有共享RAM，至少所有的核心可以共享相当大的一部分内存；
所有的核可以共享Flash。但是，如果可以对flash/ram进行分区，以便从核心到fla有不同的路径，那么性能可以得到提高。
单一的寻址空间，至少在共享的内存寻址空间内。
AutoSar多核架构应能在支持和不支持内存保护的系统上运行。
0.3 多核局限

不支持在启动操作系统（StartOS）后在AutoSar控制下激活其他核（StartCore）。
调度算法不将Task动态分配给核心
AutoSar OS RESOURCE算法不支持跨核。RESOURCE可以在本地使用，在绑定到同一核心的任务之间使用，但不能在绑定到不同核心的任务/ISR之间使用。

1. AUTOSAR Multi-Core OS & AUTOSAR OS
   AUTOSAR Multi-Core OS是从现有的AUTOSAR OS衍生出来的。AUTOSAR Multi-Core OS不是一个虚拟的ECU的概念，而是一个共享相同配置和大部分代码的操作系统，但是对每个核的数据结构是不同的。为了减少内存占用，所有的核都应该使用相同的基本代码

2.调度机制
任务的优先级决定了调度。由于多个核心真正并行运行，因此可以同时执行多个任务。

在同一个核心上具有相同优先级的Task将按激活顺序执行；在不同核上具有相同优先级的Task可能不会按激活顺序执行，因为核之间的调度是相互独立的。一个核上的低优先级Task可以与另一个核上的高优先级Task并行运行。Task和ISR不能通过调度算法动态地改变核。

3.可定位实体（Locatable Entities）
可定位实体是必须完全位于一个核上的实体。配置是定义了LEs在核上的分配（OsApplicationCoreRef ）。

在Autosar标准中，OSA就是一种LE。在单核系统上，操作系统应用程序仅适用于SC3和SC4，因为该机制用于支持内存保护并意味着使用扩展模式。在多核系统中，操作系统应用程序总是独立于内存保护，在SC1标准模式下是可能的

指定到同一个OSA中的Task/ISR应在同一核上执行。

4.多核启动
多核启动方式与硬件强相关。特别的，硬件只启动一个核（主核），其他的核（从核）处于halt状态直到由软件激活。

Autosar多核操作系统规范要求系统具有主-从启动行为，可以由硬件直接支持，也可以在软件中模拟。主核定义为无需软件激活，而从核需要软件激活。

在多核配置中，Autosar使用的每个从核必须在StartOS输入到核上之前激活。

如果核被激活，它会在调用“main”函数之前执行一些特定于硬件和编译器的操作。如果在每个核心上执行相同的“main”功能，则必须根据功能内的特定核心id来区分核心

StartOS对所有的核进行两次同步：第一次同步点位于StartupHook执行之前，第二个同步店在StartupHook之后调度器启动之前。第二次同步取决于程序执行，但是需要在调度开始之前。

第一次同步之后，各个核调用StartupHook。系统中只有一个StartupHook函数，必须在StartupHook期间执行核个别功能GetCoreID函数可用于区分个别核。全局StartupHoop执行结束之后，每个核执行OSA的StartupHook函数。由于操作系统应用程序绑定到核，因此特定于操作系统应用程序的StartupHook仅在绑定了相应的OSA的核上执行。

5. Autosar OS控制的核
   Autosar OS API提供了StartCore函数来启动它控制下的核。StartCore可以在主核和从核上被多次调用。

StartOS函数应在StartCore激活的所有核心上调用。不允许从已经调用StartOS的核心调用StartCore。

属于Autosar系统的多核应由Autosar OS API StartCore来激活。

6. 不受Autosar OS控制的核
   StartNonAutosarCore 可以在StartOS前后调用，用来激活被其他OS控制或者不被OS控制的核。Autosar功能不应该在这些核上调用，否则会出现未定义的行为。

7. Multi-Core关闭概念
   Autosar提供了两种关闭概念，同步关闭和单独关闭。同步关闭由ShutdownAllCores()触发，单独关闭由ShutdownOS()触发。

7.1 同步关机概念

如果拥有合适权限的Task调用“ShutdownAllCores()”，一个会触发关机流程的信号会传输到其他各个核。一旦某个核上开始关机流程，中断核Task都不会再执行，调度也不会发生，因此，再来激活Task不会产生任何作用，也不会由错误产生。应用开发人员和系统集成人员有责任保证在调用“ShutdownAllCores()”之前所有的应用层软件和基础软件层的各种准备工作都已完成。

关机过程中，每个核在同步点之后执行各自OSA特定的ShutdownHook函数。所有核到达同步点之后，全局ShutdownHook函数在所有的核中并行执行。

7.2 单独关机概念

如果一个任务调用ShutdownOS，那么将在调用ShutdownOS的核上关闭操作系统。每个核都可以调用ShutdownOS，与StartOS类似，ShutdownOS可以单独关闭核。为关闭整个ECU，需要在每个核上调用ShutdownOS。ShutdownOS没有返回值。

7.3 内部严重错误导致的关机

在多核系统中，只在一个核上检测到致命的内部操作系统错误。在这种情况下，该核心的本地关闭是没有意义的。

如果操作系统检测到致命的内部错误，则应关闭所有核心。

8. GetTaskID
   GetTaskID可以在Task或ISR2级别调用。单核系统中，GetTaskID返回被中断的Task或表示没有Task正在运行。Multi-Core系统中，GetTaskID表示该核上没有Task正在运行或该核上被打断的Task ID。

9. 中断禁能
   所有类型的中断只能在本地核上禁用。这意味着其他内核上的中断标志保持其当前状态。在其他核心上继续调度。在其他核心上运行ISR将继续执行。

DisableAllInterrupts ；EnableAllInterrupts ；SuspendAllInterrupts ；ResumeAllInterrupts ；SuspendOSInterrupts ；ResumeOSInterrupts 。以上系统服务只影响调用该服务的核。

10. 任务激活（Task Activation）
    Task激活应扩展到跨核心工作。如果一个Task需要在另一个核上激活，该核上应有一个调度决策，如果该核未启动，则会产生一个错误。

11. 任务链（Task Chaining）
    Task链应扩展到跨核心工作。如果一个Task需要在另一个核上激活，该核上应有一个调度决策，如果该核未启动，则会产生一个错误。

12. OS启动
    StartOS在每个核上都被调用。用户通过StartOS(AppMode)中的AppMode向操作系统提供操作系统模式参数。操作系统模式中规定了OS自动启动时的配置参数（Tasks，Alarms,Schedule Tables）

多核操作系统中，所有的核都应运行在相同的AppMode中，如果用AppMode DONOTCARE调用StartOS，则使用其他核心的AppMode 。至少有一个核心必须定义除DONOTCARE之外的AppMode。如果所有核心上的应用程序模式相同，StartOS将继续其任务。

13. Task Termination
    任务的终止需要额外的检查：不允许在自旋锁被占用时终止任务。如果使用占用的自旋锁调用TerminateTask/ChainTask，则返回错误。

14. Termination of OSA
    与Task类似，OSA不允许在任意Task占用自旋锁时被终止。在这种情况下，锁会自动释放。为了避免错误处理的雪崩，不调用ErrorHook。TerminateApplication(A)可以在不同的核中并行调用。TerminateApplication(A)支持只执行第一次调用并忽略后续调用的模式直到终止完成，

15. OS关闭
    每个核都能使用ShutdownOS函数关闭OS。通过调用ShutdownOS，只有调用的核会进入关机流程。如果用户希望关闭所有核（或多或少时并行的），应调用ShutdownAllCores。

ShutdownOS和ShutdownAllCores没有返回值。ShutdownOS是为在没有RTE和模式管理的内核上运行操作系统的用户提供的。

16. 等待EVENT
    EVENT等待机制必须适应新的多核自旋锁功能：调用WaitEvent可能取消任务的调度，这种情况下将无法释放自旋锁。因此，WaitEvent必须检查调用的任务是否持有一个自旋锁，作为一种RESOURCE，处于等待状态的任务不能占用自旋锁。

17. Calling trusted functions 调用受信任函数
    函数可以作为OSA的一部分声明为受信任的。他们只能通过调用CallTrustedFunction接口函数来执行。假设访问权限是相应配置的，来自OS应用程序A的任务可以从OS应用程序B调用可信函数。

在多核系统中，这些从一个操作系统应用程序到另一个操作系统应用程序的可信函数调用仅限于同一个核。

18. 调用重新调度
    调度API函数必须以WaitEvent相同的方式适应多核自旋锁的功能。任务占用自旋锁时不应主动强制取消调度

19. RESOURCE占用
    GetResource函数允许同一核上的Task之间互斥。OS生成器应脱机检查任务是否不在不同的内核上（见7.9.30），GetResource函数将联机检查此要求

优先级上限协议（由GetResource使用）临时更改Task的优先级。这种方法在多核系统上失败，因为优先级是每个核的局部优先级。因此，优先级上限协议不足以关键部分免受来自不同核心的访问。

注：优先级上限协议不适用于多核操作系统。

如果自旋锁和资源被任务/ISR锁定，则必须按照严格的后进先出（LIFO）顺序解锁。

每个硬件都为核心分配一个唯一的物理ID，物理ID是区分各核的唯一方式，uC的物理ID不一定是连续的也不一定从0开始。

软件需要一种识别核ID的机制，例如与核相关的特定变量。由于物理核ID通常不能用作核心特定变量的直接数组索引，因此需要逻辑核ID将物理核ID映射到数组索引。软件无需知道。在软件中，不需要知道物理核ID，逻辑核ID就足够了。

OSA和其他软件对象和核的映射关系在配置文件中确定。所有的映射关系与硬件无关因此不必基于物理核ID而基于逻辑核ID。

函数GetCoreID在内部将物理核ID映射到逻辑核ID，映射是特定与实现的，GetCoreID可以是C函数也可以是宏定义。

注：GetCoreID函数要在StartOS函数之前调用。

20. COUNTER
    与单核情况类似，每个操作系统（在每个核上）提供至少一个从计时器派生的计数器。因此，可以定义几个属于不同OSA的计数器，这些计数器要么驻留在同一个内核上，要么驻留在不同的内核上。

21. 多核操作系统上COUNTER的限制
    AutoSarOS操作系统只能在它所在的内核上增加计数器。如果x和y分配给不同的核，则分配给OSA-x的计数器不能由OSA-y递增。

两个做出上述限制的原因：

当允许对计数器进行跨核心修改（一个核等待另一个核修改计数器）时，可能会出现竞争条件（Race conditions）。
递增计数器的核心必须检查基于计数器的警报（ALARM）是否已过期。当不同的核操作同一个警报时，过期警报的处理更为复杂，因为互斥是必要的。

22. COUNTER同步
    COUNTER是用来驱动ALARM和调度表的。为了同步不同核上的ALARM和调度表，对应的COUNTER需要同步。

例如，如果硬件支持这一点，则不同核心上相应的自由运行硬件计数器可能使用相同的计时器（由外围设备维护的相同计数器值），并因此在不同核心上提供相同的时基。然后，软件计数器可以通过附加到这些核本地对应硬件计数器的警报来增加，例如，驱动不同内核上的同步调度表。

同步性的好坏取决于硬件结构和系统配置。

23. ALARM
    AutoSAR OS的ALARM机制提供了激活TASK，设置EVENT，增加计数器（COUNTER），或者调用ALARM回调函数的服务。

ALARM只能绑定到相同核上的COUNTER。激活TASK和EVENT设置对应的ALARM动作与TASK绑定的核无关。然而，由OSA设定的访问权限不能忽视（Trusted or Untrusted）。此外，当ALARM绑定到其他核时，应允许操作ALARM。SetRelAlarm,SetAbsAlarm,CancelAlarm等API函数可以用来操作其他核上的ALARM参数。

注：ALARM到期可以激活不同核上的TASK，设置不同核上的EVENT。

ALARM回调函数知道ALARM绑定的核上运行，只有SC1系统上运行，其他类别的系统中不允许。

24. 调度表
    与ALARM相似，调度表可以用来激活TASK和设置EVENT，调度表只能绑定在COUNTER所在的核。

为简化系统启动，可以启动其他核上的调度表。系统设计人员负责正确处理计划表。例如，可以从一个核来控制调度表。

AutoSAR OS应在其OSA所在的核上处理调度表。

StartScheduleTableAbs ，StartScheduleTableRel ，StopScheduleTable，GetScheduleTableStatus 这些API函数可以对其他核上的调度表进行操作。

25. 自旋锁机制（SpinLock）
    与多核概念相符，需要一种不同核上的TASK互斥机制。这种机制不用于相同核上的不同TASK之间，因为这没有意义。

SpinLock是一种忙碌等待机制，它轮询（lock）变量直到它变为可用为止。通常，这需要一个原子级的“测试和设置”功能，其细节是特定于实现的。

一旦一个lock变量被TASK/ISR2占用，其他核上的其他TASK/ISR无法占用这个变量。SpinLock机制在轮询lock变量时不会取消这些其他任务的调度。但是，在轮询lock变量时，可能会发生优先级较高的TASK/ISR准备就绪的情况。在这种情况下，旋转任务将受到干扰。

用户可以通过SuspendAllInterrupts来敲击自旋锁（rapping the spinlock），这样就不会被其他的TASK干扰。OS可以通过配置参数OsSpinlockLockMethod自动完成。

另外一种死锁情形：

为了避免死锁，不允许嵌套不同的自旋锁。如果自旋锁是嵌套的，则必须定义唯一的顺序。自旋锁只能按此顺序执行，而允许跳过单个自旋锁。

自旋锁机制本身并不是无死锁的。必须在配置描述中说明请求任务/ISR的自旋锁的顺序。如果任务占用自旋锁，则应限制调度

。

自旋锁：

主要作用是给临界数据加锁，从而保护临界数据不被同时访问，实现多任务的同步。如果临界数据当前不可访问，那么就自旋直到可以访问为止。
自旋锁和互斥锁存在差异的是自旋锁不会引起调用者睡眠，如果自旋锁无法获取，那么调用者一直循环检测自旋锁直到释放。
spinlock的工作方式本身就体现了它的优缺点，优点是执行速度快，不涉及上下文切换；缺点是耗费CPU资源。

因为在现代处理器系统中，考虑到中断、内核抢占以及其他处理器的访问，所以spinlock自旋锁应该阻止在代码运行过程中出现的其他并发干扰。