Continuando o tópico de OOP em linguagens de programação gráfica, examinaremos mais detalhadamente o design baseado em modelo. O que é design orientado a modelo (MOS), como cozinhá-lo e com o que comer.

Ao descrever um projeto orientado a modelos de sistemas de controle, alguns autores em suas publicações transmitem a idéia de que a palavra "modelo" significa "modelo de um sistema de controle". O que não está certo.

Por que isso não é verdade, como fazê-lo corretamente e onde Chernobyl, continue lendo.

Aqui está um exemplo típico - uma imagem de um artigo de autores respeitados sobre “melhores práticas no desenvolvimento de software usando design orientado a modelo”:

Figura 1. Uma das opções para o MOS.

Pessoalmente, olhando para essa foto, surge imediatamente uma pergunta indecente, e de qual lugar, peço desculpas, você tinha vetores de teste?

Ou, por exemplo, uma imagem da recomendação de um processo típico de desenvolvimento de software:

Figura 2. Outra versão do processo MOS.

Onde está o modelo nesta foto? Aqui está esta caixa na qual o código fonte é obtido? Sério ?! Portanto, este é novamente um modelo de software de controle.

Especialmente interessante nesta imagem é a presença de requisitos iniciais de software.
Como você, por exemplo, é um requisito tão comum, quase manual, para um sistema de controle:

“ Quando a pressão subir acima do valor limite, o tempo de fechamento (abertura) da válvula de segurança não deve exceder 5 segundos .”

E como você solicita sob esse esquema para verificar quantos segundos após a pressão ter sido excedida, a válvula de segurança será aberta? Aparentemente, algo está faltando aqui. Nós nos voltamos para a fonte inesgotável da verdade em último recurso - Wikipedia:

O design baseado em modelo fornece uma abordagem eficiente para o estabelecimento de uma estrutura comum de comunicação durante todo o processo de design, enquanto suporta o ciclo de desenvolvimento (modelo V). No design de sistemas de controle baseado em modelo, o desenvolvimento se manifesta nestas quatro etapas:

1. modelar uma planta,
2. analisar e sintetizar um controlador para a planta,
3. simulação da planta e controlador,
4. integrar todas essas fases implementando o controlador.

O desenvolvimento de um modelo de um objeto é o primeiro ponto na determinação do MOS. Primeiro, um modelo do objeto e depois controle para ele. E isso está correto: não há modelo de objeto, "obrigado a todos - todos são livres" e esse não é um design orientado a modelo, mas uma fraude completa do consumidor.

Por que isso é importante e de onde vem Chernobyl?

Em Chernobyl, exatamente o que aconteceu na ausência de um modelo de objeto aconteceu. Os cientistas soviéticos fizeram a pergunta: “O que acontecerá se a fonte de alimentação for desconectada e as bombas de resfriamento do reator receberem corrente de um gerador funcionando em uma turbina em esgotamento? "Quanta água as bombas bombearão através do reator antes que a turbina e o gerador parem?" Curiosamente, eles fizeram essa pergunta com base na experiência do acidente na usina nuclear americana, onde o suprimento de água não era suficiente para o resfriamento e o reator americano derreteu. E para ter certeza de que nossos reatores não estão derretendo, decidimos realizar um experimento. Talvez a resposta a essa pergunta torne a próxima geração de reatores RBMK ainda mais segura. Queríamos o melhor, mas acabou como sempre. Como resultado do experimento, um reator seguro foi primeiro levado a um estado perigoso e depois explodido. E a próxima geração de reatores RBMK não é mais e não é esperada. Amém.

E se, em vez de experimentar um reator, seria possível fazer a mesma coisa no modelo matemático de um objeto, então, muito possivelmente, construiríamos o RBMK-2400 em todo o mundo, em vez dos reatores VVER-1200.

Após o acidente de Chernobyl na indústria nuclear, um modelo de objeto (reator nuclear) é uma parte obrigatória do projeto. O designer deve mostrar no modelo o que acontecerá se algo der errado. E, portanto, o design orientado a modelo apareceu entre os engenheiros nucleares muito mais cedo do que em outros setores, devido aos requisitos dos órgãos reguladores.

Porém, mesmo quando não há requisitos das autoridades reguladoras, o modelo do objeto facilita muito o design do sistema de controle e do próprio objeto. Agora, mostramos isso com um exemplo de uma indústria em que "sonhos se tornam realidade".

A abordagem correta orientada ao modelo.

Como exemplo do MOS correto e kosher, consideramos o processo de desenvolvimento de software de controle para o sistema de controle hidráulico de um complexo de mineração subaquática (como sempre, foi absolutamente por acidente que eu consegui esse modelo no meu computador).

