目录
一、安全需求的来源
二、术语介绍
三、模块简介
一、简述
二、监控实体和监测点
三、监督机制的相互作用
1、监督功能
1.1 Alive Supervision
1.2 Deadline Supervision
1.3 Logical Supervision
1.4 错误处理
1.4.1 错误处理的方式
1.5 使用约束
1.6 关联模块
四、功能分析
4.1 Local Supervision Status
4.2 Global Supervision Status
五、外部输入知识
数据手册《AURIX Safety Manual V1.5.1.pdf》
5.3.4 System Timer Plausibility Check
SM1[AoU].STM:Plausibility
系统定时器(STM)不受硬件监控。STM的失败包括错误或没有中断产生以及STM计数器值的错误内容。这些故障应由系统集成商通过系统级安全措施加以控制。
根据STM的使用情况,对在特定CPU上执行的软件进行超时监视(5.3.5)和/或程序流监视(5.3.6)可能就足够了。或者,合理性检查使用一个独立的计时器,如另一个STM或CPU时间保护系统,可以在软件中实现。
5.3.5 Timeout Monitoring
SM1[AoU].WDT:TIMEOUT
微控制器的硬件故障以及延迟程序执行的软件故障都可能危及整个系统的定时。为防止这种情况发生,应实行时间保护制度。
5.3.6 Program Flow Monitoring
SM1[AoU].WDT:PFM
微控制器的硬件故障以及软件故障都可能破坏各个程序段的顺序和时间。为了防止这种情况发生,应实施程序流监控(逻辑和时间监控)。
5.3.7 Monitoring with External Watchdog
SM1[AoU].ExtWDT
除了会导致AURIX完全或部分失败而不能发出错误信号的环境条件外,外部窗口看门狗还可以检测微控制器的内部故障,从而导致整个微控制器的执行严重延迟或停止,例如电源管理控制故障。
架构-软件层的内容
安全系统的AUTOSAR BSW分配
1、 Local Supervision Status : 局部监控状态
表示单个被监控实体的当前监控结果
2、Global Supervision Status :全局监控状态
汇总所有被监控实体的本地监控状态得到的全局状态
3、Supervised Entity : 监控实体
一种软件实体,包括在看门狗管理器的监控之下。每个受监控的实体只有一个标识符。监控实体表示软件组件或基础软件模块中的检查点集合。在软件组件或基础软件模块中可能有零个、一个或多个受监控的实体。
4、Supervised Entity Identifier : 监督实体标识符
一种标识符,在应用程序中唯一地标识受监控的实体。
5、Deadline Supervision :期限监控
一种检查两个检查点之间的执行时间是否低于给定的最高执行时间限制的监控。
6、Alive supervision :生命值监控
一种监控,检查一个被监控的实体是否执行足够频繁和不太频繁(包括公差)。
7、Logical Supervision : 逻辑监控
一种对软件的在线监控,检查软件(被监督的实体或一组被监督的实体)是否按程序员定义的顺序(按开发的代码)执行。
8、Checkpoint :监测点
被监督实体控制流中的一个点,在那里活动被报告给看门狗管理器。
9、Alive Counter :
检查点上下文中看门狗管理器中的独立数据资源,用于跟踪和处理它的活动指示量。
10、Alive Indication:
由受监督实体的检查点提供的指示,向看门狗管理器表明其活动状态。
11、Graph
通过转换连接的一组检查点,其中至少有一个检查点是初始检查点。在图的任意两个检查点之间都有一条路径(通过过渡)。
12、External Graph
外部转换是两个检查点之间的转换,其中检查点属于不同的受监督实体。
下图显示了基本软件模块到AUTOSAR层的映射关系
WDG是AUTOSAR(服务层)标准化基础软件体系结构的基础软件模块。它可以根据时间约束(时序程序流监控)和正确的执行顺序(逻辑程序流监控)来监督应用程序执行的可靠性。
看门狗管理器监督可配置数量的被监督实体的执行。当它检测到程序执行中违反了配置的时间和/或逻辑约束时,它将采取许多可配置的操作来从此故障中恢复。
看门狗Manager提供了三种机制
1. 生命监控-用于监控定时软件的时间。
2. 期限监控-针对非周期性软件
3.逻辑监控-用于监控执行顺序的正确性。
看门狗管理器监控软件的执行。监控的逻辑单位是被监控实体。监控实体和AUTOSAR中的架构构建块之间没有固定的关系,即SW-Cs、CDDs、RTE、BSW模块,但通常情况下,根据开发者的选择,一个监督实体可以代表一个swc或一个SW-C、一个BSW模块或CDD中的一个可运行对象。
被监控实体中的重要位置被定义为检查点。监控实体的代码与Watchdog Manager的调用交织在一起,当它们到达检查点时向Watchdog Manager报告。
每个被监督实体都有一个或多个检查点。被监督实体的检查点和检查点之间的转换形成一个图。这个图叫做内部图。此外,来自不同监督实体的检查点也可以通过外部过渡连接起来,形成一个外部图。在每个看门狗管理器模式中可以有多个外部图形。
一个图可能有一个或多个初始检查点和一个或多个最终检查点。从任何初始检查点开始,到任何最终检查点结束的任何顺序都是正确的(假设检查点属于相同的Graph)。在最后一个检查点之后,可以报告任何初始检查点。
在看门狗管理器设置中,可以配置检查点所需的时间以及允许的外部和内部图形。
在运行时,看门狗管理器会验证配置的图形是否被执行。这就是所谓的逻辑监督。看门狗管理器还验证检查点和转换的时间。对于定期检查点的机制称为活监督,对于非定期检查点的机制称为期限监督。
检查点的粒度不是由看门狗管理器固定的。很少有粗粒度的检查点会限制Watchdog Manager的检测能力。例如,如果一个应用程序SW-C只有一个检查点,它指示一个循环的Runnable已经启动,那么看门狗管理器只能检测到这个Runnable被重新启动,并检查时间约束。相反,如果该SW-C在每个块和可运行的分支上都有检查点,看门狗管理器也可以检测该SW-C的控制流中的故障。检查点的高粒度会导致Watchdog Manager的配置复杂而庞大。
三种监督机制对被监督单位进行监督。一个监督实体可以启用一个、两个或三个机制。基于每种启用机制的结果,监督实体(称为Local计算状态)。
当每个监督实体的状态确定,然后基于每个本地监控状态,确定整个MCU的状态(称为全局监控监督状况)。
周期性监督实体在给定的时间跨度内对它们的执行次数有限制。通过Alive Supervision,看门狗经理定期检查被监督实体的检查点是否已达到给定的限制。这意味着看门狗管理器检查监督实体是否运行得不太频繁或不太罕见。
要提供实时监视,需要配置检查点及其时间约束。活动监督最简单的配置是一个检查点,没有任何转换。
Alive Supervison Algorithm
要发送活动指示,受监督实体调用该函数
WdgM_CheckpointReached,它的结果是增加检查点的活动计数器 ,这个Main函数由AUTOSAR调度器执行,其周期由配置参数SupervisionCycle(参见WdgMSupervisionCycle)定义。在每个监督参考周期(是监督周期的倍数),可以定期检查一个或多个被监督实体的执行可靠性,对主要职能监督实体的每个检查点的柜台进行循环检查。
非周期性或偶发性监督实体对两个检查点之间的时间有单独的限制。通过期限监督,看门狗管理器检查一个被监督实体的两个检查点之间的转换时间。这意味着Watchodog Manager将检查监视实体中的某些步骤所花费的时间是否在配置的最小值和最大值之内。
对于每个Deadline Supervision,配置两个由一个Transition连接的检查点。截止日期附加到从开始检查点到结束检查点的转换上。最简单的Deadline Supervision配置包含两个检查点和一个过渡,如图7所示
在一个监督实体中可以定义多个转换。过渡和检查点不一定要形成一个闭合图。因为这个监督功能只考虑开始和结束检查点,所以可以有独立的图,如下图所示。此外,检查点可以被锁住。
以上均是被定义为带时间限制的转换,这块的基础是WdgMMode以及两个监测点之间的定义,需求【SWC_WdgM_00293】不是特别理解,难道有很多Mode吗?
方法:
对于每个截止日期开始检查点(即由WdgMDeadlineStartRef引用的检查点),看门狗管理器有一个时间戳变量,存储到达检查点的时间。
一个用于期限监督的时间戳变量是通过读取OS tick获得的。对于每个监督实体,配置一个操作系统计数器。
一个操作系统计数器可以在受监管实体之间共享,或者可以为每个受监管实体使用一个单独的操作系统计数器(特定于实现)。如果使用操作系统应用程序/分区,并且计数器在属于不同操作系统应用程序的受监管实体之间共享,那么需要配置允许访问计数器的操作系统应用程序列表(OsCounterAccessingApplication)。
逻辑监控是检查嵌入式系统软件是否正确执行的一项基本技术。当需要逻辑监督时,请参考安全标准(IEC 61508或ISO26262)。逻辑监督关注控制流错误,在应用程序无错误执行期间,控制流错误会导致与有效(即编码/编译)程序序列的背离。如果一个或多个程序指令按照错误的顺序处理,或者根本不处理,就会发生错误的控制流。控制流错误可能导致数据损坏、微控制器复位或故障静默违反。对于控制流图,这意味着每次监督实体报告一个新的检查点时,必须验证在前一个检查点和报告的检查点之间配置了一个转换。
Alive Supervision Configuration
逻辑监督检查被监督实体的代码是否按照正确的顺序执行。
对于每个逻辑监督,都有一个由转换连接的检查点图。该图抽象了看门狗管理器模块的受监督实体的行为。
为一个受监督实体的例子,让我们考虑下面的代码片段,它包含检查点CP0-0到CP0-6。
执行逻辑监控如下图所示
所示的图给出了监督实体更抽象的视图,其中检查点CP0-1表示完整的while循环。
逻辑监督图有两种类型。首先,存在一个内部图,在这个图中,所有检查点都属于同一个监督实体,检查点之间通过内部转换连接。每个监督实体可以有零个或一个内部图。
第二,有一个外部图,其中至少有两个检查点属于不同的受监督实体。检查点与外部连接
转换。
逻辑监督图有两种类型。内部图和外部图的主要区别在于,内部图是监督实体的属性(它不依赖于看门狗管理模式),而外部图依赖于模式。
内部图的逻辑监督的参数是内部过渡(参见WdgMInternalTransition),它包含在一个监督实体(WdgMSupervisedEntity)中。每个内部转换连接两个检查点。这意味着所有模式共享相同的内部过渡。只有可能在模式中停用受监督实体,这会使其内部转换的逻辑监督不活动。外部图的参数(参见WdgMExternalLogicalSupervision)包含在一个模式(WdgMMode)中。每个外部转换连接两个检查点。检查点的存在与它们是否被任何转换连接无关。
实现方式:
在看门狗管理器初始化之后,还没有报告检查点,即被监督实体是被动的。这些信息保存在活动标志中(每个图有一个标志)。
每个内部图也代表一个逻辑监督。假设有N个内部图,这意味着一个被监督实体有N个逻辑监督结果。
每个外部图表示一个逻辑监督,但它可能跨越多个受监督实体。假设有M个外部图跨越一个被监督实体,结果是M个来自被监督实体的逻辑监督结果。
当看门狗管理器本身由于编程错误或内存故障而无法正确地评估被监管实体时,仍然可能发生看门狗管理器错误地设置了触发条件而不会导致看门狗重置。因此,可能需要在看门狗管理器本身中使用监督实体和检查点(或其他内部监督机制),同时避免看门狗管理器中的递归。
全局变量,这点需要注意。
注意一个问题,WDGM并不一定是都复位,Entry处理机制,看是否恢复。
Error Handling in the Supervised Entity
Partition Shutdown
Reset by Hardware Watchdog
Immediate MCU Reset
单片机复位和看门狗复位是两种基本等价的系统级错误反应机制。在与安全相关的系统中,建议两者并行使用。通过这种方式,两种机制形成了一个“冗余关机路径”。
看门狗管理器模块启动了许多机制来从监控失败中恢复。这些范围从受监管实体内的本地错误恢复到ECU的全局重置。
回调简述
Watchdog Manager模块通过RTE Mode机制通知SW-Cs和cdd监控失败。然后,swc和cdd可以采取行动从失败中恢复。(见[SWS_WdgM_00197], [SWS_WdgM_00198])。
上报诊断
当全局监控状态达到WDGM_GLOBAL_STATUS_STOPPED,且配置参数wdgmdemstoppedmonitionreport为TRUE时,看门狗管理器向DEM报告错误状态WDGM_E_SUPERVISION。(SRS_BSW_00339 SRS_ModeMgm_09159)
复位(复位并不一定是单片机复位)
如果看门狗管理模块检测到位于非受信任分区中的受监管实体的监管失败,它可以通过终止相应的OS应用程序来重启/关闭该分区。
看门狗管理模块在状态为WDGM_GLOBAL_STATUS_STOPPED时,停止设置看门狗接口触发条件。因此,硬件看门狗超时后,会导致ECU复位 。
对于那些一旦检测到不可恢复的监控故障就需要复位单片机的应用程序,或者从硬件看门狗获得独立的关机路径的应用程序,看门狗管理模块可以立即复位单片机。
看门狗管理器不支持并发执行的受监督实体的逻辑监督,因为它一次只跟踪图的一个实例。
Deadline Supervision有一个弱点:它只检测延迟(当报告结束检查点时),但不检测超时(当根本不报告结束检查点时)
操作系统启动后,将初始化看门狗管理器。因此,它不能在启动过程的早期负责控制看门狗驱动程序。通常,在看门狗驱动程序中配置一个足够大的初始超时就足够了,以弥补看门狗驱动程序和看门狗管理器初始化之间的差距。或者,集成商可以使用ECU状态管理器设施(标注)。
定期调用WdgM_MainFunction最好由AUTOSAR调度程序;在启动期间,调用可能由另一个模块完成。
一个带有所有检查点的监督实体只能属于一个OSApplication(最多)。由于操作系统应用程序只能在一个核心上运行,因此一个特定的受监督实体可以在一个核心上运行。
运行时环境负责将检查点信息从SW-Cs或cdd中的受监督实体传播到看门狗管理器模块。看门狗管理模块使用运行时环境的服务,将监控状态的变化通知sw - c。BSW模块可以不使用RTE调用Watchdog Manager模块。
WdgIf
EcuM
Mcu
Det
Dem
SchM
Rte
BswM
OS
被监管实体是看门狗管理器模块的监管单位。每个被监管实体可以由不同的监管功能或它们的组合来监管。每个结果都是正确或不正确的。在Watchdog Manager初始化时,所有结果都被设置为正确。这意味着对于每个受监督实体都有三个部分结果(一个来自活动监督,一个来自期限监督和一个来自逻辑监督)。
下图是WDGM概述
Deadline Supervision和Logical Supervision的监控结果的确定在函数WdgM_CheckpointReached中执行。在此函数的一次执行过程中,它只更新一个特定监督实体的结果。
Alive Supervision的监控结果的确定在函数WdgM_MainFunction中执行。在此函数的一次执行过程中,它会更新所有被监督实体的活动监督结果。
监视实体在容器WdgMGeneral中定义。受监督实体包含检查点。
单个superviser entity的状态指示。
基于所有被监管实体的本地监管状态,全局“监控状态”计算。
“全局监控状态”与“本地监控状态”的值相似。主要的区别是增加了WDGM_GLOBAL_STATUS_STOPPED值。下图显示了它们之间的值和转换。
看门狗栈由3个模块创建
1、看门狗管理器(Watchdog Manager)监督所谓的被监督实体(Supervised Entities)的执行(可配置数量)。当它检测到程序执行违反了配置的时间和/或逻辑约束时,它将采取几个可配置的操作来从此故障中恢复。
2、看门狗接口允许看门狗管理器(或看门狗的任何其他客户端)选择正确的看门狗驱动程序。
3、看门狗驱动提供初始化、修改操作方式、设置触发条件(超时)等服务。
基于ETAS的配置生成如下(如有冒犯请联系删除)
Watchdog stack的配置如下所示
1、配置SWCs
创建SWCs
在SWC上创建受监督的实体,此处理解这个词(supervised entities
),表示受监控的实体。
此处有个特别深的疑问点,当我们配置好Alive之后,会自己产生一个mode,也就是WdgM_IndividualMode,对应于《AUTOSAR_SWS_WatchdogManager.pdf》8.7.2.3 Port Interfaces章节,
ALIVE是配置的,红框里面的MODE是自动生成的。
2、BSW的配置
通过配置WdgM、WdgIf和Wdg模块创建监督机制。
进一步根据用户需求手动配置看门狗栈
配置EcuM、BswM支持栈看门狗(这块的配置有待深究)
BSW code generation
3、MCAL配置
在外部看门狗中创建SPI、I2C协议来初始化和触发条件。
4、RTE配置
连接SWC和WdgM服务组件。
将可运行的看门狗服务(WdgM、WdgIf、Wdg)映射到OS任务中。
UTOSAR BSW Stack及其与最近组件的关系
ExtWdg驱动使用GPT模块调度服务TLF35584