Verificación automática de los requisitos del pliego de condiciones durante la modelización dinámica.

Continuando con el tema «¿Cuáles son tus pruebas?», examinemos el problema del modelado matemático desde una perspectiva diferente. Después de asegurarnos de que el modelo es fiel a la verdad de la vida, podemos responder a la pregunta principal: «¿qué es lo que realmente tenemos aquí?». Al crear un modelo de un objeto técnico, generalmente queremos asegurarnos de que este objeto cumpla con nuestras expectativas. Para esto se realizan cálculos dinámicos de los procesos y el resultado se compara con los requisitos. Esto es lo que se conoce como gemelo digital, prototipo virtual y demás términos modernos que, en la fase de diseño, tienen la tarea de garantizar que obtengamos lo que planeamos.

¿Cómo podemos asegurarnos rápidamente de que nuestro sistema es exactamente lo que estamos diseñando, si volará o flotará nuestra construcción? ¿Y si vuela, cuán alto? ¿Y si flota, cuán profundo?

En este artículo se analiza la automatización de la verificación del cumplimiento de los requisitos técnicos al crear modelos dinámicos de sistemas técnicos. Como ejemplo, examinaremos un elemento del pliego de condiciones para un sistema de refrigeración por aire de una aeronave.

Consideramos aquellos requisitos que pueden expresarse numéricamente y verificarse matemáticamente en base a un modelo de cálculo específico. Está claro que esto es solo una parte de los requisitos generales para cualquier sistema técnico, pero es precisamente en su verificación donde invertimos tiempo, nervios y dinero en la creación de modelos dinámicos del objeto.

Al describir los requisitos técnicos en forma de documento, se pueden distinguir varios tipos de requisitos diferentes, cada uno de los cuales requiere diferentes enfoques para la formación de la verificación automática del cumplimiento de los requisitos.

Por ejemplo, consideremos este pequeño pero real conjunto de requisitos:

1. Temperatura del aire atmosférico a la entrada del SVO:
   en reposo − de menos 35 a 35 ºC,
   en vuelo − de menos 35 a 39 ºC.
2. Presión estática del aire atmosférico en vuelo − de 700 a 1013 hPa (de 526 a 760 mm Hg).
3. Presión total del aire a la entrada del tomador de aire del SVO en vuelo − de 754 a 1200 hPa (de 566 a 1050 mm Hg).
4. Temperatura del aire de enfriamiento:
   en reposo − no más de 27 ºC, para bloques técnicos − no más de 29 ºC,
   en vuelo − no más de 25 ºC, para bloques técnicos − no más de 27 ºC.
5. Consumo de aire de refrigeración:
   en tierra − no menos de 708 kg/h,
   en vuelo − no menos de 660 kg/h.
6. La temperatura del aire en los compartimentos de instrumentos − no más de 60 ºC.
7. La cantidad de humedad libre en el aire de refrigeración − no más de 2 g/kg de aire seco.

Incluso en este conjunto limitado de requisitos se pueden destacar al menos dos categorías que deben ser tratadas de manera diferente en el sistema:

• requisitos de las condiciones de operación del sistema (p.p. 1-3);
• requisitos paramétricos del sistema (p.p. 3-7).

Requisitos de las condiciones de operación del sistema
Las condiciones externas para el sistema en desarrollo durante la modelación pueden ser establecidas como condiciones límite, o como resultado del funcionamiento del sistema general.
En la modelación dinámica, es necesario asegurarse de que los modos de operación establecidos sean cubiertos por el proceso de modelación.

Requisitos paramétricos del sistema
Estos requisitos son parámetros proporcionados por el propio sistema. Durante el proceso de modelación, podemos obtener estos parámetros como resultados de los cálculos y asegurarnos de que los requisitos se cumplen en cada cálculo específico.

Identificación y codificación de requisitos

Para facilitar el trabajo con los requisitos, las normas existentes recomiendan asignar un identificador a cada requisito. Al asignar identificadores, es muy deseable utilizar un sistema de codificación uniforme.

El código del requisito puede ser simplemente un número que refleja el número de orden del requisito, o puede incluir el código del tipo de requisito, el código del sistema o equipo al que se aplica, el código del parámetro, el código de la ubicación y mucho más de lo que pueda imaginar un ingeniero. (una opción de utilización de codificación se puede ver en el artículo)

En la tabla 1 se presenta un ejemplo simple de codificación de requisitos.

