Verificação automática dos requisitos do TFD durante a modelagem dinâmica.

Continuando o tema "Quais são suas provas?", vejamos o problema da modelagem matemática sob uma nova perspectiva. Depois de garantirmos que o modelo reflete a dura realidade da vida, podemos responder à pergunta principal: "o que exatamente temos aqui?". Ao criar um modelo de um objeto técnico, geralmente queremos ter a certeza de que esse objeto atenderá às nossas expectativas. Para isso, realizamos cálculos dinâmicos dos processos e comparamos os resultados com os requisitos. Isso é o que chamamos de gêmeo digital, protótipo virtual e outros termos da moda que na fase de projeto resolvem o desafio de garantir que obteremos aquilo que planejamos.

Como podemos rapidamente confirmar que nosso sistema é exatamente aquilo que estamos projetando? Ele irá voar ou flutuar? E se voar, até que altura? E se flutuar, até que profundidade?

Este artigo aborda 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. Vamos examinar um elemento do termo de referência para o sistema de arrefecimento por ar de uma aeronave.

Analisamos os 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 para qualquer sistema técnico, mas é precisamente na verificação deles que gastamos tempo, nervos e dinheiro na criação de modelos dinâmicos do objeto.

Ao descrever os requisitos técnicos em forma de documento, podemos destacar vários tipos de requisitos diferentes, cada um dos quais requer abordagens distintas para a formação da verificação automática do cumprimento dos requisitos.

Por exemplo, consideremos um pequeno, mas real conjunto de requisitos:

1. Temperatura do ar atmosférico na entrada do sistema de arrefecimento por ar:
   em repouso - de menos 35 a 35 ºC,
   em voo - de menos 35 a 39 ºC.
2. Pressão atmosférica estática em voo - de 700 a 1013 hPa (de 526 a 760 mmHg).
3. Pressão total do ar na entrada do coletor de ar do sistema de arrefecimento em voo - de 754 a 1200 hPa (de 566 a 1050 mmHg).
4. Temperatura do ar de arrefecimento:
   em repouso - não mais que 27 ºC, para os blocos técnicos - não mais que 29 ºC,
   no voo − não mais que 25 ºC, para blocos técnicos − não mais que 27 ºC.
5. Consumo de ar de refrigeração:
   em repouso − não menos que 708 kg/h,
   no voo − não menos que 660 kg/h.
6. A temperatura do ar nos compartimentos de instrumentos − não mais que 60 ºC.
7. A quantidade de umidade livre e finamente dispersa no ar de refrigeração − não mais que 2 g/kg de ar seco.

Mesmo nesse conjunto restrito de requisitos, podemos destacar pelo menos duas categorias que precisam ser tratadas de maneira diferente no sistema:

• requisitos das condições de operação do sistema (itens 1-3);
• requisitos paramétricos do sistema (itens 3-7).

Requisitos das condições de operação do sistema
As condições externas para o sistema em desenvolvimento, durante a modelagem, podem ser definidas como condições de contorno ou como resultado da operação do sistema geral.
Na modelagem dinâmica, é necessário garantir que os modos de operação definidos sejam cobertos pelo processo de modelagem.

Requisitos paramétricos do sistema
Esses requisitos representam parâmetros fornecidos pelo próprio sistema. Durante a modelagem, podemos obter esses parâmetros como resultados de cálculos 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 os requisitos, as normas existentes recomendam atribuir um identificador a cada requisito. Ao atribuir identificadores, é altamente desejável usar um sistema de codificação unificado.

O código do requisito pode ser simplesmente um número, refletindo o número sequencial do requisito, ou pode conter um código do tipo de requisito, código do sistema ou agregado ao qual se aplica, código do parâmetro, código de localização e muito mais, que um engenheiro puder imaginar. (opção de uso de codificação veja no artigo)

A tabela 1 apresenta um exemplo simples de codificação de requisitos.

