Verificación automática dos requisitos TOR no proceso de simulación dinámica

Continuando co tema "Cal é a súa evidencia?", vexamos o problema da modelización matemática dende o outro lado. Despois de estar convencidos de que o modelo corresponde á verdade caseira da vida, podemos responder á pregunta principal: "¿Que temos aquí exactamente?" Ao crear un modelo dun obxecto técnico, normalmente queremos asegurarnos de que este obxecto satisfaga as nosas expectativas. Para iso, realízanse cálculos dinámicos dos procesos e compárase o resultado cos requisitos. Trátase dun xemelgo dixital, un prototipo virtual, etc. rapaces de moda que, na fase de deseño, resolven o problema de como asegurarnos de conseguir o que planeamos.

Como podemos asegurarnos rapidamente de que o noso sistema sexa exactamente o que deseñamos, o noso deseño voará ou flotará? E se voa, a que altura? E se flota, a que profundidade?

Este artigo analiza a automatización da verificación do cumprimento dos requisitos dun edificio técnico ao crear modelos dinámicos de sistemas técnicos. Como exemplo, vexamos un elemento da especificación técnica dun sistema de refrixeración por aire de avión.

Consideramos aqueles requisitos que poden ser expresados ​​numericamente e verificados matematicamente a partir dun modelo de cálculo específico. Está claro que isto é só parte dos requisitos xerais de calquera sistema técnico, pero é en comprobalos cando gastamos tempo, nervios e cartos na creación de modelos dinámicos do obxecto.

Ao describir os requisitos técnicos en forma de documento, pódense distinguir varios tipos de requisitos diferentes, cada un dos cales require enfoques diferentes para a formación da verificación automática do cumprimento dos requisitos.

Por exemplo, considere este pequeno pero realista conxunto de requisitos:

1. Temperatura do aire atmosférico á entrada do sistema de tratamento de auga:
   no aparcamento - de menos 35 a 35 ºС,
   en voo - de menos 35 a 39 ºС.
2. A presión estática do aire atmosférico en voo é de 700 a 1013 GPa (de 526 a 760 mm Hg).
3. A presión total do aire na entrada da entrada de aire SVO en voo é de 754 a 1200 GPa (de 566 a 1050 mm Hg).
4. Temperatura do aire de refrixeración:
   no aparcamento - non máis de 27 ºС, para bloques técnicos - non máis de 29 ºС,
   en voo - non máis de 25 ºС, para bloques técnicos - non máis de 27 ºС.
5. Fluxo de aire de refrixeración:
   cando está estacionado - polo menos 708 kg/h,
   en voo - non menos de 660 kg/h.
6. A temperatura do aire nos compartimentos dos instrumentos non supera os 60 ºС.
7. A cantidade de humidade libre fina no aire de refrixeración non supera os 2 g/kg de aire seco.

Incluso dentro deste conxunto limitado de requisitos, hai polo menos dúas categorías que deben ser tratadas de forma diferente no sistema:

• requisitos para as condicións de funcionamento do sistema (cláusulas 1-3);
• requisitos paramétricos para o sistema (cláusulas 3-7).

Requisitos das condicións de funcionamento do sistema
As condicións externas para o sistema que se está a desenvolver durante a modelización pódense especificar como condicións de contorno ou como resultado do funcionamento do sistema xeral.
Na simulación dinámica, é necesario asegurarse de que as condicións de operación especificadas estean cubertas polo proceso de simulación.

Requisitos do sistema paramétrico
Estes requisitos son parámetros proporcionados polo propio sistema. Durante o proceso de modelado, podemos obter estes parámetros como resultados do cálculo e asegurarnos de que se cumpren os requisitos en cada cálculo específico.

Identificación e codificación de requisitos

Para facilitar o traballo cos requisitos, os estándares existentes recomendan asignar un identificador a cada requisito. Ao asignar identificadores, é moi desexable utilizar un sistema de codificación unificado.

O código de requisito pode ser simplemente un número que representa o número de orde do requisito ou pode conter un código para o tipo de requisito, un código para o sistema ou unidade ao que se aplica, un código de parámetro, un código de localización e calquera outra cousa que o enxeñeiro poida imaxinar. (consulta o artigo para o uso da codificación)

A táboa 1 ofrece un exemplo sinxelo de codificación de requisitos.

1. código da fonte dos requisitos R-requisitos TK;
2. código tipo de requisitos E - requisitos - parámetros ambientais ou condicións de funcionamento
   S - requisitos proporcionados polo sistema;
3. código de estado da aeronave 0 - calquera, G - estacionado, F - en voo;
4. código de tipo de parámetro físico T - temperatura, P - presión, G - caudal, humidade H;
5. número de serie do requisito.

