← Volver al índice

Incidente aeroespacial - 1999

Mars Climate Orbiter

La sonda Mars Climate Orbiter se perdió por una inconsistencia de unidades entre sistemas de software. El fallo fue un ejemplo clásico de integración deficiente y validaciones insuficientes en misiones críticas.

Tipo de sistema Orbitador de exploración
Criticidad Aeroespacial - Misión crítica
Impacto Pérdida total de la misión

Identidad y contexto

Base del caso

La navegación interplanetaria requiere una coherencia absoluta de unidades.

1) Identificación del caso

  • Nombre del sistema: Mars Climate Orbiter.
  • Organismo responsable: NASA / JPL, con contratistas externos.
  • Año del incidente: 1999.
  • Área: Aeroespacial, navegación y control orbital.

2) Contexto previo

  • Qué hacía el software: calculaba trayectorias y correcciones de impulso.
  • Problema real: insertar la nave en una órbita estable alrededor de Marte.
  • Entorno: misión crítica, coordinación entre equipos y proveedores.
  • Complejidad: sistema distribuido con integración de telemetría y control.

Naturaleza del bug

Qué falló y cómo se observó

Un módulo usaba unidades inglesas mientras el resto esperaba unidades métricas.

3) Descripción del bug

  • Tipo de error: conversión de unidades / validación insuficiente.
  • Localización: cálculo de impulsos en el software de navegación.
  • Lenguaje y componente: módulos de control terrestre y software de vuelo.
  • Cómo se introdujo: integración de subsistemas con supuestos distintos.

4) Cómo se manifestó

  • Síntoma visible: trayectoria más baja de lo previsto.
  • Error sistemático: cada corrección acumulaba el desfase de unidades.
  • Dependencia: comandos de impulso calculados en libras-fuerza vs newtons.
  • Reproducción: evidente en simulaciones integradas con unidades mixtas.
  • Ejemplo: se esperaba un ajuste de 10 N, pero se aplicaban 10 lbf.

Impacto

Consecuencias, costos y personas

La nave ingresó demasiado bajo y se perdió en la atmósfera marciana.

5) Consecuencias directas

  • Pérdida de control y comunicación con la nave.
  • Interrupción completa de la misión.
  • Datos científicos no recolectados.

6) Impacto económico

  • Pérdidas estimadas: cientos de millones de USD.
  • Costos de reparación: reemplazo de misión y revisiones internas.
  • Impacto reputacional: escrutinio sobre la integración de software.

7) Impacto humano

  • No hubo lesiones ni fallecimientos.
  • Impacto social: frustración en la comunidad científica.
  • Impacto legal: auditorías y revisiones de contratos.

Causas y organización

Raíz técnica y fallas de ingeniería

La integración falló en lo más básico: hablar el mismo idioma de unidades.

8) Causa raíz (Root Cause Analysis)

  • Defecto técnico puntual: uso de unidades inglesas en un módulo clave.
  • Combinación de errores: falta de validación cruzada en integración.
  • Mala interacción software-hardware: comandos incorrectos a sistemas de impulso.
  • Falta de pruebas en condiciones integradas de extremo a extremo.

9) Fallas de ingeniería organizacional

  • Falta de revisión por pares entre equipos de contratistas.
  • Ausencia de estándares estrictos de unidades en integración.
  • Documentación insuficiente y controles de interfaz pobres.
  • QA limitado a pruebas parciales, no sistémicas.

Detección y respuesta

Cómo se descubrió y se reaccionó

La pérdida de telemetría fue el primer indicador de la falla.

10) Cómo se descubrió

  • Detección al perderse la señal durante la inserción orbital.
  • Investigación posterior en modelos de navegación.

11) Respuesta de la empresa

  • Comunicados públicos y reporte oficial de NASA.
  • Revisión de procesos de integración de software.
  • Refuerzo de estándares de unidades.

12) Cómo se arregló

  • Corrección de conversiones y validaciones de unidades.
  • Pruebas integradas con verificación de consistencia.
  • Mejoras en documentación y contratos de interfaz.

Aprendizajes

Lecciones y enfoque moderno

Unidades consistentes son un requisito funcional en misiones críticas.

13) Lecciones aprendidas

  • Validar unidades físicas en cada interfaz de software.
  • Diseño defensivo con chequeos de consistencia.
  • Pruebas de integración con datos reales y simulados.
  • Evitar suposiciones en datos externos.

14) Qué se haría hoy distinto

  • CI/CD con validación automática de unidades.
  • Observabilidad en telemetría con alertas de desviación.
  • Canary releases en simulaciones de vuelo.
  • Estándares regulatorios más estrictos para software aeroespacial.
  • IA para detectar incoherencias en integraciones.