前言

本文章所参考的 AUTOSAR 标准为 4.4.0 版本

AUTOSAR OS，源于早期的 OSEK OS，随着汽车行业的快速发展，特别是对电子信息安全和功能安全要求的日益提升，传统的 OSEK OS 已无法满足这些高标准的需求。为此，AUTOSAR 组织进行了扩展和增强，基于 OSEK OS 的基础，为用户提供了四类具备不同功能安全级别的可裁剪操作系统类型，分别是 SC1 至 SC4。

SC1: OSEK OS + Schedule Table；
SC2: OSEK OS + Schedule Table + Timing Protection;
SC3: OSEK OS + Schedule Table + Memory Protection;
SC4: OSEK OS + Schedule Table + Timing Protection + Memory Protection；

如下图所示，较为清晰了描述了这四种不同可裁剪类型的区别与联系。

AUTOSAR OS 时间保护

概念

AUTOSAR OS 的四大可定制类型凸显了时间保护（Timing Protection）这一关键功能机制的重要性。作为实时操作系统，AUTOSAR OS 需要在预设时限内精确执行任务。然而，超时错误偶有发生，此时系统需采取有效的时间保护措施以预防此类情况。

Deadline Monitoring 是常见的时间保护手段。一旦 OS 检测到任务运行超时，它会触发相应的 Hook 函数以报告系统错误。然而，AUTOSAR OS 并未采用监控截止时间的方法来实现时间保护，因为这种方式往往无法精确识别错误的根源。

以任务 1 为例，即便其运行时间超过截止时间，也不一定意味着任务 1 本身存在错误。实际上，可能是在执行任务 1 之前，任务 2 频繁抢占资源或长时间阻塞资源访问，间接导致任务 1 超时。若仅因任务 1 超时而判断其为错误并停止，那么真正的罪魁祸首任务 2 则可能继续逍遥法外，这显然不合理，也无法有效保护 OS 中各任务的时间管理。

为了更好地说明这一点，我们可以设想一个操作系统，其中包含任务 A、B、C，每个任务都有明确的优先级、执行时间和截止时间，如下表所示：

假设所有任务均于时间 0 准备就绪，执行流程将严格遵循以下时序，确保所有任务均按时完成。

任务 A 因最高优先级而首先执行。
随后，任务 B 在 1 个 Tick 后启动，任务 C 则在 3 个 Tick 后开始。
任务 C 执行 1 个 Tick 后被任务 A 中断，待任务 A 完成后，任务 C 继续执行。
至第 10 个 Tick，任务 C 完成，整个过程中无超时现象，且剩余 1 个 Tick 的空闲时间。

现考虑任务 A 与 B 出现行为异常的情形。异常状态如下图所示：

任务 A 的第二个周期与任务 B 的第一个周期均出现运行时间延长的情况，但均在截止时间之内完成。
任务 B 在第二个周期提前启动，同样未超过其截止时间。
尽管任务 C 按照正常时序执行，但由于任务 A 与任务 B 的异常行为，导致任务 C 的执行超时，从而引发超时错误。

因此，从上述案例的分析中，我们可以得出以下结论：在固定优先级抢占式操作系统，如 AUTOSAR OS 中，任务或中断服务例程（ISR）是否能够满足其截止日期，主要取决于三大关键因素：

任务/ISR 的执行时间： 这包括任务从获得 CPU 执行权到主动放弃 CPU 的执行周期时间，以及第二类 ISR 从开始到结束的总运行时间。
任务/ISR 因低优先级任务/ISR 锁定共享资源或禁用中断而遭受的阻塞时间： 这涉及任务或 ISR 持有共享资源的时间（从 GetResource 调用到 ReleaseResource 调用的时间），操作系统中断被任务/ISR 挂起的时间（OSInterrupts 关闭到打开的时间），以及任务/ISR 暂停/禁用所有中断的持续时间（AllInterrupts 关闭到打开的时间）。
任务/ISR 的到达间隔率： 这指的是任务从连续两次获得 CPU 执行权之间的间隔时间，包括任务从 SUSPENDED 状态转换到 READY 状态的时间，以及从 WAITING 状态转换到 READY 状态的时间。对于第二类 ISR，这还包括其连续两次执行之间的间隔时间。

