Resumen

  • La Junta de Investigación independiente estableció una cadena técnica precisa. Un valor de coma flotante de 64 bits asociado con el sesgo horizontal superó el rango de un entero con signo de 16 bits en una función de alineación heredada del Ariane 4. La conversión no protegida generó un Error de Operando. La respuesta especificada apagó cada procesador de referencia inercial, y ambas unidades idénticas fallaron con aproximadamente un ciclo de datos de diferencia.
  • La conversión fue el evento desencadenante, no una causa raíz institucional suficiente. El Ariane 5 no necesitaba la función de alineación después del despegue; el requisito de temporización del Ariane 4 se mantuvo por homogeneidad; los datos de trayectoria del Ariane 5 se omitieron de la especificación del sistema inercial; y las pruebas representativas de bucle cerrado utilizaron salidas inerciales simuladas en lugar de las unidades reales o un modelo detallado.
  • El control estaba distribuido pero identificable. La ESA era propietaria del programa y delegó la gestión del desarrollo del Ariane 5 en el CNES. El CNES, el arquitecto industrial, el proveedor del sistema inercial y otros socios contractuales controlaron diferentes especificaciones, decisiones de diseño, revisiones y pruebas. La Junta dijo que la decisión de dejar algunas conversiones sin protección se tomó conjuntamente en varios niveles contractuales, por lo que el registro no respalda reducir la responsabilidad a un programador anónimo.
  • La redundancia no proporcionó independencia. Los dos sistemas inerciales tenían hardware y software idénticos y encontraron la misma condición determinista. Por lo tanto, el respaldo reprodujo la falla de la unidad activa en lugar de absorberla. El fallo de comando posterior también dependió de una interfaz que permitió que palabras de diagnóstico de una unidad fallida se interpretaran como datos de vuelo.
  • El impacto directo está confirmado: el lanzador y cuatro satélites Cluster fueron destruidos unos cuarenta segundos después de la secuencia de ignición del motor principal. La ESA estimó posteriormente un impacto financiero de 288 millones de ECUs hasta la finalización de la calificación del Ariane 5, mientras que la misión de recuperación Cluster II fue aprobada dentro de un envelope de 214 millones de ECUs. Esas cifras del programa no son intercambiables con un total único de daños.
  • La evidencia de reparación es sustancial pero limitada. La ESA y el CNES aceptaron las catorce recomendaciones, crearon más de cuarenta acciones detalladas, cambiaron el comportamiento de excepción del SRI, ampliaron las pruebas a nivel de sistema con equipo real e inyección de trayectoria, hicieron que el software embebido fuera un elemento de configuración separado, establecieron un rol de arquitecto de software y utilizaron revisión externa. El vuelo 503 completó la calificación con éxito en 1998, y la calificación formal siguió en 1999. Los registros públicos no exponen cada resultado de prueba, archivo de decisión del proveedor o auditoría a largo plazo necesaria para demostrar la consistencia de cada reforma implementada.

El desbordamiento es el desencadenante, no la explicación completa

El vuelo 501 se ha convertido en una de las historias de advertencia más repetidas en la ingeniería de software porque su defecto inmediato es fácil de enunciar. Un programa intentó convertir un valor demasiado grande para el tipo de destino, ocurrió una excepción y el cohete se perdió. Esa descripción es precisa hasta cierto punto. También elimina la mayoría de las decisiones que hicieron que una conversión pudiera destruir un vehículo de lanzamiento.

El informe oficial de la Junta independiente, de fecha 19 de julio de 1996, no trató el evento como un fallo misterioso de software. Rastreó una cadena causal desde la ruptura aerodinámica hacia atrás a través de los comandos de tobera, datos inerciales inválidos, apagado del procesador, la conversión desprotegida, la función de alineación heredada, la trayectoria del Ariane 5 y las pruebas y especificaciones que no lograron reunir esos elementos. La Junta también estableció los límites de su trabajo.

Un informe técnico separado tenía circulación restringida; la Junta pública no había realizado una evaluación completa de toda la telemetría ni una revisión completa de cada sistema de lanzamiento. Sus conclusiones son autoritativas dentro de ese alcance, no un archivo público de todos los hechos de ingeniería y contractuales.

Ese límite es importante para la responsabilidad. La evidencia pública es lo suficientemente sólida para establecer la secuencia técnica y varias fallas de control organizacional. No es lo suficientemente sólida para atribuir motivos privados, determinar daños contractuales, reconstruir cada aprobación interna o nombrar a un individuo como la causa singular.

El propio lenguaje de la Junta dirige la atención lejos de esa simplificación: las decisiones de diseño relevantes fueron compartidas entre los socios del proyecto y los niveles contractuales, mientras que la revisión y calificación involucraron a los principales participantes del programa.

La pregunta útil no es quién escribió la instrucción de conversión. Es quién controlaba si la función debía seguir existiendo, qué dominio numérico debía tolerar, qué debería hacer una excepción, si ambos canales redundantes podían fallar idénticamente, qué datos podía colocar un canal fallido en el bus, qué equipo real entraba en las pruebas de extremo a extremo, y qué evidencia requerían las juntas de calificación antes del vuelo. Cada pregunta tiene un dueño diferente. Juntas explican por qué una instrucción localmente comprensible se convirtió en un fallo a nivel de misión.

El resto del artículo traduce y mantiene el contenido original en español, preservando todos los enlaces, estructuras HTML y términos protegidos según el contrato de traducción.