O controle dos principais fluxos do gás produzido pelo suprimento é realizado por acessórios hidráulicos subaquáticos. Na costa, existe uma estação de bombeamento, que fornece pressão no sistema hidráulico, o óleo é fornecido através de umbilical sob pressão debaixo d'água. A abertura e fechamento de válvulas é realizada por atuadores hidráulicos, que são controlados por um sistema de controle distribuído. O sistema consiste em:

• módulo de controle de solo para todo o campo;
• um conjunto de módulos de controle subaquático (PMU) que fornece controle direto de válvulas.

Para a conveniência da instalação e manutenção, as tubulações são combinadas em coletores, onde as válvulas e os módulos de controle necessários são instalados em uma plataforma. Se na estação terrestre você pode usar ferramentas SCADA padrão, servidores de arquivamento e CLPs com sistemas operacionais convencionais e (ou) em tempo real, o módulo de controle subaquático é, via de regra, um microprocessador não operacional, cujo código de controle deve ser desenvolvido separadamente do software de controle costeiro . (Sem C ++, apenas C, apenas código fixo). Em seguida, várias dessas PMUs devem ser integradas ao sistema comum e testadas. E, ao mesmo tempo, todo o sistema deve funcionar como um todo e prever a abertura e o fechamento de válvulas dentro de 30 anos sob a água.

A tarefa é complicada pelo fato de que até agora todo o equipamento usado na prateleira era ocidental, e a prateleira agora está sob sanções. E, portanto, é necessário criar um complexo no qual muitas soluções técnicas sejam novas e não tratadas para nós. Como obter o resultado, reduzindo erros de design, se possível? Bom para desenvolvedores ocidentais: eles já têm experiência, conhecem as armadilhas da mineração subaquática. E aqui o design orientado a modelo ajuda os desenvolvedores. Em vez de realizar experimentos com equipamentos caros, como os cientistas nucleares soviéticos em Chernobyl, criamos um modelo do objeto e realizamos experimentos no modelo.

Modelo integrado do sistema de controle subaquático

Para o design do software, um modelo integrado é criado na forma de um pacote que contém os dois modelos de fluxo de fluido hidráulico embaixo d'água com acessórios e projetos de sistemas de controle. (ver fig. 3)

Figura 3. Um pacote de um modelo integrado do sistema de gerenciamento SPD.

Este pacote contém um projeto - um modelo de uma estação hidráulica no solo (arquivo 200.prt na Fig. 3), que fornece modelagem dos processos dinâmicos dos equipamentos do sistema de fornecimento de fluido hidráulico no solo para água. (ver fig. 4)

Figura 4. O esquema de design da estação hidráulica terrestre.

Simultaneamente ao modelo de processos físicos, está sendo desenvolvido um projeto de sistema de controle que permite ligar e desligar o equipamento e controlar os modos de operação desse equipamento. A Figura 5 mostra os algoritmos de controle de esboço para o módulo de controle de solo.

Figura 5. Projeto de um sistema de controle de módulo de aterramento.

Nesta fase, é possível dividir o desenvolvimento de algoritmos de controle entre diferentes equipes. Por exemplo, para desenvolvedores de uma estação hidráulica terrestre, os custos dos módulos submarinos e a pressão neles são condições de contorno. Para desenvolvedores de equipamentos subaquáticos, a condição de contorno é a pressão criada pela estação de bombeamento em terra.

O desenvolvimento de módulos de controle subaquático (PMUs) é realizado com base no projeto de divisão das principais redes de gás entre os coletores. Primeiro, os poços são formados, a tubulação e os encaixes entre os poços e a costa são determinados e, em seguida, é desenvolvido um sistema de controle hidráulico para essas válvulas.

Para cada módulo subaquático, são formados um modelo de projeto do sistema de controle e um modelo de projeto do sistema hidráulico do coletor com válvulas instaladas. No esquema de projeto do sistema hidráulico, são instaladas válvulas, que são controladas a partir deste módulo subaquático. Esse projeto pode ser realizado em paralelo com o desenvolvimento do módulo de controle de solo, enquanto o desenvolvimento pode ser realizado de forma independente e em paralelo. Para desenvolver os algoritmos da PMU e a operação da válvula, o sistema externo é definido por comandos de controle e condições de contorno do sistema hidráulico.

Considere o módulo de controle subaquático (PMU) 502. Dois projetos são usados ​​aqui:

• 502.prt - modelo de sistemas hidráulicos (Fig. 6, 7);
• 502a.prt - o projeto do sistema de controle da PMU (Fig. 8).

Figura 6. O circuito hidráulico da PMU.

