Verificación automática de requisitos TOR en el proceso de simulación dinámica

Continuando con el tema "¿Cuál es tu evidencia?", veamos el problema del modelado matemático desde el otro lado. Una vez que estemos convencidos de que el modelo corresponde a la verdad casera de la vida, podemos responder a la pregunta principal: "¿Qué es exactamente lo que tenemos aquí?" Al crear un modelo de un objeto técnico, normalmente queremos asegurarnos de que este objeto cumpla con nuestras expectativas. Para ello se realizan cálculos dinámicos de procesos y se compara el resultado con las necesidades. Se trata de un gemelo digital, un prototipo virtual, etc. pequeños chicos de moda que, en la etapa de diseño, resuelven el problema de cómo asegurarnos de que obtengamos lo que planeamos.

¿Cómo podemos asegurarnos rápidamente de que nuestro sistema sea exactamente lo que diseñamos? ¿Nuestro diseño volará o flotará? Y si vuela ¿a qué altura? Y si flota ¿a qué profundidad?

Este artículo analiza la automatización de la verificación del cumplimiento de los requisitos de un edificio técnico al crear modelos dinámicos de sistemas técnicos. Como ejemplo, veamos un elemento de la especificación técnica de un sistema de refrigeración por aire de un avión.

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 sólo una parte de los requisitos generales de cualquier sistema técnico, pero es precisamente en comprobarlos donde dedicamos tiempo, nervios y dinero a crear 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, considere este pequeño pero realista conjunto de requisitos:

1. Temperatura del aire atmosférico a la entrada del sistema de tratamiento de agua:
   en el estacionamiento - de menos 35 a 35 ºС,
   en vuelo: de menos 35 a 39 ºС.
2. La presión estática del aire atmosférico en vuelo es de 700 a 1013 GPa (de 526 a 760 mm Hg).
3. La presión total del aire en la entrada de la entrada de aire del SVO en vuelo es de 754 a 1200 GPa (de 566 a 1050 mm Hg).
4. Temperatura del aire de refrigeración:
   en el estacionamiento - no más de 27 ºС, para bloques técnicos - no más de 29 ºС,
   en vuelo - no más de 25 ºС, para bloques técnicos - no más de 27 ºС.
5. Flujo de aire de refrigeración:
   cuando está estacionado: al menos 708 kg/h,
   en vuelo - no menos de 660 kg/h.
6. La temperatura del aire en los compartimentos de instrumentos no supera los 60 ºС.
7. La cantidad de humedad fina libre en el aire de refrigeración no supera los 2 g/kg de aire seco.

Incluso dentro de este conjunto limitado de requisitos, hay al menos dos categorías que deben manejarse de manera diferente en el sistema:

• requisitos para las condiciones de funcionamiento del sistema (cláusulas 1-3);
• Requisitos paramétricos para el sistema (cláusulas 3-7).

Requisitos de las condiciones de funcionamiento del sistema.
Las condiciones externas para el sistema que se desarrolla durante el modelado se pueden especificar como condiciones de contorno o como resultado del funcionamiento del sistema general.
En la simulación dinámica, es necesario garantizar que el proceso de simulación cubra las condiciones operativas especificadas.

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

Identificación y codificación de requisitos.

Para facilitar el trabajo con los requisitos, los estándares existentes recomiendan asignar un identificador a cada requisito. Al asignar identificadores, es muy recomendable utilizar un sistema de codificación unificado.

El código de requisito puede ser simplemente un número que represente el número de pedido del requisito, o puede contener un código para el tipo de requisito, un código para el sistema o unidad al que se aplica, un código de parámetro, un código de ubicación y cualquier otra cosa que el ingeniero pueda imaginar. (consulte el artículo para conocer el uso de la codificación)

La Tabla 1 proporciona un ejemplo sencillo de codificación de requisitos.

1. código de la fuente de requisitos Requisitos R TK;
2. código tipo de requisitos E - requisitos - parámetros ambientales o condiciones de funcionamiento
   S - requisitos proporcionados por el sistema;
