Desenvolvimento de um Programa Computacional Conversor de Casos ATP em Diagrama do ATPDRAW™ Via Documento XML

‍

Autores: J. P. R. Carvalho (ESC Engenharia), V. R. Simoni (UFPE), V. Moraes (Tempest Security Intelligence, H.F.M. Filho (ESC Engenharia), R.F. Dias (ESC Engenharia)

‍

1 INTRODUÇÃO

O Alternative Transients Program (ATP) é um programa amplamente utilizado para simulação computacional de fenômenos transitórios de natureza eletromagnética e eletromecânica em sistemas elétricos de potência. O início de seu desenvolvimento, ainda sob o nome de Electromagnetic Transients Program (EMTP), ocorreu na década de 1960, com o interesse do Hermann W. Dommel, em parceria com a Bonneville Power Administration (BPA). Anos seguintes, com o término da parceria, o desenvolvimento do projeto foi assumido por Scott Meyer e Tsu-huei Liu, co-presidentes do Canadian/American EMTP User Group, juntamente com contribuições externas [1].

É possível, utilizando os recursos do ATP, modelar desde componentes básicos, como resistores lineares, indutores, capacitores, fontes ideais e chaves controladas por tempo, até componentes complexos, como linhas de transmissão, elementos não lineares e sistemas de controle.

De forma complementar e com o intuito de agregar ao ATP, em 1999 iniciou-se o projeto de desenvolvimento do ATPDraw™ na Norwegian University of Science and Techonolgy (NTNU), com Hans Kristian Høidale e outros subcontratados para programação e documentação. O ATPDraw™ é um préprocessador gráfico do ATP executado no sistema operacional Windows. A partir dele é possível construir um circuito elétrico utilizando a seleção de componentes dos respectivos menus e, diante de uma correta parametrização da simulação, é gerado um arquivo com extensão “.atp” que pode ser utilizado no ATP [2]. Entretanto, não há recurso que permita gerar componentes gráficos suportados pelo ATPDraw™, originado de um caso ATP, montado exclusivamente pelo editor de texto. A sua estruturação de dados apresenta apenas o necessário para realizar os cálculos das simulações solicitadas, sem qualquer informação gráfica dos objetos e da topologia do sistema em estudo.

Assim, este trabalho propõe o desenvolvimento de um programa computacional para converter informações de rotinas estruturadas do arquivo de extensão “.atp” em componentes reconhecidos pelo ATPDraw™, por meio da linguagem de marcação descrita no documento eXtensible Markup Language (XML), em que os dados dos parâmetros contidos no arquivo de extensão “.atp” são passados para os valores dos atributos do arquivo de extensão “.xml” nos elementos criados em correspondência com cada componente aceito e identificado pelas regras determinadas no ATP.
Toda a modelagem dos padrões de cartões ATP foi estruturada em arquivos JavaScript Object Notation (JSON), o que facilita a inserção de novos padrões de cartões não contemplados neste trabalho, bem como possíveis alterações futuras. A Figura 1 apresenta o fluxograma da ferramenta. Implicitamente, a construção de um caso ATP é realizada utilizando um editor de texto de acordo com as regras determinadas em sua documentação oficial [3] ou com o uso do pré-compilador ATPDraw™. De forma eficiente, a proposta deste trabalho permite o dinamismo e a união entre as duas alternativas mencionadas.

‍

‍

2 MOTIVAÇÃO

Os dados de entrada de um arquivo de extensão “.atp” são montados de acordo com a estrutura do cartão de dados de 80 colunas, embora seja possível alterar para 132 colunas por meio de um cartão de solicitação especial, mas não é usual, nem de boa prática. Logo, presume-se que os dados de entrada consistam em linhas American Standard Code for Information Interchange (ASCII) com 80 colunas, e, portanto, a estrutura do conteúdo do ATP pode ser montado usando qualquer editor de texto [3]. No entanto, não é um método visualmente agradável, o que o torna, muita das vezes, ineficiente na modelagem de redes complexas para análise, caso o usuário não tenha boa experiência sobre as regras de construção do caso ATP.

O método usual, dessa maneira, seria utilizando uma Guide User Interface (GUI). Uma GUI fornece recursos de apontar, clicar e criar conectividade de componentes de rede. Desde o final dos anos 1990, a comunidade ATP tem acesso livre de royalties a uma GUI chamada ATPDraw™ [2]. A partir desse pré-processador gráfico é possível criar automaticamente o arquivo de entrada do programa, com extensão “.atp”, por meio de um diagrama representativo do sistema, com extensão “.acp”, e executar análise via o compilador “tpbig.exe”.

Para utilizar o ATP, o usuário precisa fornecer um arquivo de entrada com formato padrão, com extensão “.atp”, contendo a parametrização da simulação e a configuração do sistema elétrico escritos em forma de rotina para ser simulado. No entanto, além do conhecimento especializado a respeito dos modelos disponíveis no programa, esta tarefa exige uma compreensão da sintaxe e da formatação desse arquivo.

Os meios padrões de processamento de uma simulação de transitórios eletromagnéticos via ATP são: um por meio de texto seguindo um script, em que comandos reservados do programa realizam determinadas funções e a partir da configuração de parâmetros, prepara o ambiente da simulação; e o outro diretamente sobre a tela do ATPDraw™, que, com o mouse se consegue selecionar componentes relacionados aos cartões do ATP, configurando seus parâmetros nas interfaces gráficas correspondentes, e, por meio das conexões estabelecidas, executar o compilador do ATP.

Portanto, a interface de usuário ideal seria aquela que possibilita uma boa experiência, tanto por meio da GUI, quanto pela edição do código em um editor de texto, em que a alteração de dados em uma visualização seja imediatamente refletida na outra. Com as novas funcionalidades da versão 7 do ATPDraw™, a importação e exportação de componentes utilizando um documento XML [2], expandiu-se as possibilidades de edição e intercâmbio entre os programas computacionais que reconheçam essa extensão de arquivo, o que fomentou o desenvolvimento de uma ferramenta que proporcionasse o tráfego de dados bidirecional entre ATP e ATPDraw™.

Dessa maneira, unir a virtude de produtividade da construção do caso de estudo, via texto, e a estética gráfica, via ATPDraw™, é a principal motivação desse projeto. O programa computacional desenvolvido e apresentado neste trabalho, nomeado de “ATP2Draw”, irá transcrever automaticamente as rotinas compostas pelos cartões do ATP, que representam cada elemento do circuito, em componentes gráficos compreendidos pelo ATPDraw™, passando seus parâmetros de configuração. Portanto, por meio desse desenvolvimento será possível economizar tempo de elaboração das análises e ter a possibilidade de uma visualização gráfica esteticamente agradável, facilitando o entendimento e modificação da modelagem dos componentes.

Por fim, há uma base de dados de estudo, modelada em ATP, que é consideravelmente maior do que a base de dados criada a partir de um diagrama de sistema modelado em ATPDraw™, devido ao tempo de utilização do ATP por analistas. Dessa forma, aproveitar a extensa lista de casos já construídos e convertê-los para tornar o ambiente de simulação mais útil e de fácil compreensão é o objetivo do programa proposto, que possibilita a troca de dados entre ATP e ATPDraw™ de forma bidirecional, tornando o ambiente de simulação mais dinâmico e eficiente.

‍

3 TECNOLOGIAS ENVOLVIDAS

Nos subtópicos seguintes serão abordadas brevemente os fundamentos e o porquê do envolvimento de cada tecnologia no software proposto.
A arquitetura escolhida para o desenvolvimento do ATP2Draw foi por meio da estruturação dos dados em documento JSON, e, por meio deles, são carregados os padrões e regras do sistema para, depois, fazer a leitura do caso ATP, verificar as compatibilidades com os cartões e, por último, escrever em arquivo XML os dados lidos. A Figura 2 ilustra este processo.

‍

Apesar de que os arquivos JSON e XML tenham propósitos semelhantes [4] e [5], que são modelar e intercambiar dados, a inclusão das duas tecnologias no escopo do projeto é pelo fato que JSON possui uma sintaxe mais simples, permite estruturar dados mais complexos, por meio da sua maneira de definir o tipo do dado. Já o XML está inserido, porque é o único tipo de arquivo editável que o ATPDraw™ permite importação e exportação.

3.1 XML

‍
O arquivo XML é baseado em uma linguagem de marcação, a qual possui um formato de texto simples e muito flexível, sendo um subconjunto do Standard Generalized Markup Language (SGML) e definido pelo Word Wide Web Consortium (W3C), assegurando que os dados estruturados serão uniformes e independentes de aplicações e fornecedores [4].

O documento da linguagem XML foi projetado para armazenar e transportar dados com característica auto descritiva. As instruções nele contidas são encapsuladas em uma estrutura de comandos, que contêm essas informações – comumente denominadas de tags –, e são caracterizadas por elementos, atributos, valores e conteúdo dos elementos. Sendo assim, por meio de um programa computacional é possível interpretar e manipular seus dados de forma que execute alguma instrução com o objetivo de exibir algum conteúdo, como também armazene e envie seus dados com baixo custo computacional [6].

A partir da documentação do ATPDraw™ versão 7 [2], é possível estabelecer as regras de hierarquia e validar os tipos de elementos, atributos e valores com base no Document Type Data (DTD) e, então, obter suas descrições, bem como assim como o relacionamento entre essas entidades, no “skeleton” do documento XML ATPDraw™.

‍

3.2 JSON

‍

Assim como o documento da linguagem XML, JSON é uma tecnologia para estruturação e intercâmcio de dados complexos de maneira robusta, baseado na modelagem dos seus tipos primitivos e estruturados, por meio do processo de parser e serialização do conteúdo, o qual foi derivado da ECMAScript Programming Language Standard, que estabelece um conjunto de regras de formatação para realizar suas aplicações [5]. Em um JSON, a estrutura do conteúdo de qualquer elemento é representada por um par chave-valor, em que a chave é o que vem antes dos dois-pontos e valor é o que vem depois, como mostra a seguinte sintaxe: {"Chave": "Valor"}.

Para atender aos objetivos propostos pelo software, foi necessário uma estrutura geral que informe a correspondência do documento com o cartão ATP checado, regras de identificação dos padrões pré-definidos pelo [3] e transcrição dos parâmetros lidos para o referido componente do documento XML, como mostra o esquemático da Figura 3.

‍

Em que o valor passado para a chave “name” indica onde o cartão correspondente começa; o objeto “initialValues” contém valores padrões para serem determinados na estrutura de dado do tipo dicionário “VARIABLES”, em que seus valores podem ser modificados dinamicamente quando o caso ATP é lido; o array “components” descreve como lidar com o arquivo de extensão “.atp” definindo padrões e o array “globalContent” define o conteúdo aplicado a todos elementos do componente. Ainda, se o array “$globalRules” é usado, suas regras serão aplicadas a todos elementos do componente.

Foi necessário customizar algumas regras para permitir que haja padrões de identificação, como também tornar possível efetuar cálculos no momento de intercâmbio de informações entre a leitura do JSON e a escrita do XML, de forma que sejam compatíveis.

Valores começando com o cifrão “$” são tratados como variáveis – exemplo: “$VINTAGE”, que é verificado para definir a precisão das casas decimais dos parâmetros contidos no padrão a ser utilizado – e armazenados em uma estrutura de dado do tipo dicionário, nomeado de “VARIABLES”.

Chaves “rule” serão utilizadas para definir as regras de identificação inclusas nos valores das chaves “pattern”. Quando a “rule” estiver dentro de um objeto do array “patterns”, significa que é uma regra restrita àquele “pattern” que está contido no mesmo objeto. Quando ela estiver fora do array “patterns”, implica uma regra geral para todos os objetos dentro do “patterns”.

Dentro de um valor, por exemplo “$n1”, significará considerar a variável “n1” completa, “$n1_1[:-1]” significará considerar a variável “n1_1” até seu penúltimo caractere, e “$n1_1[-1]” significará considerar apenas o último caractere da variável “n1_1”. Isso será necessário para evitar colisões na geração dos vários componentes que compartilhem o mesmo “pattern”, como strings de nós correpondentes a componentes monofásicos e trifásicos.

Os elementos que possuam a chave com o nome “content” são utilizados para atribuir o valor diretamente ao documento XML correspondente, logo, os parâmetros podem ser passados de forma implícita, quando são correspondentes aos atributos pertencentes ao elemento data do XML, ou de forma explícita, por meio da estrutura performada nos seus próprios objetos. Caso o elemento “content” possua uma string como valor, este valor deve ser uma referência para outro elemento dentro do JSON.

Quando necessário criar outros elementos na árvore XML, correspondente a um componente, basta definir o nome do elemento, a ser criado no XML, como valor da chave “Type” e por seguinte, no mesmo objeto, inserir os atributos e valores, como pares chave-valor respectivamente.

Em aspectos gerais, uma breve simulação de como os scripts irão trabalhar com o JSON se baseia em verificar se os elementos do array “pattern” correspondem às linhas que estão sendo lidas no arquivo ATP. Em caso afirmativo, o código do “$rule”, dentro do mesmo objeto do “pattern”, é executado para que logo em seguida carregue o conteúdo do “content” específico e seja transcrito para o documento XML. Por fim, o código do “$rule” fora do “patterns” é executado, assim como os dados do “content” são escritos no XML. E assim finaliza a construção da árvore XML correspondente a cada componente.

‍

3.3 Pacotes das Bibliotecas C# Utilizadas

‍

Para o C# trabalhar com o intercâmbio de dados, tanto pelo JSON, como XML, são necessárias a inclusão de três principais bibliotecas: Json.net, LINQ to XML e Microsoft.CodeAnalysis. CSharp.Scripting [7] – [10]. A biblioteca LINQ to XML é um dos pacotes inclusos na tecnologia Language INtegrated Query (LINQ), que fornece experiência de consulta consistente, diretamente dentro da linguagem, através das expressões de sintaxe declarativa, similar a linguagem de banco de dados relacional Structered Query Language (SQL). Com esse tipo de sintaxe, pode-se executar operações de filtragem, agrupamento, seleção etc., em fontes de dados com um mínimo de código, o que torna o desenvolvimento da aplicação mais eficaz, pois retira a responsabilidade do desenvolvedor de se preocupar com regras para trabalhar esses tipos de documentos que intercambiam dados. Dessa forma, evita-se uma sintaxe prolixa, erros e sobrecargas no programa computacional.

A biblioteca json.net é utilizada para carregar os arquivos JSON de forma estruturada, a qual é desenvolvida e mantida open-source. E a biblioteca Microsoft.CodeAnalysis.CSharp.Scripting permite a compilação de possíveis trechos de código C# dentro dos valores das chaves existente nos arquivos JSON, a qual foi desenvolvida e mantida open-source. Esta biblioteca é necessária porque C# é uma linguagem pré-compilada, dessa forma, ela é responsável pela compilação e execução dos códigos durante o processo de execução do código.

‍

3.4 Estruturação do ATP

‍

Devido a época que foi desenvolvido, o ATP teve como principal tecnologia de programação a linguagem Fortran, e, originalmente, a sintaxe da linguagem Fortran foi definida de forma que cada linha do programa fosse escrita em um cartão perfurado, com um carácter por coluna [11]. Em vista disso, a estrutura do arquivo de entrada do ATP herdou esta concepção. Embora atualmente seja utilizado um arquivo em formato texto com codificação ASCII, é comum o emprego do termo “cartão” em referência às linhas do arquivo e de “classes de cartões de dados” para os diferentes tipos de dados suportados pelo programa.

Esses cartões são divididos em classes como os cartões dólar ($-cards), cartões classificados por classe (“/” cards), cartão “$INCLUDE” para modularização de dados e cartões que iniciam um novo caso ATP, os quais são divididos em: cartões de solicitação especial, os quais requisitam palavras-chave; cartões de dados “miscellaneous”; e extensões para cartões de dados “miscellaneous” [3].
Os $-cards são compreendidos a partir de palavras reservadas, depois do cifrão $, situado na coluna 1 do cartão, os quais são de requisição arbitrária na construção do arquivo de extensão “.atp” e são atendidos localmente (varia de acordo ao hardware de cada computador) na sub-rotina Card IMAGE (CIMAGE), dependentes da instalação do programa, exceto o cartão “$INCLUDE”. Esses cartões têm como objetivo geral manipular a configuração da simulação e parâmetros de saída da execução do caso ATP.

De um modo geral, o arquivo de entrada do ATP é composto de oitenta colunas, nas quais as informações são arranjadas de acordo com o formato de dados específico. A palavra reservada “BEGIN NEW DATA CASE” indica o início de um novo caso, como também indica o término do caso corrente. Entres essas duas palavras são inseridas as lógicas dos cartões correspodentes aos TACS e MODELS (opcionalmente), BRANCH, SWITCH, SOURCE e OUTPUT, de forma implícita, em que cada cartão tem seu campo de conteúdo encerrado pela palavra BLANK.

‍
Essa arquitetura anterior deve ser seguida rigorosamente para que se evite erros de leitura dos dados. No entanto, para proporcionar maior flexibilidade no cadastro dos dados, o programa ATP aceita também a estruturação dos cartões classificados por classe, reconhecidos a partir do caractere “/”, localizado na coluna 1 do arquivo de extensão “.atp”, e seguido da palavra-chave correspondente à classe do cartão lógico.
Dentre as suas vantagens, destaca-se a principal de ter clareza na identificação dos componentes e rotinas atribuídas a cada cartão solicitado, logo o software ATP2Draw tem como premissa que o caso ATP esteja montado de acordo com essa regra.

‍

4 RESULTADOS

‍

Diante do propósito de apresentar uma aplicação da funcionalidade do programa computacional desenvolvido na realização de estudos presentes no projeto básico de um empreendimento, é apresentada, nos tópicos seguintes, a conversão do caso ATP para o ATPDraw™, por meio de um documento XML, para uma energização de uma linha de transmissão e de um transformador de potência.

‍
O estudo de energização de linha de transmissão tem como objetivo avaliar as máximas sobretensões transitórias a serem impostas aos barramentos das subestações e aos terminais das linhas de transmissão, bem como avaliar a energia dissipada nos para-raios de linha, para que haja o dimensionamento desses equipamentos sob o ponto de vista da sua capacidade de absorção [12].

Já o estudo de energização de um transformador tem como objetivo identificar sobretensões e corrente de inrush no equipamento, e energia dissipada nos para-raios de cada nível de tensão, fornecendo subsídios para a especificação dos equipamentos a serem instalados nas subestações, bem como identificar situações potencialmente problemáticas, indicando ainda se há ou não a necessidade de medidas mitigadoras como resistores de pré-inserção ou sincronizadores [12].

‍
Apesar da análise neste trabalho ser restrita a dois casos de estudo, suas modelagens, no ATP, levam em consideração os principais componentes de um sistema elétrico, os quais são estendidos para representação de todos os demais estudos de transitórios eletromagnéticos que envolvem manobra.

Com o intuito de lançar uma primeira versão do programa que contemplasse a maioria dos componentes essenciais para elaboração dos principais estudos elétricos de transitórios, focou-se na identificação dos padrões de cada possível componente, suportado pelo ATP e o ATPDraw™, e obteve êxito na conversão desses casos. As funcionalidades do ATP que não são suportadas pelo ATPDraw™, ainda assim, serão passadas como conteúdo de texto para o componente “ADITTIONAL”, com a invocação do seu referido cartão. Dessa forma, todas funcionalidades do ATP serão preservadas no ambiente gráfico.
Na primeira análise tem-se uma energização de linha de transmissão, cuja topologia é mostrada na Figura 4.

‍

‍

A Figura 5 mostra o sistema do estudo em análise, na versão XML, lida pelo ATPDraw™, por meio do ATP2Draw.

‍

‍

Na segunda análise tem-se uma energização de transformador, cuja topologia é mostrada na Figura 6.

‍

A Figura 7 mostra o sistema do estudo em análise, na versão XML, lida pelo ATPDraw™, por meio do ATP2Draw.

‍

‍

Por fim, ressalta-se que o presente programa contempla a conversão dos componentes correspondentes aos cartões lógicos: TACS (fontes, funções transferência, dispositivos e declarações fortran); BRANCH (linear, não linear – exceto modelo de transformadores XFORMER –, linhas com parâmetros distribuídos e concentrados, e a rotina LCC – Line Constantes Cable – para circuitos aéreos trifásicos, com até 6 cabos por feixe); SWITCH (controlada por tempo e tensão, diodo, triac, TACS, de medição, estatística e sistemática); SOURCE (fonte CA e CC – exceto máquina universal, indução e síncrona –, dente de serra, trem de pulso, rampa e de surto); LOAD FLOW (barra de carga, barra de geração e barra de balanço); OUTPUT (tensão de linha, de fase e entre termináis do ramo); transposições físicas; separador de fases e rotinas de suporte (FREQUENCY SCAN, HARMONIC FREQUENCY SCAN e FIX SOURCE).

‍

5 CONCLUSÕES

Por meio da utilização do programa ATP2Draw [13], tornou-se possível aproveitar os casos ATP, puramente construídos via cartão, e visualizar todos os componentes gráficos, correspondentes ao ATPDraw™, o que auxilia o entendimento dos mais variados sistemas, por meio de qualquer analista dos estudos, facilitando sua interoperabilidade. Para demonstrar sua potencialidade, abordou-se análises de casos reais, que contemplaram os principais componentes da modelagem de uma rede representativa para estudos de transitórios eletromagnéticos. Com a utilização do programa computacional desenvolvido, espera-se fornecer eficácia na conversão dos arquivos de extensão “.atp” para arquivos de extensão “.xml”, de forma que ambos irão gerar o mesmo comportamento das grandezas monitoradas no fenômeno.

‍
Desenvolvimentos futuros do ATP2Draw comtemplarão a alocação dos componentes interpretados, na tela, por métodos de layout de grafos, a fim de dispor uma rede, com topologia complexa, na interface gráfica de forma estritamente organizada, na qual haja a minimização do cruzamento das conexões que interligam os objetos e seus comprimentos, sem ocorrer colisão de posicionamento dos elementos.

‍

6 TRABALHOS FUTUROS

No estado atual do ATP2Draw, ainda não há a implementação de um método matemático formal para otimizar a posição dos componentes no diagrama, e isso é uma funcionalidade importante a ser tratada, como passo da seguinte versão do programa computacional, pois esse procedimento demanda tempo considerável do analista, que poderia ser economizado na entrega de determinado estudo, e dedicado para outras análises. Uma possível solução é estudar e implementar métodos de layout de grafos, com soluções passíveis de pequenas modificações pelo analista.
Por fim, outras possíveis atualizações do software se conterão a contemplar objetos que ainda não foram suportados devido a sua especificidade, como o cartão “MODELS”, as máquinas universais, síncronas e de indução, do cartão “SOURCE”, e os modelos de transformadores mais acurados, através das rotinas “XFORMER”.

‍

7 REFERÊNCIAS

[1] EMTP ALLIANCE, 2021, https://www.emtp.com/about-us/emtp-history.
[2] HØIDALEN, H. K., "ATPDraw – The Graphical Preprocessor to ATP – User Manual,” Norway, 2022.
[3] CANADIAN-AMERICAN EMTP USER’S GROUP, "Alternative Transients Program (ATP-EMTP) – Rule Book,” 1987-2016.
[4] W3C®, 2016, https://www.w3.org/XML.
[5] CROCKFORD, D., “The application/json Media Type for JavaScript Object Notation (JSON)”.
[6] W3SCHOOLS., “Documentação do XML”, https://www.w3schools.com/xml/default.asp.
[7] NUGET., Pacote C#, 2021, https://www.nuget.org/packages/Microsoft.CodeAnalysis.CSharp.Scripting.
[8] OBARLIK, O., “Json.Net & Json.Net.Core”, 2021, https://github.com/obarlik.
[9] MICROSOFT., “Documentação do LINQ-XML”, 2022, https://docs.microsoft.com/en-us/dotnet/api/system.XML.linq?view=net-6.0.
[10] .NET Foundation. “ROLSYN.NET”, 2022, https://github.com/dotnet/roslyn.
[11] ORACLE. “FORTRAN 77 Language Reference”, https://docs.oracle.com/cd/E19957-01/805-4939/6j4m0vnc3/index.html.
[12] GREENWOOD. A, Electrical Transients in Power Systems, Second Edition: Wiley, 1991.
[13] CARVALHO, J. P. R, “ATP2Draw”, 2023, https://github.com/joao-regocarvalho/ATP2Draw.