返回档案库

案例库 · 软件与 IT · 技术决策 · 1999

NASA 损失了一个 3.27 亿美元的火星探测器——因为两个团队用了不同的单位

洛克希德的软件说磅力秒,NASA 的软件说牛顿秒。没人做换算,探测器就飞进了大气层。

NASA · 洛克希德·马丁 · 1999-09-23

怎么回事

火星气候轨道器花了九个月,完美无瑕地飞了 6.69 亿公里——朝着错误的地方。洛克希德·马丁的地面软件用磅力秒报告推进器冲量,那是它的工程师一直用的英制单位。NASA 的导航软件把同样的数字读成牛顿秒,也就是接口规范实际要求的公制单位。于是每一次轨道修正都差了 4.45 倍。

这些误差很小,悄悄地累积。导航员在飞往火星途中注意到轨道在漂移,提出了担忧,但这个偏差从没被上报到一次正式审查。1999 年 9 月 23 日,轨道器开始入轨点火时,比计划低了 170 公里——扎进了火星大气层里,而不是在大气层之上——随后被烧毁,或被弹进了太空。信号再也没能重新捕获。

事故调查委员会的结论很直白:根本原因不是单位混淆本身,而是让它存活下来的流程——两个组织之间一个未经验证的接口,以及那些被注意到、被讨论过、却没有被处理的警示信号。

为什么会这样

  • 软件接口规范要求公制;洛克希德的模块输出英制。没有人在边界上写或跑一个检查。
  • 巡航期间发现了导航异常,却被非正式地处理,从没上报。
  • 本可以发现这个不匹配的端到端测试,在进度压力下被跳过了。
  • “更快、更好、更省”时代的人员配置,让导航团队人手单薄,审查更单薄。
代价3.27 亿美元的任务代价高昂

教训

团队之间的接口会悄无声息地失败。纸面上的约定毫无意义,除非有一台机器去检查真正跨过边界的实际数据。

后来呢

NASA 彻底改革了任务审查流程,明确规定必须使用公制,这一事件也成了地球上每一门工程课程里单位换算的经典反面教材——对一个从没机会工作的探测器来说,这是一份出奇有效的遗产。

资料来源

发现哪里写错了?告诉我们。

Comments · 0

    登录 后就能评论。

    类似的案例

    这家公司栽倒的地方,别处有人漂亮地解开过。 第二意见 →