¿Cómo se prueba el software utilizado en los sistemas críticos de vida o muerte?

Un avión, a diferencia de, por ejemplo, un sitio web, es un sistema en el que cualquier falla en ciertos sistemas es completamente inaceptable, ya que los errores, por ejemplo, en la supervisión del vuelo pueden hacer que el piloto automático no funcione correctamente y se hunda. Obviamente, esto no sucede ya que los brillantes ingenieros de Boeing y Airbus tienen controles en el piloto automático para asegurarse de que no decida repentinamente que una inmersión es una maniobra perfectamente aceptable y segura. O tal vez la computadora se cuelga, y los pilotos en el avión más nuevo ya no pueden volar el avión. Por supuesto, hay varios procedimientos de seguridad y redundancias integrados en estos sistemas para evitar un choque (tanto del software como de la aeronave).

Sin embargo, por otro lado, es bastante obvio que el software no es perfecto: tanto el software de código abierto como el de código cerrado se bloquean regularmente, y solo el programa más simple "Hello World" no falla. ¿Cómo pueden los ingenieros que diseñan los sistemas de software en las industrias aeronáutica, médica y de vida o muerte logran probar su software para que no falle (y si falla, al menos falla con gracia)?

_{Espero desesperadamente que no todos vayan a ir: "¡Oh, trabajo para Boeing / Airbus / (alguna otra compañía) y no lo es! Diviértase en su próximo vuelo / visita al hospital".}

He trabajado mucho en controles industriales. No tiene que estar en una industria gloriosa como la aeroespacial. Casi todas las máquinas industriales tienen suficiente energía potencial para causar lesiones graves o la muerte. He estado cerca cuando la gente resultó herida. Si pasa la mayor parte de su tiempo en un escritorio en una oficina, probablemente se sorprenderá de lo peligrosos que pueden ser la mayoría de los trabajos de fábrica (y ciertamente fueron hasta hace poco). Ahora tenemos mejores métodos de protección de la máquina. Así es como funciona en la práctica (aunque varía de jurisdicción a jurisdicción):

Hay estándares de OSHA en los EE. UU., Y pautas similares (generalmente más estrictas) en la UE. Por lo general, comienzan por exigirle que haga un análisis del riesgo. Esto significa que usted hace una lista de todos los peligros y luego los clasifica, teniendo en cuenta cosas como con qué frecuencia una persona estaría expuesta al riesgo, qué tan fácil es evitar el riesgo (depende de la velocidad, etc.) y qué es la gravedad del resultado (corte, amputación, muerte, etc.).

Gran parte del análisis tiene que ver con la protección de los riesgos. Si coloca una jaula grande alrededor de su máquina y la atornilla, entonces su máquina se considera segura si los componentes de la máquina no pueden romper la protección. Si necesita una herramienta para ingresar, se considera una tarea de mantenimiento, y se supone que las personas de mantenimiento deben estar capacitadas sobre cómo trabajar de manera segura en una máquina. Sin embargo, en realidad, la mayoría de las máquinas necesitan una interacción regular con los operadores, por lo que tenemos que colocar puertas de acceso en la protección, o cortinas de luz, etc. Es necesario controlar esas puertas y cortinas de luz y la potencia a los peligros a los que el operador se expone. tiene que ser apagado de una manera "de control confiable".

Según ese análisis, los riesgos se clasifican en varias categorías. Una escala de clasificación común es la Categoría 1 a la Categoría 4 (basada en la norma EN 954-1). De acuerdo con esas categorías, usted está legalmente obligado a proporcionar un cierto nivel de protección y seguridad de la máquina.

La categoría 4, por ejemplo, requiere que:

Una sola falla en cada una de estas partes no causa la pérdida de la función de seguridad.

La falla única se detecta con o antes de la próxima solicitud a la función de seguridad, o si esto no es posible, una acumulación de fallas puede no causar la pérdida de la función de seguridad.

Esto puede ser difícil de lograr en la práctica, pero se simplifica por la disponibilidad de componentes estándar que están certificados para la Categoría 4. Por ejemplo, un componente común en estos sistemas es un relé de seguridad. Estos son más que solo relés mecánicos:

