Verificação automática dos requisitos de especificações técnicas durante a modelagem dinâmica

Continuando o tema "Qual é a sua evidência?", vamos examinar o problema da modelagem matemática do outro lado. Depois de estarmos convencidos de que o modelo corresponde à verdade caseira da vida, podemos responder à questão principal: “o que, exatamente, temos aqui?” Ao criar um modelo de um objeto técnico, geralmente queremos ter certeza de que esse objeto atenderá às nossas expectativas. Para tanto, são realizados cálculos dinâmicos dos processos e o resultado é comparado com os requisitos. Este é um gêmeo digital, um protótipo virtual, etc. garotinhos da moda que, na fase de design, resolvem o problema de como garantir que conseguiremos o que planejamos.

Como podemos garantir rapidamente que nosso sistema é exatamente o que projetamos, nosso projeto voará ou flutuará? E se voar, quão alto? E se flutuar, qual a profundidade?

Este artigo discute a automação da verificação do cumprimento dos requisitos de um edifício técnico na criação de modelos dinâmicos de sistemas técnicos. Como exemplo, vejamos um elemento da especificação técnica de um sistema de refrigeração de ar de aeronave.

Consideramos aqueles requisitos que podem ser expressos numericamente e verificados matematicamente com base em um modelo de cálculo específico. É claro que isso é apenas parte dos requisitos gerais de qualquer sistema técnico, mas é verificando-os que gastamos tempo, nervosismo e dinheiro na criação de modelos dinâmicos do objeto.

Ao descrever requisitos técnicos na forma de um documento, vários tipos de requisitos diferentes podem ser distinguidos, cada um dos quais requer abordagens diferentes para a formação de verificação automática do cumprimento dos requisitos.

Por exemplo, considere este pequeno mas realista conjunto de requisitos:

1. Temperatura do ar atmosférico na entrada do sistema de tratamento de água:
   no estacionamento - de menos 35 a 35 ºС,
   em voo - de menos 35 a 39 ºС.
2. A pressão estática do ar atmosférico em vôo é de 700 a 1013 GPa (de 526 a 760 mm Hg).
3. A pressão total do ar na entrada da entrada de ar do SVO em vôo é de 754 a 1200 GPa (de 566 a 1050 mm Hg).
4. Temperatura do ar de resfriamento:
   no estacionamento - não mais que 27 ºС, para blocos técnicos - não mais que 29 ºС,
   em vôo - não mais que 25 ºС, para blocos técnicos - não mais que 27 ºС.
5. Fluxo de ar de resfriamento:
   quando estacionado - pelo menos 708 kg/h,
   em vôo - não inferior a 660 kg/h.
6. A temperatura do ar nos compartimentos dos instrumentos não é superior a 60 ºС.
7. A quantidade de umidade fina livre no ar de resfriamento não é superior a 2 g/kg de ar seco.

Mesmo dentro deste conjunto limitado de requisitos, existem pelo menos duas categorias que precisam ser tratadas de forma diferente no sistema:

• requisitos para condições operacionais do sistema (cláusulas 1-3);
• requisitos paramétricos para o sistema (cláusulas 3-7).

Requisitos de condições operacionais do sistema
As condições externas para o sistema que está sendo desenvolvido durante a modelagem podem ser especificadas como condições de contorno ou como resultado da operação do sistema geral.
Na simulação dinâmica, é necessário garantir que as condições operacionais especificadas sejam cobertas pelo processo de simulação.

Requisitos do sistema paramétrico
Esses requisitos são parâmetros fornecidos pelo próprio sistema. Durante o processo de modelagem, podemos obter esses parâmetros como resultados de cálculo e garantir que os requisitos sejam atendidos em cada cálculo específico.

Identificação e codificação de requisitos

Para facilitar o trabalho com requisitos, os padrões existentes recomendam atribuir um identificador a cada requisito. Ao atribuir identificadores, é altamente desejável usar um sistema de codificação unificado.

Um código de requisito pode ser simplesmente um número que representa o número de pedido do requisito ou pode conter um código para o tipo de requisito, um código para o sistema ou unidade ao qual se aplica, um código de parâmetro, um código de localização e qualquer outra coisa que um engenheiro possa imaginar. (veja o artigo para o uso de codificação)

A Tabela 1 fornece um exemplo simples de codificação de requisitos.

1. código da fonte dos requisitos R-requisitos TK;
2. tipo de código de requisitos E - requisitos - parâmetros ambientais ou condições operacionais
   S – requisitos fornecidos pelo sistema;
3. código de status da aeronave 0 – qualquer, G – estacionada, F – em voo;
4. código de tipo de parâmetro físico T – temperatura, P – pressão, G – vazão, umidade H;
5. número de série do requisito.