1. código de fuente de requisitos R- requisitos TS;
2. código tipo de requisitos E – requisitos – parámetros del entorno externo, o condiciones de operación
   S — requisitos proporcionados por el sistema;
3. código del estado del avión 0 – cualquiera, G – en tierra, F – en vuelo;
4. código del tipo de parámetros físicos T – temperatura, P – presión, G – flujo, humedad H;
5. número de orden del requisito.

Proyecto del sistema de verificación de requisitos.

Para cada requisito calculado hay un algoritmo de evaluación de la conformidad de los parámetros calculados con los parámetros establecidos en el requisito. En general, cualquier sistema de gestión siempre contiene, por defecto, algoritmos de verificación de requisitos. Incluso cualquier regulador los contiene. Si la temperatura excede el límite, se activa el aire acondicionado. Así, la primera fase de cualquier regulación es la verificación de la conformidad de los parámetros con el requisito.

Y dado que la verificación es un algoritmo, se pueden utilizar las mismas herramientas y medios que usamos para crear programas de control. Por ejemplo, el entorno SimInTech permite crear paquetes de proyectos que contienen diversas partes del modelo, realizadas como proyectos separados (modelo de objeto, modelo de sistema de control, modelo del entorno, etc.).

El proyecto de verificación de requisitos en este caso se convierte en un proyecto de algoritmos y se conecta al paquete del modelo. Y en el modo de modelación dinámica, realiza el análisis de conformidad con los requisitos del pliego de condiciones.

Un posible ejemplo de diseño del proyecto del sistema se presenta en la Figura 1.

Figura 1. Ejemplo de diseño del proyecto de verificación.

Al igual que para los algoritmos de control, los requisitos se pueden presentar en forma de un conjunto de hojas. Para facilitar el trabajo con algoritmos en entornos de modelado estructural como SimInTech, Simulink, y AmeSim, se utilizan las capacidades de creación de estructuras jerárquicas en forma de submodelos. Esta organización permite agrupar diferentes requisitos en conjuntos para simplificar el trabajo con grandes cantidades de requisitos, tal como se hace para los algoritmos de control (ver figura 2).

Figura 2. Estructura jerárquica del modelo de verificación de requisitos.

Por ejemplo, en el caso considerado, se han identificado dos grupos: requisitos para el entorno y requisitos directamente relacionados con el sistema. Por lo tanto, se utiliza una estructura de datos de dos niveles: dos grupos, cada uno de los cuales es una hoja del algoritmo.

Para conectar los datos al modelo se utiliza un esquema estándar de formación de base de datos de señales, en el que se almacenan datos para el intercambio entre las partes del proyecto.

Al crear y probar software, en esta base se colocan las lecturas de los sensores (análogos a los sensores reales del sistema), que son utilizados por el sistema de control.
Para el proyecto de pruebas, en esta misma base de datos se pueden guardar cualquier parámetro calculado en el modelo dinámico, y así ser utilizado para verificar el cumplimiento de los requisitos.

El propio modelo dinámico en este caso puede ser implementado en cualquier sistema de modelado matemático o incluso en forma de un programa ejecutable. El único requisito es la existencia de interfaces de software para emitir datos de modelado al entorno externo.

Figura 3. Conexión del proyecto de verificación al modelo integral.

Un ejemplo de una hoja básica de verificación de requisitos se presenta en la figura 4. Desde el punto de vista del desarrollador, representa un esquema de cálculo habitual, en el que se presenta gráficamente el algoritmo de verificación de requisitos.

Figura 4. Hoja de verificación de requisitos.

Las partes principales de la hoja de verificación se describen en la figura 5. El algoritmo de verificación se forma de manera análoga a los esquemas de cálculo de los algoritmos de control. En la parte derecha se encuentra un bloque de lectura de señales de la base de datos. En este bloque se accede a la base de datos de señales durante la modelación.

Las señales recibidas se analizan para calcular las condiciones de verificación de los requisitos. En este caso, se realiza un análisis de altura para determinar la posición del avión (si está en el estacionamiento o en vuelo). Para este propósito, se pueden utilizar otras señales y parámetros calculados del modelo.

Las condiciones de verificación y los parámetros a verificar se envían a bloques de verificación estándar, donde se analiza la conformidad de esos parámetros con los requisitos establecidos. Los resultados se registran en la base de datos de señales de manera que se pueden usar para generar automáticamente una lista de verificación.