针对上述三大关键因素，AUTOSAR OS 采用了以下三种时间保护机制：

执行时间保护： 确保任务或第二类 ISR 的执行时间在静态配置的上限之内，称为执行预算。这主要保护任务的实际执行时间和第二类 ISR 的完整运行周期。
锁定时间保护： 确保任务或 ISR 锁定共享资源或禁用中断的时间不超过静态配置的上限，称为锁定预算。这主要涉及对共享资源持有时间、操作系统中断挂起时间以及所有中断禁用时间的监控。
到达间隔时间保护： 保证任务或第二类 ISR 到达间隔时间在静态配置的下限之上，称为时间帧。这确保了任务从 READY 状态转换的间隔时间以及第二类 ISR 的执行间隔符合预设要求。

下图显示了执行时间保护和到达间隔时间保护如何与 AUTOSAR OS 的任务状态转换模型进行交互。

特别的，值得注意的是 AUTOSAR OS 的时间保护机制具备以下基本特性：

任务与二类中断的专用性： 时间保护机制仅适用于任务和第二类中断，而不适用于第一类中断。这是因为在 AUTOSAR OS 中，第一类中断通常被设计为异步事件处理，其执行时间通常较短且难以预测，因此不适用于时间保护。
OS 启动先决条件： 在操作系统（OS）未启动之前，时间保护机制将不会生效。这是因为时间保护机制依赖于 OS 提供的服务和资源，如任务调度、中断管理等，而这些服务在 OS 未启动前是不可用的。
信任级别的要求： 在 trusted OS-Applications 场景中，所有的时间信息都必须准确无误，否则系统可能会在运行时发生失败。这是因为信任级别的应用通常对实时性和可靠性有更高的要求，任何时间上的误差都可能导致系统行为异常。然而，对于 non-trusted OS Applications，时间保护机制可以作为加强可执行对象之间定时界限的一个手段，以提高系统的稳定性和可靠性。
中断禁用限制： DisableAllInterrupts 和 SuspendAllInterrupts 等相关接口并不能关闭时间保护定时器中断。这是因为时间保护定时器中断是确保系统实时性和任务截止日期的重要机制，如果允许这些接口关闭时间保护定时器中断，将会破坏时间保护的完整性和有效性。因此，AUTOSAR OS 设计规定这些接口不得影响时间保护定时器中断的正常工作。

故障后措施

关于时间保护机制在检测到时间异常后的具体处理细节，AUTOSAR_SWS_OS 7.7.2.2 Requirements 规范中进行了明确的规定。当时间保护机制检测到任何与时间相关的异常时，会调用 ProtectionHook 函数，并传递相应的错误码，以便应用程序或系统能够采取适当的措施进行响应。

E_OS_PROTECTION_ARRIVAL：当触发到达间隔时间保护时，意味着任务或 ISR 的到达间隔时间违反了静态配置的下限（时间帧）。这种情况下，ProtectionHook 函数将收到 E_OS_PROTECTION_ARRIVAL 错误码。这通常表明系统调度或任务管理存在问题，可能需要重新评估任务的时间需求或调度策略。
E_OS_PROTECTION_TIME：当触发执行时间保护或锁定时间保护时，意味着任务或 ISR 的执行时间或锁定时间超过了静态配置的上限（执行预算或锁定预算）。在这种情况下，ProtectionHook 函数将收到 E_OS_PROTECTION_TIME 错误码。这通常表明存在代码效率问题、资源争用或优先级配置不当等问题，需要进行性能调优或资源分配调整。
E_OS_PROTECTION_LOCKED：当触发锁定时间保护时，意味着任务或 ISR 因锁定共享资源或禁用中断而遭受的阻塞时间超过了静态配置的上限。此时，ProtectionHook 函数将接收到 E_OS_PROTECTION_LOCKED 错误码。这通常表明资源管理或中断控制存在问题，可能需要优化资源访问方式、减少资源争用或调整中断处理策略。

ProtectionHook 函数的具体实现取决于应用程序或系统的需求。在接收到这些错误码后，它可以用于记录错误信息、触发警报、执行恢复操作或采取其他适当的措施来应对时间异常。

