X
BLOG

5 consejos para el análisis estático y dinámico en software de dispositivos médicos

5 consejos para el análisis estático y dinámico en software de dispositivos médicos Tiempo de leer: 6 minutos
A medida que la ciberseguridad se está convirtiendo en un fuerte enfoque de la FDA con requisitos específicos en torno al análisis de código estático y dinámico, los ingenieros deben automatizar esas prácticas e integrarlas en los flujos de trabajo de desarrollo existentes. En este blog invitado, Andrey Shastin de Auriga comparte algunos trucos del oficio.

En Auriga, hemos estado entregando muchos proyectos de desarrollo de software para dispositivos médicos durante casi 2 décadas, desde medidores de glucosa en sangre relativamente simples hasta sistemas más complejos como bombas de infusión, monitores de pacientes y unidades de ventilación pulmonar. La implementación de prácticas de análisis de código estático y dinámico y su implementación en estos proyectos es una parte integral de nuestro proceso, y aquí compartiré algunos consejos de nuestra experiencia práctica y desafíos.

Análisis de código estático

El análisis estático es una práctica para verificar automáticamente el cumplimiento de pautas de codificación conocidas (es decir, MISRA, CERT, AUTOSAR, JSF) y detectar errores potenciales como desreferenciación de puntero nulo, división por cero y desbordamientos de búfer. Las herramientas modernas de análisis estático también complementan la práctica tradicional de revisión de código al reducir el esfuerzo manual en al menos un 30%.

En la mayoría de los casos, la primera ejecución de una herramienta de análisis estático contra su código actual mostrará miles de errores (hemos encontrado incluso más de 20,000 en la primera ejecución), lo que, por supuesto, puede ser increíblemente abrumador, ya que parece que sería necesario años para arreglarlos todos. Así que aquí hay algunos consejos de nuestros expertos para hacer frente al problema.

Consejo n. ° 1: el compilador es tu amigo

Los equipos de desarrollo disciplinados generalmente compilan con –Wall y –Werror (en GCC), o / Wall / WX (en Visual Studio), o usando opciones similares en otros compiladores. Corregir las advertencias del compilador es una forma fácil y económica de prepararse para la ejecución del análisis estático. Hemos visto que revisar la salida de su compilador en un modo "paranoico" puede reducir el volumen general de violaciones del análisis estático.

Si bien haber arreglado todas las advertencias del compilador es algo bueno, hay muchos proyectos en los que usar solo un compilador no será suficiente e incluso una opción aceptable por razones de cumplimiento.

Después de agotar su compilador, use herramientas de análisis estático que están destinadas a profundizar mucho más en el código y brindarle muchas más sugerencias.

Consejo n. ° 2: adopte el análisis estático al principio del proceso

Si actualmente está desarrollando software para dispositivos médicos, debe estar preparado para abordar la cuestión de una práctica de análisis de código estático automatizado. Es casi seguro que el análisis estático será un tema de discusión durante una auditoría interna / externa o incluso una presentación previa a la comercialización.

La clave es implementar la herramienta de tal manera que el desarrollo no pierda velocidad mientras se enfoca en mejorar la calidad y no se ocupa de la idiosincrasia y el ruido de la herramienta. Este es un acto de equilibrio, que requiere práctica y experiencia que los ingenieros de Auriga han adquirido a lo largo de los años, pero lo que hemos descubierto es que, al descubrir la causa raíz de los errores informados, es probable que descubra que muchos de ellos son fáciles de solucionar. .

Aquí hay solo algunos ejemplos del informe de análisis estático que se pueden solucionar fácilmente con un simple guión o con pasantes bien capacitados:

1) Llamada de funciones claras en destructores:

una. El destructor '~ CTitle' no debe llamar a la función 'clear_' que no está en el contexto de prueba

B. El destructor '~ THelper' no debe llamar a la función 'removeModule' que no está en el contexto de prueba