ID Requisitos	Descrición	Parámetro
REGT01	Temperatura do aire ambiente na entrada do sistema de refrixeración de auga: no aparcamento - desde menos 35ºС. ata 35 ºС.
REFT01	Temperatura do aire atmosférico na entrada do sistema de defensa aérea: en voo - de menos 35 ºС ata 39 ºС.
REFP01	A presión atmosférica estática en voo é de 700 a 1013 hPa (de 526 a 760 mm Hg).
REFP02	A presión total do aire na entrada da entrada de aire SVO en voo é de 754 a 1200 hPa (de 566 a 1050 mm Hg).
RSGT01	Temperatura do aire de arrefriamento: cando está estacionado non máis de 27 ºС
RSGT02	Temperatura do aire de refrixeración: no aparcamento, para unidades técnicas non superior a 29 ºС
RSFT01	A temperatura do aire de arrefriamento en voo non supera os 25 ºС
RSFT02	Temperatura do aire de refrixeración: en voo, para unidades técnicas non superior a 27 ºС
RSGG01	Caudal de aire de refrixeración: cando está estacionado non menos de 708 kg/h
RSFG01	Caudal de aire de refrixeración: en voo non inferior a 660 kg/h
RS0T01	A temperatura do aire nos compartimentos dos instrumentos non supera os 60 ºС
RSH01	A cantidade de humidade libre fina no aire de refrixeración non supera os 2 g/kg de aire seco

Deseño do sistema de verificación de requisitos.

Para cada requisito de deseño existe un algoritmo para avaliar a correspondencia dos parámetros de deseño e os parámetros especificados no requisito. En xeral, calquera sistema de control sempre contén algoritmos para comprobar os requisitos simplemente por defecto. E ata calquera regulador os contén. Se a temperatura supera os límites, o aire acondicionado acende. Así, a primeira etapa de calquera normativa é comprobar se os parámetros cumpren os requisitos.

E como a verificación é un algoritmo, entón podemos usar as mesmas ferramentas e ferramentas que usamos para crear programas de control. Por exemplo, o ambiente SimInTech permítelle crear paquetes de proxectos que conteñan varias partes do modelo, executados en forma de proxectos separados (modelo de obxecto, modelo de sistema de control, modelo de ambiente, etc.).

O proxecto de verificación de requisitos neste caso convértese no mesmo proxecto de algoritmo e está conectado ao paquete modelo. E na modalidade de modelado dinámico realiza unha análise para o cumprimento dos requisitos das especificacións técnicas.

Na figura 1 móstrase un posible exemplo de deseño de sistema.

Figura 1. Exemplo de deseño dun proxecto de verificación.

Do mesmo xeito que para os algoritmos de control, os requisitos pódense elaborar como un conxunto de follas. Para a comodidade de traballar con algoritmos en contornos de modelado estrutural como SimInTech, Simulink, AmeSim, utilízase a capacidade de crear estruturas de varios niveis en forma de submodelos. Esta organización permite agrupar varios requisitos en conxuntos para simplificar o traballo cunha serie de requisitos, como se fai para os algoritmos de control (ver figura 2).

Figura 2. Estrutura xerárquica do modelo de verificación de requisitos.

Por exemplo, no caso considerado, distínguense dous grupos: requisitos para o medio ambiente e requisitos directamente para o sistema. Polo tanto, utilízase unha estrutura de datos de dous niveis: dous grupos, cada un dos cales é unha folla do algoritmo.

Para conectar datos ao modelo, utilízase un esquema estándar para xerar unha base de datos de sinais, que almacena datos para o intercambio entre partes do proxecto.

Ao crear e probar software, colócanse nesta base de datos as lecturas dos sensores (análogos dos sensores do sistema reais) que utiliza o sistema de control.
Para un proxecto de proba, calquera parámetro calculado no modelo dinámico pódese almacenar na mesma base de datos e, así, utilizarse para comprobar se se cumpren os requisitos.

Neste caso, o propio modelo dinámico pódese executar en calquera sistema de modelado matemático ou mesmo en forma de programa executable. O único requisito é a presenza de interfaces de software para emitir datos de modelado ao ambiente externo.

Figura 3. Conectando o proxecto de verificación ao modelo complexo.

Un exemplo de folla de verificación de requisitos básicos preséntase na Figura 4. Desde o punto de vista do desenvolvedor, é un diagrama de cálculo convencional no que se presenta graficamente o algoritmo de verificación de requisitos.

Figura 4. Ficha de verificación de requisitos.

