metodologia de anÁlise de sistemas de proteÇÃo...
TRANSCRIPT
UNIVERSIDADE ESTADUAL DO OESTE DO PARANÁ
CAMPUS DE FOZ DO IGUAÇU
PROGRAMA DE PÓS-GRADUAÇÃO EMENGENHARIA ELÉTRICA E COMPUTAÇÃO
DISSERTAÇÃO DE MESTRADO
METODOLOGIA DE ANÁLISE DE SISTEMAS DEPROTEÇÃO COM CONTROLE DISTRIBUÍDO ATRAVÉSDA FERRAMENTA DE MODELAGEM E VERIFICAÇÃO
FORMAL ESTATÍSTICA
FELIPE CRESTANI DOS SANTOS
FOZ DO IGUAÇU2017
Felipe Crestani dos Santos
Metodologia de Análise de Sistemas de Proteção comControle Distribuído Através da Ferramenta de Modelagem e
Verificação Formal Estatística
Dissertação de Mestrado apresentada ao Programa dePós-Graduação em Engenharia Elétrica e Computa-ção como parte dos requisitos para obtenção do títulode Mestre em Engenharia Elétrica.Área de concentração: Sistemas Dinâmicos e Ener-géticos.
Orientador: Guilherme de Oliveira Kunz
Foz do Iguaçu2017
ii
Metodologia de Análise de Sistemas de Proteção comControle Distribuído Através da Ferramenta de Modelagem e
Verificação Formal Estatística
Felipe Crestani dos Santos
Esta Dissertação de Mestrado foi apresentada ao Programa de Pós-Graduação emEngenharia Elétrica e Computação e aprovada pela Banca Examinadora:
Data da defesa pública: 17/11/2017.
Prof. Dr. Guilherme de Oliveira Kunz - (Orientador)Universidade Estadual do Oeste do Paraná - UNIOESTE
Prof. Dr. César Rafael Claure TorricoUniversidade Tecnológica Federal do Paraná - UTFPR
Prof. Dr. Romeu ReginattoUniversidade Estadual do Oeste do Paraná - UNIOESTE
iv
Resumo
A linha de pesquisa abordada neste trabalho aponta para o estudo e desenvolvimento de ferra-mentas que subsidiem a proposição e validação de Sistemas de Proteção de Sistemas de EnergiaElétrica. Em geral, este processo é realizado mediante simulações computacionais envolvendodiversos cenários de operação e distúrbios, tendo como principal limitação a impossibilidade derepresentar todos os caminhos de evolução do sistema em análise. Nesse contexto, propõe-se oemprego da técnica de Modelagem e Verificação Formal como ferramenta de suporte ao projeto,análise e implementação de estratégias de proteção, principalmente no sentido de comprovar sea estratégia atende os requisitos de segurança e comportamento determinístico temporal espe-rado. Em síntese, o método consiste na verificação de propriedades descritas em lógicas tem-porais, sob uma abstração apropriada (formalismo) do comportamento do sistema. Esta disser-tação possui enfoque nestes dois requisitos: modelagem do sistema de proteção através de umformalismo adequado e tradução dos requisitos do comportamento desejado em propriedadesdescritas em lógica temporal. Com relação ao formalismo de apoio, a modelagem do sistemade proteção é baseada em uma abstração de Autômatos Temporizados Híbridos. Como ferra-menta de validação, adota-se a técnica de Verificação Formal Estatística, através do softwareUPPAAL STRATEGO. Salienta-se que este trabalho se delimita apenas na modelagem e validaçãoindividual dos principais equipamentos de um sistema de proteção, sendo 18 modelos de dis-positivos e protocolos como barramentos de comunicação (LAN), protocolo de sincronizaçãode tempo PTP, protocolos de comunicação baseados em IEC 61850 e funções de proteção, e 13modelos auxiliares que implementam um comportamento estocástico para subsidiar o processode validação do sistema de proteção. O desenvolvimento dos modelos se deu através de umaabordagem sistemática envolvendo processos de simulação e verificação das propriedades sobo modelo em análise. Através desta metodologia, garante-se que os modelos desenvolvidos re-presentam o comportamento esperado de seus respectivos dispositivos. Para isso, os resultadosdo processo de verificação foram comparados com requisitos comportamentais definidos pornormas, testes de conformidade em equipamentos/protocolos e trabalhos acadêmicos vincula-dos à área. Com relação às contribuições do trabalho, identificou-se três linhas de pesquisa quepodem fazer o uso dos modelos desenvolvidos: i) implementação de novas estratégias de pro-teção; ii) realização de testes de conformidade em equipamentos externos à rede de autômatos;e iii) indicação de erros de parametrização do sistema de proteção.
Palavras-chave: Sistemas de Proteção, Verificação Formal Estatística, Sistemas de Tempo RealCríticos, Autômatos Temporizados Híbridos.
v
Abstract
The main line of research of this work is the study of approaches for supporting the deve-lopment and analysis of the Power System Protection. In general, this process is carried outthrough of a large number of simulations involving various operating scenarios. The main li-mitation of this technique is the impossibility of coverage of all behavior of the system underanalysis. In this context, this work proposes the use of Model Checking as a tool to supportthe procedure of development of power system protection schemes, principally in the sense ofproving the security requirements and temporal deterministic expected behavior. Model Chec-king is a verification technique that explores exhaustively and automatically all possible systemstates, checking if this model meets a given specification. This work focuses on this two pil-lars of the Model Checking: to choose an appropriate modeling formalism for representationof the power system protection and how to describe the specification in temporal-logic for theverification process. With regard to the modeling formalism, the power system protection willbe represented by the Hybrid Automata theory, while the verification tool adopted will be Sta-tistical Model Checking, by the UPPAAL STRATEGO toolkit. It is underlined that this workis limited to the modeling of individual components of the power system protection, such that18 models of the devices and protocols like communication bus (LAN), time synchronizationprotocol (PTP) and IEC 61850 communication protocols (SV and GOOSE) and Logical Nodesof power system protection, and 13 auxiliaries models, which emules the stochastic behaviorto subsidise the verification process. The methodology of modelling adopted guarantees theeffective representation of the components behaviour of power system protection. For this, theresults of Model Checking process were compared with behavioral requirements defined bystandards, conformance testings and paper related to the area. With regard to the contributionsof this work, were identified three researches areas that could use the models developed in thiswork: i) implementation of power system protection schemes; ii) achievement of conformancetesting; and iii) indication of the parameterization error of the power protection system scheme.
Keywords: Power System Protection, Statistical Model Checking, Hard Real Time, HybridAutomata.
vi
vii
Dedico este trabalho à minha família: Jaqueline, Laelcio, Beatriz e Lucas.
viii
Agradecimentos
Agradeço primeiramente a Deus, por ter me proporcionado a saúde e sabedoria necessáriapara realização deste sonho.
À minha esposa, Jaqueline, e meus pais Laelcio e Beatriz, pelo apoio, paciência e com-preensão pelo tempo em casa dedicado a esta dissertação.
Ao meu orientador Prof. Dr. Guilherme Kunz de Oliveira pela dedicação, apoio e suportenecessário durante o desenvolvimento e conclusão da pesquisa.
Aos meus amigos e colegas de pós-graduação e trabalho, em especial Thiago, Dabit eJonas pelo companheirismo e discussões técnicas.
À FPTI, pela concessão da bolsa e flexibilidade de horários para realização deste trabalho.
ix
x
xi
“Contudo, seja qual for o grau a que chegamos,o que importa é prosseguir decididamente.”
Fp 3,16
xii
Sumário
Lista de Figuras xv
Lista de Tabelas xx
Lista de Símbolos xxii
1 Introdução 1
1.1 Contextualização e Justificativa da Linha de Pesquisa . . . . . . . . . . . . . . 1
1.2 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5 Estrutura da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2 Fundamentação Teórica 15
2.1 Evolução dos Sistemas de Proteção de Sistemas de Energia Elétrica . . . . . . 15
2.1.1 Protocolo IEC 61850 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.2 Protocolo de Sincronização de Tempo IEEE 1588 . . . . . . . . . . . . 26
2.2 Modelagem e Verificação Formal de Sistemas de Tempo Real Críticos . . . . . 28
2.2.1 Formalismo de apoio à Modelagem . . . . . . . . . . . . . . . . . . . 29
2.2.2 Lógica Temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.2.3 Verificador de Modelos . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3 Materiais e Métodos 49
3.1 Modelagem do Sistema de Proteção . . . . . . . . . . . . . . . . . . . . . . . 49
xiii
xiv
3.2 Metodologia para Validação dos Modelos . . . . . . . . . . . . . . . . . . . . 52
3.3 Metodologia para Análise de Sistemas de Proteção . . . . . . . . . . . . . . . 53
3.4 Aplicação da Metodologia no UPPAAL: Interação Relé-Disjuntor (Caso Exem-plo) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.4.1 Modelo Relé no Caso Exemplo . . . . . . . . . . . . . . . . . . . . . 57
3.4.2 Modelo Disjuntor no Caso Exemplo . . . . . . . . . . . . . . . . . . . 61
3.4.3 Integração entre os Modelos no Caso Exemplo . . . . . . . . . . . . . 63
3.5 Implementação de Funções de Geração de Números Aleatórios Baseados emFunções de Distribuição de Probabilidade Paramétricas . . . . . . . . . . . . . 68
3.5.1 Exemplo de Aplicação em Estudos de Confiabilidade . . . . . . . . . . 72
4 Modelagem e Verificação do Sistema de Proteção 75
4.1 Barramento de Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.1.1 Modelagem do Barramento de Comunicação . . . . . . . . . . . . . . 76
4.1.2 Validação do Modelo de Barramento de Comunicação . . . . . . . . . 78
4.2 Protocolo de Sincronização de Tempo IEEE 1588 . . . . . . . . . . . . . . . . 88
4.2.1 Modelagem do Protocolo PTP . . . . . . . . . . . . . . . . . . . . . . 89
4.2.2 Validação dos Modelos PTP . . . . . . . . . . . . . . . . . . . . . . . 91
4.3 Serviços de Comunicação em IEC 61850 . . . . . . . . . . . . . . . . . . . . 99
4.3.1 Modelagem e Verificação da Transmissão de Mensagens GOOSE . . . 99
4.3.2 Modelagem e Verificação da Transmissão de Mensagens SV . . . . . . 109
4.4 Modelagem e Verificação da Merging Unit . . . . . . . . . . . . . . . . . . . . 117
4.5 Modelagem e Verificação das Funções de Proteção . . . . . . . . . . . . . . . 120
5 Conclusão 127
5.1 Conclusões Gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
5.2 Sugestões de Pesquisas Futuras . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Referências Bibliográficas 131
xv
A Programa de Conversão de Dados do UPPAAL para o Matlab 137
xvi
Lista de Figuras
1.1 Conceito de Agentes Relé no trabalho de Tomita et al. (1998). . . . . . . . . . 4
1.2 Validação de desempenho em Sistemas de Proteção via simulações. . . . . . . 10
1.3 Validação de desempenho em Sistemas de Proteção via Análise Formal: a) ocor-rência de deadlock; b) acessibilidade de estado marcado. . . . . . . . . . . . . 11
1.4 Delimitação da linha de pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1 Níveis e interfaces lógicas de uma subestação em 61850. . . . . . . . . . . . . 20
2.2 Representação simplificada dos protocolos 61850. Fonte: (Liu, 2015). . . . . . 22
2.3 Tempo de retransmissão das mensagens GOOSE. . . . . . . . . . . . . . . . . 23
2.4 Processo de virtualização segundo IEC 61850. . . . . . . . . . . . . . . . . . . 25
2.5 Abordagem baseada em Verificação Formal. . . . . . . . . . . . . . . . . . . . 29
2.6 Exemplo de AEF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.7 Exemplo de AFT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.8 Visualização da semântica de algumas fórmulas CTL básicas. . . . . . . . . . . 35
2.9 Modelo exemplificando uma rede de autômatos. a) autômato relay e b) autô-mato Circuit Breaker. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.10 Exemplos de fórmulas de trajeto no UPPAAL: a) Acessibilidade: E <> ϕ , b)Segurança: A[]ϕ e c) Acessibilidade: ϕ−− > ψ. . . . . . . . . . . . . . . . . 40
2.11 Etapa de Verificação Formal para a) autômatos discretos e b) autômatos híbridos. 42
3.1 Estrutura do sistema de proteção adotado. . . . . . . . . . . . . . . . . . . . . 50
3.2 Rede de autômatos do sistema de proteção. . . . . . . . . . . . . . . . . . . . 51
3.3 Fluxograma para validação dos modelos. Fonte: Adaptado de Kunz (2012). . . 52
3.4 Operação integrada da rede de autômatos. . . . . . . . . . . . . . . . . . . . . 54
xvii
xviii
3.5 Aplicações dos modelos desenvolvidos em ferramentas de suporte para a) im-plementação de estratégias, b) análise de desempenho de estratégias, e c) testesde conformidade em equipamentos reais. . . . . . . . . . . . . . . . . . . . . . 55
3.6 Exemplo de função diferencial (Caso Exemplo). . . . . . . . . . . . . . . . . . 56
3.7 Modelos considerados no Caso Exemplo. . . . . . . . . . . . . . . . . . . . . 56
3.8 Representação em Autômatos Temporizados do modelo Relé no Caso Exemplo. 58
3.9 Autômato que implementa a ocorrência de faltas no sistema elétrico para o mo-delo Relé. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.10 Simulação da rede de autômatos Relé + Fault_Detect. . . . . . . . . . . . . . . 59
3.11 Representação em Autômatos Temporizados do modelo Disjuntor para o CasoExemplo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.12 Autômato que implementa a geração aleatória de trips. . . . . . . . . . . . . . 62
3.13 Simulação da rede de autômatos Relé/Disjuntor no Caso Exemplo. . . . . . . . 62
3.14 Adaptações aos modelos a) Disjuntor e b) Relé, no Caso Exemplo. . . . . . . . 64
3.15 Simulação considerando a rede de autômatos formada no Caso Exemplo. . . . 65
3.16 Modelo Observador para o Caso Exemplo. . . . . . . . . . . . . . . . . . . . . 66
3.17 Correções ao modelo Relé. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.18 Modelos para avaliação das funções de distribuição a) via simulação; e b) viaverificação formal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.19 Implementação das funções de distribuição de probabilidade. . . . . . . . . . . 70
3.20 Comparação entre os modelos geradores de números aleatórios a) função den-sidade de probabilidade, e b) função cumulativa. . . . . . . . . . . . . . . . . . 70
3.21 Densidade de probabilidade das funções a) uniforme, b) exponencial, c) normal,d) lognormal e e) weibull. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.22 Rede de autômatos representando para teste de confiabilidade em um disjuntor.Modelos: a) Gerador aleatório de trips, b) Disjuntor e c) modo de falha . . . . 73
3.23 Densidade de probabilidade da função de falha do disjuntor em a) 10 anos e b)50 anos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.1 Tempo de transferência de pacotes. . . . . . . . . . . . . . . . . . . . . . . . . 76
4.2 Representação do modelo do barramento de comunicação. . . . . . . . . . . . 77
xix
4.3 Modelagem da LAN: a) delay fixo (“LAN_FIX”); b) delay variável com distri-buição uniforme (“LAN_UNIF”) e c) delay variável com distribuição lognormal(“LAN_LNORM”). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.4 Ordenação dos pacotes através do algoritmo bubble-sort. . . . . . . . . . . . . 79
4.5 Modelos emissores e receptores: a) emissor com tempo fixo; b) emissor comtempo variável em distribuição uniforme; c) emissor com tempo variável emdistribuição exponencial e d) receptor. . . . . . . . . . . . . . . . . . . . . . . 80
4.6 Modelos dos observadores: a) observador da LAN; b) observador de recebimento. 81
4.7 Simulações envolvendo os modelos a) LAN_FIX; b) LAN_UNIF e c) LAN_LNORM. 82
4.8 Inversão de pacotes devido à a) overflow da FIFO e b) caminhos diferentes nobarramento de comunicação. . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.9 Funcionamento do Protocolo IEEE 1588 two-step clock. . . . . . . . . . . . . 88
4.10 Representação do Modelo PTP. . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.11 Modelos do Protocolo PTP: a) Master_task1, b) Master_task2 e c) Slave_task . 90
4.12 Montagem dos Pacotes do Protocolo PTP. . . . . . . . . . . . . . . . . . . . . 91
4.13 Modelos auxiliares para o protocolo PTP: a) observador de mensagens (sniffer),b) emissor de mensagens PTP e c) observador de recebimento. . . . . . . . . . 92
4.14 Simulação envolvendo o modelo master_task1. . . . . . . . . . . . . . . . . . 93
4.15 Simulação envolvendo o modelo Master_Task2. . . . . . . . . . . . . . . . . . 95
4.16 Simulação envolvendo o modelo Slave_Task. . . . . . . . . . . . . . . . . . . 97
4.17 Simulação do funcionamento do protocolo PTP considerando seis dispositivos. 98
4.18 Modelo do serviço de emissão de mensagens GOOSE. . . . . . . . . . . . . . 100
4.19 Funções de atualização dos pacotes GOOSE. . . . . . . . . . . . . . . . . . . 100
4.20 Modelos auxiliares para verificação dos modelos emissores e receptores GO-OSE a) Nó Lógico estocástico e b) observador de mensagens GOOSE. . . . . . 102
4.21 Simulação considerando o modelo emissor GOOSE. . . . . . . . . . . . . . . 103
4.22 Modelo do serviço de recepção de mensagens GOOSE. . . . . . . . . . . . . . 105
4.23 Modelo do Nó Lógico receptor GOOSE. . . . . . . . . . . . . . . . . . . . . . 106
4.24 Simulação considerando o modelo receptor GOOSE. . . . . . . . . . . . . . . 107
4.25 Modelo do serviço de emissão de mensagens SV. . . . . . . . . . . . . . . . . 109
xx
4.26 Montagem dos pacotes do protocolo SV. . . . . . . . . . . . . . . . . . . . . . 110
4.27 Modelo do serviço de recepção de mensagens SV. . . . . . . . . . . . . . . . . 111
4.28 Modelo do serviço de recepção de mensagens SV. . . . . . . . . . . . . . . . . 113
4.29 Modelo do Nó Lógico receptor SV. . . . . . . . . . . . . . . . . . . . . . . . . 114
4.30 Simulação envolvendo o modelo de recepção SV. . . . . . . . . . . . . . . . . 114
4.31 Conceito básico de aplicação de Merging Unit. . . . . . . . . . . . . . . . . . 117
4.32 Modelo representativo da Merging Unit. . . . . . . . . . . . . . . . . . . . . . 118
4.33 Modelo proposto de Merging Unit. a) Amostragem do sinal de entrada e b) NóLógico para envio de mensagens SV. . . . . . . . . . . . . . . . . . . . . . . . 118
4.34 Simulação do processo de amostragem de uma Merging Unit. . . . . . . . . . . 119
4.35 Observador do modelo Merging Unit. . . . . . . . . . . . . . . . . . . . . . . 119
4.36 Estrutura de proteção considerada. . . . . . . . . . . . . . . . . . . . . . . . . 121
4.37 Modelagem IED: a) Nó Lógico da função de proteção, b) Algoritmo da funçãode proteção de distância, c) algoritmo da função de proteção de sobrecorrenteinstantânea e d) Algoritmo da função de proteção de sobrecorrente temporizada. 122
4.38 Sintaxe de inicialização das funções de proteção. . . . . . . . . . . . . . . . . 123
4.39 Modelo emissor de valores SV aleatórios baseados no Nó Lógico MMXU. . . . 124
4.40 Simulação envolvendo a função de proteção de distância. . . . . . . . . . . . . 124
4.41 Simulação da função de proteção de sobrecorrente. . . . . . . . . . . . . . . . 125
5.1 Modelos desenvolvidos neste trabalho. . . . . . . . . . . . . . . . . . . . . . . 128
A.1 Interface do programa Uppaal2Matlab . . . . . . . . . . . . . . . . . . . . . . 137
A.2 Interface de localização do arquivo Uppaal . . . . . . . . . . . . . . . . . . . . 138
A.3 Exportação das variáveis do Uppaal . . . . . . . . . . . . . . . . . . . . . . . 138
A.4 Gerando gráficos com o Uppaal2Matlab . . . . . . . . . . . . . . . . . . . . . 139
A.5 Simulação contendo as variáveis selecionadas . . . . . . . . . . . . . . . . . . 139
Lista de Tabelas
1.1 Segmentação dos trabalhos revisados na primeira etapa da dissertação. . . . . . 3
2.1 Estrutura da norma IEC 61850 até o ano de 2013. . . . . . . . . . . . . . . . . 19
2.2 Categorias dos nós lógicos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3 Principais Nós Lógicos de proteção. Fonte: Adaptado de (Machado, 2015). . . 26
2.4 Resumo das Queries no UPPAAL STRATEGO. . . . . . . . . . . . . . . . . . . . 42
3.1 Verificações sobre o modelo Relé para o Caso Exemplo. . . . . . . . . . . . . . 60
3.2 Verificações sobre o modelo Disjuntor no Caso Exemplo. . . . . . . . . . . . . 63
3.3 Verificações sobre o modelo global do Caso Exemplo. . . . . . . . . . . . . . . 66
3.4 Verificações sobre o modelo corrigido para o Caso Exemplo. . . . . . . . . . . 67
3.5 Comparação entre as funções de distribuição de probabilidade implementadas. . 71
4.1 Descrição das Principais Variáveis Adotadas no Modelo da LAN. . . . . . . . . 81
4.2 Verificação das Propriedades dos Modelos do Barramento de Comunicação. . . 86
4.3 Descrição das Principais Variáveis Adotadas no Modelo Master_task1 . . . . . 93
4.4 Verificação das propriedades sobre o modelo Master_Task1. . . . . . . . . . . 94
4.5 Verificação das propriedades sobre o modelo Master_Task2. . . . . . . . . . . 96
4.6 Verificação das propriedades sobre o modelo Slave_Task. . . . . . . . . . . . . 97
4.7 Descrição das principais variáveis adotadas no Modelo GOOSE. . . . . . . . . 101
4.8 Verificação sobre o serviço de emissão de mensagens GOOSE. . . . . . . . . . 104
4.9 Verificação do serviço de recepção de mensagens GOOSE. . . . . . . . . . . . 108
4.10 Verificação do serviço de emissão de mensagens SV. . . . . . . . . . . . . . . 112
4.11 Verificação Receptor SV. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
xxi
xxii
4.12 Verificação das propriedades sobre o modelo Merging Unit. . . . . . . . . . . . 120
4.13 Verificação das propriedades as funções de proteção do modelo IED. . . . . . . 126
xxiii
xxiv
Lista de Símbolos
ACSI Abstract Communication Service InterfaceAEF Autômatos de Estados FinitosAFT Autômatos Finitos TemporizadosAH Autômatos HíbridosATH Autômatos Temporizados HíbridosA/D Analógico-DigitalCB Circuit BreakerCTL Computation Tree LogicFDP Função Densidade de ProbabilidadeGUI Graphical User InterfaceGOOSE Generic Object Oriented Substation EventsIA Inteligência ArtificialIAD Inteligência Artificial DistribuídaIEC International Electrotechnical CommissionIED Intelligent Electronic DeviceIEEE Institute of Electrical and Electronics EngineersIF InterfaceIHM Interface Homem-MáquinaIRIG-B Inter-Range Instrumentation GroupLAN Local Area NetworkLasse Laboratório de Automação e Simulação de Sistemas ElétricosLD Logical DeviceLN Logical NodeLPTA Linear Priced Timed AutomataLT Linha de TransmissãoLTL Linear Temporal LogicMAS Multi-Agent SystemsMITL Metric Interval Temporal LogicMTBF Mean Time Between FailuresMU Merging UnitNTP Network Time ProtocolPD Physical DevicePFS Product Flow SchemePTI Parque Tecnológico Itaipu
xxv
PTP Precision Time ProtocolRoE Rate of EcponentialRP Redes de PetriRTDS Real Time Digital SimulatorSAS Sistemas de Automação de SubestaçõesSCADA Supervisory Control and Data AcquisitionSDEDs Sistemas Dinâmicos a Eventos DiscretosSEEs Sistemas de Energia ElétricaSHRV Sistema Hidráulico de Regulação de VelocidadeSIN Sistema Interligado NacionalSMAs Sistema MultiagentesSMC Statistical Model CheckingSNTP Simple Network Time ProtocolSV Sampled ValuesTC Transformador de CorrenteTCTL Timed Computation Tree LogicTP Transformador de Potencial (tensão)ttl time-Allowed-to-liveUGs Unidades de GeraçãoUGDs Unidades de Geração DistribuídaVLAN Virtual Local Area Network
xxvi
Capítulo 1
Introdução
A problemática abordada nesta dissertação é a do emprego de métodos de modelageme verificação formal de propriedades de sistemas híbridos aplicados em Sistemas de Proteçãode Sistemas de Energia Elétrica (SEEs), como ferramenta de suporte à proposição, análise dedesempenho e testes de conformidade em equipamentos pertencentes a estes sistemas. Inicia-se este capítulo com os principais aspectos referentes à motivação e justificativa da escolha dotema da pesquisa, seguindo uma abordagem histórica das atividades desenvolvidas ao longo dotrabalho. Além disso, o capítulo em questão engloba o contexto no qual a linha de pesquisa estáinserida, apontando a problemática geral e as contribuições técnicas/científicas do trabalho. Porfim, apresenta-se os objetivos e a organização (estrutura) da dissertação.
1.1 Contextualização e Justificativa da Linha de Pesquisa
A linha de pesquisa abordada por esta dissertação originou-se de um projeto de pesquisainiciado no Laboratório de Automação e Simulação de Sistemas Elétricos (Lasse), em 2015.Inicialmente, a meta do projeto se inclinava para a proposição de ferramentas computacionaisque auxiliassem os engenheiros da usina de Itaipu na avaliação de coordenação de sistemas deproteção, envolvendo principalmente a proteção de sobrecorrente das unidades geradoras coma proteção de distância adotada no tronco de 765 kV, que conecta Itaipu ao Sistema Interli-gado Nacional (SIN). Eventualmente, a estratégia proposta seria avaliada através de estudos noSimulador Digital em Tempo Real – RTDS (Real Time Digital Simulator), disponível no Lasse.
Durante a etapa de revisão bibliográfica realizada na área, identificou-se a tendência parao emprego de métodos computacionais baseados em Inteligência Artificial Distribuída (IAD)nos Sistemas de Proteção, motivado principalmente pelo aumento da complexidade de opera-ção e pela nova característica descentralizada de controle imposta a estes sistemas, aos quaiscaracterísticas como coordenação e cooperação se tornam essenciais para o seu pleno funcio-namento. Nesse contexto, recentes estudos apontam aos Sistemas Multiagentes (SMAs) comoferramenta bastante promissora para lidar com tais desafios.
1
2
Os SMAs são considerados uma ramificação da IAD, que ao contrário do paradigmatradicional de Inteligência Artificial (IA), volta-se para o estudo do comportamento apresentadopor vários agentes autônomos que interagem entre si e com o ambiente em que estão situadospara atingirem metas (sejam individuais ou coletivas).
A divergência entre definições de pesquisadores das mais diversas áreas do conhecimentoindica que ainda não há um consenso a respeito de conceitos no âmbito dos SMAs, princi-palmente pela característica multi e interdisciplinar desta abordagem. No entanto, a revisãobibliográfica realizada permitiu a identificação de conceitos que estão intrinsecamente relacio-nados nestas diversas definições. Alguns autores são comumente referenciados nos trabalhosrevisados, como Russel e Norvig, Wooldridge, Sichiman, entre outros clássicos da área de IAD(Russell & Norvig, 2010; Wooldridge, 2009). No âmbito das aplicações em SEEs, a defini-ção de agente autônomo é comumente ratificada por Wooldridge, sendo uma entidade física ouvirtual situada em um ambiente (também físico ou virtual) capaz de perceber as alterações noambiente e modificá-lo através de ações de forma a atingir seus objetivos (Wooldridge, 2009).
Devido às características desejáveis aos SMAs, como autonomia, habilidade social, reati-vidade, pró-atividade, entre outros, esta abordagem é vista como uma ferramenta em potenciala ser aplicada em diversas funções de controle e operação em sistemas elétricos (McArthuret al., 2007b). Outra vantagem é a escalabilidade e flexibilidade que os SMAs podem oferecer,características essenciais quando trata-se de sistemas em constante mudança e com a quantidadesignificativa de dispositivos quanto os SEEs. Especificamente na área de sistemas de potência,diversas pesquisas estão sendo direcionadas para simulação, otimização da operação, controle,proteção e desempenho desses sistemas através de SMAs (Catterson et al., 2011).
Baseado nesse contexto, a revisão bibliográfica foi então direcionada na área de apli-cações de SMAs em sistemas elétricos, mais especificamente em Sistemas de Proteção. Afinalidade desta etapa foi identificar uma linha de pesquisa consistente para desenvolvimentodos estudos envolvendo a coordenação entre as funções de proteção de geradores e de linhasde transmissão, baseada no paradigma de SMAs. Da revisão, definiu-se a classificação em trêslinhas de pesquisa, conforme apresentado na Tabela 1.1. Tal segmentação é relativa ao períodode operação/atuação dos SMAs com relação ao distúrbio elétrico e pode ser sintetizada por:
• Pré-Falta: tipicamente utilizam SMAs para realização de reajustes do sistema de proteçãode acordo com a condição operativa do sistema elétrico. Tais reajustes são responsáveispelo aumento e/ou garantia da coordenação, seletividade e confiabilidade do sistema deproteção frente às diversas condições operativas do sistema em questão;
• Tempo-Real: tipicamente utilizam SMAs na detecção e extinção de faltas em sistemaselétricos. Outros trabalhos, que também podem ser classificados como tempo-real, utili-zam SMAs na proposição de esquemas especiais de proteção, como por exemplo, prote-ção sistêmica e prevenção de desligamentos em cascata;
3
• Pós-Falta: aplicados à reconfiguração do sistema elétrico e validação da atuação do sis-tema de proteção, mediante análise dos dados de oscilografia relativo ao evento.
Tabela 1.1: Segmentação dos trabalhos revisados na primeira etapa da dissertação.
Pré-falta
Projeto(Wong & Kalam, 1995), (Wong & Kalam, 1997), (Park &Lim, 2006)
Proteção Adaptativa(Tomita et al., 1998), (Shaoqun et al., 2005), (Chen et al.,2005), (Sheng et al., 2006), (Thorp, 2008), (Wan et al.,2010)
Proteções Especiais(Xiangjun et al., 2004), (Li et al., 2005), (Sheng et al.,2010), (Owonipa et al., 2011), (Liu et al., 2012)
Tempo Real
(Tomita et al., 1998), (Coury et al., 2002), (Shono et al.,2002), (Yanxia et al., 2002), (Chen et al., 2004), (Shaohuaet al., 2005), (Xiangjun et al., 2004), (Giovanini et al.,2006), (Shono et al., 2002), (Sheng et al., 2010), (Yanget al., 2006), (Pang et al., 2010), (Owonipa et al., 2011),(Liu et al., 2012)
Pós-Falta
Reconfiguração (Sheng et al., 2006), (Rivera et al., 2014)
Diagnóstico(McArthur & Davidson, 2004), (Strachan et al., 2007),(Hossack et al., 2002), (Hossack et al., 2001), (Davidsonet al., 2003), (McArthur et al., 2004)
Baseado no número relativo de publicações revisadas nesta dissertação (Tabela 1.1) epelas atividades de pesquisa atualmente desenvolvidas pelo Lasse1, definiu-se como principallinha de pesquisa do mestrado a área de Sistemas de Proteção baseados em SMAs em TempoReal.
No âmbito das aplicações de SMAs nos Sistemas de Proteção, tomou-se como base o tra-balho de Tomita et al. (1998). Apesar de que o trabalho em questão seja relativamente antigo, asaber 1998, o mesmo é amplamente citado nos recentes trabalhos relacionados à implementaçãode Sistemas de Proteção com Controle Distribuído, fornecendo os conceitos básicos necessáriospara a formalização de estratégias de proteção neste novo paradigma.
No trabalho de Tomita et al. (1998), os autores propõem um sistema de proteção dife-rencial adaptativo e cooperativo introduzindo o conceito de “Agentes Relé”. Esse conceito éempregado como uma abstração de uma entidade computacional que observa e atua no ambi-ente em que vive de maneira autônoma. O funcionamento da filosofia de proteção propostapelos autores é baseado no compartilhamento de dados e funções de diversos dispositivos deproteção dispersos geograficamente em um SEE/Subestação, através de uma rede de comuni-cação existente entre eles (Tomita et al., 1998).
1Já existe um projeto em vigência no Lasse relativo à área de aplicação de SMAs no período Pós-Falta, empre-gado na avaliação do sistema de proteção da Usina de Itaipu através de dados de oscilografia dos registradores deperturbação da usina.
4
O sistema de proteção proposto é composto basicamente por quatro módulos (“AgentesRelé”) que interagem entre si de forma a detectar e isolar o trecho sob falta no SEE: Agentesde Equipamento, Agentes Móveis, Agentes Protetores e Agentes Reorganizadores. Os Agentesde Equipamento gerenciam dados e funções próprias de cada dispositivo do sistema de prote-ção como Agentes de “Linha”, “Barra”, “Transformadores de Corrente e Tensão (TCs e TPs)”e “Disjuntores (CBs)”. Os Agentes Móveis transitam, através da rede de comunicação, entreos Agentes de Equipamentos para utilizar os dados e funções destes equipamentos. Exemplosdestes agentes são os Agentes “Coletores de TCs e TPS” e de “trips”. Os Agentes Protetoressupervisionam os Agentes Móveis com finalidade de detectar falhas no sistema elétrico. Sãodestacados dois agentes protetores no trabalho em questão, Agentes “Detectores” e “Isolado-res”. Por fim, os Agentes Reorganizadores coordenam a atuação dos demais agentes de acordocom o estado operativo do SEE.
Uma abstração dos “Agentes Relés” propostos por Tomita et al. (1998) é apresentada naFigura 1.1. Basicamente, os Agentes Móveis transmitem os dados de grandezas elétricas (faso-res de corrente e tensão elétrica) dos extremos de um determinado trecho do SEE, provenientedos sensores dos Agentes de Equipamentos (TPs e TCs), até os Agentes Protetores. De acordocom a lógica associada aos Agentes Protetores, caso seja detectada uma condição de falta, osAgentes Móveis transmitem uma mensagem de trip aos disjuntores associados pelo trecho emquestão. Os Agentes Reorganizadores coordenam os Agentes Móveis e os Agentes Protetoresde acordo com a topologia do SEE, separando o sistema em diversas zonas de proteção.
BA
Equivalente Equivalente
Agentes de
Equipamento
Agente TC Agente TP
Agente CB
Comunicação
Agentes de
Equipamento
Agente TC Agente TP
Agente CB
Agente móvel
Agente
reorganizador
Agente
Protetor
Agente móvel
CBCB
TC TC
TP TP
Figura 1.1: Conceito de Agentes Relé no trabalho de Tomita et al. (1998).
Assim como a operação supracitada, demais esquemas de operação para proteção de reta-guarda e adaptativa são descritas no trabalho em questão e novas filosofias podem ser propostasutilizando-se desta abordagem. Segundo os autores, o emprego de “agentes relé” em Sistemasde Proteção assegura que SEEs possam operar mantendo confiabilidade e seletividade, aumen-tando a eficiência dos esquemas de proteção tradicionais.
5
No entanto, para que os sistemas de proteção de SEEs baseados em SMAs possam assu-mir esse papel importante nos sistemas elétricos reais, faz-se necessário a avaliação de formaadequada da capacidade desse novo paradigma para provimento desses em serviços em temporeal e com confiabilidade, visando manter a operação adequada dos SEEs. Porém, estas ques-tões práticas de implementação e operação dos SMAs, assim como os requisitos do sistemade comunicação não foram discutidos pelos autores. Além disso, a discussão superficial rela-tiva à implementação e validação dos SMAs nos outros trabalhos revisados indicam que estaabordagem ainda está em um patamar inicial de desenvolvimento.
Tais fatores indicam a necessidade de uma abordagem que sistematize o procedimento deprojeto e validação de Sistemas de Proteção baseados em técnicas de IA, como é o caso dosSMAs. A relevância dos estudos propostos pela comunidade científica na área de operação econtrole distribuído e as recentes contribuições técnicas/científicas na área da Ciencia da Com-putação apontam esta linha de pesquisa como essencial para implementação do novo paradigmados Sistemas de Proteção, principalmente no âmbito do comportamento determinístico (opera-ção lógica e temporal) do controle das novas estratégias de proteção (Sengupta et al., 2015a).
É nesse contexto que o tema desta pesquisa finalmente se inclinou para a criação de umainfra-estrutura necessária para validação dos Sistemas de Proteção. Uma vez definida estainfra-estrutura, garante-se o projeto efetivo e correta validação de desempenho dos sistemasde proteção com controle distribuído através de uma abordagem sistemática e formal, tantopara sistemas baseados em esquemas tradicionais, quanto em técnicas de Inteligência Artificial.
A seguir, apresenta-se como motivação da linha de pesquisa as lacunas técnicas/científicasexistentes no processo de especificação, projeto e validação de Sistemas de Proteção, evidenci-ando as principais contribuições e o produto desta dissertação. Destaca-se também o crescenteemprego da técnica de modelagem e verificação formal como ferramenta de suporte à área deproteção de sistemas elétricos.
1.2 Motivação
Da revisão bibliográfica realizada na sub-área de Aplicações de SMAs em SEEs, identifica-se que a justificativa e os benefícios do emprego deste paradigma já estão fortemente con-solidados na literatura, tal que um grupo de pesquisa no IEEE (IEEE Multi-Agent Systems -MAS Working Group) atualmente desenvolve diversas atividades de pesquisa vinculadas à área(McArthur et al., 2007b; McArthur et al., 2007a).
No entanto, dos trabalhos revisados até o momento na área em questão e pela experiên-cia da equipe técnica do Lasse na área de validação destes sistemas, nota-se que as estratégiasde proteção baseadas neste novo paradigma (em sistemas distribuídos como um todo), emboramais sofisticadas, não são implementadas em sistemas elétricos reais, e quando implementadas,
6
funcionam sobrepostas aos esquemas tradicionais. Isto deve-se, provavelmente, à falta de pre-missas técnicas no âmbito da avaliação de desempenho e comportamento das novas filosofiasde proteção.
A adequação das funcionalidades propostas pelos atuais trabalhos na área de Sistemasde Proteção levanta questões importantes sobre estrutura, planejamento e operação dos SEEs.Características como interoperabilidade e livre alocação de funções, necessários para gerenci-amento de dados no novo cenário dos sistemas elétricos, e o aumento da complexidade dastarefas envolvidas na área de sistemas elétricos demandam ferramentas que também possuemcapacidade de operação e processamento distribuído.
A bibliografia consultada indica a necessidade de uma abordagem formal que sistema-tize o projeto e validação dos Sistemas de Proteção (Rondon, 2012; Khurram et al., 2013; Si-queira, 2014; David et al., 2015). Em geral, a prática comum para a garantia da confiabilidade ecorreção destes sistemas é através de simulações computacionais envolvendo diversos cenários(cases) de operação e distúrbios. A validação do sistema é então realizada pela comparaçãodo desempenho, mediante aos casos considerados, com os requisitos previamente estabeleci-dos durante a fase de projeto. Ainda que algumas técnicas permitam a geração dos cenáriosde forma automática e estocástica, como por exemplo Monte Carlo, a desvantagem deste tipode abordagem está no fato de não conseguir representar todas as possibilidades de evolução decomportamento do sistema em análise (Dai et al., 2014). Embora seja considerado um númerosignificativamente alto de testes, não há garantia formal de que o sistema apresente comporta-mento indesejável logo em sua primeira atuação em campo, além de que a análise manual dosresultados se torna impraticável a medida em que se eleva o número de dados gerados.
Isto decorre do fato de que a abordagem baseada em simulações mostra apenas uma daspossíveis soluções para a evolução do sistemas em determinadas condições e em um intervalodelimitado de tempo. Ainda, sistemas em que a sua condição inicial não é conhecida, seucomportamento depende de interações com o ambiente exterior, e/ou o objetivo da análise nãose restrinja apenas a um determinado intervalo de tempo, sua simulação nem sempre é efetivapara garantir seu comportamento desejado (Villani, 2004).
Este é o caso típico dos SEEs, incertezas entre a carga e geração de energia elétrica dificul-tam o estabelecimento da condição inicial do sistema (ponto de operação), a quantidade elevadae variabilidade dos eventos como variações de cargas e geração, chaveamento de elementos darede (abertura desejada ou não de circuitos, entrada de cargas/geração, etc), distúrbios (posição,tipo e duração do distúrbio na linha de transmissão, etc) mostram que o comportamento do sis-tema dependa de vários fatores e, no contexto do intervalo de tempo, os sistemas estão sujeitosaos distúrbios supracitados em qualquer instante durante seu funcionamento.
Tratando-se ainda de sistemas de tempo real críticos, como é o caso dos Sistemas deProteção, o projeto (tanto hardware, quanto software) deve ser elaborado de forma com que setenha uma resposta apropriada para qualquer tipo de entrada em qualquer instante de tempo,
7
sendo a confiabilidade e o determinismo temporal destes sistemas requisitos indispensáveis aoseu funcionamento (Kunz, 2012).
Nesse contexto, os atuais métodos computacionais de proposição e validação dos Siste-mas de Proteção deverão ser atualizados para o novo paradigma dos sistemas elétricos, princi-palmente no âmbito da análise de confiabilidade das novas estratégias. Além disso, a criticidadetemporal imposta aos SEEs e a característica distribuída inerente ao novo paradigma dos siste-mas elétricos demandam ferramentas com suporte a sistemas concorrentes de tempo real.
O termo tempo real empregado na descrição dos Sistemas de Proteção neste trabalhoutiliza-se no sentido consagrado na Ciência da Computação no âmbito de sistemas de tempo real“determinísticos” ou “críticos” (no inglês, hard real-time) (Kunz, 2012). Já o termo “concor-rente” é empregado para definir que estes sistemas são executados por vários processos (equi-pamentos) de forma simultânea, independentes e com compartilhamento de recursos.
Recentes estudos demonstram o crescente interesse em metodologias e ferramentas quevisam o projeto efetivo de sistemas complexos, minimizando o trabalho relacionado à garan-tia da “correta” especificação durante o ciclo de desenvolvimento destes projetos (Kunz, 2012;Rondon, 2012; Siqueira, 2014; Sengupta et al., 2015a; Mahmood et al., 2016). Dentre estasferramentas, destaca-se o emprego da análise formal, que consiste na verificação (prova) depropriedades do modelo. Diferente da abordagem baseada em simulações e testes, não são evi-denciados necessariamente a variável tempo ou determinada interação com o ambiente. Logo,se os requisitos relacionados ao comportamento do sistema são traduzidos em propriedades, averificação destas propriedades garante a ausência de erros (comportamentos inesperados) sobas mais diferentes circunstâncias de operação do sistema (Campos & Machado, 2009).
O termo “análise formal” corresponde a uma porção de técnicas para verificação automá-tica de sistemas, como uso de simetrias, redução de ordem parcial, representação e manipula-ção simbólica de espaço de estados, verificação de modelos, prova de teoremas, dentre outras(Wang, 2006). Porém, as duas últimas (verificação de modelos e prova de teoremas) são asferramentas mais populares na literatura. A prova de teoremas (Theorem Proving) consiste eminferir (ou contradizer) uma propriedade através de regras lógicas da matemática. Para isso, ocomportamento do sistema deve ser descrito através de regras e axiomas.
Já a técnica de verificação de modelos (Model Checking) consiste na exaustiva exploraçãode todos os comportamentos possíveis do modelo. As propriedades são descritas em lógicastemporais e a técnica de verificação consiste na validação (ou não) destas propriedades paratodos os estados possíveis do modelo. A principal desvantagem deste tipo de abordagem, estána eventual “explosão de estados” em modelos mais complexos. Portanto, esta ferramentaé restrita apenas em modelos de estados finitos. No trabalho em questão, adota-se o termo“verificação formal” como referência à técnica model checking.
8
O uso da verificação formal exige que o sistema a ser avaliado seja modelado através deuma linguagem de especificação precisa e não ambígua. Logo, a escolha do formalismo ade-quado para a representação de uma realidade específica não é uma tarefa trivial e depende dediversos fatores que são estabelecidos de acordo com o grau de realismo entre o modelo e ocomportamento físico ideal abordado no estudo. Isto implica que o modelo deve representar demaneira fidedigna o possível comportamento da realidade de acordo com o que se deseja avaliar,sem comprometer a verificação formal por incoerências tanto por questões de modelos simples(que não consideram os comportamentos desejáveis) quanto por questões de modelos comple-xos, comprometendo-se a análise por escassez de recursos computacionais (Kunz, 2012).
Nesta dissertação, os Sistemas de Proteção serão abordados sob uma abstração de Siste-mas Dinâmicos a Eventos Discretos (SDEDs), ou seja, um sistema orientado a eventos cujosestados são representados por variáveis discretas que são modificadas ou evoluem de acordocom a ocorrência de eventos discretos. Diversas abstrações podem ser empregadas no forma-lismo destes sistemas, como por exemplo, Redes de Petri (e suas variações), Grafcet, SistemasCondição/Evento, Autômatos Finitos (e suas variações) e Modelos Algébricos (Cassandras &Lafortune, 2010).
De modo geral, a modelagem do sistema de proteção sob uma abstração de SDEDs énaturalmente justificada pela ocorrência síncrona e assíncrona de eventos discretos que, emsequência específica, levam o sistema a um estado pré-determinado. Por exemplo, a ocorrênciade um distúrbio em determinado trecho do sistema elétrico é identificada por um relé, que porsua vez envia um comando de trip aos disjuntores associados ao trecho em questão, isolando otrecho que estava sob defeito.
Dentre os formalismos utilizados para modelagem de SDEDs citados, destacam-se osAutômatos de Estados Finitos (AEF) e as Redes de Petri (RP), principalmente por serem os maisutilizados para esta finalidade (Villani, 2004). Os dois formalismos representam explicitamentea estrutura de transições entre estados de SDEDs. Em AEFs, isto é feito enumerando-se osestados e conectando-os através possíveis transições (eventos). Já em RP, em vez de enumeraros estados, a informação do estado é “distribuída” entre um conjunto de posições que captamas condições chaves (fichas) que governam o comportamento do modelo.
Com relação à escolha do formalismo, considerando a abordagem clássica entre AEFe RP, os AEFs são mais eficientes quanto à modelagem de sistemas que apresentam grau decomplexidade significativo (número elevado de elementos e/ou interações) principalmente pelacaracterística inerente de componentização e decomposição do sistema em sub-sistemas, per-mitindo a modularização do problema de análise. Além disso, em termos de implementação dealgoritmos, a tradução dos modelos desenvolvidos para máquinas de estados (Mealy ou Moore)é mais natural tratando-se da linguagem baseada em AEFs (Cassandras & Lafortune, 2010).
9
Considerando as características e vantagens que os AEFs apresentam para a modelagemde diversos sistemas como uma abstração a SDEDs, o presente trabalho explora o potencialdeste formalismo através de uma metodologia para análise de Sistemas de Proteção com Con-trole Distribuído. O formalismo adotado será baseado em “Autômatos Temporizados Híbri-dos"(ATHs), que consiste em uma extensão dos AEFs capazes de representar também variáveiscontínuas.
As características que levaram a escolha deste formalismo para representação do Sistemade Proteção deve-se principalmente pela necessidade de se representar o tempo como uma va-riável cujo valor depende das características do sistema. Além disso, o próprio framework(UPPAAL STRATEGO2 ) (David et al., 2015) utilizado na modelagem, simulação e verificaçãodos modelos considera o modelo como híbrido apenas pela declaração e manipulação de va-riáveis de ponto flutuante e em operações envolvendo a taxa de atualização dos relógios domodelo.
Como resultado, permite-se a implementação de funções não determinísticas para repre-sentação do comportamento de determinados modelos, como por exemplo a representação dedelay no sistema de comunicação e Tempo Médio entre Falhas (MTBF) em modelos de falhasde componentes. Além da representação da dinâmica do sistema através de equações diferenci-ais, como é o caso do comportamento das variáveis associadas ao sistema elétrico.
No entanto, a inclusão de variáveis contínuas ao formalismo introduz um problema denão-decidibilidade à rede de autômatos, uma vez que não é possível representar a evolução docomportamento do sistema através de um número finito de estados. Logo, o emprego de técnicasde verificação formal clássicas não são eficazes para validação dos modelos desenvolvidos sobreo formalismo de ATHs. Como solução a este problema, propõe-se o emprego da verificaçãoformal estatística, na qual permite a verificação da probabilidade de determinada propriedadeser verdadeira em um intervalo de tempo.
É importante salientar que a classificação em sistema discreto ou híbrido é referente aabstração de determinada realidade e não uma propriedade da realidade em si. Um mesmosistema pode ser modelo em abstrações de diversas classes. Por exemplo, a atuação da funçãode proteção de uma SEEs pode ser modelada como um sistema discreto, sendo a dinâmica regidapor relações de causa e efeito quando a falta é aplicada. No modelo discreto, um sinal de tripdeve ser gerado (instantaneamente ou temporizado) após a identificação de uma falta pelo relé.Este mesmo sistema pode ser modelado através de um sistema híbrido, sendo a dinâmica dasvariáveis elétricas regidas pelas equações diferenciais do sistema elétrico. Neste caso, verifica-se a excursão das variáveis monitoradas pelo sistema de proteção e, então, gera-se um sinal detrip.
2Disponível em http://people.cs.aau.dk/ marius/stratego/
10
Detalhes acerca do emprego da verificação formal aos sistemas de proteção serão dis-cutidos ao longo da dissertação, porém, como motivação, cita-se a comparação das diferentesabordagens (simulação e verificação formal) em um exemplo simples envolvendo a operaçãode um relé em um sistema de proteção.
Suponha a linha de transmissão (LT) protegida pelo relé descrito na Figura 1.2. O compor-tamento esperado do sistema no exemplo em questão é apenas a geração correta de comandosde trips pelo relé, devido a ocorrência de alguma situação de falta. Para o estudo em questão,não faz-se necessário a modelagem de qual função de proteção o relé está operando. Nos ca-pítulos referentes à modelagem mais específica do relé, serão abordadas funções de proteçãocomo sobrecorrente e impedância.
Eq.R
:d
d
P
QC
CB
:g
g
P
QG
:d
d
P
QC
d
1
2
3:
F
g
g
Z
F
? ?
??
?
Figura 1.2: Validação de desempenho em Sistemas de Proteção via simulações.
Segundo a abordagem baseada em simulações, a análise de desempenho do relé seria rea-lizada através da aplicação de faltas em diversos cenários envolvendo a variação dos parâmetrosdestacados com o sinal de interrogação na Figura 1.2. A validação do sistema de proteção seriaentão feita pela análise dos trips gerados pelo relé em função da falta aplicada em cada cenáriode simulações. Na identificação de uma atuação incorreta do sistema de proteção, o projetistaavalia o cenário cujo comportamento não seja o esperado e, após o reajuste da parametrizaçãodo relé, uma nova bateria de testes é necessária. Caso não seja detectada nenhuma incoerêncianos resultados, o sistema de proteção é dito como corretamente parametrizado. No entanto, con-forme abordado anteriormente, pode haver um cenário de operação que leve o comportamentodo sistema de proteção à um erro de operação e que não foi considerado nos testes realizados.
Já segundo a abordagem baseada em verificação formal, o sistema de proteção seria des-crito através de uma linguagem formal, como por exemplo AEFs. A validação do sistema deproteção seria então realizada por meio da verificação de propriedades de acessibilidade e se-gurança do modelo. Esta abstração é apresentada na Figura 1.3.
A verificação da ocorrência de deadlock no modelo é representada através da Figura 1.3.a.Esta propriedade indica se a o modelo desenvolvido apresenta alguma sequência de eventos queleve o modelo a uma condição de intertravamento.
Na Figura 1.3.b é apresentada a verificação de propriedade associada a acessibilidade dedeterminado estado desejável ao modelo. Um exemplo de verificação nesse sentido poderiaser: “Sempre que houver uma condição de trip, o relé está em uma situação de falta?”, ou “É
11
possível a geração de um sinal de trip em um intervalo menor do que X ms após a ocorrênciade uma falta?”. No contexto da verificação formal estatística, as mesmas perguntas (descritasanteriormente) seriam verificadas no modelo, porém, incluindo o termo “Qual é a probabilidadedo evento X acontecer em um intervalo de tempo menor do que Y segundos”.
(a) (b)
Figura 1.3: Validação de desempenho em Sistemas de Proteção via Análise Formal: a)ocorrência de deadlock; b) acessibilidade de estado marcado.
De um modo geral, esta seria a aplicação da modelagem e verificação formal de sistemascríticos aos Sistemas de Proteção. No entanto, conforme será abordado na próxima subseção,esta dissertação possui foco apenas na modelagem dos principais componentes pertencentesaos Sistemas de Proteção. O conceito de modelagem e verificação formal é então aplicadoindividualmente sobre cada componente.
1.3 Objetivos
Em resposta ao aumento da complexidade de operação dos SEEs e à necessidade de me-todologias mais sofisticadas para a análise de Sistemas de Proteção, principalmente em relaçãoàs expectativas de segurança e confiabilidade, este trabalho propõe o emprego da técnica demodelagem e verificação formal estatística como ferramenta de suporte ao projeto, simulação,validação e implementação de novas estratégias para tal.
Da revisão de trabalhos relacionados a este tema, apresentada no Capítulo 2, identificou-se três áreas possíveis onde a ferramenta de modelagem e verificação formal possa ser integradaem uma metodologia sistemática de desenvolvimento em Sistemas de Proteção, a saber: i) naetapa que antecede a implementação do controle da nova estratégia de proteção proposta, ondeos modelos que representam o sistema do controle, já verificados formalmente, são traduzidosem uma linguagem de programação apropriada; ii) na etapa de testes de desempenho da estra-tégia proposta, sendo a rede de autômatos (composição de todos os modelos) a representaçãodo algoritmo de controle da estratégia juntamente com os elementos físicos, a verificação daspropriedades do modelo representam o funcionamento global da estratégia; e iii) em testes deconformidade em equipamentos individuais, onde algum modelo da rede de autômatos que re-presenta a estratégia, é substituído por um equipamento físico real, com finalidade de avaliar oseu comportamento juntamente com a rede de autômatos.
12
Salienta-se que este trabalho se delimita apenas na construção e validação dos modelosque representam o sistema de proteção. As metodologias supracitadas podem ser caracterizadascomo pesquisas futuras, nas quais poderão utilizar os modelos aqui desenvolvidos. Na Figura1.4 é apresentado o escopo de pesquisa desta dissertação. A estrutura ilustrada pela figura emquestão foi elaborada com base nos trabalhos (Sengupta et al., 2015a; Kunz, 2012; Rondon,2012; Siqueira, 2014; Villani, 2004), discutidos no próximo capítulo.
Especificação
Informal
REQUISITOS DO
SISTEMA DE
CONTROLE
INFORMAÇÕES
SOBRE O
SISTEMA FÍSICO
Especificação
Formal
MODELO DO
SISTEMA DE
CONTROLE
MODELO DO
SISTEMA FÍSICO
Verficação
MODELO DO
SISTEMA DE
CONTROLE
MODELO DO
SISTEMA FÍSICO
Implementação
SISTEMA DE
CONTROLE
Modelagem Análise
Implementação do
controle da estratégia
proposta
DELIMITAÇÃO DA LINHA DE PESQUISA DESTA DISSERTAÇÃO
METODOLOGIA DE PROPOSIÇÃO E AVALIAÇÃO DE SISTEMAS DE PROTEÇÃO
IED, CLP, PROCESSADOR
Validação
SISTEMA DE
CONTROLE
Testes de desempenho
da estratégia proposta/
Identificação de erros
no projetoRTDS
Testes de Conformidade
SISTEMA DE
CONTROLESISTEMA
FÍSICO
EQUIPAMENTOS REAIS
Externalização de
modelos para testes
de conformidade em
equipamentos reais
LINHAS DE PESQUISAS FUTURAS
Figura 1.4: Delimitação da linha de pesquisa
Baseado nesse contexto, o objetivo geral deste trabalho consiste na modelagem e valida-ção dos principais dispositivos empregados em Sistemas de Proteção com Controle Distribuídoatravés de Autômatos Temporizados Híbridos. Dentro deste objetivo geral, cita-se os seguintesobjetivos específicos:
• Desenvolver os modelos dos principais dispositivos e protocolos empregados no funci-onamento dos Sistemas de Proteção com Controle Distribuído, segundo a abstração deAutômatos Temporizados Híbridos;
• Estudo e implementação dos principais modelos probabilísticos empregados em estudosde confiabilidade de sistemas de tempo real críticos, segundo abstração de AutômatosTemporizados Híbridos;
• Estudo e implementação dos principais modelos matemáticos para representação de sis-temas elétricos dinâmicos, segundo a abstração de Autômatos Temporizados Híbridos;
• Formalizar as propriedades comportamentais desejáveis aos modelos através de lingua-gem formal, de modo a ser aplicado a ferramenta de verificação formal estatística; e
13
• Aplicar metodologia de análise baseada na técnica de verificação formal estatística deforma a validar os modelos desenvolvidos.
1.4 Metodologia
A metodologia de pesquisa adotada neste trabalho consistiu, primeiramente, na revisãobibliográfica no tema principal desta dissertação, ao qual envolve: Sistemas de Proteção comControle Distribuído, técnicas de validação de Sistemas de Tempo Real Críticos, formalismospara modelagem de SDEDs e aplicativos de modelagem, simulação e verificação de autômatostemporizados híbridos. Tendo como suporte a teoria supracitada, iniciou-se a construção evalidação dos modelos como descrito a seguir.
As características construtivas e operacionais dos principais dispositivos empregados emsistemas de proteção foram levantadas por meio de estudos de artigos científicos, livros, rela-tórios de agências nacionais e internacionais vinculadas ao setor elétrico e materiais fornecidospor fabricantes de equipamentos.
A dinâmica associada aos dispositivos eletromecânicos, assim como as incertezas e errosinerentes envolvidos nos processos de amostragem e transmissão de sinais elétricos que afetamos sistemas de proteção foram consideradas nos modelos propostos. Tais funcionalidades foramdesenvolvidas e validadas de maneira genérica, de modo com que os modelos possam ser utili-zados, em estudos futuros, com parâmetros reais de equipamentos fornecidos por fabricantes edemais estudos da área.
A modelagem dos equipamentos e das estratégias de proteção basearam-se em estudos denormas e livros. Como exemplo de algumas normativas consultadas para auxílio da modelageme estudo dos Sistemas de Proteção, cita-se:
• IEC 61850, “Communication Networks and Systems in Substations”;• IEEE 1588, “IEEE Standard for a Precision Clock Synchronization Protocol for Networ-
ked Measurement and Control Systems”;• IEEE Std 1046 - “IEEE Application Guide for Distributed Digital Control and Monito-
ring for Power Plants”;• IEEE Std 242 - “IEEE Recommended Practice for Protection and Coordination of Indus-
trial and Commercial Power Systems”• IEEE C37.91 - “IEEE Guide for Protective Relay Applications to Power Transformers”;• IEEE C37.97 - “IEEE Guide for Protective Relay Applications to Power System Buses”• IEEE C37.102 - “IEEE Guide for AC Generator Protection”;• IEEE C37.113 - “IEEE Draft Guide for Protective Relay Applications to Transmission
Lines”;
14
As análises conclusivas a respeito da validação dos modelos foram realizadas com basena fundamentação teórica, juntamente com os resultados obtidos através da metodologia apre-sentada no Capítulo 3.
1.5 Estrutura da Dissertação
No Capítulo 2 são apresentadas as bases teóricas necessárias ao entendimento dos con-ceitos que compreendem o restante do trabalho. Em síntese são apresentados conceitos comoSistemas de Proteção com Controle Distribuído, IEC 61850, Sistemas de Tempo Real Críticos,Protocolo de Sincronização de tempo PTP, formalismo baseado em Autômatos TemporizadosHíbridos e Verificação Formal Estatística. Através destes conceitos, justifica-se a abordagemdos Sistemas de Proteção com Controle Distribuído através de Autômatos Temporizados Híbri-dos.
Com base na teoria e contextualização do Capítulo 2, o Capítulo 3 detalha a soluçãoproposta no trabalho para construção e validação dos modelos. A arquitetura básica do sis-tema de proteção e seus principais equipamentos também são abordados neste capítulo. Alémdisso, o capítulo apresenta o aplicativo de modelagem, simulação e verificação formal estatís-tica adotado no trabalho, o UPPAAL STRATEGO e, através de um exemplo simples, destaca aimportância desta metodologia como suporte à validação de Sistemas de Proteção. No capí-tulo também é apresentada a implementação dos modelos de distribuição de probabilidade noUPPAAL STRATEGO.
O desenvolvimento e validação dos modelos que representam os dispositivos dos Sis-tema de Proteção é apresentado no Capítulo 4. No capítulo, são apresentadas as simulações everificações aplicadas aos modelos, de acordo com a metodologia proposta no Capítulo 3.
Por fim, no Capítulo 5, apresenta-se as conclusões e contribuições do trabalho, assimcomo propostas para o desenvolvimento de trabalhos futuros.
Capítulo 2
Fundamentação Teórica
A linha de pesquisa abordada por esta dissertação aponta para o estudo da técnica de Veri-ficação Formal como ferramenta de suporte a validação de Sistemas de Proteção com ControleDistribuído. Nesse contexto, no capítulo em questão é apresentada a fundamentação teóricanecessária ao entendimento dos conceitos que compreendem esta abordagem. Salienta-se queo objetivo do capítulo é apenas fornecer uma base teórica dentro do contexto de aplicação dotrabalho e para uma revisão mais detalhada sugere-se como leitura os próprios trabalhos citadosao longo do texto.
Dentro do escopo do trabalho, a revisão é iniciada pelo contexto da evolução dos Sistemasde Proteção de Sistemas de Energia Elétrica, compreendendo basicamente a nova característicade operação e controle imposta pela norma IEC 61850. Na sequência, discute-se os principaisaspectos relativos à abordagem da Verificação Formal, como adoção do formalismo de apoioà etapa de modelagem e especificação das propriedades. Além disso, discute-se o aplicativoUPPAAL STRATEGO, onde serão desenvolvidos os modelos do sistema de proteção. Por fim,apresenta-se os principais trabalhos que contribuíram para a especificação do tema da disserta-ção.
2.1 Evolução dos Sistemas de Proteção de Sistemas de Ener-gia Elétrica
Os Sistemas de Energia Elétrica (SEEs) têm como função principal o atendimento e forne-cimento de energia elétrica ininterrupta e com qualidade adequada aos seus usuários (John Grain-ger & Stevenson, 1994). Devido à sua complexidade, o SEE é subdivido basicamente em sub-sistemas de geração, transmissão, subtransmissão e distribuição. Porém, fatores como desequi-líbrio entre o crescimento na demanda por energia elétrica e o investimento no sistema elétrico(em todos os segmentos) e restrições (técnicas, ambientais e econômicas) mais rígidas colabo-ram para que a operação dos SEEs esteja próxima a seus limites (Li et al., 2005). Além disso,a quantidade crescente de conexões de Unidades de Geração Distribuída (UGDs) e o aumento
15
16
de cargas não lineares nas indústrias alteram a característica do fluxo de potência nos sistemasde transmissão (ou subtransmissão) e distribuição, interferindo de maneira prejudicial em suaoperação (Kojovic, 2002; Kauhaniemi & Kumpulainen, 2004).
Para que os sistemas supracitados operem dentro dos padrões de segurança, qualidade,confiabilidade e continuidade definidos pelos órgãos que regulamentam suas concessões, di-versas estratégias de operação, controle e proteção são empregadas pelas concessionárias queatuam nos setores de energia elétrica.
A linha de pesquisa deste trabalho se concentra nos Sistemas de Proteção dos SEEs, maisespecificamente no segmento de transmissão, cujo principal objetivo é proporcionar, da formamais rápida e segura possível, o isolamento de um equipamento, área ou região em falha, fa-zendo com que o restante do sistema elétrico continue em operação. Em síntese, estes sistemassão projetados para atender principalmente a três funções, i) proteção de seres humanos; ii) iso-lação mais rápida possível de uma falha após a sua ocorrência; e iii) proteção dos equipamentosdo sistema elétrico (IEEE, 2001).
A evolução tecnológica, principalmente no âmbito da globalização, forçou a abertura demercados e estimulou a competitividade entre os agentes do setor elétrico, onde a eficiência tec-nológica se apresenta como chave fundamental para atuação neste cenário (Rondon, 2012). Ali-ado a este fator, avanços tecnológicos nas mais diversas áreas do conhecimento, principalmentena área da Ciência da Computação, têm aumentado a complexidade das tarefas envolvidas naoperação dos SEEs.
Os problemas técnicos decorrentes das novas características do setor elétrico podem com-prometer a confiabilidade dos Sistemas de Proteção empregados atualmente (Li et al., 2005; Liuet al., 2012). Diversas filosofias e estratégias de proteção de SEEs estão sendo propostas pelacomunidade científica da área em questão de forma a garantir a confiabilidade dos sistemas deproteção (Li et al., 2012). Em geral, estas novas estratégias se enquadram no conceito de redesinteligentes (no inglês, smart grids), no qual propõe-se a implementação de uma “camada de in-formação” ao sistema elétrico que proporcione funcionalidades que auxiliem no gerenciamentodo sistema em si, permitindo que o próprio sistema execute tarefas como controle, proteção, re-configuração, acompanhamento da demanda e consumo de energia elétrica, redução de perdas,entre outras (Cecilia & Sudarsanan, 2016).
Embora este tema esteja atualmente presente na discussão dos principais eventos científi-cos da área de SEEs, a revisão bibliográfica, citada na subseção de contextualização do Capítulo1, indicou vários trabalhos que já discutiam as funcionalidades das smart grids desde a décadade 90, porém o termo smart grid ainda não era empregado.
Neste conceito, os relés digitais, que apesar de serem dispositivos sofisticados passíveis deimplementação de estratégias inteligentes são atualmente empregados de maneira tradicional,evoluem para os dispositivos eletrônicos inteligentes (IEDs, do inglês Intelligent Electronic
17
Device), com caráter multifuncional relacionado não apenas à função de proteção, mas tambémcom capacidade de comunicação com os demais dispositivos da subestação, compartilhandoinformações de monitoramento e controle, além de integrar estas funções distribuídas sobreuma rede local. Dessa forma, os Sistemas de Proteção começam a apresentar arquitetura decontrole descentralizado, no qual características como coordenação e cooperação tornam-seessenciais para o seu pleno funcionamento (Laaksonen & Suomi, 2013; Isa et al., 2015).
Como infraestrutura de comunicação, tais trabalhos apresentam a premissa da utilizaçãode sistemas de comunicação Ethernet nas subestações de SEEs. A adequação destas funcio-nalidades levanta questões importantes sobre estrutura, planejamento e operação do sistema deproteção, uma vez que este tipo de interligação acrescenta mais um aspecto a ser avaliado du-rante o funcionamento do sistema de proteção, que é o atraso de tempo inerente na comunicaçãodos dados.
Um importante instrumento que pode contribuir para a implementação destas estraté-gias é o conjunto de normas técnicas IEC 61850 – “Redes de Comunicação e Sistemas emSubestações”, nas quais, dentre as demais funcionalidades, propõem uma arquitetura de co-municação única entre os diversos dispositivos digitais em uma subestação de energia elétrica,independente da função que estes exerçam na subestação ou de seus fabricantes, permitindoatravés do compartilhamento de informações a interoperabilidade e livre alocação de funções(Igarashi, 2011).
Esta norma se apresenta como uma ferramenta bastante promissora e fundamental parasuperar os desafios impostos pelo novo paradigma dos SEEs, pois possibilita o emprego defuncionalidades até então não disponíveis nos protocolos convencionais.
Nesse contexto, adota-se a estrutura de Sistemas de Automação de Subestações (SAS)proposta pela norma IEC 61850 na modelagem do sistema de proteção realizada nesta disserta-ção. Dentro do escopo do trabalho, a seguir são apresentados os principais aspectos da norma.
2.1.1 Protocolo IEC 61850
O atual cenário de operação e gerenciamento de dados dos SEEs demandam aos Sistemasde Proteção uma arquitetura de controle descentralizada, composta por dispositivos distribuídosao longo das instalações elétricas. Características como interoperabilidade e livre alocação defunções se tornam essenciais para o pleno funcionamento destes sistemas.
No entanto, os Sistemas de Proteção tradicionalmente baseados em circuitos cabeadospossuem diversas limitações em requisitos operacionais como modularidade, escalabilidade einteroperabilidade entre equipamentos de diferentes fabricantes, além da quantidade excessivade cabeamento, relés auxiliares e conversores de protocolos, elevando-se o custo e complexi-dade de instalação (Machado, 2015).
18
A norma IEC 61850 foi então proposta para suprir essa lacuna através da criação de umpadrão que permite a integração entre todos os dispositivos do SAS, a partir da especificação dosrequisitos do sistema de comunicação, características funcionais, estrutura e nomenclatura dedados e serviços, além de propor uma solução unificada para as interações entre controladoresdos dispositivos e como devem ser testados para avaliação da conformidade do sistema (Kunz,2012).
A norma consiste de uma série documentos agrupados em 10 partes, conforme apresen-tado pela Tabela 2.1. Na tabela em questão, apenas constam os documentos atualizados atéo ano de 2013. Uma série de novos documentos (2015/2016) associados à IEC 61850 já es-tão disponíveis, no entanto, pelo escopo do trabalho e pela falta de acesso à estes, não serãodiscutidos.
Dentro do contexto de aplicação desta dissertação, primeiramente cita-se a estruturaçãodo SAS recomendada na parte #5 da norma. Esta segmentação é indicada como segue:
• Nível de Estação: o Nível de Estação (Station Level) é abordado na IEC 61850-8 e defineo mapeamento das camadas de comunicação TCP/IP. Este é o nível superior dentro dasubestação, onde situam-se a Interface Homem-Máquina (IHM), equipamentos de tele-comunicações, base de dados do sistema de automação e outros;
• Nível de Vão: o Nível de Vão (Bay Level) é definido na parte #7 da norma. Ela defineo modelo de dados e aplicação das funções do sistema. Neste nível se encontram osequipamentos de proteção, automação e controle;
• Nível de Processo: o Nível de Processo (Process Level), parte #9, define a transmissãodos valores analógicos de tensão e corrente dos transformadores de instrumentação e dosprotocolos de mensagens com requisitos de tempo real entre os equipamentos. Este é onível mais baixo no qual situam os sensores e atuadores.
19
Tabela 2.1: Estrutura da norma IEC 61850 até o ano de 2013.
Característica Parte Descrição Edição
Aspectos do Sistema
#1 Introdução e visão geral 2.0 (03/2013)#2 Glossário 1.0 (08/2003)#3 Requisitos gerais 1.0 (01/2001)#4 Gerenciamento de sistema e projeto 2.0 (04/2001)
#5Requisitos de comunicação para fun-ções e modelos de dispositivos
2.0 (01/2013)
Configuração #6Linguagem de Configuração para IEDsde subestações
2.0 (12/2009)
Estrutura de comunicação
#7-1 Princípios e modelos 2.0 (07/2011)
#7-2Serviço de Interface de ComunicaçãoAbstrata (ACSI)
2.0 (08/2010)
#7-3 Classe de Dados Comum (CDC) 2.0 (12/2010)
#7-4Classes de Nós Lógicos e dados com-patíveis
2.0 (03/2010)
#7-410As usinas hidroelétricas - Comunica-ção para monitoramento e controle 2.0 (10/2012)
#7-420 Recursos energéticos distribuídos 2.0 (03/2009)
#7-510As usinas hidroelétricas - Conceitos demodelagem e diretrizes
2.0 (03/2012)
Mapeamento de Serviço deComunicação
#8-1Mapeamento para MMS (ISO/IEC9506 Parte 1 e 2) e para ISO/IEC 8802-3
2.0 (07/2011)
#9-2Serviço de Interface de ComunicaçãoAbstrata (ACSI)
2.0 (08/2010)
Ensaios #10 Testes de conformidade 2.0 (12/2012)
#80-1
Orientação para troca de informações apartir de um modelo de dados baseadoem CDC usando IEC 60870-5-101 ouIEC 60870-5-104
1.0 (12/2008)
#90-1Uso da IEC 61850 para comunicaçãoentre subestações
1.0 (03/2010)
#90-4 Diretrizes de engenharia de rede 1.0 (08/2013)
#90-5Uso da IEC 61850 para transmitir in-formações de sincrofasores de acordocom a IEEE C37.118
1.0 (05/2012)
#90-7
Modelos de objeto para conversores depotência em sistemas com RecursosEnergéticos Distribuídos (DER)
1.0 (02/2013)
20
Baseado na estrutura hierárquica de SAS proposto pela IEC 61850, na Figura 2.1 é apre-sentada a estrutura do sistema de proteção adotado nesta dissertação. Ainda na figura em ques-tão, é possível identificar as interfaces e serviços aplicados nesta estrutura. As interfaces (IFs)são destacadas na Figura 2.1 através dos círculos rotulados com números. A descrição destesserviços são definidos por:
• IF1: troca de dados de proteção entre o Nível de Estação e o Nível de Bay;• IF2: troca de dados de proteção entre subestações;• IF3: troca de dados entre dispositivos de um mesmo vão;• IF4: troca de valores amostrados entre Nível de Processo e Nível de Vão;• IF5: troca de dados de controle entre Nível de Processo e Nível de Vão;• IF6: troca de dados de controle entre Nível de Vão e Nível de Estação;• IF7: troca de dados entre Nível de Estação e um ponto de monitoração remota dentro da
mesma LAN;• IF8: troca de dados entre Vãos;• IF9: troca de dados entre dispositivos do Nível de Estação;• IF10: troca de dados de controle entre uma subestação o centro de controle remoto;• IF11: troca de dados entre subestações.
Station Bus (#8)
Power Substation
Station Level
Bay Level
Process Level
Process Bus (#9)
Remote Process Interface Remote Process Interface
PROT. CONTR. PROT. CONTR.
4,54,5
83 3
4,54,5
FCT. A FCT. B
9
1,61,6
2 2
710
Figura 2.1: Níveis e interfaces lógicas de uma subestação em 61850.
21
Além disso, observa-se na Figura 2.1 a definição de dois barramentos de interfaces decomunicação, o Barramento de Estação e o Barramento de Processo. Apesar de que a figuraem questão indique a separação em dois barramentos distintos, salienta-se que esta separaçãoocorre somente para os níveis lógicos hierárquicos e, na prática, se tem apenas um link físicoonde trafegam as informações dos Níveis de Processo, Vão e Estação.
O Barramento de Estação é discutido na IEC 61850-8-1. Nele, estabelece-se a comunica-ção vertical entre os centros de comandos e os IEDs e a comunicação horizontal entre os IEDsdo Nível de Vão, como envio de comandos e bloqueios. Já o Barramento de Processo (IEC61850-9-2) está ligado aos equipamentos primários e de manobra que fazem parte da subesta-ção.
Com relação à estrutura de comunicação, as partes #7-2 e #7-4 da IEC 61850 definemrespectivamente os serviços e os objetos de dados abstratos. Referente à #7-2, define-se o ACSI(do inglês Abstract Communication Service Interface) como um modelo de classe hierárquica,contendo todas as informações que podem ser acessadas e trocadas. O ACSI dispõe das seguin-tes interfaces:
• Interface cliente-servidor, para mensagens de tempo real não críticos;• Interface ponto-a-ponto, para mensagens de tempo real críticos; e• Outros serviços como sincronismo de tempo e transferência de arquivos.
Como o trabalho em questão modela o comportamento da operação do sistema de prote-ção, será dado maior enfoque às interface ponto-a-ponto, pois as funções de proteção utilizam-sedos serviços de transmissão de dados GOOSE (Generic Object Oriented Substation Events) eSVs (sampled values) que esta fornece.
A interface ponto-a-ponto é uma interface abstrata para rápida e confiável distribuiçãode eventos em todo o sistema através da arquitetura publisher/subcriber (editor/assinante), naqual o método publisher (em uma aplicação de um dispositivo) envia as mensagens sem des-tino específico e método subscriber (em muitas aplicações remotas em diferentes dispositivos)somente processa as mensagens de seu interesse.
Na Figura 2.2 destacam-se os serviços mais relevantes para a integração dos IEDs em umSAS. Da figura em questão, observa-se que as mensagens GOOSE e SVs são mapeadas direta-mente na camada Ethernet, logo, elimina-se o acréscimo de tempo à codificação/decodificaçãodestas mensagens ao passar pelas camadas intermediárias.
Para assegurar o desempenho na transmissão de dados em um SAS, indica-se a utilizaçãode VLANs (Virtual Local Area Network), de forma a reduzir eventuais carregamentos na rede.Por serem mapeadas na camada Ethernet, as mensagens GOOSE e SV permitem a inserção deum identificador (tag) dentro do seu quadro de mensagem, o que permite aos dispositivos darede identificar a VLAN da qual o quadro pertence. Desta forma, é possível a criação de grupos
22
lógicos entre IEDs que se encontram fisicamente conectados à mesma rede LAN (Guerrero,2011). Na sequência, apresenta-se os dois principais serviços de transmissão de dados adotadospela IEC 61850 (no âmbito deste trabalho) e suas aplicações nas funções de proteção.
Figura 2.2: Representação simplificada dos protocolos 61850. Fonte: (Liu, 2015).
Mensagens GOOSE
As mensagens GOOSE são mensagens de alta prioridade de transmissão com requisitosde tempo real. A mensagem é pertencente ao modelo GSE (Generic Substation Events), o qualpermite a entrega quase simultânea de uma mesma informação para mais de um dispositivofísico. Estas mensagens são aplicadas em funções de proteção e automação, onde o tempo detomada de decisão é extremamente crítico. Sumariza-se a seguir, as principais característicasde uma mensagem GOOSE:
• A mensagem GOOSE é mapeada diretamente na camada Ethernet da pilha TCP/IP. Asmensagens são do tipo sem conexão, assim, não há verificação de estabilidade de conexãoe nem da confirmação de recebimento dos pacotes enviados. Estas características otimi-zam a decodificação da mensagem no dispositivo receptor, representando menor tempode tratamento e transferência da mensagem;• As mensagens utilizam o método de transmissão multicast dentro de uma VLAN (Virtual
LAN). Nesse método, a mensagem é copiada e enviada de um dispositivo transmissor paraum conjunto específico de receptores (que estão na mesma VLAN);• Como não há verificação de recebimento, a confiabilidade de envio das mensagens é
determinada pelo método de retransmissão das mensagens.
23
Na Figura 2.3 é apresentado o tempo de espera para a próxima retransmissão de dados. Otempo T0 representa a retransmissão da mensagem em condições estáveis do sistema, a normaindica este tempo em 1024 ms. A ausência deste sinal representa uma falha no emissor ouno barramento de comunicação. Na ocorrência de eventos, os intervalos de transmissão vãosendo incrementados exponencial na base 2. O valor de tempo para a próxima retransmissão damensagem é encapsulada ao pacote GOOSE através do parâmetro ttl (time-Allowed-to-live).
T0 (T0) T1 T1 T2 T3 T0
Tempo de transmissão
Evento
T0 - retransmissão em condições estáveis
(T0) - retransmissão em condições estáveis sendo interrompida por um evento
T1 – tempos de retransmissão mais curtos após evento
T2, T3 – incremento de tempo de retransmissão até retornar a uma condição estável
Figura 2.3: Tempo de retransmissão das mensagens GOOSE.
Através do parâmetro lógico GoEna, também encapsulado no pacote GOOSE, o disposi-tivo emissor comunica aos receptores que não haverá a próxima retransmissão de mensagem.Desta forma, o processamento dos receptores não identificam como falha o não recebimento dopacote.
Além dos parâmetros supracitados, outros parâmetros também compõem o pacote GO-OSE. Dentro do contexto de aplicação desta dissertação, destacam-se os parâmetros StNum(State Number) e SqNum (Sequence Number), os quais indicam a ordem das mensagens quesão transmitidas e ocorrência de eventos que alteram o valor da variável transmitida pelo pa-cote (GOOSEData). O parâmetro StNum é utilizado para definir quantas vezes o equipamentomudou de estado. A cada nova atualização, incrementa-se o valor deste parâmetro. Além doincremento do parâmetro StNum, a atualização de uma variável é também determinada pelo pa-râmetro SqNum em valor “0”. Em condições estáveis, o parâmetro StNum permanece inalteradoenquanto SqNum é incrementado de “1” até o valor limite definido na IEC 61850.
Mensagens de valores amostrados SV
As mensagens SVs também são mensagens com restrição de tempo real. Seu funcio-namento básico consiste em amostrar digitalmente a grandeza obtida de transformadores deinstrumentação e transmiti-la digitalmente aos IEDs através do Barramento de Processo.
24
Assim como as mensagens GOOSE, o requisito de tempo nas mensagens SV é alcançadopelo fato destas serem mapeadas diretamente sobre a camada Ethernet do modelo TCP/IP e ado-ção do modelo de comunicação publisher-subscriber, porém, o mecanismo de publicação dasmensagens SVs são diferentes. Enquanto a GOOSE tem caráter não determinístico, dependentedos eventos, as mensagens SV são determinísticas, sendo o envio determinado pela frequênciade amostragem do sinal e pela resolução temporal necessária para a conversão analógica-digital(A/D).
Dentro do contexto de aplicação desta dissertação, os pacotes das mensagens SVs sãoformados essencialmente por campos que identificam o emissor e tipos dos dados a serem trans-mitidos e por um contador de sequência SmpCnt que indica a correta ordem de transmissão dasmensagens. O contador SmpCnt é incrementado de “0” até o valor limite definido na parte #9.2da norma. Além destes parâmetros, um parâmetro SmpRate também é encapsulado ao pacotepara indicação do intervalo de tempo entre o envio das amostras, de forma aos receptores identi-ficarem problemas no recebimento de pacotes devido ao tempo excedido na espera do próximopacote. A interrupção programada no envio das mensagens é indicada pelo parâmetro SvEna.
A implementação das mensagens SV pode ser realizada sob a adoção de transformado-res de instrumentação ópticos, os quais já possuem as saídas das grandezas elétricas de formadigitalizada ou pela implantação de conversores A/D na saída dos transformadores de instru-mentação convencionais. Neste último caso, a montagem do frame SV é realizado por meio deequipamentos Merge Unit (Skendzic & Zweigle, 2007).
Além de especificar elementos de protocolos, a norma IEC 61850 provê um modelo decomo os dispositivos do SAS devem organizar e interpretar os dados e funções associados àsua operação. Esta organização é realizada através de um modelo de orientação a objetos, aqual decompõe as funcionalidades de um objeto real em pequenas entidades. Esta decompo-sição facilita a descrição da interação entre os componentes do sistema e permite o empregodas funcionalidades de livre alocação de funções e interoperabilidade entre IEDs de diferentesfabricantes. Na sequência discute-se os principais aspectos relacionados à esta decomposição.
Modelagem de Dispositivos na IEC 61850
Na Figura 2.4 é ilustrada a organização dos dados baseada na norma IEC 61850 para umdisjuntor. O modelo de dispositivo começa com um dispositivo físico PD (do inglês PhysicalDevice), que como o nome sugere, corresponde ao próprio hardware que é conectado à rede.Este dispositivo é acessado através de um endereço de rede correspondente. Dentro de cadadispositivo físico, podem haver vários dispositivos lógicos LD (Logical Device).
25
Figura 2.4: Processo de virtualização segundo IEC 61850.
Os LDs são agrupamentos de representações das funções que operam em aplicações deproteção, controle e aquisição de dados. A este agrupamento dá-se o nome de nós lógicos LNs(Logical Nodes). Um LN é um agrupamento de dados e serviços associados a alguma função noSAS. Cada LN contém seus respectivos dados organizados em uma classe de dados, definida naparte #7-3 da norma. Por exemplo, um disjuntor é modelado pelo LN XCBR e contém atributoscomo Loc, que indica se a operação é remota ou local, Pos, para indicar posição (aberto oufechado), BlkOpn e BlkCls para comandos de abertura e fechamento respectivamente, entreoutros. Cada Dispositivo Lógico indica o grupo de Nós Lógicos que estão inseridos em suafuncionalidade conforme apresentado na Tabela 2.2. Os atributos de cada Nó Lógico da Tabela2.2 são descritos na parte #7.4 da IEC 61850.
Tabela 2.2: Categorias dos nós lógicos.
Grupo Função Grupo FunçãoA Controle Automático P ProteçãoC Controle Supervisionado Q Qualidade de EnergiaF Blocos Funcionais R Funções Relacionadas à ProteçãoG Função Genérica S Sensores, MonitoraçãoI Interfaces e Arquivamento T Transformador de InstrumentosK Equipamentos Mecânicos X Disjuntores e Chaves SeccionadorasL Funções do Sistema Y Transfomadores de PotênciaM Medição Z Outros Equipamentos
No âmbito desta dissertação, destacam-se os nós lógicos relacionados às funções de prote-ção. A Tabela 2.3 apresenta alguns destes, propostos pela IEC 61850 em referência das funçõesde proteção segundo a IEE C37.2.
26
Tabela 2.3: Principais Nós Lógicos de proteção. Fonte: Adaptado de (Machado, 2015).
Função de ProteçãoReferência Nó Lógico
IEEE C37.2 IEC 61850Distância 21 PDIS
Diferencial 87 PDIFSobrecorrente Instantâneo 50 PIOC
Sobrecorrente Temporizado 51 PTOCVolts/Hz 24 PVPH
Subtensão 27 PTUVSobretensão 59 PTOV
Direcional de Potência 32 PDPRPerda de Excitação 40 PUEX
Sobrecarga 49 PTTRFrequência 81 PTOF, PTUF
Teleproteção 85 PSCH
A característica de controle descentralizado e o conceito de interoperabilidade é entãorealizada através da implementação destas estruturas nos IEDs, de forma com que os nós lógicosdo SAS podem estar configurados em um único IED ou distribuídos entre outros dispositivos.
No entanto, dentro do contexto inserido por esta característica de controle descentrali-zado, a sincronização dos relógios dos diferentes dispositivos que operam sobre o sistema é devital importância, principalmente quando é necessária a coordenação e interoperabilidade entreeles. Sincronizados, os IEDs podem ser referidos à mesma base de tempo, permitindo a realiza-ção de tarefas como log de sequência de eventos, medição de sincrofasores, teleproteção, entreoutros. A seguir, apresenta-se a discussão sobre o serviço de sincronismo de tempo indicadopara o novo paradigma dos Sistemas de Proteção.
2.1.2 Protocolo de Sincronização de Tempo IEEE 1588
Avanços tecnológicos na área de eletrônica de potência e microeletrônica permitiram quefunções de proteção, monitoramento e controle fossem executadas por um único equipamento,os IEDs. Esta integração é realizada através de um sistema de comunicação entre os equipa-mentos. Diversos são os meios (físicos) e protocolos (lógicos) utilizados para a sincronizaçãodos relógios, porém, nem todos atendem às especificações mínimas exigidas para o Sistemasde Proteção. Um dos primeiros protocolos de sincronização utilizado nesta área foi o IRIG-B(Inter-Range Instrumentation Group). Porém, devido à necessidade de uma rede independentepara sua implementação e por ser muito susceptível à ruídos, este protocolo caiu em desuso.
27
Com a adoção de redes de comunicação Ethernet nas subestações, a tendência é que oprocesso de sincronismo utilize a infraestrutura de comunicação já existente. No entanto, osprotocolos disponíveis neste tipo de rede, em especial o SNTP (proposta pela primeira versãoda IEC 61850), não atendem plenamente os requisitos de precisão temporal impostos por algu-mas aplicações do SAS, como registros de oscilografia, transmissão de valores amostrados noBarramento de Processo e os sincrofasores (Ingram et al., 2012).
Inicialmente, fora proposto o sincronismo individual de cada Merging Unit através daLigth Edition IEC 61850-9-2-LE por um barramento específico operando no formato 1 pps.Nesse padrão, obteve-se uma precisão na ordem de microssegundos, mas ainda seria necessáriaa utilização de uma rede específica para esta finalidade.
Mais recentemente, a utilização da norma IEEE 1588v2 como padrão para sincronismode tempo em SAS tem sido avaliada (Ingram et al., 2012). Com este protocolo, é possível asincronização do relógio interno de diversos dispositivos com precisão na ordem de dezenas denanossegundos.
Também referida como PTP (do inglês Precision Time Protocol), a norma está em suasegunda versão, desde 2008. A principal diferença em relação ao SNTP, é que o PTP prevê osuporte por hardware para as estampas de tempo que são transmitidas no processo de sincro-nismo, eliminando as imprecisões de tempo inerentes ao protocolo TCP/IP.
O PTP é baseado em uma arquitetura cliente-servidor em que mensagens são trocadaspara determinação do offset e atraso de tempo relativo ao tráfego de dados na rede. O protocoloé composto basicamente por duas etapas. A primeira etapa consiste no estabelecimento da hie-rarquia mestre-escravo entre os relógios dos dispositivos conectados à rede. O estabelecimentoda hierarquia é realizada através da troca de mensagens contendo parâmetros que expressam ascaracterísticas dos relógios internos, como qualidade e estabilidade.
Em sequência, o processo de sincronização identifica o atraso de propagação médio entreo envio dos pacotes do mestre ao escravo, após um determinado tempo de observação, paraque o escravo possa fazer as correções adequadas em seu relógio. Durante esse processo, énecessário conhecer o instante no qual determinada mensagem foi transmitida e recebida porcada dispositivo. O registro deste instante é feito através de hardwares que possuam suporte aoprotocolo PTP. Esse suporte consiste na captura e geração de estampas de tempo diretamentena interface de rede.
28
2.2 Modelagem e Verificação Formal de Sistemas de TempoReal Críticos
Conforme abordado na seção anterior, fatores como a complexidade na operação dosSEEs e avanços tecnológicos na área da Engenharia Elétrica e Computação têm demandado oemprego de estratégias de operação, controle e proteção mais sofisticadas. No entanto, a revisãobibliográfica realizada na área indica que as técnicas e ferramentas para validação destas novassoluções não sofreram o mesmo desenvolvimento.
Especificamente na área de Sistemas de Proteção de SEEs, a falta de premissas técnicasno âmbito da avaliação de desempenho e do comportamento das novas filosofias de proteçãolimitam suas aplicações em sistemas elétricos reais, embora apresentem desempenho superior(pelo menos em teoria) em comparação com os esquemas tradicionais.
Em geral, o processo de proposição e validação de sistemas de proteção é realizado atravésde simulações computacionais envolvendo diversos pontos de operação e distúrbios, baseando-se principalmente na expertise do projetista e histórico de projetos similares. A limitação desteprocedimento é a impossibilidade de representar todos os pontos de operação e eventos em queo sistema elétrico estará sujeito. Ainda que sejam consideradas um número significativo decondições operativas na fase de projeto do sistema, não há garantias formais de que o mesmonão apresente comportamento indesejável logo em sua primeira atuação em campo.
A necessidade de uma abordagem genérica que sistematize as etapas de projeto e vali-dação de Sistemas Críticos de Tempo Real tem sido apontada por recentes trabalhos (Siqueira,2014; Sengupta et al., 2015a; Sengupta et al., 2015b). A bibliografia consultada confirma, noentanto, que esta área ainda está em um patamar inicial de desenvolvimento.
Baseado nesse contexto, o emprego de técnicas formais de modelagem e análise de de-sempenho em sistemas de proteção se apresenta como uma ferramenta promissora e robustapara superar os desafios no âmbito de confiabilidade e segurança em sistemas de proteção comcontrole distribuído, permitindo a investigação das principais propriedades comportamentais dosistema em teste, principalmente no sentido de comprovar se o sistema de controle das estra-tégias de proteção atende os requisitos de segurança e comportamento determinístico esperado(Mahmood et al., 2016).
Tal processo é basicamente segmentado em três principais etapas: “Modelagem”, “Espe-cificação” e “Verificação” (Baier & Katoen, 2008), conforme ilustrado pela Figura 2.5. A etapade modelagem consiste na abstração de determinada realidade para a linguagem formal empre-gada pelo verificador de modelos. A modelagem deve contemplar todas os comportamentosessenciais da realidade em análise sem comprometer o processo de verificação por escassez derecursos computacionais (Ferreira, 2012).
29
MODELAGEM
SISTEMA REAL
MODELO
REQUISITOS
ESPECIFICAÇÃO PROPRIEDADES
VERIFICAÇÃOO MODELO
ATENDE A
PROPRIEDADE?
TESTEMUNHA
CONTRAEXEMPLO
SIM
NÃO
Figura 2.5: Abordagem baseada em Verificação Formal.
Após a modelagem, é necessário que sejam elencadas propriedades as quais se desejaverificar. A especificação das propriedades normalmente é feita através da lógica temporal, aqual permite a descrição de afirmativas sobre a evolução do comportamento de um sistema nodecorrer do tempo (Ferreira, 2012).
Por fim, algoritmos de verificação avaliam exaustivamente os estados do modelo de en-trada em busca de estados que satisfaçam (ou não) as propriedades descritas na fase de especi-ficação. Caso todas as propriedades do modelo sejam verdadeiras, o modelo é então dito comocorreto. Caso não obedeça a alguma propriedade, o verificador gera o contra-exemplo mos-trando a condição da não verificação de determinada propriedade (Ferreira, 2012). A seguir,apresenta-se mais detalhadamente as etapas do processo de Verificação Formal.
2.2.1 Formalismo de apoio à Modelagem
Além de se apresentar como uma abstração natural dos Sistemas de Proteção, a aborda-gem baseada em Sistemas Dinâmicos a Eventos Discretos (SDEDs) permite que a modelagemdo sistema em análise seja realizada por uma linguagem precisa e não ambígua, fator essencialno contexto da Verificação Formal (Cassandras & Lafortune, 2010).
Diversos são os formalismos adotados para modelagem de aplicações industriais e a es-colha do formalismo adequado não é uma tarefa trivial, dependendo de diversos fatores quesão estabelecidos de acordo com o grau de realismo entre o modelo e o comportamento físicoideal abordado no estudo. Isto implica que o modelo deve representar de maneira fidedigna,no mínimo, o possível comportamento da realidade de acordo com o que se deseja avaliar, semcomprometer a verificação formal por incoerências tanto por questões de modelos simples (quenão consideram os comportamentos desejáveis) quanto por questões de modelos complexos,comprometendo-se a análise por escassez de recursos computacionais.
30
No contexto dos SDEDs, não existe um formalismo matemático único que seja comple-tamente satisfatório para a consideração simultânea de aspectos presentes nas classes de pro-blemas que se podem formular (Cassandras & Lafortune, 2010). Isso implica que um mesmosistema pode ser corretamente modelado através de realismos diferentes, baseado principal-mente nas características do estudo em que este será abordado.
No entanto, a literatura consultada indica que as principais abordagens consistem em for-malismos baseados na evolução dos Autômatos de Estados Finitos e Redes de Petri (Kunz,2012; Rondon, 2012). O formalismo empregado no trabalho em questão será baseado em Autô-matos Temporizados Híbridos que consiste em uma extensão dos Autômatos Finitos capazes derepresentar também variáveis contínuas.
Na área de Sistemas de Tempo Real Críticos, destaca-se alguns argumentos que apontampara o emprego deste formalismo como linguagem de apoio à modelagem, dentre estes, cita-sea capacidade de representar, de forma natural, as características principais dos SDEDs, comosincronismo, assincronismo, concorrência, causalidade, conflito e compartilhamento de recur-sos. Além disso, a representação gráfica dos autômatos facilita o processo de modelagem einterpretação dos modelos.
Um Autômato de Estados Finitos é uma máquina de estados finitos que representa al-guma realidade (abstração de um mecanismo, dispositivo ou sistema). A partir de um con-junto sequencial de entradas (alfabeto), o autômato reage e muda de estado de acordo comuma função de transição. Formalmente, um Autômato Finito pode ser representado por (Davidet al., 2015; John E. Hopcroft, 2001):
Definição 1 (Autômatos de Estados Finitos). Um Autômato de Estados Finitos (AEF) é umatupla A = (Q,Σ, ϕ, q0, F ), onde: i) Q = {q0, q1, · · · , qn} denota o conjunto finito de estadosdo autômato, ii) Σ é um alfabeto finito de símbolos, iii) ϕ : Q × Σ → P (Q) é a função detransição, iv) q0 ∈ Q é o estado inicial, e v) F ⊆ Q é um conjunto de estados de aceitação.
Graficamente, os autômatos podem ser representados por grafos direcionados, em que osestados e eventos são representados respectivamente por nós e arcos. Um exemplo de AEF éapresentado na Figura 2.6. No grafo, o conjunto de estados é denotado por Q = {q0, q1, q3},sendo o estado inicial q0 representado graficamente através da conexão do arco que não possuinó de origem. O alfabeto do autômato é denotado como Σ = {a, b, c, d}, sendo este compostopelas arcos rotulados do grafo. Ainda no exemplo em questão, a função de transição é repre-sentada por f (q0, a) = q1, f (q1, b) = q0, f (q1, c) = q2ef (q2, d) = q0. O conjunto de estadosde aceitação (estados marcados ou finais) não são descritos na Figura 2.6. Estes representariamquais estados, quando alcançados, atingem o objetivo ou funcionalidade desejada ao autômato.
O comportamento do autômato da Figura 2.6 é descrito como segue: inicia a partir doestado inicial q0 e permanece neste até a ocorrência de um evento a, que dispara a transição doautômato para o estado q1. Este processo se repete baseado nas transições definidas em f .
31
q0
a
b
q1 q2
c
d
Figura 2.6: Exemplo de AEF.
Os AEFs podem ser classificados em determinísticos e não-determinísticos. AEF deter-minístico é um autômato onde, dependendo do estado corrente e do símbolo lido, o autômatoassume um único estado bem determinado. Já um AEF não-determinístico, dependendo doestado corrente e do símbolo lido, o sistema pode assumir um conjunto de estados alternativos.
A relação entre um AEF e a lógica temporal (abordada na próxima subseção) foi esta-belecida em 1986, por Vardi e Wolper, ao provarem que para cada fórmula da lógica temporalexiste um caminho de computação possível no autômato. No entanto, em sua forma clássica, oAEF não se aplica a avaliação de Sistemas de Tempo Real Críticos, pois esta representação ape-nas serve para mostrar como um sistema evolui de um estado a outro, não abordando aspectostemporais entre estas transições.
Em 1991, Alur e Dill propuseram esta modificação na teoria dos AEFs, a qual foi denomi-nada de teoria dos Autômatos Finitos Temporizados (AFTs). Os AFTs são uma representaçãoque permite modelar o comportamento de sistemas em relação ao tempo através de um con-junto especial de variáveis denominadas relógios (clocks). Estas variáveis possuem valoresreais e marcam a passagem do tempo, sendo incrementados de maneira síncrona conforme otempo avança.
As transições de um AFT podem se encontrar ativas ou inativas de acordo com restrições(condições) sobre os valores de cada relógio, denominadas guardas (guard). Uma trajetóriapode tomar uma transição apenas se os relógios satisfizerem as guardas associadas à ela. Sendoassim, a transição de estados agora não depende unicamente do símbolo lido, mas também dotempo relativo da entrada do símbolo. Nesse contexto, um AFT pode ser descrito como segue(David et al., 2015):
Seja C um conjunto de relógios e x, y ∈ C; c ∈ N; op_rel ∈ {≤,≥,=, <,>}; Define-se B(C)
como um conjunto de guardas, sob conjunção na forma x op_rel c ou x− y op_rel c.
Definição 2 (Autômatos Finitos Temporizados). Um Autômato Finito Temporizado (AFT) éuma tupla A = (Q, q0, C, A, I, E), onde: i) Q é um conjunto finito de estados, ii) q0 ∈ Q é oestado inicial, iii) C é o conjunto finito de relógios, iv) A é o conjunto de ações, v) I : Q →B(C) as invariantes atribuídas aos estados, e vi) E ⊆ Q×A×B(C)× 2C ×Q é um conjuntode transições entre dois estados com uma ação, uma guarda e um conjunto de relógios.
32
Na definição supracitada, observa-se a inclusão de uma característica denominada Inva-riante ao modelo. Esta é uma outra maneira de controlar o disparo das transições dos estados.O sistema pode permanecer em um estado somente enquanto a Invariante associada a este es-tado permanecer verdadeira, isto é, alguma das transições discretas devem ser tomadas antes dainvariante torna-se falsa.
Na Figura 2.7 é apresentada uma variação do autômato exemplo descrito na Figura 2.6,incluindo o relógio x e operações e controles sobre este relógio através da invariante x ≤ 1,guarda x == 1 e atualização x = 0. Logo, a função de transição entre o estado q0 e q1
é determinada através da invariante associada ao estado q0 e do guarda associado ao arco deligação entre os estados. Nesse caso, a partir do estado q0, o autômato avança ao estado q1 após1 unidade de tempo no relógio x.
q0
b
q1 q2
1x
1x
0x
0x
c
d
Figura 2.7: Exemplo de AFT.
No entanto, dentro do âmbito de modelagem dos Sistemas de Proteção abordado nestetrabalho, verifica-se a necessidade ainda da representação de variáveis contínuas ao formalismo,de forma com que o tempo seja tratado como uma variável cujo valor varia de acordo comas características do sistema. A definição de autômatos híbridos empregada neste trabalho édescrita por (adaptado de (David et al., 2015; Susuki et al., 2012; Rinast, 2012)):
Definição 3 (Autômatos híbridos). Um Autômato Híbrido (AH) é uma tuplaH = (Q×X,Q0×X0, ε,Σ, Inv,G) onde: i) Q × X denota o espaço de estados híbridos, sendo Q um conjuntofinito de estados discretos {q1, q2, · · · , qN} e X ⊆ Rn espaço de estados das variáveis contí-nuas; ii)Q0×X0 ⊆ Q×X é o conjunto de condições iniciais do autômato; iii) {εq}q∈Q associaa cada estado discreto a dinâmica das variáveis contínuas através de equações diferenciais deprimeira ordem; iv) Σ ⊆ Q × Q denota o conjunto de transições (ou alfabeto) do autômato.Cada transição e ∈ Σ relaciona dois estados, sendo o estado de saída denotado por s(e) eo de chegada t(e); v) Inv denota as invariantes de cada estado, e vi) {Ge}e∈Σ associa cadatransição a um guarda Ge ⊆ Invs(e).
Da definição AH, observa-se que já não é possível representar o sistema por meio de umautômato de estados finitos, uma vez que para cada estado discreto Q, existe infinitos valores deX para o estado híbrido Q ×X . Isto introduz um problema de não-decidibilidade ao sistema,não sendo possível a aplicação das técnicas clássicas de verificação formal. Posteriormente,discute-se uma alternativa de ferramenta para análise das propriedades de um sistema híbrido.
33
Uma das características desejáveis à abordagem baseada em autômatos é a decomposiçãode um sistema em vários componentes, cada qual modelado por um autômato separado. A inte-ração entre essas partes é determinada com a operação de composição síncrona. Esta interaçãopode ocorrer de duas formas: cada parte pode se sincronizar por meio de transições discretas,via rótulos de sincronismo ou apenas pelo compartilhamento de variáveis.
2.2.2 Lógica Temporal
Lógicas temporais são formalismos que permitem descrever as especificações do sistemaatravés de operadores temporais e quantificadores de caminhos combinados aos operadores delógica clássica. Ela define uma relação de ordem entre estados globais de um sistema, des-crevendo as sequências em que as proposições atômicas vão sendo obedecidas à medida que oscaminhos de computação evoluem. Logo, diferente da lógica clássica, a lógica temporal permiteexpressar situações que poderão ocorrer durante uma sequência de tempo (Rondon, 2012).
As lógicas temporais mais utilizadas na área de Verificação Formal são as lógicas LTL (Li-near Temporal Logic) e CTL (Computation Tree Logic), as quais diferem-se basicamente pelalimitação quanto à trajetória do modelo. Em síntese, uma fórmula LTL estabelece uma regrapara um determinado caminho de computação do modelo em análise, enquanto a CTL, permitea expressão de propriedades sobre um ou todos os caminhos de computação possíveis. Seman-ticamente, as fórmulas baseadas em LTL são construídas associando-se operadores temporais eproposições atômicas, já em CLT, inclui-se também os quantificadores de caminho.
Além destes, a composição das fórmulas pode ser feita através de conectores booleanosda lógica proposicional, com operador de negação (¬), operador OU (∨), operador E (∧) eimplicação (→).
A semântica dos operadores temporais é definida a partir de um caminho de computaçãoespecífico e têm por objetivo a ordenação temporal de ocorrência de eventos sobre este caminho.Os principais operadores são:
• � (G) – Simbolizando "globalmente". Este operador indica a ocorrência de determinadacondição globalmente, ou seja, em todos os estados sucessores do estado atual do sistema;• ♦ (F ) – Simbolizando "em um estado futuro". Este operador indica a ocorrência de
determinada condição em um estado futuro ao estado em que se encontra o sistema emdado momento;• © (X) – Simbolizando "no próximo estado". Este operador indica a ocorrência de de-
terminada condição em um estado sucessor ao estado em que se encontra o sistema emdeterminado momento; e• ∪ – Simbolizando "até que". Este operador indica a precedência entre eventos em um
dado momento, indicando que determinada condição deve ser verdade até o momento emque outra condição venha a ser satisfeita.
34
Os quantificadores de caminho são utilizados para determinar o ramo da árvore de estadosque será abrangido. Os quantificadores são:
• ∀ (A) – Simbolizando “para todos os caminhos”. Este quantificador indica que todos oscaminhos de computação possíveis devem respeitar proposição atômica; e• ∃ (E) – Simbolizando que a proposição atômica deve ser verdadeira em pelo menos um
ramo da árvore de estados do modelo.
As proposições atômicas são usadas para formalizar as condições de interesse nos estadosdo sistema e, em conjunto com os operadores supracitados, determinam as propriedades queserão verificadas sobre o modelo em estudo. A seguir apresenta-se a descrição semântica dealgumas formulações baseadas em CTL. Na Figura 2.8, é apresentada a interpretação gráficadestas fórmulas.
• ∀�(ϕ) – Para todos os caminhos, em todos os estados, ϕ deve ser satisfeito. Esta pro-priedade denota um comportamento global em todos os caminhos e estados possíveis dacomputação;• ∀♦(ϕ) – Para todos os caminhos, no futuro, ϕ deve ser satisfeito. A propriedade denota
a existência de um ou mais estados que satisfaçam ϕ em dado momento, para todoscaminhos de computação.• ∀©(ϕ) – Para todos os caminhos, no próximo estado, ϕ deve ser satisfeito. A propriedade
descreve um comportamento em um estado sucessor de um dado estado para todos oscaminhos de computação.• ∀(ϕ ∪ ψ) – Para todos os caminhos, ϕ é verdade até que ψ seja satisfeito. A propriedade
demonstra a precedência na ocorrência de um evento ϕ para que o evento ψ ocorra, sendoψ um estado sucessor de ϕ. A sintaxe deste operador indica ainda que, sendo ψ válidoem todos os caminhos, não é necessária a ocorrência de ϕ nestes mesmos caminhos paraque a fórmula seja válida.• ∃�(ϕ) – Existe um caminho na árvore de estados em que em todos estados ϕ é satisfeito.
A propriedade demonstra a ocorrência de pelo menos um caminho de computação ondeϕ é sempre verdade.• ∃♦(ϕ) – Existe um caminho onde, no futuro, em pelo menos um estado ϕ é verdade. Para
a propriedade ser válida, deve haver pelo menos um estado que satisfaz ϕ na árvore deestados, não importa o ramo.• ∃©(ϕ) – Existe um caminho onde, no próximo estado, ϕ deve ser satisfeito. Propriedade
válida somente para os estados que possuam como sucessores estados que satisfazem ϕ
• ∃(ϕ ∪ ψ) – Existe um caminho onde ϕ é satisfeito até que ψ venha a ser válido. Fórmulaválida em pelo menos um caminho na árvore onde, para ψ ser satisfeito, ϕ deve sersatisfeito em pelo menos um estado antecessor direto de ψ.
35
Figura 2.8: Visualização da semântica de algumas fórmulas CTL básicas.
2.2.3 Verificador de Modelos
Dentre as ferramentas de modelagem e verificação formal de sistemas híbridos existen-tes no mercado, como UPPAAL (David et al., 2015), Hycomp (Cimatti et al., 2013), Hytech(Henzinger et al., 1997), Prism (Kwiatkowska et al., 2011) entre outros, optou-se pelo UPPAAL
pelos seguintes motivos:
• O formalismo de base do UPPAAL, Autômatos Temporizados, é implementado através desua representação gráfica (grafos), tornando a construção dos modelos mais intuitiva;
• O UPPAAL agrega ferramentas para modelagem (gráfica), simulação (gráfica) e verifica-ção (via conferência automática de modelos) em um mesmo ambiente, reduzindo o riscode erros de análise ocasionadas pela translação entre formalismos para ambientes dife-rentes;
• Extensões na linguagem de modelamento, como tipo dos estados da rede de autômatos(Normal, Urgent ou Commited), canais de sincronização e tipos de variáveis disponíveis(incluindo a definição de tipos pelo usuário) permitem a representação de diversos com-portamentos com um elevado grau de realismo;
• O UPPAAL já é uma ferramenta consolidada na área em questão (primeiras versões desde1995) e está em constante atualização por parte de seus desenvolvedores.
36
Desenvolvido através de uma parceria entre o Departamento de Tecnologia da Informaçãoda Universidade de Uppsala e o Departamento de Ciência da Computação da Universidadede Aalborg (de onde deriva-se o nome Upp-Aal), o UPPAAL consiste em uma suíte poderosapara modelagem e verificação de sistemas concorrentes de tempo real. O sistema em análiseé modelado através de uma rede de Autômatos de Estados Finitos com restrições de tempo esuas propriedades são descritas através da lógica TCTL (do inglês Timed Computational TreeLogic), na qual permite-se a inclusão da variável tempo nos caminhos de computação possíveissobre a rede de autômatos.
Por se tratar de uma ferramenta que está se consolidando na área de modelagem e verifi-cação formal de sistemas de tempo real críticos, o UPPAAL tem sido alvo de um investimentocontínuo pelas universidades envolvidas, do qual diversas ferramentas estão sendo derivadasde sua arquitetura. Por exemplo, conforme abordado pelo trabalho de Kunz (2012), com oUPPAAL TRON é possível fazer testes de conformidade em equipamentos reais por meio deuma interface lógica com a rede de autômatos construída. O UPPAAL CORA permite a realiza-ção de análises de otimização sobre execuções de modelos, desenvolvidos sobre uma extensãodos autômatos temporizados LPTA (Linear Priced Timed Automata) que permite que o modeloseja anotado com a noção de custos. UPPAAL TIGA implementa um algoritmo em tempo deexibição (on-the-fly) para sintetizar estratégias de alcance às propriedades de acessibilidade esegurança. A determinação das estratégias é baseada na teoria de jogos temporizados, que con-siste em determinar a sequência de eventos para chegar a um estado vencedor. O formalismoempregado pelo UPPAAL TIGA é baseado na teoria de Autômatos Jogo-Temporizados (TimedGames Automata), também uma extensão ao formalismo do UPPAAL clássico. Uma ferramentade verificação formal estatística (Statistical Model Checking) é empregada pelo UPPAAL SMC.O formalismo empregado pelo UPPAAL SMC é baseado em autômatos híbridos estocásticos. Aabrangência destas ferramentas também motivaram o emprego do UPPAAL como ferramenta demodelagem e verificação de modelos nesta dissertação.
Introdução ao UPPAAL STRATEGO
Relativamente ao UPPAAL e suas extensões, dentre as vantagens de sua utilização cita-sea possibilidade de manipulação das três fases de elaboração do modelo do sistema: modelagem,simulação e verificação. Isso é possível através da integração entre as aplicações de interfacegráfica GUI (Graphical User Interface) e o mecanismo de verificação (Verification Engine) emuma arquitetura cliente-servidor. De acordo com a complexidade do sistema em análise, o me-canismo de verificação pode ser usado em modo stand-alone (via batch). A interface gráfica édividida em três partes principais: editor, no qual é usado para construção do modelo; simulador,onde pode-se avaliar o comportamento do modelo através de escolha manual das transições (porparte do usuário), de modo randômico ou através de contra-exemplos (ou testemunha) geradosnas verificações; e verificador, onde implementa-se as propriedades que serão verificadas.
37
O formalismo de base empregado pelo UPPAAL é uma extensão dos Autômatos Tempo-rizados do modelo proposto por Alur e Dill (Alur & Dill, 1994): cada autômato é definido porum template ou process. Os estados são representados por locations e as transições por edges.As restrições de tempo são realizadas através de variáveis do tipo relógio (clock). Além des-tes componentes, há um conjunto de ampliações da linguagem de modelamento que permite arepresentação de comportamentos mais sofisticados.
Por exemplo, um sistema complexo pode ser modelado como uma rede de autômatos,sendo que cada autômato representa uma decomposição do comportamento global do sistema.A integração entre os autômatos pode ser realizada através de transições com variáveis ou fun-ções compartilhadas e por transições específicas, denominadas canais de sincronização. Noprimeiro caso, as transições são estendidas com a capacidade de testar uma determinada con-dição (guard) e, caso o teste permita o disparo da transição em questão, de alterar o valor dasvariáveis (update). Diversos tipos de variáveis podem ser declarados no UPPAAL, como boo-leano, inteiro, vetores, estruturas, ponteiros, constantes, relógios, relógios híbridos e variáveisdefinidas pelo usuário. O autômato com essa funcionalidade passa a considerar um conjunto devariáveis e uma transição passa a ser uma tupla ε =< qi, g, l, a, qf > que significa: uma transi-ção ε pode ser selecionada quando o estado qi é o estado de controle, a guarda g é verificada ea entrada do autômato começa pela etiqueta l da transição. Como consequência desta transiçãoa atualização a é acionada e o estado de controle passa do estado qi para o estado qf . Alémda atualização das variáveis, o campo update das transições permite a chamada de funções pré-definidas como sin(), cos(), random(), sqrt(), pow(), ln(), assim como funções definidas pelousuário em linguagem sintaticamente semelhante a linguagem C.
Já na segunda situação, uma sincronização corresponde virtualmente ao envio e recepçãode mensagens. A etiqueta da transição emissora é rotulada pelo final “!” e a da receptora com“?”. Canais de sincronização podem ser declarados como binários (“chan c”) ou broadcast(“broadcast chan c”). A transição entre canais binários somente pode ocorrer caso exista pelomenos uma transição receptora ativa (c?) para uma transição emissora (c!). Já em canais bro-adcast, se não houver receptores habilitados, a transição emissora ainda pode ser disparada.Adicionalmente, é possível declarar que determinados canais de sincronização devam ocorrersem restrições de tempo, o que implica no disparo instantâneo quando estiver em seu estado decontrole. Neste caso, adiciona-se o prefixo urgent na declaração do canal de sincronização.
Os estados podem conter condições (sobre variáveis do tipo relógio ou relógio híbrido)designadas por invariantes. O invariante introduz a noção de obrigação de evolução do autô-mato, ao contrário dos guardas, que indicam apenas a possibilidade de progresso. Um invariante“I” em um estado “q” significa que o autômato pode passar no estado em questão apenas en-quanto “I” for satisfeito. Se isso não for possível, o sistema assume uma condição de falha.Também, através dos invariantes, se faz o controle das taxas de evolução das variáveis do tiporelógio, para sistemas híbridos. Assim como nos canais de sincronização urgentes, há tam-bém a possibilidade de declaração de estados em que não existe a evolução de tempo. Esses
38
estados podem ser declarados como urgent ou committed. Os estados urgentes são semantica-mente semelhantes à adição de um relógio extra “t”, que reinicia em todas as entradas e temum invariante “t <= 0”. Assim, os relógios permanecem inalterados enquanto o sistema estáem um estado urgente. Já os estados commited são mais restritivos e obrigam imediatamente aexecução de uma transição que parte dele. Estes tipos de estados permitem modelar sequênciade ações que não envolvem tempo, ou seja, que não representam mudanças físicas no sistema.
Na Figura 2.9 é apresentada uma rede de autômatos exemplificando algumas ampliaçõesda linguagem de modelamento do UPPAAL. Do modelo, identifica-se canais de sincronização,atualizações de relógios em transições, guardas, invariantes e estados committed. O funciona-mento da rede de autômatos da Figura 2.9 é interpretada da seguinte maneira: o autômato relayenvia sinais de trip através da transição com a etiqueta Trip!. A taxa de envio desta transiçãoé baseada em uma função de distribuição exponencial com taxa igual a 1. A transição Trip?ocorre no autômato circuit breaker, a qual reseta o relógio t. O autômato permanece no estadoarcing em um intervalo entre 2 e 5 unidades de tempo, representando o tempo do disjuntorabrir. Por fim, o autômato circuit breaker volta para sua condição inicial (estado idle).
Nome do
estadoCanal de
sincronização
emissor
Taxa da função
de distribuição
exponencial
(a)
Canal de
sincronização
receptor
Atualização
de variável Invariante
do estado
Guarda da
transição
Estado
commited
(b)
Figura 2.9: Modelo exemplificando uma rede de autômatos. a) autômato relay e b) autômatoCircuit Breaker.
Dentro do formalismo adotado pelo UPPAAL STRATEGO, o instante de disparo das transi-ções é representado por distribuições de probabilidade, sendo os invariantes descritos por umafunção de distribuição uniforme. Com relação à interpretação física dos invariantes, pode-seinferir que o tempo “t” em que o autômato ficará em um estado “q” é dado por uma função dedistribuição uniforme com limite fechado em “Lim”, sendo “t <= Lim” o invariante associadoao estado “q”. Para estados sem invariantes, o disparo das transições é representado por umafunção de distribuição exponencial, sendo a taxa da distribuição exponencial declarada pelousuário no campo rate of exponential do estado. Assim como no caso anterior, a implementa-ção desta função significa que o tempo de permanência “t” em um estado “q” é representado poruma função de distribuição exponencial do tipo e−Lim, sendo “Lim” a taxa de exponencial doestado em questão. Adicionalmente, pode-se também atribuir a noção de probabilidade atravésde pesos declarados nas transições.
39
Dentro do propósito desta dissertação, além da construção de modelos fidedignos atra-vés da linguagem de modelagem e suas extensões no UPPAAL, a etapa de verificação formaldos modelos é um ponto crucial da metodologia proposta. Tal como o modelo, a especificaçãodas propriedades deve ser expressa numa linguagem bem definida formalmente e computaci-onalmente possível. Nesse contexto, serão abordados de maneira resumida os fundamentosrelacionados com a especificação das propriedades a serem verificadas sobre os modelos emanálise.
Tal como referido anteriormente, a especificação das propriedades no UPPAAL clássicoé realizada através da TCTL, na qual consiste em uma extensão da CTL (Emerson & Clarke,1982). Através desta linguagem é possível expressar a variável tempo nos caminhos de compu-tação possíveis, como por exemplo E♦<5φ, que verifica se existe um caminho de computaçãoque satisfaz φ em um intervalo de tempo inferior a 5 unidades.
Conforme abordado anteriormente, uma fórmula descrita em CTL consiste na associaçãoentre operadores temporais e quantificadores de caminho. No UPPAAL, a condição de trava-mento é expressa utilizando um operador temporal (embora esta não seja estritamente umafórmula de estado). A fórmula consiste simplesmente na palavra-chave deadlock e é satisfeitapor todos os estados de deadlock. Uma condição de deadlock é detectada se houver um estadoda rede de autômatos em que nenhuma transição com uma ação de saída para o próprio estadoou para algum dos estados sucessores é detectada. Devido às limitações computacionais atuaisno UPPAAL, a fórmula do deadlock só pode ser usada com um quantificador de caminho, dotipo “A[] not deadlock”, que testa se em todos os caminhos possíveis inexiste uma condição detravamento.
A associação dos operadores temporais e quantificadores permite a descrição de propri-edades do sistema. Basicamente estas propriedades são classificadas em acessibilidade, se-gurança e vivacidade. Propriedades de acessibilidade permitem verificar se uma fórmula deum determinado estado é eventualmente satisfeita ao longo de uma trajetória de estados. NoUPPAAL, a sintaxe para esta propriedade é dada por “E <> ϕ”, cuja formulação também podeser: existe um caminho da rede de autômatos que, a partir do estado inicial, satisfaz a fórmula ϕ.As propriedades de acessibilidade são usadas frequentemente ao projetar um modelo para veri-ficar a sua utilidade, porém, estas expressões não garantem a exatidão do modelo, mas verificase o seu funcionamento básico é possível de ocorrer.
As propriedades de segurança são usadas para expressar que determinada condição nuncairá acontecer. Estas propriedades são formuladas de forma positiva, por exemplo, algo bomé sempre verdadeiro. Considerando ϕ a formulação de teste, no UPPAAL, as propriedades desegurança podem ser expressar por A[]ϕ, que é satisfeita se em todos os estados alcançáveis darede de autômatos ϕ é satisfeita, e por E[]ϕ, que significa que deve existir ao menos um trajetoda rede de autômatos em que todos os estados satisfazem ϕ.
40
Por fim, as propriedades de vivacidade expressam que determinada condição eventual-mente pode ocorrer. No UPPAAL, dois tipos de propriedades de vivacidade podem ser es-pecificadas: A <> ϕ, que é satisfeita caso exista ao menos um caminho que satisfaça ϕ, eψ − − > ϕ, que é satisfeita caso exista alguma transição entre estados que satisfaçam ψ e ϕ,respectivamente.
Na Figura 2.10 são apresentados alguns exemplos de fórmulas de trajeto no UPPAAL e suainterpretação na rede de autômatos em análise. Estas especificações são denominadas queriese são implementadas na guia de verificação. Pode-se configurar para que o processo de verifi-cação retorne uma testemunha (em caso de atendimento à propriedade) e contra-exemplo (emcaso contrário) na guia de simulação.
(a)
(b)
(c)
Figura 2.10: Exemplos de fórmulas de trajeto no UPPAAL: a) Acessibilidade: E <> ϕ , b)Segurança: A[]ϕ e c) Acessibilidade: ϕ−− > ψ.
A bibliografia consultada indica uma variedade de aplicações em que esta ferramentaé empregada com sucesso na modelagem e verificação formal de sistemas concorrentes detempo real, como (Ravn et al., 2011; Hessel & Pettersson, 2007; Bordbar et al., 2005; Blomet al., 2005; Bordbar & Okano, 2003). Porém, o formalismo de base destes trabalhos é baseadoem Autômatos Temporizados. A principal desvantagem deste formalismo, está na eventual “ex-plosão de estados” em sistemas mais complexos. Além disso, a inclusão de variáveis contínuasao modelo introduz o problema da não garantia de convergência do procedimento de verifica-ção das propriedades do modelo em análise, uma vez que não é possível representar o sistemaatravés de um número finito de estados.
Como o formalismo de base proposto nesta dissertação para representação dos modelosque compõem os Sistemas de Proteção é baseado em Autômatos Temporizados Híbridos, o em-prego das fórmulas de trajeto e de estado do UPPAAL clássico não são suficientes para validaçãodos modelos construídos. Nesse contexto, a ferramenta adotada para verificação dos modelosé o UPPAAL STRATEGO, do qual é possível a representação de modelos através de redes deautômatos cujo comportamento pode depender de características estocásticas e dinâmicas nãolineares.
41
O UPPAAL STRATEGO inclui uma série de novas queries para especificação das proprieda-des da rede de autômatos. Uma delas é a Simulate N [<= bound]{E1, .., Ek}, na qual permitea visualização das variáveis E1, ..Ek para N simulações em um intervalo bound de unidadesde tempo. Para especificação das propriedades sobre a rede de autômatos, o UPPAAL empregauma extensão da lógica MITL (do inglês, Metric Interval Temporal Logic) através de três tiposde questões: i) estimação de probabilidade (quantitativa); ii) testes de hipóteses (qualitativa); eiii) comparação de probabilidade (qualitativa).
A estimação de probabilidade é uma query quantitativa, da qual é possível responderquestões como: “Qual a probabilidade PM(�x≤Cϕ) de uma rede de autômatos M eventual-mente satisfazer ϕ em um intervalo de tempo x menor do que C”. O processo de cálculo destaprobabilidade é realizada de maneira semelhante ao método de Monte Carlo. Determinado umgrau de confiabilidade e tolerância (dados pelo usuário), o UPPAAL calcula o número de amos-tras necessárias para análise. Métodos estatísticos são aplicados nos resultados de forma a obterinformações do comportamento do sistema. Mesmo não fornecendo uma garantia formal doatendimento da propriedade em análise, a probabilidade de atendê-la já pode ser suficiente paragarantir o comportamento esperado do modelo. As fórmulas de estados e trajeto são introduzi-das nas queries como Pr[<= bound] (‘ <>′ |‘[ ]′ ϕ). Detalhes da implementação desta querypode ser encontrada em (Hérault et al., 2004).
Na Figura 2.11 é ilustrada a diferença entre a abordagem clássica e a abordagem esta-tística, dentro do contexto de aplicação deste trabalho. Como exemplo, supondo um caso deidentificação de falta e abertura de disjuntor, na etapa de verificação formal considerando omodelo discreto poderia ser feita a verificação de “O disjuntor deve abrir 80 ms após a identi-ficação da falta” (Figura 2.11.a). Já considerando o modelo híbrido, a mesma situação deveráser expressa por “qual a probabilidade do disjuntor abrir 80 ms após a identificação da falta”(Figura 2.11.b).
O teste de hipótese é uma query qualitativa, e responde testes como “Qual a probabi-lidade PM(�x≤Cϕ) de uma rede de autômatos M que satisfaça ϕ em um intervalo de tempox ≤ C ser maior ou igual a p ∈ [0, 1]”. A sintaxe de implementação de queries de testes dehipóteses no UPPAAL é Pr[bound](<> ϕ) <= double . Por fim, a comparação de probabi-lidade, como o próprio nome sugere, responde questões como “a probabilidade PM(�x≤Cϕ1)
é maior ou igual à probabilidade PM(�y≤Cϕ2)”. A sintaxe de implementação desta query éPr[bound](<> ϕ1) <= Pr[bound](<> ϕ2).
Na Tabela 2.4 são apresentadas as principais queries que serão utilizadas para validaçãodos modelos desenvolvidos nesta dissertação.
42
MODELAGEM
SISTEMA REAL MODELO
ESPECIFICAÇÕES
COMPORTAMENTO DESEJADO
ESPECIFICAÇÃO INFORMAL MODELAGEM LÓGICA TEMPORAL
PROPRIEDADES
R
MODEL
CHECKER
O MODELO
ATENDE A
PROPRIEDADE?
TESTEMUNHA
CONTRAEXEMPLO
SIM
NÃOUPPAAL
(a)
MODELAGEM
SISTEMA REAL MODELO
ESPECIFICAÇÕES
COMPORTAMENTO DESEJADO
ESPECIFICAÇÃO INFORMAL MODELAGEM LÓGICA TEMPORAL
PROPRIEDADES
R
MODEL
CHECKERATENDE A
PROPRIEDADE?
Probabilidade
UPPAAL
(b)
Figura 2.11: Etapa de Verificação Formal para a) autômatos discretos e b) autômatos híbridos.
Tabela 2.4: Resumo das Queries no UPPAAL STRATEGO.
Queries de SimulaçãoSimulação simulate int [bound] {expr1, expr2 }
Queries de Verificação Formal ClássicaSegurança A[ ] propVivacidade E<> propDeadlock A[ ] not deadlock
Queries de Verificação Formal EstatísticaEstimação Pr[bound] (<> prop)Comparação Pr[bound](<> prop1) ≥ Pr[bound](<> prop2)Teste de Hipóteses Pr[bound](<> prop) ≥ double
43
2.3 Trabalhos Relacionados
Assim como as demais pesquisas realizadas no cunho acadêmico e científico, o desen-volvimento desta dissertação foi continuamente conduzido sob aspectos técnico/científicos detrabalhos que estão sendo realizados e discutidas nos principais eventos e conferências da áreaem questão, no âmbito de identificar uma linha de pesquisa consistente (e factível) que se en-caixe nos interesses de desenvolvimento futuros do Parque Tecnológico Itaipu (PTI), através doLasse.
Nesse contexto, esta seção tem como objetivo relatar os principais trabalhos na área demodelagem e verificação formal em sistemas elétricos que direcionaram as atividades realizadasao longo do desenvolvimento do trabalho.
Mais especificamente na área de validação de Sistemas de Proteção, os trabalhos de Sen-gupta et al. (2015) “Automated Verification of Power System Protection Schemes – Part I e II”serviram como ponto de partida para o desenvolvimento desta pesquisa. O trabalho em questãoé dividido em duas partes (dois artigos) e consiste basicamente na verificação da coordenaçãoentre relés de sobrecorrente e impedância, mediante a observação de propriedades desejáveisao sistema de proteção. As propriedades do sistema de proteção são traduzidas em variáveiscontínuas, denominadas grau de satisfação, e são verificadas indiretamente através da excursãoda amplitude destas durante o período de tempo analisado. Na violação de alguma destas pro-priedades, os autores propõem uma ferramenta automática para parametrização adequada dosrelés.
Na primeira parte do trabalho, “Part I: Modeling and Specifications” (Sengupta et al.,2015a), são apresentados os modelos em autômatos híbridos e a tradução das propriedades dosistema de proteção para uma variação da lógica temporal clássica. Um método para geraçãoautomática dos casos a serem analisados é apresentado na segunda parte do trabalho, “Part II:Test Case Generation Using Swarm Intelligence” (Sengupta et al., 2015b). Também, no artigoem questão, os autores propõem um método para o reajuste automático dos relés, de forma comque o novo ajuste não viole novamente a propriedade associada ao erro de parametrização.
Devido à relação com o trabalho desta dissertação, foi dado enfoque apenas na primeiraparte do trabalho de Sengupta et al. (2015). No artigo em questão são apresentados os modelos(teóricos) em autômatos híbridos de duas funções de proteção, sobrecorrente e impedância, e dodisjuntor. A ferramenta de implementação dos modelos é o Hytech. Supõe-se que, como o ob-jetivo do trabalho é a análise da parametrização dos relés, não foram considerados a modelagemdos TPs/TCs e do meio de comunicação entre os dispositivos (relés + disjuntor), assim comoas funções de probabilidade que descrevem os modos de falha dos elementos. A arquitetura dosistema de proteção também não é discutida. Os modelos apresentados não foram validadosindividualmente no trabalho. O emprego da ferramenta Hytech possibilita uma interface comdados de programas externos, que no trabalho em questão, empregou-se um software de simu-
44
lação de transitórios eletromagnéticos para representar a dinâmica das variáveis elétricas dosSEEs. Não foi discutido a modelagem que o software emprega nos elementos do sistema elé-trico, porém, os autores comentam que os geradores foram modelados de acordo com o modeloclássico, representado por uma fonte de tensão em série com uma reatância transitória.
Ainda em Sengupta et al. (2015a), são especificadas as três propriedades desejáveis aosistema de proteção: coordenação entre relés, função de retaguarda e operação ótima dos relés.As propriedades foram traduzidas em variáveis contínuas (grau de satisfação) de tal modoque, valores positivos do grau de satisfação indicam atendimento da propriedade associada,e valores negativos indicam violação. Os autores propõem uma extensão da lógica temporalpara representação de cada grau de satisfação. Nesse contexto, as propriedades são verificadasindiretamente através do valor do grau de satisfação durante o período de tempo considerado.
Para descrição detalhada sobre o funcionamento da metodologia proposta, os autoresapresentam alguns testes realizados envolvendo a coordenação entre relés de sobrecorrente edistância sobre o sistema teste “IEEE 9 barras”. A verificação das propriedades do sistemaelétrico são avaliadas através da excursão das variáveis contínuas que representam os denomi-nados grau de satisfação. Os resultados dos testes apontam que a metodologia pode identificaratuações incorretas do sistema de proteção de maneira mais rápida e eficiente do que a análisemanual.
Ainda que a abordagem adotada pelos autores seja baseada em autômatos híbridos, assimcomo será abordado nesta dissertação, o procedimento adotado para análise dos sistemas deproteção está um pouco divergente do conceito de modelagem e verificação formal. Além damodelagem de mais elementos dos sistemas de proteção, este trabalho considerará a modelagemdas funções estatísticas que representam os modos de falhas de cada dispositivo. Antes daanálise do sistema de proteção com a integração entre os modelos, esta dissertação empregaráo método de verificação formal estatística com finalidade de validar o comportamento de cadamodelo individual. Também será considera a infraestrutura em que o sistema de proteção iráoperar, como sistemas de comunicação e protocolos de sincronização de relógios.
Além disso, no trabalho de Sengupta et al. (2015) a dinâmica das variáveis elétricasque modelam o comportamento do sistema elétrico são realizadas por um software de simula-ção à parte do verificador de modelos. Do ponto de vista de validação dos modelos adotadonesta dissertação, a modelagem do sistema elétrico não possui influencia no comportamentodos modelos, uma vez que pretende-se “emular” este comportamento através de funções de dis-tribuição de probabilidade. No entanto, para fins de simulação, serão desenvolvidos algoritmosque modelam o comportamento da dinâmica dos sistemas elétricos, porém, estes modelos serãodesenvolvidos na mesma ferramenta em que será modelado o sistema de proteção, não havendonecessidade de integração entre diversos softwares.
De um modo geral, entende-se que a verificação de propriedades adotada no trabalho deSengupta et al. (2015) pode se tornar parte de uma metodologia sistemática de desenvolvimento
45
e validação de projetos de Sistemas de Proteção, na etapa de testes de desempenho. Através dosresultados apresentados, demonstra-se que a ferramenta pode identificar atuações incorretas dosistema de proteção de uma maneira mais rápida e eficiente, quando comparada com os métodosmanuais de interpretação das simulações que fazem parte do processo de validação do sistemade proteção em análise.
Em Siqueira (2014) é proposta uma metodologia para modelagem e análise de algoritmosde controle envolvidos no processo de automação dos sistemas de geração de energia hidre-létrica. No trabalho em questão, a verificação formal compõe um procedimento sistemáticoe eficaz no desenvolvimento de algoritmos de controle em sistemas de automação, especifi-camente no controle de Unidades de Geração (UGs), antecedendo a etapa de implementação,propriamente dita. O procedimento de desenvolvimento do sistema de controle citado no traba-lho em questão é dividido em quatro fases, a saber: i) Especificação Informal representada pelosrequisitos do sistema de controle a ser desenvolvido e pelas informações e características do sis-tema físico (a ser controlado); ii) Especificação Formal do problema de controle, representadapela interação entre os modelos do sistema de controle e físico; iii) Verificação do Modelo dosistema de controle, baseado em técnicas de verificação formal; e iv) Implementação do modelodo sistema de controle, a qual inclui hardware e software, por meio da utilização de um IED,CLP ou outro tipo de controlador, juntamente com seu algoritmo de controle em uma lingua-gem de programação apropriada. Segundo os autores, o emprego desta metodologia garante oprojeto efetivo do sistema de controle, sendo que os erros de projeto são identificados ainda naetapa de modelagem do sistema.
O escopo do trabalho de Siqueira (2014) se limita nas fases de Especificação Formal eVerificação (fases ii e iii supracitadas). Em relação ao formalismo para modelagem do sistema(fase ii), os autores propõem uma extensão das Redes de Petri Interpretadas por Sinais, Redesde Petri Interpretada por Sinais Orientada por Objetos. Esse formalismo utiliza os concei-tos de componentização e decomposição do modelo do sistema em sub-redes e objetos, o quepermite a modularização do problema de análise. Outra vantagem do formalismo proposto é apossibilidade de criação de uma biblioteca de modelos permitindo a reutilização dos mesmos.Com relação à análise dos modelos (fase iii), propriedades funcionais que descrevem o compor-tamento do sistema são padronizadas pelos autores. A análise é feita com base na verificaçãodestas propriedades adaptadas ao novo formalismo. As propriedades que devem ser obrigatori-amente cumpridas são escolhidas de acordo com as exigências e tipos do sistema de controle.Desta forma, a mesma sistemática, de uma forma flexível, pode ser aplicada em outros tipos desistemas de controle (Siqueira, 2014).
Uma metodologia é proposta pelo autor de forma a construir e validar os modelos dossistemas de controle sistematicamente. Basicamente, este processo é dividido em três etapas,que são desdobradas em atividades, a saber: Etapa 1. Levantamento dos Requisitos, que com-preende as etapas de Especificação Formal, Elaboração do Diagrama PFS (do inglês ProductFlow Scheme); Etapa 2. Análise dos Requisitos, com as atividades Diagrama de Atividades e
46
Definição das Classes e Objetos; e Etapa 3. Projeto, que consiste nas atividades Elaboraçãodo Diagrama de Sequência e Comunicação, Modelagem das Classes e Objetos no formalismoproposto e Verificação.
Ainda no trabalho em questão, a metodologia proposta para modelagem e verificação dossistemas de controle é aplicada em um Sistema Hidráulico de Regulação de Velocidade (SHRV).Informações reais de um sistema SHRV típico foram utilizadas para construção dos modelos.De forma a reduzir a complexidade dos modelos, a utilização da metodologia proposta abrangeuos componentes e objetos mais significativos e representativos do sistema em análise. Como aetapa de verificação formal abordada no trabalho em questão antecede a etapa de implementaçãodo algoritmo de controle, através da verificação do SHRV proposto, constatou-se que o modeloatendeu as exigências de corretude formal, isto quer dizer que o algoritmo a ser construído deacordo com o modelo verificado pode ser implementado sem riscos de apresentar loops infinitosno programas, deadlocks, falta de inicialização (não retorno ao seu estado inicial) e ações decomandos conflitantes (valores contraditórios).
Diferente da abordagem proposta em Sengupta et al. (2015), Siqueira (2014) apresentauma metodologia sistemática para construção e validação dos modelos que compõem o sistemade controle. Após a validação do modelo do sistema de controle, o autor afirma que o algo-ritmo de controle pode ser elaborada com base no modelo em questão. Nos dois trabalhos nãoforam considerados a possibilidade de falha dos equipamentos e os modelos dos sistemas decomunicação entre os dispositivos.
Com relação à esta dissertação, a abordagem proposta por Siqueira (2014) se difere prin-cipalmente no formalismo de base. Enquanto o autor emprega uma extensão das Redes de Petri,esta dissertação usará o formalismo baseado em uma extensão dos Autômatos de Estados Fi-nitos. Outra diferença está no objeto da pesquisa, enquanto o escopo de Siqueira (2014) selimita em sistemas envolvidos no processo de automação de UGs, esta dissertação abrangerá osSistemas de Proteção e Monitoramento.
Em Kunz (2012) é feita a modelagem e validação do sistema de comunicação para anorma IEC 61850. Além do sistema de comunicação, é proposta a modelagem e validação dosprincipais dispositivos empregados em um sistema automático de transporte de passageiros, oSistema Aeromovel. Assim como em Siqueira (2014), a proposta de Kunz (2012) é o desen-volvimento de uma metodologia que garanta o projeto efetivo de controladores, porém, nesteúltimo, aplicados aos sistemas de proteção, operação e supervisão do Sistema Aeromovel. Paraisso, propõe-se uma ampliação da norma IEC 61850 de modo com que a mesma também sejaempregada nos sistemas de transporte.
Para o autor, a simulação e verificação formal da rede de autômatos não é suficientepara garantia de que os modelos propostos serão traduzidos corretamente em uma linguagemde programação pois, por exemplo, algumas operações efetuadas nos modelos em autômatostemporizados não são possíveis de serem implementadas em um controlador real, necessitando
47
novamente de outra correção no modelo. Nesse contexto, propõe-se também a inclusão de umaetapa denominada “testes de conformidade” no sistema, que consiste basicamente substituiçãode um modelo da rede de autômatos por um processo computacional ou equipamento físico queeste modelo representa. Nesta configuração, realizam-se também os processos de simulação everificação formal.
Além da etapa de especificação informal (levantamento de requisitos) e especificação everificação formal dos modelos, Kunz (2012) também adota a simulação como parte do pro-cesso de construção e validação dos modelos. O processo de modelagem, simulação e verifica-ção dos modelos é realizada através de uma abstração de autômatos temporizados, no aplicativoUPPAAL. A etapa de testes de conformidade dos modelos é realizada através de uma extensãodo UPPAAL, o UPPAAL TRON. Através da análise dos sinais de interface (saída e entrada), oUPPAAL TRON avalia se o comportamento do programa produzido está de acordo com o com-portamento do modelo em autômatos temporizados (Kunz, 2012).
Porém, com relação ao que será proposto nesta dissertação, os modelos desenvolvidos porKunz (2012) são baseados no formalismo clássico dos autômatos temporizados, representadosapenas por variáveis discretas e com taxas de avanço de relógio (clock) fixas. Apesar de queo sistema de controle seja inerentemente discreto, os sistemas físicos (objetos de controle) sãomelhores representados por funções contínuas. Na integração destes dois modelos, observa-seum comportamento híbrido, com evoluções de variáveis discretas e contínuas. Além disso, seráproposta a inclusão de modelos estatísticos que representam os modos de falhas dos principaisdispositivos. Nesse contexto, o processo de validação dos modelos será realizada através daferramenta de Verificação Formal Estatística.
Por fim, através de Kunz (2012), identifica-se também que o processo de modelageme verificação formal podem ser empregados como ferramentas de testes de conformidade deequipamentos.
48
Capítulo 3
Materiais e Métodos
No capítulo anterior, foram apresentados os conceitos básicos para contextualização eentendimento da abordagem proposta nesse trabalho. De maneira geral, propõe-se o empregoda técnica de verificação formal como ferramenta de suporte para a validação de Sistemas deProteção. Considerando o propósito em questão, a construção dos modelos se apresenta comoitem crucial da metodologia, logo, a mesma também deve ser suportada por um procedimentoformal de desenvolvimento. Neste capítulo serão apresentadas as considerações feitas no de-senvolvimento e validação dos modelos que representam a operação do sistema de proteção.
3.1 Modelagem do Sistema de Proteção
Além de se apresentar como uma abstração natural dos Sistemas de Proteção, a aborda-gem baseada em Autômatos Híbridos tem como vantagem a possibilidade de decomposiçãodo modelo do sistema em análise, geralmente complexo, em subsistemas mais compreensíveis.Cada subsistema representa o comportamento individual de determinado elemento e é modeladoatravés de um autômato. A integração dos modelos é realizada através da Composição Síncronaentre os autômatos (Cassandras & Lafortune, 2010), considerando as transições (eventos) quesão compartilhadas entre os modelos.
Nesse contexto, a obtenção de um modelo para o sistema de proteção pode então ser pen-sado como uma composição de modelos para seus subsistemas. Assim como os demais estudosna área de modelagem de sistemas, a representação dos subsistemas através de uma determinadaabstração depende de diversos fatores estabelecidos com o grau de realismo entre o modelo e ocomportamento físico ideal abordado no estudo, de forma a não comprometer a análise da qualo modelo será submetido, ou por escassez de recursos computacionais (modelo complexo), oupor modelo não fidedigno ao comportamento real (modelo simplificado). Visando este equi-líbrio, nesta dissertação buscou-se simplificar, quando possível, os modelos sem comprometerseu funcionamento.
49
50
Com a crescente motivação do emprego de redes Ethernet nas subestações de energiaelétrica, a estrutura do sistema de proteção adotado neste trabalho é baseado na indicação danorma IEC 61850, conforme apresentado na Figura 3.1. Nesta representação podem ser identifi-cados, principalmente, as Merging Units, os IEDs de proteção e controle e a estação de controleincluindo os sistemas SCADA e IHM, nos três níves de hierarquia propostos pela norma, Pro-cesso (Process), Vão (Bay) e Estação (Station), respectivamente. Os barramentos (Processo eEstação) que realizam a interface entre os níveis da subestação são representados por switches.Nota-se ainda nos barramentos do sistema de comunicação, que não está explícita a topologiada rede (estrela, anel ou variações destas), nem a quantidade de switches. Como a norma in-dica o protocolo PTP para sincronização dos relógios, um servidor de tempo é conectado aosBarramentos de Processo e Estação.
Intelligent
Eletronic Device
Intelligent
Eletronic Device
Intelligent
Eletronic Device
MU MU MU
GPSGPS
Mu1Mu2 Mun
Ethernet Switch
IED1 IED2 IEDn
Power Substation
Ethernet Switch
Process Bus
SCADA
Station Bus
Bay 1 Bay 2 Bay n
Switch
Switch
Engineering
station
Station Level
Bay Level
Process Level
Figura 3.1: Estrutura do sistema de proteção adotado.
Com relação à construção dos modelos do sistema de proteção, vale ressaltar que serãoconsiderados não apenas os dispositivos físicos que operam sobre o sistema, mas também oscontroladores e protocolos que realizam a função de comunicação entre os mesmos. Na Fi-gura 3.2 é apresentada a rede de autômatos considerando o sistema de proteção da Figura 3.1.Ainda que representados na Figura 3.2, os componentes pertencentes ao Nível de Estação não
51
serão abordados nesta dissertação, uma vez que pretende-se avaliar o comportamento do sis-tema de proteção durante a ocorrência de um distúrbio. Nesse contexto, o fluxo de informaçãono sistema de comunicação serão provenientes apenas das mensagens com critério de temporeal GOOSE, SV e PTP.
Circuit Breaker CT/VT
Merging
Unit
LAN
Process Level
Process Bus
IEDFunction A Function B Function C
Bay Level
LANStation Bus
SCADA ComU
Station Level
Time
Source
Power Substation
Modelos
Considerados
Modelos
Desconsiderados
PTP,
GOOSE,
SV
Figura 3.2: Rede de autômatos do sistema de proteção.
Referente aos modelos, o barramento de processo será representado por um modelo debarramento de comunicação, no qual estarão inclusos os efeitos (atraso de tempo e ordem demensagens) provenientes da pilha do protocolo de comunicação dos remetentes e destinatáriosdas mensagens e do meio físico (condutor). Estruturalmente, este modelo comportará a troca demensagens de tipos como PTP, SV e GOOSE, logo, será incorporado ao modelo a funcionali-dade de VLAN, para que cada tipo de mensagem esteja implementada em um modelo de LANdiferente. A modelagem do barramento de comunicação está descrita na Seção 5.1.
O desenvolvimento do protocolo de sincronização de relógios PTP é apresentado na Seção5.2. Nesta dissertação descreve-se apenas a etapa do protocolo relativa à troca de mensagensentre mestre e escravos, baseado no método two-step que a norma IEEE 1588 descreve.
O serviço de transmissão das mensagens GOOSE e SV, relativo à IEC 61850, são dis-cutidos na Seção 5.3. Estes protocolos implementam a comunicação entre os dispositivos queexecutam as funções de proteção no SAS, como Merging Units e IEDs.
52
Ao Nível de Processo, o modelo de Merging Unit é desenvolvido na Seção 5.4. Estemodelo também incorpora os modelos de TPs e TCs, do Nível de Processo, e dos serviços detransmissão GOOSE e SV. Já o modelo do disjuntor é apresentado na Seção 5.6.
Conforme ilustrado na Figura 3.2, o IED será subdivido em funções de proteção. Es-tas, também são segmentadas em conformidade com a IEC 61850. A descrição dos modelosassociados ao IED é apresentada na Seção 5.5.
3.2 Metodologia para Validação dos Modelos
Cada modelo será submetido à metodologia apresentada pela Figura 3.3, detalhada a se-guir:
Não
Sim
Não
SimSim
Não
Simulação
Comportamento
esperado
Início
Levantamento
de Requisitos
Modelagem
Requisitos
Atendidos?
Fim
Simplificação?
Verificação
Modelos de sistemas de
controle e de sistemas
físicos
Figura 3.3: Fluxograma para validação dos modelos. Fonte: Adaptado de Kunz (2012).
1. Levantamento de requisitos: dspecificação dos requisitos do equipamento ou controla-dor a ser modelado.
2. Modelagem: desenvolvimento dos modelos do equipamento/controle na forma de autô-matos temporizados híbridos;
3. Simulação: a etapa de simulação tem como objetivo verificar se o sistema possui com-portamento esperado conforme o especificado;
4. Verificação: a etapa de verificação tem por objetivo verificar formalmente se os requisitosdo modelo são completamente atendidos. No caso de não atender aos requisitos, volta-seà etapa de modelagem;
5. Simplificação: existe a possibilidade de realizar simplificações nos modelos de forma areduzir o esforço computacional no processo de verificação. Esta simplificação é neces-sária na integração entre dois modelos previamente validados individualmente.
53
As principais características operacionais dos modelos que representam os sistemas físi-cos e (quando aplicáveis) as variações eletromagnéticas e eletromecânicas dos sistemas elétricosserão representados por meio de equações diferenciais. Os principais eventos e modelos de fa-lhas dos sistemas físicos e de controle serão representadas por meio de funções de distribuiçãoestatísticas paramétricas. Nesse contexto, adotou-se como ferramenta de desenvolvimento oaplicativo UPPAAL STRATEGO, o qual suporta estas funcionalidades.
Além disso, com o UPPAAL é possível manipular as três etapas de desenvolvimento dosmodelos segundo a Figura 3.3: Modelagem, Simulação e Verificação. Entretanto, conformediscutido no capítulo anterior, as variáveis contínuas introduzem o problema de não decidibi-lidade aos modelos híbridos. Logo, de acordo com o tipo de modelo a ser verificado (discretoou híbrido) a etapa de verificação formal da metodologia proposta possui abordagens distintas(Verificação Formal Clássica ou Estatística).
3.3 Metodologia para Análise de Sistemas de Proteção
Uma vez construídos e validados os modelos dos subsistemas que representam o sistemade proteção, a integração destes permite a análise global do sistema de proteção. Em algunscasos, a validação dos modelos necessariamente deve ser integrada com outros, como por exem-plo, o modelo que representa o protocolo PTP deve ser composto pelos modelos de emissor ereceptor de mensagens, validados juntamente com o modelo da LAN.
Na Figura 3.4 é apresentada a operação sincronizada entre os modelos desenvolvidos. Asinterfaces entre os modelos são destacadas pelos círculos numerados (em vermelho) e represen-tam as transições compartilhadas pelos modelos, implementadas através de canais de sincroni-zação. Periodicamente, através das transições rotuladas em “0”, há uma troca de mensagensreferente ao protocolo PTP, entre o modelo Time Source, IED e Merging Unit, através da LAN.Também periodicamente, a Merging Unit lê as informações analógicas de tensão e corrente domodelo CT/VT (rótulo “1”) e envia os dados para a LAN através de mensagens SV (Rótulo“2”). Os dados relativos às funções de proteção do IED são recebidos e tratados. De acordocom a função de proteção implementada no IED, caso seja detectada alguma condição anormal,uma mensagem de trip via GOOSE é enviada aos disjuntores associados à esta falta (Rótulo 4e 5).
Conforme destacado no início da dissertação (Seção 1.3), a integração entre os modelosdesenvolvidos permite que a técnica de verificação formal seja empregada como ferramenta desuporte em outras linhas de pesquisa na área de Sistemas de Proteção, a saber: i) implemen-tação do controle da estratégia de proteção proposta, ii) testes de desempenho da estratégia deproteção para identificação de erros de projeto via simulações ou via técnica de Hardware inthe Loop e iii) externalização dos modelos para testes de conformidade em equipamentos reais.Estas linhas de pesquisa foram ilustradas na Figura 1.4.
54
Circuit Breaker CT/VT
Merging
Unit
LAN
Process Level
Process Bus
IEDFunction A Function B Function C
Bay Level
LANStation Bus
SCADA ComU
Station Level
Time
Source
Power Substation
PTP,
GOOSE,
SV
0
1
2
3
4
5
Figura 3.4: Operação integrada da rede de autômatos.
A aplicação das metodologias supracitadas e a relação entre os modelos desenvolvidosnesta dissertação são apresentadas na Figura 3.5. Na Figura 3.5.a a verificação formal é ado-tada como ferramenta de suporte para implementação de novas estratégias de proteção. Nestaabordagem, após a verificação formal sobre a rede de autômatos, garante-se que o autômatoque representa a funcionalidade da proteção esteja livre de erros de projeto. Nesse contexto,traduz-se o autômato para uma linguagem de programação a ser implementada no controlador.
Já na Figura 3.5.b, a verificação formal é empregada como guia para identificação deatuações incorretas do sistema de proteção. Após a modelagem do sistema de proteção emanálise, a verificação de propriedades pode identificar eventuais erros de lógica no sistema,como parametrização inadequada dos relés e problemas de coordenação.
Na Figura 3.5.c a verificação formal é apresentada como ferramenta de validação de equi-pamentos reais, ou denominada testes de conformidade. Neste exemplo, após a verificação darede de autômatos que representa o sistema de proteção, substitui-se o autômato que representao IED por um IED físico (real).
55
Salienta-se que para estas três metodologias, primeiramente faz-se necessário a validaçãode todos os modelos que compõem a infraestrutura, o que será abordado neste trabalho.
Circuit Breaker CT/VT
Merging
Unit
LAN
Process
Level
Process
Bus
IED
Function X
Bay
Level
Time
Source
Linguagem de
Programação
Implementação do controle
(a)
Circuit Breaker CT/VT
Merging
Unit
LAN
Process
Level
Process
Bus
IED
Function X
Bay
Level
Time
Source
Testes de desempenho/
Identificação de erros na lógica
(b)
Circuit Breaker CT/VT
Merging
Unit
LAN
Process
Level
Process
Bus
Bay
Level
Time
Source
Testes de conformidade
Intelligent
Eletronic Device
IED
Dispositivo
Sob Teste
(DUT)
(c)
Figura 3.5: Aplicações dos modelos desenvolvidos em ferramentas de suporte para a)implementação de estratégias, b) análise de desempenho de estratégias, e c) testes de
conformidade em equipamentos reais.
56
3.4 Aplicação da Metodologia no UPPAAL: Interação Relé-Disjuntor (Caso Exemplo)
De forma a demonstrar a aplicação das funcionalidades do aplicativo UPPAAL STRATEGO,será empregada (passo a passo) a metodologia proposta no desenvolvimento e validação dosmodelos que representam o sistema de proteção. O processo de desenvolvimento dos modelosserá dividido em atividades conforme indicado pela Figura 3.3, do Capítulo 3.
O subsistema adotado como exemplo é uma simplificação da interação entre um relé edois disjuntores. Pode-se observar esse comportamento, por exemplo, através do trip enviadopor uma função de proteção diferencial aos dois disjuntores associados ao elemento protegido,conforme ilustrado na Figura 3.6. Salienta-se que este exemplo tem finalidade apenas de de-monstração do emprego detalhado da metodologia de modelagem e validação proposta nestetrabalho. Logo, de forma a reduzir a complexidade de desenvolvimento do subsistema emquestão, serão desconsiderados alguns comportamentos do modelo, como o processo de amos-tragem e condicionamento dos sinais que alimentam o relé e sua respectiva lógica da função daproteção e o comportamento do sistema de comunicação entre o relé e os disjuntores.
A
B
C D E
F
Bay
Controller
21
87
Figura 3.6: Exemplo de função diferencial (Caso Exemplo).
Inicialmente, identifica-se que o comportamento que será modelado neste exemplo podeser composto, naturalmente, por dois subsistemas (rede de autômatos): Relé e Disjuntor. Estesmodelos são representados na Figura 3.7.
Circuit Breaker 1
Relay
Circuit Breaker 2
Trip
reset
Trip
reset
Figura 3.7: Modelos considerados no Caso Exemplo.
57
Conforme observa-se na Figura 3.7, a interação entre os autômatos se dá através do com-partilhamento das transições trip e reset. Basicamente, quando o modelo Relé identifica a ocor-rência de uma falta, envia um comando de trip aos dois modelos Disjuntor. Por sua vez, quandoo modelo Disjuntor recebe um comando de trip, seus terminais são abertos de forma a isolar ocircuito que esteja sob defeito. Admite-se, neste exemplo, que a falta é eliminada instantanea-mente após o envio do comando de trip do relé. A construção e validação dos modelos se daráindividualmente para cada dispositivo (Relé e Disjuntor), e em seguida é realizada a integraçãoentre os modelos.
A seguir, são apresentadas as etapas de desenvolvimento dos modelos segundo a metodo-logia apresentada no Capítulo 3. As atividades podem ser divididas em: 1) Levantamento deRequisitos; 2) Modelagem; 3) Simulação; 4) Verificação; e 5) Simplificação (vide Figura 3.3).
3.4.1 Modelo Relé no Caso Exemplo
Etapa 1: Levantamento de Requisitos
No contexto da abordagem proposta nesta dissertação, o Levantamento de Requisitos con-siste na descrição técnica do sistema a ser modelado e o seu comportamento esperado, consi-derando o grau de realismo adequado à finalidade de sua análise. Como a modelagem consisteem um exemplo simples para demonstração da teoria, o grau de realismo do modelo do relénão é elevado. Em outras palavras, como se deseja avaliar a interação entre relé e disjuntor,alguns subsistemas do relé não serão considerados, como as etapas de amostragem e condici-onamento dos sinais, funções lógicas que o relé implementa, algoritmos para tratamentos dosdados, tempo de processamento, circuito de alimentação, entre outros. Portanto, para o estudoem questão considera-se os seguintes requisitos operacionais:
• Ausência de Deadlock: O modelo desenvolvido não deve travar em hipótese alguma, umavez que trata-se de um componente crítico do sistema de proteção;
• Comportamento Esperado: Para fins de verificação, este requisito considera que as saídasdo relé devem estar de acordo com a função que lhe é esperada, ou seja, o relé não podeenviar um comando de trip caso não seja detectada uma condição de falta, e o contrário,ao detectar a falta, o relé deve enviar o trip do modo mais rápido possível.
Etapa 2: Modelagem
Diante dos requisitos postulados na subseção anterior, uma possível abstração do compor-tamento do Relé para a análise em questão é apresentada na Figura 3.8.a. O modelo é compostopor três estados, checking, check e fault. O estado checking abstrai os blocos funcionais res-ponsáveis pela execução da função lógica do relé, como circuitos de filtros e de amostragem e
58
retenção dos sinais de entrada (sample and holder) e cálculos matemáticos para representaçãodas amostras de acordo com a função específica do relé. No modelo, a cada unidade de tempot, faz-se uma verificação na presença de uma operação anormal do sistema elétrico, através davariável f_detec. Para efeitos de análise, considera-se a unidade de tempo t como ciclo de scando relé. Logo, caso no próximo ciclo da lógica computacional do relé seja detectada a ocorrên-cia de uma falta no sistema elétrico, o relé vai para o estado fault. Na transição entre estes doisestados, um comando de trip é enviado aos disjuntores associados ao circuito sob falta. O enviodeste comando é realizado através do canal síncrono Trip, rotulado por Trip!. O estado fault domodelo indica que o relé detectou uma condição anormal e enviou um comando para aberturados disjuntores. Ele fica nesse estado até que o operador habilite-o novamente, após a devidalocalização e correção do defeito que originou a abertura dos disjuntores. O evento de reseté modelado através de uma transição aleatória baseada na função de distribuição exponencialcom taxa unitária.
Figura 3.8: Representação em Autômatos Temporizados do modelo Relé no Caso Exemplo.
Etapa 3: Simulação
De forma a avaliar o comportamento do modelo Relé, do ponto de vista da simulação,foi desenvolvido um autômato que implementa a detecção das faltas aleatoriamente, denomi-nado aqui como Fault_Detect e representado pela Figura 3.9. O modelo é composto por trêsestados: norm_cond, fault_cond e trip_cond, que indicam operação normal, falta detectada etrip enviado pelo relé, respectivamente. O modelo permanece na condição normal até que umatransição, modelada por uma função de distribuição exponencial com taxa igual a 1/3, leve-opara a condição de falta. Cabe comentar aqui que no modelo em questão utilizou-se a função dedistribuição exponencial por ser nativa ao UPPAAL, porém, caso seja necessário, outras funçõespodem ser utilizadas como geradoras de eventos aleatórios, conforme apresentado anterior-mente na etapa de modelagem estatística. No próximo ciclo de scan do relé, a falta é detectadae um comando de trip é enviado pelo modelo Relé. A mensagem de trip é lida também pelomodelo Fault_Detect, que o leva para o estado trip_cond. Considera-se que o envio de trip dorelé elimina instantaneamente a falta. O modelo fica neste estado até que haja um reset no relé.
59
Figura 3.9: Autômato que implementa a ocorrência de faltas no sistema elétrico para o modeloRelé.
Além do desenvolvimento do modelo Fault_Detect, foram empregadas algumas variáveisque auxiliam na análise dos resultados. A variável do tipo inteiro aux_trip indica o estadológico do sinal de trip (1 ou 0) e o relógio tfault, que representa o tempo de eliminação da falta.No UPPAAL, os estados dos autômatos também podem ser empregados como variáveis lógicas,sendo que a ocorrência de determinado estado leva sua variável lógica para nível alto. Pararepresentar o fim do ciclo de scan do relé foi utilizado o estado check do relé (Figura 3.8).
Diversas simulações envolvendo a rede de autômatos formada pelos modelos Relé eFault_Detect foram analisadas. Na Figura 3.10 é apresentada uma destas. São destacadasas variáveis do tipo Relógio tfault (tempo de eliminação da falta) e do tipo lógico scan (estadocheck), f_detect e aux_trip. A variável check indica o ciclo de scan do relé. A cada amostragem(considerado 1 unidade de tempo), verifica-se se há uma condição de falta no sistema (variávelf_detec), caso positivo, imediatamente é enviada uma mensagem de trip. Conforme conside-rado na etapa de modelagem, a eliminação da falta se dá instantaneamente após a ocorrência deum trip. Esse comportamento é observado na simulação através da borda de subida da variávelde trip, onde é acompanhado da borda de descida da variável t_fault. A borda de descida davariável aux_trip indica o reset do relé.
time (t)0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
sign
als
Fault/ Scan
Trip
00.250.5
3.751
f_detec - Logicalcheck - Logicalaux_trip - Logicalt_fault(t) - Clock
Figura 3.10: Simulação da rede de autômatos Relé + Fault_Detect.
60
Da Figura 3.10, também é possível concluir que o tempo de eliminação da falta (tfault)depende do início da sua ocorrência com relação ao início do ciclo de scan. A falta é identificadaapenas ao final de cada ciclo de scan (pulsos da variável check). Logo, quão mais perto do iníciodo ciclo de scan ocorre a falta, maior o tempo necessário para o relé identificar a falta. Nessecontexto, também espera-se que o tempo máximo de identificação da falta é 1 ciclo de scan (1unidade de tempo t).
Por fim, através da análise manual dos resultados da simulação, conclui-se que o sistemaapresenta comportamento de acordo com o esperado. Logo, avança-se para a próxima etapa,Verificação Formal, de forma a avaliar mais profundamente o comportamento do sistema emquestão.
Etapa 4: Verificação Formal
Com base na especificação informal definida na etapa de Levantamento de Requisitos,formulou-se as propriedades necessárias para verificação do modelo em questão. Estas pro-priedades são descritas informal e formalmente na Tabela 3.1, juntamente com o resultado dasverificações. Por se tratar de um modelo simples, não é necessária a etapa de simplificação(Etapa 5). Os testes foram realizados em um notebook Dell Inspiron Intel(R) Core(TM) i5-5200 CPU @2.2GHz (4 Gb RAM) em cerca de 0,034 segundos.
Tabela 3.1: Verificações sobre o modelo Relé para o Caso Exemplo.
Descrição Informal Descrição Formal PropriedadeSatisfeita
Verifica a ausência de deadlock nomodelo
A[] not deadlock Sim
Verifica a relação entre detecção defalta e geração de comando trip.• Sempre que houver a detecçãode falta, o relé deve enviar um co-mando trip;• O relé não pode enviar comandode trip sem que falta identificada.
A[] not (Relay.faultand f_detec == false)
Sim
E<> (Relay.fault and(f_detec == false))
Não
Verifica o tempo de eliminação dafalta. Deve ser menor do que 1 ciclode scan do Relé.
E<>(Fault_Detec.fault_cond)and (tfault>1)
Não
A[] not( Relay.faultand (tfault<=1 andFault_Detec.fault_cond))
Sim
61
3.4.2 Modelo Disjuntor no Caso Exemplo
Etapa 1: Levantamento de Requisitos
Com relação ao comportamento esperado do disjuntor no Caso Exemplo, serão conside-rados os seguintes requisitos:
• Ausência de deadlock;
• Comportamento Determinístico: Sempre que receber um comando de trip, o disjuntordeve abrir seus terminais, exceto em condições de falha mecânica durante a abertura;
Etapa 2: Modelagem
Na Figura 3.11 é apresentado o modelo proposto que representa o comportamento do dis-juntor para o estudo em questão. Basicamente, o modelo é representado por cinco estados: idle,arcing, open, stuck e block. Inicialmente, o disjuntor está no estado idle (inativo), que repre-senta sua condição normalmente fechada. Ao receber um comando de trip, o disjuntor iniciao processo de abertura dos seus terminais, representado no modelo pelo estado arcing. Esseprocesso é representado por um atraso de tempo entre 2 e 5 unidades de tempo t. Considera-sea possibilidade de que o disjuntor não consiga, por consequência de uma falha mecânica, abriros seus terminais. Essa possibilidade é representa através de pesos nas transições que levam odisjuntor ao estado de operação normal e falha, sendo 90% de sucesso e 10% de chance de falha.Salienta-se que poderia ser proposto um autômato que implementasse a função de distribuiçãoda falha (semelhante à Figura 3.22), porém, como o modelo em questão trata-se apenas de umexemplo para demonstrar a aplicação da ferramenta, adotou-se uma solução mais simples. Porfim, o Disjuntor fica bloqueado até que o operador identifique e corrija o defeito que originou otrip.
Figura 3.11: Representação em Autômatos Temporizados do modelo Disjuntor para o CasoExemplo.
62
Etapa 3: Simulação
Para permitir avaliar o comportamento do modelo disjuntor através de simulações, foidesenvolvido um autômato que implementa a geração de eventos de trip aleatoriamente, apre-sentado na Figura 3.12. Assim como na modelagem do relé, algumas variáveis também foramadotadas para auxílio da avaliação do comportamento do modelo: as variáveis do tipo inteiroaux_trip, aux_open e aux_stuck indicam o estado lógico do sinal de trip, estado disjuntor abertoe estado disjuntor em falha, respectivamente.
Figura 3.12: Autômato que implementa a geração aleatória de trips.
Na Figura 3.13 é apresentada uma simulação para o modelo Disjuntor. A diferença detempo entre as bordas de subidas dos sinais Trip, Open e Stuck indicam o tempo em que omodelo ficou no estado arcing. Em um intervalo de tempo de 50 unidades de t, ocorreram 7eventos de trip, dos quais, em apenas 1 evento o Disjuntor falhou. De acordo com a Figura3.13, considera-se que o comportamento apresentado pelo modelo Disjuntor corresponde, ini-cialmente, corresponde ao esperado com a etapa de Levantamento de Requisitos.
time0 5 10 15 20 25 30 35 40 45 50
Trip
Open
Stuck
Figura 3.13: Simulação da rede de autômatos Relé/Disjuntor no Caso Exemplo.
Etapa 4: Verificação Formal
Na Tabela 3.2 estão apresentadas as verificações realizadas sobre o modelo Disjuntor, deacordo com a etapa de Levantamento de Requisitos. Assim como na verificação do modeloRelé, não foram necessárias simplificações no modelo.
63
Tabela 3.2: Verificações sobre o modelo Disjuntor no Caso Exemplo.
Descrição Informal Descrição Formal PropriedadeSatisfeita
Verifica a ausência de deadlock nomodelo
A[] not deadlock Sim
Verifica o comportamento básico deoperação do disjuntor.• O disjuntor pode abrir;• O disjuntor pode travar;• O disjuntor pode estar aberto e fe-chado ao mesmo tempo;• O disjuntor pode operar sem rece-ber comando de trip
E<>Circuit_Breaker.open
Sim
E<>Circuit_Breaker.stuck
Sim
E<>(Circuit_Breaker.openandCircuit_Breaker.stuck)
Não
E<>(Circuit_Breaker.openorCircuit_Breaker.stuck)and (aux_trip==0)
Não
3.4.3 Integração entre os Modelos no Caso Exemplo
A interação entre relé e disjuntores, proposta como exemplo para aplicação da metodo-logia desta dissertação, foi subdividida em dois sistemas (autômatos): modelo Relé e modeloDisjuntor. Ainda que a validação dos modelos desenvolvidos para o Caso Exemplo desta Se-ção se deu através de um processo formal, do qual pode-se afirmar que a abstração realizadarepresenta o o comportamento esperado dos subsistemas considerados, não há garantias de quea rede de autômatos formada pela integração dos modelos individuais esteja representando cor-retamente o comportamento esperado do sistema global. Isso acontece porque a composiçãosíncrona entre os autômatos pode conter estados ou transições que dependam dos mesmos re-cursos (eventos ou variáveis), gerando novos estados que não são desejáveis ao funcionamentodo sistema (Cassandras & Lafortune, 2010). Ainda com o objetivo de aplicar passo a passo ametodologia de modelagem e verificação formal no aplicativo UPPAAL, esta subseção apresentaas atividades realizadas sobre a integração dos modelos Relé e Disjuntor.
Etapa 1: Levantamento de Requisitos
Para efeitos de análise de comportamento esperado do sistema global descrito no CasoExemplo, consideram-se os seguintes requisitos:
• Ausência de deadlock: a integração entre os modelos não pode gerar estados sem saídas;
• Comportamento esperado: Sempre que o relé identificar uma falta, deve ser enviado umcomando de trip aos dois disjuntores, que por sua vez deverão abrir seus terminais, exceto
64
em condições de falhas. Os disjuntores devem operar de forma síncrona ao trip, ou seja,o mesmo trip deve comandar a abertura dos disjuntores. Os disjuntores não podem sairdo estado inativo sem que haja uma condição de falta detectada pelo relé.
Etapa 2: Modelagem
De forma a integrar os modelos desenvolvidos nas etapas anteriores, algumas alteraçõesforam realizadas nos autômatos. Primeiramente, o modelo Disjuntor foi alterado de forma apermitir que o mesmo modelo represente mais disjuntores, explicitando aqui a vantagem dereuso dos modelos. Também foi introduzido ao modelo um estado que antecede a tentativa deabertura dos disjuntores. O modelo e as variáveis que o compõem foram atribuídos de parâme-tros de identificação, conforme apresentado na Figura 3.14.a. O funcionamento do modelo emquestão é o mesmo que discutido na subseção anterior. Com relação ao modelo Relé, apenasalterou-se o evento de Reset. Antes, o relé emitia esta mensagem, agora ele recebe (de Reset!para Reset?). Esta alteração foi motivada pelo seguinte motivo, anteriormente, considerava-seque a emissão do comando trip removia imediatamente a falta. No modelo integrado, a falta éremovida somente após a abertura do disjuntor, cujo evento possui atraso entre 2 e 5 unidadesde tempo t.
(a)
(b)
Figura 3.14: Adaptações aos modelos a) Disjuntor e b) Relé, no Caso Exemplo.
65
Etapa 3: Simulação
O comportamento da rede de autômatos formada pela integração entre o modelo Relée dois modelos Disjuntores foi avaliado através de diversas simulações computacionais. NaFigura 3.15 é apresentada uma simulação a qual demonstra que o comportamento do sistemaparcialmente está de acordo com o esperado. Observa-se que ao fim de cada ciclo de Scan domodelo Relé (variável check), na presença de uma falta (f_detec) o relé envia um comando detrip aos modelos Disjuntor (variável Relay_Trip). O trip é recebido pelos disjuntores ao mesmotempo (aux_trip(0,1)). Após um determinado tempo, que representa o processo de aberturado disjuntor, os disjuntores abrem (aux_open). Não foram encontradas operação de falha nosdisjuntores para o cenário apresentado pela Figura 3.15.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Fault/Scan
Relay_Trip
aux_trip
aux_open
aux_stuck
f_deteccheckRelay_Tripaux_trip(0)aux_open(0)aux_stuck(0)aux_trip(1)aux_open(1)aux_stuck(1)
Figura 3.15: Simulação considerando a rede de autômatos formada no Caso Exemplo.
Um problema encontrado na simulação apresentada na Figura 3.15 está na sincronizaçãodo evento Reset do relé e dos disjuntores. Nota-se que a variável Relay_Trip tem seu valoralterado para nível zero na borda de descida do primeiro disjuntor que completa o evento deabertura, variáveis aux_trip. A princípio, esta incoerência não afeta significativamente no com-portamento do sistema, porém, a mesma será melhor analisada na etapa de verificação formal.
Etapa 4: Verificação
De forma a verificar as propriedades postuladas na etapa de Levantamento de Requisitos,implementou-se um observador para analisar o envio e recebimento dos comandos de trip narede de autômatos. O observador implementado é apresentado na Figura 3.16. Basicamente, omodelo conta o número de trips enviado pelo relé e recebido pelos disjuntores. Estas variáveisauxiliam na verificação da operação dos relés para o mesmo evento de trip.
66
Figura 3.16: Modelo Observador para o Caso Exemplo.
Na Tabela 3.3 estão apresentadas as verificações realizadas sobre o modelo. Os resul-tados das verificações realizadas sobre a rede de autômatos indica problemas de modelagemresultante da integração dos subsistemas. Conforme apresentado na Tabela 3.3, algumas propri-edades não convergiram, como a verificação de deadlock e da ocorrência de alguns estados domodelo. Por fim, através da última propriedade verificada na tabela em questão, nota-se que aocorrência entre o evento de trip e abertura dos disjuntores não estão sincronizados, ou seja, nãoé o mesmo comando de trip que leva o disjuntor a atuar. Através do contra-exemplo gerado poresta verificação, identificou-se que os autômatos saem do sincronismo nos eventos de Reset domodelo, assim como apresentado na simulação da Figura 3.15. O problema ocorre quando umdos disjuntores dispara um evento de Reset ao relé, que por sua vez, volta ao estado checking.Caso o relé envie um sinal de trip antes que o segundo disjuntor saia também do estado block,ocorre o problema de sincronismo entre os autômatos. Lembrando que isto acontece pois os ca-nais de sincronização do tipo broadcast não são bloqueantes, conforme discutido na introduçãoao UPPAAL.
Tabela 3.3: Verificações sobre o modelo global do Caso Exemplo.
Descrição Informal Descrição Formal PropriedadeSatisfeita
Verifica a ausência de deadlock nomodelo
A[] not deadlock Não Converge
Verifica o comportamento básico deoperação do modelo.• O relé pode identificar faltas;• Os disjuntores podem abrir ou fe-char;• Os disjuntores podem atuar sem aidentificação de falta pelo relé;• Verifica o sincronismo de opera-ções entre disjuntores e relé
E<> (Relay.fault) SimE<> (CB1.open orCB1.stuck) and(CB2.open or CB2.stuck)
Não Converge
E<> Relay.fault and(CB1.idle and CB2.idle)
Não Converge
A[] not(CB1.blockand not(cont_Trip ==cont_TripReceiver[0])and CB2.block andnot(cont_Trip ==cont_TripReceiver[1]))
Não
A metodologia proposta nesta dissertação indica que em casos de problemas nas etapasde simulação e verificação, a modelagem do sistema deve ser refeita, de modo a corrigir aincoerência do modelo. Baseado nos resultados das simulações e na verificação formal sobre
67
o modelos, a correção foi dirigida ao evento de Reset entre os autômatos. Na Figura 3.17 estárepresentado o modelo atualizado do autômato relé. Neste novo modelo, o relé só retorna aoestado normal de funcionamento após o envio de todos os eventos de reset dos disjuntores.Embora não apresentado, nos modelos disjuntores apenas implementou-se a identificação doseventos de reset, na forma Reset[Id]!.
Figura 3.17: Correções ao modelo Relé.
De acordo com a metodologia proposta no Capítulo 3, o novo modelo deveria ser sub-metido a novas simulações, porém, esta etapa foi desconsiderada neste exemplo. A nova redede autômatos foi então verificada sob as mesmas verificações do modelo anterior. O resultadodas verificações é apresentado na Tabela 3.4, e indicam, finalmente, que a rede de autômatosformada pelos modelos Relé e Disjuntores, desenvolvidos nesta subseção, representam adequa-damente a interação entre relés e disjuntores proposta neste exemplo. Salienta-se que estesmodelos foram simplificados de forma a exemplificar o emprego da metodologia sobre os sub-sistemas que irão compor o sistema de proteção adotado nesta dissertação.
Tabela 3.4: Verificações sobre o modelo corrigido para o Caso Exemplo.
Descrição Informal Descrição Formal PropriedadeSatisfeita
Verifica a ausência de deadlock nomodelo
A[] not deadlock Sim
Verifica o comportamento básico deoperação do modelo.• O relé pode identificar faltas;• Os disjuntores podem abrir ou fe-char;• Os disjuntores podem atuar sem aidentificação de falta pelo relé;• Verifica o sincronismo de opera-ções entre disjuntores e relé
E<> (Relay.fault) SimE<> (CB1.open orCB1.stuck) and(CB2.open or CB2.stuck)
Sim
E<> Relay.fault and(CB1.idle and CB2.idle)
Não
A[] not(CB1.blockand not(cont_Trip ==cont_TripReceiver[0])and CB2.block andnot(cont_Trip ==cont_TripReceiver[1]))
Sim
68
3.5 Implementação de Funções de Geração de Números Ale-atórios Baseados em Funções de Distribuição de Proba-bilidade Paramétricas
Os principais eventos e modelos de falhas dos dispositivos eletrônicos e eletromecânicosempregados no sistema de proteção, assim como a representação dos eventos de distúrbioselétricos como posição, tipo e resistência de falta serão representados por meio de funçõesde distribuição paramétricas no UPPAAL STRATEGO. Conforme abordado anteriormente, estaversão do UPPAAL permite a representação de sistemas através de redes de autômatos cujocomportamento seja de natureza estocástica.
Com relação à implementação estatística, por padrão, o UPPAAL contém duas funções dedistribuição: i) distribuição uniforme, através das invariantes presentes nos estados e através dafunção random() e ii) distribuição exponencial, através do parâmetro Rate of Exponential, pre-sente na definição dos estados. Em geral, no UPPAAL estas funções de distribuição são empre-gadas no controle dos disparos de transições da rede de autômatos. Além dessa funcionalidade,esta dissertação adota estas funções para representação de fenômenos não determinísticos comodelay no barramento de comunicação e modelos de falhas de componentes.
A partir da versão 4.0 do UPPAAL, é possível a definição de novas funções definidas pelousuário através de uma linguagem semanticamente semelhante à linguagem C, o que possibilitaa implementação de outras distribuições de probabilidade. Nesse contexto, implementou-se ge-radores de números aleatórios baseados nas principais funções de distribuição empregadas emestudos de confiabilidade de sistemas críticos: Normal, Log-Normal e Weibull. Para implemen-tação das funções que geram variáveis aleatórias baseadas nas funções de distribuição supra-citadas, existem na literatura diversas técnicas como Método de Inversão, Aceitação-Rejeição,Quociente de Uniformes, Composição, Soma de Doze Uniforme (ou Método da Convolução),Box-Muller, Variante de Marsaglia e Ahrens-Dieter (Schutz, 2012), que utilizam-se do algo-ritmo que gera valores aleatórios baseados na função de distribuição uniforme, neste caso, nativaao UPPAAL. A seguir, são apresentadas as funções de distribuição e seus respectivos geradoresde números aleatórios:
• Exponencial
– FDP: f(x) = λe−λx
– Gerador (Método de Inversão): xexp = − ln(Unif())λ
• Normal
– FDP: f(x) = 1√2πσ2
e
[− 1
2(x−µσ )2]
– Gerador (Box-Muller): xnorm = µ+ σ√−2 ln (Unif()) · cos (2πUnif())
69
• Log-normal
– FDP: f(x) = 1
x√
2πσ2e
[− 1
2( log x−µσ )
2]
– Gerador (Box-Muller): xlnorm = exnorm
• Weibull
– FDP: f(x) = kc
(xc
)k−1 · e−(xc )k
– Gerador (Inversão): xwb = c · k√− ln (Unif())
Os geradores de números aleatórios foram implementados em funções globais no aplica-tivo UPPAAL, de modo com que possam ser utilizadas por qualquer modelo da rede de autôma-tos. A chamada das funções é realizada através do campo update das transições dos autômatos.
Na Figura 3.18.a é apresentada uma aplicação para geração de números aleatórios ba-seados nas distribuições implementadas. A cada 1 unidade de tempo t, a transição ocorre ea variável x recebe a variável aleatória de acordo com a distribuição desejada. Nota-se que achamada da função deve ser acompanhada de seus respectivos parâmetros. Outro exemplo deaplicação das funções de distribuição implementadas é apresentada na Figura 3.18.b. Nestaaplicação, a variável “delay” recebe o número aleatório de acordo com a função de distribuiçãodesejada e aguarda no estado wait até que o relógio “x” (com taxa de avanço unitária) atinja oseu valor (delay). A implementação das funções de distribuição de probabilidade são apresen-tadas na Figura 3.19. O modelo representado pela Figura 3.18.a foi utilizado para comparaçãocom funções de distribuição implementadas no RStudio e Matlab. Foram geradas um númerosignificativamente grande de amostras (60.000) para cada função de distribuição.
x = f(parameters),
t = 0
gen
t<=1
t == 1
(a)
delay = f(parameters),
x = 0
x<=delay &&
delay’==0delay’==0
x == delayinit wait end
(b)
Figura 3.18: Modelos para avaliação das funções de distribuição a) via simulação; e b) viaverificação formal.
As Figuras 3.20.a e 3.20.b apresentam a comparação das funções densidade de probabi-lidade e de distribuição acumulada, respectivamente, entre as variáveis aleatórias geradas pelaimplementação no UPPAAL e de variáveis geradas pelo Matlab. Através da Figura 3.20, nota-seque os geradores de números aleatórios implementados no UPPAAL estão em conformidade comas funções de distribuição de programas consolidados na literatura, como é o caso do Matlab.Além disso, a Tabela 3.5 apresenta a comparação entre os parâmetros de cada função de distri-buição, de onde também é possível a indicação da associação entre as funções de distribuiçãode probabilidade implementadas.
70
1 // ====================================================2 // MODELOS DE DISTRIBUIÇÃO DE PROBABILIDADE3 // ====================================================4 const double PI = 3.14159265358979323846;5 // Distribuição Uniforme (Nativa do Uppaal)6 double runif() {7 return random(1.0);8 }9 // Distribuição Exponencial (Inversão)
10 double rexp(double roe){11 return -ln(runif())/roe;12 }13 // Distribuição Normal (Box-Muller)14 double rnorm(double mean, double standardDeviation){15 double r = sqrt(-2.0*ln(random(1.0)));16 double theta = 2.0*PI*random(1.0);17 return mean + standardDeviation*r*cos(theta);18 }19 // Distribuição LogNormal (Box-Muller)20 double rlnorm(double mu, double sigma) {21 double m = ln(pow(mu,2)/sqrt(sigma + pow(mu,2)));22 double s = sqrt(ln(sigma/(pow(mu,2))+1));23 return exp(rnorm(m,s));24 }25 // Distribuição de Weibull (Inversão)26 double rweibull(double scale, double shape) {27 double a = 1.0 / shape;28 double b = -ln(runif());29 return scale*pow(b,a);30 }31 // Distribuição tipo U (Método de inversão)32 double rushaped(double inf, double sup){33 return ((inf+sup)/2 + (sup-inf)/2 *sin(2*PI*runif()));//+rnorm(0.5,0.1); Ruído34 }
Figura 3.19: Implementação das funções de distribuição de probabilidade.
-5 -4 -3 -2 -1 0 1 2 3 4 5 6 7 8 9 10
x
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
f(x)
Norm_MatlabNorm_UppaalLnorm_MatlabLnorm_UppaalWeibull_MatlabWeibull_UppaalExp_MatlabExp_Uppaal
Norm_Uppaal
Norm_Matlab
Exp_Matlab
Exp_UppaalLnorm_Matlab
Lnorm_Uppaal
Weibull_Uppaal
Weibull_Matlab
(a) (b)
Figura 3.20: Comparação entre os modelos geradores de números aleatórios a) funçãodensidade de probabilidade, e b) função cumulativa.
Já com relação ao modelo da Figura 3.18.b, a validação dos algoritmos pode ser reali-zada através do processo de verificação formal. Através da ferramenta de verificação formalestatística, pode ser determinada a probabilidade (e a curva de distribuição) do sistema atingiro estado end (no caso em questão). Pare que se obtenha a curva de distribuição com todos ospontos, deve-se garantir que a query possua um tempo x suficiente para que o autômato chegueao estado end.
71
Tabela 3.5: Comparação entre as funções de distribuição de probabilidade implementadas.
FunçãoMédia Média Desvio Padrão Desvio PadrãoMatlab UPPAAL Matlab UPPAAL
Exponencial 1, 0011 1, 0045 0, 9986 1, 0085Normal −0, 0039 −0, 0022 0, 9971 1, 0011
Log-Normal 2, 0016 2, 0011 0, 9999 1, 0052Weibull 2, 7100 2, 7104 1, 8378 1, 8346
Na Figura 3.21 são apresentados a densidade de probabilidade das funções de distribuiçãoimplementadas. Foram consideradas as queries “Pr[t <= 1000](<> functions.end)”. Nota-se através da densidade de probabilidade das funções apresentada na Figura 3.21 que todasas amostras são enquadradas dentro do intervalo de 0 a 100 unidades de tempo t. O limitede cada query poderia ser reduzido até o máximo valor pela densidade de probabilidade dafunção associada a esta query. Nestes testes, foram consideradas um grau de confiabilidadede 99,9%, com incerteza de 5 · 10−5. Para estes parâmetros, a ferramenta de verificação gerou69075 amostras, conforme apresenta a Figura 3.21. Como todas as amostras se enquadraram nointervalo considerado (1000 unidades de tempo), a probabilidade de cada função de distribuiçãoatingir o estado end foi de 100%, conforme ilustra a legenda de cada função densidade deprobabilidade.
72
(a) (b)
(c) (d)
(e)
Figura 3.21: Densidade de probabilidade das funções a) uniforme, b) exponencial, c) normal,d) lognormal e e) weibull.
3.5.1 Exemplo de Aplicação em Estudos de Confiabilidade
Como exemplo simples de aplicação e validação das funções de distribuição implemen-tadas no UPPAAL, é realizado um estudo de confiabilidade de um disjuntor, ilustrado na Figura3.22. O estudo é realizado por uma rede de autômatos composta por três modelos (templates).O autômato que representa o disjuntor está representado na Figura 3.22.b. Basicamente, estemodelo recebe comandos de trips e tenta abrir seus terminais. Em caso de sucesso, o disjuntorvai para o estado Open, em caso de falha, vai para o estado Stuck. O autômato que modela adistribuição de falhas do disjuntor é representado na Figura 3.22.c. Uma distribuição exponen-
73
cial com taxa 1/10 é empregada para representar a probabilidade de falha do disjuntor. Segundoa teoria de confiabilidade, esta distribuição é adequada por apresentar taxa de falha constanteao parâmetro Tempo Médio Entre Falhas – MTBF. No exemplo em questão, considera-se que odisjuntor possua um MTBF de 10 anos, logo, a unidade de tempo t no UPPAAL corresponde otempo em anos.
(a) (b) (c)
Figura 3.22: Rede de autômatos representando para teste de confiabilidade em um disjuntor.Modelos: a) Gerador aleatório de trips, b) Disjuntor e c) modo de falha
O estudo de confiabilidade neste exemplo consiste em avaliar a disponibilidade (ou in-disponibilidade) do disjuntor em um determinado período de tempo. As análises foram reali-zadas com 99% de grau de confiabilidade e 5 · 10−3 de tolerância. Nas Figuras 3.23.a e 3.23.bestão apresentadas as densidades de probabilidade para que o disjuntor falhe em um períodode 10 e 50 anos, respectivamente. As queries utilizadas nesta análise foram Pr[<= 10](<>
CB.Stuck) e Pr[<= 50](<> CB.Stuck).
(a) (b)
Figura 3.23: Densidade de probabilidade da função de falha do disjuntor em a) 10 anos e b) 50anos.
Com relação à densidade de probabilidade resultante do estudo, nota-se que em 10 anos(tempo igual ao MTBF do disjuntor) há uma probabilidade de aproximadamente 62% do dis-juntor falhar. O tempo médio em que as falhas podem ocorrem está em cerca de 4,2 anos. Estesvalores estão coerentes, uma vez que a probabilidade de ocorrência de um evento em um tempoigual ao seu MTBF é Pr(MTBF ) = 1− e−MTBF
MTBF = 63, 21%.
74
Considerando o período de 50 anos, todas as amostras consideradas no estudo apresenta-ram falha, com tempo médio de falha em 9,35 anos. Outros estudos indicaram que à medidaem que se aumenta o tempo analisado, a taxa média de falha se aproxima ao MTBF.
Capítulo 4
Modelagem e Verificação do Sistema deProteção
Neste capitulo será apresentado o desenvolvimento e validação dos modelos que repre-sentam os dispositivos que compõem o sistema de proteção. Os modelos foram desenvolvidosatravés de uma abstração de autômatos temporizados híbridos no aplicativo UPPAAL STRATEGO.A validação dos modelos foi realizada através da metodologia exposta no Capítulo 3, porém,neste capítulo constam apenas os modelos finais resultantes da metodologia.
4.1 Barramento de Comunicação
Inicialmente, descreve-se o desenvolvimento do modelo do barramento de comunicaçãoque interliga os dispositivos do sistema de proteção. Conforme abordado nos capítulos ante-riores, este modelo será responsável pela transmissão das mensagens do protocolo IEC 61850(GOOSE e SV) e do protocolo de sincronização de tempo IEEE 1588. No entanto, a modela-gem nesta etapa não faz a distinção do tipo de mensagem que está transitando na rede, sendoesta funcionalidade adaptada posteriormente de acordo com a necessidade dos outros modelos.
O modelo proposto é baseado no tempo de transferência entre dois dispositivos físicosdefinido na parte #5 da norma IEC 61850. Da definição, o atraso de comunicação é compostopela soma dos tempos de codificação e decodificação dos quadros da mensagem em cada dispo-sitivo (transmissor e receptor) e pelo tempo de propagação do pacote no meio físico utilizado,incluindo o tempo de roteamento dos switches dispostos ao longo da rede de comunicação. Ostempos supracitados estão referenciados na Figura 4.1 como ta, tc e tb, respectivamente.
O tempo de transferência depende, de maneira mais significativa, da topologia da redee do tráfego de dados. Com relação à topologia da rede, na parte #9-2 da norma IEC 61850são apresentadas algumas arquiteturas possíveis para o barramento de comunicação. Já comrelação ao tráfego de dados na rede, alguns mecanismos de comunicação, como o GOOSE, sãobaseados na replicação de mensagens de forma a aumentar a confiabilidade de transmissão das
75
76
informações. Na ocorrência de eventos do sistema elétrico, observa-se um aumento significa-tivo das mensagens GOOSE nos sistemas baseados em IEC 61850. Isto acarretará no aumentodo tempo em que os pacotes permaneçam nos buffers dos dispositivos que tratam destas men-sagens, como switches e IEDs.
ta tb tc
Transfer time
t = ta+tb+tc
Physical Device
PD1
Physical Device
PD2
Sender Receiver
Physical
Medium
Cod. Decod.
Application Application
Figura 4.1: Tempo de transferência de pacotes.
Nesse contexto, o comportamento não determinístico do atraso do sistema de comunica-ção será representado através de modelos probabilísticos. Além disso, prevê-se a utilização deVLANs para separação dos tipos de mensagens que transitam na rede.
4.1.1 Modelagem do Barramento de Comunicação
O modelo de barramento de comunicação consiste basicamente de uma fila circular (FIFO- First In, First Out) temporizada. São propostos três modelos diferentes de representação dotempo de transmissão do barramento de comunicação, a saber: i) tempo de atraso fixo, ii) tempode atraso variável baseado em função de distribuição uniforme e iii) tempo de atraso variávelbaseado em função de distribuição lognormal.
Na Figura 4.2 estão representados os três modelos propostos para abstração do atraso detempo no sistema de comunicação. Em todos os modelos estão evidenciados as principais carac-terísticas do barramento de comunicação: função de recebimento, de armazenamento e de enviode pacotes. Nota-se na figura em questão que o tempo total de transmissão agora é determinadopelo tempo em que as mensagens permanecem no buffer do barramento de comunicação.
O modelo de tempo fixo (denominado como “LAN_FIX”), como o próprio nome sugere,ao receber um pacote, aguarda um tempo fixo tfix, mantendo o pacote na ordem correta dechegada, e disponibiliza-o para os receptores. O modelo de tempo variável baseado em dis-tribuição uniforme (“LAN_UNIF”), aguarda o tempo obtido por uma função de distribuiçãouniforme nos intervalos tfix ±∆ para disponibilização do pacote. Neste modelo, também são
77
preservadas todas as ordens de chegada e saída dos pacotes. Por fim, o modelo de tempo va-riável baseado em distribuição lognormal (“LAN_LNORM”) aguarda um tempo baseado emtfix + lognorm() para retirada dos pacotes da fila. Apenas este modelo permite a alteração daordem de transmissão dos pacotes, uma vez que um pacote que chega por último pode obterum valor tfix + lognorm() menor do que os pacotes que já estavam no Buffer. Esta alteração,fisicamente indica a alteração na ordem de chegada dos pacotes devido, por exemplo, a umarota de transmissão diferente.
Transfer time
t = ta+tb+tc
Physical Device
PD1Physical Device
PD2
Sender Receiver
Cod. Decod.
Application Application
LAN
FIFO
LastFirst
tfix
tfix-Δ tfix+Δ
tfix+lognorm()
LAN - FIX
LAN - UNIF
LAN - LNORM
Figura 4.2: Representação do modelo do barramento de comunicação.
Baseado nesse contexto, na Figura 4.3 estão apresentados os modelos desenvolvidos parao barramento de comunicação. A funcionalidade de VLAN ao modelo é implementada pelapassagem por parâmetros dos canais de sincronização que ativam a inserção e remoção de pa-cotes à fila. Conforme abordado na figura em questão, os modelos são compostos por trêsestados. O estado “FIFO” faz o controle de tempo das mensagens que estão no buffer da LAN.O modelo sai deste estado por dois canais de sincronização. O canal de sincronização receptor“Send?” simboliza a inserção de pacotes na LAN. Em caso de inserção de pacote quando o buf-fer está cheio, uma variável de overflow indica o estado de erro da LAN. Em condições normais,insere-se o novo pacote à fila e contabiliza-se o tempo de espera de acordo com cada modelo.Transcorrido o tempo do pacote permanecer na fila do barramento de comunicação, o mesmo édisponibilizado a todos os receptores pertencentes à VLAN através do canal de sincronizaçãoemissor “Receive!”. Este procedimento retira o pacote da fila do barramento de comunicação.
Excepcionalmente, no modelo LAN-LNORM (Figura 4.3.c), ao inserir um pacote ao buf-fer da LAN, necessita-se verificar se o tempo de espera calculado para o pacote em questão émenor do que algum tempo de espera atual de um pacote que já esteja na fila. Esta verificaçãoé realizada através de algoritmo de ordenação do tipo bubble-sort, descrito na Figura 4.4.
78
(a)
(b)
(c)
Figura 4.3: Modelagem da LAN: a) delay fixo (“LAN_FIX”); b) delay variável comdistribuição uniforme (“LAN_UNIF”) e c) delay variável com distribuição lognormal
(“LAN_LNORM”).
4.1.2 Validação do Modelo de Barramento de Comunicação
O desempenho dos modelos do barramento de comunicação foi avaliado mediante simu-lações e verificações de propriedades de acordo com a metodologia descrita no Capítulo 3. Osestudos foram conduzidos em ambientes hipotéticos envolvendo o desenvolvimento de diversosmodelos geradores de eventos randômicos, de forma a avaliar a conformidade dos modelos emuma diversidade de cenários.
79
1 double v e t [ c t _ i L i m ] , aux ;2 double aux_tmsg [ c t _ i L i m ] , a u x _ t d e l a y [ c t _ i L i m ] ;3 stMsg s t B u f f _ a u x ;4 void s o r t ( hybrid c l o c k &t_msg [ c t _ i L i m ] , hybrid c l o c k &t _ d e l a y [ c t _ i L i m ] )5 {6 i n t [ 0 , c t_ iL im −1] i _ a u x F i r s t = i _ F i r s t ;7 i n t i , j ;89 f o r ( i =0 ; i < c t _ i L i m ; i ++)
10 {11 aux_tmsg [ i ] = t_msg [ i ] ;12 a u x _ t d e l a y [ i ] = t _ d e l a y [ i ] ;13 v e t [ i ] = a u x _ t d e l a y [ i ] − aux_tmsg [ i ] ;14 }15 f o r ( i =1 ; i <i_NElem ; i ++)16 {17 i _ a u x F i r s t = i _ F i r s t ;18 f o r ( j =1 ; j <i_NElem ; j ++)19 {20 i f ( v e t [ i _ a u x F i r s t ] > v e t [ ( i _ a u x F i r s t +1)% c t _ i L i m ] )21 {22 aux = v e t [ ( i _ a u x F i r s t +1)% c t _ i L i m ] ;23 v e t [ ( i _ a u x F i r s t +1)% c t _ i L i m ] = v e t [ i _ a u x F i r s t ] ;24 v e t [ i _ a u x F i r s t ] = aux ;2526 aux = t_msg [ ( i _ a u x F i r s t +1)% c t _ i L i m ] ;27 t_msg [ ( i _ a u x F i r s t +1)% c t _ i L i m ] = t_msg [ i _ a u x F i r s t ] ;28 t_msg [ i _ a u x F i r s t ] = aux ;2930 aux = t _ d e l a y [ ( i _ a u x F i r s t +1)% c t _ i L i m ] ;31 t _ d e l a y [ ( i _ a u x F i r s t +1)% c t _ i L i m ] = t _ d e l a y [ i _ a u x F i r s t ] ;32 t _ d e l a y [ i _ a u x F i r s t ] = aux ;3334 s t B u f f _ a u x = stBuff_LAN [ ( i _ a u x F i r s t +1)% c t _ i L i m ] ;35 stBuff_LAN [ ( i _ a u x F i r s t +1)% c t _ i L i m ] = stBuff_LAN [ i _ a u x F i r s t ] ;36 stBuff_LAN [ i _ a u x F i r s t ] = s t B u f f _ a u x ;3738 }39 i _ a u x F i r s t = ( i _ a u x F i r s t +1)% c t _ i L i m ;40 }41 }42 }
Figura 4.4: Ordenação dos pacotes através do algoritmo bubble-sort.
Na Figura 4.5 estão apresentados os modelos emissores aleatórios de pacotes e modeloreceptor empregados nos estudos. Com relação aos emissores, desenvolveu-se três modelos degeração de mensagens com diferença apenas na determinação do intervalo de tempo entre enviode mensagens. No emissor de tempo fixo, Figura 4.5.a, o modelo determina inicialmente qualo intervalo de tempo será usado entre o envio das mensagens. No modelo em questão, esteintervalo é definido através de uma função de distribuição uniforme no intervalo entre 1 e 160unidades de tempo e permanece o mesmo durante todo o período em análise.
80
(a) (b)
(c) (d)
Figura 4.5: Modelos emissores e receptores: a) emissor com tempo fixo; b) emissor comtempo variável em distribuição uniforme; c) emissor com tempo variável em distribuição
exponencial e d) receptor.
De maneira análoga, no modelo emissor com intervalo de tempo uniforme, o tempo deenvio entre mensagens é determinado a cada emissão por uma função de distribuição uniformecom limites pré-determinados na inicialização do modelo. Estes limites são determinados emtorno de um offset de 150 unidades de tempo.
O modelo emissor com intervalo de tempo exponencial inicialmente determina a Taxa daExponencial (RoE) por uma função de distribuição uniforme no intervalo entre 1 e 5 unidadese utiliza este parâmetro para a função de distribuição exponencial. O intervalo de tempo paraa próxima transmissão é determinado por meio da função de distribuição exponencial sobre oestado inativo “IDLE”.
Em todos os modelos, definiu-se uma estrutura de dados composta pelo endereço do dis-positivo que está enviando a mensagem e um contador de sequência, que é incrementado atéum valor limite e em seguida retorna ao valor “0”.
Além disso, desenvolveu-se dois modelos observadores para auxiliarem no processo desimulação e verificação das propriedades do modelo do barramento de comunicação. Estesmodelos estão representados na Figura 4.6. O observador da LAN (Figura 4.6.a) monitora ainserção e remoção dos pacotes à LAN, sinalizando eventuais erros como overflow, tempo depermanência da mensagem no buffer, ordem de inserção e remoção dos pacotes. Já o modeloobservador de recebimento (Figura 4.6.b) verifica a sequência de chegada dos pacotes no mo-delo receptor, sinalizando eventuais perdas ou inversões de pacotes.
81
(a)
(b)
Figura 4.6: Modelos dos observadores: a) observador da LAN; b) observador de recebimento.
De forma a reduzir o processamento computacional, foram atribuídos limites baixos nasvariáveis que modelam o comportamento do sistema. Tais valores e a descrição das principaisvariáveis adotadas no estudo estão sumarizadas na Tabela 4.1.
Tabela 4.1: Descrição das Principais Variáveis Adotadas no Modelo da LAN.
Variável Descrição Valor
ct_iContLimValor limite para a contagem de sequência das men-sagens. Quando o contador da mensagem chega aovalor máximo, o mesmo retorna ao zero.
8
ct_iLim Tamanho do buffer do barramento de comunicação. 5
i_FixIntervalo entre envio de amostras do modelo de emis-sor de tempo fixo.
runif(1 : 160) [t]
ct_tDelayF ixTempo de transferência de pacotes para o modeloLAN-FIX.
400 [t]
ct_deltaUnifVariação de tempo sobre o tempo de transferência depacotes ct_tDelayF ix no modelo LAN-UNIF.
50 [t]
ct_deltaLnormVariação de tempo sobre o tempo de transferência depacotes ct_tDelayF ix no modelo LAN-LNORM.
30lnorm(1.5, 0.7)
Com relação ao comportamento dos modelos, na Figura 4.7 são apresentadas simulaçõesenvolvendo os três modelos de barramento de comunicação propostos. As simulações são re-alizadas considerando o modelo de emissor de tempo fixo (“LAN_FIX”), parametrizado comintervalo entre mensagens de 100 unidades de tempo.
82
0 100 200 300 400 500 600 700 800 900 1000t
Send
Receive
012345
02468
0
400
Logical_States
N_Elem
Msg_Cont
t0
t1
t2
t3
t4
(a)
0 100 200 300 400 500 600 700 800 900 1000t
Send
Receive
012345
02468
0
delay_fix - ∆tdelay_fix + ∆t
Logical_States
N_Elem
Msg_Cont
t0
t1
t2
t3
t4
(b)
0 100 200 300 400 500 600 700 800 900 1000t
Send
Receive
012345
02467
0
400
Logical_States
N_Elem
Msg_Cont
t0
t1
t2
t3
t4
(c)
Figura 4.7: Simulações envolvendo os modelos a) LAN_FIX; b) LAN_UNIF e c)LAN_LNORM.
83
Nas simulações em questão, destacam-se as variáveis lógicas relacionadas aos estadosde envio e recebimento de mensagens, o número de elementos na fila do barramento de co-municação, o contador de sequência das variáveis que chegam à LAN e o tempo em que cadamensagem permanece no barramento.
Através da Figura 4.7, é possível notar que em nenhum momento houve a ocorrência deoverflow da fila do barramento de comunicação. Isto é justificado pois o intervalo entre o enviodas mensagens dos emissores, tfix = 100 é maior do que o máximo intervalo suportado pelaLAN, delayfix/ct_iLim = 80. Testes considerando intervalo entre as mensagens enviadas emtfix ≤ 100 foram realizados e foram observadas o estouro de memória na LAN, no entanto,análises mais conclusivas são apresentadas da etapa de verificação formal dos modelos.
Com relação ao modelo de atraso com tempo fixo (“LAN_FIX”), Figura 4.7.a, observa-seo tempo de espera das mensagens que chegam ao buffer da LAN em 400 unidades de tempo.O contador de sequência das mensagens aparentemente também apresenta comportamento ade-quado, pois, ao chegar no valor limite (parametrizado em 8), reinicia a contagem.
Já para o modelo com atraso de tempo uniforme (“LAN_UNIF”), Figura 4.7.b, os tem-pos de armazenamento dos pacotes variam na faixa de 350 a 450 unidades de tempo (valoresparametrizados na simulação em questão). Destaca-se nesta simulação, o recebimento de men-sagens em tempos próximos em aproximadamente t = 650 unidades. A interpretação físicapara este comportamento é o diferente percurso que as mensagens percorreram pela rede decomunicação até o dispositivo receptor. Conforme discutido anteriormente, neste modelo nãoé possível a inversão de ordem de recebimento das mensagens. O fenômeno mais crítico nestemodelo, além da perda de pacotes que não está incorporada ainda, pode ser observado pelarecebimento de duas mensagens quase instantâneas.
Por fim, a Figura 4.7.c descreve o comportamento do modelo considerando o atraso detempo em uma distribuição lognormal (“LAN_LNORM”). O modelo em questão é mais suscep-tível à falhas de overflow e inversão de pacotes do que os modelos anteriores. Como o intervalode tempo em que as mensagens ficam na fila do barramento de comunicação não possui limita-ção de tempo superior, não há garantias de que a LAN não apresente overflow para determinadointervalo de tempo relacionado ao envio das mensagens. Na simulação em questão, não foramidentificados problemas de overflow e inversão de pacotes.
Uma simulação adicional é apresentada na Figura 4.8, onde consta a perda de pacotesdevido à ocorrência de overflow no barramento de comunicação modelado por tempo lognormal,observado na Figura 4.8.a e inversão da chegada de pacotes ao receptor, através da Figura 4.8.b.Para ambas as simulações foram considerados os parâmetros da Tabela 4.1.
Com relação à ocorrência de overflow, Figura 4.8.a, nota-se que aproximadamente noinstante t = 1.200, o buffer estava com capacidade máxima. O próximo evento, em t = 1.300,é a entrada de um pacote à fila, o que leva o estouro do buffer e perda do pacote.
84
Na Figura 4.8.b, aproximadamente no instante t = 1.200, nota-se a inversão da chegadados pacotes através da variável de contagem de sequência das mensagens lida pelo receptor.Diferente do comportamento descrito na Figura 4.8.a, neste caso não há a ocorrência de overflowdo barramento de comunicação. Esta situação também é considerada como um erro do sistemade comunicação.
0 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500 1600 1700 1800 1900 2000
t
Send
Receive
012345
02468
0
1
Logical_States
N_Elem
msgCont_SendmsgCont_Rec
Overflow
(a)
0 150 300 450 600 750 900 1050 1200 1350 1500 1650 1800 1950t
Send
Receive
012345
02468
0
1
Logical_States
N_Elem
msgCont_SendmsgCont_Rec
Overflow
(b)
Figura 4.8: Inversão de pacotes devido à a) overflow da FIFO e b) caminhos diferentes nobarramento de comunicação.
O mesmo cenário, envolvendo a transmissão aleatória baseada no modelo de emissãocom tempo fixo foi utilizado para a verificação das propriedades dos modelos do barramento decomunicação. Salienta-se que os resultados obtidos através dos outros modelos de emissoresrandômicos (distribuição uniforme e exponencial) apresentam probabilidades de atendimento
85
das propriedades diferentes, porém, a interpretação destes resultados levam às mesmas conclu-sões a respeito da validação dos modelos.
Na Tabela 4.2 estão descritas as propriedades em linguagem informal e formal e osresultados apresentados para os três modelos propostos para o barramento de comunicação:LAN_FIX, LAN_UNIF e LAN_LNORM. Os resultados foram obtidos considerando-se intervalode tempo t <= 2500, com 99% de confiança, precisão de 1% e passo de integração t = 0, 005.O comportamento desejado dos modelos foi descrito através de propriedades de acessibilidadee segurança.
O intervalo de tempo adotado nas verificações, assim como o modelo emissor de tempofixo foram escolhidos de maneira parcimoniosa, pois com estes parâmetros é possível umainterpretação mais coerente dos resultados.
As propriedades P5.1.1 e P5.1.2 (Tabela 4.2) indicam a possibilidade dos modelos dereceberem e enviarem mensagens no intervalo de tempo especificado. Para todos os modelos,estas propriedades foram integralmente atendidas. Isto indica, indiretamente, a ausência dedeadlocks durante o intervalo de tempo em análise.
A propriedade P5.1.3 (Tabela 4.2) indica a probabilidade de ocorrência de overflow paraos modelos. Primeiramente, com relação ao modelo de tempo fixo, o resultado de 50% em aten-der esta propriedade está de acordo com o esperado. Isto é justificado pelo seguinte argumento:a determinação do tempo de envio das mensagens por parte do emissor, é efetuada através deuma função de distribuição uniforme entre os valores 1 e 160. O mínimo intervalo de tempoentre mensagens enviadas à LAN é determinada pela razão entre o tempo de permanência na filae a capacidade de armazenamento de pacotes na fila da LAN. Neste caso, este limite consta de80 unidades de tempo, ficando na metade do intervalo da função de distribuição uniforme quedetermina o tempo de envio das mensagens. Logo, esperava-se a probabilidade de ocorrênciade overflow em 50%, conforme apresentado pelo resultado.
De maneira análoga, esta propriedade deve apresentar valores próximos de 50% para osdemais modelos do barramento de comunicação. A justificativa numérica para os resultadosapresentados aos outros modelos não é uma tarefa trivial, pois consta da intersecção de duasfunções de distribuição diferentes. No entanto, justifica-se os valores maiores do que o mo-delo LAN_FIX pois o tempo de transferência entre as mensagens nestes modelos de LAN sãodeslocados com relação ao valor de tempo fixo.
A propriedade P5.1.4 (Tabela 4.2) descreve a eventual entrega de mensagens que não es-tão presentes na fila do barramento de comunicação, indicando um erro de lógica ou de controledo modelo da fila. Como esperado, nos três modelos de LAN não foi observado este erro parao tempo solicitado.
86Tabela 4.2: Verificação das Propriedades dos Modelos do Barramento de Comunicação.
Nome Descrição Informal Descrição Formal Resultadofix unif lnorm
P5.1.1 Verifica a probabilidade da LAN em receber mensa-gens.
Pr[<=2500](<> VLAN0.S) 100,0% 100,0% 100,0%
P5.1.2 Verifica a probabilidade da LAN em “entregar” men-sagens.
Pr[<=2500](<> VLAN0.R) 100,0% 100,0% 100,0%
P5.1.3 Verifica a probabilidade da LAN em apresentar Over-flow.
Pr[<=2500](<> VLAN0.b_flagoverflow) 50,00% 54,80% 56,13%
P5.1.4 Verifica a probabilidade da LAN de “entregar” men-sagens que não estão em seu Buffer. Pr[<=2500](<> SNIF_VLAN0.ERROR) 0,00% 0,00% 0,00%
P5.1.5Verifica a probabilidade da LAN entrar em overflowconsiderando intervalo de envio de mensagens maiordo que o seu limite de tranmissão.
Pr[<=2500]([] VLAN0.b_flagoverflowimply ((VLAN0.ct_tDelayFix+VLAN0.ct_delta)/ct_iLim)<SRV_VLAN0.i_Fix)
0,00% 0,00% NA
P5.1.6Verifica a probabilidade da LAN entrar em overflowconsiderando intervalo de envio de mensagens menordo que seu limite de transmissão.
Pr[<=2500]([] VLAN0.b_flagoverflowimply ((VLAN0.ct_tDelayFix-VLAN0.ct_delta)/ct_iLim)>SRV_VLAN0.i_Fix)
100,0% 87,99% NA
P5.1.7Verifica a probabilidade da LAN em manter a ordemcorreta das mensagens em situações que não houveoverflow.
Pr[<=2500]([] SNIF_VLAN0.OBS_SENDimply SNIF_VLAN0.S_obs_new==(SNIF_VLAN0.S_obs_old+1)%(ct_iContLim+1))
100,0% 100,0% 100,0%
Pr[<=2500]([] SNIF_VLAN0.OBS_RECimply SNIF_VLAN0.R_obs_new==(SNIF_VLAN0.R_obs_old+1)%(ct_iContLim+1))
100,0% 100,0% 97,20%
P5.1.8 Verifica a probabilidade da perda de pacotes em situ-ações em que não houve overflow?
Pr[<=2500](<> (obs_Rec.NOK and!VLAN0.b_flagoverflow))
0,00% 0,00% 1,98%
87
As propriedades P5.1.5 e P5.1.6 (Tabela 4.2) utilizam-se do fato de que o intervalo detempo entre as mensagens do emissor é fixo. Desta maneira, pode-se encontrar uma relação en-tre o intervalo de envio das mensagens e a capacidade da LAN, conforme abordado na discussãoda propriedade P5.1.3. Estas propriedades não se aplicam ao modelo de LAN-LNORM, umavez que não há limites superiores para o tempo de transmissão das mensagens, ainda que valoresmaiores apresentam baixa probabilidade de ocorrência na função de distribuição lognormal.
Com relação à P5.1.5, especifica-se a probabilidade do sistema apresentar overflow emsituações de intervalo de envio de mensagens maior do que o capacidade de transmissão mínimada LAN. Conforme esperado, os valores apresentados para os modelos LAN_FIX e LAN_UNIFforam 0%. No caso da LAN_UNIF, em específico, a capacidade de transmissão mínima da LANé garantida considerando o offset de ct_deltaUnif sobre o valor do tempo fixo da LAN. Valoresentre ±ct_deltaUnif não é possível ter conclusões a respeito do overflow da LAN.
De maneira análoga, a propriedade P5.1.6 avalia o oposto de P5.1.5. Sempre que houveroverflow, indica que o intervalo de envio de mensagens está inferior ao limite mínimo da ca-pacidade de transmissão da LAN. O resultado, próximo de 100%, de P5.1.6 para os modeloscorresponde ao comportamento esperado do modelo.
A propriedade P5.1.7 (Tabela 4.2) avalia a probabilidade de ocorrência de erros nos con-tadores de sequência das mensagens. Para eliminar os casos de perdas de pacotes devido àocorrência de overflow na LAN, conforme discutido anteriormente, esta propriedade é condici-onada ao caso de não ocorrência de overflow.
A propriedade é ainda subdividida em duas condições, no mecanismo de montagem dasmensagens e no recebimento das mesmas. Isto é necessário para garantir que um recebimentocom alteração na contagem de sequência das mensagens não seja ocasionado pelo próprio me-canismo de emissão. Com relação à montagem dos pacotes, todos os modelos atendem em100% esta propriedade. No entanto, no recebimento, apenas o modelo LAN-LNORM apre-senta possibilidade de inversão de pacotes, conforme discutido na etapa de desenvolvimentodos modelos.
Da mesma maneira, a propriedade P5.1.8 (Tabela 4.2) avalia a possibilidade de inversãode pacotes por parte do modelo receptor. Conforme esperado, o único modelo com possibili-dade de inversão dos pacotes é o modelo LAN_LNORM . Salienta-se que o resultado destapropriedade depende da parametrização da função de distribuição que modela o atraso de tempodas mensagens.
88
4.2 Protocolo de Sincronização de Tempo IEEE 1588
Esta seção apresenta o desenvolvimento dos modelos relativos ao protocolo de sincroni-zação de relógios IEEE 1588 (PTP). Conforme abordado no início do trabalho, o protocolo écomposto basicamente por duas etapas: a primeira é o estabelecimento da hierarquia mestre-escravo e a segunda é caracterizada pela troca de mensagens para o sincronismo de tempo, pro-priamente dito. O modelo abordado nesta dissertação considera que a primeira etapa, formaçãoda hierarquia, já esteja devidamente concluída. Com relação à segunda etapa, considera-se ocomportamento descrito pela Figura 4.9, denominado two-step clock pela norma em questão.
Mestre Escravo
Sync (1)F_Up (1)
t1
t2t2 ,t1Sync (2)F_Up (2)
t1
t2 ,t1,t3
t4
t2 ,t1,t3,t4
Rep (1)
Req (1)
Memória do
Escravo
Desconsidera Sync(2) e
Fup(2), pois o escravo
aguarda o Rep(1)
T_Out
T_Out
Ajusta o
tempo
Figura 4.9: Funcionamento do Protocolo IEEE 1588 two-step clock.
O processo de sincronismo two-step clock (Figura 4.9) consiste na seguinte sequência:periodicamente o mestre envia uma mensagem de solicitação do processo de requisição Syncseguida de uma mensagem Follow_Up contendo a estampa de tempo t1 referente ao envio damensagem Sync. A estampa de tempo t1 está referenciada no relógio local do mestre. Aoreceber a mensagem de sincronismo Sync, o escravo guarda este instante de tempo em t2, queestá referenciado ao relógio local do escravo. A estampa de tempo t1 contida na mensagemFollow_Up é armazenada pelo escravo para realização do ajuste de seu relógio.
Em seguida, o escravo solicita outra troca de mensagens para efetuar o cálculo do delaydo sistema de comunicação. Esta requisição é realizada através das mensagens Delay_Req eDelay_Resp enviadas pelo escravo e pelo mestre, respectivamente. O instante de tempo do envioda mensagem Delay_Req é armazenado em t3, referenciado ao escravo. O instante de tempo derecebimento da mensagem Delay_Req pelo mestre é armazenado na variável t4 (referenciadoao mestre). Este instante de tempo é enviado ao escravo pela estampa de tempo da mensagemDelay_Req.
Por fim, armazenados os tempos t1, t2, t3 e t4, o escravo ajusta o seu tempo local baseadonas Equações 4.1 e 4.2, sendo ts o relógio local do escravo. A norma também prevê o empregode um controlador diferencial no oscilador interno do relógio escravo, em casos de uma pequenadiferença de tempo entre mestre e escravo. No entanto, o modelo desenvolvido considera apenasa correção absoluta no relógio interno do escravo através das Equações 4.1 e 4.2.
89
offset =(t2 − t1) + (t4 − t3)
2(4.1)
ts = ts − offset (4.2)
4.2.1 Modelagem do Protocolo PTP
O comportamento do protocolo sincronização de tempo PTP foi descrito através de trêsautômatos, ilustrados na Figura 4.10. Dois autômatos fazem a abstração das tarefas realizadaspelo dispositivo mestre da hierarquia. O modelo Master_task1 implementa a geração das men-sagens de sincronismo Sync e Follow_Up. O modelo Master_task2 é responsável pela recepçãode mensagens Delay_Req, provenientes de dispositivos escravos e pelo envio do instante detempo do recebimento da mensagem em questão, através do envio de Delay_Resp. Por fim, omodelo Slave_task implementa a máquina de estados relativa ao processo de ajuste do relógiodo dispositivo escravo. O modelo em questão é responsável pelo gerenciamento das variáveisque armazenam as estampas de tempo t1, t2, t3 e t4, através da troca de mensagens definidapelo protocolo.
M S
Sync (n)F_Up (n)
Req (1)
Rep (n)
Master
task1
Master
task2
Slave
task
Figura 4.10: Representação do Modelo PTP.
Na Figura 4.11 estão apresentados os modelos que descrevem o funcionamento do proto-colo de sincronização PTP. Todos os modelos recebem como parâmetros de entrada os canais desincronização que representam as VLANs aos quais os mesmos estão conectados e o endereçodo dispositivo em questão. Os endereços dos modelos são usados como parâmetro da estruturado pacote adotado. Além do endereço, o tipo da mensagem, um contador de sequência de men-sagem e a estampa de tempo da mensagem são utilizadas pela estrutura do pacote relativo àsmensagens PTP.
Na Figura 4.11.a é apresentado o modelo que implementa a geração das mensagens desincronismo Sync e Follow_Up. O protocolo IEEE 1588 permite a faixa de ±30% de desvio
90
de tempo relativo ao intervalo parametrizado de envio da mensagem Sync, descrito pela va-riável ct_logSyncInterval. Nesse contexto, o modelo em questão implementa a geração dasmensagens de sincronismo em um intervalo entre ±30% baseado em uma função de distribui-ção uniforme. No momento de envio da mensagem em questão, o modelo faz a aquisição doinstante de tempo. Este instante é integrado à mensagem Follow_Up e enviado na metade dointervalo parametrizado para envio da mensagem de sincronismo.
(a)
(b)
(c)
Figura 4.11: Modelos do Protocolo PTP: a) Master_task1, b) Master_task2 e c) Slave_task
Já a Figura 4.11.b consta a implementação do modelo Master_task2. Este modelo recebemensagens do tipo Delay_Request, faz a medida do instante de tempo em que a mensagem foirecebida e o envia através da mensagem Delay_Resp, mantendo o mesmo contador de sequênciada mensagem de requisição.
Por fim, na Figura 4.11.c está apresentado o modelo que abstrai o comportamento dodispositivo escravo no protocolo PTP. O modelo basicamente espera pela mensagem Sync e
91
sua respectiva Follow_Up. Faz a requisição para cálculo do delay do sistema de comunicaçãomantendo o mesmo contador de sequência das mensagens anteriores e aguarda a resposta domestre. O tempo de espera da mensagem relativa ao cálculo do delay é parametrizado pelavariável ct_logMinDelayReqInterval.
Na Figura 4.12 está apresentado o código que implementa a montagem dos pacotes utili-zados pelos modelos.
1 void mk_SyncPack ( ) {2 s t B u f f _ M a s t e r . i_msgType = c t _ m t f S y n c ;3 s t B u f f _ M a s t e r . i _ s o u r c e P o r t I d = i I d ;4 s t B u f f _ M a s t e r . i _ s e q u e n c e I D = i_Co n t ;5 s t B u f f _ M a s t e r _ T i m e = hc_Tm ; }6 void mk_FollowUpPack ( ) {7 s t B u f f _ M a s t e r . i_msgType = ct_mtfFol low_Up ;8 s t B u f f _ M a s t e r . i _ s o u r c e P o r t I d = i I d ;9 s t B u f f _ M a s t e r . i _ s e q u e n c e I D = i_Co n t ; }
10 void mk_DelayReqPack ( ) {11 s t B u f f _ S l a v e . i_msgType = c t_mt fDe lay_Req ;12 s t B u f f _ S l a v e . i _ s o u r c e P o r t I d = i I d ;13 s t B u f f _ S l a v e _ T i m e = hc_Ts [ i I d −1]; }14 void mk_DelayRespPack ( ) {15 s t B u f f _ M a s t e r . i_msgType = c t_mt fDe lay_Resp ;16 s t B u f f _ M a s t e r . i _ s o u r c e P o r t I d = i I d ;17 s t B u f f _ M a s t e r _ T i m e = hc_Tm ; }
Figura 4.12: Montagem dos Pacotes do Protocolo PTP.
4.2.2 Validação dos Modelos PTP
Diferente do processo de validação adotado no modelo do barramento de comunicação,na subseção anterior, a validação do protocolo PTP será realizado através de três validações in-dividuais, uma para cada modelo (task) desenvolvido. Após a validação individual dos modelos,será acrescentado um modelo de barramento de comunicação de forma a avaliar o comporta-mento global dos três modelos rodando em processos paralelos.
Na Figura 4.13 estão apresentados os modelos que subsidiaram o processo de validação doprotocolo PTP. A Figura 4.13.a apresenta o observador de mensagens do protocolo. O modeloem questão atua como um sniffer de rede, monitorando o tipo, tempo, contador de sequência eendereço do emissor de todas as mensagens trocadas entre os modelos.
Na Figura 4.13.b é apresentado o modelo emissor de mensagens aleatórias. Este modeloemula a emissão de todos os pacotes usados pelos modelos PTP. Na Figura 4.13.c está apresen-tado o modelo observador de recebimento de mensagens do dispositivo escravo, com finalidadede verificação da sequência de mensagens recebidas pelo modelo escravo.
92
(a)
(b) (c)
Figura 4.13: Modelos auxiliares para o protocolo PTP: a) observador de mensagens (sniffer),b) emissor de mensagens PTP e c) observador de recebimento.
Validação do modelo Master_task1
Como o modelo Master_task1 (Figura 4.11.a) possui somente canais de sincronizaçãoemissores, faz-se necessária apenas a instanciação do modelo observador de mensagens (Figura4.13.a) para sua validação. Assim como no processo de validação anterior, os valores limi-tes das variáveis foram reduzidos de forma a otimizar o esforço computacional utilizado peloverificador de modelos. Na Tabela 4.3 estão apresentadas as principais variáveis usadas nesteprocesso.
Considerando tais parâmetros, a Figura 4.14 apresenta o resultado de uma simulação parao modelo Master_task1. Da figura em questão, destacam-se os instantes de envio das mensagensSync e Follow_Up, o contador de sequências das mensagens e a estampa de tempo registradaem cada envio da mensagem Sync. Através da simulação apresentada pela Figura 4.14, aparen-
93
temente conclui-se que o comportamento do modelo está de acordo com o esperado pela normaIEEE 1588, porém, esta afirmação somente é possível após a análise da verificação formal sobreo modelo.
Tabela 4.3: Descrição das Principais Variáveis Adotadas no Modelo Master_task1
Variável Descrição Valor
ct_logSyncIntervalExpoente para determinação do intervalo de tempopara envio de mensagens de sincronismo pelo dispo-sitivo mestre.
0
d_SyncTimeIntervalo de tempo para envio das mensagens de sin-cronismo. Determinado por 2logSyncInterval
1
ct_iContLimValor limite para o identificador de sequência dasmensagens
10
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Sync
Follow_Up
0
0.7
1.302468
10
0
20
Logical_States
t_Sync
seq_ID
Master_ClockTime_Stamp
Figura 4.14: Simulação envolvendo o modelo master_task1.
As propriedades comportamentais testadas para o modelo master_task1 são apresentadasna Tabela 4.4. Estas propriedades foram definidas de acordo com o comportamento básicoesperado pelo protocolo e por requisitos de operação indicados em testes de conformidade parao protocolo PTP. Os resultados foram obtidos considerando-se intervalo de tempo t <= 100,com 99% de confiança, precisão de 1% e passo de integração t = 0.005.
As propriedades P5.2.1, P5.2.2 e P5.2.3 (Tabela 4.4) indicam o comportamento básicodo modelo, que é o envio de mensagens Sync e Follow_Up. Para P5.2.1 e P5.2.2, a probabili-dade de atendimento destas propriedades em 100% correspondem que o modelo irá enviar estasmensagens ao menos uma vez durante o período de tempo em análise. Com relação a P5.2.3,cujo resultado é 0%, indica que o modelo não envia outros tipos de mensagens.
A propriedade P5.2.4 (Tabela 4.4) verifica se o intervalo de envio das mensagens de sin-cronismo estão dentro da faixa permitida pelo protocolo, correspondente a ±30% do parâmetrologSync_Interval.
94
Por fim, a propriedade P5.2.5 (Tabela 4.4) verifica a geração da estampa de tempo en-viada pela mensagem Follow_Up, estando sempre associada ao instante de tempo de envio damensagem de sincronismo Sync. Assim como as propriedades anteriores, a verificação formalestatística garante que esta propriedade será sempre satisfeita.
Tabela 4.4: Verificação das propriedades sobre o modelo Master_Task1.
Nome Descrição Informal Descrição Formal Resultado
P5.2.1 Verifica a probabilidade domodelo enviar mensagensSync.
Pr[<=100](<>Obs_msg.REC_SYNC)
100,00%
P5.2.2Verifica a probabilidade domodelo enviar mensagensFollow_Up.
Pr[<=100](<>Obs_msg.REC_FUP)
100,00%
P5.2.3Verifica a probabilidade domodelo enviar outros tipos demensagens.
Pr[<=100](<>Obs_msg.REC_DREQ orObs_msg.REC_DRESP orObs_msg.REC_UNKNW)
0,00%
P5.2.4
Verifica a probabilidade domodelo enviar mensagens desincronismo fora da faixa deintervalo permitida (±30%sobre t_sync).
Pr[<=100]([]Obs_msg.REC_SYNC imply(Obs_msg.c_obsSync>=d_SyncTimemin &&Obs_msg.c_obsSync<=d_SyncTimemax))
100,00%
Pr[<=100]([]Obs_msg.REC_SYNC imply(Obs_msg.c_obsSync<d_SyncTimemin ||Obs_msg.c_obsSync>d_SyncTimemax))
0,00%
P5.2.5
Verifica a probabilidade daestampa de tempo da mensa-gem Follow_Up corresponderao tempo de envio da mensa-gem de sincronismo.
Pr[<=100]([]Obs_msg.REC_SYNC imply(Obs_msg.stBuff_Obs_Time==hc_Tm))
100,00%
Validação do modelo Master_Task2
Para validação do modelo Master_Task2 foram necessárias as instanciações dos mode-los Random_Sender, que emula a emissão aleatória de pacotes PTP e do modelo Sniffer, queobserva a troca de mensagens PTP no sistema de comunicação. Como o modelo em análisefaz o envio de mensagens do tipo Delay_Resp, estas mensagens foram desabilitadas do modeloRandom_Sender.
Os resultados foram obtidos considerando-se intervalo de tempo t <= 100, com 99% deconfiança, precisão de 1% e passo de integração t = 0, 005.
95
Uma simulação do modelo em teste é apresentada na Figura 4.15. Da simulação, evidencia-se a troca de mensagens PTP na rede e a geração da estampa de tempo pelo modelo mas-ter_task2.
Conforme observado na Figura 4.15, a resposta do modelo apenas reage às mensagensDelay_Req do emissor aleatório. No recebimento desta mensagem, o modelo faz a aquisiçãodo relógio e o envia através de uma estampa de tempo na mensagem Delay_Resp.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20t
Sync
Follow_Up
Delay_Req
Delay_Resp
0
20
Logical_States - Random Generator
Logical_State - Model Response
Master_ClockTime_Stamp
Figura 4.15: Simulação envolvendo o modelo Master_Task2.
Três propriedades foram consideradas na verificação do comportamento do modelo, con-forme apresentado na Tabela 4.5. Como também há emissão de mensagens pelo modelo emissoraleatório, em todas as propriedades é necessária a verificação do endereço do emissor das men-sagens. Este endereço é disponibilizado na própria estrutura do pacote.
A propriedade P5.2.6 (Tabela 4.5) verifica a probabilidade básica do modelo enviar men-sagens do tipo Delay_Resp. Como esperado, verifica-se a probabilidade de 100% para o modeloatender esta propriedade. A propriedade P5.2.7 (Tabela 4.5) verifica a probabilidade do modeloenviar outros tipos de mensagens à rede, como Sync, Follow_Up e Delay_Req. Por fim, a pro-priedade P5.2.8 (Tabela 4.5) verifica a propriedade do modelo gerar a estampa de tempo queserá enviada pela mensagem Delay_Resp no instante de recebimento da mensagem de requi-sição. Os resultados apresentados na Tabela 4.5 indicam a correta modelagem desta tarefa doprotocolo.
96
Tabela 4.5: Verificação das propriedades sobre o modelo Master_Task2.
Nome Descrição Informal Descrição Formal Resultado
P5.2.6Verifica a probabilidade domodelo enviar mensagensDelay_Resp.
Pr[<=100](<>Obs_msg.REC_DRESP &&Obs_msg.stBuff_Obs.i_sourcePortId==ct_MasterId)
100,00%
P5.2.7Verifica a probabilidade domodelo enviar outros tipos demensagens.
Pr[<=100](<>(Obs_msg.REC_SYNC orObs_msg.REC_FUP orObs_msg.REC_DREQ orObs_msg.REC_UNKNW) and(Obs_msg.stBuff_Obs.i_sourcePortId==ct_MasterId))
0,00%
P5.2.8
Verifica a probabilidade daestampa de tempo da mensa-gem Delay_Resp correspon-der ao tempo de recebimentoda mensagem Delay_Req.
Pr[<=100]([](Obs_msg.REC_DRESP andObs_msg.stBuff_Obs.i_sourcePortId==ct_MasterId) imply(Obs_msg.stBuff_Obs_Time==hc_Tm))
100,00%
Validação do modelo Slave_Task
Assim como no processo de verificação formal anterior, a validação do modelo Slave_Taskse deu através dos modelos Random_Sender e Sniffer. No entanto, as mensagens do tipo De-lay_Req pelo modelo emissor aleatório foram desabilitadas.
A Figura 4.16 apresenta o comportamento do modelo durante uma simulação. Na figuraem questão, destaca-se as mensagens geradas pelo modelo emissor aleatório, Sync, Follow_Upe Delay_Resp. A cada envio da mensagem Sync, o emissor altera o valor do identificador (ID)de sequência dos pacotes.
Com relação às variáveis do Slave_Task, na Figura 4.16 estão apresentados os estadoslógicos em que o dispositivo escravo espera mensagens do tipo Follow_Up e Delay_Resp, oenvio da mensagem Delay_Req e o instante em que o dispositivo efetua a sincronização de seurelógio.
Como o envio das mensagens enviadas pelo dispositivo mestre apresentam caráter alea-tório, na simulação é possível identificar apenas uma vez a sincronização do relógio, uma vezque esta sincronização depende de uma sequência determinada de mensagens em intervalosde tempo especificados. No entanto, através da simulação, o sistema aparentemente possui ocomportamento determinado pelo protocolo.
97
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20t
Sync
Follow_Up
Delay_Resp
05
10
Delay_Req
Wait
Adjust_Time
Logical_States - Random Generator
Logical_State - Model Response
Wait Follow_Up Wait Delay_Resp
Logical_State - Model Response
msg_Cont - Random Generator
Figura 4.16: Simulação envolvendo o modelo Slave_Task.
A Tabela 4.6 apresenta as propriedades verificadas sobre o modelo. Assim como nosmodelos anteriores, as propriedades básicas de envio de mensagens foram testadas. As pro-priedades P5.2.9 e P5.2.10 (Tabela 4.6) indicam o envio correto das mensagens do modeloSlave_Task, enquanto a propriedade P5.2.11 (Tabela 4.6) verifica se a requisição de delay aodispositivo mestre é realizada através de uma sequência válida de mensagens Sync e Follow_Up.
Tabela 4.6: Verificação das propriedades sobre o modelo Slave_Task.
Nome Descrição Informal Descrição Formal Resultado
P5.2.9Qual é probabilidade do mo-delo enviar mensagens De-lay_Req?
Pr[<=100](<>Obs_msg.REC_DREQ &&Obs_msg.stBuff_Obs.i_sourcePortId==ct_SlaveId1)
100.00%
P5.2.10Qual é a probabilidade domodelo enviar outros tipos demensagens?
Pr[<=100](<>(Obs_msg.REC_SYNC orObs_msg.REC_FUP orObs_msg.REC_DRESP orObs_msg.REC_UNKNW) and(Obs_msg.stBuff_Obs.i_sourcePortId==ct_SlaveId1))
0.00%
P5.2.11
Qual é a probabilidade domodelo fazer uma requisiçãode delay referente à mensa-gens Sync e Follow_Up comIDs de sequência diferentes?
Pr[<=100](<>Obs_msg.REC_DRESP andOBS_Slave1.i_SyncID !=OBS_Slave1.i_SyncID )
0.00%
98
Integração entre os Modelos
De forma a avaliar o comportamento global do modelo PTP, integrando todas as tarefas,testes envolvendo um ambiente hipotético foram considerados. No teste apresentado, considera-se o funcionamento do protocolo PTP sobre seis dispositivos, sendo um dispositivo mestre ecinco escravos. Conforme abordado anteriormente, a etapa de formação desta hierarquia não éconsiderada nos modelos.
Como sistema de comunicação, considerou-se o modelo de barramento de comunica-ção com tempo de atraso fixo entre as mensagens. O tempo de atraso no barramento foiparametrizado para 1 unidade de tempo. O tempo de envio das mensagens de sincronismo(logSync_Interval) foi parametrizado para 5 unidades de tempo.
O efeito de deriva (drift) dos relógios dos dispositivos escravos foram considerados nesteestudo. Os valores de deriva foram determinados através de uma função de distribuição uni-forme com variação em torno de ±5% sobre o relógio do dispositivo mestre. Com relação àimplementação, esta funcionalidade é realizada em uma invariante de estado sob a forma deforall(i:int[0,ct_nSlave-1])hc_Ts[i]’==dDrift[i].
A Figura 4.17 apresenta uma simulação considerando os valores dos relógios dos dispo-sitivos para este cenário. Valores iniciais dos relógios escravos foram configurados para 10, 7,5, -3 e -7. Da figura em questão, nota-se que o processo de sincronismo é realizado periodica-mente sobre os dispositivos. No entanto, o ajuste do offset dos relógios não consegue ajustar osrelógios exatamente à referência (mestre). Isto é observado pelo efeito de deriva aos relógiosescravos. Testes envolvendo a diminuição (e eliminação) deste efeito foram realizados, pro-porcionando ajuste mais preciso entre os relógios. As propriedades que foram verificadas aosmodelos foram realizadas sobre o protocolo PTP global, obtendo-se os mesmos resultados.
0 5 10 15 20 25 30 35 40 45 50t
-8
-6
-4
-2
0
2
4
6
8
10
cloc
k
Clock Masterref
Clock Slave1
Clock Slave2
Clock Slave3
Clock Slave4
Clock Slave5
15 17.5 20 22.5 25
-0.2
0
0.2
Figura 4.17: Simulação do funcionamento do protocolo PTP considerando seis dispositivos.
99
4.3 Serviços de Comunicação em IEC 61850
Nesta seção apresenta-se a modelagem e verificação dos modelos associados aos proto-colos de comunicação GOOSE e SV. No âmbito dos Sistemas de Proteção, estes protocolos sãoextremamente fundamentais, uma vez que são responsáveis pela transmissão das mensagens detempo real crítico no sistema.
As mensagens do tipo GOOSE descrevem a comunicação horizontal entre equipamentospertencentes ao mesmo nível. Estas mensagens são aplicadas em funções de proteção e automa-ção, como por exemplo os trips de relés. Já as mensagens SVs têm a proposta de transmissãode valores amostrados de medição provenientes dos transformadores de instrumentação comsuporte a 61850 ou de Merging Units. Assim como o protocolo GOOSE, as mensagens SVspossuem restrições de tempo real e são utilizadas pelos sistemas de controle e proteção.
4.3.1 Modelagem e Verificação da Transmissão de Mensagens GOOSE
Modelo Emissor GOOSE
O desenvolvimento dos modelos associados à transmissão e recepção de mensagens GO-OSE foi baseado conforme nas máquinas de estado propostas pela parte #8-1 da IEC 61850.O modelo emissor de mensagens GOOSE é apresentado na Figura 4.18. As funções de atu-alização do modelo estão descritas na Figura 4.19. O autômato é composto basicamente portrês estados, N_EXIST, RETRANSMIT_PEND e RETRANSMIT. Inicia-se no estado N_EXIST,o qual indica que a transmissão de mensagens GOOSE está desabilitada pelo seu respectivo NóLógico. O emissor inicia o envio das mensagens apenas quando a variável “b_GoEna” está emnível lógico alto.
O modelo emissor inicia o processo de transmissão de mensagens após o disparo do canalde sincronização receptor “ch_GoEna?”, proveniente do modelo Nó Lógico associado, com avariável “b_GoEna” em nível alto. Conforme abordado no Capítulo 2, utiliza-se o método deretransmissão das mensagens GOOSE para aumentar a probabilidade de sucesso no envio dasmensagens. No modelo em questão, este processo é representado pela variável timeAllowedto-Live “i_ttl”. Esta variável é inserida no pacote de dados que será transmitido, de forma comque o receptor saiba quando deverá receber a próxima mensagem. Se um novo pacote não érecebido em um intervalo próximo (acima de 30%) ao parâmetro “i_ttl” da mensagem atual, odispositivo receptor assume que houve um erro no processo de comunicação.
100
Figura 4.18: Modelo do serviço de emissão de mensagens GOOSE.
1 void m k _ g s e I n i t P a c k ( ) {2 s tBuff_GS . i_ID = i I d ;3 s tBuff_GS . i_SqNum = 0 ;4 s tBuff_GS . i_StNum = ( i_auxStnum%ct_ iCon tL im ) + 1 ;5 s tBuff_GS . i _ t t l = 0 ;6 s tBuff_GS . b_GoEna = b_GoEna [ i I d ] ;7 s tBuff_GS . GOOSEData = g s e _ d a t a [ i I d ] ;8 i_auxStnum = stBuff_GS . i_StNum ;9 }
1011 void mk_gseUpdatePack ( ) {12 s tBuff_GS . i_ID = i I d ;13 s tBuff_GS . i_SqNum = ( s tBuff_GS . i_SqNum%ct_ iCon tL im ) + 1 ;14 s tBuff_GS . b_GoEna = b_GoEna [ i I d ] ;15 s tBuff_GS . GOOSEData = g s e _ d a t a [ i I d ] ;16 i f ( s tBuff_GS . i _ t t l < c t_RetLim ) {17 s tBuff_GS . i _ t t l ++;18 }19 }2021 void mk_gseF in i shPack ( ) {22 / / i_auxStnum = 1 ;23 s tBuff_GS . b_GoEna = b_GoEna [ i I d ] ;24 }2526 void send_gsePack ( ) {27 stBuff_GOLAN [ i _ L a s t ]= s tBuff_GS ;28 stBuff_LAN_TimeStamp [ i _ L a s t ]= hc_tLN [ i I d ] ;29 }
Figura 4.19: Funções de atualização dos pacotes GOOSE.
Os principais atributos que caracterizam a transmissão das mensagens GOOSE foramconsideradas na estrutura dos pacotes. Estes atributos são apresentados na Tabela 4.7, eviden-ciando também os parâmetros considerados nos testes realizados no processo de validação dosmodelos desta seção. Salienta-se que os parâmetros adotados são reduzidos em comparaçãocom a norma para redução do esforço computacional no processo de verificação.
101
O envio das mensagens é realizado através do canal de sincronização emissor “Send!”,onde copia-se a estrutura atual do pacote da mensagem GOOSE (“st_Buff_GS”) para a últimaposição disponível na fila do barramento de comunicação. A implementação da funcionalidadede VLAN ao modelo é realizada através da passagem por parâmetro deste canal de sincroniza-ção.
Tabela 4.7: Descrição das principais variáveis adotadas no Modelo GOOSE.
Variável Descrição Valor
i_StNumEsta variável é utilizada para definir quantas vezes oequipamento mudou de estado (cada evento).
[0,10]
i_SqNum
Esta variável é incrementada a cada retransmissão demensagens. Em condições estáveis, ao atingir o valorlimite do contador retorna para o valor 1. Em mu-dança de estados, esta variável recebe o valor 0.
[0,10]
d_ttlVariável que indica o próximo tempo de espera pararetransmissão das mensagens. Seu incremento é daforma d_ttl = 2i_ttl
[0,64]
b_GoEnaVariável que habilita/desabilita o envio das mensa-gens GOOSE
[true,false]
GOOSEDataVariável que indica os dados transmitidos pela men-sagem GOOSE
[0,10]
De forma a avaliar o comportamento do modelo emissor GOOSE, via simulação e verifi-cação formal, propôs-se um modelo de Nó Lógico com comportamento estocástico. O modeloem questão é apresentado na Figura 4.20.a. Salienta-se que este Nó Lógico foi proposto apenaspara validação dos modelos dos serviços GOOSE e SV.
O Nó Lógico (Figura 4.20.a) inicia habilitando o disparo de mensagens do modelo GO-OSE. Aleatoriamente, este modelo altera os valores das variáveis associadas às mensagens ehabilita/desabilita os serviços de envio.
Além do modelo de Nó Lógico, propôs-se um observador de mensagens GOOSE, repre-sentado na Figura 4.20.b, que verifica o envio e recebimento das mensagens GOOSE sobre aVLAN parametrizada pelos canais de sincronização “ch_LNWriteGo”, “Send” e “Receive”.Através do canal de sincronização receptor “ch_LNWriteGo?” é possível a identificação deuma alteração na variável enviada pelo emissor GOOSE.
Com relação ao modelo emissor GOOSE, na Figura 4.21 está apresentada uma simulaçãoenvolvendo o modelo de Nó Lógico estocástico. Os parâmetros deste cenário são os apresen-tados pela Tabela 4.7. Na simulação estão destacadas as variáveis geradas pelo modelo NóLógico, GoEna e Goose_Data, e as variáveis do modelo emissor GOOSE, instante de retrans-missão das mensagens Retransmit e contadores de sequência e estado das mensagens enviadas.
102
(a)
(b)
Figura 4.20: Modelos auxiliares para verificação dos modelos emissores e receptores GOOSEa) Nó Lógico estocástico e b) observador de mensagens GOOSE.
Conforme previsto pelo protocolo, cada retransmissão da mensagem GOOSE provoca umacréscimo no contador SqNum. Ao atingir o limite deste contador, a variável assume o valor “1”,pois o valor “0” é reservado apenas para a primeira (nova) mensagem enviada pelo emissor. Já ocontador StNum é incrementado a cada atualização da variável enviada pela mensagem GOOSE.
Ainda na Figura 4.21, observa-se que as mensagens são enviadas apenas quando o NóLógico habilita o emissor GOOSE, indicado pela variável GoEna.
A verificação das propriedades sobre o modelo emissor de mensagens GOOSE está apre-sentada na Tabela 4.8. Neste processo foram utilizados o modelo Nó Lógico Estocástico(RGS_LNA), o modelo do serviço emissão de mensagens GOOSE (LNA_SRV_GSE) e o mo-delo observador de mensagens (LNA_OBS).
A propriedade P5.3.1 (Tabela 4.8) avalia o comportamento do modelo frente à habilita-ção/desabilitação de envio de mensagens pelo Nó Lógico. Conforme discutido anteriormente,a norma prevê que a transmissão das mensagens seja realizada apenas quando o Nó Lógicohabilitar o serviço através do parâmetro “GoEna”. Os resultados obtidos nesta propriedadeconfirmam o comportamento do modelo segundo a norma IEC 61850.
103
0 10 20 30 40 50 60 70 80 90 100
t
GoEna
Retransmit
02468
100
2
4
6
8
10
Logical State - Random
Logical State - Model Response
Goose Data - Random
SqNum StNum
Figura 4.21: Simulação considerando o modelo emissor GOOSE.
O processo de geração do contador de sequência “SqNum” é avaliado pela propriedadeP5.3.2 (Tabela 4.8). Em condições estáveis da variável observada pela mensagem GOOSE, ocontador deve ser incrementado de “1” até o valor limite parametrizado. Excepcionalmente, naocorrência de um evento que altere a variável observada, a próxima mensagem enviada deveconstar com “SqNum” em “0”, evidenciando o primeiro envio da mensagem.
Por fim, na propriedade P5.3.3 (Tabela 4.8) avalia-se a atualização do contador de sequên-cia “StNum” está em conformidade com a norma. Os resultados apresentados nesta propriedadeindicam que a variável “StNum” é atualizada apenas quando há atualização da variável enviadapela mensagem GOOSE.
104Tabela 4.8: Verificação sobre o serviço de emissão de mensagens GOOSE.
Nome Descrição Informal Descrição Formal Resultado
P5.3.1Verifica a probabilidade do modelo enviar mensagensGOOSE após a habilitação/desabilitação do Nó Ló-gico.
Pr[<=1000] ([](LNA_SRV_GSE.RETRANSMIT_PEND
or LNA_SRV_GSE.RETRANSMIT) imply
b_GoEna[ct_LNAID]==false)
0,00%
Pr[<=1000] ([](LNA_SRV_GSE.RETRANSMIT_PEND
or LNA_SRV_GSE.RETRANSMIT) imply
b_GoEna[ct_LNAID]==true)
100,00%
P5.3.2
Verifica a probabilidade do modelo atualizar correta-mente o contador de sequência SqNum:• Em caso de atualização da variável enviada pelamensagem, SqNum deve ser “0”;• Se o contador atingir o limite em condições estáveis,deve ser atualizado para “1”.
Pr[<=1000]([] ( LNA_OBS.b_newGoose==trueand LNA_SRV_GSE.RETRANSMIT) implystBuff_GOLAN[i_Last].i_SqNum==0)
100,00%
Pr[<=1000]([] ( LNA_OBS.b_newGoose==trueand LNA_SRV_GSE.RETRANSMIT) implystBuff_GOLAN[i_Last].i_SqNum!=0)
0,00%
Pr[<=1000]([] (LNA_OBS.b_newGoose==falseand LNA_OBS.G_SEND) implystBuff_GOLAN[i_Last].i_SqNum==((LNA_OBS.stBuff_GObs.i_SqNum%ct_iContLim)+1))
100,00%
Pr[<=1000]([] (LNA_OBS.b_newGoose==false
and LNA_OBS.G_SEND) imply
stBuff_GOLAN[i_Last].i_SqNum!=
((LNA_OBS.stBuff_GObs.i_SqNum%
ct_iContLim)+1))
0,00%
P5.3.3 Verifica a probabilidade do modelo atualizar correta-mente o contador de sequência StNum.
Pr[<=1000]([] (LNA_OBS.b_newGoose==false
and LNA_OBS.G_SEND) imply
stBuff_GOLAN[i_Last].i_StNum==
LNA_OBS.stBuff_GObs.i_StNum)
0,00%
Pr[<=1000]([] (LNA_OBS.b_newGoose==true
and LNA_OBS.G_SEND) imply
stBuff_GOLAN[i_Last].i_StNum==
(LNA_OBS.stBuff_GObs.i_StNum%ct_iContLim))
100,00%
105
Modelo Receptor GOOSE
Assim como a modelagem do serviço de emissão de mensagens GOOSE, o modelo derecepção de mensagens foi desenvolvido baseado na parte #8-1 da IE 61850, e consiste ba-sicamente de três estados: “NON_EXISTENT”, “VALID” e “QUESTIONABLE”. O modeloproposto nesta dissertação é apresentado na Figura 4.22.
Figura 4.22: Modelo do serviço de recepção de mensagens GOOSE.
O modelo inicia no estado “N_EXIST”, no qual indica que nenhuma mensagem é espe-rada pelo receptor. O recebimento de uma mensagem é realizada pelo canal de sincronizaçãoreceptor “Receive?”, que copia o primeiro pacote disponível na fila do barramento de comuni-cação. O canal de sincronização é instanciado ao modelo via passagem por parâmetro, assim épossível a implementação da VLAN entre emissor e receptor.
Nem toda mensagem recebida pelo receptor GOOSE é processada, pois os Nós Lógicosnecessitam conhecer o estado de determinados dispositivos de acordo com sua parametrização,logo, primeiramente verifica-se se o pacote recebido é de interesse do Nó Lógico, para posteriorprocessamento da mensagem. Essa verificação é realizada pelo parâmetro “i_ID” do pacoteGOOSE, que indica o endereço do Nó Lógico emissor da mensagem.
Caso a mensagem recebida pelo receptor seja de interesse e o conteúdo do pacote es-teja atualizado, a mensagem é processada pelo Nó Lógico através do canal de sincronização“ch_LNReadGo!”. O receptor aguarda o intervalo de tempo d_ttl presente no pacote recebido.Se uma nova mensagem de interesse é entregue ao receptor antes do intervalo d_ttl, o modeloassume como uma mensagem válida. Após este intervalo, o não recebimento da mensagemimplica em um erro de envio da mensagem.
Em caso de erro, o modelo retorna ao estado “N_EXIST”, indicando ao Nó Lógico quenão houve o recebimento de uma mensagem GOOSE. O modelo também volta ao estado inicialcaso o Nó Lógico emissor envie o parâmetro “b_GoEna” em nível lógico baixo, o que implicaem uma interrupção intencional no envio das mensagens.
106
Para subsidiar o processo de validação do serviço de recepção de mensagens GOOSEpropô-se a representação de um Nó Lógico receptor de mensagens GOOSE. O modelo de NóLógico desenvolvido é apresentado na Figura 4.23. Assim como o Nó Lógico associado aoserviço de emissão de mensagens, discutido anteriormente, este Nó Lógico possui finalidadeapenas de subsídio à validação do serviço de recepção, não havendo interpretações com os NósLógicos desenvolvidos às funções de proteção.
Figura 4.23: Modelo do Nó Lógico receptor GOOSE.
O Nó Lógico interagem com o serviço de recepção de mensagens GOOSE através detrês canais de sincronização: “ch_gseRead”, que indica ao Nó Lógico que a próxima leituracorresponde a um novo valor da variável observada, “ch_gseStop”, que indica uma interrupçãointencional do Nó Lógico emissor na transmissão das mensagens e o canal “ch_gseFail”, o qualindica a ocorrência de uma falha no processo de transmissão das mensagens GOOSE.
Do modelo de recepção de mensagens GOOSE, a ocorrência de uma falha é sinalizada oupor estouro no tempo de espera do próximo pacote GOOSE, de acordo com o parâmetro “ttl”do pacote atual, ou por erro no contador de sequência “SqNum” do pacote atual, em relação aoúltimo pacote recebido.
Além dos modelos supracitados, propôs-se a integração do modelo de barramento de co-municação com temporização fixa, proposto no início do capítulo. A escolha por este modelo deLAN é devido à melhor interpretação lógica dos resultados obtidos via simulação e verificaçãoformal. No entanto, a adoção do modelo de LAN com temporização fixa nos pacotes permiteapenas a ocorrência de falhas devido ao contador de sequência, em situações de overflow dobarramento de comunicação.
Adicionalmente, propôs-se uma função de distribuição uniforme com faixa entre 1 e 20unidades de tempo para determinação do tempo de espera da fila do barramento de comunica-ção, uma vez que o intervalo de transmissão das mensagens GOOSE é determinado pela funçãode retransmissão exponencial.
Para a verificação do modelo de recepção, propõe-se o cenário composto pelo Nó Ló-gico emissor de mensagens GOOSE (RGS_LNA), o modelo do serviço de transmissão GOOSE(LNA_SRV_GSE) , o modelo de LAN com tempo fixo (LAN), o modelo do serviço de recepção
107
de mensagens GOOSE (LNB_CLT_SMV_LNA), parametrizado para processar informações doNó Lógico LNA e o Nó Lógico receptor (LNB_GSE), além dos modelos observadores que cap-turam os eventos para fins de debug. O evento habilita/desabilita a transmissão de mensagensno modelo do Nó Lógico emissor foi desativado. Na Figura 4.24 é apresentada uma simula-ção para o cenário de validação proposto. Na simulação em questão, a temporização da LANdeterminada foi de 2 unidades de tempo.
0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100
t
GoEna
Transmit
02.5
57.510
0
2
4
6
Logical Variable - Random
Logical State - Model Response
Data_SenderData_Receiver
sqNum_SendersqNum_Receiver
Figura 4.24: Simulação considerando o modelo receptor GOOSE.
Na simulação apresentada pela Figura 4.24 estão destacadas as principais variáveis quedeterminam o comportamento dos modelos. Detalhando-se principalmente a variável observadapela mensagem “GOOSEData” e o contador de sequência “SqNum”. Conforme observado nafigura, o modelo emissor receptor possui um atraso de tempo fixo com relação às variações nomodelo emissor.
O comportamento esperado pelo modelo foi traduzido nas propriedades descritas pela Ta-bela 4.9. Diferente dos processos de verificação realizados até o momento, neste foi necessárioa redução do intervalo de confiança para 95%.
Primeiramente, através da propriedade P5.3.4 (Tabela 4.9), verifica-se o comportamentobásico do Nó Lógico em receber mensagens. O resultado obtido de 100% indica que, mesmo naocorrência de overflow no barramento de comunicação, não há bloqueios na rede de autômatosque impossibilitam o recebimento das mensagens.
A propriedade P5.3.5 (Tabela 4.9) avalia a probabilidade do cenário apresentar erros noprocesso de transmissão das mensagens. Conforme discutido anteriormente, do modelo de LANadotado os erros de transmissão estão associados ao overflow do barramento de comunicação.Da característica de retransmissão em intervalos de tempo exponencial das mensagens GOOSE,a interpretação do resultado de 85, 31% não é uma tarefa trivial. Nesse contexto, assume-seapenas uma interpretação qualitativa de que o modelo pode apresentar problemas de transmissãodas mensagens.
108Tabela 4.9: Verificação do serviço de recepção de mensagens GOOSE.
Nome Descrição Informal Descrição Formal Resultado
P5.3.4 Verifica a probabilidade do modelo em receber men-sagens. Pr[<=500](<> LNB_GSE.LISTEN) 100.00%
P5.3.5 Verifica a probabilidade da composição entre os mo-delos apresentar falha na recepção das mensagens. Pr[<=500](<> LNB_GSE.PACK_ERROR) 85.31%
P5.3.6Verifica a probabilidade de ocorrência da falha asso-ciada a um evento de overflow do sistema de comuni-cação
Pr[<=500](<> LNB_GSE.PACK_ERROR and!LAN.b_flagoverflow)
0.00%
Pr[<=500]([] LNB_GSE.PACK_ERROR implyLAN.b_flagoverflow)
100.00%
P5.3.7
Verifica a probabilidade de integridade de recebi-mento das mensagens pelo Nó Lógico receptor:• A mensagem recebida corresponde ao primeiro pa-cote da fila do barramento de comunicação;• O dado recebido pelo Nó Lógico corresponde aodado recebido pelo serviço de recepção;• O Nó Lógico sempre lê a primeira mensagem pósatualização da variável.
Pr[<=500](<> (LNB_CLT_GSE_LNA.RECand !LAN.b_flagoverflow) &&LNB_CLT_GSE_LNA.stBuff_GR!=stBuff_GOLAN[i_First])
0.00%
Pr[<=500]([] (LNB_GSE.LISTENand !LAN.b_flagoverflow) implyLNB_CLT_GSE_LNA.stBuff_GR.GOOSEData==LNB_GSE.stBuff_GOLN.GOOSEData)
100.00%
Pr[<=500]([] (LNB_GSE.LISTENand !LAN.b_flagoverflow) implyLNB_CLT_GSE_LNA.stBuff_GR.i_SqNum==0)
100.00%
109
Estes erros são devidamente associados ao overflow da LAN através propriedade P5.3.6(Tabela 4.9), de onde é possível afirmar que a ocorrência de overflow no barramento de co-municação acarreta em problemas na transmissão do protocolo GOOSE. Esta propriedade éreforçada pelos resultados obtidos na etapa de verificação da LAN. Salienta-se que, no modelode LAN com tempo de atraso baseado em distribuição lognormal, por exemplo, os erros detransmissão também estariam associados à inversão de pacotes e ao desvio do tempo de atraso(Jitter) no barramento de comunicação.
Por fim, a propriedade P5.3.7 (Tabela 4.9) é subdividida em três verificações, as quaisavaliam a corretude dos dados entregues ao Nó Lógico. Verifica-se se a sequência das mensa-gens da fila do barramento de comunicação é mantida durante a leitura do pacote pelo serviçode recepção e se o dado recebido corresponde ao mesmo entregue ao Nó Lógico. Além disso,verifica se a mensagem entregue ao Nó Lógico corresponde ao primeiro pacote enviado peloserviço de emissão de mensagens GOOSE.
4.3.2 Modelagem e Verificação da Transmissão de Mensagens SV
Os modelos de transmissão das mensagens de valores amostrados SVs foram desenvol-vidos sob uma variação dos modelos GOOSE, apresentados na subseção anterior. A principaldiferença entre os modelos está no mecanismo de retransmissão das mensagens utilizado pelosserviços.
O modelo do serviço de emissão das mensagens SVs proposto nesta dissertação é apre-sentado na Figura 4.25. A função de montagem do pacote utilizado no modelo é apresen-tada na Figura 4.26. Assim como no modelo GOOSE, as mensagens são enviadas apenasquando o Nó Lógico associado ao serviço habilita a emissão das mensagens, através da va-riável “b_SvEna[iId]”. O modelo envia as mensagens periodicamente de acordo com a taxade envio parametrizada por “i_smpRate”. Esta variável também é inserida no pacote enviado,de forma com que o receptor possa identificar eventuais problemas na transmissão da próximamensagem.
Figura 4.25: Modelo do serviço de emissão de mensagens SV.
110
1 void mk_SVPack ( ) {2 s tBuff_SVS . i_ID = i I d ;3 s tBuff_SVS . i_smpCnt = i_auxsmpCnt ;4 s tBuff_SVS . i_smpRate = i_smpRate ;5 s tBuff_SVS . b_SvEna = b_SvEna [ i I d ] ;6 s tBuf f_SVS_t ime = hc_tLN [ i I d ] ;7 stBuff_SVS_mod = d_LNmod [ i I d ] ;8 s tBuff_SVS_ang = d_LNang [ i I d ] ;9 i_auxsmpCnt = ( s tBuff_SVS . i_smpCnt%c t_ iCon tL im ) + 1 ;
10 }
Figura 4.26: Montagem dos pacotes do protocolo SV.
Outra maneira do receptor identificar erros de transmissão nas mensagens SVs é atravésdo contador de sequência “i_smpCnt” inserido nos pacotes. Assim como no serviço de emissãoGOOSE, o início da transmissão é devidamente identificado pelo valor reservado “0”. Duranteo restante da transmissão, este contador é incrementado até o valor limite e retorna ao valor “1”.
Completando a estrutura do pacote SV adotado, inclui-se dois conjuntos de dados digitaissimbolizando uma grandeza vetorial, módulo e ângulo. Além destes, uma estampa de tempotambém é adicionado ao pacote.
Para validação do modelo de emissão, o mesmo nó lógico proposto na Figura 4.20 foiempregado. Com relação ao protocolo SV, este nó lógico habilita e desabilita a emissão dasmensagens e altera o valor da grandeza digital a ser enviada, de modo aleatório.
Um modelo observador também foi proposto para avaliar o serviço de emissão de mensa-gens SVs. O modelo basicamente copia os comandos enviados pelo Nó Lógico e as mensagensque são transmitidas pelo dispositivo emissor.
Na Figura 4.27 é apresentada uma simulação envolvendo o Nó Lógico emissor e o ser-viço de emissão de mensagens SV (Figura 4.25), destacando as principais variáveis do modelo.Na simulação em questão, foram adotados como parâmetros o intervalo de tempo de envio(“i_smpRate”) 4 unidades de tempo, limite do contador de sequência em 10 unidades e varia-ção baseada em função uniforme entre 0 e 5 unidades para as variáveis digitais (“ang” e “mod”).
Da simulação, observa-se que o modelo somente faz a transmissão das mensagens quandoa variável “SvEna” está em nível lógico alto. O intervalo entre envio das mensagens está em 4unidades de tempo, conforme parametrizado, com o contador de sequência iniciando em “0”,nas primeiras mensagens após a borda de subida de “SvEna”, e sendo incrementado a cada novoenvio. Com relação aos dados digitais, nota-se que no instante de envio de cada mensagem,atualizam-se as variáveis “mod” e “ang” com os valores atuais do Nó Lógico.
111
0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100
t
SvEna
Transmit
0
2.5
50
2.5
50
2
4
6
Logical Variable - Random
Logical State - Model Response
mod_LN mod_SV
ang_LN ang_SV
smpCont
Figura 4.27: Modelo do serviço de recepção de mensagens SV.
A Tabela 4.10 apresenta o processo de verificação formal realizado sobre o serviço deemissão das mensagens SVs. O cenário deste processo é composto pelo nó lógico emissor demensagens SV (RGS_LNA), pelo serviço de emissão de mensagens SV (LNA_SRV_SMV) epelo observador do nó lógico (LNA_OBS).
Primeiramente verifica-se a probabilidade do modelo enviar mensagens de acordo coma permissão do Nó Lógico associado ao serviço de emissão. O resultado apresentado nestapropriedade (P5.3.8 - Tabela 4.10) indica que o modelo envia mensagens somente quando o NóLógico habilita este serviço.
O intervalo entre as emissões é verificado através da propriedade P5.3.9 (Tabela 4.10).Os valores resultantes na propriedade em questão indicam que o modelo envia as mensagens deacordo com o valor parametrizado pelo variável “i_smpRate”.
Assim como no serviço de transmissão de mensagens GOOSE, a primeira mensagemenviada pelo serviço de transmissão SV deve estar devidamente identificada. A propriedadeP5.3.10 (Tabela 4.10) avalia esta identificação. A primeira mensagem enviada pelo modeloemissor deve constar com o contador “i_smpCnt” em valor “0”, e ao longo da transmissão dasmensagens, o contador é incrementado de “1” até o valor limite. Os resultados obtidos por estaverificação validam este comportamento.
Por fim, a propriedade P5.3.11 (Tabela 4.10) avalia se os valores digitais que são enviadospelas mensagens SV correspondem aos valores presentes no Nó Lógico no instante de envio dasmensagens. O modelo de emissão proposto também atende esta propriedade.
112Tabela 4.10: Verificação do serviço de emissão de mensagens SV.
Nome Descrição Informal Descrição Formal Resultado
P5.3.8 Verifica a probabilidade do modelo enviar mensagensSV após a habilitação/desabilitação do Nó Lógico.
Pr[<=100]([] (LNA_SRV_SMV.TRANSMITor LNA_SRV_SMV.WAIT_SMP) implyb_SvEna[ct_LNAID]==true)
100.00%
Pr[<=100]([] (LNA_SRV_SMV.TRANSMITor LNA_SRV_SMV.WAIT_SMP) implyb_SvEna[ct_LNAID]!=true)
0.00%
P5.3.9 Verifica a probabilidade do modelo enviar mensagensno intervalo de tempo especificado por i_smpRate.
Pr[<=100]([] LNA_SRV_SMV.TRANSMITimply LNA_SRV_SMV.c_sv<=LNA_SRV_SMV.i_smpRate)
100.00%
Pr[<=100]([] LNA_SRV_SMV.TRANSMITimply LNA_SRV_SMV.c_sv>LNA_SRV_SMV.i_smpRate)
0.00%
P5.3.10
Verifica a probabilidade do modelo atualizar correta-mente o contador de sequência i_smpCnt:• O primeiro envio da mensagem deve iniciar emsmpCnt = 0;• Se o contador atingir o limite sem que ocorra umaparada pelo Nó Lógico, o mesmo retorna para o valor“1”.
Pr[<=100]([] LNA_OBS.SV_SENDand LNA_OBS.b_newSV==true implyLNA_OBS.stBuff_SVObs.i_smpCnt==0)
100.00%
Pr[<=100]([] LNA_OBS.SV_SEND andLNA_OBS.b_newSV==false implyLNA_OBS.stBuff_SVObs.i_smpCnt==((LNA_OBS.Obs_smpCntOld%ct_iContLim)+1))
100.00%
P5.3.11 Verifica a probabilidade do modelo enviar correta-mente as variáveis do seu Nó Lógico associado.
Pr[<=100]([] LNA_SRV_SMV.TRANSMIT implyLNA_SRV_SMV.stBuff_SVS_mod==d_LNmod[ct_LNAID] andLNA_SRV_SMV.stBuff_SVS_ang==d_LNang[ct_LNAID])
100.00%
113
Com relação ao serviço de recepção das mensagens SV, na Figura 4.28 é apresentado omodelo proposto nesta dissertação. O modelo em questão também trata-se de uma variação domodelo de recepção de mensagens GOOSE. O modelo é responsável pela validação da mensa-gem recebida e posteriormente, caso a mensagem seja válida, envio dos dados recebidos ao seuNó Lógico associado.
Figura 4.28: Modelo do serviço de recepção de mensagens SV.
A verificação é realizada em três etapas. Primeiramente verifica-se o endereço do emissordo pacote. Se a mensagem é de interesse ao Nó Lógico, posteriormente verifica-se a validadeda mensagem através do contador de sequência contido no pacote. O valor da taxa de envio dodispositivo emissor também é utilizado como verificação de integridade da mensagem. Caso otempo esperado pela próxima mensagem ultrapasse o tempo de 30% a mais do que o contidona variável “i_smpRate” do último pacote, o modelo assume que houve um erro no processo decomunicação.
A interação com o Nó Lógico receptor é realizada através de quatro canais de sincroni-zação: “ch_svStop”, “ch_svStart”, “ch_svRead” e “ch_svFail”. O primeiro canal indica ao NóLógico que o emissor parou de enviar as mensagens propositalmente. A falta de recepção dasmensagens não informada pelo emissor SV é indicada ao Nó Lógico com o canal “ch_svFail”.Este canal também é utilizado caso o contador de sequência da mensagem recebida não estáem coerência com a última mensagem, indicando a perda ou inversão de pacotes no sistema decomunicação. O canal “ch_svStart” indica ao Nó Lógico o início do processo de transmissãode mensagens SV. A cada leitura válida, o Nó Lógico atualiza as variáveis digitais de acordocom o canal “ch_svRead”.
O Nó Lógico apresentado na Figura 4.29 foi proposto para verificar o comportamento domodelo de recepção das mensagens SV. A interação entre o modelo receptor é realizada atravésdos canais de sincronização supracitados.
114
Figura 4.29: Modelo do Nó Lógico receptor SV.
Na Figura 4.30 é apresentada uma simulação envolvendo os modelos de emissão e recep-ção de mensagens SVs. O intervalo entre envio de mensagens considerado nas simulações éde 6 unidades de tempo. São evidenciados as principais variáveis associadas aos serviços deemissão e recepção das mensagens. O barramento de comunicação com atraso fixo foi adotadoneste estudo, o que facilita a compreensão dos resultados obtidos no processo de validação. Oatraso no barramento foi parametrizado em 3 unidades de tempo.
0 10 20 30 40 50 60 70 80 90 100
t
SvEna
Transmit
0
2.5
5
0
2.5
5
02468
Logical Variable - Random
Logical State - Model Response
mod_Sendermod_Rec
ang_Senderang_Rec
smpCnt_SendersmpCnt_Rec
Figura 4.30: Simulação envolvendo o modelo de recepção SV.
Como o cenário em questão consta de um modelo de LAN com temporização fixa, umevento de falha na transmissão dos pacotes possível é ocorrência de overflow no barramentode comunicação. Assim sendo, conforme visto na seção de desenvolvimento dos modelos dobarramento de comunicação, a ocorrência de overflow faz com que algumas mensagens não sãopublicadas no sistema, havendo assim, a alteração dos contadores de sequência dos pacotes.
O cenário considerado no estudo de validação do modelo de recepção foi compostopelo modelo nó lógico emissor aleatório (RGS_LAN), o serviço de emissão de mensagensSV (LNA_SRV_SV), o modelo de LAN com temporização fixa (LAN), o serviço de recep-ção de mensagens SV (LNB_CLT_SV) e o nó lógico de recepção (LNB_SV), além de modelosobservadores.
115
Considerou-se como intervalo de transmissão do modelo emissor em 6 unidades de tempoe o atraso da LAN determinado através de uma função de distribuição uniforme entre 10e 50. Desta forma, os valores limites da função de distribuição uniforme que determina oatraso no barramento de comunicação foi determinado considerando a propriedade de over-flow verificada na seção de validação da LAN, sendo o limite do intervalo entre envio demensagens determinado pelo atraso e pelo tamanho do buffer da LAN. Para o caso em ques-tão, adota-se um buffer com tamanho de 5 unidades, logo, o valor limiar de atraso para otempo de transmissão do modelo emissor (6 unidades de tempo) é 30 unidades de tempo, poisdelayfix/ct_iLim = 30/5 = 6.
O principal comportamento esperado pelos modelos de recepção foram representadosatravés das propriedades destacadas na Tabela 4.11. Assim como na validação dos modelosGOOSE, os resultados foram obtidos com intervalo de confiança de 95%.
A propriedade P5.3.12 (Tabela 4.11) verifica se no cenário em questão ocorre um eventode erro ao processo de comunicação. Conforme abordado anteriormente, como o modelo deLAN adotado no processo de verificação formal é o modelo com temporização fixa, o únicoevento associado a um erro de comunicação será o de overflow do barramento de comunicação.Neste caso, a probabilidade de ocorrência de erro no cenário de comunicação considerado é omesmo do que a probabilidade de ocorrência de overflow na LAN. Para os parâmetros conside-rados, o resultado obtido de 56.31% está coerente com o valor esperado, uma vez que a variaçãopermitida ao delay da LAN esteja em uma faixa de 10 a 50 unidades de tempo, sendo o intervalode 30 o valor limiar para ocorrência de overflow.
Ainda com a ocorrência de overflow do barramento de comunicação, o modelo de re-cepção de mensagens SV ainda está disponível para recebimento de outros pacotes, conformeresulta a propriedade P5.3.13 (Tabela 4.11), indicando a ausência de deadlock na rede de autô-matos.
A associação de um erro de recebimento das mensagens SV ao evento de overflow no bar-ramento de comunicação é avaliado através da propriedade P5.3.14. Verifica-se a probabilidadede ocorrência de um erro de recepção sem que haja overflow na LAN. O resultado esperadodesta probabilidade seria de 0, 0%, no entanto, como o intervalo de confiança foi reduzido para90%, naturalmente alguns resultados apresentarão desvios em relação ao valor esperado. Damesma forma foi observado na outra verificação associada à propriedade P5.3.14 (Tabela 4.11),onde verifica-se que sempre na ocorrência de um erro de recepção, um evento de overflow deveser observado.
A propriedade P5.3.15 (Tabela 4.11) verifica a probabilidade do modelo sempre ler amensagem que está na primeira posição da fila do buffer do barramento de comunicação. Senão houver inversão de pacotes no sistema de comunicação, esta propriedade garante que oreceptor sempre está lendo as mensagens de maneira sequencial com que foram enviadas àLAN.
116Tabela 4.11: Verificação Receptor SV.
Nome Descrição Informal Descrição Formal Resultado
P5.3.12 Verifica a probabilidade da composição entre os mo-delos apresentar falha na recepção das mensagens. Pr[<=350](<> LNB_SV.PACK_ERROR) 56.31%
P5.3.13 Verifica a probabilidade do modelo em receber men-sagens.
Pr[<=350](<> (LAN.b_flagoverflow or!LAN.b_flagoverflow) and LNB_SV.LISTEN)
100.00%
P5.3.14Verifica a probabilidade de ocorrência da falha asso-ciada a um evento de overflow do sistema de comuni-cação
Pr[<=350](<> LNB_SV.PACK_ERROR and!LAN.b_flagoverflow)
8.15%
Pr[<=350]([] LNB_SV.PACK_ERROR implyLAN.b_flagoverflow)
93.76%
P5.3.15Verifica a probabilidade do Nó Lógico receber sem-pre a primeira mensagem disponível na pilha do bar-ramento de comunicação.
Pr[<=100]([] LNB_SV.LISTEN implystBuff_SVLAN_mod[i_First]==LNB_SV.stBuff_SVLN_mod &&stBuff_SVLAN_ang[i_First]==LNB_SV.stBuff_SVLN_ang)
100.00%
P5.3.16 Verifica a probabilidade em manter a sequência na or-dem das mensagens entregues ao Nó Lógico receptor.
Pr[<=100]([] LNB_CLT_SMV_LNA.A implyLNB_CLT_SMV_LNA.stBuff_SVR.i_smpCnt==((LNB_CLT_SMV_LNA.i_smpCntold%ct_iContLim)+1))
0.00%
Pr[<=350]([] (!LAN.b_flagoverflowand LNB_CLT_SMV_LNA.A andLNB_CLT_SMV_LNA.b_FirstPack==false)implyLNB_CLT_SMV_LNA.stBuff_SVR.i_smpCnt==((LNB_CLT_SMV_LNA.i_smpCntold%ct_iContLim)+1))
89.82%
117
Esta sequência de recepção é melhor avaliada na propriedade P5.3.16 (Tabela 4.11). Pri-meiramente, verifica-se a probabilidade do modelo sempre ler as mensagens em sequência dobuffer da LAN. Esta verificação é realizada sobre os contadores de sequência de mensagenssucessivas. No entanto, o resultado de 0% indica que esta propriedade não é verdadeira. Istoacontece pois não foi verificado a ocorrência de overflow no barramento de comunicação. Logo,a segunda verificação realizada em P5.3.16 indica que o cenário em análise possui 89, 82% deprobabilidade em manter a sequência de leitura das mensagens.
4.4 Modelagem e Verificação da Merging Unit
Conforme abordado no capítulo de revisão bibliográfica desta dissertação, o modelo Mer-ging Unit representa os dispositivos que estão conectados ao barramento de processo coletandoe enviando os dados associados às funções de controle e proteção. Dentro do contexto destetrabalho, os dados amostrados são provenientes de sinais analógicos de corrente e tensão detransformadores de instrumentação do SAS, conforme indicado pela Figura 4.31.
V I
IEC 61850-9-2 (SV)
IEC 61850-8-1 (GOOSE)
Merging
Unit
Clock
Synchronization
Figura 4.31: Conceito básico de aplicação de Merging Unit.
Em síntese, a Merging Unit realiza a transdução de sinais contínuos e/ou discretos dosequipamentos de campo para o Barramento de Processo, onde estão conectados os IEDs queprocessam os sinais amostrados em funções específicas de controle e proteção. Logo, a Mer-ging Unit deve contemplar basicamente processos de condicionamento de sinais, conversoresanalógicos-digitais (AD) e interface de comunicação Ethernet. Devido à característica distri-buída dos Sistemas de Proteção, adota-se o emprego de várias Merging Units instaladas ao longodo SAS, logo, a sincronização temporal das amostras é item crucial para o funcionamento dosistema de proteção.
Na Figura 4.32 é apresentado um diagrama ilustrativo contendo os principais modelosque serão considerados no funcionamento das Merging Units. Conforme indicado pela figuraem questão, o modelo de Merging Unit proposto nesta dissertação realiza a amostragem deum sinal analógico, adiciona a estampa de tempo à amostra, e disponibiliza para o barramento
118
de comunicação através de mensagens SV. Como os modelos de emissão das mensagens SVe do protocolo de sincronização PTP já foram devidamente discutidos, esta seção apresenta amodelagem e verificação do processo de amostragem do sinal analógico.
A/D
ProcessPTP
Process
SV Publisher
Process
IEC 61850-9-2
SAMPLED VALUES
Analog
Values
Sampled
Values
Clock
Synchronization
Messages
Figura 4.32: Modelo representativo da Merging Unit.
O modelo proposto para o processo de amostragem do sinal de entrada é apresentado naFigura 4.33. Periodicamente o modelo armazena em um buffer que representa a temporizaçãodo processo de conversão AD. Na figura em questão, implementou-se a função de distribuiçãoU-Shape, a qual indica a densidade de probabilidade de amostragem de um sinal senoidal. Aaquisição do relógio local da Merging Unit é realizada no instante da amostragem do sinal.
(a)
(b)
Figura 4.33: Modelo proposto de Merging Unit. a) Amostragem do sinal de entrada e b) NóLógico para envio de mensagens SV.
Transcorrido o tempo de conversão da amostra, a mesma é disponibilizada pelo canal desincronização “ch_SampleDisp” ao modelo do Nó Lógico, representado pela Figura 4.33.b. Omodelo do serviço de transmissão de mensagens SV copia os dados do Nó Lógico, encapsulamem pacote específico, e transferem em intervalos de tempo definidos pela taxa de amostragemdo sinal.
119
Uma simulação deste processo é ilustrado na Figura 4.34. No cenário em questão, adotou-se como sinal de entrada uma onda senoidal com variações aleatórias em 1.05 pu na frequênciae amplitude. A taxa de amostragem adotada foi de 0.1 unidades de tempo e o delay no processode conversão em 2 unidades de tempo. Evidencia-se na figura o sinal analógico e discretizadopelo modelo e a estampa de tempo correspondente para cada amostra.
0 2.5 5 7.5 10 12.5 15 17.5 20 22.5 25 27.5 30
t
-1.5
-1
-0.5
0
0.5
1
1.50
6
12
18
24
30
analog_valuesampled_value
time_analogtime_sampled
Figura 4.34: Simulação do processo de amostragem de uma Merging Unit.
Para subsidiar o processo de verificação da Merging Unit propôs-se o observador ilustradona Figura 4.35. O modelo armazena os dados que são amostrados pelo conversor AD e os dadosque são disponibilizados ao Nó Lógico. Salienta-se que o modelo observador é válido apenasem curto intervalo de tempo, uma vez que as mensagens armazenadas por ele não são retiradasdo buffer de leitura. A capacidade do buffer foi parametrizada em 1.000 unidades.
Figura 4.35: Observador do modelo Merging Unit.
O comportamento esperado pelo modelo Merging Unit foi traduzido nas propriedadesapresentadas pela Tabela 4.12. Conforme abordado anteriormente, a verificação consiste ape-nas no processo de amostragem do sinal analógico de entrada. A propriedade P5.4.1 (Tabela4.12) verifica o tempo total do processo de amostragem e conversão do sinal de entrada. Noperíodo analisado, todas as amostras apresentaram tempo de espera inferior ou igual ao valorparametrizado.
Na propriedade 5.4.2 (Tabela 4.12) é verificada se é mantida a ordem dos dados amostra-dos e enviados pelo Nó Lógico. Da descrição formal que representa a propriedade em questão,
120
faz-se necessário aguardar o tempo de atraso do AD correspondente à posição da amostra nobuffer de leitura do observador. Ambas propriedades indicam o comportamento esperado peloMerging Unit.
Tabela 4.12: Verificação das propriedades sobre o modelo Merging Unit.
Nome Descrição Informal Descrição Formal Resultado
P5.4.1
Verifica a probabilidade dotempo de atraso do processode conversão AD estar dentrodo período especificado
Pr[<=5] ([]forall(i:BuffAD_len)(c_tDelayAD[i]<=T_AD.ct_tDelayFix))
100.00%
P5.4.2Verifica a probabilidade domodelo em manter a sequên-cia das amostras
Pr[<=5]([]forall(i:BuffObs_len)(Obs_MU.SENDand t>(i+1)*T_AD.ct_tDelayFix implyObs_MU.d_VarSampled[i]==Obs_MU.d_VarSent[i]))
100.00%
Pr[<=5]([]forall(i:BuffObs_len)(Obs_MU.SENDand t>(i+1)*T_AD.ct_tDelayFix implyObs_MU.d_tsSampled[i]==Obs_MU.d_tsSent[i]))
100.00%
4.5 Modelagem e Verificação das Funções de Proteção
Esta seção apresenta o desenvolvimento dos modelos associados às funções de proteçãodos IEDs. Como o comportamento dos protocolos de transmissão de mensagens em tempo real(GOOSE e SV) e sincronização de tempo (PTP) já foram abordados ao longo deste capítulo,estes modelos não serão considerados neste seção.
Serão abordadas três funções de proteção nesta dissertação: proteção de distância (PDIS),proteção de sobrecorrente instantânea (PIOC) e proteção de sobrecorrente temporizada (PTOC).A distribuição dos nós lógicos segundo seu grupo funcional, de acordo com a IEC 61850, emum cenário teste é apresentado na Figura 4.36. Adicionalmente aos modelos comentados, afigura apresenta o Nó Lógico MMXU, o qual processa os valores amostrados de corrente etensão disponibilizando informações como módulo, fase, valor rms, entre outras grandezas.O Nó Lógico PTRC conecta as saídas de trips das funções de proteção e transmite ao NóLógico XCBR, o qual modela o comportamento do disjuntor. Estes dois modelos não serãoconsiderados nesta seção.
121
TVTR TCTR
MUMMXU
PDIS
PIOC
PTOC
PTRC
IED
XCBR
Figura 4.36: Estrutura de proteção considerada.
Na Figura 4.37 estão apresentados os modelos que abstraem o comportamento do IEDadotado nos estudos. O Nó Lógico da função de proteção é descrito pela Figura 4.37.a. Omodelo recebe as mensagens do receptor SV associado à função de proteção parametrizado. Noexemplo em questão, o modelo recebe mensagens SV do modelo MMXU contendo o móduloda corrente elétrica e a resistência e reatância calculada a partir do ponto de medição associadoà Merging Unit. A cada mensagem recebida, o Nó Lógico envia um comando para que oalgoritmo da função de proteção processe a informação. Em caso de anomalias detectadas pelafunção de proteção associado ao Nó Lógico, o mesmo envia o comando de trip ao barramentode comunicação através do modelo emissor de mensagens GOOSE.
Conforme abordado anteriormente, serão consideradas três funções de proteção nesta dis-sertação. Na Figura 4.37.b é apresentado o algoritmo da função de proteção de distância. Omodelo recebe como parâmetros a configuração da zona de proteção como impedância da linhade transmissão, temporização, entre outros. O modelo recebe os valores de impedância calcu-lados pelo Nó Lógico MMXU e verifica se a impedância “vista” está dentro do raio de proteçãoparametrizado. De acordo com o tempo de espera parametrizado, o modelo envia ao Nó Lógicoda proteção o comando de trip.
A função de proteção de sobrecorrente instantânea é representada pelo autômato da Figura4.37.c. O modelo observa se o valor do módulo da corrente elétrica calculada pelo Nó LógicoMMXU é superior ao valor parametrizado. Em caso positivo, um comando de trip é enviado aoNó Lógico da proteção.
122
(a)
(b) (c)
(d)
Figura 4.37: Modelagem IED: a) Nó Lógico da função de proteção, b) Algoritmo da função deproteção de distância, c) algoritmo da função de proteção de sobrecorrente instantânea e d)
Algoritmo da função de proteção de sobrecorrente temporizada.
123
Na Figura 4.37.d está apresentado o modelo da função de proteção de sobrecorrente tem-porizada. A curva de temporização adotada é baseada no modelo IEC 60255-151 (Equação4.3). De acordo com o módulo da corrente observada pelo modelo, determina-se a temporiza-ção mínima para envio do trip. Se o sistema permanecer em condição de falta por um temposuperior ao determinado pela curva, o comando de trip é enviado ao Nó Lógico da função deproteção.
T =β(
IIn
)α− 1· TMS (4.3)
onde T é o tempo de operação, β e α são constantes que determinam a característica da curvade temporização, I é a corrente observada pela função de proteção, In é a corrente de pickup eTMS é o multiplicador de tempo associado às relações de transformação dos transformadoresde corrente.
A parametrização adotada no estudo em questão é relativa ao modelo com característicade tempo inverso padrão, correspondente à α = 0.02 e β = 0.14.
A Figura 4.38 apresenta a sintaxe no UPPAAL STRATEGO para instanciar os modelos. Nafigura em questão, a função de proteção de sobrecorrente é parametrizada com corrente depickup em 2 unidades. Ainda na Figura 4.38, destaca-se a implementação das três zonas deproteção da função de proteção de distância. As zonas de proteção são implementadas pelomesmo modelo, no entanto, com parametrizações diferentes.
1 /∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗2 LN I n s t a n t i a t i o n s ( IED )3 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗ /4 PIOC_A = LN_P ( ct_LNAID ) ;5 OC50_A = OC50 ( ct_LNAID , ct_LNAID ) ;67 PTOC_B = LN_P ( ct_LNBID ) ;8 OC51_B = OC51 ( ct_LNBID , ct_LNBID ) ;9
10 PDIS_C = LN_P ( ct_LNCID ) ;11 PDIS1_C = P21 ( ct_LNCID , ct_Z1ID , 0 . 5 0 0 , 0 . 1 0 0 , 0 . 5 2 0 , 0 . 0 ) ;12 PDIS2_C = P21 ( ct_LNCID , ct_Z2ID , 0 . 6 0 5 , 0 . 1 3 0 , 0 . 6 3 3 , 1 . 0 ) ;13 PDIS3_C = P21 ( ct_LNCID , ct_Z3ID , 1 . 1 5 0 , 0 . 2 5 0 , 1 . 2 0 4 , 2 . 0 ) ;
Figura 4.38: Sintaxe de inicialização das funções de proteção.
Como não serão abordados os modelos referentes ao protocolo de transmissão de mensa-gens de valores amostrados pelo Nó Lógico MMXU, propôs-se um modelo que emula a geraçãodestas mensagens. O modelo proposto é apresentado na Figura 4.39. Os valores aleatórios sãodeterminados por uma função de distribuição uniforme com faixa entre 0.1 e 5.0 unidades. Ointervalo entre amostras considerado neste cenário é parametrizado em 0.3 unidades de tempo.
124
Figura 4.39: Modelo emissor de valores SV aleatórios baseados no Nó Lógico MMXU.
Um exemplo de simulação da operação da função de proteção de distância é apresentadona Figura 4.40. Da figura, observa-se os valores de resistência e reatância amostrados aleatori-amente e o comportamento das zonas de proteção.
0 5 10 15 20 25 30 35 40 45 50t
Zone1
Zone2
Zone3
012345
TimingTrip
TimingTrip
TimingTrip
XmRm
(a)
-1 -0.5 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5r
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
5
x
Zone1
Zone2
Zone3
Impedance
t0
LT1
LT2
LT3
(b)
Figura 4.40: Simulação envolvendo a função de proteção de distância.
A Figura 4.40.a apresenta as binárias das zonas de proteção. Destaca-se primeiramente
125
a identificação de que a impedância medida está dentro da zona de proteção e, transcorrido otempo parametrizado, gera-se um comando de trip nas zonas 2 e 3. A Figura 4.40.b apresentao diagrama de impedâncias para a simulação em questão, de onde justifica-se a atuação daproteção das zonas 2 e 3.
De maneira análoga apresenta-se uma simulação considerando o comportamento das fun-ções de proteção de sobrecorrente na Figura 4.41. Na simulação em questão, aplicou-se umaentrada de corrente em rampa. Com relação ao modelo PIOC, nota-se que ao passar do limiar decorrente parametrizado (2 unidades), o modelo gera um sinal de trip ao Nó Lógico no próximociclo de scan do IED.
Já no modelo PTOC, a partir do limiar, calcula-se o tempo de atuação da proteção. Nasimulação em questão, o máximo valor de temporização da função de proteção foi limitado a50 unidades de tempo. Como a corrente continua crescendo com o passar do tempo, o tempode espera calculado pela curva vai diminuindo de forma exponencial a cada ciclo de scan. Otrip da proteção é então gerado quando o tempo de falta atinge o tempo calculado na curva.
0 5 10 15 20 25 30 35 40 45 500
5
10
15
20
25
Trip50
Trip51
0
12.5
25
37.5
50
IsI_pickup
tcurveTiming
Figura 4.41: Simulação da função de proteção de sobrecorrente.
Assim como nos demais processos de desenvolvimento dos modelos, realizou-se a veri-ficação formal sobre as principais propriedades comportamentais do autômato em análise. ATabela 4.13 apresenta a descrição e resultados desta verificação. Salienta-se que no processo devalidação, os modelos foram validados individualmente, em três baterias de testes.
A propriedade P5.5.1 (Tabela 4.13) verifica o correto comportamento da função de prote-ção de distância. A geração de trip só deve ocorrer quando a impedância “vista” pelo IED estádentro da zona de proteção parametrizada e o tempo de permanência nesta zona seja maior doque o tempo limite, também parametrizado.
Da mesma forma, a propriedade P5.5.2 (Tabela 4.13) analisa o funcionamento das funçõesde proteção de sobrecorrente. Ambos resultados demonstram que os modelos estão coerentescom o funcionamento esperado, apenas dentro do âmbito de análise desta dissertação.
126
Tabela 4.13: Verificação das propriedades as funções de proteção do modelo IED.
Nome Descrição Informal Descrição Formal Resultado
P5.5.1
Verifica a probabilidade deatuação das zonas de proteçãoem relação à impedância me-dida e tempo transcorrido du-rante a falta.
Pr[<=100]([]PDIS_C.TRIP imply(PDIS1_C.d_Zrel<=PDIS1_C.Zmod &&PDIS1_C.c_tfault>=PDIS1_C.tfault))
100.00%
Pr[<=100]([]PDIS_C.TRIP imply(PDIS2_C.d_Zrel<=PDIS2_C.Zmod &&PDIS2_C.c_tfault>=PDIS2_C.tfault))
100.00%
Pr[<=100]([]PDIS_C.TRIP imply(PDIS3_C.d_Zrel<=PDIS3_C.Zmod &&PDIS3_C.c_tfault>=PDIS3_C.tfault))
100.00%
P5.5.2
Verifica a probabilidade deatuação correta das funçõesde sobrecorrente em relaçãoà corrente medida e tempotranscorrido durante a falta.
Pr[<=100]([]PIOC_A.TRIP implyOC50_A.d_Im >=OC50_A.d_Ipickup)
100.00%
Pr[<=100]([]PTOC_B.TRIP implyOC51_B.d_Im >=OC51_B.d_Ipickup &&OC51_B.c_tfault>=OC51_B.d_tcurve)
100.00%
Capítulo 5
Conclusão
Este capítulo apresenta uma síntese do conhecimento adquirido ao longo do desenvolvi-mento desta dissertação, discutindo as conclusões dos resultados atingidos, desafios e limitaçõesencontradas durante a pesquisa e sugestões para trabalhos futuros utilizando-se dos modelos de-senvolvidos no trabalho.
5.1 Conclusões Gerais
Os avanços tecnológicos nas mais diversas áreas do conhecimento, sobretudo na área daCiência da Computação, permitiram o desenvolvimento de técnicas de processamento e ge-renciamento de dados mais eficientes. No contexto dos Sistemas de Energia Elétrica, este de-senvolvimento circunda as inovações potenciais na comunicação entre dispositivos, nos quaiscaracterísticas como coordenação e cooperação se tornam essenciais para sua plena operação.As redes inteligentes (smart grids) são hoje uma realidade e estão alterando significativamentea concepção de projeto e operação dos sistemas elétricos.
Em específico na área de Sistemas de Proteção, este trabalho apresentou diversos estudosonde propõem-se o emprego de estratégias de proteção mais sofisticadas e, em teoria, com de-sempenho superior aos esquemas de proteção tradicionais. No entanto, quando implementadasem sistemas elétricos reais, estas estratégias geralmente operam na retaguarda do sistema deproteção tradicional.
Em resposta à necessidade de ferramentas mais sofisticadas na área de Sistemas de Prote-ção, este trabalho apresentou o emprego da técnica de Modelagem e Verificação Formal comoferramenta de suporte à proposição e validação das novas estratégias de proteção, permitindo ainvestigação das principais propriedades comportamentais do sistema em teste, principalmenteno sentido de verificar se o sistema de controle da estratégia proposta atende os requisitos ope-racionais, de segurança e comportamento determinístico temporal esperado.
127
128
Para isso, foram desenvolvidos os principais modelos de dispositivos e protocolos queatuam sobre os Sistemas de Proteção no âmbito do novo paradigma dos SEEs. Em geral, fo-ram desenvolvidos 31 modelos que podem subsidiar esta ferramenta de análise de Sistemasde Proteção, sendo 18 modelos referentes a equipamentos e protocolos, como barramentos decomunicação, protocolo de sincronização de tempo, protocolos de comunicação baseados nanorma IEC 61850 e funções de proteção e 13 modelos que auxiliaram no processo de Verifica-ção Formal.
Na Figura 5.1 os modelos desenvolvidos são apresentados segundo a estrutura hierárquicade um SAS baseado na IEC 61850. Salienta-se que o objetivo desta dissertação era apenas dedesenvolver e validar os modelos de forma individual e a integração entre os modelos propostospode requerer novas adequações.
Model: LAN_fix
Parameters: broadcast chan &Send, broadcast chan &Receive
S
FIFO
R
(c_tDelaymsg[i_First] <= ct_tDelayFix) &&
forall(i:int[0,ct_iLim-1])c_tDelaymsg[i]'==b_trun[i]
c_tDelaymsg[i_Last] = 0,
b_trun[i_Last] = true
b_flagoverflow = true
i_NElem++,
i_Last = (i_Last+1)%ct_iLim
c_tDelaymsg[i_First]=0,
b_trun[i_First]=0,
i_First=(i_First + 1)%ct_iLim,
i_NElem--
Send?
!Buffer_Overflow()!Buffer_Empty() &&
c_tDelaymsg[i_First]>=
ct_tDelayFix
Receive!
Buffer_Overflow()
Send?
Model: LAN_lnorm
Parameters: broadcast chan &Send, broadcast chan &Receive
S
FIFO
R
(c_tDelaymsg[i_First] <= d_tDelayVar[i_First]) &&
forall(i:int[0,ct_iLim-1])c_tDelaymsg[i]'==b_trun[i] &&
forall(j:int[0,ct_iLim-1])d_tDelayVar[j]'==0
b_flagoverflow = true
c_tDelaymsg[i_First]=0,
d_tDelayVar[i_First]=0,
b_trun[i_First]=0,
i_First=(i_First + 1)%ct_iLim,
i_NElem--
c_tDelaymsg[i_Last] = 0,
b_trun[i_Last] = true
d_tDelayVar[i_Last] = ct_tDelayFix +
30*rlnorm(mean,std),
i_NElem++,
sort(c_tDelaymsg, d_tDelayVar),
i_Last = (i_Last+1)%ct_iLim
Receive!
Buffer_Overflow()
!Buffer_Overflow()
Send?
!Buffer_Empty() &&
(c_tDelaymsg[i_First] >=
d_tDelayVar[i_First])
Send?
Model: LAN_unif
Parameters: broadcast chan &Send, broadcast chan &Receive
S
FIFO
R
(c_tDelaymsg[i_First] <= ct_tDelayFix+ct_delta) &&
forall(i:int[0,ct_iLim-1])c_tDelaymsg[i]'==b_trun[i]
b_flagoverflow = true
c_tDelaymsg[i_First]=0,
b_trun[i_First]=0,
i_First=(i_First + 1)%ct_iLim,
i_NElem--
c_tDelaymsg[i_Last] = 0,
b_trun[i_Last] = true
i_NElem++,
i_Last = (i_Last+1)%ct_iLim
Receive!
Buffer_Overflow()
!Buffer_Overflow()
Send?
!Buffer_Empty() &&
c_tDelaymsg[i_First] >=
(ct_tDelayFix-ct_delta)
Send?
Model: Master_task1
Parameters: broadcast chan &Send, broadcast chan &Receive, int iId
FUP
d_SyncWait=timeSync_calc(),
c_tsync=0.0IDLE
SYNC
c_tsync<=
(d_SyncTime/2)
c_tsync=0.0
mk_FollowUpPack(),
stBuff_LAN[i_Last] = stBuff_Master,
stBuff_LAN_TimeStamp[i_Last] = stBuff_Master_Time,
d_SyncWait=timeSync_calc()
i_Cont=
(i_Cont+1)%(ct_iContLim+1)
mk_SyncPack(),
stBuff_LAN[i_Last] = stBuff_Master,
stBuff_LAN_TimeStamp[i_Last] = stBuff_Master_Time
c_tsync<=d_SyncWait
c_tsync==(d_SyncTime/2)
c_tsync==d_SyncWait
Send!
Send!
Model: Master_task2
Parameters: broadcast chan &Send, broadcast chan &Receive, int iId
IDLE
A
DRESP
mk_DelayRespPack(),
stBuff_LAN[i_Last] = stBuff_Master,
stBuff_LAN_TimeStamp[i_Last] = stBuff_Master_Time
stBuff_Master=
stBuff_LAN[i_First]
stBuff_Master.i_msgType !=
ct_mtfDelay_Req
stBuff_Master.i_msgType ==
ct_mtfDelay_Req
Send!
Receive?
ch_LNTrip[iId][iZone]!
ch_LNCheck[iId]?
d_Im>=d_Ipickup
d_Im<d_Ipickup
TRIP
CHECK
WAIT
d_Im =
stBuff_SVLN_mod[iId]
ch_LNTrip[iId][iZone]!
ch_LNCheck[iId]?
c_tfault<
d_tcurve
c_tfault>=
d_tcurve
d_Im>d_Ipickup
d_Im<=d_Ipickup
c_tfault'==
b_flagFault
FAULT_COND
TRIP
CHECKWAIT
b_flagFault = true,
d_tcurve=CurveOC(d_Im)
b_flagFault =false,
d_tcurve=0.0,
c_tfault=0.0
d_Im =
stBuff_SVLN_mod[iId]
ch_LNTrip[iId][iZone]!
ch_LNCheck[iId]?
c_tfault<
tfault
c_tfault>=
tfault
d_Zrel>Zmod
d_Zrel<=Zmod
c_tfault'==
b_flagFault
TRIP
CHECK
WAIT
b_flagFault = false,
c_tfault=0.0,
b_flagTemp[iId][iZone]=false
b_flagFault = true,
b_flagTemp[iId][iZone]=true
d_Xm =
stBuff_SVLN_x[iId],
d_Rm =
stBuff_SVLN_r[iId],
d_Zrel = dist_calc()
ch_Sample!
c_ts>=ct_sample
c_ts<=ct_sample SH
d_sample[i_ADLast] = rushaped(-1.0, 1.0),
d_sample_tstamp[i_ADLast] = c_MU,
c_ts=0.0
ch_svEna[iId]?
Send!
Send!
ch_svEna[iId]?
b_SvEna[iId]==false b_SvEna[iId]==true
c_sv>=i_smpRate
c_sv<=i_smpRate
TRANSMIT
WAIT_SMP
N_EXIST
mk_SVPack(),
stBuff_SVLAN[i_Last]=stBuff_SVS,
stBuff_SVLAN_time[i_Last] = stBuff_SVS_time,
stBuff_SVLAN_mod[i_Last]=stBuff_SVS_mod,
stBuff_SVLAN_ang[i_Last]=stBuff_SVS_ang,
c_sv=0.0
c_sv=0.0,
i_auxsmpCnt = 0
mk_SVPack(),
stBuff_SVLAN[i_Last]=stBuff_SVS,
stBuff_SVLAN_time[i_Last] = stBuff_SVS_time,
stBuff_SVLAN_mod[i_Last]=stBuff_SVS_mod,
stBuff_SVLAN_ang[i_Last]=stBuff_SVS_ang,
c_sv=0.0ch_gseFail[iId]!
ch_gseRead[iId]!
Receive?
Receive?
ch_gseStop[iId]!
Receive?
b_PackLoss==true
stBuff_GR.i_SqNum!=
(i_SqRec%ct_iContLim)+1
stBuff_GR.i_SqNum==
(i_SqRec%ct_iContLim)+1stBuff_GR.i_SqNum!=0 &&
b_PackLoss==false
stBuff_GR.i_SqNum==0 &&
b_PackLoss==false
c_gse>=d_ttl*1.3
c_gse>=d_ttl
c_gse<d_ttl
stBuff_GR.b_GoEna==
truestBuff_GR.b_GoEna==
false
stBuff_GR.i_ID==
iRecId
stBuff_GR.i_ID!=
iRecId
c_gse<=d_ttl
c_gse<=d_ttl*1.3
VALID
REC
N_EXIST
QUESTIONABLE
A
i_SqRec=stBuff_GR.i_SqNum,
d_ttl =
pow(2,stBuff_GR.i_ttl),
b_PackLoss = false
b_PackLoss = true
stBuff_GR=stBuff_GOLAN[i_First]stBuff_GR=stBuff_GOLAN[i_First]
stBuff_GRaux=stBuff_GR,
stBuff_GRaux_TimeStamp=
stBuff_GR_time,
c_gse=0.0
b_PackLoss = false
stBuff_GR=
stBuff_GOLAN[i_First],
stBuff_GR_time=
stBuff_LAN_TimeStamp[i_First]
Model: Goose_Sender
Parameters: broadcast chan &Send, int iId
RETRANSMIT
RETRANSMIT_PEND
c_gse<=d_ttl
c_gse==d_ttl
b_GoEna[iId]==true
mk_gseInitPack(),
send_gsePack(),
d_ttl=pow(2,stBuff_GS.i_ttl),
c_gse=0.0,
mk_gseUpdatePack()
send_gsePack(),
d_ttl=pow(2,stBuff_GS.i_ttl),
c_gse=0.0,
mk_gseUpdatePack()
N_EXIST
mk_gseFinishPack(),
send_gsePack(),
i_auxStnum = 0
A
ch_LNWriteGo[iId]?
b_GoEna[iId]==false
Send!
ch_GoEna[iId]?
ch_GoEna[iId]?
Send!Send!
ch_svRead[iId]!
ch_svFail[iId]!
ch_svStart[iId]!
Receive?
Receive?
ch_svStop[iId]!
Receive?
b_PackLoss==true &&
b_FirstPack==false
(stBuff_SVR.i_smpCnt!=
((i_smpCntold%ct_iContLim)+1)) ||
b_FirstPack==true
(stBuff_SVR.i_smpCnt==
((i_smpCntold%ct_iContLim)+1))&&
b_FirstPack==false
stBuff_SVR.i_smpCnt!=0
&& b_PackLoss==false
(stBuff_SVR.i_smpCnt==0 &&
b_PackLoss==false) &&
b_FirstPack==true
c_sv==i_smpRate*1.3
c_sv>=
i_smpRate
c_sv<=
i_smpRate
stBuff_SVR.b_SvEna==true
stBuff_SVR.b_SvEna
==false
stBuff_SVR.i_ID==
iRecId
stBuff_SVR.i_ID!=
iRecId
c_sv<=i_smpRate
c_sv<=i_smpRate*1.3
VALID
REC
N_EXIST
QUESTIONABLE
A
i_smpCntold=stBuff_SVR.i_smpCnt,
i_smpRate=stBuff_SVR.i_smpRate,
b_PackLoss = false,
b_FirstPack = false
b_FirstPack = false
b_PackLoss = true
stBuff_SVR=stBuff_SVLAN[i_First]stBuff_SVR=stBuff_SVLAN[i_First]
c_sv=0.0
b_PackLoss = false,
b_FirstPack = true
stBuff_SVR=
stBuff_SVLAN[i_First]
c_nstable?
c_stable?
stp!
taux>=3.0
taux<3.0
taux>tff
taux==tff
taux<tff
ts>=dt
forall(i:int[0,Ng-1])delta_til[i]'==w_til[i] &&
forall(k:int[0,Ng-1])w_til[k]'==(1/(data_Gen[k][gen_M]))*(Pm[k]-Pele[k]) - PCOA/MT&&
ts<=dt
FINALUNSTABLE
Atcrit=2.0
b_stable=stb_det(),
Run_Fault(99)
rmv_line(0)
b_stable=stb_det(),
Run_Fault(Bus_Falt)
ts=0,
taux=t
Z_mount(),
Y_mount(),
Load_Flow(),
include_Gen2Ybus(),
include_Zload(),
YLPQ_form(),
gen_Init(),
t = 0.0,
ts = 0.0,
tff = 0.194,
dt=0.005,
Run_Fault(Bus_Falt)
Bay Level IED
Proccess Bus
IEC 61850
IEC 61850
Merging Unit
Proccess Level
Receive?
Send!
obs_fup[iId-1]!
Receive?
obs_sync[iId-1]!
Receive?
(stBuff_Slave.i_msgType ==
ct_mtfDelay_Resp) &&
(i_ContReq ==
stBuff_Slave.i_sequenceID)
(stBuff_Slave.i_msgType !=
ct_mtfDelay_Resp) ||
(i_ContReq !=
stBuff_Slave.i_sequenceID)
c_tdreq==d_DelayReqTime
(stBuff_Slave.i_msgType ==
ct_mtfFollow_Up) &&
(i_ContReq ==
stBuff_Slave.i_sequenceID)
(stBuff_Slave.i_msgType !=
ct_mtfFollow_Up) ||
(i_ContReq !=
stBuff_Slave.i_sequenceID)
c_tdreq==
(2*d_SyncTime)
stBuff_Slave.i_msgType ==
ct_mtfSync
stBuff_Slave.i_msgType !=
ct_mtfSync
c_tdreq<=
d_DelayReqTime
c_tdreq<=
(d_DelayReqTime)
ADJ_TIME
C
WAIT_DRESP
BWAIT_FUPA
IDLE
DREQ
offset = ((t2-t1)+(t3-t4))/2,
hc_Ts[iId-1] = hc_Ts[iId-1] - offset
t4=stBuff_Slave_Time
stBuff_Slave=
stBuff_LAN[i_First],
stBuff_Slave_Time=
stBuff_LAN_TimeStamp[i_First]
mk_DelayReqPack(),
stBuff_LAN[i_Last]=
stBuff_Slave,
t3 = hc_Ts[iId-1]
t1 = stBuff_Slave_Time,
c_tdreq = 0
stBuff_Slave=
stBuff_LAN[i_First],
stBuff_Slave_Time=
stBuff_LAN_TimeStamp[i_First]
c_tdreq = 0.0,
i_ContReq = stBuff_Slave.i_sequenceID,
t2 = hc_Ts[iId-1]
stBuff_Slave=
stBuff_LAN[i_First]
PTP
MODELOS VERIFICADOS: 18
MODELOS AUXILIARES: 13
Figura 5.1: Modelos desenvolvidos neste trabalho.
129
Como formalismo de apoio, adotou-se os Autômatos Temporizados Híbridos, os quaispermitem a abstração de realidades tanto de característica discreta quanto contínua. Como fer-ramenta de validação adotou-se a técnica de Verificação Formal Estatística, através do aplicativoUPPAAL STRATEGO.
O desenvolvimento dos modelos se deu através de uma abordagem sistemática envol-vendo processos de simulação e verificação das propriedades sob o modelo em análise. Oprocesso foi repetido até que os requisitos comportamentais do modelo sejam completamenteatendidos. Em cada etapa em que o comportamento do modelo não atendeu as especificações,via simulação ou Verificação Formal, uma nova modelagem foi realizada de forma a corrigir oproblema em questão.
Os resultados obtidos ao final do procedimento de validação para cada modelo foramcomparados com requisitos operacionais definidos por normas, testes de conformidade em equi-pamentos/protocolos e por trabalhos técnico/científicos vinculados à área em questão.
Para subsidiar o processo de validação dos modelos, foram implementadas funções quegeram números aleatórios baseados nas principais distribuições de probabilidade adotadas emestudos de confiabilidade de sistemas. Estas funções foram empregadas em modelos auxiliaresque emulam um comportamento aleatório que interagem com o modelo em análise.
Os resultados obtidos indicam que a metodologia adotada garantiu o desenvolvimento demodelos que representam o comportamento esperado dos principais dispositivos de um sistemade proteção. Desta forma, conclui-se que o trabalho atingiu as metas propostas e se apresentacomo uma linha de pesquisa em potencial para trabalhos futuros.
5.2 Sugestões de Pesquisas Futuras
Da etapa de revisão bibliográfica realizada, identificou-se três linhas de pesquisa ondeos modelos desenvolvidos possam ser integrados em uma metodologia de desenvolvimento emSistemas de Proteção: i) na etapa que antecede a implementação do controle da nova estratégiade proteção proposta, onde os modelos que representam o sistema do controle são traduzidosem uma linguagem de programação apropriada para implementação; ii) na etapa de testes dedesempenho da estratégia proposta, onde a verificação das propriedades do modelo (controle +dispositivos) representam o funcionamento global da estratégia; e iii) em testes de conformidadeem equipamentos, onde um modelo da rede de autômatos é substituído por um equipamentofísico real, com finalidade de avaliar o seu comportamento juntamente com a rede de autômatos.
Para as três linhas de pesquisas supracitadas, é essencial a validação da rede de autômatosformada pela integração dos modelos individuais apresentados, sendo esta atividade, a primeiraetapa vista identificada como trabalhos futuros.
130
No contexto do Laboratório de Automação e Simulação de Sistemas Elétricos (Lasse),as linhas de pesquisa ii) e iii) se apresentam como linhas estratégicas. Com relação à linha ii),o estudo da verificação das propriedades sobre o sistema de proteção em análise pode reduziro número de cases de simulação realizados na plataforma RTDS (simulador digital em temporeal), fornecendo um menor conjunto de simulações mais consistentes. No entanto, para rea-lização desta metodologia faz-se necessária a integração entre os modelos desenvolvidos nestadissertação.
Já com relação à iii), rotinas para o desenvolvimento automático de testes de confor-midade podem ser implementadas em equipamentos eletrônicos desenvolvidos pelo Lasse ouno próprio RTDS. A simulação e a Verificação Formal dos modelos resultam em garantias deque o sistema está de acordo com os requisitos solicitados. Porém, os modelos não são apli-cáveis diretamente ao sistema físico e para isso faz-se necessária a tradução dos modelos emuma linguagem de programação que permita o interfaceamento com os dispositivos a seremcontrolados. Após esta tradução, novos testes envolvendo a validação dos modelos devem serrealizados, de forma a identificar eventuais erros no processo de implementação dos modelosem uma linguagem de programação.
Além das linhas de pesquisa supracitadas, a implementação do modelo dinâmico dossistemas elétricos pode ser adotada em estudos envolvendo a determinação da região de esta-bilidade e limites de tempo de abertura críticos do sistema de proteção através da formulaçãocorreta das propriedades a serem verificadas pelo UPPAAL STRATEGO.
Referências Bibliográficas
Alur, R. & Dill, D. L. (1994). A Theory of Timed Automata, Theor. Comput. Sci. 126(2): 183–235.
Baier, C. & Katoen, J.-P. (2008). Principles of Model Checking (Representation and MindSeries), The MIT Press.
Blom, J., Hessel, A., Jonsson, B. & Pettersson, P. (2005). Specifying and Generating Test CasesUsing Observer Automata, Springer Berlin Heidelberg, Berlin, Heidelberg, pp. 125–139.
Bordbar, B., Anane, R. & Okano, K. (2005). An Evaluation Mechanism for QoS Managementin Wireless Systems, 11th International Conference on Parallel and Distributed Systems(ICPADS’05), Vol. 2, pp. 150–154.
Bordbar, B. & Okano, K. (2003). Verification of Timeliness QoS Properties in MultimediaSystems, Springer Berlin Heidelberg, Berlin, Heidelberg, pp. 523–540.
Campos, J. C. & Machado, J. (2009). Pattern-Based Analysis of Automated Production Sys-tems, IFAC Proceedings Volumes 42(4): 972 – 977. 13th IFAC Symposium on InformationControl Problems in Manufacturing.
Cassandras, C. G. & Lafortune, S. (2010). Introduction to Discrete Event Systems, 2nd edn,Springer Publishing Company, Incorporated.
Catterson, V., Davidson, E. & McArthur, S. (2011). Practical Applications of Multi-AgentSystems in Electric Power Systems, European Transactions on Electrical Power 22: 235–252.
Cecilia, A. A. & Sudarsanan, K. (2016). A Survey in Smart Grid, 2016 International Conferenceon Emerging Trends in Engineering, Technology and Science (ICETETS), pp. 1–7.
Chen, J.-H., Chen, S.-H. & Yang, Y.-M. (2004). Study on Multi-Agent Based Bus ProtectionRelay System, Machine Learning and Cybernetics, 2004. Proceedings of 2004 Internati-onal Conference on, Vol. 1, pp. 101–104 vol.1.
Chen, J.-H., Chen, S.-H. & Yang, Y.-M. (2005). Study on Adaptive Protection Relay SystemBased on Multi-Agetn, Machine Learning and Cybernetics, 2005. Proceedings of 2005International Conference on, Vol. 1, pp. 114–118.
Cimatti, A., Mover, S. & Tonetta, S. (2013). SMT-Based Scenario Verification for HybridSystems, Formal Methods in System Design 42(1): 46–66.
Coury, D., Thorp, J., Hopkinson, K. & Birman, K. (2002). An Agent-Based Current DifferentialRelay for use with a Utility Intranet, Power Delivery, IEEE Transactions on 17(1): 47–53.
131
132
Dai, Z., Wang, Z. & Jiao, Y. (2014). Bayes Monte-Carlo Assessment Method of ProtectionSystems Reliability Based on Small Failure Sample Data, IEEE Transactions on PowerDelivery 29(4): 1841–1848.
David, A., Jensen, P. G., Larsen, K. G., Mikucionis, M. & Taankvist, J. H. (2015). UppaalStratego, in C. Baier & C. Tinelli (eds), Tools and Algorithms for the Construction andAnalysis of Systems, Vol. 9035 of Lecture Notes in Computer Science, Springer BerlinHeidelberg, pp. 206–211.
Davidson, E., McArthur, S. & McDonald, J. (2003). A Toolset for Applying Model-BasedReasoning Techniques to Diagnostics for Power Systems Protection, Power Systems, IEEETransactions on 18(2): 680–687.
Emerson, E. & Clarke, E. M. (1982). Using Branching Time Temporal Logic to SynthesizeSynchronization Skeletons, Science of Computer Programming 2(3): 241 – 266.
Ferreira, N. F. G. (2012). Verificação Formal de Sistemas Modelados em Estados Finitos.
Giovanini, R., Hopkinson, K., Coury, D. & Thorp, J. (2006). A Primary and Backup Coopera-tive Protection System Based on Wide Area Agents, Power Delivery, IEEE Transactionson 21(3): 1222–1230.
Guerrero, C. A. V. (2011). Uso do RTDS em Testes de Esquemas de Teleproteção Aplicando oPadrão IEC 61850.
Henzinger, T. A., Ho, P.-H. & Wong-Toi, H. (1997). HyTech: A model Checker for HybridSystems, Springer Berlin Heidelberg, Berlin, Heidelberg, pp. 460–463.
Hérault, T., Lassaigne, R., Magniette, F. & Peyronnet, S. (2004). Approximate ProbabilisticModel Checking, Springer Berlin Heidelberg, Berlin, Heidelberg, pp. 73–84.
Hessel, A. & Pettersson, P. (2007). Model-Based Testing of a WAP Gateway: An IndustrialCase-Study, Springer Berlin Heidelberg, pp. 116–131.
Hossack, J., Burt, G. M., McDonald, J., Cumming, T. & Stokoe, J. (2001). Progressive PowerSystem Data Interpretation and Information Dissemination, Transmission and DistributionConference and Exposition, 2001 IEEE/PES, Vol. 2, pp. 907–912 vol.2.
Hossack, J., McArthur, S., McDonald, J., Stokoe, J. & Cumming, T. (2002). A Multi-Agent Ap-proach to Power System Disturbance Diagnosis, Power System Management and Control,2002. Fifth International Conference on (Conf. Publ. No. 488), pp. 317–322.
IEEE (2001). IEEE Recommended Practice for Protection and Coordination of Industrial andCommercial Power Systems (IEEE Buff Book), IEEE Std 242-2001 (Revision of IEEE Std242-1986) pp. 1–710.
Igarashi, G. (2011). Contribuições para a Implementação de um Barramento de Processo se-gundo a Norma IEC 61850-9.
Ingram, D. M. E., Schaub, P. & Campbell, D. A. (2012). Use of Precision Time Protocol toSynchronize Sampled-Value Process Buses, IEEE Transactions on Instrumentation andMeasurement 61(5): 1173–1180.
133
Isa, N. B. M., Wei, T. C. & Yatim, A. H. M. (2015). Smart Grid Technology: Communications,Power Electronics and Control System, Sustainable Energy Engineering and Application(ICSEEA), 2015 International Conference on, pp. 10–14.
John E. Hopcroft, Rajeev Motwani, J. D. U. (2001). Introduction to Automata Theory, Langua-ges, and Computation, 2nd ed edn, Addison-Wesley.
John Grainger, J. & Stevenson, W. (1994). Power System Analysis, 1 edn, McGraw-Hill.
Kauhaniemi, K. & Kumpulainen, L. (2004). Impact of Distributed Generation on the Protectionof Distribution Networks, Developments in Power System Protection, 2004. Eighth IEEInternational Conference on, Vol. 1, pp. 315–318 Vol.1.
Khurram, A., Ali, H., Tariq, A. & Hasan, O. (2013). Formal Reliability Analysis of ProtectiveRelays in Power Distribution Systems, Springer Berlin Heidelberg, Berlin, Heidelberg,pp. 169–183.
Kojovic, L. (2002). Impact DG on Voltage Regulation, Power Engineering Society SummerMeeting, 2002 IEEE, Vol. 1, pp. 97–102 vol.1.
Kunz, G. O. (2012). Metodologia para Desenvolvimento de Sistema de Controle de APM(Automated People Movers) com Aplicação ao Sistema Aeromovel de Transporte de Pas-sageiros.
Kwiatkowska, M., Norman, G. & Parker, D. (2011). PRISM 4.0: Verification of Probabilis-tic Real-time Systems, in G. Gopalakrishnan & S. Qadeer (eds), Proc. 23rd Internatio-nal Conference on Computer Aided Verification (CAV’11), Vol. 6806 of LNCS, Springer,pp. 585–591.
Laaksonen, H. & Suomi, F. (2013). New Functionalities and Features of IEDs to Realize Ac-tive Control and Protection of Smart Grids, Electricity Distribution (CIRED 2013), 22ndInternational Conference and Exhibition on, pp. 1–4.
Li, H., Rosenwald, G., Jung, J. & Liu, C.-C. (2005). Strategic Power Infrastructure Defense,Proceedings of the IEEE 93(5): 918–933.
Li, Y. P., Volut, S. & He, C. (2012). Standardization of Relays and Protection in Smart Grid,2012 IEEE International Conference on Power System Technology (POWERCON), pp. 1–5.
Liu, Z., Chen, Z., Sun, H. & Liu, C. (2012). Control and Protection Cooperation Strategyfor Voltage Instability, Universities Power Engineering Conference (UPEC), 2012 47thInternational, pp. 1–6.
Machado, P. H. F. (2015). Metodologia de Modelagem CPN Aplicada a Análise de Desempenhode Sistemas de Comunicação baseados na Norma IEC 61850.
Mahmood, A., Hasan, O., Gillani, H. R., Saleem, Y. & Hasan, S. R. (2016). Formal Relia-bility Analysis of Protective Systems in Smart Grids, 2016 IEEE Region 10 Symposium(TENSYMP), pp. 198–202.
134
McArthur, S. D. J., Davidson, E. M., Catterson, V. M., Dimeas, A. L., Hatziargyriou, N. D.,Ponci, F. & Funabashi, T. (2007a). Multi-Agent Systems for Power Engineering Applica-tions Part II: Technologies, Standards, and Tools for Building Multi-agent Systems, IEEETransactions on Power Systems 22(4): 1753–1759.
McArthur, S. & Davidson, E. (2004). Multi-Agent Systems for Diagnostic and Condition Moni-toring Applications, Power Engineering Society General Meeting, 2004. IEEE, pp. 50–54Vol.1.
McArthur, S., Davidson, E., Catterson, V., Dimeas, A., Hatziargyriou, N., Ponci, F. & Fu-nabashi, T. (2007b). Multi-Agent Systems for Power Engineering Applications Part I:Concepts, Approaches, and Technical Challenges, Power Systems, IEEE Transactions on22(4): 1743–1752.
McArthur, S., Davidson, E., Hossack, J. & McDonald, J. (2004). Automating Power SystemFault Diagnosis Through Multi-Agent System Technology, System Sciences, 2004. Proce-edings of the 37th Annual Hawaii International Conference on, pp. 8 pp.–.
Owonipa, A., Dolan, M., Davidson, E., Catterson, V., Ault, G. & McArthur, S. (2011).The Need for an Agent Arbitration Approach for Coordinated Control in Active PowerNetworks, Universities’ Power Engineering Conference (UPEC), Proceedings of 201146th International, pp. 1–5.
Pang, Q., Gao, H. & Minjiang, X. (2010). Multi-Agent Based Fault Location Algorithm forSmart Distribution Grid, Developments in Power System Protection (DPSP 2010). Mana-ging the Change, 10th IET International Conference on, pp. 1–5.
Park, S. & Lim, J.-T. (2006). Modelling and Control of Agent-Based Power Protection SystemsUsing Supervisors, Control Theory and Applications, IEE Proceedings - 153(1): 92–98.
Ravn, A. P., Srba, J. & Vighio, S. (2011). Modelling and Verification of Web Services BusinessActivity Protocol, Springer Berlin Heidelberg, pp. 357–371.
Rinast, J. (2012). Enhancing UPPAAL’s Explanatory Power using Static Zeno Run Analysis.
Rivera, S., Farid, A. M. & Youcef-Toumi, K. (2014). A Multi-Agent System Transient StabilityPlatform for Resilient Self-Healing Operation of Multiple Microgrids, ISGT 2014, pp. 1–5.
Rondon, M. E. S. (2012). Verificação Formal de Aplicações Concorrentes em Sistemas Elétricosde Potência.
Russell, S. & Norvig, P. (2010). Artificial Intelligence: A Modern Approach, Prentice HallSeries in Artificial Intelligence, 3rd edn, Prentice Hall.
Schutz, D. C. (2012). Comparação entre Algoritmos Geradores das Distribuições Normal, Qui-Quadrado, F de Snedecor e t de Student Através de Simulação.
Sengupta, A., Mukhopadhyay, S. & Sinha, A. K. (2015a). Automated Verification of Power Sys-tem Protection Schemes - Part I: Modelling and Specifications, 2015 IEEE Power EnergySociety General Meeting, pp. 1–1.
135
Sengupta, A., Mukhopadhyay, S. & Sinha, A. K. (2015b). Automated Verification of PowerSystem Protection Schemes - Part II: Test Case Generation Using Swarm Intelligence,2015 IEEE Power Energy Society General Meeting, pp. 1–1.
Shaohua, C., Yaoquan, Y., Yuxin, L. & Jiehong, Y. (2005). Application of Multi-agent Techno-logy in Relaying for Transmission Line, Transmission and Distribution Conference andExhibition: Asia and Pacific, 2005 IEEE/PES, pp. 1–4.
Shaoqun, S., Yongli, Z., Min, H. & Hong, Y. (2005). Multiagent and WAN Based Adaptive Co-ordinated Protection System, Transmission and Distribution Conference and Exhibition:Asia and Pacific, 2005 IEEE/PES, pp. 1–6.
Sheng, S., Li, K., Chan, W., Xiangjun, Z. & Xianzhong, D. (2006). Agent-Based Self-HealingProtection System, Power Delivery, IEEE Transactions on 21(2): 610–618.
Sheng, S., Li, K., Chan, W., Zeng, X., Shi, D. & Duan, X. (2010). Adaptive Agent-Based Wide-Area Current Differential Protection System, Industry Applications, IEEE Transactions on46(5): 2111–2117.
Shono, T., Sekiguchi, K., Tanaka, T. & Katayarna, S. (2002). A Remote Supervisory Systemfor a Power System Protection and Control Unit Applying Mobile Agent Technology,Transmission and Distribution Conference and Exhibition 2002: Asia Pacific. IEEE/PES,Vol. 1, pp. 148–153 vol.1.
Siqueira, R. A. (2014). Metodologia para Modelagem e Análise de Sistemas para Controle deGeração de Energia Elétrica.
Skendzic, V. & Zweigle, G. (2007). The 61850-9-2 Process Bus and Its Impact on Power Sys-tem Protection and Control Reliability, 9th Annual Western Power Delivery AutomationConference .
Strachan, S., McArthur, S., Stephen, B., Mcdonald, J. R. & Campbell, A. (2007). Provi-ding Decision Support for the Condition-Based Maintenance of Circuit Breakers ThroughData Mining of Trip Coil Current Signatures, Power Delivery, IEEE Transactions on22(1): 178–186.
Susuki, Y., Koo, T. J., Ebina, H., Yamazaki, T., Ochi, T., Uemura, T. & Hikihara, T. (2012).A Hybrid System Approach to the Analysis and Design of Power Grid Dynamic Perfor-mance, Proceedings of the IEEE 100(1): 225–239.
Thorp, D. V. C. R. G. J. S. (2008). Sistemas Multi-Agentes Aplicados a Proteção Adaptativa deLinhas de transmissão com Três Terminais, Sba Controle & Automação 19(1): 63–71.
Tomita, Y., Fukui, C., Kudo, H., Koda, J. & Yabe, K. (1998). A Cooperative Protection Systemwith an Agent Model, Power Delivery, IEEE Transactions on 13(4): 1060–1066.
Villani, E. (2004). Modelagem e Análise de Sistemas Supervisórios Híbridos.
Wan, H., Li, K. & Wong, K. (2010). An Adaptive Multiagent Approach to Protection Relay Co-ordination With Distributed Generators in Industrial Power Distribution System, IndustryApplications, IEEE Transactions on 46(5): 2118–2124.
Wang, F. (2006). Symbolic Implementation of Model-Checking Probabilistic Timed Automata.
136
Wong, S. & Kalam, A. (1995). Development of a Power Protection System Using an Agent Ba-sed Architecture, Energy Management and Power Delivery, 1995. Proceedings of EMPD’95., 1995 International Conference on, Vol. 1, pp. 433–438 vol.1.
Wong, S. & Kalam, A. (1997). An Agent Approach to Designing Protection Systems, Deve-lopments in Power System Protection, Sixth International Conference on (Conf. Publ. No.434), pp. 373–376.
Wooldridge, M. (2009). An Introduction to MultiAgent Systems, 2nd Edition, Vol. 30.
Xiangjun, Z., Li, K., Chan, W. & Sheng, S. (2004). Multi-Agents Based Protection for Dis-tributed Generation Systems, Electric Utility Deregulation, Restructuring and Power Te-chnologies, 2004. (DRPT 2004). Proceedings of the 2004 IEEE International Conferenceon, Vol. 1, pp. 393–397 Vol.1.
Yang, Z., Lu, Z., Ma, C., Wu, Q. & Fitch, J. (2006). Improving Control Ability of RelayProtection System with Intelligent Agents, Power System Technology, 2006. PowerCon2006. International Conference on, pp. 1–6.
Yanxia, C., Xianggen, Y., Zhe, Z., Deshu, C. & Xiangjun, Z. (2002). Research on Protec-tive Relaying Systems Based on Multi-Agent System, Power System Technology, 2002.Proceedings. PowerCon 2002. International Conference on, Vol. 2, pp. 661–665 vol.2.
Apêndice A
Programa de Conversão de Dados doUPPAAL para o Matlab
Para facilitar o processo de análise de desempenho dos modelos propostos no aplicativoUPPAAL STRATEGO foi desenvolvido um programa que automatiza a conversão dos arquivos desimulação (.txt) do UPPAAL para o ambiente Matlab. O programa foi elaborado sobre o ToolBox“GUIDE” do Matlab.
Na Figura A.1 é apresentada a interface visual do programa Uppaal2Matlab. A interfaceé composta por três botões, a saber: botão “Open”, responsável pela localização do arquivo detexto com as variáveis de saída do Uppaal, botão “Convert”, que exporta as variáveis do Uppaalpara o Workspace do Matlab e o botão “Plot Composer”, que abre uma nova janela com opçõespara fazer o gráfico das variáveis desejadas.
Figura A.1: Interface do programa Uppaal2Matlab
Ao clicar em “Open”, uma nova janela é aberta com o Windows Explorer para seleçãodo aquivo de texto contendo as variáveis do Uppaal. Na Figura A.2 é apresentada a janela debusca.
137
138
Figura A.2: Interface de localização do arquivo Uppaal
Após a seleção do arquivo .txt, o botão “Convert” exporta para o Workspace do Matlabas variáveis do arquivo selecionado. A variável é exportada em format “Struct” com o nomeindicado no campo “Output Varname”. Um exemplo é ilustrado na Figura A.3. Nota-se que avariável exportada é subdividida em oito estruturas, de acordo com as variáveis exportadas nasimulação do Uppaal.
Figura A.3: Exportação das variáveis do Uppaal
Além desta funcionalidade, é possível gerar um arquivo de gráfico contendo apenas as va-riáveis de interesse. As Figuras A.4 e A.5 apresentam respectivamente a janela de configuraçãodas variáveis e o gráfico de saída para o arquivo selecionado.
139
Figura A.4: Gerando gráficos com o Uppaal2Matlab
0 100 200 300 400 500 600 700 800 900 10000
0.5
1
1.5
2
2.5
3
3.5
4
4.5
LAN_fix_SLAN_fix_RiN_Elem
Figura A.5: Simulação contendo as variáveis selecionadas