AP AUTOSAR PHM学习笔记

落叶纷飞

概述

PHM是一个系统级别的健康监控程序，监控和管理ECU的健康状况。PHM 的核心目标是确保汽车系统的可靠性和安全性，通过实时监控应用程序的时间约束(Alive Supervision, Deadline Supervision)、逻辑程序序列(Logical Supervision)以及平台健康状态(Health Channel Supervision)来实现。如果检测到失败，PHM会通知SM模块，SM模块可以决定如何处理错误并触发适当的恢复操作。

PHM还有一个接口用于控制硬件看门狗reset，当出现严重的失败通知SM无法解决时可以对芯片进行重启操作。

PHM相关名词

Acronym	Description
Checkpoint	可以理解为在被监控程序中打的桩，执行到Checkpoint时会向PHM汇报时间戳
Alive Supervision	PHM中定义的一种监控措施，属于时间约束，它会检查一个时间段内，被监控程序汇报的次数是否在正常范围内。一般周期性任务使用它
Deadline Supervision	PHM中定义的一种监控措施，属于时间约束，它包含StartCheckpoint和TargetCheckpoint，两个时间戳的差值表示被监控的程序执行时间，检查执行时间是否超过预期范围
Logical Supervision	PHM中定义的一种监控措施，属于逻辑序列检查。它包含了多个CheckpointTransition，每个CheckpointTransition包含StartCheckpoint和TargetCheckpoint。多个CheckpointTransition收尾相接可以连成一个逻辑链，用于检查程序是否按照正常逻辑运行。链条可以有分叉，合并和循环等操作。
Elementary Supervision Status	根据AliveSupervision, DeadlineSupervision或LogicalSupervision的结果评估处的状态，它是有一个状态机在kDEACTIVED, kOK, kFAILED, kEXPIRED状态之间流转。每个Supervision都有自己的状态
Supervision Entity	是 PHM 中的一个基本概念，代表软件组件的一部分或全部，它可以是一个进程、线程或软件组件中的一个逻辑部分。Supervised Entity是监督的最小单元，它可以包含Alive Supervision、Deadline Supervision 或 Logical Supervision 中的一个或多个。
Global Supervision	Global Supervision 聚合了一组 AliveSupervisions, DeadlineSupervisions 或 Logical Supervisions 的状态。通常对应于单个Function Group内的一个或多个 Supervised Entities。Global Supervision 状态反映了其下所有 Elementary Supervisions的“最差状态”。
Global Supervision Status	描述了Global Supervision的Status，和Elementary Supervision Status类似，它也有一个状态机，在kDEACTIVED, kOK, kFAILED, kEXPIRED, kSTOPPED状态间跳转。它的转换基于其包含的 Elementary Supervision Status 的变化。
Supervision Mode	由于Checkpoint是打在各个被监控进程中的桩，不可改变。在不同模式下可能监控(Alive, Deadline和Logical)的参数有所改变。为了凸显在不同Function Group Status下不同的监控参数，在GlobalSupervision中设置了Supervision Mode参数，该参数关联了某些Function Group Status的特定的值，表示在Function Group Status某些状态下，该Global Supervision的监控会起作用。PHM会根据SM中Function Group Status的变化，切换不同的Global Supervision进行监控。确保了在Checkpoint不变的情况下，针对不同的场景切换对应的监控策略。
Health Channel	它用于提供有关系统（子）系统健康状况的信息。允许外部监测程序或软件组件报告其健康状况。这些健康状态可以是系统测试的结果、环境监测算法的结果(例如RAM，CPU Loading检测)，或者是操作系统或内核的状态。上面描述的名词基本都是程序流检测，而该通道用于检测系统的一些可量化的指标是否满足要求。Health Channel 使系统集成者能够将各种监测结果集成到 PHM 中，从而实现对系统健康状况的全面监督。
Health Channel Supervision	检查被监控的软件注册的Health Channel是否在限制范围内

Supervised Entities

SM通过Function Group协调整个软件的运行，在Function Group中有多个进程运行。PHM监控Supervised Entitys，每个Supervised Entity属于一个或部分进程中。从进程开始执行就开始了监控。

下图描述了这些监控概念的关系：