• Están diseñados para monitorear canales de entrada redundantes duales, por lo que si tiene un sensor que detecta una condición de falla (como una puerta de protección abierta), generalmente tiene dos contactos con circuitos redundantes. El relé monitorea ambos canales y, si alguno de los dos se abre, desconecta la energía de sus actuadores, pero si ambos no se desconectan al mismo tiempo, entra en una condición de falla y la máquina no puede reiniciarse hasta que se repare. .
• El relé también usa pulsos eléctricos en esas líneas y usa esas señales para monitorear cables cruzados o en cortocircuito, por lo que puede detectar una falla en el cableado.
• En el lado de la salida, utiliza un conjunto de circuitos duales para accionar las bobinas de salida, por lo que si uno falla en la condición de "encendido", el otro debería evitar que la salida se energice. Además, estos son monitoreados y si se detecta una falla, impide la operación. Las bobinas en sí son relés guiados de doble fuerza, lo que significa relés físicos redundantes en la salida, además de garantizar que los contactos de cada relé estén físicamente unidos para que un contacto de, por ejemplo, 4, no pueda bloquearse por sí mismo. Estos también son monitoreados.
• También incluye una entrada para monitorear un contacto auxiliar normalmente cerrado de la carga que está controlando. Si apaga la salida, tiene que ver el contacto normalmente cerrado, lo que significa que valida que apagó el contactor del motor, o lo que fuera, antes de que se le permita volver a funcionar.

Como puede ver, estos son dispositivos complicados. Los costos típicos están en el rango de $ 200 a $ 600 por cada relé de seguridad. Obviamente hay software en estos dispositivos. Para obtener la certificación de su relé de seguridad, generalmente debe seguir un diseño como este:

• Dos procesadores redundantes, generalmente de diferentes proveedores, basados ​​en diferentes diseños.
• El código que se ejecuta en cada procesador debe ser desarrollado por dos equipos que trabajen en condiciones aisladas. Esto evita que un solo error de software sea un solo punto de falla.
• La salida de ambos procesadores tiene que estar de acuerdo o de lo contrario las fallas del relé de seguridad.

Una vez que diseñe su sistema de seguridad para su máquina, utilizando componentes con clasificación de seguridad, debe hacer que un ingeniero profesional revise y selle el diseño. Entonces construyes la máquina. Entonces el P.Eng. revisará la construcción de la máquina asegurándose de que se construyó según el diseño. Lo documentarán y realizarán algunas pruebas para asegurarse de que funciona como se esperaba. Esto se denomina revisión previa al inicio (PSR) y no se realiza en todas las jurisdicciones. Después de que pasa el PSR, se le permite tener un operador que ejecute la máquina.

En los últimos años ha habido algunas revoluciones en los sistemas de seguridad. Durante un tiempo, nadie confió en la transmisión de datos de seguridad a través de una red, por lo que lo que normalmente se llama "sistemas de E / S distribuidas" como DeviceNET y EtherCAT no se permitieron en la parte de seguridad del sistema. Sin embargo, los protocolos recientes ahora permiten que los dispositivos de seguridad se ejecuten en estas redes industriales. Los protocolos hacen uso de mensajes con marca de tiempo y procesamiento dual redundante en ambos extremos de la conexión.

Los relés de seguridad siguen el camino del ave dodo, reemplazados por PLC de seguridad más complicados, que son como una forma de construir la lógica de seguridad en un lenguaje de diagrama de bloques de funciones. Una vez más, estos PLC de seguridad utilizan todo redundante. Cuando se aprueba el programa, antes de que la máquina se ponga en servicio, el P.Eng. sellará el programa y el programa / PLC se bloqueará con una contraseña. También toma un hash del programa y ese hash se registra en la documentación (eso es lo que el P.Eng. Realmente está estampando).

Ahora, una vez que haya diseñado su sistema de seguridad, la lógica que escriba para controlar la máquina en sí misma puede ser muy cómoda. Los programadores con frecuencia hacen que las máquinas choquen causando miles de dólares en daños, pero al menos nadie resultará herido.

Hay un movimiento serio hacia la verificación formal en lugar de pruebas funcionales aleatorias.

Las agencias gubernamentales como la NASA y algunas organizaciones de defensa están gastando cada vez más en estas tecnologías.

Todavía son un PITA para el programador promedio, pero a menudo son más efectivos para probar sistemas críticos.

También hay una tendencia a probar más técnicas de la academia, para cosas como validar código multiproceso.

Depende de lo que sea el software. Por ejemplo, en los planos generalmente hay un procesamiento dual redundante para sistemas críticos; en el caso extremo, pueden usarse 2 diseños de hardware diferentes y dos piezas de s / w desarrolladas independientemente, una para ejecutar en cada una. Ambos calculan y verifican entre sí. Esto no es infalible y es extremadamente costoso.