As partes principais da folla de comprobación descríbense na figura 5. O algoritmo de comprobación fórmase de forma similar aos diagramas de deseño dos algoritmos de control. No lado dereito hai un bloque para ler sinais da base de datos. Este bloque accede á base de datos de sinais durante a simulación.

Os sinais recibidos analízanse para calcular as condicións de verificación dos requisitos. Neste caso, realízase a análise da altitude para determinar a posición da aeronave (se está estacionada ou en voo). Para este fin, pode usar outros sinais e parámetros calculados do modelo.

As condicións de verificación e os parámetros que se verifican transfírense a bloques de verificación normalizados, nos que se analizan estes parámetros para o cumprimento dos requisitos especificados. Os resultados rexístranse na base de datos de sinais de forma que se poidan utilizar para xerar automaticamente unha lista de verificación.

Figura 5. Estrutura da folla de cálculo de verificación de requisitos.

Os parámetros a probar non usan necesariamente sinais contidos na base de datos, que son controlados por parámetros calculados durante o proceso de simulación. Nada nos impide realizar cálculos adicionais no marco dos requisitos do borrador, do mesmo xeito que calculamos as condicións de verificación.

Por exemplo, este requisito:

O número de activacións do sistema de corrección durante o voo ao destino non debe exceder de 5 e o tempo total de funcionamento do sistema de corrección non debe exceder os 30 segundos.

Neste caso, engádese ao diagrama de deseño dos requisitos un algoritmo para contrarrestar o número de arranques e o tempo total de funcionamento.

Bloque de verificación de requisitos típicos.

Cada caixa de verificación de requisitos estándar está deseñada para calcular o cumprimento dun requisito dun determinado tipo. Por exemplo, os requisitos ambientais inclúen unha gama de temperaturas de funcionamento ambiente cando está estacionado e en voo. Este bloque debe recibir a temperatura do aire no modelo como parámetro e determinar se este parámetro cobre o rango de temperatura especificado./p>

O bloque contén dous portos de entrada, parámetro e condición.

O primeiro aliméntase co parámetro que se está a comprobar. Neste caso, "Temperatura externa".

Ofrécese unha variable booleana ao segundo porto, a condición para realizar a comprobación.

Se se recibe TRUE (1) na segunda entrada, entón o bloque realiza un cálculo de verificación de requisitos.

Se a segunda entrada recibe FALSO (0), non se cumpren as condicións de proba. Isto é necesario para que se poidan ter en conta as condicións de cálculo. No noso caso, esta entrada úsase para activar ou desactivar a comprobación dependendo do estado do modelo. Se a aeronave está en terra durante a simulación, non se verifican os requisitos relacionados co voo e viceversa: se a aeronave está en voo, non se verifican os requisitos relacionados coa operación no stand.

Esta entrada tamén se pode usar ao configurar o modelo, por exemplo na fase inicial do cálculo. Cando o modelo pasa ao estado necesario, os bloques de verificación están desactivados, pero en canto o sistema chega ao modo de funcionamento necesario, os bloques de verificación están activados.

Os parámetros deste bloque son:

• condicións de contorno: límites de intervalo superior (UpLimit) e inferior (DownLimit) que se deben comprobar;
• tempo de exposición do sistema necesario nos intervalos de límite (TimeInterval) en segundos;
• ID de solicitude ReqName;
• a permisibilidade de exceder o intervalo Out_range é unha variable booleana que determina se un valor que supera o intervalo marcado é unha violación do requisito.

Nalgúns casos, a saída do valor da proba indica que o sistema ten algunha marxe e pode estar operando fóra do seu rango de funcionamento. Noutros casos, unha saída significa que o sistema non pode manter os puntos de referencia dentro do intervalo.

Figura 6. Un bloque de verificación de propiedades típico no diagrama e os seus parámetros.

Como resultado do cálculo deste bloque, na saída fórmase a variable Resultado, que toma os seguintes valores:

• 0 – rNone, valor non definido;
• 1 – rFeito, cumpre o requisito;
• 2 – rFault, non se cumpre o requisito.

A imaxe do bloque contén:

• texto identificador;
• visualizacións dixitais dos parámetros dos límites de medición;
• identificador de cor do estado do parámetro.

Dentro do bloque pode haber un circuíto de inferencia lóxica bastante complexo.

Por exemplo, para comprobar o rango de temperatura de funcionamento da unidade que se mostra na Figura 6, o circuíto interno móstrase na Figura 7.

Figura 7. Diagrama interno da unidade de determinación do intervalo de temperatura.

Dentro do bloque do circuíto, utilízanse as propiedades especificadas nos parámetros do bloque.
Ademais de analizar o cumprimento dos requisitos, o diagrama interno do bloque contén un gráfico necesario para visualizar os resultados da simulación. Este gráfico pódese usar tanto para ver durante o cálculo como para analizar os resultados despois do cálculo.