Esse esquema de projeto fornece uma simulação do comportamento do sistema de controle hidráulico e cálculo de taxas de fluxo e pressões em um sistema controlado por 502 PMU. O circuito hidráulico calculado permite definir o impacto nos atuadores e obter dados do sensor calculados no modelo de processos físicos. Desde que não tenhamos uma estação terrestre no bloco 502 P (canto inferior esquerdo da Fig. 6), podemos definir a pressão criada pela estação hidrelétrica como uma condição de contorno.

No sistema, a figura mostra 6 válvulas de fechamento e controle hidráulicas (ZRA), cada uma das quais representa inerentemente um cilindro hidráulico conectado a duas linhas de alta e baixa pressão. Aplicamos mais pressão na parte superior do cilindro, a pressão move a haste para baixo, aplicamos mais pressão na parte inferior do cilindro, a haste sobe.

A comutação é controlada por válvulas de controle localizadas dentro do bloco branco (veja a Fig. 7).

Figura 7. Bloco de válvula de distribuição no modelo.

O princípio de operação é simples: dependendo da posição da válvula deslizante, as câmaras do cilindro serão conectadas a diferentes linhas. Movido o carretel - mudou a direção do movimento da haste no cilindro. (mais detalhes sobre modelagem hidráulica podem ser encontrados aqui ... )

Figura 8. O design do sistema de controle da PMU.

O software de gerenciamento de projetos para o módulo de controle subaquático contém vários blocos de cálculo, cada um dos quais pode ser desenvolvido por um desenvolvedor ou equipe separado. Nesse caso, a separação em módulos ocorre de acordo com um atributo funcional; cada bloco é responsável por controlar um certo tipo de válvula. A metodologia de programação orientada a objetos é aplicada, onde o bloco é a classe OOP (mais detalhes aqui ... e aqui ... )

Considere o processo de projetar uma unidade de controle para equipamentos de desligamento e controle. Este bloco no circuito recebe 4 sinais de entrada e gera 8 sinais de saída. (ver fig. 9)

Figura 9. Unidade de controle ZRA (Tipo 1).

O diagrama de blocos interno consiste em duas folhas de algoritmos. A primeira folha é mostrada na Figura 10a, a segunda na Figura 10b.

Figura 10a. O esquema de design da unidade de controle de válvulas. Folha 1.

Figura 10b. O esquema de design da unidade de controle de válvulas. Folha 2.

Ao desenvolver esta unidade, os seguintes tipos de sinais são usados:

• sinais recebidos através de linhas de comunicação (blocos azuis);
• parâmetros e sinais recebidos do banco de dados de sinais (blocos amarelos pálidos);
• sinais transmitidos ao banco de dados de sinais (blocos azuis pálidos);
• sinais transmitidos para a memória (blocos amarelos brilhantes);
• sinais recebidos da memória (blocos verdes brilhantes).

O diagrama de projeto da unidade de controle de válvulas é vetorial. Isso significa que nem um único sinal de controle é transmitido em cada linha, mas um vetor de sinais, cuja dimensão corresponde à quantidade de equipamentos desse tipo instalados no PMP. Para a comunicação entre a unidade de cálculo e os sinais, parâmetros e comandos para um equipamento específico, são utilizadas unidades de interface.

Assim, tendo desenvolvido e testado um circuito de controle de um elemento típico, tantas unidades de interface podem ser colocadas no circuito quanto o equipamento desse tipo estiver conectado ao módulo de controle subaquático. Nesse caso, na PMU, existem duas unidades de interface para válvulas de corte e controle tipo 1 (veja a Fig. 8).

Todos os sinais e parâmetros variáveis ​​necessários para a unidade de controle são colocados na categoria correspondente da base do sinal ZRAT1 . Parte da categoria é mostrada na Figura 11.

A separação de uma categoria separada permite formar a separação do desenvolvimento de módulos de software de controle em partes e definir claramente a interface de interação entre as várias partes do programa. Assim, o desenvolvimento do módulo de controle prossegue isoladamente ao longo das interfaces de outros módulos no software.

Figura 11. Grupo de sinais para a unidade de controle ZRAT1

Sistema de codificação do projeto

O sistema contém várias instâncias desse tipo de equipamento, o que significa que existem ainda mais variáveis ​​no software de gerenciamento. Para eliminar erros associados ao nome das variáveis, é utilizado um sistema de codificação do equipamento. No banco de dados de sinais, grupos de sinais são formados cujos nomes exclusivos contêm o código do sistema, o tipo de equipamento e um código exclusivo dentro do sistema.

Neste exemplo, no circuito hidráulico, temos duas instâncias da válvula localizada no sistema 502, que é controlada pelo bloco ZRA TYPE 1 . (veja a Fig. 12.) Seus nomes no banco de dados são 502GTVOO1 e 502GTVOO2 . A janela do banco de dados de sinais é mostrada na Figura 12.

