c++ - for - ¿Se ha usado Boost en un proyecto regulado(FDA, FAA)?

descargar boost

Question

Al publicar un comentario recientemente, me encontré comentando que, según mi experiencia, Boost no se usa mucho en las industrias reguladas (FDA, FAA). De hecho, no conozco ningún proyecto que lo use o lo haya usado. Sin embargo, me doy cuenta de que puede faltar mi experiencia aquí, así que quería saber si alguien tenía conocimiento de un proyecto que utiliza boost en un dispositivo médico o en un sistema de vuelo de aviación (iluminación, controles de cabina, equipo de cabina, etc.).

No estoy seguro de que este sea el lugar correcto para preguntarlo (quizás algún otro sitio SO), pero pensé que sería un buen lugar para comenzar.

Esta no es una pregunta acerca de si se debe usar o no el refuerzo en estas áreas, es una pregunta sobre si alguien sabe si se ha utilizado.

EDITE Algunos ejemplos de proyectos que podrían ayudar a aclarar esto: sistemas de iluminación de cabina de avión, sistemas de gestión de cabina, instrumentación de cabina, bombas de infusión / alimentos / insulina, máquinas de diálisis, dispositivos de diagnóstico de laboratorio, sistemas de recopilación de datos de centros de sangre, etc. Algunos son de soporte vital o potencialmente crítico para el vuelo, algunos recopilan datos, otros recopilan datos utilizados para tomar decisiones médicas, etc., pero creo que todos están cubiertos como dispositivos regulados por la FAA / FDA.

EDITAR Las bibliotecas externas (no vienen con la cadena de desarrollo) a menudo se incorporan a este tipo de proyectos para otros fines (bibliotecas de gráficos, controladores, pilas USB, etc.) Se tratan como SOUP . El uso de impulso caería bajo este enfoque. ¿Alguien sabe de un proyecto donde se usó boost de esta manera?

EDIT Boost es un marco muy grande, con múltiples componentes. Estoy buscando cualquier parte que haya sido utilizada en un proyecto. Por ejemplo, "Boost smart pointers" o "Boost Enable" o "Boost Array" o "Boost Optional", etc. Pero se utilizan en "todo", no en parte. No se usa mirando el código Boost y reutilizando la idea; utilizado como un componente completo del sistema (es decir, el sentido legal).

Esto es fundamental para la pregunta, ya que usarlo de esta manera significa que se deben tratar las compensaciones del manejo de la SOUP. Esto puede colocar esta pregunta fuera del alcance de este sitio SO ... no estoy seguro.

Answer 1

Creo que la mejor respuesta que podemos tener aquí es "sí y no". Intentaré explicar por qué.

Boost es un gran paraguas para muchas bibliotecas constituyentes. Algunos de ellos dependen unos de otros de varias maneras (por ejemplo, cuando una biblioteca de nivel superior necesita características proporcionadas por una parte de nivel inferior de Boost como los rasgos de tipo). Esto plantea preguntas sobre la utilidad de una respuesta simple a la pregunta, porque si se han usado tres partes de Boost en un proyecto regulado, pero son partes diferentes de las que quiere usar, no tiene mucho valor saber esto. Y nunca sabremos la respuesta completa con respecto a todas las partes, porque usted no puede demostrar ser negativo (y hay demasiadas partes para esperar una respuesta "100% sí").

Boost está (y siempre ha estado) evolucionando rápidamente. Se agregan bibliotecas totalmente nuevas todo el tiempo. ASIO es uno grande que no existía hasta hace poco. Esto hace que sea aún más difícil responder a la pregunta, porque con el tiempo hay partes de Boost que son jóvenes y no están tan bien probadas como otras. Además, las bibliotecas existentes a veces pasan por revisiones incompatibles con versiones anteriores (por ejemplo, "Boost Filesystem 3" no hace mucho tiempo).

