Tecnología de PCB - Cómo encontrar defectos de software en el proceso de diseño de PCB

Cómo evitar los defectos de software ocultos pero comunes en el proceso de diseño de pcb, e introducir varias tecnologías para ayudar a los ingenieros a encontrar errores ocultos en el software de la placa de copia de PCB (www.pcbwork.net). La mayoría de los proyectos de desarrollo de software dependen de una combinación de inspección de código, pruebas estructurales y pruebas funcionales para identificar defectos de software. Aunque estas tecnologías tradicionales son muy importantes y permiten detectar la mayoría de los problemas de software, no pueden detectar muchos errores comunes en sistemas complejos hoy en día.

Las pruebas estructurales o las pruebas de caja blanca pueden detectar eficazmente errores de lógica, flujo de control, cálculo y datos en el Código. La prueba requiere una visión general del trabajo interno del software (de ahí el nombre de "caja blanca" o "caja de vidrio") para conocer los detalles de la estructura del software. Revisa cada expresión condicional, operación matemática, entrada y salida. Debido a la necesidad de probar muchos detalles, las pruebas estructurales revisan una unidad de software a la vez, generalmente una función o clase.

La revisión del Código también utiliza las mismas técnicas complejas que la detección de defectos de implementación y problemas potenciales. Al igual que las pruebas de caja blanca, generalmente se revisa cada unidad del software, ya que un proceso de revisión válido requiere una inspección centralizada y detallada.

A diferencia de las revisiones y las pruebas de caja blanca, las pruebas funcionales o las hipótesis de prueba de caja negra no saben nada sobre la implementación del software. Prueba la salida impulsada por una entrada controlada. Las pruebas funcionales se componen de programas de prueba escritos por probadores o desarrolladores. Especifican la salida esperada del programa correspondiente a un conjunto específico de entradas del programa. Después de la prueba, el probador compara la salida real con la salida esperada para encontrar el problema. Las pruebas de caja negra pueden detectar eficazmente necesidades no satisfechas, problemas de interfaz, problemas de rendimiento y errores en las funciones más utilizadas en el programa.

Aunque la combinación de estas tecnologías permite detectar la mayoría de los errores ocultos en programas de software específicos, también tienen limitaciones. La revisión de código y las pruebas de caja blanca solo están dirigidas a una pequeña parte del Código a la vez, ignorando el resto del sistema. Las pruebas de caja negra suelen considerar el sistema en su conjunto e ignorar los detalles de implementación. Algunas cuestiones importantes solo se pueden encontrar prestando atención a los detalles de su interacción en todo el sistema; Los métodos tradicionales no pueden identificar estos problemas de manera confiable. El sistema de software debe ser inspeccionado en su conjunto para encontrar las causas específicas de problemas específicos. Dado que normalmente no es posible analizar a fondo cada detalle del programa y su interacción con todas las demás partes del código, el análisis debe dirigirse a aspectos específicos del programa que se sabe que causa problemas.

Este artículo explorará tres áreas de problemas potenciales:

Desbordamiento de la pila

* condiciones de competencia

* punto muerto

Los lectores pueden leer la segunda parte de este artículo en línea, que explorará las siguientes preguntas:

* Cuestiones de programación

* condiciones de reentrada

Todos los problemas anteriores son comunes en sistemas que utilizan tecnología de diseño Multitarea en tiempo real.

Desbordamiento de la pila

El procesador utiliza la pila para almacenar variables temporales, pasar parámetros a la función llamada, guardar el "estado" del hilo, etc. si el sistema no utiliza memoria virtual (en otras palabras, no puede transferir páginas de memoria al disco para liberar espacio de memoria para otros usos), la pila se fija al tamaño del producto cuando sale de la fábrica. Si por alguna razón la pila está fuera del alcance asignado por el programador, el programa se volverá incierto. Esta inestabilidad puede causar fallas graves en el sistema. Por lo tanto, es importante asegurarse de que el sistema pueda asignar suficientes pilas en el peor de los casos.

La única manera de asegurarse de que el desbordamiento de la pila nunca ocurra es analizar el código, determinar el uso máximo de la pila del programa en todos los casos posibles y luego comprobar si se han asignado suficientes pilas. Es poco probable que la prueba desencadene una combinación específica de entradas instantáneas y provoque el peor escenario para el sistema.

El concepto de análisis en profundidad de la pila es relativamente simple:

1. crear un árbol de llamadas para cada hilo independiente.

2. determina el uso de la pila de cada función en el árbol de llamadas.

3. revise cada árbol de llamadas para determinar qué ruta de llamada desde la raíz del árbol hasta la "hoja" externa requiere la pila más grande.

4. agregue el uso máximo de la pila de cada árbol de llamadas de hilo independiente.

5. determinar el uso máximo de la pila de cada rutina de servicio de interrupción (isr) en cada prioridad de interrupción y calcular el total. Sin embargo, si el ISR en sí no tiene una pila, sino que utiliza una pila que interrumpe el hilo, se debe agregar el número máximo de pilas utilizadas por el ISR a la pila de cada hilo.

6. para cada prioridad en el diseño y diseño del pcb, agregue el número de pilas utilizadas para guardar el Estado del procesador cuando se produce la interrupción.

7. si está usando rtos, agregue el número máximo de pilas necesarias para el uso interno del propio rtos (a diferencia de las llamadas al sistema causadas por el Código de aplicación incluido en el paso 2).

Además, hay dos cosas importantes que considerar. En primer lugar, el árbol de llamadas construido solo a partir del código fuente del lenguaje de alto nivel puede ser incompleto. La mayoría de los compiladores utilizan bibliotecas de tiempo de ejecución para optimizar tareas de cálculo comunes, como multiplicación y División de enteros de gran valor, operaciones de coma flotante, etc. estas llamadas solo son visibles en el lenguaje de montaje generado por el compilador. Las propias funciones de tiempo de ejecución pueden usar una gran cantidad de espacio de pila y deben incluirse en el análisis. Si se utiliza el lenguaje C +, el árbol de llamadas también debe incluir todos los siguientes tipos de funciones (métodos): estructura, destructor, operador de carga pesada, estructura de copia y función de conversión. Todos los punteros de función también deben ser analizados y las funciones que llaman están incluidas en el análisis.