1. código da fonte dos requisitos R- requisitos do TSD;
2. código tipo de requisitos E – requisitos – parâmetros do ambiente externo, ou condições de operação;
   S — requisitos garantidos pelo sistema;
3. código do estado da aeronave 0 – qualquer, G – em repouso, F – no voo;
4. código do tipo de parâmetros físicos T – temperatura, P – pressão, G – consumo, umidade H;
5. número sequencial do requisito.

Projeto do sistema de verificação de requisitos.

Para cada requisito de cálculo, existe um algoritmo para avaliação da conformidade entre os parâmetros calculados e os parâmetros estabelecidos no requisito. No fundo, qualquer sistema de controle contém, por padrão, algoritmos de verificação de requisitos. Mesmo qualquer regulador os contém. Se a temperatura ultrapassar os limites, o ar-condicionado é acionado. Assim, a primeira etapa de qualquer regulação é a verificação da conformidade dos parâmetros com o requisito.

E como a verificação é um algoritmo, podemos utilizar os mesmos meios e ferramentas que usamos para criar programas de controle. Por exemplo, o ambiente SimInTech permite criar pacotes de projetos que contêm várias partes do modelo, realizadas como projetos separados (modelo do objeto, modelo do sistema de controle, modelo do ambiente, etc.).

O projeto de verificação de requisitos torna-se, nesse caso, um projeto algorítmico e se conecta ao pacote do modelo. E, em modo de modelagem dinâmica, realiza a análise de conformidade com os requisitos do termo de referência.

Um exemplo possível de como o projeto do sistema pode ser apresentado é mostrado na Figura 1.

Figura 1. Exemplo de apresentação do projeto de verificação.

Assim como para os algoritmos de controle, os requisitos podem ser apresentados na forma de um conjunto de folhas. Para facilitar o trabalho com algoritmos em ambientes de modelagem estrutural como SimInTech, Simulink e AmeSim, são usadas capacidades de criação de estruturas em múltiplos níveis na forma de submodelos. Essa organização permite agrupar diferentes requisitos em conjuntos para simplificar o trabalho com o conjunto de requisitos, da mesma forma que é feito para algoritmos de controle (veja a Fig. 2).

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

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

Para conectar os dados ao modelo, é usada uma estrutura padrão de formação de banco de dados de sinais, na qual são armazenados dados para troca entre partes do projeto.

Durante a criação e teste de software, esta base armazena leituras de sensores (análogos aos sensores reais do sistema), que são utilizados pelo sistema de controle.
Para o projeto de teste, nesta mesma base de dados podem ser salvos quaisquer parâmetros calculados no modelo dinâmico, e dessa forma utilizados para verificar o cumprimento dos requisitos.

O próprio modelo dinâmico, neste caso, pode ser executado em qualquer sistema de modelagem matemática ou mesmo na forma de um programa executável. A única exigência é que existam interfaces de software para a emissão de dados de modelagem para o ambiente externo.

Figura 3. Conexão do projeto de verificação com o modelo complexo.

Um exemplo de uma folha básica de verificação de requisitos é apresentado na figura 4. Do ponto de vista do desenvolvedor, ela representa um esquema de cálculo comum, 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 maneira análoga aos esquemas de cálculo dos algoritmos de controle. Na parte direita, há um bloco de leitura de sinais do banco de dados. Nesse bloco, ocorre o acesso ao banco de dados de sinais durante a modelagem.

Os sinais recebidos são analisados para calcular as condições de verificação dos requisitos. No caso em questão, é feita uma análise da altitude para determinar a posição da aeronave (se está estacionada ou em voo). Para esse objetivo, podem ser utilizados outros sinais e parâmetros calculados pelo modelo.

As condições de verificação e os parâmetros verificados são enviados para os blocos de verificação padrão, onde a análise desses parâmetros é realizada para verificar a conformidade com os requisitos estabelecidos. Os resultados são registrados em um banco de dados de sinais de forma que possam ser usados para a geração automática de uma lista de verificação.

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

