背景
目前硬件告警是针对末端器件进行告警的，比如风扇硬件访问不通就是风扇硬件告警；但目前存在一种场景，比如风扇硬件是经过pca9545分路后挂在不同通道上的，有的时候可能是pca9545硬件问题导致风扇硬件访问不通，但实际的告警还是风扇硬件告警，不够精确，需要结合日志、甚至是需要逻辑分析仪抓取波形分析才能定位到是pca9545硬件问题，因此需要一个能够精准标识出故障器件的属性，告警关联对应硬件状态属性，可以精确告警是链路上哪个硬件产生问题，快速定位问题，减少问题排查分析的成本。
属性变更流程：
状态变更跟随实际硬件访问，每次硬件访问根据硬件链路向硬件发送数据，链路上任意一级硬件访问失败就中断访问，并报错，现在需要做的就是在报错前根据访问结果和刷新策略刷新硬件的状态。假设topo如下：
Hisport
├──Pca9545_PCA9545
| └──Channel_1
| ├──Pca9555_IO
| └──Lm75_LM75
└──Eeprom_3_3
状态切换图：
器件未访问时，状态处于255；比如Lm75刚上树，Lm75访问状态就是初始的255.
器件访问成功时，本级器件及前级器件访问状态刷新为0；比如访问Eeprom后，硬件返回成功，则将Eeprom状态更新为0。
器件访问失败时，本级器件状态刷新为1；比如Pca9555访问时，需要先打开通道再访问，打开通道就需要先访问Pca9545发送数据，若此时Pca9545访问失败，整个硬件访问中断，并将Pca9545的状态更新为1。
决策点
在bmc.kepler.Chip接口下新增属性AccessStatus表示当前器件访问状态
详细描述
1、新增属性
资源path：
/bmc/kepler/Chip/Ads78/:Id
/bmc/kepler/Chip/CanbusChip/:Id
/bmc/kepler/Chip/Complex/:Id
/bmc/kepler/Chip/Cpld/:Id
/bmc/kepler/Chip/CpldChip/:Id
/bmc/kepler/Chip/CpldRegister/:Id
/bmc/kepler/Chip/Eeprom/:Id
/bmc/kepler/Chip/Lm75/:Id
/bmc/kepler/Chip/Pca9544/:Id
/bmc/kepler/Chip/Pca9545/:Id
/bmc/kepler/Chip/Pca9555/:Id
/bmc/kepler/Chip/Rtc/:Id
/bmc/kepler/Chip/Smc/:Id
/bmc/kepler/Chip/Vrd/:Id
资源interface：bmc.kepler.Chip
变化类型：新增
应用场景：
HealthStatus：记录器件访问状态
持久化类型： 不持久化
操作权限：ReadOnly
详细描述：
| 属性名称 | 变化类型 | 签名 | 读写&权限 | 持久化 | 变化通知 | 接口说明 | 接口约束 |
|---|---|---|---|---|---|---|---|
| AccessStatus | 修改属性 | y | ReadOnly | NA | true | 记录器件访问状态 | 1）取值定义：[0：器件访问正常；1、器件访问异常；255：初始值] |
评审结论
不同意bmc.kepler.Chip接口新增属性AccessStatus，使用已有属性HealthStatus表示器件健康/访问状态，修改HealthStatus默认值为0，取值定义：0 - 器件访问正常，1 - 器件访问异常
遗留问题及确认结论
1、确认HealthStatus目前在CSR的配置和使用情况，以及硬件代理是否使用，修改默认值的影响是什么。
结论：已排查目前CSR配置的仓，包括产品仓和vpd仓，目前对HealthStatus只有在部分chip里配置了0，目前只有少数Fru对象有同步该属性，且Fru同步后未在代码内使用，使用无影响，仅需将默认值修改为0，保证初始状态默认为成功。