摘要

如果留意过飞机失事以后的新闻报道，你会注意到，除了第一时间搜救幸存者，搜救队还会花大力气地毯式地查找黑匣子的下落。那么什么是黑匣子？对我们嵌入式产品有哪些借鉴意义？如何打造自己的黑匣子？

1. 什么是黑匣子

除了飞机以外，轮船，火车，汽车也有类似的装置。黑匣子主要是用于记录行驶的数据信息，以飞机为例，它里面记录了：

驾驶员座舱中驾驶人员从飞机起飞到着陆的相互对话以

飞行时的各种数据，如各类传感器的测量数据，故障信息等。

有了这些数据信息以后，我们就可以在飞机维护检修时，通过数据分析，纠正飞行员的不良驾驶情况，监控、预测飞机主要部件的健康状态，预防事故的发生；在发生事故以后，判定事故发生的原因，避免同类事故再次发生。

     类似地，在嵌入式或者纯软件产品中，也有许多类“黑匣子”的设计。例如，下图为Windows事件管理器中的其中一条日志，里面详细记录了这条日志的类别，发生时间，事件级别等信息。这样在排查问题的时候就一目了然了。

例如，微信公众号后台的统计信息，记录各种类型的数据，可以方便运营人员了解粉丝们的偏好。

再比如，手机的耗电历史趋势，以及耗电排名，方便用户有针对性地进行耗电优化设置。

2. 如何设计产品的黑匣子

了解了黑匣子的作用，那么我们就可以着手准备和设计自己产品的黑匣子。

如上图所示，我觉得可以根据实际产品使用的芯片和外部资源的情况，选择上述的一种或者多种类型的数据进行保存与上传，充当我们自己产品的黑匣子。

2.1 事件记录

我们可以事先识别和定义产品的关键性诊断事件，例如电流电压温度等异常，开关机动作等。但是如何才能完整识别产品中所有有价值的诊断事件呢？可以参考下图。

传感器和执行器这块，不妨借鉴下汽车中OBD的方法，总体来说在OBD中，它把嵌入式产品的故障分为以下几类：

- 硬件范围高：即超出硬件可以量测的范围，例如电压采样线路最高只能采样到10V，但是实际MCU采样到15V

- 硬件范围低：即超出硬件可以量测的范围，例如温度传感器只能采样到-20℃，但是实际MCU采样到-30℃。

- 硬件间歇性故障：即采样或者状态不合理地跳变，例如非工作模式下，温度采样连续跳变，那么说明可能是线路上接触不良。

- 合理性范围高：即超出从产品角度考虑的高限值，例如LPF电芯电压高于3.8V，那么我们就禁止充电。

- 合理性范围高：即超出从产品角度考虑的低限值，例如LPF电芯电压高于2.6V，那么我们就禁止放电。

再来说说上图中的事件属性：

- ID：事件的编号，通过编号就能确定事件的名称，这样可以避免存储和上传大段的字符；

- 可能原因：事件发生的原因可能有多个，我们可以根据条件判断记录发生时刻的具体原因；

- 发生的模块：如果在产品中多个模块都有同样的事件，可以增加这一属性，记录是哪一个模块发生；

- 级别：根据事件的优先级或者严重度等级做好归类，方便后期进行事件筛选；

- 时间：事件发生的时间，方便后续维护与确认；

- 特定数据：记录事件发生时相关数据，例如BMS产品电池过流事件发生时，记录此刻电池电芯的电压，电流，温度，状态等数据，方便后续人员排查原因。

2.2 特定时刻的数据

如果资源够用，或者产品有网络功能能够上传到云端服务器，可以周期性的上传/存储产品运行数据（电流，电压，温度，用户操作，当前模式等），方便进行用户行为，工况等方面的大数据分析。

2.3 统计类数据

顾名思义，这块负责进行记录统计类的一些数据。例如，电源类产品可以统计停留在不能模式下的时长，累计放出了多少功率的电量，开关机次数；BMS类的产品可以统计累计充电的AH量，充电次数，平均电流，平均温度，均衡次数等等。

本期先到这，欢迎扫码关注本公众号。

转载是一种动力 分享是一种美德