Não é necessário utilizar sinalizações contidas no banco de dados como parâmetros verificados, que são controlados pelos parâmetros calculados durante o processo de modelagem. Nada impede que, dentro do projeto de requisitos, sejam realizados cálculos adicionais, assim como calculamos as condições de verificação.

Por exemplo, tal requisito:

O número de ativações do sistema corretor durante o voo até o destino não deve exceder 5, e o tempo total de operação do sistema corretor não deve ultrapassar 30 segundos.

Nesse caso, um algoritmo contador de ativações e tempo de operação total é adicionado ao esquema de cálculo do projeto de requisitos.

Bloco de verificação de requisitos padrão.

Cada bloco de verificação de requisitos é destinado a calcular a execução de um requisito de um tipo específico. Por exemplo, nos requisitos ambientais, há um intervalo de temperaturas de operação do ar ambiente em solo e em voo. Este bloco deve receber como parâmetro a temperatura do ar no modelo e determinar se esse parâmetro cobre o intervalo de temperaturas definido.

O bloco contém duas portas de entrada, param e condition.

Na primeira é aplicado o parâmetro verificado. Neste caso, "Temperatura do ambiente externo".

Na segunda porta é aplicada uma variável booleana – a condição de execução da verificação.

Se o segundo ingresso receber TRUE (1), o bloco realiza o cálculo da verificação do requisito.

Se a segunda entrada recebe FALSE (0), as condições de verificação não são atendidas. Isso é necessário para levar em conta as condições de cálculo. No nosso caso, essa entrada é usada para ativar ou desativar a verificação dependendo do estado do modelo. Se a aeronave durante a modelagem estiver no solo, os requisitos relacionados ao voo não são verificados e vice-versa – se a aeronave estiver em voo, os requisitos relacionados à operação em estacionamento não são verificados.

Essa entrada também pode ser utilizada ao configurar o modelo, por exemplo, na fase inicial do cálculo. Quando o modelo é ajustado ao estado desejado, os blocos de verificação estão desligados, mas assim que o sistema atinge o modo de operação requerido, os blocos de verificação são ativados.

Os parâmetros deste bloco são:

• condições limites: limite superior (UpLimit) e limite inferior (DownLimit) das faixas a serem verificadas;
• tempo de espera requerido do sistema nas faixas limites (TimeInterval) em segundos;
• identificador do requisito ReqName;
• permitibilidade de ultrapassar o limite Out_range – uma variável booleana que define se a saída de um valor fora da faixa verificada é uma violação.

Em alguns casos, a saída do valor verificado significa que o sistema tem margem e pode operar além da faixa de operação. Em outros casos, a saída significa que o sistema não é capaz de manter os parâmetros definidos dentro da faixa.

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

Como resultado do cálculo deste bloco, é gerada a variável Result, que assume os seguintes valores:

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

A imagem do bloco contém:

• texto do identificador;
• displays numéricos dos parâmetros dos limites de medição;
• identificador de cor do estado do parâmetro.

Dentro do bloco pode haver um esquema lógico de saída bastante complexo.

Por exemplo, para verificar a faixa de temperatura de trabalho do bloco mostrado na Figura 6, o esquema interno é apresentado na Figura 7.

Figura 7. Esquema interno do bloco de determinação da faixa de temperaturas.

Dentro do bloco, o esquema utiliza propriedades definidas nos parâmetros do bloco.
Além da análise da conformidade dos requisitos, o esquema interno do bloco contém um gráfico necessário para a apresentaçã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 enviados 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. (veja a Fig. 8)

Um exemplo de relatório gerado com base nos resultados da simulação é um arquivo HTML, criado de acordo com um formato especificado. O formato pode ser ajustado de forma arbitrária para o formato aceito por uma organização específica.

