Uso del modelado y la simulación para realizar pruebas de diseños y requisitos

El modelado es una forma eficiente y económica de representar un sistema del mundo real. Un modelo puede representar aspectos clave del sistema, tales como los requisitos subyacentes, los componentes y cómo se comunican tales componentes entre sí. El modelo se puede simular, lo que permite a los diseñadores realizar pruebas de los diseños antes de que esté disponible el hardware, o bien probar condiciones que resultan difíciles o caras de replicar en el mundo real. La iteración entre el modelado y la simulación puede mejorar la calidad del diseño del sistema en una etapa temprana y reducir así el número de errores que se descubran más adelante en el proceso de diseño.

A pesar de estas ventajas, los diseñadores que confían principalmente en la codificación manual no siempre aprovechan el modelado y la simulación. La configuración de las pruebas puede ser difícil y llevar tiempo, y si se utilizan herramientas independientes para cada dominio puede ser un reto conseguir una visión del diseño a nivel de sistema. Como consecuencia, los defectos que se podrían haber descubierto durante la fase de modelado y simulación a menudo se localizan durante la fase de implementación, cuando resulta más caro corregirlos.

Estos problemas se han abordado en Simulink®, una plataforma para el modelado y la simulación. Simulink no solo soporta modelización multidominio, sino también simulación, con su propio conjunto de solvers de ecuaciones diferenciales ordinarias (EDO). Una ventaja básica de utilizar Simulink es que se pueden representar distintos dominios, tales como sistemas de control, máquinas de estado y modelos de entorno, en un solo modelo, y posteriormente ejecutar simulaciones dentro de Simulink para comprobar que el modelo se ha creado correctamente. Conforme se ejecuta la simulación, se puede acceder a prestaciones de análisis, tales como visualizaciones de datos, animaciones de estado y puntos de interrupción condicionales. Una vez que la simulación ha concluido, se pueden analizar los datos registrados con scripts de MATLAB y herramientas de visualización.

En este artículo, describimos un flujo de trabajo para crear un modelo de componente a partir de requisitos, simulando y probando ese modelo de componente y después conectándolo a un modelo a nivel de sistema para llevar a cabo más simulaciones y pruebas. Con objeto de ilustrar este flujo de trabajo crearemos y probaremos el componente de gestión de fallos del HL-20, un vehículo de reentrada diseñado por la NASA como complemento del or- bitador del Transbordador Espacial. Conectaremos nuestro componente a un modelo a nivel de sistema que incluye modelos de entorno y controles de vuelo, además de orientación, navegación y control (GNC, por sus siglas en inglés); posteriormente, simularemos el modelo a nivel de sistema para validar su comportamiento.

El modelo utilizado en este ejemplo está disponible en Aerospace Blockset.

Creación del modelo de componente a partir de los requisitos

El primer paso es modelar la lógica de gestión de fallos del sistema actuador. El documento de requisitos establece cinco modos posibles para el actuador: pasivo, espera, activo, aislado y apagado. Para simplificar, consideraremos solo los cuatro primeros modos. Representamos estos modos agregando cuatro estados a un diagrama de estado de Stateflow® (Figura 1).

A continuación, tenemos que determinar cómo pasará el sistema de un estado (o modo) a otro. Sirviéndonos de la información facilitada en el documento de requisitos, agregamos transiciones que conectan los estados y especificamos qué condiciones se deben cumplir para que el sistema cambie de estado. Asimismo, agrupamos los estados Pasivo, Activo y Espera en un único superestado, ya que todos ellos pasan al estado Aislado cuando se da la misma condición. Esta técnica de modelado jerárquica nos ayuda a modelizar una lógica compleja de forma visual y sencilla (Figura 2).

Seguimos creando el modelo, conectando cada elemento a un requisito de sistema concreto (Figura 3). Más tarde podremos remontarnos en nuestro modelo hasta el documento de requisitos para explicar por qué se tomó una determinada decisión sobre el diseño.

