<!--

• @Author: your name
• @Date: 2020-03-15 16:58:40
• @LastEditTime: 2020-03-20 15:17:35
• @LastEditors: Please set LastEditors
• @Description: In User Settings Edit
• @FilePath: \HX_DK_FOR_NORDIC_52840_BLE_MESH_PRIVATE\初出茅庐\Health Model浅析.md -->

前言

继上一章节Configuration Model浅析 之后，小编相信一直读我们文章的朋友现在已经知道如何通过Configuration Model去配置或者获取节点的相关参数；但是，如果想要进一步获取当前节点的“健康”状态，还是需要Health Model来处理；那么，这个时候又会有读者跳出来说：“在Configuration Model章节中不是有Heartbeat吗？为什么还要这个Health Model？”

那么，我们就讲解一下它们之间的区别：

• Heartbeat

  1. 最常用的就是告诉同一个Mesh网络的其他节点，我还"活"着，没有掉线；
  2. 同一个Mesh网络中接受到心跳包时，可以判断其离发送者有多远，从而配置合理的TTL值；

• Health Model

  1. 汇报当前节点的故障信息，例如："设备过热，就会发出过热的故障信息"，"设备电量不足，就会发出电量不足的故障信息"等等；
  2. 该模型在一定程度上，也可以使用Health Current Status来告之同一个Mesh网络的其他节点，我还"活"着，没有掉线；

总得来说，这两者是相互独立，又可以同时共存；只不是前者仅仅是侧重于节点是否正常工作，而后者不但能监控到节点是否工作，同时还能汇报是什么原因导致不能工作，也就是说可以提供更多的细节；

Health Server Model

该模型跟Configuration Server Model是一样的，也是SIG强制要求必须要有的一个模型，也就是说每个节点都会有至少一个Health Server Model；其主要的特性如下所示：

• 同样，该模型也是一个根模型

• 跟其他普通的SIG模型一样，该模型也支持发布与订阅的功能

• 跟Configuration Server Model不同的是，其不但可以存在于首要元素中，也可以存在于次要元素中；同时，还可以在一个节点的不同元素中同时存在

  

• 与该模型的通讯均采用AppKey加解密

• 其SIG Model ID为0x0002

那么，该模型又会有哪些状态呢？具体如下所示：

由上表可知，这些状态仅在首要元素中方有效，这也就是说当我们只能与对端设备在其首要元素中进行Health Server Model相关的配置通讯；同样的，既然有状态，那就务必会有对应的消息去获取或者配置该状态。具体有哪些消息，如下表所示：

Health Fault

这是一个综合的状态，其表示一个元素的警告或者错误情况；该状态由公司ID来标识，而且一个节点可能会存在多个公司ID；

Current Fault

该状态表示最近自检的测试项以及该测试当前可能存在的的警告和错误情况，具体的帧格式如下所示：

其中，Test ID的取值范围如下：

Vendor specific test的取值又分为两种情况：

• 0x01-0x7F

  该取值范围已经由蓝牙联盟规定好了，用于表示特定的警告和错误情况

• 0x80-0xFF

  该取值范围则是预留给设备制造商使用，用于它们特定的警告和错误情况

当没有警告或者错误情况，则FaultArray域的内容为空；但是，一旦有警告和错误情况产生，则相对应的信息则马上会在FaultArray中记录；一旦消失，则自动从FaultArray中移除；具体的Fault值如下表所示：

虽然在Spec中没有明确指出Standard Test以及Vendor Specific Test是哪些内容，但是我们从上述的故障错误信息可以间接地了解到，测试的内容是上述表格中的一个或者多个。

Health Current Status

该消息用于向外汇报元素当前的 “健康” 状态，其对应的帧格式内容如下表所示：

如Current Fault所述，如果没有故障或者错误情况，那么FaultArray域的值可以为空，但是如果有多个故障或者错误情况，那么FaultArray域就有多个值；其中Test ID和Company ID是用于定位供应商特定的哪个测试项以及哪个故障，这也就是说Health Fault基本上是跟Test ID和Company ID绑定在一起了。

除此之外，还有如下两点需要注意的：

• 当Publish Period State的值非0且任意Company ID的Current Fault Fault Array不包括任何记录时，那么Health Current Status就会每隔几秒主动发送一次，其中Company ID域填充的内容为Health Fault状态所支持的公司ID，而FaultArray域的内容直接为空；至于隔多少秒则由Publish Period State的值所决定；
• 当Publish Period State的值非0且至少存在一个Company ID的Current Fault Fault Array包含记录时，那么Health Current Status就会每隔几秒主动发送一次，其中Company ID域填充的内容为该包含记录的Company ID，而FaultArray域则填充存在的一系列故障；至于隔多少秒，此时则由Publish Period State的值除以2^^{Health Fast Period Divisor state} 所得的值决定，其中Health Fast Period Divisor state的取值为0~15；

其中Publish Period State跟在Configuration Model浅析中提及到的是一样的。