2) Verificar NULL:

una. "PMP" posiblemente sea nulo

B. "((NPage *) this) -> pSysCfg_" posiblemente sea nulo

3) Posiblemente declaración en sección incorrecta:

una. Los miembros de datos 'D_FILE_1' se declaran como 'públicos'

4) Argumentos no constantes:

una. El literal de cadena "MCollection" se pasa a la función "FixedBlockHeap" como puntero a un objeto no constante

Puede dejar de lado muchas infracciones en el código existente y tratarlas cuando tenga un tiempo de inactividad. Sin embargo, es importante NO introducir nuevas infracciones (departamento técnico) a medida que desarrolla el código. Por ejemplo, Parasoft C / C ++test tiene características que permiten a los ingenieros filtrar el ruido y concentrarse en corregir las violaciones recientes más críticas del análisis estático.

Análisis dinámico

Mientras que el análisis estático interpreta el código fuente como texto y saca todas las conclusiones basándose en la salida del analizador sin ejecutar una sola instrucción, pruebas de seguridad de aplicaciones dinámicas o DAST proporciona una perspectiva diferente sobre el código. Examina el correr código, que muestra la cobertura, la suficiencia y la calidad del código de las pruebas unitarias, pérdidas de memoria y otros problemas potenciales de debilidades.

Consejo n. ° 3: sea flexible con su entorno de ejecución

El término "integrado" cubre una gran cantidad de dispositivos: desde MCU de 8 bits con kilobytes de RAM y flash hasta CPU multinúcleo de 64 bits con gigabytes de RAM y SSD de alta velocidad. En caso de que el funcionamiento diario del dispositivo requiera un mínimo de memoria y potencia de procesamiento, es probable que los fabricantes opten por un hardware orientado únicamente a sus necesidades que abordan las limitaciones de tamaño, peso o costo. Aunque generalmente dejan cierta capacidad para actualizaciones y mantenimiento de software, aún puede ser insuficiente cuando se trata de la herramienta de análisis dinámico que instrumenta el software, ya que el proceso requerirá una gran cantidad de RAM (en comparación con el modo de operación normal) y espacio de almacenamiento para recopilar resultados de cobertura de prueba y código.

Por lo tanto, cuando la cantidad de memoria en el dispositivo es demasiado baja para ejecutar pruebas y recopilar cobertura de código, es posible que la plataforma de destino no sea adecuada para recopilar cobertura de código para pruebas de integración y unidad.

Si su plataforma de destino principal no es compatible desde el primer momento, busque alternativas válidas. Podría haber una plataforma hermana con más interfaces y memoria respaldada por una herramienta de análisis dinámico para que pueda usarla para pruebas unitarias y algunas de integración. Otra alternativa es utilizar simuladores de hardware que ejecuten ARM Fast Models y QEMU.

Si bien ejecutar pruebas en la plataforma de destino es lo más deseable, muchas veces los equipos optan por no realizar pruebas de integración de la unidad y algunas aplicaciones en la estación de trabajo del desarrollador (como Linux, Mac, Windows) para beneficiarse de un ciclo de desarrollo más rápido y una mayor cantidad de herramientas disponibles. para plataformas de desarrollo general. En ese caso, necesitará portar su código incrustado para compilar con un compilador de host, lo que podría presentar algunos desafíos.

Hay muchos compiladores, herramientas de compilación, marcos y métodos para ejecutarlos. Las herramientas de análisis dinámico admiten algunas técnicas de compilación comunes con presunciones internas sobre cómo los desarrolladores podrían aplicarlas. Por lo tanto, incluso si el código es portátil, lo más probable es que el equipo del proyecto necesite tiempo adicional para alinear la configuración de una herramienta de análisis dinámico según cómo funcione el sistema de compilación del proyecto.

