2.2时序监控
时序是嵌入式系统的一个重要属性。安全行为要求在正确的时间内执行系统操作和响应。
正确的时间可以用一组必须满足的时序约束来描述。然而，AUTOSAR SWC本身无法确保正确的时机。这取决于AUTOSAR运行时环境和基础软件的适当支持。在集成过程中，需要确保AUTOSAR SWC的时序约束。
2.2.1故障模式
根据ISO26262，以下与时序和执行相关的故障可被视为 SWC之间干扰的原因：
- 阻塞执行
- 死锁
- 活锁
- 执行时间分配不正确
- 软件要素之间的同步不正确
时序保护和监控可以描述为对以下属性的监控：监控任务在指时序间调度，满足执行时间预算，并且不独占OS资源。
为了保证与安全相关的功能将遵守其时序约束，应检测并处理垄断CPU的任务（例如CPU负载过重，太多中断请求）。
2.2.2描述
AUTOSAR提供以下时序监控机制：
- 使用 OS的时序保护机制。
- 使用Watchdog Manager进行时序程序流监控。
本章将解释Watchdog Manager在实现应用软件时序监控方面的应用。
Watchdog Manager还引入了一种称为逻辑监控的机制，该机制可以与死线监控结合使用，以提供高诊断覆盖率。
此外，本章还将概述AUTOSAR OS的时序保护机制。
2.2.2.1受监控实体
Watchdog Manager监控AUTOSAR ECU中应用程序软件的执行。监控的逻辑单元称为监控实体。在AUTOSAR中，受监控实体和架构构建基块之间没有固定的关系。通常，受监控实体可以表示一个SWC或SWC的一个Runnable、一个BSW模块或CDD，具体取决于开发者的选择。
受监控实体中的重要节点被定义为检查点。受监控实体的代码与Watchdog Manager的函数调用交互。这些调用用于向Watchdog Manager报告已到达检查点。
2.2.2.2Watchdog Manager
Watchdog Manager是AUTOSAR架构的基础软件模块。Watchdog Manager将看门狗硬件的触发与软件执行的监控联系起来。当检测到对程序执行的时态和/或逻辑约束的违反时，将采取许多可配置的操作来从此故障中恢复。
Watchdog Manager为时序程序流监控提供以下机制：
活体监控：定期监控实体对执行频率有限制。通过活体监控，Watchdog Manager会定期检查受监控实体的检查点是否已达到给定限制。这意味着Watchdog Manager会检查受监控实体的运行频率是否太高或太低。
活体监控是使用单个检查点执行的，没有切换。受监控实体必须周期性地调用检查点，以发出其及时操作的信号。OS定期执行Watchdog Manager以验证检查点参数。
受监控的实体也可以通过多个活体监控实例进行监控，因此每个活体监控都包含一个独立的检查点。请参见图9。
图9：具有独立检查点的实时监控
死线监控：非周期性或周期性监控实体对两个检查点之间的时间安排有单独的限制。通过死线监控，Watchdog Manager检查受监控实体的两个检查点之间的转换时间。这意味着Watchdog Manager会检查受监控实体中的某些步骤所花费的时间是否在配置的最小值和最大值之内。请参见图10。
如果从未到达第二个检查点，则死线监控将无法检测到此问题。出现此问题的原因是，在调用第二个检查点后，Watchdog Manager将执行时序检查。
图10：死线监控
2.2.2.3 OS的时序保护
根据AUTOSAR OS规范，当任务或中断在运行时错过其死线时，就会发生实时系统中的时序故障。
AUTOSAR OS不提供时序保护的死线监控。死线监控不足以正确识别导致AUTOSAR系统中时序故障的任务或中断。违反死线可能是由不相关的任务或干扰执行的中断引起的。请咨询AUTOSAR OS规范23了解更多详情。
在固定优先级抢占式 OS（如AUTOSAR OS）中，任务或中断是否满足其死线取决于以下因素：
- 任务/中断在系统中的执行时间。
- 任务/中断遭受较低优先级的任务/中断阻塞共享资源或禁用中断的阻塞时间。
- 系统中任务/中断的到达间隔速率。
为了安全准确地提供时序保护， OS必须在运行时控制这些因素，以确保任务/中断可以满足各自的死线。AUTOSAR OS提供以下时序保护机制：
- 执行时间保护。任务或2类中断的执行时间上限，即所谓的执行预算，通过 OS进行监控，以防止时序错误。
- 锁定时间保护。OS监控资源阻塞、锁定和暂停中断的上限，即所谓的锁定预算。
- 到达时间保护。正在激活的任务或2类中断到达之间的下限，即所谓的时间片，通过 OS进行监控，以防止时序错误。
注意：执行时间实施需要硬件支持，例如时序实施中断。如果使用中断来实现时间执行，则该中断的优先级应高到足以“中断”受监控的任务或中断。
2.2.3检测与响应
Watchdog Manager为时序和逻辑程序流监控提供了三种机制：死线监控、活体监控和逻辑监控。
监控机制是静态配置的。对于受监控实体的监控，可以采用多种监控机制。
根据每个已启用机制的结果，计算受监控实体的状态（称为局部状态）。当确定每个受监控实体的状态时，然后根据每个局部监控状态，确定整个MCU的状态（称为全局监控状态）。
根据每个受监控实体的局部监控状态和全局监控状态，Watchdog Manager会启动许多机制来从监控失败中恢复。这些范围从受监控实体内的局部错误恢复到ECU的全局重置。
Watchdog Manager可以采用以下错误恢复机制：
受监控实体中的错误处理
如果受监控实体是SWC或CDD，则Watchdog Manager可以通过RTE模式机制通知受监控实体有关监控情况。然后，受监控实体可以采取措施从该故障中恢复。
Watchdog Manager可能会在检测到监控故障时向诊断事件管理器（DEM）注册一个条目。受监控实体可能会根据该错误条目执行恢复操作。分区关闭
如果Watchdog Manager模块在位于不受信的分区中的受监控实体中检测到监控故障，则Watchdog Manager模块可以通过调用BswM请求分区关闭。
通过硬件看门狗重置
Watchdog Manager向看门狗接口指示看门狗接口何时不再触发硬件看门狗。在硬件看门狗超时后，硬件看门狗将重置ECU或MCU。这导致ECU和/或MCU硬件的重新初始化以及软件的完全重新初始化。
立即复位MCU
如果需要对监控故障立即做出全局响应，Watchdog Manager可能会直接导致MCU复位。这将导致MCU硬件和完整软件的重新初始化。通常，MCU复位不会重新初始化ECU硬件的其余分区。
注：AUTOSAR文档“应用程序级别的错误说明”提供了有关错误处理的其他信息。在文档中，解释了如何执行错误处理以及可以从何处获取所需数据（例如替代值）。此外，本文档还详细介绍了如何在AUTOSAR中执行 OS-Applications/分区终止和重新启动。
2.2.4限制
- 检查点的粒度不是由Watchdog Manager固定的。很少有粗制的检查点会限制Watchdog Manager的检测能力。例如，如果应用程序SWC只有一个检查点，指示循环可运行已启动，则Watchdog Manager只能检测此可运行已重新启动并消除时序约束。相反，如果该SWC在可运行的每个块和分支上都有检查点，则Watchdog Manager也可能检测到该SWC的控制流中的故障。检查点的高粒度会导致Watchdog Manager的复杂和大量配置。
- 死线监控有一个弱点：它只检测延迟（当报告结束检查点时），但它不检测超时（当根本没有报告结束检查点时）。
- 不支持死线监控（即开始1、开始2、结束2、结束1）的嵌套。
- 每个受监控实体具有多个检查点的“活体监控”功能在“Watchdog Manager规范”中未一致地指定。目前，建议每个监控实体仅支持一个活体监控检查点。
- 为了关闭或重新启动（作为错误响应）包含受监控实体的分区，集成代码（ OS-Applications的重新启动任务）通过调用Watchdog Manager的可用函数来停用（或停用+激活）受影响分区的所有受监控实体。这有点复杂，在Watchdog Manager规范文档的未来版本中被认为是Watchdog Manager的新加功能。
- 库无法调用BSW，因此库不能由Watchdog Manager监控。但是，可以通过在模块的代码中放置库调用之前和之后的检查点来使用死线监控，以监控库实例运行。
- 如何使用受监控实体ID标识BSW模块尚未标准化。
引用来源：AUTOSAR document 2021
作者：杨玉柱
文章来源：汽车电子设计
推荐阅读
更多汽车电子干货请关注 汽车电子设计 专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。