Registered Fault

该状态主要是用于备份Current Fault的故障信息，一旦在Current Fault中的FaultArray域有新增的信息都会在该状态的FaultArray备一份；但是，当从Current Fault中的FaultArray中移除信息时，该状态的FaultArray内容则不会同步移除，其需要专门的Health Fault Clear消息来移除；该状态的具体内容跟Current Fault是完全一样的。

Health Fault Get

该消息用于获取元素的公司ID所识别的当前Registered Fault状态信息，其帧格式如下所示：

同样的，其是一个带应答的消息，具体的应答内容如Health Fault Status所示。

Health Fault Clear

该消息用于移除元素的公司ID所识别的当前Registered Fault状态信息，除了操作码不一样，其他的帧格式内容跟上述的Health Fault Get是一样的；同样的，其是一个带应答的消息，具体的应答内容如Health Fault Status所示。

Health Fault Clear Unacknowledged

除了操作码以及不需要应答之外，该消息基本上跟上述的Health Fault Clear是一样的。

Health Fault Test

该消息用于执行一个元素特定实现的自测程序，其帧格式内容如下所示：

从上表的内容可以再次证明，Health Fault是跟Company ID和Test ID绑定在一起的；即不同的Company ID的Test ID对应的测试内容就不同，而Health Fault也就随着不同而不同。同样的，其是一个带应答的消息，具体的应答内容如Health Fault Status所示。

Health Fault Status

该消息用于应答上述的Clear、Get、Test消息，其内容基本上与Health Current Status一致；只不过该消息返回的是元素当前的Registered Fault state的内容。

Health Fault Test Unacknowledged

顾名思义，该消息跟上述的Health Fault Test的功能是一样的；只不过，该消息不需要应答，除此之外所有的内容都是一样的。

Health Period

该状态主要是配置Health Current Status发布的周期，其取值范围为0~15，具体的详情请参考Health Current Status内容所示。

Health Period Get

跟其他的Get消息一样，这是一个带应答的消息，用于获取元素当前的Health Fast Period Divisor状态值，应答消息如Health Period Status所示。

Health Period Set

跟上述的Get消息相反的操作，该消息用于设置元素当前的Health Fast Period Divisor状态值。具体的帧格式内容如下所示：

同样的，其应答消息如Health Period Status所示。

Health Period Set Unacknowledged

该消息除了不需要应答，其他均跟上述的Health Period Set是一模一样的。

Health Period Status

该消息主要用于应答上述的Get和Set消息，报告元素当前最新的Health Fast Period Divisor状态值，具体的帧格式内容如下所示：

Attention Timer

一看这个状态名，小编不知道还有没有读者对其有印象？该状态的作用我们在PB-GATT入网过程中已经讲解过，为了唤醒大家的记忆，我们这里贴一张图：

显然，该状态仅用于provisioning入网的时候使用，就是给予new device一个时间值，然后做出任何可以引起周边事物注意的动作时长为attention time秒；其中Spec对该状态作出了如下规定：

• 如果一个设备不支持Attention Timer，那么该状态值就必须为0；
• 如果一个设备支持该状态，那么其取值范围0x01~0xFF秒，同时采用可以被人识别的方式，如LED闪烁，振动等等来引起别人的注意；具体哪种方式，则根据具体的设备类型；
• 该状态值每秒就会减1，直至为0；

该状态对应的取值规定如下表所示：

Health Attention Get

该消息用于获取元素当前的Attention Timer状态值，应答的消息如Health Attention Status所示。

Health Attention Set

该消息是上述Get消息相反的操作，用于设置Attention Timer状态值，具体的帧格式如下所示：

同样其应答的消息如Health Attention Status所示。

Health Attention Set Unacknowledged

该消息除了不需要应答，其他均跟上述的Health Attention Set是一模一样的。

Health Attention Status

该消息主要用于应答上述的Get和Set消息，报告元素当前最新的Attention Timer状态值，具体的帧格式内容如下所示：

Health Client Model

该模型跟上述的Health Server Model一般都是成双成对的，用于发送Client命令查询或者配置对端设备的状态值；换句话说，无非就是Client用于发送配置或者查询命令，而Server用于接收命令并响应相对应的命令，基本上能有该模型的大部分都是Provisioner。其主要的特性大体跟Server是一样的，详情如下所示：

• 同样，该模型也是一个根模型
• 该模型不但可以存在于首要元素中，也可以存在于次要元素中
• 与该模型的通讯均采用AppKey加解密
• 其SIG Model ID为0x0003

至于，Client中的配置或者查询命令，小编已在Health Server Model中细述。

总结

Health Model主要用于监控节点的硬件物理状态，这就类似于我们平时在PC上运行鲁大师检测电脑的硬件有没有损耗等健康信息。至此，Foundation Model就已经全部讲解完毕，小编相信一直关注并深度阅读该序列文章的读者，势必对该基础模型已经了然于胸。