Muchas partes de Boost terminan en proyectos, no por una dependencia tradicional sino más bien por copiar y pegar el código de Boost, y quizás modificarlo a gusto (por ejemplo, agregar o eliminar soporte para compiladores específicos). Del mismo modo, muchas partes de Boost terminan en proyectos por el hecho de que Boost es una especie de campo de prueba para muchas de las nuevas características de la biblioteca estándar de C ++, como shared_ptr (C ++ 11) y unordered_map (TR1). Algunas de las características que forman parte del lenguaje de hoy fueron originalmente parte de Boost, por lo que muchas personas han usado el "Código Boost" sin siquiera saberlo.

Tenga en cuenta que el código no se vuelve más seguro cuando pasa al estado oficial dentro del idioma: GCC ha tenido errores que no existían en las implementaciones equivalentes de Boost de los mismos conceptos. Esto es importante cuando se consideran preguntas prácticas como "¿Deberíamos permitir el uso de Boost en nuestro proyecto o deberíamos limitarnos a lo que nos ofrece el proveedor del compilador?" Si está pensando en usar una característica que ha sido implementada muy recientemente por su proveedor del compilador (por ejemplo, en el último año), es posible que esté mejor utilizando una implementación de terceros (por ejemplo, Boost) que sea más madura.

Finalmente, ya que parece que el ímpetu para esta pregunta es obtener cierta seguridad de que usar Boost no es una mala idea para un proyecto de producción: ciertamente diría que usar Boost en general es bueno y está bien, con la gran advertencia que necesita. un experto local en Boost que sabe qué partes de Boost no deben utilizarse en su dominio. Por ejemplo, Boost Spirit, Phoenix y Wave son ejemplos de bibliotecas que han estado en Boost por un tiempo, pero que muy pocas personas entienden profundamente. Una cosa es usar el código de la biblioteca que no entiendes completamente (todos lo hacemos), y otra muy distinta es usar un código que casi ninguna persona en el mundo entiende.

En resumen, no creo que nadie pueda darte la seguridad de que buscas que Boost esté bien para los sistemas críticos para la seguridad. Debe evaluarlo por su cuenta, de la misma manera que necesita evaluar el software de su propio proveedor del compilador, sus dependencias de terceros y el código que usted mismo escribe. He usado las cuatro categorías de software bastante, y en mi experiencia, Boost tenía menos errores críticos que cualquiera de los otros, y menos regresiones que GCC o mi propio código.

Answer 2

Lo diría mucho si se trata de cómo los diseñadores de sistemas manejan la seguridad del sistema a nivel arquitectónico.

Triplicación

Por ejemplo, si el enfoque adoptado es una redundancia triplicada con un votante de confianza, las pruebas / ensayos del sistema serán el paso más importante para aprobar la implementación. Supongamos que uno de los equipos de desarrollo de los triplicados eligió usar Boost. Si el sistema en su totalidad pasara todos sus vectores de prueba, entonces se podría argumentar que no era necesario rastrear a través de Boost en busca de errores de implementación. Obviamente, si los tres triplicados hubieran optado por usar Boost, entonces eso sería motivo de preocupación, porque entonces el alcance de los vectores de prueba se vuelve incontrolable.

La triplicación es un enfoque estándar para manejar el problema del uso de recursos de software como compiladores, bibliotecas y programadores, todos los cuales están en riesgo de error. Boost es solo otro de estos. Se podría argumentar que los punteros compartidos de Boost son claramente una forma de reducir el riesgo de error del programador. Que en la ronda es más probable que sea beneficioso para el sistema en su conjunto.

Importante, pero no crítico para la seguridad

Donde se pone interesante es cuando no se está utilizando la triplicación, y uno está ahora en el reino de tener que confiar realmente en las cosas. Es interesante que la forma en que muchos sistemas parecen sortear el problema es decir que, en última instancia, hay un humano en control que supervisa y puede intervenir en caso de error del sistema.

Por ejemplo, la industria del automóvil tiene un conjunto de reglas de programación llamadas MISRA. El software para un sistema ABS se debe escribir en este conjunto de reglas, y las herramientas de desarrollo deben configurarse para hacer cumplir esas reglas en el código fuente. La idea es que esto reducirá el riesgo de errores no detectados a un nivel aceptable. Y como en última instancia hay un conductor que conduce el automóvil, siempre puede frenar su propia cadencia. Y así, la industria automovilística ha evitado tener que tener una implementación triplicada de ABS.