ID Requisitos	descrição	Parâmetro
REGT01	Temperatura do ar ambiente na entrada do sistema de refrigeração de água: no estacionamento - de menos 35ºС. até 35ºС.
REFT01	Temperatura atmosférica do ar na entrada do sistema de defesa aérea: em voo - de menos 35 ºС a 39 ºС.
REFP01	A pressão atmosférica estática do ar em vôo é de 700 a 1013 hPa (de 526 a 760 mm Hg).
REFP02	A pressão total do ar na entrada da entrada de ar do SVO em vôo é de 754 a 1200 hPa (de 566 a 1050 mm Hg).
RSGT01	Temperatura do ar de resfriamento: quando estacionado não superior a 27 ºС
RSGT02	Temperatura do ar de refrigeração: no estacionamento, para unidades técnicas não superior a 29 ºС
RSFT01	Temperatura do ar de resfriamento em voo não superior a 25 ºС
RSFT02	Temperatura do ar de resfriamento: em voo, para unidades técnicas não superior a 27 ºС
RSGG01	Fluxo de ar de refrigeração: quando estacionado não inferior a 708 kg/h
RSFG01	Fluxo de ar de resfriamento: em voo não inferior a 660 kg/h
RS0T01	Temperatura do ar nos compartimentos de instrumentos não superior a 60 ºС
RSH01	A quantidade de umidade fina livre no ar de resfriamento não é superior a 2 g/kg de ar seco

Projeto de sistema de verificação de requisitos.

Para cada requisito de projeto existe um algoritmo para avaliar a correspondência dos parâmetros de projeto e os parâmetros especificados no requisito. Em geral, qualquer sistema de controle sempre contém algoritmos para verificar requisitos simplesmente por padrão. E mesmo qualquer regulador os contém. Se a temperatura ultrapassar os limites, o ar condicionado liga. Assim, a primeira etapa de qualquer regulamentação é verificar se os parâmetros atendem aos requisitos.

E como a verificação é um algoritmo, podemos usar as mesmas ferramentas e ferramentas que usamos para criar programas de controle. Por exemplo, o ambiente SimInTech permite criar pacotes de projetos contendo várias partes do modelo, executados na forma de projetos separados (modelo de objeto, modelo de sistema de controle, modelo de ambiente, etc.).

O projeto de verificação de requisitos, neste caso, torna-se o mesmo projeto de algoritmo e está conectado ao pacote de modelo. E no modo de modelagem dinâmica realiza uma análise para atendimento aos requisitos das especificações técnicas.

Um possível exemplo de projeto de sistema é mostrado na Figura 1.

Figura 1. Exemplo de desenho de um projeto de verificação.

Assim como acontece com algoritmos de controle, os requisitos podem ser elaborados como um conjunto de planilhas. Para a conveniência de trabalhar com algoritmos em ambientes de modelagem estrutural como SimInTech, Simulink, AmeSim, é utilizada a capacidade de criar estruturas multiníveis na forma de submodelos. Esta organização permite agrupar vários requisitos em conjuntos para simplificar o trabalho com uma variedade de requisitos, como é feito para algoritmos de controle (ver Fig. 2).

Figura 2. Estrutura hierárquica do modelo de verificação de requisitos.

Por exemplo, no caso em consideração, distinguem-se dois grupos: requisitos para o ambiente e requisitos diretamente para o sistema. Portanto, é utilizada uma estrutura de dados de dois níveis: dois grupos, cada um dos quais é uma folha do algoritmo.

Para conectar os dados ao modelo, é utilizado um esquema padrão para gerar um banco de dados de sinais, que armazena dados para troca entre partes do projeto.

Ao criar e testar software, as leituras dos sensores (análogos dos sensores do sistema real) que são utilizados pelo sistema de controle são colocadas neste banco de dados.
Para um projeto de teste, quaisquer parâmetros calculados no modelo dinâmico podem ser armazenados no mesmo banco de dados e assim utilizados para verificar se os requisitos foram atendidos.

Neste caso, o próprio modelo dinâmico pode ser executado em qualquer sistema de modelagem matemática ou mesmo na forma de um programa executável. O único requisito é a presença de interfaces de software para emissão de dados de modelagem para o ambiente externo.

Figura 3. Conectando o projeto de verificação ao modelo complexo.

Um exemplo de planilha de verificação de requisitos básicos é apresentado na Figura 4. Do ponto de vista do desenvolvedor, é um diagrama de cálculo convencional no qual o algoritmo de verificação de requisitos é apresentado graficamente.

Figura 4. Folha de verificação de requisitos.

