特约专栏 | AUTOSAR的一种时间保护机制（Deadline Supervision）介绍

SASETECH

建立安全生态圈，成为汽车安全的布道者

引言

AUTOSAR的一种时间保护机制（Deadline Supervision）介绍

在AUTOSAR_EXP_FunctionalSafetyMeasures中介绍了AUTOSAR标准中的一些有助于防止、检测和减轻软硬件故障和串扰的安全机制，分别为：1.内存隔离、2.时间保护、3.逻辑监控、4.E2E保护。

这里主要介绍一下时间保护的机制，失效原理和失效模式，并介绍一种利用Autosar WatchDog Manger 模块实现对监控实例执行过快、执行过慢这几种故障的诊断机制，称为Deadline Supervision。

➡本文主要内容分为2个部分（约2000字，10分钟阅读）

需要进行时间保护的原因

一个控制器内，嵌入式软件可以由非安全相关和安全相关的软件组件组成，这些组件执行不同ASIL级别的功能。

根据GBT34590 Part6 7.4.9 ,如果嵌入式软件由不同ASIL等级的软件组件组成,那么除非能够证明软件之间免于干扰，否则软件需要按照其中最高的软件等级去开发，所以在软件架构设计阶段，需要进行相关失效分析（DFA）。

图：GBT34590 Part6 7.4.9

根据ISO2626 Part 6 附录D GB∕T 34590.6-2017 道路车辆 功能安全 第6部分：产品开发：软件层面.pdf 中介绍，通常起软件分区间相互干扰的原因是以下四点：

1.存储

2.时间、时序

3.执行

4.信息交换

而这正好对应了开头AUTOSAR规范中提供的4种安全机制：内存隔离、时间保护、逻辑监控、E2E保护，这里主要介绍一下与时间相关的AUTOSAR软件机制，即第2点和第3点。

时间是嵌入式系统的一个重要特性。安全行为要求系统动作和反应在正确的时间内执行。正确的时间可以用一组必须满足的时间约束来描述。但是软件组件本身不能保证时间资源的确定性。它依赖于OS运行时环境和基本软件的适当支持。在集成过程中，需要确保AUTOSAR软件的时间约束。根据GBT 34590中第11部分中央处理单元的失效模式（这部分在旧版本中的Part5 表D.1部分也有所提及），相关的失效模式可能有：

1.指令流未执行（完全遗漏）

2.非预期指令流被执行（误启动）

3.指令流执行时间错误（过早/过晚）

4.指令流结果不正确

另外参考GBT 34590中第6部分软件层面附录D，在软件造成也需要分析要素之间的干扰，时序和执行部分需要考虑下列故障影响：

1.执行阻塞

2.死锁

3.活锁

4.执行时间的不正确分配

5.软件要素间的不正确同步

所以，软件中应该有一种监视任务执行情况的处理机制，监控任务满足设计时的预算，并且不独占操作系统资源。为了保证安全相关的函数能够遵守它们的时间限制，必须检测和处理独占CPU的任务(例如CPU负载过重、许多中断请求)，AUTOSAR中提供了以下两种时间监控的机制。

第一种是在操作系统中使用时间保护机制 Timing Pro-tection mechanisms using the Operating System，目前我的理解是，这种机制主要是诊断失效任务执行阻塞这种情况，主要指的是给系统调度的各类中断/任务任务一个预期的时间资源分配，当超出这个这个分配的时候，触发时间保护机制，类似于系统对于堆栈溢出的检测。因为有的任务是QM的，但存在资源锁定的情况，对系统时间资源占用会影响到安全相关的任务的运行。

第二种是使用看门狗管理单元进行时间程序流监控  Temporal Program Flow Monitoring using the Watchdog Manager，该种监控包含了2种：

1.Deadline Supervision:时限监控

2.Alive Supervision:存活监控

此外，Autosar WatchDog Manger还提供了一种称为逻辑监督的机制，它可以与Deadline Supervision相结合，用于诊断程序的无序执行，提供高诊断覆盖率（诊断覆盖率从90%上升到99%，用于ASIL C/D的系统）。在ASIL B的系统中，我们只要做到Deadline Supervision和Alive Supervision。

Deadline Supervision机制介绍

关于Deadline Supervision，是在一个监控实例（可以是一个SWC也可以是一个Runable、BSW module或者CDD）中配置了两个由Transition 连接的检查点（CP）。最后期限附加在从开始检查点到结束检查点的转换上。最简单的期限监督配置包含两个。CP和一个Transition ，如下图所示。

配置以下参数

上述最大最小值设置我理解是一个Dealline Super-vision触发的一个窗口时间。当监控实例到达 start checkpoint 时，Watchdog Manager会存储一个时间戳（时间戳是通过读取OS tick获得的），对于每个监控实例，都会配置一个OS Counter，一个OS Counter可以用于不同的监控实例，也可以独用。如果在不同的OS-Applications或者分区中使用共享的OS Counter,需要配置允许OS-application访问计数器的列表(OsCount-erAccessingApplication)，由于DeadlineMax和Min用的单位是秒，所以函数WdgM_CheckpointReached可以用 OsSecondsPerTick来配置一下时间。

当DeadlineSupervision start Check point到达时且Watchdog Manager 处在active mode的状态，函数WdgM_CheckpointReached将当前时间戳记录作为开始点的参考。使用OS的函数GetElapsedTime去计算时间戳的距离。

需要注意的是：

1.每次到达WdgMDeadlineStartRef，时间戳会被当前的时间戳更新，如果因逻辑错误，监控实例没有到达结束点WdgMDeadlineStopRef。而经过了几次WdgMDeadlineStartRef，那么每次开始的时间戳会不断更新。[SWS_WdgM_00228]

2.根据AUTOSAR SWS WatchDog Manger 在一个Sequence中几次到达End Cp的情况没有被考虑。[SWS_WdgM_00354]

3.Dealline Supervision需要到达WdgMDeadline-StopRef之后，比较开始结束两端的时间戳内的时间是否符合WdgMDeadlineMax、WdgMDeadlineMin。在此之前的Deadline Supervision状态都是正常状态。[SWS_WdgM_00294]

因此，如果只应用Deadline Supervision这种安全机制是无法覆盖执行错误和没有执行这种故障的。（使用类似逻辑的硬件看门狗机制可以检查到没有执行的故障，但是无法细化到task级别)，这种时窗狗的行为只能监控到执行过快和执行过慢。我们需要配置WdgMGeneral / WdgMDevErrorDetect来打开错误检测和通知。之后会根据Watchdog Manager错误处理和故障恢复策略执行。

参考文档

AUTOSAR_EXP_FunctionalSafetyMeasures

AUTOSAR_SWS_WatchdogManager

GB/T 34590 Part5、6、11

Zhu Zhenhai / 作者

闻继伟 | 校阅

文章转载自公众号：Sasetech