Se recomienda encarecidamente que todos los esfuerzos se estimen con anticipación para elegir el mejor enfoque para el desarrollo futuro y el apoyo en una perspectiva a largo plazo.

Consejo n. ° 4: no confíe demasiado en los casos de prueba generados automáticamente

Las modernas herramientas de análisis dinámico generan automáticamente conjuntos de pruebas unitarias para aumentar la cobertura del código. Pero las herramientas son solo herramientas: son independientes de varios escenarios de cómo se pretende usar el código de producción, especialmente cuando se intenta aumentar la cobertura del código y cruzar la frontera entre las pruebas unitarias puras y las pruebas de integración. Aún tendrá que actualizar manualmente las pruebas unitarias generadas, e incluso escribir nuevas, porque solo usted sabe lo que se pretende que haga el código cuando se trata de resultados positivos y negativos de las pruebas.

En nuestra experiencia, un conjunto de archivos seleccionados en un área crítica puede tener pruebas unitarias generadas automáticamente cubiertas en un rango desde el 40% hasta el 100% para cada archivo. Pero en promedio, para todo el proyecto, las cifras pueden variar del 25% al ​​60%.

Además, las pruebas unitarias autogeneradas que utilizan solo el código fuente como entrada a menudo pueden ejecutarse perfectamente en un código con errores. La generación automática debe utilizarse como una buena forma de iniciar el proceso de prueba unitaria. El proceso de crear casos de prueba manualmente mejora la calidad del código porque obliga a una revisión adicional del código y proporciona un punto de vista diferente en el diseño.

Consejo n. ° 5: No subestime el esfuerzo de calificación / validación de herramientas

La FDA exige que cualquier herramienta que se utilice durante el desarrollo formal sea válida para el uso previsto para garantizar que realiza las acciones esperadas y produce los resultados correctos. Por lo general, este es un protocolo de prueba especial llamado IUV (Validación de uso previsto).

Los proveedores líderes en la industria de herramientas de análisis estáticas y dinámicas ayudan a producir los procedimientos y la documentación necesarios, y esto es extremadamente útil para minimizar sus esfuerzos. Parasoft's es especialmente valioso porque automatiza gran parte del proceso. Al igual que con cualquier otro paquete genérico, es posible que desee reservar algunos de sus esfuerzos para revisar y ajustar los documentos a fin de sincronizarlos con sus propios procedimientos de SGC. Por ejemplo, el software Tool Qualification de Parasoft proporciona un conjunto de casos de prueba que se ejecutarán en su entorno para validar las capacidades de análisis estático y dinámico.

En resumen

  1. Trate las advertencias del compilador como errores. Las advertencias pueden convertirse en errores más adelante para la versión más reciente del mismo compilador. Las advertencias a menudo significan que el compilador hace algo implícitamente.
  2. Ejecute herramientas de análisis estático al principio del proyecto y solucione los problemas a medida que aparezcan.
  3. Mantenga el código portátil. Incluso si no planea portar su producto a otra plataforma, esta podría ser una opción en el futuro. Por otro lado, esto también ayudará a mantener su código limpio, fácil de mantener y legible, lo que siempre es bueno para su revisión y soporte adicional.
  4. No confíe demasiado en los casos de prueba generados automáticamente para mejorar la calidad del código.
  5. No subestime la necesidad y el esfuerzo de validar la herramienta para el uso previsto.

Si desea ayuda con la adopción de análisis estáticos y dinámicos, contáctenos en Auriga.

Pruebas de desarrollo unificadas para aplicaciones C y C ++

Escrito por

Andrey Shastin

Como ejecutivo de tecnología y asociaciones comerciales en Auriga, Andrey elabora estrategias para su oferta de I + D de software para resolver los desafíos SDLC integrados de los fabricantes de dispositivos electrónicos, incluida la garantía de calidad y ciberseguridad.

Reciba las últimas noticias y recursos sobre pruebas de software en su bandeja de entrada.

Prueba Parasoft