Figura 5. Estructura de la hoja de cálculo de verificación de requisitos.

No es necesario utilizar señales contenidas en la base de datos como parámetros a verificar, que son gestionados por parámetros calculados durante el proceso de modelado. No hay nada que impida realizar cálculos adicionales en el marco del proyecto de requisitos, así como hacemos para calcular las condiciones de verificación.

Por ejemplo, este requisito:

El número de activaciones del sistema de corrección durante el vuelo hacia el objetivo no debe exceder 5, y el tiempo total de funcionamiento del sistema de corrección no debe superar 30 segundos.

En este caso, se añade un algoritmo contador al esquema de cálculo del proyecto de requisitos para contabilizar el número de activaciones y el tiempo total de funcionamiento.

Bloque de verificación de requisitos estándar.

Cada bloque de verificación de requisitos está diseñado para calcular el cumplimiento de un tipo específico de requisito. Por ejemplo, en los requisitos del entorno, hay un rango de temperaturas de trabajo del aire ambiente en el estacionamiento y en vuelo. Este bloque debe recibir como parámetro la temperatura del aire en el modelo y determinar si este parámetro cubre el rango de temperaturas establecido.

El bloque contiene dos puertos de entrada, param y condition.

El primero recibe el parámetro a verificar. En este caso, "Temperatura del ambiente exterior".

Al segundo puerto se le asigna una variable booleana: la condición de cumplimiento de la verificación.

Si el segundo puerto recibe TRUE (1), el bloque realiza el cálculo de la verificación del requisito.

Si la segunda entrada recibe FALSE (0), las condiciones de verificación no se cumplen. Esto es necesario para que se puedan tener en cuenta las condiciones de cálculo. En nuestro caso, esta entrada se utiliza para activar o desactivar la verificación según el estado del modelo. Si la aeronave se encuentra en tierra durante la simulación, no se verifican los requisitos relacionados con el vuelo, y viceversa: si la aeronave está en vuelo, no se verifican los requisitos relacionados con la operación en tierra.

Esta entrada también se puede utilizar al configurar el modelo, por ejemplo, en la etapa inicial del cálculo. Cuando el modelo se lleva al estado requerido, los bloques de verificación se desactivan, pero tan pronto como el sistema alcanza el régimen de operación deseado, los bloques de verificación se activan.

Los parámetros de este bloque se establecen como:

• condiciones límite: el límite superior (UpLimit) y el límite inferior (DownLimit) de los rangos que deben ser verificados;
• el tiempo de espera requerido del sistema en los rangos límite (TimeInterval) en segundos;
• el identificador del requisito ReqName;
• la permisibilidad de salir del rango Out_range – una variable boolean que determina si la salida del valor se considera una violación del requisito.

En algunos casos, la salida del valor verificado significa que el sistema tiene un margen y puede operar fuera del rango de trabajo. En otros casos, la salida significa que el sistema no puede mantener los parámetros establecidos dentro del rango.

Figura 6. Bloque de verificación típico del atributo en el diagrama y sus parámetros.

Como resultado del cálculo de este bloque, se genera la variable Result, que puede tomar los siguientes valores:

• 0 – rNone, valor no definido;
• 1 – rDone, requisito cumplido;
• 2 – rFault, requisito no cumplido.

La imagen del bloque contiene:

• texto del identificador;
• muestras digitales de los parámetros de los límites de medición;
• identificación de color del estado del parámetro.

Dentro del bloque puede haber un esquema de inferencia lógica bastante complejo.

Por ejemplo, para verificar el rango operativo de temperatura del bloque mostrado en la figura 6, el esquema interno se presenta en la figura 7.

Figura 7. Esquema interno del bloque de determinación del rango de temperatura.

Dentro del bloque, se utilizan las propiedades definidas en los parámetros del bloque.
Además del análisis de conformidad de los requisitos, el esquema interno del bloque contiene un gráfico necesario para mostrar los resultados de la simulación. Este gráfico puede ser utilizado tanto para la visualización durante el cálculo como para el análisis de resultados posterior al cálculo.

Los resultados del cálculo se transmiten a la salida del bloque y se registran simultáneamente en un archivo de reporte general, que se crea a partir de los resultados de todo el proyecto. (ver figura 8)

El ejemplo de reporte, creado a partir de los resultados de la simulación, representa un archivo HTML, diseñado de acuerdo a un formato específico. El formato puede ser configurado de forma arbitraria para ajustarse al que utiliza una organización particular.