Están extendiendo la misma filosofía a los sistemas de automóviles más complejos, como el control de crucero adaptativo y los autos de auto conducción. Personalmente creo que tal extensión no es razonable para los autos que conducen. La legislación pertinente deja claro que es culpa de los "conductores" si un vehículo de este tipo tiene un accidente (es decir, todavía lo está "conduciendo"), pero la publicidad brillante no se detendrá en ese aspecto importante.

Es lo mismo en el mundo de los dispositivos médicos; se supone que debe haber una enfermera o alguien que esté monitoreando al paciente de todos modos, por lo que el problema ocasional está cubierto por esa supervisión. Todo es muy pobre de todos modos; Si bien el software para un dispositivo médico puede haber sido probado y aprobado por escrito, con bastante frecuencia estas cosas se ejecutan en Windows XP integrado. Todos se conectan en red y terminan siendo infestados con virus informáticos, etc. La FDA no le permitirá tener un sistema de actualización automática en el lugar, solo el proveedor del dispositivo puede actualizarlo y, por supuesto, no pueden esperar mantenerse al día. . Así que terminas con un software médico bien probado y bien probado que se ejecuta en la parte superior de una instalación de sistema operativo que ha tenido a todos los piratas informáticos del mundo haciendo que Dios sabe qué. Creo que el uso de Boost en estas circunstancias no aumentará mucho el riesgo general del sistema.

Entonces, si una cadena de herramientas compatible con MISRA ofreciera Boost como parte de esa cadena de herramientas, entonces no veo por qué sería diferente a una cadena de herramientas que ofrece una biblioteca C estándar. Si el proveedor de la cadena de herramientas lo está certificando, entonces no es diferente a la situación con cualquier otra cosa.

Hay debilidades con ese enfoque. En mi experiencia, me he encontrado con una cadena de herramientas compatible con MISRA de uso generalizado cuyo compilador generó un código de objeto no deseado cuando se activaron todas las optimizaciones. De hecho, pude verificar esto en el desmontaje. Luego eché un vistazo al código fuente de la biblioteca C estándar de toolchains, y claramente no estaba escrito en el conjunto de reglas MISRA, y además contenía errores deslumbrantes y horribles.

Y, sin embargo, no existe un bloqueo reglamentario para construir, probar y vender un sistema ABS para automóvil utilizando esta cadena de herramientas, siempre que marque la casilla de verificación MISRA en la configuración del proyecto. Agregar Boost a esa cadena de herramientas difícilmente empeoraría las cosas.

Seguridad crítica sin triplicación

El enfoque final es la no triplicación y no la supervisión humana. Esto es realmente difícil porque entonces necesita una prueba formal de la corrección de cada componente de la cadena de herramientas, el sistema operativo, los controladores, los chips, etc. AFAIK nunca se ha hecho para un sistema verdaderamente crítico como los reactores nucleares, la aviónica de control de vuelo u otros Sistemas que realmente matarán a la gente si salen mal.

Lo único que se me acerca por lo que puedo decir es el conjunto de compiladores de Greenhill y su sistema operativo INTEGRITY. Pueden proporcionarle pruebas de verificación y pruebas formales (por una gran tarifa) para cada línea del sistema operativo, todas sus bibliotecas y su compilador, todo. Si alguna vez se intentara un sistema verdaderamente crítico para la seguridad sin triplicación, sería un punto de partida.

No creo que hayan hecho un C ++ 11 todavía, aunque he agregado Boost a su cadena de herramientas y funcionó bien (no estaba en un sistema crítico de seguridad que me apresuro a agregar).

Conclusión

Ciertamente, si equipos como Greenhills con una merecida y buena reputación de herramientas confiables y bien probadas ofrecen Boost, creo que uno estaría en una buena posición para usarlo en un sistema regulado. Sin embargo, dudo que la totalidad de Boost se ofrezca de esa manera; es más probable que sigan los estándares del compilador.

También sé que en el pasado, GCC se sometió a pruebas formales de validación del compilador para que pueda usarse en Stuff That Matters. Espero que eso se repita más pronto o más tarde para las encarnaciones más recientes que han tomado aspectos de Boost.