debugging - que - Parches de software en un billón de millas
que es un parche de seguridad informatica (5)
Bueno, estoy seguro de que tienen simuladores para probar y mecanismos para aplicar hot-patching. Echa un vistazo al siguiente artículo vinculado: hay una muy buena descripción general del diseño de la nave espacial. La Sección 5 discute la maquinaria de cálculo.
http://www.boulder.swri.edu/pkb/ssr/ssr-fountain.pdf
De nota:
- Procesadores redundantes
- Cambio de comando por la tarjeta de enlace ascendente que no requiere ayuda del procesador
- Reglas de tiempo rezagado
¿Podría alguien aquí arrojar algo de luz sobre cómo la NASA va a diseñar su arquitectura de nave espacial para asegurarse de que son capaces de parchear errores en el código implementado?
Nunca he construido ningún sistema de tipo "en tiempo real" y esta es una pregunta que se me viene a la mente después de leer este artículo:
http://pluto.jhuapl.edu/overview/piPerspective.php?page=piPerspective_05_21_2010
"Una de las primeras cosas importantes que haremos cuando despertemos la nave espacial la próxima semana será cargar casi 20 correcciones de errores menores y otras mejoras de código a nuestro software de protección contra fallas (o" respuesta de piloto automático ").
No he trabajado en naves espaciales, pero las máquinas en las que he trabajado han sido construidas para tener un estado inactivo estable donde es posible apagar la máquina brevemente para parchear el firmware. Los sistemas que han acomodado actualizaciones "en vivo" son aquellos que se dividieron en componentes que interactúan, donde puede reducir un segmento del sistema el tiempo suficiente para actualizarlo y los otros componentes pueden continuar funcionando normalmente, ya que pueden tolerar el tiempo de inactividad temporal del componente revisado.
Una forma de hacerlo es tener capacidades paralelas (redundantes), como máquinas paralelas que realizan la misma tarea, de modo que el proceso pueda enrutarse alrededor de la máquina en servicio. El beneficio de este enfoque es que puede reducirlo por períodos más largos para un servicio más significativo, como el mantenimiento preventivo de hardware regular. Una vez que tenga esta capacidad, es relativamente fácil soportar el tiempo de inactividad para un parche de firmware.
Nunca he construido un sistema en tiempo real, pero en ese sistema, sospecho que su sistema no tendría mecanismo de protección de memoria. No lo necesitan, ya que ellos mismos escribieron su propio software. Sin protección de memoria, será trivial que un programa escriba la ubicación de la memoria de otro programa y esto se puede usar para aplicar hot-patch a un programa en ejecución (escribir un código de auto modificación era una técnica popular en el pasado, sin protección de memoria las mismas técnicas utilizadas para el código de auto modificación pueden usarse para modificar el código de otro programa).
Linux ha podido hacer parches menores en el kernel sin reiniciar durante algún tiempo con Ksplice. Esto es necesario para usar en situaciones donde cualquier tiempo de inactividad puede ser catastrófico. Nunca lo he usado, pero creo que la técnica que utilizan es básicamente esta:
Ksplice puede aplicar parches al kernel de Linux sin reiniciar la computadora. Ksplice toma como entrada un diff unificado y el código fuente del núcleo original, y actualiza el kernel en ejecución en la memoria. El uso de Ksplice no requiere ninguna preparación antes de que el sistema se inicie originalmente (el kernel en ejecución no necesita haber sido especialmente compilado, por ejemplo). Para generar una actualización, Ksplice debe determinar qué código dentro del núcleo ha sido cambiado por el parche del código fuente. Ksplice realiza este análisis en la capa de código de objeto ELF, en lugar de hacerlo en la capa de código fuente C.
Para aplicar un parche, Ksplice primero congela la ejecución de una computadora por lo que es el único programa en ejecución. El sistema verifica que ningún procesador estuvo en el medio de ejecutar funciones que serán modificadas por el parche. Ksplice modifica el comienzo de las funciones modificadas para que apunten a nuevas versiones actualizadas de esas funciones y modifique los datos y las estructuras en la memoria que deben modificarse. Finalmente, Ksplice reanuda cada procesador ejecutándose donde lo dejó.
(de Wikipedia)
Uno de los enfoques que se ha usado en el pasado es usar LISP.
He sido desarrollador de software de sistema de conmutación telefónica pública, que tiene restricciones bastante severas sobre la confiabilidad, disponibilidad, capacidad de supervivencia y rendimiento que se acercan a lo que necesitan los sistemas de naves espaciales. No he trabajado en naves espaciales (aunque sí trabajé con muchos antiguos programadores de transbordadores mientras estuve en IBM), y no estoy familiarizado con VXworks, el sistema operativo utilizado en muchas naves espaciales (incluyendo los rovers de Marte, que tienen un registro operativo fenomenal )
Uno de los requisitos básicos para la paridad es que un sistema debe diseñarse desde cero para el parcheo. Esto incluye la estructura del módulo, de modo que se puedan agregar nuevas variables y reemplazar los métodos, sin interrumpir las operaciones actuales. Esto a menudo significa que tanto el código antiguo como el nuevo para un método cambiado serán residentes, y la operación de parchado simplemente actualiza el vector de envío para la clase o módulo.
Es casi obligatorio que el software de parcheo (y desinstalación) esté integrado en el sistema operativo.
Cuando trabajaba en sistemas telefónicos, generalmente utilizábamos funciones de parcheo y reemplazo de módulos en el sistema para cargar y probar nuestras nuevas funciones, así como las correcciones de errores, mucho antes de que estos cambios fueran enviados para compilaciones. Todos los desarrolladores deben sentirse cómodos con los parches y el reemplazo de módulos como parte de su trabajo. Desarrolla un nivel de confianza en estos componentes y se asegura de que el código de aplicación y reemplazo se ejerza de manera rutinaria.
Las pruebas son mucho más estrictas en estos sistemas que cualquier otro que haya encontrado en cualquier otro proyecto. Maquetas completas y parciales del sistema de despliegue estarán disponibles. También es probable que haya entornos de máquinas virtuales, donde la carga completa se puede ejecutar y probar. Los planes de prueba en todos los niveles superiores a la prueba unitaria serán escritos y revisados formalmente, al igual que las inspecciones formales del código (y también serán rutinarias).
El diseño del sistema tolerante a fallas, incluido el diseño del software, es esencial. No sé específicamente sobre los sistemas de naves espaciales, pero algo así como los clústeres de alta disponibilidad es probablemente estándar, con la capacidad adicional de funcionar tanto sincronizados como no sincronizados, y con la capacidad de transferir información entre los lados durante una conmutación por error. Un beneficio adicional de esta estructura de sistema es que puede dividir el sistema (si es necesario), volver a cargar el lado inactivo con una nueva carga de software y probarlo en el sistema de producción sin estar conectado a la red del sistema o al bus. Cuando esté satisfecho de que el nuevo software se está ejecutando correctamente, simplemente puede realizar una conmutación por error.
Al igual que con la aplicación de parches, cada desarrollador debe saber cómo realizar cambios en la conmutación por error, y debe hacerlos durante el desarrollo y las pruebas. Además, los desarrolladores deben conocer cada problema de actualización de software que pueda forzar una conmutación por error, y deben saber cómo escribir parches y reemplazo de módulos que eviten las conmutaciones por error requeridas siempre que sea posible.
En general, estos sistemas están diseñados desde cero (hardware, sistema operativo, compiladores y posiblemente lenguaje de programación) para estos entornos. No consideraría Windows, Mac OSX, Linux o cualquier variante de Unix suficientemente robusto. Parte de eso son los requisitos en tiempo real, pero todo el tema de la confiabilidad y la capacidad de supervivencia es tan crítico.
ACTUALIZACIÓN: como otro punto de interés, aquí hay un blog de uno de los controladores de rover de Marte . Esto te dará una perspectiva de la vida diaria de mantener una nave espacial operativa. ¡Cosas ordenadas!