As principais partes da folha de verificação estão descritas na Figura 5. O algoritmo de verificação é formado de forma semelhante aos diagramas de projeto dos algoritmos de controle. No lado direito existe um bloco para leitura de sinais do banco de dados. Este bloco acessa o banco de dados de sinais durante a simulação.

Os sinais recebidos são analisados ​​para calcular as condições de verificação dos requisitos. Neste caso, é realizada uma análise de altitude para determinar a posição da aeronave (se estacionada ou em voo). Para isso, você pode utilizar outros sinais e parâmetros calculados do modelo.

As condições de verificação e os parâmetros verificados são transferidos para blocos de verificação padrão, nos quais esses parâmetros são analisados ​​quanto à conformidade com os requisitos especificados. Os resultados são registrados no banco de dados de sinais de forma que possam ser usados ​​para gerar automaticamente uma lista de verificação.

Figura 5. Estrutura da planilha de cálculo de verificação de requisitos.

Os parâmetros a serem testados não utilizam necessariamente sinais contidos no banco de dados, os quais são controlados por parâmetros calculados durante o processo de simulação. Nada nos impede de realizar cálculos adicionais no âmbito dos projetos de requisitos, tal como calculamos as condições de verificação.

Por exemplo, este requisito:

O número de ativações do sistema de correção durante o vôo até o alvo não deve ultrapassar 5, e o tempo total de operação do sistema de correção não deve ultrapassar 30 segundos.

Neste caso, um algoritmo para contabilizar o número de partidas e o tempo total de operação é adicionado ao diagrama de projeto dos requisitos.

Bloco típico de verificação de requisitos.

Cada caixa de seleção de requisito padrão é projetada para calcular o atendimento de um requisito de um determinado tipo. Por exemplo, os requisitos ambientais incluem uma gama de temperaturas ambientes de funcionamento quando estacionado e em voo. Este bloco deve receber como parâmetro a temperatura do ar no modelo e determinar se este parâmetro cobre a faixa de temperatura especificada./p>

O bloco contém duas portas de entrada, parâmetro e condição.

O primeiro é alimentado com o parâmetro que está sendo verificado. Neste caso, “Temperatura externa”.

Uma variável booleana é fornecida à segunda porta - a condição para realizar a verificação.

Se TRUE (1) for recebido na segunda entrada, então o bloco realiza um cálculo de verificação de requisitos.

Se a segunda entrada receber FALSO (0), as condições de teste não serão atendidas. Isto é necessário para que as condições de cálculo possam ser levadas em consideração. No nosso caso, esta entrada é utilizada para habilitar ou desabilitar a verificação dependendo do estado do modelo. Se a aeronave estiver no solo durante a simulação, os requisitos relativos ao voo não serão verificados, e vice-versa - se a aeronave estiver em voo, os requisitos relativos à operação no stand não serão verificados.

Esta entrada também pode ser utilizada na configuração do modelo, por exemplo, na fase inicial do cálculo. Quando o modelo é colocado no estado necessário, os blocos de verificação são desabilitados, mas assim que o sistema atinge o modo operacional necessário, os blocos de verificação são ativados.

Os parâmetros deste bloco são:

• condições de contorno: limites superior (UpLimit) e inferior (DownLimit) do intervalo que devem ser verificados;
• tempo necessário de exposição do sistema nas faixas limite (TimeInterval) em segundos;
• ID da solicitação NomeReq;
• permissibilidade de exceder o intervalo Out_range é uma variável booleana que determina se um valor que excede o intervalo verificado é uma violação do requisito.

Em alguns casos, a saída do valor de teste indica que o sistema tem alguma margem e pode estar operando fora da faixa operacional. Em outros casos, uma saída significa que o sistema não consegue manter os pontos de ajuste dentro da faixa.

Figura 6. Um bloco típico de verificação de propriedade no diagrama e seus parâmetros.

Como resultado do cálculo deste bloco, a variável Resultado é formada na saída, que assume os seguintes valores:

• 0 – rNone, valor não definido;
• 1 – rDone, o requisito foi atendido;
• 2 – rFault, o requisito não foi atendido.

A imagem do bloco contém:

• texto identificador;
• exibições digitais de parâmetros de limites de medição;
• identificador de cor do status do parâmetro.

Dentro do bloco pode haver um circuito de inferência lógica bastante complexo.

Por exemplo, para verificar a faixa de temperatura operacional da unidade mostrada na Figura 6, o circuito interno é mostrado na Figura 7.

Figura 7. Diagrama interno da unidade de determinação da faixa de temperatura.

Dentro do bloco de circuito, são utilizadas as propriedades especificadas nos parâmetros do bloco.
Além de analisar o atendimento aos requisitos, o diagrama interno do bloco contém um gráfico necessário para visualização dos resultados da simulação. Este gráfico pode ser usado tanto para visualização durante o cálculo quanto para análise dos resultados após o cálculo.

