案例库 · 软件与 IT · 技术决策 · 1999
NASA 损失了一个 3.27 亿美元的火星探测器——因为两个团队用了不同的单位
洛克希德的软件说磅力秒,NASA 的软件说牛顿秒。没人做换算,探测器就飞进了大气层。
NASA · 洛克希德·马丁 · 1999-09-23
怎么回事
火星气候轨道器花了九个月,完美无瑕地飞了 6.69 亿公里——朝着错误的地方。洛克希德·马丁的地面软件用磅力秒报告推进器冲量,那是它的工程师一直用的英制单位。NASA 的导航软件把同样的数字读成牛顿秒,也就是接口规范实际要求的公制单位。于是每一次轨道修正都差了 4.45 倍。
这些误差很小,悄悄地累积。导航员在飞往火星途中注意到轨道在漂移,提出了担忧,但这个偏差从没被上报到一次正式审查。1999 年 9 月 23 日,轨道器开始入轨点火时,比计划低了 170 公里——扎进了火星大气层里,而不是在大气层之上——随后被烧毁,或被弹进了太空。信号再也没能重新捕获。
事故调查委员会的结论很直白:根本原因不是单位混淆本身,而是让它存活下来的流程——两个组织之间一个未经验证的接口,以及那些被注意到、被讨论过、却没有被处理的警示信号。
为什么会这样
- 软件接口规范要求公制;洛克希德的模块输出英制。没有人在边界上写或跑一个检查。
- 巡航期间发现了导航异常,却被非正式地处理,从没上报。
- 本可以发现这个不匹配的端到端测试,在进度压力下被跳过了。
- “更快、更好、更省”时代的人员配置,让导航团队人手单薄,审查更单薄。
代价3.27 亿美元的任务代价高昂
教训
团队之间的接口会悄无声息地失败。纸面上的约定毫无意义,除非有一台机器去检查真正跨过边界的实际数据。
后来呢
NASA 彻底改革了任务审查流程,明确规定必须使用公制,这一事件也成了地球上每一门工程课程里单位换算的经典反面教材——对一个从没机会工作的探测器来说,这是一份出奇有效的遗产。
资料来源
- Mars Climate Orbiter Mishap Investigation Board Phase I Report (NASA, 1999)
- Mars Climate Orbiter — NASA Science
发现哪里写错了?告诉我们。
类似的案例
这家公司栽倒的地方,别处有人漂亮地解开过。 第二意见 →

Comments · 0
登录 后就能评论。