系统架构设计背后的不良涌现物

《系统架构》曾讲述了这样一个惊险案例：

一架A320客机试图在有侧风的情况下着陆。一般来说，客机降落时减速手段有舵面，发动机反推，机轮刹车，减速伞（排名不分先后）。

飞机着陆后，机长尝试使用发动机反推器减速，不料却不起作用，这是为什么呢？

（图1 发动机反推的原理图 来源：知乎卢西的答案）

 

这是因为：控制反推器的软件系统，基于安全原因，只有当它认为飞机确实已经“着陆”的情况下，才会打开反推器，而它判断飞机有没有着陆的依据，则是两侧的起落架是否全都压紧了。

但当时由于A320客机着陆时一侧机翼比较低，因此另一侧的起落架没有压下，这就导致软件系统判定飞机尚未着陆，因而选择不打开反推器。

 

（图2 反推开启后的实况 来源：知乎卢西的答案）

 

《系统架构》说，在这个案例中，每个部件当时都按计划执行着自己的功能，结果却发生了事故，试着理解并预估这种系统故障，也是系统思维的一项目标。

 

系统部件都做好了单元测试，然后组装起来，就能应对不良涌现物吗？很遗憾，不能。必须认认真真做好集成测试。

我以前就讲过下面这个经典案例：

NASA的“火星极地着陆者”于1999年12月3日坠毁于火星表面，原因也是每个部件都按计划忠实地执行自己的功能……

 

（图3 正在地面进行组装测试的火星极地着陆者号）

 

在发射前，有一个小组负责测试探测器的脚落地过程（leg fold-down procedure）。如果探测器的三个着陆支架触地了，那么制动发动机就会关机。

另一个小组则测试探测器着陆过程的其他部分，但这个小组的成员总是在开始测试之前重置计算机、清除数据位，所以测试一切顺利。

这两个小组的工作都没什么问题，但就是没有合在一起测试。

在真实飞行中，着陆支架伸展出来的这个动作产生了意外的信号，制动发动机以为已经触地了，于是在探测器距离火星表面还足足有40米的时候就提前关机了。

所以探测器就摔碎了。

 

对于预测涌现物，《系统架构》给出了三种方式：

第一种，根据以前做过的情况来预测。比如找到做过类似东西的人，把他们组成一个有效的团队，以此抵御风险。

第二种，做试验。甚至有时候需要构建高度结构化的原型。或者采用螺旋式开发，先把系统的某些部分构建出来，并检验其涌现物是否合意，然后再于后续的螺旋环节中逐次构建系统的其余部分。

第三种，建模。通过建模来预测涌现物并取得巨大成功的例子就是集成电路的开发。

如果系统既没有先例，又不能试验，而且无法可靠地建模，那就必须对将要涌现出来的功能进行推理了，最终还是必须依靠我们自己的判断力，愿上帝保佑。

 

关键词：涌现，系统架构，集成测试，单元测试，建模

-完-