PHM提供了三种类型的监控策略监控Supervised Entity：Alive Supervision, Deadline Supervision和Logical Supervision。Supervised Entity的结果依赖于Elementary Supervision Status，每个Alive/Deadline/Logical Supervision都会有一个Elementary Supervision Status。而属于一个Global Supervision的所有Elementary Supervision Status将决定Global Supervision Status。

Global Supervision对应于一个功能组(Function Group)的全部或部分，一个Global Supervision可以包含对应于单个功能组内控制的进程的所有或某些Elementary Supervision。Elementary Supervision映射到Global Supervision具有灵活性,用户可以通过配置决定哪些Elementary Supervision属于哪个Global Supervision。但有以下限制：

构成一个Global Supervision的所有Elementary Supervision都对应于同一个Function Group内的控制进程.

一个Elementary Supervision只能属于一个全局监控。

下面的图可以很好的理解：





如果一个Checkpoint汇报给PHM，又如下配置：

该Checkpoint ref到NoCheckpointSupervision，或者

该Checkpoint所在的Supervision Entity配置为NoSupervision

在与进程正在执行的Function Group Status对应的Supervision Mode下，PHM应该忽略检查点的报告。

如果汇报的进程和汇报的检查点不一致，则忽略。例如本来是进程A要汇报的Checkpoint，结果进程B汇报了这个Checkpoint，则忽略。

开始/停止Supervisions

一旦相应进程报告“执行状态为kRunning”，PHM应立即启动Supervised Entity实例的AliveSupervision的第一个aliveReferenceCycle。进程报告执行状态kRunning的信息由EM提供。

对于Alive Supervision，如果在被监督的进程进入kRunning之前收到了检查点的报告，应该忽略掉。对于Deadline Supervision和Logical Supervision则不受kRunning的影响，他们可以在被监控进程进入kRunning之前就开启监控。

一旦PHM受到了来自EM的消息被监控的进程即将停止运行，或者进程已经停止运行了，PHM应该停止所有的监控策略。

如果被监控的进程是一个自终止进程，自终止的进程不需要SIGTERM信号就会自己停止，因此有必要记录进程开始停止的时间点，让Alive监控能够停止。自终止进程在停止运行前使用了terminatingCheckpoint。此外，PHM收到terminatingCheckpoint后，必须添加一个超时，用于检查进程是否在报告terminatingCheckpoint后的timeout时间内终止。这个此超时检查是为了监视进程在执行终止过程中没有卡住导致无法终止。如果自终止进程没有在有效时间内停止运行，PHM会把这个失败汇报给SM。如果在timeout到一半时，收到了EM汇报的该进程的SIGTERM信息，则立即停止timeout。这是因为一旦EM发送SIGTERM给该进程，EM会监控它的停止timeout。

PHM一旦接受了自终止进程报告的 terminatingCheckpoint，或者EM通知的停止信号，会立即停止Alive Supervision。如果被监控的自终止进程使用了AliveSupervision，但它终止的时候，PHM没收到它的terminatingCheckpoint或者来自EM的SIGTERM，PHM会通知该失效到SM。

Health Channel Supervision

通过使用Health Channel Supervision，用户可以把一些外部监控结果纳入PHM的管理范畴。例如系统的CPU Loading, RAM test等。

Health Channel可以实现：

受监管软件的Global Supervision Status。

环境监测算法的结果。例如电压监测、温度监测。

内存完整性测试程序的结果，例如RAM测试、ROM测试。

操作系统或内核的状态。例如OS状态、内核状态。

另一个平台实例或虚拟机或ECU的状态

每个HealthChannel通过抽象化的Health Status将结果回报给PHM，不同的HealthChannel可以拥有不同的Health Status。Health Status的初值在配置Health Channel时通过HealthStatusInitValue配置项指定。HealthStatus通过PHM提供的接口ReportHealthStatus进行汇报。

Supervision Mode

在AP系统中，Supervision Mode根据Function Group State的改变而改变。Function Group State改变会在以下方面影响进程：

有些进程停止运行

有些进程开始运行

有些进程重新执行

有些进程继续保持执行

PHM中这些进程中关联的Supervised Entities也需要进行同步的变化。

对于停止运行的进程，Alive/Deadline/Logical Supervision应该停止监控，监控结果应该设置为正确。

