← Volver al índice

Incidente aeroespacial - 1996

Ariane 5, Vuelo 501

El Ariane 5 se destruyó segundos después del despegue por una conversión numérica errónea en el sistema de referencia inercial. El caso es paradigmático sobre reutilización de software sin revalidación completa.

Tipo de sistema Vehículo de lanzamiento
Criticidad Aeroespacial - Tiempo real
Impacto Pérdida total del cohete

Identidad y contexto

Base del caso

Un sistema nuevo reutilizó software de otra misión con supuestos distintos.

1) Identificación del caso

  • Nombre del sistema: Ariane 5 Flight 501 - Sistema de referencia inercial.
  • Organismo responsable: Agencia Espacial Europea (ESA) / Arianespace.
  • Año del incidente: 1996.
  • Área: Aeroespacial, navegación y guiado.

2) Contexto previo

  • Qué hacía el software: calculaba actitud y trayectoria en vuelo.
  • Problema real: asegurar estabilidad en el ascenso y liberación de carga.
  • Entorno: misión crítica, sin margen de recuperación.
  • Complejidad: sistema embebido de tiempo real con sensores inerciales.

Naturaleza del bug

Qué falló y cómo se observó

Una conversión numérica fallida propagó valores inválidos al sistema de guiado.

3) Descripción del bug

  • Tipo de error: conversión de tipos / overflow.
  • Localización: software del sistema de referencia inercial (SRI).
  • Lenguaje y componente: Ada en firmware de navegación.
  • Cómo se introdujo: reutilización de código de Ariane 4 sin ajustes.

4) Cómo se manifestó

  • Síntoma visible: pérdida abrupta de control de actitud.
  • Error sistemático: activado por valores fuera de rango.
  • Dependencia: velocidad horizontal mayor que la prevista.
  • Reproducción: inevitable en el perfil de vuelo del Ariane 5.
  • Ejemplo: un valor de 64 bits truncado a 16 bits generó overflow inmediato.

Impacto

Consecuencias, costos y personas

El cohete se autodestruyó para evitar riesgos mayores.

5) Consecuencias directas

  • Pérdida de control de trayectoria y destrucción del vehículo.
  • Interrupción completa de la misión.
  • Decisiones automáticas erróneas del sistema de guiado.

6) Impacto económico

  • Pérdidas estimadas: cientos de millones de USD.
  • Costos de reparación: rediseño del software y retrasos de programa.
  • Impacto reputacional: fuerte impacto en la confiabilidad percibida.

7) Impacto humano

  • No hubo lesiones ni fallecimientos.
  • Impacto social: revisiones públicas de procedimientos de seguridad.
  • Impacto legal: investigaciones y auditorías técnicas.

Causas y organización

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

La reutilización de software se consideró segura sin validar nuevos rangos.

8) Causa raíz (Root Cause Analysis)

  • Defecto técnico puntual: overflow por conversión de 64 a 16 bits.
  • Combinación de errores: ausencia de chequeo de rango y supuestos heredados.
  • Mala interacción software-hardware: valores fuera de rango para el perfil nuevo.
  • Falta de pruebas en condiciones específicas del Ariane 5.

9) Fallas de ingeniería organizacional

  • Confianza excesiva en software reutilizado.
  • Falta de revisión por pares de supuestos numéricos.
  • Documentación insuficiente de límites operativos.
  • QA no orientado a escenarios nuevos de vuelo.

Detección y respuesta

Cómo se descubrió y se reaccionó

El fallo fue inmediato y se reconstruyó con telemetría de vuelo.

10) Cómo se descubrió

  • Telemetría mostró fallas simultáneas en el sistema inercial.
  • Investigación técnica posterior del código Ada.

11) Respuesta de la empresa

  • Suspensión temporal de vuelos del Ariane 5.
  • Informes públicos con análisis detallado.
  • Rediseño del software con chequeos de rango.

12) Cómo se arregló

  • Corrección de conversiones y validaciones de rango.
  • Pruebas extendidas con datos de vuelo reales.
  • Revisión de supuestos de reutilización de software.

Aprendizajes

Lecciones y enfoque moderno

Reutilizar software crítico exige revalidación completa.

13) Lecciones aprendidas

  • Validar rangos numéricos en sistemas críticos.
  • Diseño defensivo con chequeos de overflow.
  • Pruebas de integración con perfiles reales de vuelo.
  • Evitar supuestos heredados sin evidencia.

14) Qué se haría hoy distinto

  • CI/CD con simuladores de vuelo y verificación formal.
  • Observabilidad de telemetría para detectar valores fuera de rango.
  • Canary releases en vuelos de prueba.
  • Estándares regulatorios más estrictos en software aeroespacial.
  • IA para inspección de código y detección de overflow.