Os resultados do cálculo são transmitidos para a saída do bloco e simultaneamente registrados em um arquivo de relatório geral, que é criado com base nos resultados de todo o projeto. (ver Fig. 8)

Um exemplo de relatório criado com base nos resultados da simulação é um arquivo html criado de acordo com um determinado formato. O formato pode ser configurado arbitrariamente para o formato aceito por uma organização específica.

Dentro do bloco de circuito, são utilizadas as propriedades especificadas nos parâmetros do bloco.
Além de analisar o atendimento aos requisitos, o diagrama interno do bloco contém um gráfico necessário para visualização dos resultados da simulação. Este gráfico pode ser usado tanto para visualização durante o cálculo quanto para análise dos resultados após o cálculo.

Os resultados do cálculo são transmitidos para a saída do bloco e simultaneamente registrados em um arquivo de relatório geral, que é criado com base nos resultados de todo o projeto. (ver Fig. 8)

Um exemplo de relatório criado com base nos resultados da simulação é um arquivo html criado de acordo com um determinado formato. O formato pode ser configurado arbitrariamente para o formato aceito por uma organização específica.

Figura 8. Exemplo de arquivo de relatório baseado em resultados de simulação.

Neste exemplo, o formulário do relatório é configurado diretamente nas propriedades do projeto e o formato na tabela é definido como sinais globais do projeto. Nesse caso, o próprio SimInTech resolve o problema de configuração do relatório, e o bloco de gravação de resultados em um arquivo utiliza essas linhas para gravar no arquivo de relatório.

Figura 9. Configurando o formato do relatório nos sinais globais do projeto

Usando um banco de dados de sinais para requisitos.

Para automatizar o trabalho com configurações de propriedades, uma estrutura padrão é criada no banco de dados de sinais para cada bloco típico. (ver Fig. 10)

Figura 10. Exemplo de estrutura de um bloco de verificação de requisitos em um banco de dados de sinais.

O banco de dados de sinais fornece:

• Armazenando todos os parâmetros necessários de requisitos do sistema.
• Visualização conveniente dos requisitos de projeto existentes a partir de parâmetros especificados e resultados de modelagem atuais.
• Configurando um bloco ou grupo de blocos usando uma linguagem de programação de script. Alterações no banco de dados de sinais levam a alterações nos valores das propriedades do bloco no diagrama.
• Armazenar descrições de texto, links para itens de especificações técnicas ou identificadores no sistema de gerenciamento de requisitos.

As estruturas de banco de dados de sinais para requisitos podem ser facilmente configuradas para funcionar com um sistema de gerenciamento de requisitos de terceiros. Um diagrama geral de interação com sistemas de gerenciamento de requisitos é apresentado na Figura 11.

Figura 11. Diagrama de interação com o sistema de gerenciamento de requisitos.

A sequência de interação entre o projeto de teste SimInTech e o sistema de controle de requisitos é a seguinte:

1. Os termos de referência são divididos em requisitos.
2. São identificados os requisitos das especificações técnicas que podem ser verificados por modelagem matemática de processos técnicos.
3. Os atributos dos requisitos selecionados são transferidos para o banco de dados de sinais SimInTech na estrutura de blocos padrão (por exemplo, temperatura máxima e mínima).
4. Durante o processo de cálculo, os dados da estrutura são transferidos para diagramas de projeto de blocos, a análise é realizada e os resultados são armazenados em um banco de dados de sinais.
5. Assim que o cálculo for concluído, os resultados da análise são transferidos para o sistema de gerenciamento de requisitos.

As etapas de requisitos 3 a 5 podem ser repetidas durante o processo de design quando ocorrem alterações no design e/ou nos requisitos e o impacto das mudanças precisa ser testado novamente.

Conclusões.

• O protótipo criado do sistema proporciona uma redução significativa no tempo de análise dos modelos existentes para atendimento aos requisitos das especificações técnicas.
• A tecnologia de teste proposta utiliza modelos dinâmicos já existentes e pode ser utilizada até mesmo para quaisquer modelos dinâmicos, incluindo aqueles não realizados no ambiente SimInTech.
• O uso da organização de dados em lote permite criar pacotes de verificação de requisitos paralelamente ao desenvolvimento do modelo ou até mesmo usar esses pacotes como especificações técnicas para o desenvolvimento do modelo.
• A tecnologia pode ser integrada aos sistemas de gerenciamento de requisitos existentes sem custos significativos.

Para quem leu até o fim, link para um vídeo mostrando como o protótipo funciona.

Fonte: habr.com