对于开始运行的进程，在新的Function Group State下，根据Supervision Mode找到对应的Global Supervision，配置相关Alive/Deadline/Logical Supervision的参数，开始监控。

如果新运行的进程属于NoSupervision的配置，那么该进程将不会执行任何形式的监控。尽管可以在某些Supervision Mode中排除。但是在进程执行期间，不支持动态的在监控启用和禁用之间动态切换，该设置直到进程结束。监控禁用可以从进程开始执行时对应的Function Group State对应的Supervision Mode开始应用。所以如果某些进程在Mode切换过程中监控需要启用或禁止，该进程必须重启。



重启的进程监控，因为Function Group State改变导致重启的进程的监控，可以理解为进程先终止，然后再启动进程。

继续监控的进程，这部分进程的监控确保在两个Function Group State切换中，监控参数不会有任何改变。

Supervision Status

Global Supervision Status的结果由Alive Supervision, Deadline Supervision和Logical Supervision的Elementary Supervision Status一起决定。

Elementary Supervision Status

每个Alive Supervision, Deadline Supervision和Logical Supervision都有一个Elementary Supervision Status，它的结果基于两点：

Elementary Supervision Status当前状态

Supervision的当前结果

Elementary Supervision Status是一个状态机，有如下状态：kOK, kDEACTIVATED, kEXPIRED和kFAILED，其中kFAILED只和Alive Supervision相关。状态跳转见下图。

Status的初始化，Status的初始化值为kDEACTIVATED，对于AliveSupervision，failedAliveSupervisionReferenceCycles的值为0. (1)

保持kOK状态，如果Status为kOK状态，并且所有的监控状态都正常，则会继续维持在kOK的状态。

kOK状态到kEXPIRED状态，如果当前Status为kOK状态，并且：


Alive Supervision检测到永久性失效，例如失效次数超过了failedReferenceCyclesTolerance的限制(2)，或者

Deadline/Logical Supervision的结果不正确(2)


kOK状态到kFAILED状态，该状态转化仅适用于Alive Supervision。当前Status为kOK状态，并且Alive Supervision检测到了临时失败，会进入该状态。例如检测失败的次数大于0，并且小于failedReferenceCyclesTolerance的限制(3)。

保持kFAILED状态。当前Status为kFAILED状态，并且AliveSupervision失败次数没有超过failedReferenceCyclesTolerance的限制，会停留在该状态

kFAILED状态到kOK状态，当前Status为kFAILED状态，并且没有失败的Alive Supervision(5).

kFAILED状态到kEXPIRED状态，当前Status为kFAILED状态，并且Alive Supervision检测到永久性失效，例如失效次数超过了failedReferenceCyclesTolerance的限制(6)。

kOK状态到kDEACTIVATED状态，当前Status为kOK状态，并且PHM收到了被监控的进程即将停止或者进程已经停止。状态会切换到kDEACTIVED，并且failedAliveSupervisionReferenceCycle被设置为0.

kFAILED到kDEACTIVATED 状态，当前Status为kFAILED状态，并且PHM收到了被监控的进程即将停止或者进程已经停止。状态会切换到kDEACTIVED

保持kDEACTIVATED 状态，当前Status为kDEACTIVATED状态，或者有Supervision Mode跳转，下面的操作可能造成无法保持kDEACTIVATED状态：


对于AliveSupervision，对应的进程报告执行状态为kRunning

对于Deadline Supervision和Logical Supervision，任何监控中的checkpoint被汇报


kDEACTIVATED 状态到kOK状态，当前Status为kDEACTIVATED状态，并且Supervision Mode跳转，下面的操作可能导致跳转：


对于AliveSupervision，相关的进程报告执行状态为kRunning

对于Deadline Supervision，第一次收到Checkpoint

对于Logical Supervision，第一次收到Checkpoint并且这个Checkpoint是正确的


kEXPIRED状态到kDEACTIVATED状态，如果当前状态为kEXPIRED，并且Status的状态和OS，EM或者SM无关。并且PHM收到了EM被监控进程将要停止运行的通知或者进程已经停止了，PHM会将状态切换到kDEACTIVATED(4)。如果涉及到OS, EM或SM监控失败，则认为切换到kDEACTIVATED状态无法解决问题，会通过硬件看门狗重启解决。