Cuando se trata de cosas como las pruebas de los sistemas de la aeronave, hay una serie de pruebas realizadas: las pruebas de los sistemas relacionados con el vuelo toman meses, y si realiza algún cambio, se requiere una serie completa de reevaluaciones. Esto generalmente se hace en un simulador, que en realidad podría estar lleno de piezas reales de la aeronave (por ejemplo, cabina) con un motor simulado o similar. Como puede imaginar, esto también es horriblemente costoso de construir. Los cambios se evalúan contra un programa de prueba formal y luego se ejecutan en un avión real en vuelos de prueba. En el camino se ejecutan pruebas como "funcional alterado", aquí es donde se permite que el elemento modificado haga su trabajo normal y todo se verifica / prueba para ver que no haya ningún efecto perjudicial. Esto también cuesta mucho dinero y puede llevar semanas.

Sé de un ejemplo en el que se requería un cambio muy simple a un sistema de vuelo, tan simple que te sorprendería lo insignificante que es. Sin embargo, la nueva prueba de esto habría llevado más de 3 meses y costaría algo así como $ 1M.

Cuando ingresa a la medicina, hay toda una serie de obstáculos regulatorios para saltar relacionados no solo con las pruebas sino también con los procesos y la documentación del desarrollo.

Todos estos campos son un gran paso adelante desde lugares que eliminan un poco de código PHP para un sitio web. Es lento, laborioso, difícil, aburrido, tedioso, meticuloso y muy costoso. Tome sus costos normales de desarrollo / prueba y multiplíquelo por aproximadamente 100 y se está acercando a la marca.

Para el software del transbordador espacial de la NASA, lea They Write the Right Stuff . Para la FDA (Administración de Alimentos y Medicamentos de los EE. UU.) Lea, lea esto

Como ya tienes suficientes respuestas geniales e informativas, aquí está mi opinión.

Es simple: la primera prueba siempre se realiza en los propios programadores. Tiende a mantener bajo el recuento de errores y garantiza que solo los programadores de calidad se mantengan en la nómina.

El software vital no se prueba con ningún estándar que no sea el "parece funcionar" , ya que se hace por todas partes.

Toda la inversión se destina a lo que parecía funcionar antes o para proyectos que permitan a los no programadores producir un mejor software.

ps No hay comentarios sobre el primero -1, pero me encantaría tomar -1para cada referencia que contrarresta mi declaración.

¿Puedo tomar un +1 por cada referencia que encuentre que el software crítico no está bien diseñado o probado? Simson Garfinkel documenta diez casos en un artículo sobre WIRED.

No hay una respuesta para todos los casos. Depende del fabricante individual decidir cómo diseñar y probar su software. Pero todo el proceso de desarrollo de software debe cumplir con las especificaciones formales.

Por ejemplo, cuando la creación de software para dispositivos médicos debe seguir la norma IEC 62304 estándar para el software para dispositivos médicos. (Lamentablemente, solo puedo vincular a Wikipedia, ya que no es gratis). Casi todos los países del mundo requieren que se siga este estándar.

Cuán estrictos son estos requisitos depende del riesgo de daño. Por ejemplo, un dispositivo de soporte vital tendría el mayor riesgo de daño (muerte segura si el sistema falla), mientras que un sistema que funciona con diagnósticos de enfermedades tiene un riesgo menor (posible muerte si una enfermedad terminal no se diagnostica correctamente si el sistema falla).

Pero lo que esto dice básicamente es que debe haber una trazabilidad desde los requisitos hasta el software. Debe realizar verificaciones de la unidad de software. Eso no especifica cuál es la verificación. Pueden ser pruebas unitarias, puede ser una revisión de código. Para los dispositivos de mayor riesgo, debe revisar manualmente las interfaces entre las unidades de software (por lo que yo entiendo y recuerdo). Y, por supuesto, muchas otras reglas. Ah, y debes escribir mucha documentación para documentar tu trabajo.

El estándar no prohíbe el desarrollo ágil, aunque al leerlo parece que fue escrito con el desarrollo en cascada en mente.

No conozco otras áreas de desarrollo de software, como aviación, trenes, automóviles, etc. Pero supongo que existen otras pautas formales similares.

Se utilizan muchas técnicas, incluidas, entre otras, las siguientes:

• diseño formal y / o validación
• estrictos estándares de codificación que evitan la programación sofisticada, como la asignación dinámica de memoria
• ingenieros de calidad muy exigentes
• Muchas técnicas de análisis estático como revisión de código, árboles de fallas, FMECA, ...

Pero la técnica número uno es:

• PRUEBAS

El software de una nave espacial necesita más esfuerzo para probar que para diseñar y codificar en primer lugar.

