T O P

[资源分享]     系统架构设计背后的不良涌现物

  • By - 楼主

  • 2021-07-13 14:01:32
  • 《系统架构》曾讲述了这样一个惊险案例:

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

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

    (图1 发动机反推的原理图 来源:知乎卢西的答案)

     

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

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

     

    (图2 反推开启后的实况 来源:知乎卢西的答案)

     

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

     

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

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

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

     

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

     

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

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

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

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

    所以探测器就摔碎了。

     

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

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

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

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

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

     

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

    -完-

    本帖子中包含资源

    您需要 登录 才可以下载,没有帐号?立即注册