保持kEXPIRED 状态，如果Status为kEXPIRED状态，并且在满足kEXPIRED状态到kDEACTIVATED状态条件之前，都会停留在该状态。

kDEACTIVATED状态到kEXPIRED状态，如果Status为kDEACTIVATED状态，对于Logical Supervision，第一个Checkpoint就失败了，PHM会跳转到kEXPIRED

Global Supervision Status

Flobal Supervision Status是由一系列的Alive/Deadline/Logical Supervision的Elementary Supervision Status的结果聚合而成。它包含了所有Elementary Supervision Status的最差的结果。

Global Supervision Status和Elementary Supervision Status有类似的值，Global Supervision Status多了一个kSTOPPED值。当状态到达kEXPIRED时，PHM向SM报告失效。状态kSTOPPED仅用于严重失败，它会直接使用看门狗复位，一般只有涉及到OS, SM和EM的监控失败才会导致进入该状态。进入kSTOPPED状态后，还有一个timeout时间expiredSupervisionTolerance，可用于在复位前清理数据。

状态跳转如下图所示，基本逻辑和Elementary Supervision Status类似，一般都是取Elementary Supervision Status最差值作为该状态的结果。



Recovery actions

PHM用于监测在平台上运行的进程，向SM报告他们的失效。如果失败来自于SM，则通过看门狗恢复它。



Notify SM

当Global Supervision Status进入kFAILED状态后，需要通知SM，SM会根据情况进一步处理，大多数情况是将Function Group切换到其他状态。

根据功能安全的考虑，PHM需要确保SM收到了检测到失败的通知。PHM设置了一个timeout，监测RecoveryHandler的返回，如果没有及时返回，PHM将通过错误喂狗或停止喂狗触发重启。RecoveryHandler的参数executionError应该包含对应的Function Group和ProcessExecutionError。参数supervision应该包含进入kEXPIRED状态的Supervision的类型。

如果Health Status的状态改变需要通知SM，则通过RecoveryHandler 通知SM，参数healthStatusId应该根据方法ReportHealthStatus获得。因此哪些状态的变化需要通知SM，需要用户自行配置。

如果通过RecoveryHandler接口向SM报告后没有在timeout时间内收到SM的ack，PHM应该停止调用WatchdogInterface::AliveNotification，改为调用WatchdogInterface::FireWatchdogReaction。

Handling of HW Watchdog

PHM是AP模块中唯一一个能够调用硬件看门狗的模块。PHM能够通过停止喂狗或错误喂狗触发芯片重启，它影响整个软件的运行，因此只能作为最后的手段使用，以确保不受干扰。

PHM通过WatchdogInterface操作看门狗，它会周期性的喂狗。如果PHM没有在配置的时间内喂狗，会导致芯片重启。
Configuration Parameters

PHM的recovery action只有一个参数：

recoveryNotificationTimeout: PHM在发送notification后等到SM返回ack的最长时间

Manifest Elements

该Manifest主要用于工具链配置xml文件，它的配置有助于理解PHM中各个实体之间的联系。

AliveSupervision

aliveReferenceCycle	它描述了一个时间段，在这个时间段中，会比较预期检查点个数和实际检查点个数。例如在一个10ms的周期任务重，如果该参数设置为1000，则预期的点数为100
checkpoint	ref到对应的CheckPoint
expectedAliveIndications	描述了在aliveReferenceCycle时间段内，应该收到预期的检查点个数
failedReferenceCyclesTolerance	它描述了能够容忍的aliveReferenceCycle不达标的次数，当达到上限后，会进入kEXPIRED状态
maxMargin	实际点数小于等于(expectedAliveIndications  + maxMargin)为正常
minMargin	实际点数大于等于(expectedAliveIndications  - minMargin)为正常
terminatingCheckpoint	ref到CheckPoint，它被定义为此AliveSupervisory的terminating  checkpoint。当自我终止进程准备终止时，它将报告一个名为 terminatingCheckpoint 的检查点，以通知 PHM 它将开始终止过程
terminatingCheckpointTimeoutUntilTermination	在Supervised Entity 报告了一个特定的检查点（  terminatingCheckpoint）之后，PHM 等待进程实际终止的时间。如果在超时时间内，进程没有实际终止，PHM  将认为发生了错误，并可以将此失败情况通知给 SM