ProtectionHook

ProtectionHook 函数在 AUTOSAR OS 中扮演了一个关键角色，它为用户提供了一个自定义的接口，用于处理时间保护机制检测到的时间异常。这个函数的原型如你所述，ProtectionReturnType ProtectionHook(StatusType Fatalerror)，其中 Fatalerror 参数是一个状态类型，用于传递检测到的具体错误码。

当用户实现 ProtectionHook 函数时，他们需要根据传递的错误码来决定函数的行为。根据 AUTOSAR_SWS_OS 7.8.2 Requirements 规范，ProtectionHook 函数可以通过返回不同的命令码来指示系统应采取的措施，这些命令码及其对应的功能如下：

PRO_IGNORE：选择忽略此次错误。这通常适用于那些认为不会导致严重问题或可以容忍的小幅度时间偏差。
PRO_TERMINATETASKISR：强制终止引起时间异常的任务或第二类中断服务例程（ISR）。这是一种比较严格的措施，用于防止错误扩散或保护系统免受进一步的影响。
PRO_TERMINATEAPPL：强制终止引起时间异常的任务或 ISR 所属的应用程序。这通常用于隔离和清除问题来源，但可能导致部分系统功能丧失。
PRO_TERMINATEAPPL_RESTART：强制重启引起时间异常的任务或 ISR 所属的应用程序，并尝试恢复系统到正常状态。这是一种更为激进的恢复措施，适用于那些认为重启应用程序可以解决问题的场景。
PRO_SHUTDOWN：关闭整个系统。这是一种极端的措施，通常只在系统出现无法恢复的错误或面临严重的安全威胁时才使用。

ProtectionHook 函数的实现应该基于应用程序和系统的具体需求，以及对错误处理和系统恢复能力的权衡。在编写 ProtectionHook 函数时，开发者需要仔细考虑每个命令码的含义和潜在影响，以确保系统在遇到时间异常时能够做出合理且有效的响应。

通过这种机制，AUTOSAR OS 提供了一种灵活而强大的手段来管理实时系统中的时间相关错误，从而增强了系统的健壮性和可靠性。

硬件实现

仅以英飞凌的 TriCore 架构为例进行讲解

英飞凌的 TriCore 架构是一个专为汽车和工业应用设计的实时处理器架构。在其 AURIX 系列微控制器中，时间保护系统是一个关键特性，它提供了对任务执行时间的监控和保护，从而确保系统的实时性和可靠性。

从 Infineon-AURIX_TC3xx_Architecture_vol1-UserManual-v01_00-EN 手册的 11 Temporal Protection System 章节中，我们可以了解到 TriCore 架构的时间保护定时器具有以下功能：

单调递减： 时间保护定时器以 CPU 主频的频率单调递减。这意味着定时器从写入的非零值开始，以固定的时钟周期逐渐递减至零。
启动与关闭： 通过写入非零值来启动定时器，而写入零值则关闭定时器。这种机制允许软件精确地控制何时开始和停止时间监控。
异常陷阱触发： 当定时器到期（即递减至零）时，会触发一个异常陷阱（Class-4, Tin-7）。这是一个硬件级别的中断，用于通知软件有一个时间保护事件发生了。重要的是，这个异常陷阱是不能通过 DisableAllInterrupts/SuspendAllInterrupts 等接口关闭的，因为它是由硬件直接管理和触发的。
多核支持： 每个核都配备了独立的时间保护定时器。以 TC397 为例，它有 6 个核，每个核有 3 个独立的时间保护定时器。这意味着总共有 6 * 3 = 18 个时间保护定时器可供使用。这种设计允许每个任务或第二类中断服务例程（ISR）在不同的核上运行，并独立地受到时间保护的监控。

另外，TriCore 架构还提供了一个 CPU_CCNT 的寄存器，该寄存器在手册Infineon-AURIX_TC3xx_Architecture_vol1-UserManual-v01_00-EN中的 12.11 Performance Counter Registers 章节可以查阅到，该寄存器会记录当前的 CPU 时钟周期，这个寄存器非常适合用来进行间隔时间保护