Os resultados do cálculo transmítense á saída do bloque e grávanse simultaneamente nun ficheiro de informe xeral, que se crea en función dos resultados de todo o proxecto. (ver figura 8)

Un exemplo de informe creado a partir dos resultados da simulación é un ficheiro html creado segundo un formato determinado. O formato pódese configurar arbitrariamente co formato aceptado por unha organización en particular.

Dentro do bloque do circuíto, utilízanse as propiedades especificadas nos parámetros do bloque.
Ademais de analizar o cumprimento dos requisitos, o diagrama interno do bloque contén un gráfico necesario para visualizar os resultados da simulación. Este gráfico pódese usar tanto para ver durante o cálculo como para analizar os resultados despois do cálculo.

Os resultados do cálculo transmítense á saída do bloque e grávanse simultaneamente nun ficheiro de informe xeral, que se crea en función dos resultados de todo o proxecto. (ver figura 8)

Un exemplo de informe creado a partir dos resultados da simulación é un ficheiro html creado segundo un formato determinado. O formato pódese configurar arbitrariamente co formato aceptado por unha organización en particular.

Figura 8. Exemplo dun ficheiro de informe baseado nos resultados da simulación.

Neste exemplo, o formulario de informe configúrase directamente nas propiedades do proxecto e o formato da táboa establécese como sinais globais do proxecto. Neste caso, o propio SimInTech resolve o problema de configurar o informe e o bloque para escribir resultados nun ficheiro utiliza estas liñas para escribir no ficheiro de informe.

Figura 9. Definición do formato de informe en sinais globais do proxecto

Usando unha base de datos de sinais para os requisitos.

Para automatizar o traballo coa configuración das propiedades, créase unha estrutura estándar na base de datos de sinais para cada bloque típico. (ver figura 10)

Figura 10. Exemplo da estrutura dun bloque de verificación de requisitos nunha base de datos de sinais.

A base de datos de sinais ofrece:

• Almacenamento de todos os parámetros necesarios dos requisitos do sistema.
• Visualización cómoda dos requisitos existentes do proxecto a partir de parámetros especificados e dos resultados actuais do modelado.
• Configurar un bloque ou un grupo de bloques mediante unha linguaxe de programación de scripts. Os cambios na base de datos de sinais levan a cambios nos valores das propiedades do bloque no diagrama.
• Almacenamento de descricións de texto, ligazóns a elementos de especificacións técnicas ou identificadores no sistema de xestión de requisitos.

As estruturas de bases de datos de sinais para requisitos pódense configurar facilmente para funcionar cun sistema de xestión de requisitos de terceiros.Na figura 11 preséntase un diagrama xeral de interacción cos sistemas de xestión de requisitos.

Figura 11. Diagrama de interacción co sistema de xestión de requisitos.

A secuencia de interacción entre o proxecto de proba SimInTech e o sistema de control de requisitos é a seguinte:

1. Os termos de referencia están desglosados ​​en requisitos.
2. Identificáronse os requisitos das especificacións técnicas que se poden verificar mediante modelización matemática de procesos técnicos.
3. Os atributos dos requisitos seleccionados transfírense á base de datos de sinais SimInTech na estrutura de bloques estándar (por exemplo, temperatura máxima e mínima).
4. Durante o proceso de cálculo, os datos da estrutura transfírense a diagramas de deseño de bloques, realízase a análise e os resultados gárdanse nunha base de datos de sinais.
5. Unha vez finalizado o cálculo, os resultados da análise transfírense ao sistema de xestión de requisitos.

Os pasos 3 a 5 dos requisitos poden repetirse durante o proceso de deseño cando se producen cambios no deseño e/ou requisitos e hai que volver a probar o impacto dos cambios.

Conclusións.

• O prototipo creado do sistema proporciona unha redución significativa no tempo de análise dos modelos existentes para o cumprimento dos requisitos das especificacións técnicas.
• A tecnoloxía de proba proposta utiliza modelos dinámicos xa existentes e pódese utilizar incluso para calquera modelo dinámico, incluídos os que non se realizan no contorno SimInTech.
• Usar a organización de datos por lotes permítelle crear paquetes de verificación de requisitos en paralelo co desenvolvemento de modelos, ou mesmo utilizar estes paquetes como especificacións técnicas para o desenvolvemento de modelos.
• A tecnoloxía pódese integrar cos sistemas de xestión de requisitos existentes sen custos significativos.

Para os que len ata o final, ligazón a un vídeo que mostra como funciona o prototipo.

Fonte: www.habr.com