DeadlineSupervision

maxDeadline	Dadline监控的最长的时间段
minDeadline	Dadline监控的最短的时间段
transition	CheckpointTransition  ref了SourceCheckpoint和TargetCheckpoint。通过它可以获得两次检查点消耗的时间，判别DeadlineSupervision是否通过

LogicalSupervision

finalCheckpoint	结束检查点，可以配置多个Checkpoint作为初始检查点。该配置可以ref到多个Checkpoint作
initialCheckpoint	初始检查点，可以配置多个Checkpoint作为初始检查点。LogicalSupervision  始终从初始检查点开始。该配置可以ref到多个Checkpoint
transition	每个  CheckpointTransition  定义了从SourceCheckpoint到TargetCheckpoint的转换。LogicalSupervision通过一系列的CheckpointTransition将检查点串联起来。其中允许进行分叉和合并。理论上支持循环

NoCheckpointSupervision

checkpoint

它ref了一组特定的  SupervisionCheckpoints，这些检查点不应该被任何SupervisionEntity所监督。该类可以用来优化监督配置，通过排除那些不需要监督的检查点来减少系统的复杂性和监督开销

NoSupervision

process	指定哪个进程或进程实例不应受到  Alive Supervision、Deadline Supervision 或 Logical Supervision  的监督。如果这个参数被设置，那么与之关联的进程将不会被 PHM 监督。
targetPhmSupervisedEntity	一个实例引用，指向一个  RPortPrototype，该 RPortPrototype 表示一个特定的 Supervised Entity  实例。通过这个参数，NoSupervision 可以精确地指定不需要被监督的 Supervised Entity 实例。

SupervisionMode

activeSupervision	在该SupervisionMode中，有哪些Supervision被激活，包括AliveSupervision,  DeadlineSupervision, LogicalSupervision。可以ref多个
expiredSupervisionTolerance	当GlobalSupervision到了kSTOPPED状态时，需要通过看门狗复位。在复位前等待的时间。该时间能够给系统一些后处理时间，保存数据等。
modeCondition	参数是一个引用，指向一个  SupervisionModeCondition 对象，它定义了触发当前 SupervisionMode 配置的条件或情境。

GlobalSupervision

alive  Supervision	当前GlobalSupervision监控的alive  Supervision的集和，
deadline  Supervision	当前GlobalSupervision监控的deadline  Supervision的集和，
logical  Supervision	当前GlobalSupervision监控的logical  Supervision的集和，
noCheckpoint  Supervision	不需要进行监督的CheckPoint所在的NoCheckpointSupervision集和
noSupervision	当前GlobalSupervision中NoSupervision的集和
supervision  Mode	GlobalSupervision在哪些SupervisionMode下使用
transition	在当前GlobalSupervision中使用的CheckpointTransition的集和

HealthChannel

recoveryNotification

ref了该healthChannel使用的RecoveryNotification

HealthChannelExternalStatus

healthChannel	ref到一个HealthChannel
notifiedStatus	他是一个聚合属性，它包含了一组  HealthChannelExternalReportedStatus  对象。这些对象定义了当HealthChannel的状态发生变化时，哪些状态将触发状态管理的 Recovery Notification
process	定义需要HealthChannel需要监控的进程，当进程中的状态发生变化时，它会通过  HealthChannelExternalStatus 报告状态

总结

PHM模块实现了程序流监控和状态监控。Alive/Deadline/Logical Supervision都是通过打桩的形式对程序流的监控。而Health Channel则可以对程序运行产生的结果，OS相关结果或系统运行状态进行监控，HealthChannel极大的扩展了AP架构和非AP软件的兼容性，能够尽量的将非AP的软件纳入监管范围，对于AP的推广有很多作用。

程序流监管中，将打桩和监管分开，被监控的程序进行打桩，而监控的操作则由PHM统一管理。同时将PHM和Function Group State进行绑定，一旦Function Group State发生改变，在不动Checkpoint的基础上，只需重新配置一个Global Supervision，就可以实现另一套配置进行监管。这样的监管可以根据系统软甲不同的运行状态实施不同的监管策略，更加的灵活。