3. código de estado de la aeronave 0 – cualquiera, G – estacionado, F – en vuelo;
4. código de tipo de parámetro físico T – temperatura, P – presión, G – caudal, humedad H;
5. número de serie del requisito.

ID Requisitos	Descripción	Parámetro
REGT01	Temperatura del aire ambiente a la entrada del sistema de refrigeración por agua: en el estacionamiento - desde menos 35ºС. hasta 35 ºС.
REFT01	Temperatura del aire atmosférico a la entrada del sistema de defensa aérea: en vuelo: de menos 35 ºС a 39 ºС.
REFP01	La presión atmosférica estática en vuelo es de 700 a 1013 hPa (de 526 a 760 mm Hg).
REFP02	La presión total del aire a la entrada de la entrada de aire del SVO en vuelo es de 754 a 1200 hPa (de 566 a 1050 mm Hg).
RSGT01	Temperatura del aire de refrigeración: cuando está estacionado no más de 27 ºС
RSGT02	Temperatura del aire de refrigeración: en el estacionamiento, para unidades técnicas no más de 29 ºС
RSFT01	La temperatura del aire de refrigeración en vuelo no supera los 25 ºС.
RSFT02	Temperatura del aire de refrigeración: en vuelo, para unidades técnicas no más de 27 ºС
RSGG01	Caudal de aire de refrigeración: estacionado no menos de 708 kg/h
RSFG01	Flujo de aire de refrigeración: en vuelo no menos de 660 kg/h
RS0T01	La temperatura del aire en los compartimentos de instrumentos no supera los 60 ºС.
RSH01	La cantidad de humedad fina libre en el aire de refrigeración no supera los 2 g/kg de aire seco.

Diseño de sistema de verificación de requisitos.

Para cada requisito de diseño existe un algoritmo para evaluar la correspondencia de los parámetros de diseño y los parámetros especificados en el requisito. En general, cualquier sistema de control siempre contiene algoritmos para verificar los requisitos simplemente por defecto. E incluso cualquier regulador los contiene. Si la temperatura sale de los límites, el aire acondicionado se enciende. Por tanto, la primera etapa de cualquier regulación es comprobar si los parámetros cumplen los requisitos.

Y dado que la verificación es un algoritmo, podemos usar las mismas herramientas y herramientas que usamos para crear programas de control. Por ejemplo, el entorno SimInTech le permite crear paquetes de proyectos que contienen varias partes del modelo, ejecutadas en forma de proyectos separados (modelo de objetos, modelo de sistema de control, modelo de entorno, etc.).

En este caso, el proyecto de verificación de requisitos se convierte en el mismo proyecto de algoritmo y está conectado al paquete del modelo. Y en el modo de modelado dinámico realiza un análisis para el cumplimiento de los requisitos de las especificaciones técnicas.

Un posible ejemplo de diseño de un sistema se muestra en la Figura 1.

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

Al igual que con los algoritmos de control, los requisitos se pueden redactar en forma de un conjunto de hojas. Para facilitar el trabajo con algoritmos en entornos de modelado estructural como SimInTech, Simulink, AmeSim, se utiliza la capacidad de crear estructuras multinivel en forma de submodelos. Esta organización permite agrupar varios requisitos en conjuntos para simplificar el trabajo con una variedad de requisitos, como se hace con los algoritmos de control (ver Fig. 2).

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

Por ejemplo, en el caso que nos ocupa, se distinguen dos grupos: requisitos para el medio ambiente y requisitos directamente para el sistema. Por tanto, se utiliza una estructura de datos de dos niveles: dos grupos, cada uno de los cuales es una hoja del algoritmo.

Para conectar datos al modelo, se utiliza un esquema estándar para generar una base de datos de señales, que almacena datos para el intercambio entre partes del proyecto.

Al crear y probar software, las lecturas de los sensores (análogos de sensores del sistema real) que utiliza el sistema de control se colocan en esta base de datos.
Para un proyecto de prueba, cualquier parámetro calculado en el modelo dinámico se puede almacenar en la misma base de datos y así usarse para verificar si se cumplen los requisitos.

