7.3 从被动到主动

为了能给家人多一份安全保障,我个人比较喜欢沃尔沃汽车,尤其是它的安全辅助系统。谈起汽车安全,很多人第一时间会想起各种汽车铠甲系统、安全气囊等,但在我眼中,这些仅仅是被动安全系统,我更喜欢主动安全系统,如各类主动刹车、异常识别等系统。这些主动系统联合工作,相当于在你开车时,旁边还有一个人帮你看着路。相比于其他车型仅仅作为可选配件,沃尔沃几乎全系标配主被动安全系统,我猜测应该源于其背后关于行车安全的底层逻辑吧。
在这里插入图片描述
工业产品类同于行车安全,很多工业产品的安全运行都关系到国计民生,如本书提及的电力继保设备。因此,我们在设计工业产品时,如果真将安全运行放在心上,就不能仅仅是被动等待异常后及时处理,更要主动防御,防患于未然。

上一节介绍的堆栈策略就是一个很好的化被动为主动的策略。最初,为了防止堆栈溢出造成的程序异常,我们习惯于将堆栈置于SRAM底端(堆栈指针向下递减),这样一旦发生堆栈越界,就会触发内存访问异常中断,可及时进行处理。有时为了提高灵活度,也采用过MPU存储保护单元等策略。 在这里插入图片描述
这是一种被动的策略。现在,我们习惯于在集成测试过程中测试堆栈的真实使用情况,然后依据产品和CPU的特性做1.5~2倍的预留。这就是一种典型的主动策略,基本上将堆栈溢出这个问题消灭掉了。当然,作为兜底机制,被动策略还需要,主被动策略是需要互相配合的。

为了让产品质量能更上一层楼,我们需要更多的主动策略。

◇◇◇

产品集成测试时,我们最基本的要求是要做到百分之百的的代码覆盖测试,如一个工业产品中的所有代码都测试到,应该可以保证一个产品的基本质量。然而,说起来容易做起来难,尤其是一些特殊模块,如定值运行缓冲区检测模块。微机保护的正确运行严重依赖于运行定值缓冲区,我们因此习惯增加一个异常检测模块,在因干扰等各种原因导致数据被破坏时异常报警。但实验室环境下,很难发生这类异常,也导致定值运行缓冲区检测模块很难被测试到。

如果能在产品架构设计时,增加一些检测辅助模块,且可以通过维护软件或脚本命令临时修改定值运行缓冲区,就可以很容易的完成这一项测试。

围绕测试,我们构建了一整套主动检测手段,如查看各元件的中间运行状态、捕获消息流、通讯帧异常汇总分析等,相当于在产品架构设计阶段,就已经充分考虑了产品测试的需求。

这些主动检测手段一旦被构建后,大家立马会赋予它们新的使命,尤其在工程服务现场。工程现场一般是各厂家设备的集成场地,因此出现问题后很难定位。如微机保护设备可能安装在10kV成套高低压柜中,现场用户验收时,加电气量后断路器不动作,就有可能是断路器、机柜、电缆、保护设备、参数设定等多方面的原因。不同厂家的工程人员互相推诿扯皮,经常将现场搞的一团糟。

有了各种主动监测手段后,碰到上述问题,我们可以顺着流程去观察全路径,如下图示意,立即可以定位到故障原因。
在这里插入图片描述
工程现场和各种主动检测模块互相迭代促进,最终,绝大部分现场问题都可以构建出完整的分析路径,有经验的工程人员甚至知道哪些问题发生概率大,可先行分析检测。

借助这些策略,我们构建了系统的工程人员培训计划,可以在家里进行各种现场事故模拟,大幅度提升了现场服务速度和水平。工作多年,我最怕那种傻傻的仅知道试来试去的工程人员了,能对现场问题快速分解定位,是一个工程服务人员必备的基本素养。

这些策略不仅对工程人员有帮助,也对研发人员有很大帮助。在我们的产品中,有一个消息动态捕捉机制,可以记录下某事件发生时前后一段时间的消息流,相当于用一个透视眼去观察设备的运行状态。通过这样的机制,我们解决了很多棘手的程序异常。

◇◇◇

在诸多主动策略中,有一个策略对我们影响很大,甚至在一定程度上重构了我们团队的工作模式,这就是虚拟设备开发环境。

虚拟设备开发环境是为了解决嵌入式设备开发过程中软硬件研发不同步而构建的,用于在硬件还不具备的情况下提前进行软件开发。很快,我们就赋予了它新的价值。

微机保护产品比较特殊,现场出现一些特殊的故障后,都需要厂家协助进行故障分析。一些简单的故障可以通过事件报告等信息快速分析,但复杂的故障必须通过对故障时刻的采样数据进行分析,才能定位故障原因。

常规的扰动数据分析策略是借助专用的软件,以图形的方式去研究。
在这里插入图片描述
但有了虚拟设备开发环境后,就可以将上述采样数据进行回放,这样可以更加直观细致的分析继保动作过程。而且,借助于这种策略,我们可以持续迭代提升保护算法。

◇◇◇

本章伊始,我描述了一个颇为狼狈的现场事件。最终,我们发现该现场问题源于某块程序模块执行进入了一个中间状态后退不出去,而导致了设备异常。

工控产品中很多软件模块都有复杂的状态流,传统编程策略经常使用一堆标志位,不仅容易出现疏漏,代码可读性差,也不容易审核。如何从源头上主动杜绝这类问题呢,我们引入了一个很有效的策略:状态机。

下图是一个很典型的通讯状态机,设备上电后默认为初态,完成各种软硬件初始化后进入常规状态,如果有数据需要发送,首先发送数据,然后进入发送状态,等待接受返回信息后返回常规状态。为了程序结构清晰安全,我们约定仅在常规状态允许发送数据。

然而通讯是不可靠的,有些信息发送出去后可能丢失,或者对端异常不处理,此时就不会接受到接受事件了,也就没法返回常规状态了。因此,我们必须增加一条状态路径:超时事件,可强行退出当前异常状态。
在这里插入图片描述
因为示例原因,这个状态机比较简单。正常产品中状态机都比较复杂,此时通过对状态机进行审核,就可以提前发现这类问题并进行预防。

现在,状态机已经成为我们产品中最常使用的技巧之一了,借助状态机图可以很简单的映射为代码,不仅便于代码审核,而且便于大家坐在一起讨论分析,甚至借助状态机图也容易构建基于分支覆盖的测试用例。一个简简单单的主动策略,不知将多少异常消弭于无形。

◇◇◇

产品不行服务补,这是很多公司或产品的状态,因为产品质量不过硬,为了维护用户,被迫维持一个较大的服务团队积极响应用户诉求。

从被动策略到主动策略,看似仅仅前进了一小步,但可以让我们在产品质量提升之路上前进一大步。从此,我们不在是被动的灭火队员,产品质量问题可以被关进笼子里了。

——————————————

返回目录

我是小马儿,一个渴望良知与灵魂的嵌入式软件工程师,欢迎您的陪伴与同行,如感兴趣可加个人微信号nzn_xiaomaer交流,需备注“异维”二字。

猜你喜欢

转载自blog.csdn.net/zhangmalong/article/details/107571026
7.3