Una vez que hemos creado la lógica del actuador interior izquierdo, podemos reutilizar ese diseño para el actuador interior derecho, dado que la estructura es exactamente la misma. Los únicos elementos que hay que cambiar son las condiciones relativas a cada transición, según lo descrito en el documento de requisitos (Figura 4).

Comprobación del componente mediante simulación

Ahora que el componente está creado parcialmente, estamos listos para ejecutar simulaciones con las que comprobar que se comporta correctamente. A tal efecto, configuramos un sencillo marco de pruebas que lleva señales de entrada al componente mediante una combinación de bloques de conmutación y constantes (Figura 5).

Con Simulink y Stateflow podemos dar comienzo a la simulación sin necesidad de definir variables manualmente. Al pulsar el botón Play, aparece un cuadro de diálogo que muestra las variables que han de ser definidas para que se pueda ejecutar la simulación. Al pulsar OK, se crean automáticamente esas variables (Figura 6).

Mientras se ejecuta la simulación, el diagrama de estado se convierte en una animación, lo que nos permite saber qué estado se encuentra activo en un momento dado y cómo pasa el sistema de un estado a otro.

Una prueba ad hoc mediante la activación o desactivación de las señales de entrada revela un defecto en el diseño (Figura 7). Cuando se activa el actuador interior izquierdo, el actuador interior derecho también se debería activar. El que hayamos podido configurar las condiciones de entrada para que esto no ocurra indica que nuestro diseño tiene un defecto.

Resulta que la condición de la transición de Activo a Espera tiene un fallo. Dado que hemos vinculado cada condición a un requisito, podemos remontarnos desde esa condición hasta el requisito subyacente y comprobar que el fallo tiene su origen en el documento de requisitos y no en el diseño (Figura 8).

En la última línea se debería leer “or the left inner actuator is in the Active mode” (es decir, “o que el actuador interior izquierdo se encuentre en el modo Activo”).

Corregimos la redacción del documento de requisitos, revisamos la condición, volvemos a simular el modelo y comprobamos que ahora el sistema se comporta correctamente en respuesta a las señales de entrada.

Comprobación del sistema con el nuevo componente

Ahora que se ha comprobado el componente FDIR independientemente, estamos listos para probarlo en el modelo a nivel de sistema. Incorporamos el componente en el modelo en forma de bloque Model con el nombre FDIR_application. Una vez que el modelo está integrado en el modelo del sistema, podemos seguir trabajando en él de manera independiente del resto del sistema mediante la capacidad de referenciación de modelos de Simulink (Figura 9).

Simulamos el modelo a nivel de sistema y visualizamos el comportamiento del componente en el diagrama de estado, así como el comportamiento del sistema en su conjunto, mediante FlightGear, una herramienta de visualización de código abierto.

Para probar el sistema, configuramos un marco que inyecta fallos en el sistema actuador, a fin de poder comprobar que tanto el componente como el sistema en su conjunto responden correctamente (Figura 10).

Hasta el momento, hemos creado un componente a partir de los requisitos, hemos simulado y probado dicho componente y después lo hemos conectado a un modelo a nivel de sistema para realizar más simulaciones y pruebas. Existen diversos pasos adicionales que podemos llevar a cabo para mejorar el flujo de trabajo de modelización y simulación.

Por ejemplo, podemos hacer lo siguiente:

• Implementar un proceso de comprobación y verificación formal con pruebas de diseño, análisis de cobertura y generación de casos de prueba.

• Aumentar el rendimiento de la simulación mediante Performance Advisor en Simulink.

• Sustituir los bloques con conexiones al hardware a medida que el hardware vaya estando disponible.

• Utilizar herramientas para comprobar que los parámetros de diseño son óptimos.

Sea cual sea el siguiente paso que se elija, la clave radica en modelizar, simular y probar el sistema con la mayor frecuencia y lo más pronto que sea posible, con objeto de detectar y corregir los defectos de forma temprana y así reducir el coste de desarrollo del sistema en su conjunto.