En este caso, el propio modelo dinámico se puede ejecutar en cualquier sistema de modelado matemático o incluso en forma de programa ejecutable. El único requisito es la presencia de interfaces de software para enviar datos de modelado al entorno externo.

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

En la Figura 4 se presenta un ejemplo de una hoja de verificación de requisitos básicos. Desde el punto de vista del desarrollador, es un diagrama de cálculo convencional 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 similar a los diagramas de diseño de los algoritmos de control. En el lado derecho hay un bloque para leer señales de la base de datos. Este bloque accede a la base de datos de señales durante la simulación.

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

Las condiciones de verificación y los parámetros que se verifican se transfieren a bloques de verificación estándar, en los que se analiza el cumplimiento de estos parámetros con los requisitos especificados. Los resultados se registran en la base de datos de señales de tal manera que se pueden utilizar para generar automáticamente una lista de verificación.

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

Los parámetros a probar no necesariamente utilizan señales contenidas en la base de datos, las cuales están controladas por parámetros calculados durante el proceso de simulación. Nada nos impide realizar cálculos adicionales en el marco del proyecto de requisitos, del mismo modo que calculamos 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 de 5, y el tiempo total de funcionamiento del sistema de corrección no debe exceder de 30 segundos.

En este caso, se agrega al diagrama de diseño de los requisitos un algoritmo para contar el número de arranques y el tiempo total de funcionamiento.

Bloque de verificación de requisitos típicos.

Cada casilla de verificación de requisito estándar está diseñada para calcular el cumplimiento de un requisito de un determinado tipo. Por ejemplo, los requisitos medioambientales incluyen un rango de temperaturas ambiente de funcionamiento cuando está estacionado 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 temperatura especificado./p>

El bloque contiene dos puertos de entrada, parámetro y condición.

El primero se alimenta con el parámetro que se está comprobando. En este caso, “Temperatura exterior”.

Se suministra una variable booleana al segundo puerto: la condición para realizar la verificación.

Si se recibe VERDADERO (1) en la segunda entrada, entonces el bloque realiza un cálculo de verificación de requisitos.

Si la segunda entrada recibe FALSE (0), entonces no se cumplen las condiciones de prueba. Esto es necesario para poder tener en cuenta las condiciones de cálculo. En nuestro caso, esta entrada se utiliza para habilitar o deshabilitar la verificación dependiendo del estado del modelo. Si la aeronave está en tierra durante la simulación, entonces no se verifican los requisitos relacionados con el vuelo, y viceversa: si la aeronave está en vuelo, entonces no se verifican los requisitos relacionados con la operación en el puesto de estacionamiento.

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

Los parámetros de este bloque son:

• condiciones de contorno: límites de rango superior (UpLimit) e inferior (DownLimit) que deben verificarse;
• tiempo de exposición requerido del sistema en los rangos límite (TimeInterval) en segundos;
• ID de solicitud Nombre de solicitud;
• la permisibilidad de exceder el rango Out_range es una variable booleana que determina si un valor que excede el rango verificado es una violación del requisito.

En algunos casos, la salida del valor de prueba indica que el sistema tiene cierto margen y puede estar funcionando fuera de su rango operativo. En otros casos, una salida significa que el sistema no puede mantener los puntos de ajuste dentro del rango.

Figura 6. Un bloque de verificación de propiedades típico en el diagrama y sus parámetros.

Como resultado del cálculo de este bloque, en la salida se forma la variable Resultado, la cual toma los siguientes valores:

• 0 – rNinguno, valor no definido;
• 1 – rHecho, se cumple el requisito;
• 2 – rFault, no se cumple el requisito.

La imagen del bloque contiene:

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

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

Por ejemplo, para verificar el rango de temperatura de funcionamiento de la unidad que se muestra en la Figura 6, el circuito interno se muestra en la Figura 7.

Figura 7. Diagrama interno de la unidad de determinación de rango de temperatura.