Las aeronaves se someten a varios años de pruebas de vuelo donde el avión se encuentra en situaciones extremas. Esto prueba no solo la estructura física sino también el software.

Hay un artículo "Software perfecto" de Jack Ganssle en EETimes con fecha 3/1/2009 12:00 AM EST. Algunos puntos a partir de ahí:

• "Teóricamente, el software es el único componente que puede ser perfecto, y este siempre debe ser nuestro punto de partida". - Eso lo dice Jesse Poore. Siguiendo su página web descubrirá cómo se puede hacer un software perfecto sin mucho más costo que el software normal.
• Hay proveedores industriales de sistemas operativos altamente confiables. El artículo menciona Mircrium y Green Hills. Después de la página web de Micrium, hay una lista de estándares para certificaciones. Esos deben ser los procesos y las reglas que sigue la industria. Eso se basa en la validación formal, pero se desvió mucho de la teoría.

Curiosamente, con respecto al software comercial, los datos recopilados por Capers Jones sugieren que "el software en general tiene una eficiencia de eliminación de defectos (el porcentaje de errores eliminados antes del envío) del 87%. El firmware obtiene un 94% mucho mejor". Para mí, ninguno de estos es casi perfecto. El artículo que un respondedor anterior mencionó indica que el equipo del transbordador espacial de la NASA logró una tasa de eliminación de errores del 99%, pero el costo es de 35 millones por año para aproximadamente 400k líneas de código.

Un artículo más interesante "Software para sistemas confiables" del mismo autor el 11/1/2009, parece ser más relevante. Se puede resumir así:

• En cuanto al proceso de desarrollo, la industria ha seguido DO-178B o IEC61508. Destaca las pruebas con la mayor cobertura. Pero se puede encontrar poca evidencia sobre la efectividad de esto.
• Una autoridad de certificación, el Comité de sistemas de software confiablemente certificables, ha publicado un libro titulado "Software para sistemas confiables: evidencia suficiente". Es una buena referencia.
• El libro, básicamente, pide tres cosas: [1] Haga reglas explícitas para las pruebas de confiabilidad. [2] Realiza pruebas en contra de las reglas, pero también asegúrate de que las pruebas sean entendibles para los clientes normales o reguladores con una cantidad de tiempo menor que la de los desarrolladores. [3] Asegúrese de que los expertos en ingeniería de software y dominio de problemas estén haciendo el desarrollo y la prueba.
• El proveedor de software debe comprometerse con una garantía u otros remedios por cualquier falla de software.
• Utilice un lenguaje seguro, específicamente no C. Se sugiere SPARK.
• El diseño para el enfoque contractual es uno de los puntos fuertes de SPARK. El diseño por contrato es una tecnología importante para integrar pruebas en cada llamada a función / método, y siempre ejecutarlo en tiempo de ejecución. Más que una simple afirmación () en los viejos tiempos, el contrato también puede incluir pruebas en contra de la intención estructural y asegurarse de que no se pueda pasar ninguna violación más adelante en el ciclo de mantenimiento, cuando los desarrolladores originales se han trasladado a otros proyectos. Hay evidencias de que el diseño por contrato ha producido productos de software muy confiables. SPARK y sus herramientas se pueden utilizar para ayudar a generar casos de prueba de certificación para simplificar el proceso de certificación.

Según mi memoria, HP practicó el diseño por contrato hace casi una década. Con un equipo pequeño, 500 mil líneas de código, solo se informaron 2 errores después de la entrega. Muy impresionante.

En mi opinión, solo se puede lograr un software confiable o perfecto si el costo no es prohibitivamente alto. Los marcos o las automatizaciones son imprescindibles.

Por lo general, tienen un enclavamiento de hardware que se usa como a prueba de fallas.

Por ejemplo, los diseños estándar de cuadros de texto malvados para robots asesinos siempre vienen con un interruptor de apagado: P

Cada industria tiene su propio conjunto de agencias reguladoras que tienen requisitos de pruebas y documentación para hardware y software relacionados con la seguridad. Considere este PDF de Underwriters Laboratory (UL) que presenta el estándar UL 1998: http://www.ul.com/global/documents/offerings/industries/hightech/software/UL_softwareconformityassessment.pdf

Hay referencias en ese documento a muchos otros relacionados de UL, CSA e IEC.

Típicamente, el software relacionado con la seguridad tendrá circuitos de hardware redundantes o se requerirá que tenga otras características de control redundantes para garantizar un funcionamiento seguro y modos de falla seguros.