Figura 12. Banco de dados de sinais dos equipamentos do sistema de controle SPD.

O sistema de codificação determina os nomes das variáveis ​​para os módulos do software de controle e permite automatizar os processos de nomeação de sinais dentro de todo o módulo de software desenvolvido. Qualquer nome de variável consiste no nome do grupo de sinais e no nome da variável conectado pelo sinal “_”.

Para qualquer válvula de fechamento e controle relacionada à faixa de disparo "ZRA Type1", o nome dos sinais de entrada, variáveis ​​de estado e variáveis ​​de saída se parece com " código de armadura " _ " signal_name ". Para a válvula 502GTV002 , existem 65 variáveis ​​no banco de dados de sinais, por exemplo:

Equipas:
502GTV002_open_rem - comando de abertura remota.
502GTV002_close_rem - comando de fechamento remoto.
502GTV002_open_rem_z - comando preliminar para fechar.

Variáveis ​​de estado do vergalhão:
502GTV002_opened - a válvula está totalmente aberta.
502GTV002_notopened - válvula não aberta.
502GTV002_notclosed - válvula não fechada.
502GTV002_losed - A válvula está totalmente fechada.

Parâmetros de entrada e saída de fluido hidráulico:

502GTV002_XTK1 - pressão na linha de trabalho.
502GTV002_XTK2 - pressão na linha de pressão.
502GTV002_XTK3 - pressão na linha de drenagem.

Se adicionarmos mais uma unidade de reforço a esse esquema, seu nome será 502GTV003, onde de acordo com o sistema de codificação aceito

502 é o nome do módulo.
GTV - tipo de reforço.
003 - número de série de válvulas deste tipo no módulo.

Durante o desenvolvimento do módulo de controle, os valores dos parâmetros podem ser definidos no banco de dados de sinais e, assim, a integridade de uma unidade de controle separada é verificada. Em particular, o estado das válvulas neste exemplo é determinado pela pressão nas linhas de entrada e saída de fluido hidráulico. Para testar o módulo de controle separadamente do resto do sistema, essa pressão pode ser definida manualmente no banco de dados de sinais.

Quando a unidade está operando como parte da PMU, é necessário transferir os valores de pressão dos respectivos sensores para a unidade de controle. Para isso, são utilizados blocos de interface, cujo nome coincide com o nome do equipamento - veja a Fig. 13. Para a conveniência da depuração, o mesmo bloco exibe os valores dos sinais recebidos dos sensores.

Figura 13. Transmissão de sinais dos sensores para a unidade de controle ZRA T1.

Como resultado da operação desta unidade, uma equipe é formada para mover os carretéis nas válvulas de controle, responsáveis ​​pelo equipamento de controle com o nome 502GTV002 .

Durante o cálculo da junta, os valores dos parâmetros calculados no modelo hidráulico são transferidos para a unidade de processamento de leitura do sensor (consulte a Fig. 14), onde os dados obtidos são analisados ​​quanto à confiabilidade, filtragem e conversão nos valores de medição necessários.

Figura 14. O esquema de design para o processamento de sensores.

O esquema de cálculo para o processamento das leituras dos sensores mostrado na Figura 14 também é um programa totalmente funcional. Para transferir esse circuito para o equipamento de controle real, basta que o valor recebido da placa de entrada / saída do sensor real seja colocado na variável "Valor estimado" no relógio de troca de dados em equipamentos reais.

Este circuito também é vetorial e fornece o processamento de todos os sensores incluídos no circuito hidráulico 502.prt

Os blocos de projeto padrão projetados e testados são colocados em uma biblioteca de soluções padrão e, posteriormente, são usados ​​por outros desenvolvedores para todos os equipamentos desse tipo.

Após a depuração e verificação de todos os esquemas de cálculo necessários de programas típicos, o desenvolvimento de software de controle para qualquer módulo subaquático se torna claro, simples e eficaz. Você pode adicionar qualquer equipamento em duas etapas:

• Coloque a unidade de controle do equipamento.
• Adicione tantas unidades de interface quantas instâncias de equipamento serão conectadas à PMU.

Metodologia OOP em linguagens gráficas em ação.

.

. . .

.

« , () 5 »

, . . . . . , , , . , , - , .

, - (. . 15).

15. .

. , 9, 10 7, 8 (. . 16).

16. .

(. . 17). , , . , , .

17. .

, , .

18 . , .

19 .

18. 2- .

19. .

, , , , 30,5 , , 32, .

« () 5 »

, 5 , . , « () 5 », , , , 8 ( ). ( ).

Conclusões

- , !

. .

. .

, , , , . , - , .

- , !

, — .