Dentro del bloque, se utilizan las propiedades definidas en los parámetros del bloque.
Además del análisis de conformidad de los requisitos, el esquema interno del bloque contiene un gráfico necesario para mostrar los resultados de la simulación. Este gráfico puede ser utilizado tanto para la visualización durante el cálculo como para el análisis de resultados posterior al cálculo.

Los resultados del cálculo se transmiten a la salida del bloque y se registran simultáneamente en un archivo de reporte general, que se crea a partir de los resultados de todo el proyecto. (ver figura 8)

El ejemplo de reporte, creado a partir de los resultados de la simulación, representa un archivo HTML, diseñado de acuerdo a un formato específico. El formato puede ser configurado de forma arbitraria para ajustarse al que utiliza una organización particular.

Figura 8. Ejemplo de archivo de reporte a partir de los resultados de la simulación.

En este ejemplo, la configuración del formulario del reporte se realiza directamente en las propiedades del proyecto, mientras que el formato en la tabla se establece como señales globales del proyecto. En este caso, SimInTech resuelve la tarea de configuración del reporte por sí mismo, y el bloque de registro de resultados en el archivo utiliza estas líneas para escribir en el archivo de reporte.

Figura 9. Configuración del formato de reporte en las señales globales del proyecto.

Uso de la base de datos de señales para los requisitos.

Para automatizar el trabajo con la configuración de propiedades para cada bloque estándar, se crea una estructura tipo en la base de datos de señales. (ver figura 10)

Figura 10. Ejemplo de la estructura del bloque de verificación de requisitos en la base de datos de señales.

La base de datos de señales proporciona:

• Almacenamiento de todos los parámetros necesarios para los requisitos del sistema.
• Visualización conveniente de los requisitos existentes en el proyecto a partir de los parámetros establecidos y los actuales resultados de simulación.
• Configuración de un bloque o de un grupo de bloques utilizando un lenguaje de programación de scripts. Los cambios en la base de datos de señales llevan a cambios en los valores de las propiedades del bloque en el esquema.
• Almacenamiento de descripciones textuales, enlaces a secciones del documento de requisitos o identificadores en el sistema de gestión de requisitos.

Las estructuras de la base de datos de señales para requisitos pueden ser fácilmente configuradas para trabajar con un sistema externo de gestión de requisitos. El esquema general de interacción con los sistemas de gestión de requisitos se presenta en la figura 11.

Figura 11. Esquema de interacción con el sistema de gestión de requisitos.

La secuencia de interacción del proyecto de prueba SimInTech con el sistema de gestión de requisitos es la siguiente:

1. El pliego de condiciones se descompone en requisitos.
2. Se destacan aquellos requisitos del pliego de condiciones que pueden ser verificados mediante modelado matemático de procesos técnicos.
3. Los atributos de los requisitos destacados se transmiten a la base de datos de señales de SimInTech en estructuras de bloques típicos (por ejemplo, temperatura máxima y mínima).
4. Durante el cálculo, los datos de las estructuras se envían a los esquemas de cálculo de los bloques, se realiza el análisis y los resultados se guardan en la base de datos de señales.
5. Al finalizar el cálculo, los resultados del análisis se envían al sistema de gestión de requisitos.

Las etapas de trabajo con los requisitos 3 a 5 pueden repetirse durante el proceso de diseño, cuando ocurren cambios en el diseño y/o requisitos y, por lo tanto, es necesaria una nueva verificación del impacto de los cambios introducidos.

Conclusiones.

• El prototipo del sistema creado garantiza una reducción significativa del tiempo de análisis de los modelos existentes en relación con el cumplimiento de los requisitos del pliego de condiciones.
• La tecnología de prueba propuesta utiliza modelos dinámicos ya existentes y puede ser utilizada incluso para cualquier modelo dinámico, incluyendo aquellos desarrollados fuera del entorno SimInTech.
• El uso de una organización de datos por lotes permite crear paquetes de verificación de requisitos, paralelamente al desarrollo de modelos, o incluso utilizar estos paquetes como pliego de condiciones para el desarrollo de modelos.
• La tecnología puede integrarse sin costes significativos con los sistemas de gestión de requisitos existentes.

Para aquellos que han llegado hasta el final, enlace al video de demostración del funcionamiento del prototipo.

Fuente: habr.com