Dentro del bloque de circuito, se utilizan las propiedades especificadas en los parámetros del bloque.
Además de analizar el cumplimiento de requisitos, el diagrama interno del bloque contiene un gráfico necesario para visualizar los resultados de la simulación. Este gráfico se puede utilizar tanto para visualizar durante el cálculo como para analizar los resultados después del cálculo.

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

Un ejemplo de un informe creado en base a los resultados de la simulación es un archivo html creado según un formato determinado. El formato se puede configurar arbitrariamente según el formato aceptado por una organización en particular.

Dentro del bloque de circuito, se utilizan las propiedades especificadas en los parámetros del bloque.
Además de analizar el cumplimiento de requisitos, el diagrama interno del bloque contiene un gráfico necesario para visualizar los resultados de la simulación. Este gráfico se puede utilizar tanto para visualizar durante el cálculo como para analizar los resultados después del cálculo.

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

Un ejemplo de un informe creado en base a los resultados de la simulación es un archivo html creado según un formato determinado. El formato se puede configurar arbitrariamente según el formato aceptado por una organización en particular.

Figura 8. Ejemplo de un archivo de informe basado en los resultados de la simulación.

En este ejemplo, el formulario del informe se configura directamente en las propiedades del proyecto y el formato en la tabla se establece como señales globales del proyecto. En este caso, SimInTech resuelve el problema de configurar el informe y el bloque para escribir resultados en un archivo utiliza estas líneas para escribir en el archivo del informe.

Figura 9. Configuración del formato del informe en señales globales del proyecto

Utilizar una base de datos de señales para requerimientos.

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

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

La base de datos de señales proporciona:

• Almacenar todos los parámetros necesarios de los requisitos del sistema.
• Visualización conveniente de los requisitos del proyecto existente a partir de parámetros especificados y resultados de modelado actuales.
• Configurar un bloque o un grupo de bloques utilizando un lenguaje de programación de scripts. Los cambios en la base de datos de señales provocan cambios en los valores de las propiedades del bloque en el diagrama.
• Almacenamiento de descripciones de texto, enlaces a elementos de especificaciones técnicas o identificadores en el sistema de gestión de requisitos.

Las estructuras de bases de datos de señales para requisitos se pueden configurar fácilmente para funcionar con un sistema de gestión de requisitos de terceros. En la Figura 11 se presenta un diagrama general de interacción con los sistemas de gestión de requisitos.

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

La secuencia de interacción entre el proyecto de prueba de SimInTech y el sistema de control de requisitos es la siguiente:

1. Los términos de referencia se desglosan en requisitos.
2. Se identifican los requisitos de las especificaciones técnicas que pueden verificarse mediante modelización matemática de procesos técnicos.
3. Los atributos de los requisitos seleccionados se transfieren a la base de datos de señales de SimInTech en la estructura de bloques estándar (por ejemplo, temperatura máxima y mínima).
4. Durante el proceso de cálculo, los datos estructurales se transfieren a diagramas de diseño de bloques, se realiza el análisis y los resultados se almacenan en una base de datos de señales.
5. Una vez que se completa el cálculo, los resultados del análisis se transfieren al sistema de gestión de requisitos.

Los pasos de requisitos 3 a 5 pueden repetirse durante el proceso de diseño cuando se produzcan cambios en el diseño y/o los requisitos y sea necesario volver a probar el impacto de los cambios.

Conclusiones.

• El prototipo creado del sistema proporciona una reducción significativa en el tiempo de análisis de los modelos existentes para verificar el cumplimiento de los requisitos de las especificaciones técnicas.
• La tecnología de prueba propuesta utiliza modelos dinámicos ya existentes y puede usarse incluso para cualquier modelo dinámico, incluidos aquellos que no se realizan en el entorno SimInTech.
• El uso de la organización de datos por lotes le permite crear paquetes de verificación de requisitos en paralelo con el desarrollo del modelo, o incluso utilizar estos paquetes como especificaciones técnicas para el desarrollo del modelo.
• La tecnología se puede integrar con los sistemas de gestión de requisitos existentes sin costes significativos.

Para aquellos que leyeron hasta el final, enlace a un vídeo que muestra cómo funciona el prototipo.

Fuente: habr.com