Dentro do bloco, o esquema utiliza propriedades definidas nos parâmetros do bloco.
Além da análise da conformidade dos requisitos, o esquema interno do bloco contém um gráfico necessário para a apresentaçã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 enviados 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. (veja a Fig. 8)

Um exemplo de relatório gerado com base nos resultados da simulação é um arquivo HTML, criado de acordo com um formato especificado. O formato pode ser ajustado de forma arbitrária para o formato aceito por uma organização específica.

Fig. 8. Exemplo de arquivo de relatório com os resultados da simulação.

Neste exemplo, a configuração do formato do relatório é realizada diretamente nas propriedades do projeto, enquanto o formato na tabela é definido como sinais globais do projeto. Neste caso, o SimInTech resolve automaticamente a configuração do relatório, e o bloco de gravação dos resultados no arquivo utiliza essas linhas para registrar no arquivo de relatório.

Fig. 9. Configuração do formato do relatório nos sinais globais do projeto.

Uso de banco de dados de sinais para requisitos.

Para automatizar o trabalho com as configurações de propriedades de cada bloco padrão, uma estrutura típica é criada em um banco de dados de sinais. (veja a Fig. 10)

Fig. 10. Exemplo de estrutura do bloco de verificação de requisitos no banco de dados de sinais.

O banco de dados de sinais proporciona:

• Armazenamento de todos os parâmetros necessários dos requisitos do sistema.
• Visualização fácil dos requisitos existentes no projeto a partir dos parâmetros especificados e dos resultados atuais da simulação.
• Configuração de um bloco, ou grupo de blocos, usando uma linguagem de programação de script. As alterações no banco de dados de sinais levam a mudanças nos valores das propriedades do bloco no esquema.
• Armazenamento de descrições textuais, links para itens do documento de especificação de requisitos ou identificadores no sistema de gestão de requisitos.

As estruturas do banco de dados de sinais para requisitos podem ser facilmente configuradas para trabalhar com um sistema externo de gestão de requisitos. O esquema geral de interação com os sistemas de gestão de requisitos está apresentado na Fig. 11.

Fig. 11. Esquema de interação com o sistema de gestão de requisitos.

A sequência de interação do projeto de teste SimInTech com o sistema de gerenciamento de requisitos é a seguinte:

1. O documento técnico é dividido em requisitos.
2. Os requisitos do documento técnico que podem ser verificados por meio da modelagem matemática de processos técnicos são destacados.
3. Os atributos dos requisitos destacados são enviados para o banco de dados de sinais do SimInTech nas estruturas de blocos típicos (por exemplo, temperatura máxima e mínima).
4. Durante o cálculo, os dados da estrutura são enviados para os esquemas de cálculo dos blocos, uma análise é realizada e os resultados são salvos no banco de dados de sinais.
5. Após a conclusão do cálculo, os resultados da análise são transferidos para o sistema de gerenciamento de requisitos.

As etapas de trabalho com requisitos 3 a 5 podem ser repetidas durante o processo de design, quando ocorrem mudanças na construção e/ou nos requisitos e, consequentemente, uma nova verificação do impacto das alterações feitas é necessária.

Conclusões.

• O protótipo do sistema criado proporciona uma redução significativa no tempo de análise dos modelos existentes em relação à conformidade com os requisitos do documento técnico.
• A tecnologia de teste proposta utiliza modelos dinâmicos já existentes e pode ser usada até mesmo para quaisquer modelos dinâmicos, incluindo aqueles realizados fora do ambiente SimInTech.
• O uso da organização de dados em pacotes permite a criação de pacotes de verificação de requisitos, paralelamente ao desenvolvimento de modelos, ou mesmo o uso desses pacotes como documento técnico para o desenvolvimento de modelos.
• A tecnologia pode ser integrada com sistemas de gerenciamento de requisitos existentes sem custos significativos.

Para aqueles que chegaram até aqui, link para o vídeo com a demonstração do funcionamento do protótipo.

Fonte: habr.com