UNIVERSIDADE FEDERAL DE SANTA CATARINA CAMPUS FLORIANÓPOLIS PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA DE AUTOMAÇÃO E SISTEMAS

Roger Daniel Francisco Ferreira

APLICAÇÕES DE PROTEÇÃO, AUTOMAÇÃO E CONTROLE EM TEMPO REAL CONFORME A IEC 61850 EM AMBIENTE VIRTUALIZADO

Florianópolis 2019

Roger Daniel Francisco Ferreira

APLICAÇÕES DE PROTEÇÃO, AUTOMAÇÃO E CONTROLE EM TEMPO REAL CONFORME A IEC 61850 EM AMBIENTE VIRTUALIZADO

Tese submetida ao Programa de Pós-Graduação em Engenharia de Automação e Sistemas da Universidade Federal de Santa Catarina para a obtenção do título de Doutor em Engenharia de Automação e Sistemas. Orientador: Prof. Dr. Rômulo Silva de Oliveira

Florianópolis 2019

Ficha de identificação da obra

Ferreira, Roger Daniel Francisco Aplicações de Proteção, Automação e Controle em Tempo Real conforme a IEC 61850 em Ambiente Virtualizado / Roger Daniel Francisco Ferreira ; orientador, Rômulo Silva de Oliveira, 2019. 253 p.

Tese (doutorado) - Universidade Federal de Santa Catarina, Centro Tecnológico, Programa de Pós-Graduação em Engenharia de Automação e Sistemas, Florianópolis, 2019.

Inclui referências.

1. Engenharia de Automação e Sistemas. 2. DDS. 3. OpenDDS. 4. PAC. 5. Virtualização. I. Oliveira, Rômulo Silva de. II. Universidade Federal de Santa Catarina. Programa de Pós- Graduação em Engenharia de Automação e Sistemas. III. Título.

Roger Daniel Francisco Ferreira

APLICAÇÕES DE PROTEÇÃO, AUTOMAÇÃO E CONTROLE EM TEMPO REAL CONFORME A IEC 61850 EM AMBIENTE VIRTUALIZADO

O presente trabalho em nível de doutorado foi avaliado e aprovado por banca examinadora composta pelos seguintes membros:

Prof. Dr. Marcelo Ricardo Stemmer Universidade Federal de Santa Catarina (UFSC)

Prof. Dr. Marcos Fonseca Mendes Universidade Estadual do Oeste do Paraná (Unioeste)

Prof. Dr. Mário Antônio Ribeiro Dantas Universidade Federal de Juiz de Fora (UFJF)

Certificamos que esta é a versão original e final do trabalho de conclusão que foi julgado adequado para obtenção do título de doutor em Engenharia de Automação e Sistemas.

______Prof. Dr. Werner Kraus Junior Coordenador do Programa de Pós-Graduação em Engenharia de Automação e Sistemas

______Prof. Dr. Rômulo Silva de Oliveira Orientador

Florianópolis, 29 de Agosto de 2019.

Este trabalho é dedicado à minha família e à ITAIPU.

AGRADECIMENTOS

Primeiramente à Deus, pelo dom da vida. Aos meus pais pela minha educação e formação. À minha esposa pelo apoio e paciência. Ao meu orientador Prof. Rômulo Silva de Oliveira, pela objetividade, imparcialidade, rigor e dedicação com que conduziu todo o processo de orientação, indicando o caminho correto a seguir e motivando-me nesse longo percurso para que o trabalho pudesse evoluir e concluir satisfatoriamente. À ITAIPU pelo apoio e patrocínio, e em especial ao Eng. Jorge Habib que viabilizou essa oportunidade. Aos colegas de trabalho da ENES.DT, pelo incentivo. Ao LASSE pelo apoio na implementação dos experimentos. À secretaria do PPGEAS, na figura do Sr. Ênio Snoeijer, sempre muito solícito para atender as demandas. A todos que direta ou indiretamente ajudaram e influenciaram neste trabalho.

“Todas as vitórias ocultam uma abdicação” (Simone de Beauvoir)

RESUMO

Tecnologias de virtualização e middlewares de comunicação trazem uma nova perspectiva e um novo paradigma que podem ser aproveitados na implementação de sistemas industriais de uma maneira geral. O objetivo deste trabalho de doutorado é avaliar a viabilidade de implementar aplicações de Proteção, Automação e Controle (PAC) no caso de Sistemas Elétricos de Potência (SEP), conforme a norma IEC 61850, em ambiente virtualizado. Tal avaliação requer a proposta de uma arquitetura em camadas e implementação de uma aplicação PAC IEC 61850 em um ambiente virtualizado. Foi utilizado o middleware de comunicação DDS e o estudo de caso de uma aplicação IEC 61850 típica. A primeira etapa do trabalho avalia a comunicação fim-a-fim a partir da camada do middleware de comunicação DDS, executando-se as aplicações de benchmark dos testes de desempenho da implementação OpenDDS. O ambiente de experimentação distribuído e virtualizado usado considera dois hosts físicos comuns conectados por uma rede simples. A camada de virtualização é realizada com KVM como hosted hypervisor com Linux Ubuntu e TinyCore como Guest-OS. Nessa avaliação inicial do middleware DDS, é definido um conjunto de cenários de teste combinando comunicações host-host, host-VM e VM-VM. Cada teste mede o tempo de round-trip de cada mensagem, derivando-se a respectiva latência e jitter. A segunda etapa do trabalho avalia a comunicação fim-a-fim da aplicação IEC 61850 do estudo de caso. A aplicação final, composta por 6 módulos, foi desenvolvida seguindo um método claro e objetivo. Os dois cenários de teste usados definem testes local e distribuído. No cenário local, todos os 6 módulos executam em um único host. No cenário distribuído, o sistema é particionado em 2 hosts e 4 VMs. Cada cenário de teste realiza um conjunto de 15 casos de teste definidos em 3 scripts. Os resultados obtidos são apresentados em formato tabular e gráfico. Os resultados preliminares do teste do DDS mostram que aplicação de tempo real leve com deadlines de até 1 ms poderiam executar no ambiente virtualizado proposto. O trabalho mostra o potencial de executar aplicações de automação em um ambiente virtualizado e distribuído. Os resultados do estudo de caso, por outro lado, mostram a limitação da infraestrutura convencional utilizada. As latências máximas chegam a 20 ms e até 30 ms em alguns casos. A contribuição dessa tese é fornecer informações, baseadas na arquitetura de referência proposta e respectiva caracterização temporal, para engenheiros responsáveis pelo design de soluções de automação e pesquisadores. Dessa forma, eles podem começar a considerar e avaliar o uso de arquiteturas e tecnologias modernas de computação, particularmente de virtualização e middleware de comunicação, em novos projetos de Engenharia ou estudos de caso e investigações científicas mais específicas.

Palavras-chave: Virtualização. Sistema Distribuído. DDS. OpenDDS. Norma IEC 61850. PAC. SDPAC.

ABSTRACT

Virtualization and communication middleware technologies bring a new perspective and a new paradigm shift that can be used in the implementation of industrial systems. The goal of this thesis is to assess the feasibility to implement Protection, Automation and Control (PAC) applications in the domain of Electrical Power Systems, according to the IEC 61850 standard, in virtualized environment. Such assessment demands the proposal of a layered architecture and the implementation of a PAC IEC 61850 application in a virtualized environment. The implementation is based on the DDS communication middleware and the case study of a typical IEC 61850 application. The first step of the work asseses the end-to-end communication from the DDS communication middleware layer, running the benchmark applications of the OpenDDS implementation performance tests. The distributed and virtualized testing environment used considers two ordinary physical hosts connected by a simple network. The virtualization layer is implemented using KVM as hosted hypervisor with Linux Ubuntu and TinyCore as Guest-OS. This initial assessment of the DDS middleware defines a set of test scenarios based on the combination of host-host, host-VM and VM-VM communications. Each test measures the round-trip time of each message, from which latency and jitter are obtained. The second step of the work asseses the end-to-end communication of the case study IEC 61850 application. The final application, composed of 6 modules, was developed following a clear and straight method. The two test scenarios used define local and distributed tests. In the local scenario, all the 6 modules run in a single host. In the distributed scenario, the system is partitioned in 2 hosts and 4 VMs. Each test scenario performs a set of 15 test cases defined in 3 scripts. The results obtained are presented in tabular and graphical formats. The preliminary results of the DDS test show that soft real-time applications with deadlines up to 1 ms could run in the proposed virtualized environment. The work shows the potential to run PAC applications in a virtualized and distributed environment. The case study results, on the other hand, show the limitations of the ordinary infrastructure used. The maximum latencies reach up to 20 ms and 30 ms in a few cases. The contribution of this thesis is the information provided, based on the proposed reference architecture and respective time characterization, available to engineers responsible by the design of PAC solutions and researchers. In this way, they can begin to consider and evaluate the use of modern computing architectures and technologies, particularly virtualization and communication middleware, in new Engineering projects or case studies and more specific scientific investigations.

Keywords: Virtualization. Distributed System. DDS. OpenDDS. IEC 61850. PAC. SDPAC.

LISTA DE FIGURAS

Figura 1 – Partes da norma IEC 61850 ...... 29 Figura 2 – Diagrama funcional de um IED ...... 30 Figura 3 – Mapeando Nós Lógicos, Classes e Dados para o Mundo Real ...... 31 Figura 4 – Interação entre Logical Nodes ...... 32 Figura 5 – Perfis de Comunicação ...... 33 Figura 6 – Visão ACSI da Interação cliente-servidor ...... 35 Figura 7 – Quadro ethernet adotado no padrão IEEE 802.1p ...... 36 Figura 8 – Repetição de Mensagens GOOSE...... 37 Figura 9 – Estrutura de Dados de um IED ...... 38 Figura 10 – Usando a Core ACSI API em um IED ...... 39 Figura 11 – Arquitetura de Referência IEC TC57 ...... 40 Figura 12 – Mapeamento entre CIM e IEC 61850 ...... 41 Figura 13 – Barramento de Dados ...... 47 Figura 14 – Espaço Dados Global ...... 47 Figura 15 – Migração Mapeamento Físico do Modelo IEC 61850 para Infraestrutura de Virtualização e Nuvem ...... 53 Figura 16 – Mapeamento Projeto Lógico IEC 61850 ...... 54 Figura 17 – Relacionamento entre Objetos modelo de informação e Classes ACSI . 57 Figura 18 – Arquitetura de Comunicação do Xen ...... 71 Figura 19 – Pilha de Protocolo IEC 61850 ...... 99 Figura 20 – Definição de Tempo de Transferência ...... 100 Figura 21 – Níveis do sistema de automação elétrica ...... 111 Figura 22 – Visão da Arquitetura do DDS para Mapeamento da Norma IEC 61850 ...... 118 Figura 23 – Arquitetura do microhypervisor NOVA ...... 121 Figura 24 – Visão Arquitetura Conceitual de Alto Nível ...... 122 Figura 25 – Arquitetura em Camadas ...... 123 Figura 26 – Visão Idealizada da Arquitetura Final ...... 124 Figura 27 – Estudo de Caso: Projeto Aplicação SEP - Proteção de Bay ...... 127 Figura 28 – Estudo de Caso: Projeto Aplicação PAC61850 ...... 128 Figura 29 – Estudo de Caso: Projeto Desenho Lógico IEC 61850 ...... 130 Figura 30 – Estudo de Caso: Projeto Parcial Modelo UML IEC 61850 ...... 131

Figura 31 – Estudo de Caso: Projeto DDS ...... 132 Figura 32 – Estudo de Caso: Nuvem IEC 61850 ...... 133 Figura 33 – PolicyLib: Mapeamento OpenDDS de QoS GSE e SMV ...... 137 Figura 34 – DataLib: Mapeamento OpenDDS dos Tipos IEC 61850 ...... 138 Figura 35 – DcpsLib: Mapeamento OpenDDS da Aplicação PAC61850 ...... 139 Figura 36 – Arquitetura de Testes ...... 146 Figura 37 – Arquitetura de Testes com Linux, KVM-QEMU, TinyCore e OpenDDS 147 Figura 38 – Arquitetura de Testes com Genode-NOVA, Seoul/VBox, TinyCore e OpenDDS ...... 147 Figura 39 – Gráfico de Latência e Jitter para o Teste Host_Local ...... 151 Figura 40 – Gráfico de Quantiles de Latência por Tamanho de Mensagem para o Teste Host_Local ...... 152 Figura 41 – Gráfico de Densidade de Latência por Tamanho de Mensagem para o Teste Host_Local ...... 153 Figura 42 – Gráfico de Latência e Jitter para o Teste VM_Local ...... 154 Figura 43 – Gráfico de Latência e Jitter para o Teste Host-VM_L ...... 154 Figura 44 – Gráfico de Latência e Jitter para o Teste Host-VM_R ...... 155 Figura 45 – Gráfico de Latência e Jitter para o Teste VM-VM_L ...... 155 Figura 46 – Gráfico de Latência e Jitter para o Teste VM-VM_R ...... 156 Figura 47 – Gráfico de Latência e Jitter para o Teste Host_Host ...... 156 Figura 48 – Arquitetura de Testes do Estudo de Caso ...... 165 Figura 49 – Exemplos de Curvas de Tempo Definido e Tempo Inverso para Proteção de Sobrecorrente (50/51) ...... 165 Figura 50 – Medição de Latência para o Estudo de Caso ...... 174 Figura 51 – Estudo de Caso: Gráfico de Latência e Jitter para o Teste Local e Tempo Simulação de 2ms ...... 178 Figura 52 – Estudo de Caso: Gráfico de Quantiles de Latência por Módulo para o Teste Local e Tempo Simulação de 2ms ...... 178 Figura 53 – Estudo de Caso: Gráfico de Latência e Jitter para o Teste Distribuído e Tempo Simulação de 2ms ...... 179 Figura 54 – Estudo de Caso: Gráfico de Quantiles de Latência por Módulo para o Teste Distribuído e Tempo Simulação de 2ms ...... 179 Figura 55 – Arquitetura de Arquivos do TinyCore ...... 203

LISTA DE QUADROS

Quadro 1 – Objetivos da Norma com o Advento do IED ...... 29 Quadro 2 – Níveis para Alocação Lógica de Funções ...... 31 Quadro 3 – Serviços de Comunicações ACSI ...... 33 Quadro 4 – Mensagens previstas na Norma IEC 61850 ...... 34 Quadro 5 – Comunicação Vertical e Horizontal ...... 34 Quadro 6 – Comparação Características Principais Middlewares de Comunicação . 48 Quadro 7 – Comparação Hypervisors ...... 50 Quadro 8 – Desafios Esperados ...... 91 Quadro 9 – Características de Tempo ...... 93 Quadro 10 – Recursos Computacionais por VM ...... 93 Quadro 11 – Requisitos de Desempenho – Perfil de Tempo Real Aplicações PAC . 94 Quadro 12 – Classes de Desempenho ...... 97 Quadro 13 – Tipo de Mensagem e Classe de Desempenho ...... 97 Quadro 14 – Protocolos IEC 61850 e Requisitos ...... 99 Quadro 15 – Níveis de Automação da SEMD ...... 111 Quadro 16 – Níveis de Automação da UHI ...... 112 Quadro 17 – Requisitos dos Usuários (Visão do Autor) ...... 112 Quadro 18 – Aplicação Framework SOA ...... 116 Quadro 19 – Mapeamento de Serviços ACSI e Tópicos DDS...... 117 Quadro 20 – Configuração dos Parâmetros de QoS do DDS para Serviços ACSI . 117 Quadro 21 – Componentes Arquitetura em Camadas ...... 123 Quadro 22 – Ambientes de Implantação para Experimentos ...... 123 Quadro 23 – Estudo de Caso: Nós Lógicos Utilizados ...... 128 Quadro 24 – CDCs, Atributos, Tipos e FC dos Dados dos LNs ...... 136 Quadro 25 – Definição dos Tipos Especiais ...... 136 Quadro 26 – Relação de Testes Host-VM ...... 144 Quadro 27 – Softwares para Ambiente de Testes ...... 145 Quadro 28 – Configuração de Hardware Máquinas de Teste ...... 145 Quadro 29 – Rede de Testes ...... 146 Quadro 30 – Execução dos Testes Realizados ...... 148 Quadro 31 – Cenários de Teste para o Estudo de Caso ...... 163

LISTA DE TABELAS

Tabela 1 – Resultados Estatísticos de Latência e Jitter [µs] do DDS ...... 150 Tabela 2 – Latência Mediana [µs] ...... 157 Tabela 3 – Densidade Máxima [%] e Percentil 95 das Latências [µs] por Protocolo ...... 157 Tabela 4 – Tempo de Referência [µs] por Cenário de Teste ...... 158 Tabela 5 – Análise Tempo de Resposta ...... 160 Tabela 6 – Casos de Teste dos Experimentos com o Estudo de Caso ...... 173 Tabela 7 – Latências para Tempo de Simulação de 2 ms (Local | Distribuído) ...... 175 Tabela 8 – Latências para Tempo de Simulação de 10 ms (Local | Distribuído) ..... 175 Tabela 9 – Latências para Tempo de Simulação de 20 ms (Local | Distribuído) ..... 176 Tabela 10 – Estudo de Caso: Latência Mediana e Percentil 95 [µs] nível Tópicos (DO-vLNs) ...... 177

LISTA DE ABREVIATURAS E SIGLAS

AADL Architecture and Analysis Design Language ACSI Abstract Communication Service Interface CB Control Block CBS Constant Bandwidth Server CDF Cummulative Distribution Function CFI Canonical Format Identifier CIM Common Information Model CORBA Common Object Request Broker Architecture CoS Class of Service DDS Data Distribution Service DHT Distributed Hash Table DMS Distributed Management System DUT Device Under Test EMS Energy Management System EPRI Electric Power Research Institute GIS Gas Insulated Substation GOOSE Generic Object Oriented Substation Event GSSE Generic Substation Status Event HPC High Performance Computing HPCC High Performance Cloud Computing IaaS Infrastructure as a Service IDC Inter-Domain Communication IEC International Eletrotechnical Commission IED Intelligent Electronic Device IHM Interface Humano Máquina IoE Internet of Everything IoT Internet of Things IOU Input-Output Unit LD Logical Device LHP Lock-Holder Preemption LOC Lines Of Code LN Logical Node

MAD Median Absolute Deviation MCAA MultiCast Application Association MILS Multiple Independent Leves of Security MMS Manufacturing Message Specification MPR Multiprocessor Periodic Resource MTTR Mean Time To Repair MU Merging Unit NIST National Institute of Standards and Technology NOVA NOVA OS Virtualization Architecture OMG Object Management Group PaaS Platform as a Service PAC Proteção, Automação e Controle PAT Plano de Atualização Tecnológica PD Physical Device PDU Protocol Data Unit PIU Process Interface Unit PLC Programmable Logical Controller POC Proof of Concept (Prova de Conceito) PRP Parallel Redundancy Protocol P2V Physical to Virtual QoS Quality of Service RDF Resource Description Framework RESCH Real-Time SCHeduler REST REpresentational State Transfer REST Rapid Spanning Tree Protocol RTCA Real-Time Communication Architecture RTOS Real-Time Operating System RTPS Real-Time Publish-Subscribe RT-VM Real-Time Virtual Machine RTU Remote Terminal Unit SaaS Software as a Service SAS Substation Automation System SCADA Supervisory Control and Data Acquisition SCL Substation Configuration Language

SCSM Specific Communication Service Mapping SDSC Sistema Digital de Supervisão e Controle SEMD Subestação Margem Direita SEP Sistema Elétrico de Potência SLA Service Level Agreement SMV Sampled Measured Value SOA Service Oriented Architecture SOAP Single Objetct Access Protocol TA Tecnologia da Automação TAF Teste de Aceitação de Fábrica TCB Trusted Computing Base TCI Tag Control Information TO Tecnologia da Operação TPAA Two Party Application Association TPID Tag Protocol IDentifier UAC Unidade de Aquisição e Controle UCA Utility Communications Architecture UHI Usina Hidrelétrica de ITAIPU UML Unified Modeling Language VM Virtual Machine VMI Virtual Machine Interface VMM Virtual Machine Monitor

SUMÁRIO

1 INTRODUÇÃO ...... 15 1.1 CASO EXEMPLO: USINA HIDRELÉTRICA DE ITAIPU ...... 17

1.2 MOTIVAÇÃO ...... 19

1.3 PREMISSAS ...... 19

1.4 OBJETIVOS ...... 20

1.5 METODOLOGIA ...... 21

1.6 ESCOPO ...... 21

1.7 CONTRIBUIÇÕES ORIGINAIS ...... 22

1.8 ORGANIZAÇÃO DO TEXTO ...... 24

2 DOMÍNIO DE APLICAÇÃO E NORMA IEC 61850 ...... 27 2.1 DOMÍNIO DE APLICAÇÃO ...... 27

2.1.1 SEP (Sistemas Elétricos de Potência) ...... 27

2.1.2 Automação, SAS (Sistemas de Automação de Subestações) ...... 28

2.2 REVISÃO DA NORMA IEC 61850 ...... 29

2.2.1 Estrutura da Norma ...... 29

2.2.2 Objetivos e Conceitos ...... 29

2.2.3 IED (Intelligent Eletronic Device) ...... 30

2.2.4 Modelo de Objetos e Dados ...... 31

2.2.5 Modelo de Comunicação e Interface ACSI ...... 32

2.2.6 Priorização de Mensagens ...... 35

2.2.7 Mecanismo de Comunicação...... 36

2.2.8 Modelo UML ...... 38

2.2.9 Harmonização com a norma IEC 61970 ...... 40

2.3 CONSIDERAÇÕES FINAIS ...... 44

3 COMPUTAÇÃO EM NUVEM E MIDDLEWARE DE COMUNICAÇÃO ...... 45 3.1 REVISÃO MIDDLEWARE ...... 45

3.1.1 Middleware de Comunicação...... 45

3.1.2 DDS (Data Distribution Service) ...... 46

3.1.3 Comparação entre Middlewares ...... 48

3.2 REVISÃO VIRTUALIZAÇÃO E NUVEM ...... 49

3.2.1 Conceituação ...... 49

3.2.2 Tecnologias Existentes ...... 50

3.2.3 Segurança e Nuvem Privada ...... 50

3.2.4 Migração para a Nuvem ...... 52

3.2.5 Virtualização e Nuvem no Contexto da Norma IEC 61850 ...... 53

3.3 MAPEAMENTO DA NORMA IEC 61850 ...... 56

3.3.1 Mapeamento para CORBA ...... 56

3.3.2 Mapeamento para SOA ...... 58

3.3.3 Mapeamento para DDS ...... 58

3.3.4 Comentários ...... 62

4 ASPECTOS DE TEMPO REAL...... 64 4.1 CONCEITOS BÁSICOS ...... 64

4.2 REVISÃO VIRTUALIZAÇÃO E TEMPO REAL ...... 65

4.2.1 Desafios da Virtualização em Tempo Real (García-Valls, et al., 2014) ... 66

4.2.2 Questões de Tempo Real na Virtualização de Sistemas Embarcados (Gu, et al., 2012) ...... 68

4.2.3 Virtualização e Computação em Nuvem em Tempo Real (Xi, 2014) ...... 69

4.2.4 Impactos de Diferentes Algoritmos de Escalonamento em Serviços Web (Li, et al., 2013) ...... 71

4.2.5 NOVA: Arquitetura de Virtualização Segura baseada em Microhypervisor (Steinberg, et al., 2010) ...... 72

4.2.6 Máquinas Virtuais de Tempo Real (Cucinotta, et al., 2008) ...... 74

4.2.7 Paravirtualizando Linux em um Hypervisor de Tempo Real (Legout, et al., 2012) ...... 75

4.2.8 Genode e TinyCore como Guest-OS ...... 76

4.2.9 Quantificando o Desempenho de Implementações IaaS em Nuvem (Berndt, et al., 2013) ...... 76

4.2.10 Avaliação de Desempenho em Nuvem de Diferentes Configurações de Recursos (Batista, et al., 2014) ...... 77

4.2.11 Análise de Latência Incremental de Sistemas Cyber-Físicos Heterogêneos (Delange, et al., 2014) ...... 78

4.2.12 QoS em Computação em Nuvem (Ardagna, 2014) ...... 79

4.3 DDS E TEMPO REAL ...... 81

4.4 CONSIDERAÇÕES FINAIS ...... 87

5 CARACTERIZAÇÃO TEMPORAL DE APLICAÇÃO PAC EM AMBIENTE VIRTUALIZADO ...... 90 5.1 CONSIDERAÇÕES INICIAIS ...... 90

5.2 DESAFIOS – QUESTÕES EM ABERTO ...... 91

5.3 RECOMENDAÇÕES PARA ANÁLISE DE DESEMPENHO ...... 91

5.4 ANÁLISE DE DESEMPENHO ...... 92

5.4.1 Características de Tempo ...... 93

5.4.2 Recursos Computacionais ...... 93

5.4.3 Requisitos de Desempenho – Perfil de Tempo Real Aplicações PAC ... 93

5.4.4 Requisitos de Desempenho – Norma IEC 61850...... 94

5.4.5 Definição de Tempo de Resposta Fim-a-Fim ...... 100

5.4.6 Medição de Desempenho & Tratamento Estatístico ...... 101

5.5 CONSIDERAÇÕES FINAIS ...... 104

6 ARQUITETURA DISTRIBUÍDA E VIRTUALIZADA PARA EXPERIMENTAÇÃO ...... 106 6.1 CONSIDERAÇÕES INICIAIS ...... 106

6.1.1 Pirâmide de Automação ...... 110

6.1.2 Requisitos dos Usuários ...... 112

6.1.3 Vantagens Esperadas ...... 113

6.2 RECOMENDAÇÕES PARA DESENHO DA ARQUITETURA ...... 116

6.2.1 Genode ...... 120

6.2.2 NOVA ...... 121

6.3 DESENHO PROPOSTO ...... 121

6.4 CONSIDERAÇÕES FINAIS ...... 125

7 ESTUDO DE CASO ...... 126 7.1 PROJETO ...... 126

7.1.1 Projeto Aplicação SEP ...... 126

7.1.2 Projeto PAC61850 ...... 127

7.1.3 Projeto Desenho Lógico IEC 61850 ...... 129

7.1.4 Projeto Modelo UML IEC 61850 ...... 131

7.1.5 Projeto DDS ...... 132

7.1.6 Nuvem IEC 61850 ...... 133

7.2 IMPLEMENTAÇÃO ...... 134

7.2.1 Modelo UML Framework IEC 61850 ...... 134

7.2.2 Biblioteca Framework IEC 61850...... 135

7.2.3 Modelo DDS ...... 135

7.2.4 Aplicação PAC61850 ...... 140

7.2.5 ISO Virtual Appliances ...... 141

7.3 CONSIDERAÇÕES FINAIS ...... 142

8 RESULTADOS PRIMEIRA ETAPA – CARACTERIZAÇÃO A PARTIR DDS144 8.1 INFRAESTRUTURA DE EXPERIMENTAÇÃO ...... 144

8.2 IMPLEMENTAÇÃO DO AMBIENTE DE TESTES ...... 148

8.3 TESTES REALIZADOS ...... 148

8.4 RESULTADOS OBTIDOS ...... 149

8.5 ANÁLISE DOS RESULTADOS ...... 157

9 RESULTADOS SEGUNDA ETAPA – CARACTERIZAÇÃO APLICAÇÃO PAC61850 ...... 162

9.1 CONSIDERAÇÕES INICIAIS ...... 162

9.2 CENÁRIOS DE TESTE ...... 163

9.3 IMPLEMENTAÇÃO DO AMBIENTE DE TESTES ...... 164

9.3.1 Funções de Proteção ...... 165

9.3.2 Sequência de Eventos ...... 167

9.3.3 Simulador ...... 169

9.3.4 Sincronismo de Tempo ...... 169

9.3.5 Programação Orientada a Eventos (Event-Driven) ...... 171

9.3.6 Simplificações Adotadas ...... 171

9.4 TESTES REALIZADOS ...... 172

9.5 MEDIÇÃO DE LATÊNCIA ...... 173

9.6 RESULTADOS OBTIDOS ...... 174

9.7 ANÁLISE DOS RESULTADOS ...... 180

10 CONCLUSÃO...... 183 10.1 CONTRIBUIÇÕES DO TRABALHO DE DOUTORADO ...... 184

10.1.1 Caracterização Temporal ...... 184

10.1.2 Arquitetura Proposta ...... 186

10.2 TRABALHOS FUTUROS ...... 187

10.3 PUBLICAÇÕES ...... 188

10.4 PATROCÍNIO ...... 188

REFERÊNCIAS ...... 189

APÊNDICE A – Ambiente de Software Host ...... 195

APÊNDICE B – TinyCore ...... 201

APÊNDICE C – Genode ...... 220

APÊNDICE D – Resultados Benchmark OpenDDS ...... 228

APÊNDICE E – Ambiente de Testes para o Estudo de Caso ...... 232

APÊNDICE F – Resultados Estudo de Caso ...... 243 15

1 INTRODUÇÃO

Um Sistema Elétrico de Potência, ou SEP, tem como objetivo fornecer energia elétrica a consumidores industriais, comerciais e residenciais através da geração, transmissão e distribuição de energia elétrica. Sistemas de Proteção, Automação e Controle, ou PAC, são sistemas comumente aplicados a um SEP. Em função da tecnologia disponível, esses sistemas PAC podem ser analógicos ou digitais. (Mendes, 2011) resume bem essa evolução. Entre a década de 1970 até 1990, os sistemas evoluíram da chamada tecnologia “convencional”, ou eletromecânica, para a tecnologia dita “numérica” que utiliza dispositivos digitais. Devido à obsolescência tecnológica e fim de vida útil, os sistemas PAC passam para a tecnologia atual dita “moderna”, totalmente digital, graças às redes de comunicação de dados disponíveis em todos os níveis do sistema, uso de hardware comum e padrões abertos. A evolução tecnológica, portanto, sempre esteve e sempre estará presente nas empresas de energia elétrica e no dia a dia dos profissionais da área. No caso de empresas que estão passando por processos de modernização, como a ITAIPU, a transição analógico-digital e mesmo a digital-digital tornam-se um grande desafio. Além do desafio técnico em si, certamente um grande desafio é como conciliar durante o período de modernização os ciclos tecnológicos das soluções aplicadas do início ao fim do processo. Neste contexto, a norma IEC 61850 “Communication networks and systems for power utility automation” (61850, 2002) (Samaniego, 2010) (Mendes, 2011) (Hoz León, 2015) destaca-se como uma possível solução de padronização a ser seguida, visando minimizar ou mitigar os eventuais riscos e dificuldades de integração e interoperabilidade dos sistemas PAC entre fabricantes diferentes e entre soluções diferentes que provavelmente surgirão ao longo de um período de modernização. Através da padronização do desenho de um sistema PAC para os engenheiros de projeto, desde funções básicas, a dispositivos e suas interfaces, o padrão pode permitir a clientes como ITAIPU influenciar a indústria, fornecedores e integradores a atenderem suas necessidades específicas e requisitos da forma mais flexível e interoperável possível (Ferreira, et al., 2012) (Ferreira, et al., 2013).

16

Na sua essência, a norma IEC 61850 busca alcançar seus objetivos fundamentais: “Interoperabilidade + Liberdade Configuração + Estabilidade Longo Prazo” Na prática, o que se vê atualmente não é bem assim. Experiências recentes, com projetos IEC 61850 implantados na ITAIPU, se mostraram mais desafiadoras e complexas do que se imaginava. Por um lado existe o fato de a própria norma estar em evolução, começando com sua primeira edição de 2003 até a edição 2.0 a partir de 2009. Ou seja, os fabricantes, na busca de prover soluções novas, modernas, acabam oferecendo soluções ditas IEC 61850 que na prática apresentam lacunas importantes. Por outro lado, os clientes e suas equipes de Engenharia se veem de certa forma perdidos, seja pela dificuldade de entender a norma em si, seja pela dificuldade de encontrar ferramentas de configuração padronizadas, seja pelo uso conservador de tecnologias tradicionais, seja pela diversidade de soluções encontradas em função de pontos abertos na própria norma, seja pela pressão da indústria. Em outras palavras, o usuário fica limitado ao que existe tecnologicamente disponível sem poder de negociação e influência na indústria. Paralelamente, as tecnologias de virtualização estão sendo cada vez mais avaliadas e empregadas em sistemas industriais. Vários fabricantes, como os de sistemas SCADA (Supervisory, Control and Data Acquisition), por exemplo, já tem homologado ambientes virtuais para os servidores principais do sistema e principalmente IHM (Interface Humano Máquina). Middlewares de comunicação, por sua vez, já são utilizados há algum tempo em alguns sistemas industriais como SCADA, mas abordagens mais recentes sempre apresentam uma nova oportunidade de avaliação. Ainda assim, apesar de serem sistemas de missão crítica, estamos falando de sistemas de tempo real com deadlines da ordem de 1 s. Abre-se, portanto, uma oportunidade de se avaliar a utilização dessas tecnologias de virtualização e middlewares de comunicação para sistemas com deadlines mais apertados, como os sistemas PAC aplicados a um sistema elétrico de potência (SEP). Isso iria ao encontro com o objetivo de tentar conhecer melhor a aplicação prática da norma IEC 61850 e buscar outras opções tecnológicas, sem ficar preso aos paradigmas convencionais. 17

Esta tese de doutorado tem como motivação investigar essa nova fronteira tecnológica e avaliar soluções que podem, em algum momento, amadurecerem para se tornarem viáveis no médio-longo prazo para aplicação na prática. Pretende-se poder entender melhor as necessidades e desafios existentes, conhecer melhor as tendências tecnológicas e os rumos que o mercado e os fornecedores estão seguindo, para poder propor alternativas viáveis que agreguem mais valor à automação do setor elétrico de maneira geral. A motivação que redundou nessa proposta de doutorado pode ser melhor entendida pelo contexto apresentado a seguir.

1.1 CASO EXEMPLO: USINA HIDRELÉTRICA DE ITAIPU

A ITAIPU está nesse momento se preparando para o que pode ser considerado como o grande projeto depois da sua própria construção: o Plano de Atualização Tecnológica (PAT) da Usina Hidrelétrica de ITAIPU (UHI). Com o projeto básico contratado em 2016 e concluído em 2018, o plano, em linhas gerais, visa definir a estratégia, questões contratuais e especificar questões técnicas de como será feita a atualização tecnológica de toda a infraestrutura de PAC de todos os subsistemas das suas unidades geradoras e subestações. Todo esse trabalho envolve substituir a tecnologia convencional dos anos 80 e, em alguns casos dos sistemas digitais instalados a partir de 2000, aplicadas em reguladores de velocidade, reguladores de tensão, sistema de excitação, subestação isolada a gás, dentre outros, por tecnologia digital moderna disponível no mercado. Considerando as 20 unidades geradoras existentes, isto significa dizer que o PAT poderá levar cerca de 10 anos para ser concluído, considerando a atualização de 2 unidades por ano. A especificação técnica de cada subsistema, em particular, é o resultado principal de todo o projeto básico que define os requisitos mínimos e escopo para contratação da execução dos serviços de implantação dos novos subsistemas para modernização dos sistemas de automação de toda a planta.

18

Para plantas novas, em teoria, é mais fácil e natural nascer com uma infraestrutura moderna que pode contar, desde a concepção do projeto, com tecnologias e padrões mais recentes. No caso de plantas existentes, como a ITAIPU, os desafios de atualizar e modernizar a planta são ainda maiores, aparecendo novos fatores e restrições que dificultam ainda mais a tomada de decisões que acabam influenciando as escolhas do projeto. Neste contexto, a escolha de padrões, arquiteturas e tecnologias pode ser facilitada com provas de conceito (POC – Proof of Concept) e projetos pilotos, ou mesmo ambientes simulados, tornando a decisão mais empírica e menos subjetiva. O problema, de uma forma geral, envolve modernizar diversos sistemas PAC, com suas infraestruturas próprias, versões legadas, funções repetidas (e.g. aquisição de sinais de campo). Para empresas intensivas em uso de tecnologias de automação, como ITAIPU, este problema aumenta a dificuldade para especificar, instalar, manter e evoluir seus sistemas PAC. Ou seja, este problema tem reflexo direto nas tarefas de engenheiros de projeto, responsáveis por especificar sistemas PAC, e de equipes de manutenção, responsáveis por administrar, manter e garantir a disponibilidade dos sistemas como um todo. Mais especificamente, aumenta a dificuldade para conseguir manter diferentes versões e tecnologias ao longo de longos ciclos de vida, de 8 até 15 anos, sendo necessário conviver com sistemas fortemente acoplados, soluções fechadas (caixa preta/cinza), interfaces diversas. Consequentemente, aumenta a dificuldade recorrente de integração e gestão centralizada dos ativos utilizados, particularmente num cenário de modernização tecnológica. Acaba-se criando, assim, uma proliferação de soluções distintas, com diferentes tecnologias, arquiteturas, interfaces e padrões, aumentando significativamente a complexidade da infraestrutura de tecnologia da automação (TA - TI aplicada à Automação), ou TI Industrial, da empresa. Neste cenário, questões de sobressalente, obsolescência, gestão de configuração e versão dos equipamentos de TA e capacitação das equipes técnicas tornam-se ainda mais críticas para gerenciar e controlar, aumentando sobremaneira os custos e de certa forma os riscos de falhas e indisponibilidade forçada dos sistemas. 19

1.2 MOTIVAÇÃO

Questões de interoperabilidade e mais atualmente intercambiabilidade, são objetivos comuns de diversas normas e padrões na busca de minimizar os efeitos das dificuldades recorrentes relatadas anteriormente. Questões de ambientes integrados, unificados, são soluções buscadas por arquiteturas computacionais modernas. A norma IEC 61850, em especial, aborda a questão de interoperabilidade versus flexibilidade e destaca alguns objetivos fundamentais para aplicações PAC como destacado anteriormente: interoperabilidade, liberdade de configuração e estabilidade de longo prazo ou a prova de futuro (future proof). Somente o uso de padrões não resolve isoladamente o problema, pois as soluções dependem das tecnologias disponíveis que são empregadas e produtos de mercado. Além disso, a própria evolução das normas gera versões variadas, e não necessariamente compatíveis entre si, das soluções oferecidas no mercado, como é o caso da própria IEC 61850. No contexto tecnológico atual, seria interessante poder explorar e avaliar arquiteturas e tecnologias modernas de computação, particularmente de virtualização e middlewares de comunicação, que permitam abstrair e simplificar de maneira mais integrada e flexível o desenho e implantação da solução final. Por outro lado, a solução precisa ter desempenho suficiente para atender os requisitos de desempenho exigidos, considerando a aplicação da norma IEC 61850 como padrão para implementação do domínio de aplicações PAC. Em outras palavras, espera-se que as características de tempo da aplicação PAC IEC 61850 em ambiente virtualizado sejam satisfatórias. Se não forem, a aplicação PAC IEC 61850 não pode ser executada no ambiente virtualizado proposto.

1.3 PREMISSAS

O fato da aplicação PAC ser baseada na norma IEC 61850, referência atual para automação de SEP, é um condicionante, uma premissa, adotada neste trabalho com foco no domínio de aplicação dos sistemas elétricos de potência. Outros

20 padrões, como OpenFMBTM (Open Field Message Bus1), por exemplo, estão emergindo para aplicações em Smart Grid. Contudo, trabalhos sobre a norma IEC 61850 focam muito na questão da rede. Pouco se discute da implementação em software, que se torna literalmente caixa preta. Abstraindo a infraestrutura de rede, é possível focar no software, ou seja, aplicação propriamente dita.

1.4 OBJETIVOS

Embora fundamentais, as questões de interoperabilidade, intercambiabilidade, integração, não são o foco principal da tese. A questão central atacada na tese é se as características de tempo requeridas por uma aplicação PAC IEC 61850 podem ou não serem atendidas em um ambiente virtualizado e distribuído. No ambiente convencional sabemos que podem ser atendidas, pois é assim que as coisas são feitas atualmente. O objetivo deste trabalho de doutorado é avaliar a viabilidade de implementar aplicações PAC conforme a norma IEC 61850 em ambiente virtualizado atendendo os requisitos temporais dessas aplicações. Como objetivos específicos, tal avaliação requererá a proposta de uma arquitetura em camadas e implementação de uma aplicação PAC IEC 61850 em um ambiente virtualizado, com o propósito de verificar o seu desempenho temporal e, desta maneira, elucidar a questão principal da tese. Essa caracterização temporal deverá permitir:  determinar o grau de facilidade/dificuldade em atingir os requisitos temporais, através de um protótipo e uso de tecnologias e plataformas disponíveis, de propósito geral; e  indicar os principais gargalos/dificuldades a serem vencidos para obter implementações satisfatórias. O ambiente de experimentação deverá ser capaz de permitir a avaliação de duas questões:

1 Ver http://www.sgip.org/openfmb/. 21

1. A questão principal está vinculada com a caracterização temporal, para verificar se uma aplicação PAC funcionará em ambiente virtualizado como funciona no convencional, ou seja, se o comportamento temporal medido atende o esperado. 2. Pode-se considerar uma questão secundária a Engenharia de projeto (design), para avaliar e comparar a arquitetura convencional versus a virtualizada, e a comunicação convencional via pilha de protocolos versus middleware de comunicação.

1.5 METODOLOGIA

A metodologia proposta é centrada na construção e avaliação de desempenho de um ambiente de experimentação. O ambiente de experimentação tem como foco principal uma solução computacional: infraestrutura e implementação com desempenho suficiente. Ou seja, verificar empiricamente se implementação real é capaz de atender requisitos nos ambientes computacionais reais considerados. Para alcançar os objetivos pretendidos foi seguida a metodologia a seguir:  apresentar aspectos relevantes da norma IEC 61850;  pesquisar e estudar arquiteturas e tecnologias de virtualização, middlewares de comunicação e computação em Nuvem, e aspectos de desempenho e tempo real desses ambientes;  propor uma arquitetura distribuída e virtualizada;  propor diferentes ambientes computacionais e cenários de teste;  definir o quê e como medir e tratar os dados;  implementar uma aplicação PAC IEC 61850 no ambiente desenhado;  realizar medições do desempenho temporal; e  apresentar e analisar os resultados obtidos.

1.6 ESCOPO

A caracterização temporal será feita com base em medições de latência. A medição propriamente dita é feita no nível da aplicação usando recursos do

22 middleware de comunicação DDS, ou seja, o DDS é usado para obter os tempos de resposta fim-a-fim. Está fora do escopo a medição de throughput e configuração de QoS suportados pelo DDS. Na primeira etapa de caracterização a partir do DDS será feita a medição do tempo de ida e volta (round-trip latency), conforme prática bastante utilizada e recomendada (Pérez, et al., 2014). Na segunda etapa de caracterização da aplicação PAC IEC 61850 do estudo de caso a medição de latência é feita pelo subscritor (subscriber), que recebe as mensagens publicadas, através da diferença entre o instante de tempo em que uma mensagem é recebida e o instante de tempo de origem quando a mesma foi publicada. Na primeira etapa o escopo está limitado para:  desempenho do DDS, componente principal da solução;  aplicações de benchmark de teste do OpenDDS, implementação usada do DDS;  ambiente Linux com hypervisor KVM e TinyCore como Guest-OS; e  tempo real leve (soft real-time); Estão fora do escopo:  demais combinações de ambientes (Quadro 22);  comparação com outras soluções de virtualização, como XtratuM – ARINC-653;  tempo real crítico (hard real-time);  comparação entre abordagens de escalonamento hierárquico, reserva de recurcos, dentre outros aspectos de tempo real, conforme 4 ASPECTOS DE TEMPO REAL;  sincronismo de tempo, esquemas de failover, redundância; e  condições de teste tipo avalanche, sobrecarga de rede, falhas de rede. Na segunda etapa o escopo contempla o desempenho da aplicação PAC IEC 61850 do estudo de caso para o mesmo ambiente computacional da primeira etapa, usando sincronismo de tempo NTP (Network Time Protocol).

1.7 CONTRIBUIÇÕES ORIGINAIS

As contribuições dessa tese para o estado da arte são: 23

 com respeito a aplicação prática da norma IEC 61850, observa-se uma dificuldade para o design e documentação de projeto, seja em função da maturidade da própria norma e/ou tecnologia e soluções empregadas. A exceção de subestações onde a aplicação da norma já se encontra bem consolidada, para usinas ainda faltam definições e cases mais completos. Os trabalhos de mapeamentos encontrados, mesmo para o DDS, abordam esta questão, mas não apresentam um case para o domínio de aplicação SEP. Contribuição: o uso do middleware DDS (Data Distribution Service) com foco no dado (data-centric) permite ver todo o problema de comunicação ou troca de dados através do modelo projetado, sem necessidade de vários arquivos .xml. Ou seja, tem-se uma forma mais simplificada e clara de implementar e enxergar a questão central de troca de dados do sistema. O case apresentado mostra uma solução completa para SEP, ainda que simplificada em alguns aspectos: uma arquitetura de referência de um ambiente distribuído e virtualizado para implantação de aplicações PAC; uma aplicação PAC; e um conjunto de testes utilizado. Ou seja, tem-se disponível um possível benchmark para trabalhos futuros.  o uso de tecnologias de rede convencionais, cujas limitações exigiram o desenvolvimento de mecanismos especiais para obter redundância como Parallel Redundandy Protocol (PRP) e Rapid Spanning Tree Protocol (RSTP), evidenciam que a utilização de soluções não desenhadas para o propósito pretendido (maior desempenho e confiabilidade), acabam gerando várias mudanças de design que tornam mais complexa a implementação, testes, implantação e manutenção dos sistemas, particularmente devido aos esquemas de redundância. O uso de virtualização e Nuvem flexibiliza e simplifica a implantação dos sistemas, pois foram desenhados para isso. Recursos intrínsecos como tolerância a falhas e vMove oferecidos por algumas soluções podem ser usados para eliminar ou simplificar os esquemas de redundância. E com um middleware de comunicação como o DDS, tem-se um único e verdadeiro barramento de comunicação virtual do sistema. A questão principal é a

24

necessidade de homologar um sistema PAC em ambientes virtualizados para verificar se o seu desempenho atende os requisitos de tempo da aplicação. Os trabalhos encontrados não contemplam uma caraterização temporal como essa, que aborde sistemas PAC baseados na norma IEC 61850 implementados com middleware de comunicação DDS e implantados em ambiente virtualizado. Contribuição: para o case proposto e implementado, a tese apresenta seu resultado principal que é a caracterização temporal de uma aplicação típica de proteção de sobrecorrente denominada BAY61850. Primeiramente é avaliado o ambiente computacional proposto do ponto de vista da comunicação fim- a-fim do middleware DDS para várias combinações de comunicação entre Host-VM com o objetivo de obter um limite ou referência de tempo, mas não um tempo de resposta para o pior caso. Com o resultado potencial obtido, foi possível avançar para a segunda e principal etapa do trabalho que é finalmente caracterizar o case da aplicação BAY61850. Ou seja, a tese apresenta uma caracterização temporal que retrata o comportamento de todo o sistema PAC medido pela latência no nível de cada tópico do DDS para a infraestrutura computacional comum usada, onde cada tópico é modelado como o DataObject (DO) de um virtual Logical Node (vLN), ou um determinado dado ou conjunto de dados propriamente dito de uma função, e.g. a atuação Op da função de proteção de sobrecorrente instantânea PIOC, conforme a norma IEC 61850.

1.8 ORGANIZAÇÃO DO TEXTO

Este trabalho está organizado em dez capítulos. O capítulo 2 apresenta uma contextualização do domínio de aplicação e aspectos relevantes da norma IEC 61850. O capítulo 3 apresenta a pesquisa bibliográfica sobre arquiteturas e tecnologias de computação em Nuvem e sistemas distribuídos para aplicação em sistemas de automação elétrica. O capítulo 4 apresenta a pesquisa bibliográfica sobre aspectos de tempo real, desempenho e tolerância a falhas em ambientes distribuídos e virtualizados. 25

O trabalho dessa tese, propriamente dita, e seus resultados, se concentram nos capítulos 5, 6, 7, 8 e 9. O capítulo 5 descreve uma proposta de como realizar a caracterização temporal a partir da implementação de um protótipo e avaliação de seu desempenho, ou seja, diretamente associado à infraestrutura experimental. O capítulo destaca os desafios colocados como questões em aberto, apresenta os requisitos de desempenho comumente esperados pelas aplicações PAC, extrai recomendações de algumas referências bibliográficas, para então propor uma análise de desempenho para caracterização dos ambientes propostos a serem testados. O capítulo 6 define a arquitetura proposta a ser seguida como base conceitual para construção da infraestrutura de experimentação. O capítulo destaca a importância do uso de padrões, abertura dos sistemas, hardware comum, dentre outros aspectos, para permitir desenvolver sistemas mais flexíveis e independentes de tecnologia, cujo desafio é continuar atendendo necessariamente os requisitos de tempo, confiabilidade e segurança. O conhecimento da pirâmide de automação, requisitos dos usuários e vantagens esperadas com uso da virtualização permitem entender melhor o problema para o domínio de aplicação PAC e SEP. As recomendações para o desenho da arquitetura trazem referências úteis e práticas para atingir o objetivo final do desenho proposto. O capítulo 7 desenvolve por completo o estudo de caso. A partir da escolha do problema ou aplicação, o capítulo descreve todas as etapas do projeto bem como os detalhes da implementação, contendo informações detalhadas que podem ser replicadas ou reaproveitadas em trabalhos similares. O capítulo 8 apresenta a primeira etapa de resultados da tese. O capítulo, baseado nas propostas de arquitetura (Capítulo 6) e recomendações para caracterização temporal (Capítulo 5), define e descreve o ambiente de experimentação e cenários de teste seguidos com o objetivo de obter uma referência inicial de desempenho de tempo fim-a-fim a partir da camada do DSS. A infraestrutura de experimentação adotada, embora simples, permite 7 combinações possíveis de Host-VM, cobrindo todo o espectro de comunicações possíveis entre aplicações PAC.

26

O capítulo 9 apresenta a segunda e principal etapa de resultados da tese. O capítulo descreve os cenários de teste que definem o comportamento esperado de todo o sistema PAC, apresenta em detalhes a implementação do ambiente de testes, incluindo as funções de proteção, simulador e sincronismo de tempo, bem como os testes realizados baseados em scripts. Tudo com o objetivo de poder aferir o comportamento esperado versus o medido, conforme resultados obtidos. A medição de latência é explicada passo a passo a partir de um diagrama em camadas fim-a-fim. O capítulo 10 apresenta as principais conclusões da tese. 27

2 DOMÍNIO DE APLICAÇÃO E NORMA IEC 61850

O objetivo deste capítulo é contextualizar o domínio de aplicação e apresentar aspectos considerados mais relevantes da norma IEC 61850.

2.1 DOMÍNIO DE APLICAÇÃO

O domínio de aplicação desse trabalho de doutorado coberto pela norma IEC 61850 e, complementarmente, pela norma IEC 61970 (CIM – Common Information Model) é a automação de um SEP, ou mais especificamente os sistemas PAC, incluindo sistemas de monitoração e medição. Apesar de ser um vasto domínio, para projetos de Engenharia ele engloba atividades de prospecção de tecnologias e soluções disponíveis para especificação da modernização e atualização tecnológica de uma planta ou processo como a UHI. As áreas de conhecimento e domínios tecnológicos correlatos podem ser resumidos aqui em duas grandes áreas:  SEP – Sistema Elétrico de Potência: processo, negócio e projeto de proteção, controle e automação; e  TA – Tecnologia da Automação: eletrônica digital e analógica, computação, segurança, redes, engenharia de software, e mais atualmente virtualização e nuvem. Padrões e normas de testes de tipo, homologação, segurança, protocolos de comunicação, modelos de dados, serviços e gestão de ativos de um SEP. A TA pode ser entendida como uma importante área técnica, independente da TI (Tecnologia da Informação) corporativa, que concilia a TI aplicada a problemas de automação, às vezes também chamada de TO (Tecnologia da Operação).

2.1.1 SEP (Sistemas Elétricos de Potência)

A função principal de um sistema elétrico de potência é levar energia elétrica aos consumidores de forma segura, com qualidade e disponibilidade (Garcia, et al., 2012). Os equipamentos principais do SEP incluem unidades geradoras,

28 transformadores, disjuntores, seccionadoras, linhas de transmissão e linhas de distribuição. Um SEP pode ser dividido em três segmentos conhecidos como GTD: geração, transmissão e distribuição. No caso de uma usina hidrelétrica como a de ITAIPU, existe uma grande diversidade de subsistemas componentes, desde a tomada d’água até a subestação e transmissão. A especificação das interfaces entre esses subsistemas permitiria conhecer explicitamente suas interações e troca de dados. A norma IEC 61850 busca justamente criar um modelo comum de dados e objetos e definir interfaces entre funcionalidades destes subsistemas.

2.1.2 Automação, SAS (Sistemas de Automação de Subestações)

O termo automação é normalmente confundido quanto ao seu escopo real, talvez pela função mais geral de automatizar uma planta industrial como um todo, sendo muitas vezes usado para representar todo e qualquer sistema, incluindo sistemas mais específicos como proteção, controle ou monitoração. Para automação de subestações, por exemplo, o termo SAS (Substation Automation System) que inclui proteção, controle, monitoração, medição e instrumentação, é comumente encontrado, o que corrobora com esta visão. Automatismo, por sua vez, explicita melhor os mecanismos e lógicas de automação como intertravamentos, dentre outros. A norma IEC 61850 nasceu com foco em sistemas de automação de subestações. Com o avanço da norma e das tecnologias, a norma começou a abranger outras áreas, como usinas hidrelétricas e smart grids. A norma em si e muitas referências bibliográficas ainda utilizam o termo SAS. No caso de um SEP, o termo PAC parece mais representativo, pois separa explicitamente os três principais sistemas usados para automatizar as diferentes partes, sendo usado muitas vezes pela própria comunidade da norma IEC 61850. Neste trabalho de doutorado, o termo PAC será usado doravante para representar toda e qualquer solução de automação de quaisquer subsistemas de um SEP, incluindo SAS. Na parte de automação consideram-se incluídos os sistemas de monitoração, medição e instrumentação subjacentes. 29

2.2 REVISÃO DA NORMA IEC 61850

O objetivo desta revisão é apresentar os aspectos da norma considerados mais relevantes para esta tese. Informações mais detalhadas podem ser obtidas diretamente da norma ou diversos trabalhos publicados ao longo dos últimos anos.

2.2.1 Estrutura da Norma

Na sua primeira versão, publicada em 2003, a norma IEC 61850 apresenta dez partes, com um total aproximado de 1000 páginas, conforme Figura 1 a seguir. Figura 1 – Partes da norma IEC 61850

Fonte: (Samaniego, 2010) (DOS SANTOS, L., 2007) O barramento de subestação é chamado barramento de estação na norma.

2.2.2 Objetivos e Conceitos

Com o advento dos Dispositivos Eletrônicos Inteligentes, ou IED’s (Intelligent Electronic Devices), a norma busca atender os objetivos listados no Quadro 1. Quadro 1 – Objetivos da Norma com o Advento do IED Objetivo Descrição Habilidade de IED’s de um ou mais fabricantes em trocar Interoperabilidade informações, utilizando a informação para a execução de suas

30

próprias funções.

Suporte a diferentes filosofias e capacidade para a livre alocação de Livre Configuração funções, ou seja, deve trabalhar igualmente bem tanto em sistemas centralizados como em sistemas distribuídos.

O padrão é a prova de futuro, ou seja, deve ser capaz de Estabilidade em acompanhar os progressos na tecnologia da comunicação, bem Longo Prazo como requisitos de um sistema evolutivo. Fonte: (Samaniego, 2010) Em linhas gerais, pode-se dizer que a norma IEC 61850 visa padronizar dois aspectos importantes para facilitar a especificação de sistemas PAC e tornar independente a implementação de um:  Modelo comum de objetos e dados para o desenho lógico do sistema; e  Modelo de serviços e mecanismos de comunicação entre IED’s.

2.2.3 IED (Intelligent Eletronic Device)

O diagrama funcional do IED segundo a norma é apresentado na Figura 2. Figura 2 – Diagrama funcional de um IED

Fonte: (Samaniego, 2010) (DOS SANTOS, L., 2007) Neste diagrama é possível ver no quadro central da figura as diversas funções PAC previstas na norma, como por exemplo, a função de proteção de sobrecorrente temporizada PTOC. 31

2.2.4 Modelo de Objetos e Dados

O modelo de dados está centrado no conceito do nó lógico, ou Logical Node (LN). O LN é um modelo abstrato de uma interface que representa uma função elementar de um sistema de automação na planta, por exemplo: disjuntores e transformadores de tensão e corrente (Samaniego, 2010). A Figura 3 apresenta uma representação mais clássica do modelo de dados. O PD (Physical Device) representa o IED. O LD (Logical Device) representa um container de LNs. O Data Class o Data Object (DO) e Data o Data Attribute (DA). Figura 3 – Mapeando Nós Lógicos, Classes e Dados para o Mundo Real

Fonte: (Gers, 2012) As funções devem ser alocadas de maneira lógica e livre em três níveis de controle (IEC 61850-5), conforme Quadro 2. Quadro 2 – Níveis para Alocação Lógica de Funções Nível Funções Encontram-se todas as funções vinculadas diretamente com o processo. Processo Ex: funções dos equipamentos de medição e atuação.

Encontram-se as funções que utilizam os dados de um vão e atuam Vão diretamente nos equipamentos primários (disjuntores e seccionadoras). Ex: intertravamento entre disjuntores e seccionadoras.

Funções que usam os dados de vão ou da subestação inteira e atuam Estação diretamente nos equipamentos primários. Ou funções que representam a interface entre a subestação e o centro de controle ou entre a estação

32

de engenharia para monitoramento e manutenção. Ex: interfaces. Fonte: (Samaniego, 2010) A Figura 4 ilustra a interação entre LN’s conforme a norma IEC 61850-5. Figura 4 – Interação entre Logical Nodes

Fonte: Figura 3 (IEC 61850-5) O aspecto mais interessante a se observar nesta figura são as funcionalidades F1 e F2. Para implementar essas funcionalidades, as funções necessárias ou LN’s podem estar distribuídas em diferentes dispositivos físicos, ou seja, Physical Devices (PD’s) ou IED’s. As conexões ou comunicações são destacadas como conexões físicas (PC – Physical Connection) ou lógicas (LC – Logical Connection).

2.2.5 Modelo de Comunicação e Interface ACSI

No modelo de comunicação, uma forma simplificada de visualizar os perfis de comunicação é apresentada na Figura 5 adaptada de (Liang, et al., 2008). A Abstract Communication Service Interface (ACSI) ou Interface de Serviços de Comunicação Abstrata, definida na IEC 61850-7-2, como o próprio nome indica, provê a API de serviços de comunicação para as aplicações. O Specific Communication Service Mapping (SCSM), definido nas partes 8-1 (MMS-TCP/IP-Ethernet), 8-2, 9-1 (Peer-to-peer) e 9-2 (SMV) da norma IEC 61850, realiza o mapeamento dos serviços disponíveis às aplicações (ACSI) para mensagens específicas. 33

Figura 5 – Perfis de Comunicação

SAS IEC 61850 Applications

MCAA Time TPAA ACSI Peer-to-peer – Publish / Subscribe Model Sync Client-Server

SNTP SCSM SMV GOOSE GSSE MMS PTP

ASN.1 ASN.1

UDP TCP Comm. GSSE Stack T-Profile IP

Priority Tagging - IEEE 802.1p / 802.1Q

Media Ethernet

As comunicações disponíveis são de três tipos conforme Quadro 3. Quadro 3 – Serviços de Comunicações ACSI Serviço Características Representado pelo modelo de associação TPAA (Two Party Application Association) responsável por fornecer os serviços para gestão das associações entre clientes e servidores. Client-Server O serviço deve permitir troca de informações através de uma conexão bidirecional orientada a conexão, confiável e com controle de fluxo de ponta a ponta.

Representado pelo modelo de associação MCAA (MultiCast Application Association) responsável por fornecer um serviço de troca de Peer-to-peer informações unidirecional entre uma fonte (publisher) e um ou mais destinos (subscriber).

Time e Time Serviços de referência e sincronismo de tempo. Synchronization Fonte: (Kostic, et al., 2007) As mensagens são descritas no Quadro 4.

34

Quadro 4 – Mensagens previstas na Norma IEC 61850 Mensagem Características Nas interações do tipo cliente-servidor entre aplicações e servidores, MMS existe o mapeamento para MMS (Manufacturing Message Specification) especificado na parte 8-1 da norma IEC 61850.

Generic Object Oriented Substation Events que oferece um caminho GOOSE rápido para a troca de dados no barramento de estação (station bus).

Generic Substation Status Event que oferece um caminho rápido para a GSSE troca de estado no nível da subestação.

Sampled Measured Value multicast, anteriormente SV (Sampled Value), SMV fornece uma forma efetiva para troca de dados no barramento de processo (process bus). Fonte: (Liang, et al., 2008) Enquanto MMS usa um modelo de comunicação cliente-servidor, os demais usam modelo peer-to-peer. Os principais tipos de comunicação estão destacados no Quadro 5. Quadro 5 – Comunicação Vertical e Horizontal Comunicação Características Este tipo de comunicação ocorre entre dispositivos pertencentes a níveis funcionais diferentes e é realizada no modo cliente-servidor. A configuração de IED’s, informações e medições de processo são exemplos de comunicação vertical. Neste caso, o servidor corresponde aos IED’s (nível de vão), que fornecem informações para o sistema SCADA, que corresponde ao cliente da comunicação (nível de estação). Esta comunicação geralmente não tem restrições críticas de tempo. Vertical Um tipo de comunicação vertical entre IED’s e sistemas SCADA são as mensagens MMS (Manufacturing Message Specification). Essas mensagens podem ser solicitadas via pooling ou via reports (relatórios). Na leitura via pooling o sistema SCADA solicita as informações dos IED’s, já via reports estas informações são disponibilizadas pelos IED’s para o sistema SCADA, mediante o cumprimento de condições pré- configuradas, como banda morta ou o vencimento de um tempo de integridade (tempo máximo entre amostras).

Horizontal A comunicação horizontal acontece entre os dispositivos pertencentes à 35

mesma camada funcional. As mensagens GOOSE e GSSE compõe esse grupo de mensagens de alta prioridade. A troca dessas mensagens é realizada no modo produtor-consumidor, em que determinado IED disponibiliza as informações na rede e o IED consumidor trata as mensagens que lhe forem necessárias. Fonte: (Souto, 2009) O modelo de serviços cliente-servidor da ACSI define a semântica dos dados trocados entre aplicações e servidores. O desenho da ACSI adota uma abordagem orientada a objetos, com um modelo de dados hierárquico e um conjunto de serviços para cada classe do modelo. O modelo de dados, apesar de descrito separadamente, faz parte da ACSI (Liang, et al., 2008). A Figura 6 a seguir ilustra bem a interação cliente-servidor na visão ACSI. Figura 6 – Visão ACSI da Interação cliente-servidor

Fonte: Figure 5-3 (Sanz, 2002)

2.2.6 Priorização de Mensagens

A solução para a priorização de mensagens em redes Ethernet é contemplada pelo padrão IEEE 802.1p, uma extensão do padrão IEEE 802.1Q que permite a criação de VLAN’s. O padrão 802.1Q inclui um campo VLAN TAG de 4 bytes no quadro Ethernet contendo:

36

 Ether-type TPID (Tag Protocol Identifier): sempre 0x8100 para quadro Ethernet;  TCI (Tag control Information) composto por três campos: o Priority: 0-7; o CFI (Canonical Format Identifier): 0 para switches Ethernet; e o VID (VLAN ID): faixa de 1-4095. O campo Priority são os 3 bits usados pelo padrão 802.1p dentro do campo VLAN TAG para permitir ao usuário definir 8 possíveis níveis de prioridade, ou CoS (Class of Service), da mensagem. A Figura 7 apresenta o quadro ou frame Ethernet com o padrão 802.1Q e 802.1p. Figura 7 – Quadro ethernet adotado no padrão IEEE 802.1p

Fonte: (Samaniego, 2010) (ZHANG, Q., 2005) Dois conceitos importantes se aplicam aqui:  Priority Frames: frames que carregam valor de prioridade e VLAN ID “0”; e  VLAN Unaware Mode: permite passar frames com prioridade (VLAN ID = 0) sem modificar. Mensagens GOOSE exigem switches que atendam esses dois requisitos.

2.2.7 Mecanismo de Comunicação

Se for configurado para fazer isso, a publicação de mensagens pode ser feita de forma espontânea, isto é, sem a necessidade de serem solicitadas por outro equipamento. No caso de uma mensagem GOOSE, a mesma é enviada continuamente a cada Tmax. Quando um novo evento ocorre, uma nova mensagem é gerada e o período de envio diminui para Tmin. Em seguida esse período é incrementado até que o Tmax seja atingido ou que outro evento ocorra, gerando uma 37 nova mensagem, conforme mostrado na Figura 8. Caso não ocorram novos eventos, uma mensagem é repetida em períodos de tamanho Tmax. Maiores detalhes em IEC 61850-8-1/Item 18.1.2.5. Figura 8 – Repetição de Mensagens GOOSE

Fonte: (Samaniego, 2010) (GURJÃO, E., 2006) Para definir o que deve ser transmitido, um conjunto de dados relacionados a todas as mensagens (cliente-servidor MMS, GOOSE ou SMV) e um evento que define o início da transmissão é definido em um bloco de controle (Control Block). A composição das mensagens GOOSE, por exemplo, é feita por Dataset e DataItem. Um DataItem representa cada atributo (Data Attribute) de um LN que se deseja transmitir. O Dataset é o conjunto ou lista dos DataItem criados, na ordem estabelecida. A definição é feita no nível do LD que possui um LN chamado LLN0 que encapsula a funcionalidade de comunicação do LD. O ControlBlock (CB), definido para mensagens GOOSE, GSE, SMV e MMS, contem as informações do perfil de comunicação. Para mensagem GOOSE define- se, por exemplo, tempo máximo e mínimo. Esse mecanismo visa garantir a interoperabilidade, e permite que os dados a serem transmitidos possam ser organizados de maneira flexível, na ordem desejada e oriundos de atributos de diferentes LN’s, desde que pertencentes ao mesmo LD. A Figura 9 apresenta um diagrama que ilustra bem essa estrutura de dados. Neste caso, é apresentado um exemplo de um IED de um fabricante que publica um DataSet com estrutura fixa de 14 DataItens. O IED, denominado CV, foi configurado para publicar uma mensagem GOOSE através do DataSet denominado GOOSE1 e para receber duas mensagens GOOSE através dos DataSets GooseST e GOOSE_outputs provenientes das mensagens publicadas pelos IED’s OP e AA, respectivamente.

38

Figura 9 – Estrutura de Dados de um IED

Fonte: Figura 7.12 (Samaniego, 2010)

2.2.8 Modelo UML

Para o trabalho desta tese, destaque para a grande contribuição de dois artigos pioneiros que trouxeram a norma IEC 61850 à luz da engenharia de software visando simplificar implementações de soluções IEC 61850. O primeiro trabalho de 2004 (Kostic, et al., 2004) traz à tona a discussão para uma especificação mais rigorosa dos modelos de dados e serviços de comunicação de padrões de comunicação de dados industriais, mostrando como o complexo padrão IEC 61850 pode ser modelado de forma elegante e precisa com uma abordagem de meta modelagem utilizando UML (Unified Modeling Language) para a representação do modelo. O resultado do trabalho é um modelo UML formal da norma, contendo a especificação completa dos modelos de dados e comunicação. O modelo UML contribui para tornar o padrão mais acessível para engenheiros e desenvolvedores que não precisam conhecer a fundo o domínio de aplicação, além de facilidades oferecidas por ferramentas CASE como verificação de consistência, documentação e geração de código. O segundo trabalho de 2007 (Kostic, et al., 2007) traz uma contribuição pioneira dos autores na tentativa de trazer a norma IEC 61850 mais próxima às boas 39 práticas de Engenharia de Software, e mais próxima a outros padrões e especificações de TI, como a norma IEC 61970 (CIM). Segundo os autores, a existência de uma API padronizada para os serviços da ACSI facilitaria muito a implementação do padrão e conformidade com a mesma interface. Na parte 7-2 da norma, os serviços da ACSI são definidos na forma de texto e tabela, da mesma forma que o mapeamento padronizado para MMS na parte 8-1, o que acaba levando a implementações diferentes com APIs proprietárias e não padronizadas. A proposta do trabalho é expressar a ACSI como uma API, quebrando qualquer dependência com implementações proprietárias. O processo usado passa pela modelagem, desenho, desenvolvimento e uso da API ACSI. O resultado é um modelo UML para os modelos de dados e serviços ACSI especificados pela norma. A ênfase nesse artigo são os serviços ACSI e a API proposta. Um IED que suporta a norma IEC 61850 contém um ou mais servidores ACSI para disponibilizar os serviços aos clientes. No desenho e desenvolvimento da API, um dos requisitos da API ACSI Core foi permitir sua implantação em dispositivos embarcados. A linguagem escolhida para implementação foi ANSI C++. Juntamente com alguns detalhes técnicos da solução, os autores destacam também alguns problemas e dificuldades encontrados durante o projeto da API, particularmente com relação ao entendimento da norma em si. Um caso de uso da API implementado mostra que desenvolvedores de aplicação conseguem ignorar o protocolo de comunicação subjacente graças a API proposta, conforme Figura 10. Figura 10 – Usando a Core ACSI API em um IED

Fonte: Figure 9 (Kostic, et al., 2007)

40

2.2.9 Harmonização com a norma IEC 61970

Embora não esteja diretamente ligado a este trabalho de doutorado, os esforços de harmonização da norma IEC 61850 com outras normas e padrões mostra claramente a busca por maior facilidade de integração, um objetivo importante que deveria ser prioridade em projetos modernos de automação. Por esta razão, são apresentados aqui alguns aspectos considerados relevantes desse tema. A Figura 11 ilustra bem a diversidade e complexidade da arquitetura de referência de normas e padrões IEC aplicados em sistemas PAC. Figura 11 – Arquitetura de Referência IEC TC57

Fonte: (TC57) Como existem interfaces entre o escopo dessas normas, por vezes pode ser necessário compatibilizar ou harmonizar (termo normalmente usado) as normas, como no caso da norma IEC 61970 (CIM) e IEC 61850 (Schwarz, 2005) (Kostic, et al., 2003) (Becker, 2010), conforme Figura 12 a seguir.

41

Figura 12 – Mapeamento entre CIM e IEC 61850

Fonte: (Schwarz, 2005) O trabalho (Schwarz, 2005) descreve como a norma IEC 61850 pode ser aplicada e estendida para quase toda a cadeia do setor elétrico, além da subestação (SAS), como geração (eólica, hidrelétrica, distribuída), transmissão e distribuição. O autor apresenta os diferentes modelos de informação existentes, que compreendem a informação de domínio estruturada hierarquicamente para fornecer a semântica dos dados a serem trocados. Os dois níveis existentes, modelo CIM para centros de controle e modelos relacionados ao processo, como IEC 61850, compartilham algumas informações comuns, criando uma dependência conceitual entre os níveis. O padrão CIM define uma API, mas não define protocolo para troca de dados, enquanto a norma IEC 61850 define protocolo e métodos para troca de dados, mas não define explicitamente uma API, conforme já destacado anteriormente. A extensão do modelo de informação para plantas hidrelétricas, em particular, inclui novos nós lógicos e objetos de dados, como nível de água, divididos em grupos: funções elétricas; funções mecânicas; funções hidrológicas; e sensores. Dois desafios cruciais são levantados pelo autor: a migração de informação e processamento para IEDs; e a especificação de modelos de informação bem compreensivos e consistentes (modelos comum e específicos). O autor afirma que a mudança para padrões internacionais baseados na norma IEC 61850 fornece a base estável exigida para essa migração de processamento para IEDs. O trabalho (Kostic, et al., 2003) também aborda a necessidade para a integração de padrões importantes relacionados com a troca de dados em

42 subestações (IEC 61850) e centros de controle2 (IEC 61970 EMS-API e IEC 61968 DMS-API). Embora esses dois padrões foquem nos mesmos objetos físicos, equipamentos de campo, eles diferem principalmente nos níveis de detalhe de informação fornecidos, nos requisitos de desempenho, e no escopo de responsabilidade no controle de processo. Um fato importante levantado pelos autores é o reconhecimento das empresas do setor elétrico de que os mesmos dados, e algumas vezes até a mesma funcionalidade, são usados em diferentes aplicações quando deveriam ser reutilizados, o que dificulta sobremaneira o esforço de integração de atualizações e novas aplicações. Apenas recentemente a IEC especificou uma arquitetura de referência (Figura 12) para padrões usados em empresas do setor elétrico. No caso da norma IEC 61850 e CIM (IEC 61970), é a possibilidade de interoperabilidade ou até a integração de aplicações baseadas nesses dois padrões que desafiou os autores a conceberem um mapeamento dos seus modelos de dados. O primeiro passo em direção ao mapeamento dos dois padrões foi desenvolver um modelo UML da própria norma IEC 61850, conforme apresentado na seção 2.2.8 Modelo UML, para em seguida poder iniciar a identificação das relações concretas entre os dois modelos. Como existe diferença de granularidade de informações entre os dois padrões, com IEC 61850 indo consideravelmente mais a fundo nos detalhes, e diferenças de terminologia, o mapeamento torna-se mais difícil e parcial. O resultado do mapeamento é um modelo UML construído a partir dos modelos UML do CIM e UML da norma IEC 61850 desenvolvido como pré-requisito. O mapeamento engloba dois conjuntos de elementos: (1) identificação de subestação e equipamento incluindo relações hierárquicas; e (2) medidas de estado discreto e analógicas, incluindo atributos de qualidade e estampa de tempo. Embora seja possível fazer um processamento automático do mapeamento entre o modelo IEC 61850 (descrito em SCL/XML) e o modelo CIM (descrito em CIM/XML em RDF3), alguns mapeamentos precisam de interação humana. O esquema CIM/XML é gerado automaticamente a partir do modelo UML. No caso da norma IEC 61850, como o esquema SCL (Substation Configuration Language - parte 6 da norma)

2 EMS (Energy Management System) e DMS (Distributed Management System) 3 Resource Description Framework é um framework para descrever e intercambiar metadados, ou seja, informação sobre informação. 43 modela apenas parcialmente a norma, os autores definiram um esquema próprio, denominado SCL+, que estende a SCL. Para testar o modelo UML do mapeamento e verificar até que ponto a conversão entre os dois modelos pode ser feita automaticamente, os autores desenvolveram uma ferramenta em Java. O protótipo desenvolvido fornece uma prova de conceito (POC) e mostra que é possível trocar dados de configuração entre subestação e centro de controle de forma padronizada e automatizada. Os autores afirmam que os benefícios de se ter tais modelos formalmente definidos incluem: (1) facilitar o desenvolvimento de aplicações; e (2) permitir que as empresas (clientes) possam ter definições bem especificadas e sem ambiguidades dos seus dados. Isso é de extrema importância para integração de aplicativos e extensões de aplicativos. O relatório do Electric Power Research Institute (EPRI) (Becker, 2010), por sua vez, reforça a necessidade e importância da harmonização, e mais especificamente de um modelo semântico unificado. Conforme expressado pelo National Institute of Standards and Technology (NIST), interoperabilidade é a chave para alcançar a visão de smart grid, alinhado com a visão distribuída e virtualizada a ser proposta neste trabalho de doutorado, além de ser um dos objetivos principais buscados pela norma IEC 61850. O objetivo do relatório, ao contrário de esforços anteriores de harmonização, é criar a habilidade de usar um modelo unificado comum para definir um perfil IEC 61850 que possa ser usado para gerar arquivos SCL de maneira similar já utilizada para criar arquivos CIM XML. Em reconhecimento ao problema de interface entre padrões, o NIST identificou a necessidade de um modelo semântico comum para comunicações no nível de aplicações em diversas áreas do smart grid. Um modelo unificado IEC 61850/CIM oferece a possibilidade de criar um ambiente que pode ser usado para configurar automaticamente interfaces de comunicação SCADA e ser capaz de trocar informações com outros sistemas entre implementações díspares de fornecedores. Mais especificamente, o modelo unificado atende a necessidade de ter um modelo semântico único para troca de informação entre sistemas baseados em CIM e dispositivos de campo IEC 61850. A abordagem adotada foi definir casos de uso de alta prioridade conduzidos por necessidades do negócio, para então desenvolver um modelo unificado e

44 definições de interface para suportar esses casos de uso. Os casos de uso descritos permitem identificar as interfaces nas quais a informação harmonizada precisa ser trocada, bem como uma indicação de que tipo de informação precisa ser trocado. Na perspectiva do CIM, os casos de uso identificam que partes do CIM precisam ser suportadas, levando a definição de um “grupo de perfil” CIM (profile group). Na perspectiva da IEC 61850, os objetos que serão incluídos no perfil IEC 61850 baseiam-se no que é necessário para suportar os casos de uso e no que é exigido para criar um arquivo SCL SSD ou SCD. Os detalhes da modelagem, alterações propostas e recomendações são apresentados no decorrer do longo relatório.

2.3 CONSIDERAÇÕES FINAIS

Além dos conceitos e contextualização da norma IEC 61850 em si necessários para compreender melhor o universo da norma, este capítulo destaca também a importância da integração com outros padrões, a chamada harmonização de padrões, como a norma IEC 61970 (CIM) para projetos reais de automação de SEP. A principal contribuição prática para o trabalho de doutorado diz respeito à disponibilidade dos modelos UML tanto do padrão CIM4, parte integrante da norma, quanto o modelo IEC 618505 proposto por (Kostic, et al., 2007) e (Kostic, et al., 2004). Graças a esses modelos, a implementação de um Framework IEC 61850 torna-se mais facilitada e aderente às normas. Embora o ideal fosse ter disponível também um modelo UML formal da norma IEC 61850, o que deve ocorrer em algum momento futuro.

4 Versão 15v33 do arquivo iec61970cim15v33_iec61968cim11v13_iec62325cim01v07.zip disponível em: http://cimug.ucaiug.org/CIM%20Releases/Forms/DispForm.aspx?ID=129 5 Encontrada versão de 2009 em: http://www.nettedautomation.com/standardization/IEC_TC57/WG10- 12/iec61850/61850UML.html. 45

3 COMPUTAÇÃO EM NUVEM E MIDDLEWARE DE COMUNICAÇÃO

A arquitetura a ser proposta neste trabalho de doutorado estará alicerçada sobre três partes ou componentes principais:  Norma IEC 61850 para o domínio de aplicação, apresentada no capítulo anterior;  Middleware como solução para comunicação distribuída; e  Ambiente virtualizado e Nuvem como infraestrutura computacional para implantação do sistema. Essa escolha decorre do desejo de avaliar tecnologias modernas que possam ser aplicadas no contexto da norma IEC 61850. A norma IEC 61850 vem sendo cada vez mais aplicada em sistemas de automação de SEP, foco de domínio de aplicação desta tese, e eventualmente poderá se transformar em um padrão de fato no setor elétrico. O objetivo deste capítulo é levantar as informações consideradas mais relevantes da bibliografia encontrada sobre virtualização e middlewares de comunicação para balizar as decisões do desenho da arquitetura proposta.

3.1 REVISÃO MIDDLEWARE

O objetivo desta revisão é apresentar a motivação para uso de middlewares de comunicação.

3.1.1 Middleware de Comunicação

Para uma visão mais prática, (TwinOaks Computing, 2011) define middleware de comunicação como sendo um software que permite a troca de dados entre dois componentes de software, processos e/ou aplicações separados, tanto dentro de um mesmo dispositivo ou entre múltiplos dispositivos. É um tipo específico de middleware que fica entre o sistema operacional (SO) e aplicativos de sistema que permite comunicações.

46

Segundo (TwinOaks Computing, 2011), o propósito de um middleware de comunicação é simplificar o projeto, programação e gestão das aplicações, agilizando a forma como essas aplicações recebem e processam dados, suportando múltiplas linguagens de programação e diferentes arquiteturas de hardware com diferentes recursos e capacidades, facilitando assim a comunicação entre diferentes dispositivos que se tornam capazes de “falar” e “trabalhar” uns com os outros. O uso de um middleware de comunicação reduz a complexidade do sistema. Embora diferentes tecnologias de middleware de comunicação ofereçam diferentes características e benefícios, todas elas se esforçam em: oferecer portabilidade de aplicações em diferentes SOs e hardware; reduzir o custo de desenvolvimento; e simplificar o código da aplicação resultante. Dentre os diversos middlewares existentes, no contexto da norma IEC 61850 foram encontrados alguns trabalhos que abordam o uso do: Common Object Request Broker Architecture (CORBA), padrão do Object Management Group (OMG); Data Distribution Service (DDS), padrão também da OMG; e soluções tipo Service Oriented Architecture (SOA), como o Single Object Access Protocol (SOAP) e REpresentational State Transfer (RESTful). CORBA é um padrão bem estabelecido e conhecido, assim como soluções SOA, com extensa literatura a respeito. DDS, por sua vez, é um padrão mais novo de um middleware centrado em dados, confiável e para tempo real. Como foco deste trabalho de doutorado, são apresentadas suas características principais.

3.1.2 DDS (Data Distribution Service)

Segundo (Twin Oaks Computing, 2011), DDS contem uma API bem definida e fácil de usar. As implementações do DDS oferecem comunicação de dados de alto desempenho apropriada para sistemas de tempo real ou quase tempo real. De uma forma geral, DDS é um modelo de comunicação peer-to-peer que não exige gateways, servidores, ou daemons que precisam ser executados ou configurados. DDS inclui suporte para (Twin Oaks Computing, 2011):  Tipo-seguro (type-safe) de tipos de dados definidos pela aplicação; 47

 Descoberta dinâmica (dynamic discovery) de publishers, subscribers, e tópicos;  Configuração de política de Qualidade de Serviço (QoS); e  Interoperabilidade no fio. (Foster, 2015) destaca que o DDS foi desenhado para suportar o compartilhamento de dados em larga escala, em tempo real, entre dispositivos em uma rede. DDS é usado em diversos sistemas de missão crítica com intensa troca de dados entre dispositivos, exigindo um compartilhamento de dados eficiente, previsível, com baixa latência e confiável. Ainda segundo o autor, DDS pode ser usado tanto em redes confiáveis ou não confiáveis. Mais especificamente, DDS suporta uma arquitetura descentralizada sem broker para permitir o compartilhamento de dados transparente entre produtores e consumidores. DDS é baseado na ideia de um “espaço de dados global” virtual onde produtores escrevem no espaço de dados e consumidores lêem do espaço de dados. Um modelo de dados constituído por tópicos nomeados, seus tipos de dados definidos pelo usuário e QoS associados, o qual é usado pela infraestrutura do DDS para controlar como os dados são compartilhados. A Figura 13 ilustra a conexão que o DDS faz entre produtores e consumidores através de um barramento de dados virtual.

Figura 13 – Barramento de Dados Figura 14 – Espaço Dados Global

Fonte: Figure 3 (Foster, 2015) Fonte: Figure 4 (Foster, 2015) (Foster, 2015) enfatiza que em um sistema centrado em dados (data-centric) o foco é nos dados definidos pelo usuário (modelo de dados). A unidade de troca neste tipo de sistema é um valor do dado. O papel do middleware é entender o contexto dos dados e garantir que todos os subscribers interessados tenham uma

48 visão correta e consistente dos dados, conceito similar de um banco de dados que consegue fornecer uma visão global dos dados e gerenciar o acesso aos mesmos, conforme ilustrado na Figura 14. O autor conclui que para aplicações dispositivo a dispositivo (device-to- device) com requisitos de alto desempenho, tempo real, e conectividade gerenciada de muitos para muitos (many-to-many), DDS tem vantagens distintas sobre outras tecnologias de mensagens. Além disso, DDS também está emergindo como um elemento essencial para a conexão de redes de dispositivos em tempo real para centros de dados baseados em Nuvem.

3.1.3 Comparação entre Middlewares O Quadro 6 a seguir, construído a partir de (Twin Oaks Computing, 2011), compara as características entre os principais middlewares de comunicação. Quadro 6 – Comparação Características Principais Middlewares de Comunicação Middleware Característica DDS CORBA API Socket Web Service TCP (Ponto a Publish-subscribe Ponto) UDP (Ponto Orientado a Arquitetura Ponto a ponto (multicast) a ponto, broadcast mensagem ou multicast) Mesma API para Independência todo HW, SO, e Código adicional Mesma API Mesma API Plataforma linguagem específico suportada Servidor Web Dinâmica, não Pode usar Endereços IP e deve ser Descoberta precisa especificar Naming Service portas em código especificado e endpoint configurado Fortemente tipada, Fortemente Não tem, aplicação Segurança de aplicações tipada, com precisa converter HTTP e XML Tipo chamam write() e interfaces com fluxo de bytes para não oferecem (Type-safety) read() com tipo tipos de dados o tipo de dado específico de dado específicos correto Ajuste Exige código Comportamento Políticas de QoS Limitado Limitado personalizado Comunicação GIOP e IIOP Alguma com Padrão aberto oferecem protocolos Interoperabilidade Não disponível comprovado protocolo de fio SOAP, REST e padronizado WSDL Com base nas características desejadas ou exigidas, esse quadro ajuda a encontrar a solução mais apropriada.

49

3.2 REVISÃO VIRTUALIZAÇÃO E NUVEM

O objetivo desta revisão é apresentar os conceitos envolvidos, o panorama tecnológico e soluções disponíveis sobre o paradigma de computação em nuvem. O intuito não é entrar em detalhes, mas apresentar o que for considerado importante para explorar as vantagens que um ambiente virtualizado e de Nuvem pode trazer para execução de sistemas industriais.

3.2.1 Conceituação

Referência na área, o NIST (Fang Liu, 2011) normatiza algumas definições e conceitos importantes no contexto de computação em nuvem para um entendimento comum. Para virtualização, pode-se destacar alguns termos e conceitos importantes que são usados ao longo do texto. Hypervisor é o termo utilizado para designar o software de virtualização que controla as VMs (Virtual Machines). VMM (Virtual Machine Monitor) é normalmente usado como sinônimo de hypervisor. Microvisor é um hypervisor construído a partir de um microkernel. Guest-OS é o termo usado para designar o SO da VM. Host-OS pode ser usado para designar o SO da máquina física ou host. Um hypervisor pode ser classificado conforme características construtivas de virtualização. Segundo (Gu, et al., 2012), o tipo de virtualização pode ser:  Tipo-1 ou bare-metal, quando a VMM, ou hypervisor, que gerencia as VMs, executa diretamente no hardware; e  Tipo-2 ou hosted, quando a VMM executa sobre um SO. Outra forma de classificação é:  Virtualização Total que permite executar o Guest-OS na VMM sem qualquer modificação do SO; e  Para-virtualização que exige modificar o Guest-OS com a inclusão de hypercalls para a VMM. (García-Valls, et al., 2014) discorre de maneira mais detalhada sobre os diferentes tipos de classificações de virtualização: (1) virtualização completa, que embora elimine a necessidade de modificação do Guest-OS, torna-se mais custosa,

50 pois o hypervisor precisa interceptar todas as instruções privilegiadas do kernel do Guest-OS; (2) virtualização assistida pelo hardware, técnica na qual o hardware fornece recursos adicionais que aceleram a execução das VMs; (3) para- virtualização, técnica que modifica o Guest-OS de modo que o kernel e os drivers tornam-se capazes de realizar chamadas diretas ao hypervisor, também chamadas de hypercalls; (4) virtualização no nível do SO, técnica na qual um único SO cria a ilusão de múltiplas instâncias de SO ou containers, cada um comportando-se como um SO independente; (5) virtualização no nível da aplicação, ou processo, técnica que permite executar uma aplicação sobre um conjunto de instruções virtuais independente do hardware subjacente, sendo o exemplo mais conhecido o bytecode do Java e a JVM (Java Virtual Machine) que interpreta em tempo de execução esse código executando-o no hardware real; e (6) virtualização de rede que permite emular configurações de rede em software.

3.2.2 Tecnologias Existentes

Dentre as soluções tecnológicas disponíveis para computação em nuvem, pode-se citar: VMware baseada no vSphere; KVM baseado no QEMU; Xen e versão de tempo real RT-Xen; e XtratuM. Xen é um hypervisor tipo-1 que usa para- virtualização, enquanto vSphere é um hypervisor comercial tipo-1 que não necessita modificar o Guest-OS. KVM é um hypervisor tipo-2 que executa sobre Host-OS Linux e usa QEMU como VMM. XtratuM é um hypervisor tipo ARINC-653 (Pérez, et al., 2013). O Quadro 7 compara algumas das características desses hypervisors. Quadro 7 – Comparação Hypervisors Característica vShpere KVM Xen XtratuM Tipo de Tipo-1 Tipo-2 Tipo-1 Tipo-1 Virtualização Total Total Paravirtualização Paravirtualização Tempo Real Não Não RT-Xen ARINC-653

3.2.3 Segurança e Nuvem Privada

Conforme destacado em (Ferreira, et al., 2012) (Ferreira, et al., 2013) (Mendes, 2014), questões de segurança da informação e segurança cibernética são aspectos importantes de qualquer solução de rede. 51

Segurança neste contexto não será abordada nesta tese, por se tratar de um assunto vasto, não trivial e não diretamente ligado com este trabalho de doutorado. Ainda assim, foram encontrados alguns trabalhos que abordam o tema segurança, mas em um contexto mais específico, trazendo conceitos importantes e tratando de questões relevantes para o desenho da arquitetura. Alguns trabalhos consideram características de isolação temporal e espacial, TCB (Trusted Computing Base) menor possível e verificação formal para compor um sistema seguro desde o mais baixo nível de software e hardware. (Blackham, 2013) explora o universo de microkernels e a promessa de projeto de criticidade mista para mitigar overheads de várias camadas de software através da consolidação de múltiplos subsistemas em uma única CPU, com funcionalidades de missão crítica e comuns compartilhando o mesmo processador. O autor destaca que para garantir a isolação entre subsistemas de diferentes criticidades, é necessário um supervisor de confiança para mediar o controle sobre o processador e fornecer garantias comportamentais. O autor reforça o fato de que a operação segura de sistemas críticos depende da correção funcional do software e previsibilidade das suas respostas. Ainda segundo o autor, para construir sistemas de criticidade mista de alta segurança, a TCB deve ser mantida a menor possível. A TCB refere-se ao conjunto de todos os componentes (hardware e software) que são críticos para a correta operação do sistema. O autor afirma, portanto, que o SO responsável por garantir a isolação deve ser mantido o menor possível, cuja ideia é compartilhada pelos conceitos de projeto de microkernels e microvisors. A concepção do Genode (Feske, 2010), framework de SO, já considera segurança desde o início. De acordo com a documentação oficial, são consideradas duas questões para avaliar a efetividade de uma função segura. Primeiro, qual é a superfície de ataque potencial de uma função? A resposta para essa questão exige uma avaliação da probabilidade de uma violação. Naturalmente, se existe um grande número de vetores de ataque potenciais, a segurança está em alto risco. A segunda questão é: qual é o alcance de um defeito? Se a função comprometida tem acesso ilimitado a todas as informações processadas no sistema, a privacidade de todos os usuários pode ser afetada. Se a função é capaz de instalar software, o sistema pode tornar-se propenso a portas de fundo (back doors).

52

A arquitetura do Genode foi desenhada para dar respostas mais assertivas a essas duas questões especificadas. Cada pedaço de funcionalidade é exposto somente às partes do sistema das quais depende fundamentalmente, mantendo-se oculto de todas as demais partes não relacionadas. Isto minimiza a superfície de ataque em funções seguras individuais reduzindo, desse modo, a probabilidade de uma violação de segurança. Na eventualidade de uma parte do sistema ficar comprometida, o escopo do defeito é limitado ao fragmento específico e suas partes dependentes. Funcionalidades não relacionadas permanecem incólumes. Em (Rutkowska, 2014) o autor ilustra a isolação segura de software contrapondo a isolação física com a compartimentação de software atualmente possível com o SO Qubes. O autor discute também as fraquezas da isolação de software, ou seja, potenciais problemas de ataques contra a camada de virtualização considerando três níveis: (1) a tecnologia de virtualização propriamente dita, como VT-x e VT-d; (2) o hypervisor, como o Xen; e (3) todo software adicional usado pelo sistema de virtualização. Em (Steinberg, et al., 2010), os autores destacam que a virtualização pode afetar a segurança positivamente ou negativamente, dependendo como é aplicada. A introdução da camada de virtualização geralmente aumenta a superfície de ataque e torna o sistema inteiro mais vulnerável, pois além do Guest-OS, o hypervisor e o VMM são suscetíveis a ataques também.

3.2.4 Migração para a Nuvem

O trabalho (Mohagheghi, et al., 2011) busca definir uma metodologia e ferramentas para migração orientada a modelo (model-driven) de aplicações legadas para uma arquitetura orientada a serviço com implantação em Nuvem, focando nos desafios de Engenharia de Software. Segundo o autor, requisitos não funcionais e QoS em nuvem exigem mais experimentação para entender melhor as consequências. O desempenho da aplicação depende de como os recursos virtualizados são gerenciados e testes devem ser realizados regularmente. No case apresentado, os autores identificam os desafios específicos de Engenharia de Software enfrentados. 53

3.2.5 Virtualização e Nuvem no Contexto da Norma IEC 61850

A ideia inicial de explorar infraestrutura de virtualização e Nuvem no contexto da norma IEC 61850 foi apresentada em (Ferreira, et al., 2012) (Ferreira, et al., 2013). A Figura 15 mostra uma visão simplificada da migração de uma infraestrutura física para virtual no mapeamento do modelo de dados da norma IEC 61850, apresentado inicialmente na Figura 3. Figura 15 – Migração Mapeamento Físico do Modelo IEC 61850 para Infraestrutura de Virtualização e Nuvem

Conforme destacado em (Ferreira, et al., 2012) (Ferreira, et al., 2013), no mapeamento físico convencional seguido em projetos IEC 61850, uma aplicação de software precisa ser implantada em uma máquina física específica onde será executada, criando um acoplamento direto e forte entre o software e o hardware, lógico e físico, também chamado de nó de serviço de aplicação específica. A mudança de paradigma começa com as máquinas virtuais (VMs) que permitiram a mudança do tradicional para o virtualizado. Nessa era da virtualização, a virtualização de servidor evita o acoplamento rígido através da abstração física ou de hardware completa, ou seja, desacoplamento da aplicação e hardware. Posteriormente, a evolução da tecnologia de hardware e projeto das arquiteturas convergiram para transformar toda a infraestrutura física subjacente em uma infraestrutura virtual única, unificada, com recursos computacionais disponíveis para atender os requisitos dinâmicos das aplicações, o que juntamente com os conceitos do NIST apresentados dão início a era da nuvem, ou simplesmente Nuvem.

54

Dentro deste contexto, o desenho lógico de projetos de automação baseados em padrões como a norma IEC 61850 poderia ser mapeado diretamente como nós de serviço virtual fornecendo os serviços das funções projetadas, conforme Figura 16. Figura 16 – Mapeamento Projeto Lógico IEC 61850

Logical Design Physical Design Logical Design Virtual Design

Logical Device 1 IEDs Logical Device 1 vLD1 vLD2

Logical LD1 Logical SW App SW App Nodes Nodes vLNs vLNs LNs OS OS VM VM maps to maps to Regular VM SW Manager Interface IEC 61850 Interface Network Logical Logical Cloud Nodes Nodes IEC 61850 LD2

LNs MU IOU RTU Logical Device 2 IEDs Logical Device 2 Process Tied Devices Mapeamento Lógico-Físico Mapeamento Lógico-Virtual6 Fonte: (Ferreira, et al., 2012) (Ferreira, et al., 2013) O Logical Design representa o desenho ou projeto das funções e conexões ou interfaces lógicas conforme a norma IEC 61850. Physical Design representa a realização tradicional de um projeto lógico usando IEDs e infraestrutura de rede comum, como é feito atualmente. Virtual Design, da forma representada, seria o modelo idealizado da arquitetura virtualizada da Nuvem ou Cloud IEC 61850. Os termos virtual Logical Device e virtual Logical Node, vLD e vLN respectivamente, foram intencionalmente incorporados em (Ferreira, et al., 2012) (Ferreira, et al., 2013) para mostrar explicitamente que estas funções lógicas estão sendo realizadas através de virtualização. No mapeamento tradicional do projeto lógico IEC 61850, funções lógicas mapeiam para máquinas de hardware específicas (IEDs) e as interfaces lógicas mapeiam para interconexões fornecidas pela infraestrutura de rede subjacente. Essas funções são realizadas como serviços pelo software da aplicação implantado e executado nos IEDs que se tornam nós de serviço de aplicação específica.

6 SW App: Software Application. OS: Operating System. 55

Em um projeto assim, qualquer falha de hardware de um IED ou da rede causará perda de parte ou de todas as funções lógicas, comprometendo a operação do sistema como um todo se não houver redundância. No mapeamento virtual proposto na Figura 16, os LDs são mapeados diretamente para vLDs. Nesta abordagem, toda infraestrutura de hardware funciona como uma unidade de hardware única, deixando a cargo da camada de abstração virtual e arquiteturas de software a responsabilidade pela gestão e controle de todo aspecto da execução da aplicação, comunicação e alocação de recursos. Dessa forma, com o mapeamento direto 1:1, uma VM conteria a priori somente um vLD, ou seja, a VM representaria o vLD ou a versão virtual do LD do projeto lógico, vLD1 e vLD2. E toda a infraestrutura de hardware da Nuvem em si representaria os IEDs e a rede do mapeamento físico tradicional. Mas nada impede da VM realizar um ou mais vLDs e ainda assim representar a versão virtual dos LDs, e não do IED. A Figura 15, por outro lado, mostra a VM como substituta direta do IED, ou seja, as máquinas físicas reais (IEDs) tornam-se máquinas virtuais nessa visão, e a Nuvem como substituta da rede convencional, o que parece mais intuitivo pensar num primeiro momento – substituição do hardware dedicado (dispositivo) pela VM e infra de rede de comunicação por ambiente de Nuvem. Essa visão, também chamada P2V, ou Physical to Virtual, é abordada em (Ferreira, et al., 2014). Neste trabalho de tese, contudo, o objetivo é focar no modelo lógico, portanto, a VM aqui representará a realização do vLD e a Nuvem toda infraestrutura de hardware necessária, o que inclui os recursos computacionais providos pelo hardware de um IED, e não somente os recursos de comunicação da rede. Como benefício direto resultante desta “independência de hardware”, a aplicação ou vLDs conforme estabelecido, executando agora em VMs, podem ser “movidos” na Nuvem, ou seja, uma falha de hardware da infraestrutura subjacente não irá comprometer a operação do sistema graças ao recurso de virtual move ou vMove. Dessa forma, o projeto de redundância torna-se mais uma decisão econômica em vez de um requisito de projeto e implementação, especialmente considerando-se esquemas de Disaster Recovery (DR). Obviamente a questão do tempo de migração torna-se um requisito importante.

56

Importante destacar que dispositivos de campo como Merging Unit (MU), Input-Output Unit (IOU) e qualquer outro dispositivo de propósito similar, como Unidades Terminais Remotas (UTR), que estão ligados a equipamentos do campo (processo), não podem seguir este mapeamento, pois a função que trata da aquisição e digitalização de dados não pode ser virtualizada. Por simplificação, (Ferreira, et al., 2012) (Ferreira, et al., 2013) também propõem o termo Process Interface Unit (PIU) para representar de forma genérica e mais explícita qualquer dispositivo de interface com o campo vinculado ao processo. O trabalho (Ferreira, et al., 2014) evoluiu nessa ideia apresentando uma proposta de solução para a abordagem chamada P2V, ou Physical to Virtual, para um caso de aplicação específico de um controle automático de tensão de subestação.

3.3 MAPEAMENTO DA NORMA IEC 61850

Para este trabalho de doutorado, é importante conhecer se existem trabalhos de aplicação de middlewares de comunicação para o contexto da norma IEC 61850, em particular. A pesquisa realizada mostrou que existe uma gama significativa de trabalhos de mapeamento da norma IEC 61850 para diferentes soluções tecnológicas, o que demonstra a importância que a norma vem ganhando entre especialistas de TI e TA, ou seja, os aspectos de soluções computacionais para implementação de sistemas 61850 estão ganhando cada vez mais importância. A seguir são apresentados os mapeamentos propostos, as dificuldades encontradas na visão dos autores, destacando no final alguns pontos destes trabalhos considerados relevantes.

3.3.1 Mapeamento para CORBA

Para o padrão CORBA, foram encontrados alguns trabalhos de mapeamento da norma IEC 61850. O trabalho (Sanz, 2002) apresenta o mapeamento dos objetos e serviços da ACSI especificada pela norma IEC 61850 para CORBA (CORBA SCSM) para permitir a interoperabilidade entre funções de subestação e dispositivos de diferentes fabricantes. O mapeamento contempla o modelo de objetos da norma IEC 57

61850 (Server, Logical Device e Logical Node), modelo de dados (Data Object, Data Attributes e Data Set) e modelo de comunicação (Publish / Subscribe, GOOSE e SMV, File Transfer). Algumas falhas apontadas pelo autor, decorrentes da natureza parcialmente OO (Orientada a Objetos), acabam impactando diretamente o trabalho de mapeamento. Essas constatações corroboram com o entendimento de outros autores (Kostic, et al., 2007) (Kostic, et al., 2004) de que a norma deveria seguir uma abordagem OO usando UML, similar a norma IEC 61970 (CIM). Ainda segundo o autor, o mapeamento, propriamente dito, demonstra que CORBA se encaixa tão bem com a especificação da ACSI que é possível mapeá-la diretamente como interface CORBA, ou seja, ACSI mapeia diretamente para CORBA IDL. Os objetos ACSI podem ser implementados como objetos CORBA. Uma discussão detalhada apresenta as questões de como mapear uma especificação “não puramente OO” para OO, analisando três abordagens identificadas para o mapeamento em CORBA. A abordagem escolhida faz o mapeamento para objetos CORBA até o nível de entidades que aparecem na especificação ACSI (server, logical device, logical node, etc), onde cada um destes elementos se tornarão um objeto CORBA que poderão interagir diretamente entre si. Figura 17 – Relacionamento entre Objetos modelo de informação e Classes ACSI

Fonte: Fig. 4 (Ozansoy, et al., 2004)

58

O trabalho (Ozansoy, et al., 2004) mostra a modelagem da norma IEC 61850 e o uso do CORBA para comunicação em sistemas de potência. Os autores afirmam que a norma IEC 61850 e UCA (Utility Communications Architecture) tornaram possíveis e justificáveis a integração de IEDs através da padronização. O modelo de objetos da IEC 61850, que representa os objetos físicos, padroniza a troca de informações criando uma representação independente dos dados. A Figura 17 mostra um modelo conceitual dos serviços de comunicação representados pela ACSI, destacando o relacionamento entre o modelo de objetos e os serviços disponíveis pelas classes do modelo de troca de informações ACSI. Para disponibilizar os serviços ACSI é necessário mapear a ACSI para um serviço de comunicação específico, como MMS, DCOM ou CORBA.

3.3.2 Mapeamento para SOA

Para soluções tipo SOA, alguns trabalhos abordam o SOAP e RESTful. Segundo (Pedersen, 2010), diferentemente de SOAP, que é um padrão com conjunto crescente de extensões, REST é uma alternativa mais leve, mais centrada na Web, cujo principal objetivo é ficar mais próximo da funcionalidade básica do protocolo HTTP no qual a própria Web é baseada. Como não existe um padrão que descreve REST, desenvolvedores seguem os princípios de REST para criação de serviços RESTful. O princípio REST mais importante é expor os recursos em um serviço RESTful como URLs únicas. O trabalho (Pedersen, 2010) apresenta o mapeamento da norma IEC 61850 para serviços RESTful, descrevendo como a norma pode se beneficiar do conceito do serviço REST no contexto de Recursos de Energia Distribuídos (DER – Distributed Energy Resources).

3.3.3 Mapeamento para DDS

Para o padrão DDS existem alguns trabalhos de mapeamento da norma. O trabalho (Calvo, et al., 2012) apresenta, no contexto da norma IEC 61850 e SAS, uma proposta de mapeamento dos diferentes tipos de tráfego de comunicação previstos na norma para o middleware DDS, criando assim um backbone de comunicação para aplicações SAS. 59

Os autores argumentam que a evolução da automação, com o advento dos IEDs, e a necessidade de integração cada vez maior dos componentes que formam um SAS, são atendidos pelo uso de padrões, como a norma IEC 61850, que define um modelo de dados para facilitar a integração e troca de dados entre IEDs, ou seja, interoperabilidade. Como resultado, os SAS estão se tornando aplicações distribuídas mais complexas. As soluções disponíveis e cada vez mais aceitas criam aplicações de automação distribuída, com IEDs adotando Real Time Operating Systems (RTOS) ou versões melhoradas de SO como Linux-RTAI que são melhor adaptadas para uma abordagem modular e permitem obter máximo desempenho do hardware subjacente, e redes Ethernet e TCP/IP convencionais. Neste contexto, soluções de middleware simplificam o desenho e projeto de comunicação e resolvem o problema de heterogeneidade de plataformas de diferentes fabricantes. CORBA, OPC, Web Services e DDS são alguns exemplos de tecnologias de middleware destacadas pelos autores que permitem integrar dispositivos em sistemas distribuídos. Existem mapeamentos da norma IEC 61850 para CORBA e Web Services. O trabalho (Bi, et al., 2013) investiga também a viabilidade de mapeamento da norma IEC 61850 para DDS. Segundo os autores, o desenvolvimento de plataformas de comunicação apropriadas é fundamental para atender a estratégia de produção de energia elétrica cada vez maior, mais segura, mais confiável e mais econômica, através do uso de tecnologias de automação robustas, confiáveis e de baixo custo. O artigo explora a implementação da norma IEC 61850 via DDS projetando um modelo de dados universal padronizado e um middleware de serviço de entrega. Os autores argumentam que a norma IEC 61850 especifica uma coleção de serviços elementares que podem ser realizados por um SAS, mas o padrão só define um modelo de dados abstrato e não especifica um protocolo de comunicação para implementação real. DDS, por sua vez, é apropriado para aplicações de tempo real, já que o padrão permite controlar os recursos de rede e a latência. O mecanismo de QoS do DDS, em particular, traz para o nível de aplicação a possibilidade de definir o nível de serviço (prioridade, temporização, confiabilidade, dentre outros) exigido.

60

Em uma comparação com outras opções de mapeamento, os autores destacam o mapeamento para MMS, que embora preserve algumas vantagens técnicas, não foi completamente bem sucedido devido a sua complexidade, desempenho fraco e falta de suporte para uma arquitetura publisher / subcriber. Os autores ainda afirmam que tecnologias de middleware baseadas no modelo cliente-servidor, como CORBA, não atendem adequadamente algumas características dos fluxos de dados gerados por relés de proteção, ou seja, mensagens periódicas com dados de valores amostrados. De maneira oposta às abordagens orientadas à mensagem, DDS não troca dados na forma de mensagens – os dados são definidos formalmente de maneira independente de plataforma. Mais especificamente, DDS define um espaço de dados global que pode ser acessado por qualquer aplicação com interesse nos dados. O modelo DCPS (Data Centric Publish Subcribe) descreve um conjunto de classes que são usadas na comunicação. As principais entidades são: Entity; Publisher; Subscriber; e Topic. As três últimas derivam de Entity que permite configurar a política de QoS. A classe Topic representa um fluxo de dados definido por um identificador único e por um tipo de dado. As classes Publisher e Subscriber são usadas para enviar e receber, respectivamente, dados de um Topic através das classes DataWriter e DataReader. RTI DDS é a implementação líder do padrão DDS e vem sendo usada em vários domínios de aplicação, oferecendo o serviço de comunicação que desenvolvedores precisam para distribuir dados de tempo crítico entre nós (computadores) e dispositivos embarcados. O mapeamento proposto segue um método composto de sete passos que é aplicado para o case de uma subestação de barra única, com um alimentador de 220 kV e linhas de saída de 110 kV, mostrando os modelos de dados e de comunicação resultantes. Para demonstrar as funcionalidades do DDS, foram desenvolvidas diversas aplicações de teste usando a versão comercial RTI DDS 4.5d. A configuração de teste utilizada tem três computadores ligados em rede Ethernet 10/100: 1 publisher; 1 subscriber; e 1 monitor com ferramenta da própria RTI. A aplicação consiste em um sistema de monitoração de turbina eólica que gera 10 mil dados por segundo a partir de uma placa de aquisição com taxa de amostragem de 10 kHz. 61

Os resultados obtidos mostram que quanto maior a velocidade de amostras por segundo, menor a confiabilidade (com a perda de pacotes), caindo até 76%. Para essa configuração, o trabalho conclui que o RTI DDS pode fornecer 0.5 ms de confiabilidade de comunicação, satisfazendo o tamanho de mensagem inferior a 256 bytes exigida na parte 5 da norma IEC 61850 (Hoz León, 2015). O trabalho (Pérez, et al., 2013), embora não aborde diretamente mapeamento para a norma, apresenta uma proposta interessante de arquitetura para uso do DDS em sistemas particionados baseados em um hypervisor. Nas palavras dos autores, particionamento é uma técnica que permite executar múltiplas aplicações na mesma plataforma de hardware com forte isolação temporal e espacial, possibilitando a coexistência de aplicações de criticidade diferentes. Tecnologias de middleware, por sua vez, podem oferecer serviços de interesse para sistemas particionados, tais como transparência de localização, abstração de serviços de rede, interoperabilidade. Além disso, existem tentativas iniciais de estender o DDS com um perfil de missão crítica (safety-critical), como o ARINC-653. O interesse do trabalho é possibilitar que sistemas particionados tirem proveito de middlewares de tempo real integrando-os. Os autores argumentam que alguns poucos trabalhos similares tratam da integração do DDS com tecnologias de virtualização, mas sem considerar requisitos de tempo real crítico (hard real-time). Nesse contexto, o trabalho propõem uma arquitetura de sistema que integra o padrão DDS com o hypervisor XtratuM, tipo ARINC-653, especialmente projetado para sistemas embarcados de tempo real. Na arquitetura proposta, os módulos (hardware) possuem três componentes principais: hypervisor XtratuM; partições que implementam o middleware DDS centrado em dados para oferecer facilidades de distribuição tais como transparência de localização e interoperabilidade; uma partição de I/O usada para redirecionar mensagens entre partições em módulos diferentes através da rede via DDS. A partição de I/O é uma estratégia comum adotada para implementar os device drivers, como a NIC, pois no XtratuM o controle e gestão dos dispositivos é deixado para as partições. Um protótipo foi desenvolvido para possibilitar uma análise de desempenho que estima o overhead gerado pela arquitetura proposta, considerando o cenário de

62 uso de um sistema de vigilância por vídeo como prova de conceito. O teste realizado mede o tempo de execução de uma operação remota que publica os quadros de vídeo pedidos, a partir do instante em que o pedido é feito até a imagem retornar. Para 10 mil operações executadas estimam-se os tempos médio, mínimo e máximo, e o desvio padrão. A análise de desempenho contempla dois casos de estudo: overhead devido XtratuM usado como hypervisor com três cenários diferentes; e desempenho da arquitetura de software proposta com uma partição dedicada as operações de I/O e dois cenários diferentes. Os resultados obtidos mostram que o overhead máximo de uma aplicação distribuída sobre XtratuM é inferior a 60 µs. No caso da operação distribuída via DDS foi obtido um tempo máximo de 4157 µs para sistema particionado. Um teste adicional considerando diferentes workloads (tamanho de imagem) mostrou que o hypervisor contribui com um overhead mínimo comparado com o cenário com DDS e sistema particionado, independente da carga (payload).

3.3.4 Comentários

Para mapeamento CORBA, o trabalho (Sanz, 2002) serve como referência para mapear ACSI-CORBA, além de destacar algumas deficiências e falhas da norma IEC 61850. A maior contribuição desse trabalho é a questão relevante sobre qual abordagem (nível de mapeamento) adotar no mapeamento. O trabalho (Ozansoy, et al., 2004) apresenta conceitos da norma, mas aborda o mapeamento em si de forma mais superficial. Em (Ozansoy, et al., 2004) destaque para a figura do modelo conceitual que ilustra bem o relacionamento entre objetos do modelo de informação e classes da ACSI. Os detalhes básicos do mapeamento adotado não ajudam muito a entender a solução implementada. Em ambiente SOA, o trabalho (Pedersen, 2010) descreve de maneira simples e clara como é possível considerar o uso de solução tipo SOA usando Web Services com REST para o mapeamento da norma IEC 61850 no domínio de aplicação DER. No caso do padrão DDS, o trabalho (Bi, et al., 2013) apresenta importantes detalhes do padrão em si, mostra detalhes do mapeamento, com figuras do modelo de dados e comunicação, e apresenta um benchmark de teste. (Calvo, et al., 2012) 63 tem uma referência bem completa para mapear ACSI-DDS. (Pérez, et al., 2013) mostra a possibilidade do DDS ser aplicado até o nível de sistemas embarcados, criando efetivamente uma solução mais integrada. (Foster, 2015) corrobora com esse cenário mais positivo para uso do DDS. No contexto mais amplo de IoT (Internet of Things), o trabalho destaca que o conceito de Internet Industrial é definido por dois componentes chave: (1) a conexão de sensores e atuadores de máquinas industriais a processamento local e à Internet; e (2) a conexão adiante (onward) para outras importantes redes industriais que podem gerar valor independentemente. Dentre as diversas tecnologias de mensagens existentes, um pequeno subconjunto está emergindo com capacidade de potencializar a futura Internet Industrial, como DDS e REST. O trabalho compara e contrasta as características arquiteturais chaves de cada paradigma e fornece um contexto para a escolha da tecnologia mais apropriada para suportar os requisitos de um determinado tipo de sistema.

64

4 ASPECTOS DE TEMPO REAL

Os aspectos de desempenho e tempo real são inerentes ao domínio de aplicação de sistemas PAC. Para garantir os requisitos exigidos pelas aplicações PAC, o desenho da arquitetura precisa oferecer desempenho compatível e contemplar facilidades para avaliar o desempenho da infraestrutura subjacente como um todo. O objetivo deste capítulo é levantar as informações da bibliografia encontrada sobre esses assuntos para auxiliar a escolha dessas implementações a serem usadas no desenho da arquitetura proposta, definir um estudo de caso para o qual serão gerados cenários de teste e definir uma forma para avaliar o desempenho do sistema PAC implementado.

4.1 CONCEITOS BÁSICOS

Neste contexto, convêm rever primeiramente os conceitos básicos de tempo real crítico (hard real-time), firme (firm real-time) e leve (soft real-time), pois são fundamentais e usados frequentemente daqui em diante. Segundo 7, o conceito básico de tempo real é atender o requisito principal de deadline, ou tempo limite para que uma tarefa (task) ou trabalho (job) de tempo real seja completado. Tempo real crítico considera qualquer perda de deadline como uma falha do sistema, caraterístico de sistemas de missão crítica no qual falhas para atender os requisitos de tempo podem resultar em danos a ativos, infraestrutura e até perdas humanas. Um exemplo seria um blackout no sistema elétrico devido à falha na atuação de algum sistema de proteção, ou um desastre aéreo devido alguma falha no sistema de controle do avião. Tempo real leve permite a perda frequente de deadlines, e desde que as tarefas sejam executadas em tempo hábil, seus resultados continuem a ter um valor. Tarefas completadas podem ter valor constante até o deadline e valor decrescente caso perdido o deadline. Vê-se, portanto, um conceito de qualidade associado à conclusão da tarefa como um requisito da aplicação. Serviços de stream de vídeo e áudio seriam bons exemplos.

7 https://stackoverflow.com/questions/17308956/differences-between-hard-real-time-soft-real-time-and-firm-real-time 65

Tempo real firme, por outro lado, permite também a perda de deadlines, mas com baixa frequência. Em aplicações deste tipo o sistema pode tolerar falhas de tarefas desde que estas falhas sejam adequadamente espaçadas no tempo. Contudo, o valor da conclusão da tarefa cai à zero, é nulo, ou torna-se impossível, ou seja, resultado é inválido. Linhas de produção de manufatura onde a perda de deadline resulta em uma peça montada com defeito, e com baixa frequência ou recorrência suficiente para ser pego pelo controle de qualidade, não ocasionaria uma parada de produção.

4.2 REVISÃO VIRTUALIZAÇÃO E TEMPO REAL

O domínio de aplicação desse trabalho de doutorado coberto pela norma IEC 61850 e SEPs não é, até o momento e até onde a pesquisa bibliográfica pode avançar com os critérios de busca utilizados, explorado de maneira explícita e específica em trabalhos que visam avaliar o desempenho de sistemas de automação dessa natureza em ambiente virtual. Os critérios usados na pesquisa bibliográfica permitiram encontrar trabalhos correlatos em domínios de aplicação diferentes e focos mais específicos nos padrões, tecnologias e particularmente tendências, como microhypersivors, obtidos em boa parte de referências citadas no material inicialmente obtido. Os critérios de pesquisa consideraram basicamente palavras chave como virtualização, nuvem, ambiente virtual, computação em nuvem, hypervisor, VM, tempo real, desempenho, QoS, SLA (Service Level Agreement), sistemas distribuídos, middleware, DDS, sistemas PAC, norma IEC 61850, e uma combinação das mesmas. O resultado dessa pesquisa bibliográfica, baseado nos próprios critérios ou temas de busca utilizados, permitiu encontrar trabalhos que abordam de maneira mais direta a virtualização e tempo real, bem como outros que abordam mais especificamente microkernels, microvisors, hypervisors, e ainda desempenho e QoS. O nível de detalhes das revisões tem por objetivo apresentar melhor os diversos conceitos e informações encontradas e destacar a complexidade do tema.

66

4.2.1 Desafios da Virtualização em Tempo Real (García-Valls, et al., 2014)

O trabalho (García-Valls, et al., 2014) busca identificar os desafios técnicos para suportar aplicações de tempo real em nuvem, fazendo um survey dos avanços recentes nas tecnologias de virtualização e computação em nuvem para tempo real, oferecendo direções de pesquisa que tornem possíveis aplicações de tempo real baseadas em nuvem no futuro. Os autores destacam o fato de que a evolução tecnológica em comunicações está possibilitando uma mudança inevitável em direção a modelos de computação distribuída. Mais especificamente, computação em nuvem está possibilitando a próxima geração de serviços de computação, fortemente orientada para computação massivamente distribuída e on-line, bem como permitir um novo modelo de Computação de Alto Desempenho (HPC – High Performance Computing) sob demanda. Os autores argumentam que à medida que novos domínios de aplicação entram progressivamente no mundo de nuvem, também é esperado que sistemas de tempo real se movam nessa direção, sendo a virtualização uma das principais tecnologias que está possibilitando essa mudança de paradigma na computação, particularmente a virtualização da máquina. Neste caso, em um ambiente de Computação em Nuvem de Alto Desempenho (HPCC – High Performance Cloud Computing), as aplicações têm requisitos temporais mais rígidos, de tal forma que características de desempenho, como garantias de recursos e provisionamento rápido de resultados, tornam-se críticas. Considerando a complexidade do problema, uma vez que a tecnologia de computação em nuvem não é, em sua origem, direcionada para aplicações de tempo real crítico, o trabalho foca nos desafios relevantes para aplicar tecnologias de computação em nuvem em aplicações de tempo real leve. Para aplicações de tempo real leve, foco do trabalho, os autores afirmam que a integração de políticas de escalonamento de tempo real nas plataformas de virtualização produzem benefícios diretos de uma forma hierárquica, podendo-se evitar o caminho de ignorar (bypass) o software de virtualização expondo 67 diretamente o hardware, como normalmente fazem as soluções de hypervisors de tempo real preocupadas em preservar a isolação temporal e o determinismo. Dessa forma, existe uma necessidade crescente por técnicas de virtualização em tempo real, possibilitando a existência de máquinas virtuais de tempo real (RT-VMs). Na perspectiva geral de computação em nuvem, RT-VM seria a tecnologia que possibilitaria aplicações virtualizadas atenderem restrições de QoS conforme requisitos formalizados em SLAs apropriadas. Segundo os autores, embora QoS em SLAs reais ainda seja quase um mito, a situação está mudando rapidamente. Os desafios para integrar tempo real em virtualização estão relacionados especificamente ao papel e desenho de um hypervisor de tempo real. Mais especificamente: (1) tradução de interrupções pelo hypervisor; (2) acesso ao tempo (temporizadores e relógio); (3) escalonamento de múltiplas vCPUs nas CPUs físicas; e (4) imprevisibilidade do desempenho da rede. As VMs precisam ser escalonadas para execução de uma maneira similar a que threads são escalonadas pelo SO. Sobre desafios de rede em ambientes de computação em nuvem, o tráfego de rede e a natureza dos protocolos de rede exibem um comportamento específico que não garante previsibilidade total, sendo usado QoS. Para exemplificar soluções de integração de suporte a tempo real, os autores apresentam algumas abordagens: (1) escalonamento de máquina virtual em tempo real; e (2) comunicação em tempo real. Por fim, os autores discutem sobre o direcionamento futuro dos trabalhos de pesquisa em computação em nuvem a partir de diferentes perspectivas: (1) tempo real distribuído; (2) suporte a carga de trabalho intensiva em dados e Big-Data; e (3) virtualização de funções de rede. Os autores citam desafios como: permitir, na mesma VM, coexistência de jobs com garantias de isolação temporal e espacial; migração em tempo real de VMs contendo aplicações de tempo real que são transferidas entre diferentes servidores físicos; garantir o nível desejado de isolação de desempenho na presença de cargas de trabalho intensivas em dados; e virtualização de rede com tecnologias de nuvem em ambientes de tempo real. Os autores concluem que a fusão da computação em nuvem com tempo real é um problema complexo que exige tecnologias de virtualização em tempo real para

68 consolidar as características de previsibilidade que poderão ser oferecidas no futuro. A previsibilidade ainda é desafiada pelas capacidades limitadas oferecidas ao software de tempo real para acesso aos recursos de hardware, como as latências de comunicação em nós distribuídos devido o uso dominante de protocolos de Internet que são executados em pilhas de software grandes e pesadas.

4.2.2 Questões de Tempo Real na Virtualização de Sistemas Embarcados (Gu, et al., 2012)

O trabalho (Gu, et al., 2012) apresenta um survey de questões de tempo real em virtualização para sistemas embarcados. Os autores reforçam logo de início que comparado a sistemas corporativos convencionais, virtualização em sistemas embarcados deve ter forte ênfase em questões como desempenho em tempo real, segurança e confiabilidade. O trabalho discute desde soluções de tempo real crítico para sistemas de missão crítica, a soluções baseadas no Xen, KVM e microkernel L4, incluindo duas seções especiais. Em virtualização de tempo real crítico, destaca-se o padrão ARINC-653 projetado para aplicações de missão crítica em aviação, no qual cada partição (VM) é alocada uma fatia de tempo e escalonada de um modo similar a TDMA, e para a arquitetura MILS (Multiple Independent Levels of Security) que define quatro camadas conceituais de separação: kernel e hardware; serviços de middleware; aplicações confiáveis; e comunicações distribuídas. Para soluções baseadas no Xen os autores discutem os algoritmos de escalonamento existentes e as várias modificações feitas para tentar remover limitações de tempo real. Para soluções baseadas no KVM, solução de virtualização Tipo-2 que utiliza o Linux como host SO, qualquer melhoria de tempo real aplicada ao kernel do Linux host SO se traduz diretamente em melhorias de tempo real para a VMM KVM. Dentre as melhorias de tempo real do KVM apresentadas, destaque para o RESCH (REal-time SCHeduler framework) que permite implementar novos algoritmos de escalonamento no Linux sem modificar o kernel. No caso de soluções baseadas em microkernel, L4 é o SO mais representativo, estendido para ser uma arquitetura de virtualização Tipo-1. 69

O survey aborda também a virtualização de SO que permite particionar um ambiente do SO em múltiplos domínios com espaços de nomes independentes para alcançar certo nível de segurança e proteção entre diferentes domínios. Como seções especiais, o survey discute ainda dois tópicos relevantes: escalonamento no nível de tarefa (task-grain scheduling) e o problema de Lock-Holder Preemption (LHP). Os autores terminam o survey apresentando diversas técnicas que seguem duas abordagens gerais para endereçar o problema de LHP: (1) prevenindo que ocorra; ou (2) mitigando após detectar que ocorreu.

4.2.3 Virtualização e Computação em Nuvem em Tempo Real (Xi, 2014)

O trabalho de dissertação (Xi, 2014) destaca três tendências principais no desenvolvimento de complexos sistemas embarcados de tempo real: (1) redução de custo e maior flexibilidade através das tecnologias de virtualização; (2) uso crescente de processadores de múltiplos núcleos em sistemas de tempo real; e (3) avaliação da viabilidade de implantação de aplicações de tempo real como máquinas virtuais em nuvens públicas. Neste contexto, a integração de sistemas de tempo real como VMs sobre plataformas multi-core em nuvem pública levanta novos desafios significativos de pesquisa para atender os requisitos de tempo real das aplicações. O trabalho contempla o RT-Xen, RT-Xen 2.0, RT-OpenStack e RTCA (Real Time Communication Architecture). O autor apresenta dois motivos para combinar aplicações de tempo real e virtualização: (1) consolidação do sistema e consequente otimização de recursos; e (2) poder de computação fornecido pela nuvem, tornando-se um atrativo para tarefas de tempo real de computação intensiva. Segundo o autor, escalonamento em tempo real em ambiente virtualizado ainda permanece uma questão em aberto. RT-Xen é o componente principal do trabalho. Construído sobre a teoria de escalonamento em tempo real composicional, RT-Xen implementa um conjunto de escalonadores de tempo real, incluindo escalonamento global e multi-core particionado, políticas de prioridade fixa e dinâmica, e diferentes esquemas de gerenciamento de cotas (budget).

70

RT-OpenStack integra o RT-Xen com o sistema de gerenciamento de nuvem OpenStack através de interfaces de tempo real, focando no problema de co- hospedar em nuvem VMs de tempo real com VMs sem tempo real (non real-time). Enquanto RT-Xen e RT-Openstack focam nos recursos de CPU, RTCA foca em fornecer baixa latência para Comunicações Entre Domínios (IDC – Inter-Domain Communications), ou VMs, de alta prioridade que compartilham o mesmo host. Combinado com o RT-Xen, RTCA consegue reduzir a latência de milissegundos para microssegundos além de prevenir inversão de prioridade para IDC local. No trabalho, o autor usa domínio para se referir a uma VM, virtual CPU (vCPU) para se referir a um núcleo virtual em um domínio, e physical CPU (pCPU) e núcleo indistintamente para se referir a um núcleo físico real. Na segunda parte do trabalho, o autor explora a virtualização em tempo real em múltiplos processadores (multi-core) com o RT-Xen 2.0. Segundo o autor, na teoria de escalonamento hierárquico para multiprocessador, além do modelo de recurso, existem outras formas de distribuir o budget entre múltiplas vCPUs. A avaliação experimental do RT-Xen 2.0 teve como objetivos: (1) avaliar overhead dos escalonadores; (2) avaliar a escalonabilidade do sistema sob diferentes combinações de escalonadores; (3) avaliar desempenho do sistema em tempo real em condições de sobrecarga; (4) comparar o desempenho dos servidores; e (5) avaliar o impacto da cache nos escalonadores global e particionado. Na terceira parte do trabalho, o autor explora a computação em nuvem em tempo real com o RT-OpenStack. O autor argumenta que aplicar o RT-Xen 2.0 diretamente em uma nuvem causa uma subutilização do host, e VMs sem tempo real reduzem ainda mais a utilização de recursos. Os resultados obtidos mostram que o RT-OpenStack pode suportar garantias de latência para VMs de tempo real, e ao mesmo tempo deixar que as VMs sem tempo real utilizem completamente os recursos de CPU restantes. Na quarta e última parte do trabalho, o autor aborda comunicação em tempo real com o RTCA, complementando RT-Xen e RT-OpenStack que focam em recursos de CPU para fornecer garantias de tempo real. O autor conclui o trabalho respondendo as quatro questões colocadas no início como proposição para a pesquisa do trabalho, e coloca importantes questões em aberto para pesquisa. A Figura 18 ilustra bem a arquitetura de comunicação implementada no Xen. 71

Figura 18 – Arquitetura de Comunicação do Xen

Fonte: Fig. 5.1 e 5.2 (Xi, 2014)

4.2.4 Impactos de Diferentes Algoritmos de Escalonamento em Serviços Web (Li, et al., 2013)

O trabalho (Li, et al., 2013) apresenta um estudo comparativo dos impactos de diferentes algoritmos de escalonamento em serviços web. Os autores destacam que o tempo de execução fim-a-fim é amplamente visto como uma métrica chave de qualidade de fluxos de trabalho (workflows) de serviços web. Como reduzir esse tempo, afetado por diversos fatores, é uma questão importante. Algoritmo de escalonamento é um fator em particular. Como os serviços web são compartilhados por mais de um workflow, é preciso utilizar uma estratégia de escalonamento apropriada em cada serviço para otimizar o tempo de execução fim-a-fim.

72

O trabalho foca no uso de simulações para avaliar os impactos de algoritmos de escalonamento, medindo e comparando o tempo de execução fim-a-fim dos workflows com diferentes algoritmos para poder escolher o melhor algoritmo de escalonamento que pode efetivamente diminuir o tempo máximo e médio de execução fim-a-fim da maioria dos workflows. Os algoritmos de escalonamento avaliados são: FIFO (First In First Out); EDF (Earliest Deadline First); e ESF (Earliest Start Time First). Os resultados das simulações apresentam o melhor e pior resultados obtidos de cada algoritmo comparando-se o máximo e a média, bem como resultados do EDF e ESF relativos ao FIFO. A análise dos resultados indica que o EDF é melhor na diminuição dos tempos de execução fim-a-fim máximo e médio da maior parte dos workflows, e ESF é melhor que o algoritmo FIFO tradicional.

4.2.5 NOVA: Arquitetura de Virtualização Segura baseada em Microhypervisor (Steinberg, et al., 2010)

O trabalho (Steinberg, et al., 2010), embora não aborde a questão de desempenho e tempo real explicitamente, indiretamente apresenta uma forma de evitar grandes e complexas pilhas de virtualização propensas a ataques, o que tende a impactar menos o desempenho final. O trabalho mostra como uma camada fina e simples de virtualização reduz a superfície de ataque e, desse modo, aumenta a segurança geral do sistema. Segundo os autores, apesar do apelo que a virtualização traz com a consolidação de recursos, a segurança de cada Guest-OS passa a depender adicionalmente da segurança da camada de virtualização. Consequentemente, a segurança da virtualização torna-se de fundamental importância. No artigo, os autores descrevem o desenho e implementação do NOVA – uma arquitetura de virtualização segura baseada em componentes pequenos e simples que podem ser independentemente projetados, desenvolvidos e verificados quanto a correção. No sistema projetado, o hypervisor que executa diretamente no hardware é acompanhado de múltiplos VMMs no nível de usuário que gerenciam as interações entre as VMs e os recursos físicos do host. Neste caso, os termos 73 hypervisor e VMM se referem ao kernel no modo privilegiado e ao componente no nível de usuário sem privilégios, respectivamente. O projeto do NOVA compartilha a motivação de um TCB (Trusted Computing Base) pequeno com sistemas baseados em microkernel, que adotam uma abordagem extrema ao princípio de privilégio mínimo através do uso de um kernel pequeno que implementa somente um conjunto mínimo de abstrações. Mais especificamente, três abstrações principais: espaço de endereços; threads; e IPC (Inter-Process Comunication). Funcionalidades adicionais podem ser implementadas no nível de usuário. NOVA considera virtualização total como um objetivo primário, preenchendo o gap entre microkernels tradicionais e hypervisors. Uma comparação do tamanho do TCB do NOVA com outras soluções de virtualização mostra a discrepância existente. Segundo os autores, enquanto NOVA consiste de um microhypervisor de 9 kLOC (Line Of Code), um ambiente de nível de usuário leve de 7 kLOC e o VMM de 20 kLOC, o hypervisor Xen tem cerca de 100 kLOC executando no modo mais privilegiado do processador, enquanto KVM tem aproximadamente 200 kLOC (considerando um kernel de Linux enxuto). Para os componentes principais da arquitetura, os autores descrevem detalhadamente diversos aspectos importantes e mecanismos do projeto. O microhypervisor ou microvisor implementa uma interface de hypercalls baseada em capacidades organizada em torno de cinco tipos diferentes de objetos do kernel: domínios de proteção; contextos de execução; contextos de escalonamento; portais de comunicação entre domínios de proteção; e semáforos. O escalonador implementado é um round-robin preemptivo orientado por prioridade com uma fila de execução por CPU. O microhypervisor mantem um espaço de endereços do host para cada domínio de proteção e uma tabela de paginação de sombra para cada vCPU do sistema. O microhypervisor não contém uma política para alocação de recursos. O gerenciador de partição raiz, primeiro domínio de proteção criado pelo microhypervisor, realiza as decisões iniciais de alocação de recursos. Como qualquer outro domínio de proteção, ele pode criar e destruir novos domínios de proteção e, através da delegação das respectivas capacidades, atribuir recursos. O VMM suporta a execução de Guest-OS sem modificações em uma VM,

74 emula instruções especiais, fornece dispositivos virtuais e gerencia a memória física do guest. Cada dispositivo virtual é modelado como uma máquina de estado de software que imita o comportamento do respectivo dispositivo de hardware. A BIOS, exigida pela maioria dos SOs durante a inicialização, é movida para o VMM, facilitando o acesso direto a dispositivos. O VMM suporta a virtualização de Guest- OS multiprocessador criando a quantidade desejada de vCPUs, mapeando-as para processadores físicos através da atribuição apropriada de contextos de escalonamento. Na parte final, os autores realizam uma avaliação de desempenho do NOVA. Para melhorar a acurácia dos resultados, foram desabilitados Hyper-Threading e Turbo Boost na CPU. De uma forma geral, os autores afirmam que os resultados mostram que o overhead de desempenho da virtualização total em hardware atual pode ser tão baixa quanto 1% para workloads intensivos em memória. E concluem que um resultado interessante do trabalho é que uma arquitetura como a do SO NOVA pode ser construída com overhead de desempenho desprezível, graças aos recentes recursos de virtualização de hardware e cuidadoso desenho e implementação do sistema.

4.2.6 Máquinas Virtuais de Tempo Real (Cucinotta, et al., 2008)

O trabalho (Cucinotta, et al., 2008) aborda o problema de garantia de tempo para aplicações de tempo real executando em SO virtualizado. De acordo com os autores, o problema de oferecer isolação temporal entre múltiplas VMs executando no mesmo host está aberto. A abordagem prevista neste trabalho é utilizar técnicas de escalonamento em tempo real bem estabelecidas e, em particular, reservas de recursos, para o escalonamento de VMs. A ideia é colocar uma reserva RSV = (Q, P) para um componente de software, uma VM neste caso, que reserva o processador por Q unidades de tempo a cada período P para a VM. O escalonador usado é uma variante do CBS (Constant Bandwidth Server) que implementa reservas rígidas, ou seja, não permite que o componente de software servido execute por mais de Q unidades de tempo a cada P. Dessa forma, 75 quando uma VM executa com uma reserva de recurso RSV, a relação Q/P permite controlar a velocidade da vCPU, e o período de reserva P permite controlar a granularidade da alocação de modo que as restrições temporais possam ser respeitadas. Os experimentos realizados para verificar a efetividade do uso de reservas de recursos para aumentar a previsibilidade de componentes de software virtualizados foram feitos executando o KVM no AQuoSA, um framework para kernel Linux que incorpora uma política de escalonamento CBS rígida. Os experimentos consideram a aplicação executando: (1) diretamente no host sem sobrecarga; (2) no guest da instância KVM sem sobrecarga no host; (3) no guest com sobrecarga no host; e (4) no guest com reserva rígida CBS e sobrecarga no host. Os resultados obtidos tabulados com tempo de resposta mínimo, médio, máximo e desvio padrão, mostram variações da ordem de 10 vezes com sobrecarga, ao passo que o uso de reserva com CBS consegue trazer os tempos de resposta bem próximos aos dois primeiros experimentos, mesmo com sobrecarga. Os autores concluem que a isolação temporal oferecida pelo CBS permitiria a fornecedores de serviço oferecerem serviços com garantias de QoS.

4.2.7 Paravirtualizando Linux em um Hypervisor de Tempo Real (Legout, et al., 2012)

O trabalho (Legout, et al., 2012) descreve um novo hypervisor construído no microkernel de tempo real Anaxagoros para executar o Linux em uma máquina virtual. Os autores destacam trabalhos relacionados que executam o Linux sobre um microkernel, como foi feito pelo L4Linux que é um porte do Linux para o microkernel L4, permitindo executar lado a lado tarefas Linux e de tempo real. Anaxagoros, por sua vez, não foi projetado para ser um hypervisor, mas um microkernel seguro para tempo real crítico. Mais especificamente, um kernel de sistema operacional para execução segura de tarefas de criticidade mista de tempo real crítico e sem tempo real em uma única plataforma de hardware. O sistema suporta arquitetura x86. O desenho do kernel foi projetado para ser enxuto e seguro, contando com apenas 2587 linhas de código C e 1155 linhas de assembler x86.

76

Segundo os autores, para garantir a segurança do sistema, no desenho do projeto do hypervisor cada máquina virtual deve estar isolada e não deve interferir com outras tarefas. Para atingir este objetivo, cada máquina virtual é colocada em um domínio próprio, com seu próprio espaço de endereços e sua própria thread de execução. A tarefa root, responsável por criar a máquina virtual, cria o respectivo domínio, espaço de endereços, garantindo assim a isolação entre as VMs. Para avaliar o desempenho, os autores realizaram dois tipos de teste: (1) um para ilustrar o desempenho do hypervisor; e (2) outro para mostrar as propriedades de tempo real do Anaxagoros. Para o primeiro tipo de teste, os resultados do Linux virtualizado são comparados com o Linux executando diretamente no hardware. Na avaliação do tempo real, os resultados mostraram variações significativas (desvio padrão alto) na arquitetura x86. Os autores concluem que o esforço de paravirtualizar o Linux em um sistema de tempo real não foi tão difícil quanto imaginado, e os resultados dos testes de desempenho são satisfatórios.

4.2.8 Genode e TinyCore como Guest-OS

Apesar de não serem desenhados explicitamente para tempo real, devido à concepção de projeto com TCB extremamente reduzida, o Genode (Feske, 2010) pode ser usado como Guest-OS do próprio microvisor Genode/NOVA, e o Tinycore (Kasanen, 2013), versão ultra reduzida do Linux com SO de apenas 15 Mb, pode ser usado como Guest-OS de qualquer solução de virtualização que suporte Linux. Tinycore, como qualquer Linux, ainda pode ser melhorado com a aplicação de um patch de tempo real, como o Preempt-RT8.

4.2.9 Quantificando o Desempenho de Implementações IaaS em Nuvem (Berndt, et al., 2013)

O trabalho (Berndt, et al., 2013) propõe um método para quantificar, determinar e assegurar o desempenho de aplicações em ambiente de nuvem.

8 http://forum.tinycorelinux.net/index.php?topic=9082.0 http://www.cnx-software.com/2013/01/16/understanding-preempt_rt-the-real-time-patch-elce-2012/ http://www.kernel.org/pub/linux/kernel/projects/rt/ 77

Para tornar possível a comparação de soluções de diferentes provedores de nuvem, os autores afirmam que é necessária alguma medida de desempenho unificada que mostre claramente o desempenho que pode ser esperado a partir da implantação de uma VM e que seja apropriada para uso em SLAs. Segundo os autores, o que conta é o desempenho virtualizado. No caso de sistemas de nuvem IaaS, o desempenho do host é dividido entre VMs, e uma parte é perdida para a sobrecarga de virtualização e escalonamento. Em geral, o desempenho de um sistema de computação descreve sua capacidade de realizar um determinado trabalho , em termos de unidades discretas (operações, pedidos, etc), em certo intervalo de tempo . O tempo para realizar uma única unidade de

trabalho é chamado de latência. A razão é chamada throughput. Os autores destacam os requisitos para quantificar, determinar e garantir o desempenho. Os resultados obtidos mostram o desempenho relativo das VMs para cada benchmark em relação ao tempo de execução total do conjunto de benchmarks. Os autores concluem que a visão pessimista do desempenho que pode ser esperado para a implantação de uma VM é apropriada para uso em SLAs, e reduzir a incerteza quanto o desempenho esperado e aumentar a satisfação dos clientes provavelmente vai beneficiar a adoção da nuvem.

4.2.10 Avaliação de Desempenho em Nuvem de Diferentes Configurações de Recursos (Batista, et al., 2014)

O trabalho (Batista, et al., 2014) apresenta experimentos realizados com o objetivo de identificar os recursos computacionais e a quantidade de recursos que devem ser alocados para um determinado cliente em uma nuvem de forma a obter uma utilização de recursos mais apropriada e ganho de desempenho. Os autores argumentam que para oferecer garantias de QoS sem limitar o número de solicitações aceitas, provedores devem ser capazes de ajustar dinamicamente os recursos disponíveis para atender os pedidos. Um mapeamento eficiente entre recursos e aplicações garante um balanceamento de cargas de trabalho (workload), boa utilização de recursos e permite atender níveis de QoS exigidos pelos clientes.

78

Para os autores, o termo QoS representa o conjunto de características do sistema necessárias para alcançar uma determinada funcionalidade, podendo ser descrito também como um conjunto de parâmetros que caracterizam a qualidade de um determinado fluxo de dados, como largura de faixa. Esses parâmetros são atributos de um sistema que podem ser medidos quantitativamente por métricas e usados na definição de níveis de QoS. O trabalho apresenta resultados que consideram diferentes combinações de máquinas virtuais (VMs) executando diferentes cargas de trabalho. Os experimentos iniciais mostrados analisam quais recursos computacionais deveriam ser fornecidos para melhorar o desempenho em nuvem bem como a proporção na qual estes recursos deveriam ser aumentados. Os autores utilizaram o benchmark Apache, que usa a quantidade de pedidos atendidos por segundo como métrica de resposta. Os autores concluem que a correta alocação automática de recursos permite obter um maior balanceamento de carga e melhor uso dos recursos disponíveis, além de ajudar a cumprir os níveis de QoS exigidos pelos clientes.

4.2.11 Análise de Latência Incremental de Sistemas Cyber-Físicos Heterogêneos (Delange, et al., 2014)

O trabalho (Delange, et al., 2014) propõe uma abordagem incremental baseada em modelo para analisar e validar requisitos de tempo de sistemas físico- cibernéticos, fornecendo uma análise de latência a partir de uma especificação de alto nível. Os autores destacam que apesar da importância em validar a latência fim-a- fim de fluxos de dados, a validação da latência de sistemas é normalmente feita no final, após grandes esforços de implementação e integração, sem fornecer qualquer visão durante o processo de concepção para selecionar e desenhar uma arquitetura apropriada que imponha restrições de tempo real. No trabalho, os autores propõem uma abordagem incremental para especificar e validar a latência usando modelos de arquitetura com a linguagem AADL (Architecture and Analysis Design Language), padronizada pela SAE (Society of Automotive Engineers), e utilizando a ferramenta de projeto e análise OS-ATE. 79

Na análise de latência, os autores apresentam alguns detalhes sobre elementos que contribuem (latency contributors) e regras de modelagem que impactam a latência do sistema. No estudo de caso, os autores primeiro estabelecem uma arquitetura funcional que define as várias funções, com as respectivas cotas de latências, especificação dos fluxos fim-a-fim e requisitos de latência. Essa arquitetura preliminar é então refinada em uma arquitetura de tempo de execução. A implementação de software resultante é integrada em duas alternativas: (1) distribuída: cada função é executada em processadores separados conectados por um barramento; e (2) integrada: todas as funções são executadas no mesmo processador mas isoladas uma das outras usando um sistema de partições. O estudo de caso destaca como a implantação e configurações utilizadas impactam na latência fim-a-fim. Os resultados obtidos comprovam o impacto dessas escolhas. Os autores concluem que a abordagem seguida consegue mostrar que, através da utilização de um nível apropriado de abstração, técnicas baseadas em modelo são capazes de encontrar potenciais problemas de projeto sem a necessidade de especificar detalhes internos dos componentes.

4.2.12 QoS em Computação em Nuvem (Ardagna, 2014)

O trabalho (Ardagna, 2014) apresenta uma pesquisa do estado da arte de abordagens de modelagem de QoS apropriados para sistemas em nuvem, considerando os desafios do gerenciamento de QoS, e mais especificamente o problema de alocação de recursos para garantir níveis de serviços em dimensões como desempenho, disponibilidade e confiabilidade. Segundo os autores, QoS denota os níveis de desempenho, confiabilidade e disponibilidade oferecidos por uma aplicação e pela plataforma ou infraestrutura na qual é hospedada. Os acordos de níveis de serviço (SLAs) especificam metas de QoS e penalidades associadas a violações de SLAs. No entanto, plataformas em nuvem complicam significativamente a análise, previsão e garantia de QoS, abrindo espaço para diversas pesquisas que investigam métodos de gerenciamento automático de QoS.

80

A pesquisa foca em trabalhos de modelagem mais recentes de QoS em sistemas em nuvem, contemplando esforços de pesquisa em modelagem de workload, modelagem de sistemas e aplicações para gerenciamento de QoS em nuvem. Na modelagem de workloads, a definição de modelos precisos de carga de trabalho é essencial para garantir boa previsibilidade dos modelos de QoS. O survey apresenta estudos de caracterização e técnicas de modelagem relacionadas. Por exemplo, caracterizações estatísticas de dados empíricos são úteis na modelagem de QoS, sendo vital para estimar valores realistas para parâmetros de modelos de QoS, como variância de largura de banda de rede, tempo de arranque de VMs e probabilidades de falhas de arranque. Os autores destacam que a heterogeneidade de hardware e interferência entre VMs são causas primárias de variabilidade de desempenho. O tamanho da imagem do SO impactaria na variabilidade do tempo de arranque das VMs. Técnicas de previsão de caixa de preta e análise de tendência são normalmente usadas para prever intensidade de tráfego web em diferentes escalas de tempo. Como o problema de modelagem de workload é longe de ser trivial, os autores indicam uma referência (Hoffmann, et al., 2007) que propõem um guia de boas práticas para construir modelos empíricos. Para inferência de workloads, os autores reforçam que a habilidade para quantificar demandas de recursos é um pré-requisito para parametrizar a maioria dos modelos de QoS para aplicações corporativas. Técnicas de inferência fornecem um meio para estimar o perfil de workloads de VMs individuais executando na infraestrutura subjacente, levando em consideração variáveis ocultas devido a falta de informações. Um exemplo são técnicas de regressão que estimam somente a demanda média. Esta técnica é baseada na comparação de métricas de desempenho (e.g, tempo de resposta, throughput e utilização de recursos) previstas por um modelo de desempenho em relação a medições coletadas em um ambiente experimental controlado. Várias abordagens dessa técnica são apresentadas. Na modelagem de sistemas, os autores revisam algumas classes de modelos que podem ser usados para modelar QoS em sistemas em nuvem, como modelos de enfileiramento, redes de Petri e avaliação de confiabilidade. Em modelos de desempenho, sistemas de enfileiramento, redes de enfileiramento e Redes de Enfileiramento em Camadas (LQN – Layered Queuing Network) são apresentados. 81

Em modelos de dependência, são apresentadas redes de Petri, Diagramas de Bloco de Confiabilidade (RBD – Reliability Block Diagram) e árvores de falha para análise de dependência. Redes de Petri, segundos os atuores, são apropriadas para análise de desempenho e dependência de sistemas de computadores. RBD é uma ferramenta popular para análise de confiabilidade de sistemas complexos representados por um conjunto de blocos inter-relacionados e conectados. Árvore de falha também pode ser aplicada para análise de confiabilidade, onde o sistema é representado como uma árvore de componentes inter-relacionados. Se um componente falha, assume-se que o valor lógico é true, e a propagação da falha pode ser estudada através da estrutura da árvore. Em computação em nuvem, redes de Petri são usadas mais para avaliar dependência, árvores de falha vêm sendo usadas para avaliar dependências de serviços em nuvem e seus efeitos na confiabilidade da aplicação. Modelos de serviço caixa preta vem sendo usados na descrição de serviços em termos do tempo de resposta de aplicações SaaS e orquestração de recursos IaaS. Modelos de simulação, como CloudSim, permitem modelar recursos virtualizados em nuvem e workloads e obter estimativas de QoS.

4.3 DDS E TEMPO REAL

O trabalho (Rizano, et al., 2013) avalia o desempenho de três middlewares em termos de latência, escalabilidade e throughput de comunicação. Para o estudo de caso considerado, os autores afirmam que os requisitos de projeto podem ser atendidos adotando-se uma infraestrutura de middleware que implemente funcionalidades publish-subscribe. Um diagrama de arquitetura publish-subcribe ilustra bem os dados (tópicos) trocados entre componentes do sistema com indicação explícita da periodicidade dos tempos envolvidos. Com essas restrições de tempo real, o middleware que implementa o mecanismo publish-subscribe precisa ser previsível e tem de fornecer limites superiores aceitáveis para as latências de comunicação sem comprometer a taxa de transferência (throughput). Ou seja, o middleware precisa ser explicitamente concebido e desenhado para suportar comunicações em tempo real.

82

Segundo os autores, falta ainda uma comparação sistemática de diferentes alternativas de código aberto. O padrão DDS da OMG é uma alternativa de solução juntamente com o padrão RTPS (Real-Time Publish-Subscribe) que define um protocolo no nível da aplicação baseado no UDP/IP e pode ser usado para comunicação em tempo real exigida pelo DDS. Dessa forma, RTPS implementa comunicação em tempo real sobre protocolos de transporte não confiáveis e sem conexão como o UDP, embora TCP também possa ser usado. Os autores avaliam três implementações abertas de middleware: OpenDDS, ORTE e ZeroMQ. OpenDDS, totalmente compatível com o padrão DDS, é uma implementação C++ baseada no CORBA (usando ACE/TAO). ORTE é uma implementação leve em C do protocolo RTPS que não depende de software externo. ZeroMQ, não compatível com qualquer padrão, é uma implementação em C++ que fornece suporte para o paradigma de comunicação publish-subscribe sobre TCP. Para não depender de um middleware específico, os autores desenvolveram uma camada de abstração em C++ que fornece as funcionalidades de publish- subscribe como uma API simplificada. A avaliação de desempenho compara os três middlewares com relação às latências de tempo real média e no pior caso (valor máximo obtido). Os autores concluem que embora ZeroMQ tenha sido o único a respeitar o limite de tempo real no pior caso, o que o tornaria mais apropriado para a aplicação, 99% do tempo as latências medidas ficaram abaixo de 7 ms para todos os três middlewares. O trabalho (Serrano-Torres, et al., 2014) avalia empiricamente o overhead e estabilidade de duas implementações do DDS, OpenSlice e RTI, implantadas em ambiente virtual com o VirtualBox. Na perspectiva de tempo real, os autores sugerem que a teoria tradicional de escalonamento precisa ser revisada para considerar novos modelos. Segundo os autores, uma abordagem muito eficiente para oferecer desempenho em tempo real depende do uso de hypervisors de tempo real, como RT-Xen e XtratuM, ao custo de exigir recompilar o ambiente de execução, ou seja, paravirtualização. O trabalho foca em tempo real não crítico que não exige garantias de tempo estritas e pode usar software de virtualização de propósito geral. O desempenho da comunicação é medido pelos tempos de round-trip de mensagens de diferentes tamanhos e sob diferentes permissões de processamento de CPU. 83

Os experimentos são realizados em duas configurações, com execução diretamente no host e em ambiente virtualizado, e com dois perfis de aplicação, intensiva em rede e CPU. Os resultados apresentam tempos de resposta mínimo, médio e máximo para diferentes tamanhos de mensagem. Em ambiente virtual, RTI tem melhor desempenho que OpenSlice, sendo que o desempenho de ambos se estabiliza conforme as mensagens aumentam de tamanho a partir de 2 kbytes. O trabalho (García-Valls, et al., 2013) segue o trabalho anterior (Serrano- Torres, et al., 2014) e realiza uma análise mais aprofundada do DDS em ambiente virtualizado, fornecendo um benchmark e comparando duas implementações. Os autores citam que não existem muitos estudos públicos independentes sobre o desempenho alcançado por diferentes implementações. No domínio de tempo real crítico, segundo os autores, a previsibilidade oferecida por hypervisors de tempo real é obtida ao custo de ter de recompilar o ambiente de execução, como o XtratuM. Algumas tecnologias de virtualização não oferecem isolação temporal, mas garantias estatísticas. Existem alguns trabalhos com DDS em ambiente virtualizado, porém, nenhum benchmark foi realizado e somente tempos médios foram reportados. Benchmarks de virtualização como VMark e vConsolidate podem ser usados para análise consistente de desempenho de servidores. Contudo, a execução de middleware de comunicação em ambiente virtual não é suportada por um benchmark específico. Para identificar possíveis gargalos, os autores selecionaram um conjunto representativo de testes específicos para obter o comportamento do sistema. Neste caso, o comportamento do sistema é analisado em relação ao uso de recursos físicos (consumo de CPU, largura de banda de rede e memória), estabilidade da execução e carga dos servidores. Os autores destacam que o overhead das camadas de virtualização e middleware de comunicação afetam as principais métricas estatísticas, ou seja, tempos de resposta mínimo, máximo e médio, aumentando o jitter e overhead. Na descrição do benchmark proposto, os autores levam em consideração os seguintes aspectos chave: natureza da aplicação (intensiva em rede ou CPU); paradigma do middleware de comunicação (publish- subscribe); e características do software de virtualização.

84

Os testes realizados consideram um cenário de tempo real não crítico com uma aplicação cliente-servidor executando na infraestrutura do DDS e virtualização com VirtualBox sobre Linux. A implantação é feita em duas máquinas com duas implementações diferentes do DDS: OpenSlice e RTI. Como a infraestrutura de virtualização não é de tempo real, os testes realizados focam no desempenho médio que pode ser apropriado para algumas aplicações de tempo real de melhor esforço (best-effort). Um cenário de pior caso exigiria o uso de um virtualizador e SO de tempo real. Os objetivos da avaliação são: medir o desempenho absoluto da aplicação para diferentes implementações do DDS; avaliar o overhead introduzido pela infraestrutura de virtualização com diferentes implementações do DDS; determinar o overhead absoluto introduzido pela infraestrutura do DDS comparado com mensagens ICMP, considerado aqui como um middleware de comunicação ideal. O primeiro experimento realiza diversos testes para obter o tempo fim-a-fim exigido pela interação cliente-servidor sob diferentes configurações: executando em VM ou diretamente no host; com ICMP ou DDS; e variando tamanho dos dados. O segundo experimento avalia mais especificamente o overhead do DDS. Os resultados mostram, para o DDS, variações significativas devido principalmente ao overhead de serialização e outras abstrações do modelo DDS, em comparação a pilha ICMP. OpenSlice supera o RTI. Com relação à virtualização, os resultados obtidos mostram que para aplicações com deadlines mais apertados, na ordem de 10 ms, a virtualização exige 50% do tempo total disponível, enquanto para deadlines na faixa dos 100 ms este custo cai para 5%, reduzindo para perto de 1% conforme o deadline aumenta, ou seja, o overhead de virtualização vai se tornando mais admissível. Ainda sim, o overhead de virtualização domina em todos os casos testados em relação ao overhead da abstração do middleware. Em todos os testes, o custo da abstração do middleware é tipicamente 30% do tempo total, enquanto o custo da virtualização pode representar até 72% do tempo total. O trabalho (Pérez, et al., 2014) trata da integração da tecnologia DDS sobre os serviços de comunicação do ARINC-653. Segundo os autores, a característica chave da especificação ARINC-653, aplicada na indústria de aviação, é o particionamento, que garante a isolação 85 espacial e temporal entre diferentes partições, de tal forma que um conjunto de aplicações com diferentes níveis de criticidade possam ser executadas em uma mesma plataforma de hardware. A comunicação entre partições é realizada pela troca de mensagens através do uso de canais. Um canal é composto de uma única porta de envio e uma ou mais portas de recepção. Para a integração dos dois padrões, são identificadas algumas questões de incompatibilidade e possíveis soluções, particularmente com relação a modelos de comunicação, protocolos de transporte, esquema de endereçamento, descoberta e mapeamento de entidades. Consequentemente, para lidar com essas restrições impostas por sistemas particionados como o ARINC-653, é necessário aplicar algumas extensões à especificação do DDS. Para avaliação e validação da solução proposta, foi utilizado o hypervisor XtratuM, Guest-OS MaRTE e middleware DDS da RTI para o desenvolvimento de um protótipo como prova de conceito. Interessante observar que o XtratuM foi concebido com características que oferecem isolação espacial e temporal com a (1) alocação de partições para um único espaço de endereço que não é acessível por outras aplicações e (2) através de um escalonador cíclico fixo (executivo cíclico), respectivamente, ou seja, um hypervisor tipo ARINC-653. Os resultados obtidos consideram um sistema particionado estável e estático (processos de inicialização e descoberta completados) no qual as aplicações estão conectadas através dos serviços de comunicação ARINC-653 fornecidos pelo XtratuM. O teste mede a latência de ida e volta (round-trip) de uma operação remota, ou seja, o tempo entre a chamada para publicar os dados e o retorno da operação de leitura, considerando uma carga de dados útil (data payload) de 100 bytes e a execução de 10.000 operações para estimar os tempos médio, máximo e mínimo, juntamente com o desvio padrão e o percentil 99. Dos resultados obtidos para três cenários distintos, a maior parte das medidas encontra-se próxima à média, conforme pode ser deduzido do percentil 99. Os autores concluem que a abordagem seguida fornece dispersão suficientemente baixa para a construção de aplicações previsíveis. O trabalho (Pérez, et al., 2012) apresenta uma análise dos parâmetros de QoS do DDS quando o DDS é usado para construir aplicações reativas normalmente

86 desenhadas sob o paradigma orientado a eventos (event-driven), e mostra como configurar o DDS para obter aplicações previsíveis apropriadas para aplicar técnicas de análise de escalonabilidade tradicionais. Segundo os autores, embora o DDS tenha sido desenhado inicialmente para desenvolver sistemas centrados em dados, é possível aplicar o padrão para sistemas orientados a eventos. O modelo de fluxo fim-a-fim orientado a evento definido pelo padrão MARTE possibilita a modelagem e análise de sistemas distribuídos de tempo real através da teoria de escalonamento tradicional. Mais especificamente, o modelo de fluxo fim-a-fim permite a representação de interações complexas entre as respostas a diferentes sequências de eventos, como as propostas pela especificação do DDS, e a aplicação de técnicas de análise de escalonabilidade para determinar se os requisitos de tempo podem ser atendidos ou não em um sistema distribuído de tempo real. Ferramentas CASE como o MAST facilitam o processo de desenvolvimento para engenheiros de tempo real. Os autores citam um trabalho que conclui que uma aplicação usando o modelo distribuído do DDS pode ser representada como um conjunto de fluxos fim- a-fim. No modelo de tempo real descrito, as operações ativam umas as outras através de eventos internos que podem ser gerados por tarefas ou mensagens. No modelo de distribuição do DDS, os autores destacam alguns pontos importantes: somente entidades pertencentes ao mesmo domínio podem se comunicar; subscribers precisam registrar seu interesse em receber tópicos específicos; e DDS permite a modificação de alguns parâmetros de QoS em tempo de execução como parte de uma reconfiguração dinâmica do sistema. Na descrição dos parâmetros de QoS suportados, os autores dão enfoque somente ao perfil mínimo exigido para qualquer implementação DDS. Com a introdução desses parâmetros, os autores discutem como modelá-los usando o modelo de fluxo fim-a-fim de tempo real. A análise feita assume que o processo de descoberta está concluído e não existem participantes tardios, e considera somente o perfil mínimo de parâmetros e configurações de QoS. São considerados dois tipos diferentes de aplicações de tempo real: (1) sincronizadas onde cada amostra de dados específica tem requisitos de tempo associados; e (2) não sincronizadas, nas quais as operações para obter e processar os dados estão desacopladas, sendo modeladas por dois fluxos fim-a-fim 87 independentes. Com essa base estabelecida, os autores analisam o comportamento das aplicações e a modelagem para cada parâmetro de QoS do perfil mínimo. Por exemplo, o parâmetro Deadline que não define qualquer mecanismo associado para garantir o requisito de tempo, representa apenas um serviço de notificação que precisa ser modelado como um novo fluxo fim-a-fim linear. Os resultados obtidos são apresentados em uma tabela que mostra: os diferentes parâmetros de QoS classificados de acordo com categorias estabelecidas; os valores disponíveis; se estes valores são apropriados para análise de escalonabilidade; e as respectivas entidades de modelagem do fluxo fim-a-fim.

4.4 CONSIDERAÇÕES FINAIS

A diversidade de temas e áreas de conhecimento encontrada nesta revisão mostra a complexidade envolvida na questão de desempenho em ambiente virtualizado e nuvem, mas mostra também a tendência e preocupação real que existem em aproveitar os benefícios dessas tecnologias em prol de sistemas de outros domínios de aplicação além do corporativo, com requisitos mais rígidos de desempenho e tempo real, como automação. (García-Valls, et al., 2014) apresenta um survey que contextualiza bem os desafios para suportar aplicações de tempo real em nuvem, mostrando que o escalonamento hierárquico é uma alternativa viável em hypervisors como o RT-Xen. (Gu, et al., 2012) traz um survey de questões de tempo real, como melhorias de tempo real do KVM com o RESCH e o RT-Xen, versão de tempo real do Xen, além de tópicos especiais como LHP. (Xi, 2014) trata tempo real de questões chave em ambiente virtualizado e nuvem, considerando o RT-Xen, e responde perguntas importantes. (Li, et al., 2013) traz a definição de tempo fim-a-fim de uma métrica avaliando algoritmos de escalonamento em ambiente Web. (Blackham, 2013) leva ao extremo a questão de segurança ao avaliar o desempenho do microkernel sel4 que é verificado formalmente, ou seja, um microkernel com TCB totalmente confiável livre de qualquer falha de software. (Cucinotta, et al., 2008) mostra de forma simples e clara a questão de garantia de isolação temporal com CBS, apresentando modelo de tarefas e WCRT

88 com CDF dos tempos de resposta. (Legout, et al., 2012) apresenta uma proposta de um hypervisor construído sobre um microkernel. (Steinberg, et al., 2010) apresenta a arquitetura com foco em segurança e TCB reduzido do microhypervisor NOVA e resultados contundentes de avaliação de desempenho do sistema, indicando que pesquisas estão sendo feitas para estudar como escalonar recursos de forma mais justa entre VMs e como garantir propriedades de tempo real para as VMs. Para Guest-OS de tempo real não foram pesquisadas referências específicas do tema, mas a ideia de usar um Guest-OS pequeno como Genode ou TinyCore pode contribuir para um melhor desempenho da VM. Sobre desempenho & QoS em ambiente virtualizado, (Berndt, et al., 2013) mostra uma abordagem interessante para normalizar a medição de desempenho e permitir comparar diferentes soluções de nuvem. (Batista, et al., 2014) aborda a questão de provisionamento dinâmico de recursos usando benchmarks e métricas para quantificar recursos computacionais necessários. (Delange, et al., 2014) apresenta um modelo e método de análise de alto nível de requisitos de tempo utilizando a ferramenta de projeto e análise OS-ATE. (Khethavath, et al., 2013) apresenta a ideia de nuvem distribuída. (Ardagna, 2014) apresenta um survey da importância da modelagem de QoS das aplicações. Em DDS e tempo real, (Rizano, et al., 2013) apresenta resultados práticos de experimentos simples que avaliam três soluções distintas de middleware que implementam o paradigma publish-subscribe, dentre elas o OpenDDS. (García-Valls, et al., 2013) propõem um conjunto de testes para compor um benchmark que avalia o desempenho de middlewares de comunicação em ambiente virtualizado, mais especificamente com as implementações OpenSlice e RTI do DDS. (Serrano-Torres, et al., 2014) é um estudo anterior a (García-Valls, et al., 2013) que realiza uma avaliação empírica do DDS em ambiente virtual. (Pérez, et al., 2014) apresenta um método de teste e medição e tratamento estatístico de medições em ambiente com hypervisor XtratuM. (Pérez, et al., 2012) descreve um método e ferramenta CASE usada para modelar o aspecto de tempo real do DDS para aplicações orientadas a evento. Dentro deste contexto, a possibilidade de poder avaliar de forma precisa e atender os requisitos de desempenho de aplicações PAC em ambiente virtualizado e Nuvem é o pano de fundo que motivou todo esse estudo. 89

A complexidade do problema e soluções potenciais mostra o quão difícil é tomar decisões técnicas cujos impactos ainda não são totalmente conhecidos. O estudo aqui levantado servirá de base para as recomendações a serem indicadas buscando amenizar a dificuldade inerente na tomada dessas decisões para o melhor desenho da arquitetura e respectiva avaliação de desempenho à luz das referências encontradas. Somente os resultados de testes serão capazes de elucidar a viabilidade ou potencial da proposta deste trabalho de doutorado.

90

5 CARACTERIZAÇÃO TEMPORAL DE APLICAÇÃO PAC EM AMBIENTE VIRTUALIZADO

Conforme objetivos definidos, a principal contribuição esperada desse trabalho de doutorado é a caracterização temporal de uma aplicação PAC executando em ambiente virtualizado. A estratégia adotada para defesa dessa tese, para mostrar verdadeira a hipótese levantada de ser possível executar aplicações PAC com IEC 61850 em ambiente virtualizado e distribuído, com respeito a requisitos temporais, é através da implementação de um protótipo e avaliação de seu desempenho. De forma empírica, portanto, sem recorrer a avaliações teóricas. Dessa maneira, espera-se poder responder a questão cerne de caracterização temporal que permita verificar se uma aplicação PAC IEC 61850 funcionará em ambiente distribuído e virtualizado como funciona no convencional, ou seja, se o comportamento temporal medido atende o esperado. O objetivo deste capítulo é propor uma forma de realizar essa caracterização temporal.

5.1 CONSIDERAÇÕES INICIAIS

A caracterização temporal a ser proposta neste capítulo está associada à infraestrutura experimental que será apresentada e descrita no capítulo seguinte, não podendo ser extrapolada de maneira generalizada. Conforme objetivos específicos, a caracterização temporal deverá permitir:  determinar o grau de facilidade/dificuldade em atingir os requisitos temporais, através de um protótipo e uso de tecnologias e plataformas disponíveis, de propósito geral; e  indicar os principais gargalos/dificuldades a serem vencidos para obter implementações satisfatórias. Os resultados desta pesquisa apontarão na direção da facilidade para obter os tempos requeridos, na impossibilidade de obtê-los, ou então na identificação de quais aspectos são problemáticos e quais são simples de resolver, sempre no contexto PAC, IEC 61850, DDS e virtualização. 91

5.2 DESAFIOS – QUESTÕES EM ABERTO

Considerando o uso de infraestrutura de virtualização para o desenho da arquitetura proposta, os principais desafios que podem ser antevistos para este trabalho de doutorado, colocados na forma de perguntas, são listados no Quadro 8. Quadro 8 – Desafios Esperados Perguntas Considerações A infraestrutura de rede, Considerando Tempo Real como rápido o suficiente, se for hardware e software de possível definir cenários de teste e medições que possam virtualização, conseguirá garantir um deadline, espera-se poder identificar quais tipos de ter desempenho suficiente aplicações PAC tem potencial para executar em ambiente para atender requisitos de virtualizado. aplicações de Tempo Real de sistema PAC? O que medir e como Da mesma forma que no mundo analógico é possível medir medir? diferentes pontos de um sistema, no mundo digital é importante ter visibilidade do sistema, ou seja, encontrar uma forma mais clara e explícita de medir o fluxo ou caminho dos dados e informações no sistema, e entender o comportamento, desempenho e gargalos da infraestrutura. Como dimensionar a Considerando que seja possível executar determinadas infraestrutura subjacente? aplicações e que seja possível visualizar e medir o fluxo das informações, saber até onde é possível carregar a infraestrutura subjacente representaria um enorme diferencial para engenheiros envolvidos na especificação e gestão de projetos, ou seja, saber fazer o dimensionamento (sizing) da infraestrutura subjacente para um sistema qualquer. Essa tese não tem a pretensão de esgotar o assunto, ou encontrar uma solução definitiva, mas pretende sim responder a essas questões de alguma forma.

5.3 RECOMENDAÇÕES PARA ANÁLISE DE DESEMPENHO

Para análise de desempenho é importante conhecer primeiro os requisitos de desempenho comumente esperados pelas aplicações PAC e definir os critérios que se pretende avaliar. Para auxiliar nas definições necessárias, são apresentadas a seguir algumas referências consideradas relevantes para este trabalho. Com relação a modelagem e benchmark, (García-Valls, et al., 2013) destaca que não existe um benchmark para middleware de comunicação e propõe um benchmark com um conjunto de testes específicos. (Serrano-Torres, et al., 2014)

92 chama a atenção para a necessidade de uma teoria de escalonamento revisada e adaptada para novos modelos. (Ardagna, 2014) destaca a importância de se obter modelos precisos de cargas de trabalhos para se obter boa previsibilidade de modelos de QoS, e consequentemente desempenho em tempo real. (Steinberg, et al., 2010) utiliza uma série de benchmarks para avaliar o desempenho da arquitetura proposta do microhypervisor NOVA. (Hoffmann, et al., 2007), por sua vez, destaca que apesar da proliferação de abordagens empíricas para avaliar a disponibilidade, confiabilidade e tolerância a falhas de sistemas a partir de estudos baseados em medições, a tarefa de saber qual conjunto de passos seguir para modelar e prever com sucesso variáveis de desempenho ou falhas de um sistema de software complexo é não trivial, sujeita a erros, árdua e morosa. O guia de boas práticas proposto pode ser uma ferramenta útil para ajudar a obter um modelo empírico do sistema para melhor estimação e previsão de QoS do sistema final. Com respeito aos requisitos da norma IEC 61850, de maneira mais prática, o trabalho (Hoz León, 2015) apresenta uma importante contribuição para avaliação dos protocolos da norma IEC 61850 com informações técnicas mais detalhadas desses protocolos e mensagens que são relevantes para o escopo dessa tese, pois esses protocolos definem requisitos temporais exigidos pela norma. Em (Chelluri, et al., 2015), com foco no desempenho da rede, os autores apresentam métodos de teste e validação da transmissão de mensagens durante entrega normal de pacotes Ethernet e durante falhas no caminho. Em (Cisco, 2019), referência mais atual que demonstra claramente a importância que a TI está tendo em TA, são apresentados aspectos chave da norma IEC 61850 e desafios para atender os seus requisitos, particularmente com relação a infraestrutura de rede. No âmbito do DDS, (Martinez, 2010) discute medições, estatísticas e gráficos usados para descrever o desempenho do OpenDDS.

5.4 ANÁLISE DE DESEMPENHO

Com base nas recomendações apresentadas anteriormente, é feita uma proposta de análise de desempenho para caraterização temporal dos ambientes propostos a serem testados. A proposta como um todo pode ser considerada um benchmark, baseada fortemente na abordagem recomendada pelo OpenDDS. 93

5.4.1 Características de Tempo

As características de tempo buscadas para os componentes do sistema a ser testado (Figura 25 – Arquitetura em Camadas) estão descritas no Quadro 9. Quadro 9 – Características de Tempo Característica Componentes Tempo Inicialização Hypervisor e VM Tempo Migração VM Latência e Jitter End-to-End ou Round-Trip:  Aplicação PAC – Mensagens GOOSE  DDS Throughtput de rede  Aplicação PAC – Mensagens GOOSE  DDS O tempo de migração de uma VM, embora relevante em um ambiente de Nuvem, não será medido, pois a infraestrutura de experimentação não terá o recurso de vMove. O foco será na latência e jitter da comunicação.

5.4.2 Recursos Computacionais

Monitorar os recursos computacionais pode ajudar a avaliar melhor o comportamento do desempenho. Os recursos monitorados podem ser os principais como em qualquer aplicação de software: CPU; memória; e largura de banda de rede. O uso desses recursos por VM pode ser caracterizado conforme Quadro 10. Quadro 10 – Recursos Computacionais por VM Recurso Medições CPU % de uso médio e máximo Memória Quantidade utilizada média e máxima Rede Throughtput médio e máximo

5.4.3 Requisitos de Desempenho – Perfil de Tempo Real Aplicações PAC

Os requisitos de desempenho desejáveis, baseados na experiência prática e visão do autor dessa tese enquanto atuando no setor de Engenharia de projetos de automação da UHI, estão listados no Quadro 11 a seguir.

94

Quadro 11 – Requisitos de Desempenho – Perfil de Tempo Real Aplicações PAC Requisito Descrição Aplicações de A priori deverá ser possível testar aplicações típicas em SEP como: Tempo Real  SCADA: são aplicações com restrições de tempo de 1 a 2 s;  Sincrofasores: ou medição fasorial com restrições de tempo de até 60 amostras por segundo ou 60 Hz;  Proteção: considerando 80 amostras por ciclo ou 4,8 kHz; e  Oscilografia: considerando até 256 amostras por ciclo ou 15,36 kHz. Sampled Os SMV’s previstos na norma IEC 61850, seja de circuito de proteção ou Measured medição, deverão ser adquiridos pelo sistema com taxas de até 15,36 Values KHz. Pela IEC 61850-9-2(LE), até o momento, essa taxa é de 4,8 kHz (80 amostras por ciclo), capaz de atender aplicações de proteção. No entanto, para aplicações de oscilografia é necessário prever taxa maior. GOOSE Mensagens GOOSE binárias de dados binários do campo e trip deverão ser suportadas pelo sistema. Mensagens de GOOSE analógico devem ser previstas também. Pela norma IEC 61850-5, existe uma referência de simulação em rede Ethernet onde se consegue entregar até 100 mensagens GOOSE com tempo de transferência (end-to-end) de 4 ms. A Figura 20 ilustra bem a interpretação para tempo de transferência. SLA Devem ser previstos níveis de serviço, a exemplo de Service Level Aggreement (SLA) em TI, para poder especificar as exigências ou metas de QoS de aplicações e serviços para os diferentes níveis do processo: Proteção, Controle, Automação, Supervisão e Medição e Instrumentação. Ou seja, é preciso realizar uma modelagem de QoS (Ardagna, 2014).

5.4.4 Requisitos de Desempenho – Norma IEC 61850

Os serviços de comunicação da Norma IEC 61850 definem um mecanismo de comunicação próprio e exigem um comportamento temporal bem particular, o qual deve ser considerado na caracterização temporal. De acordo com o autor (Hoz León, 2015), o modelo GOOSE pode ser utilizado para transmitir informação organizada na forma de datasets, enquanto o modelo GSSE é utilizado para transmitir informação unicamente na forma de cadeias de bits. A entidade chamada de bloco de controle GOOSE, em particular, é a encarregada de coordenar todo o procedimento de comunicação desde o lado do transmissor (IEC 61850-8-1, 2003). O serviço de comunicação GOOSE ganha um incremento na sua confiabilidade ao transmitir periodicamente informações para manter a associação entre as entidades que monitoram a aplicação. Cada mensagem na sequência de transmissão tem um atributo chamado de Time allowed To Live (TTL - tempo permitido para viver) que informa ao receptor o tempo máximo que deve aguardar para receber a próxima mensagem. Na 95 ocorrência de um evento, este tempo é reduzido e gradativamente restituído ao seu valor inicial com cada mensagem transmitida (ver Figura 8). Caso uma mensagem não chegue no tempo especificado pelo TTL, o receptor deve assumir que a conexão foi interrompida. O parâmetro TTL, junto com outro parâmetro chamado de número de sequência (seqNum) evita que o receptor entenda a mensagem como uma mensagem duplicada (IEC 61850-8-1, 2003). Por outro lado, o serviço de comunicação SMV providencia a transmissão de valores amostrados (SV – Sample Value) de maneira organizada e controlada no tempo. Similar ao serviço GOOSE, o serviço SMV está baseado no modelo de associação Multicast e permite a transmissão de informações organizadas na forma de datasets. A grande diferença entre o serviço GOOSE e o SMV é que neste último as mensagens não contêm a mesma informação em transmissões consecutivas. Outra diferença entre esses dois serviços é que no caso do SMV a norma especifica que o produtor deve transmitir as mensagens com uma taxa de amostragem fixa e a informação contida nelas não é genérica e sim valores de tensão e corrente (IEC 61850-9-2, 2003). A norma IEC 61850 completa o processo de modelagem da informação especificando os requisitos temporais que, sob o ponto de vista da aplicação (operações de proteção, controle, monitoramento, etc.), devem ter as mensagens transmitidas entre LNs. O cálculo do tempo de transmissão inicia desde o instante em que o transmissor coloca o conteúdo dos dados na sua fila de transmissão (ta) até o instante em que o receptor extrai os dados da sua fila de recepção (tc), passando pelo canal de comunicação (tb) (IEC-61850-5, 2003), conforme Figura 20 – Definição de Tempo de Transferência. Em (Chelluri, et al., 2015) os autores definem o tempo de transferência especificado para um aplicativo como sendo “o tempo permitido para uma troca de sinais ou dados através de um sistema de comunicação”, correspondendo a “duração do tempo entre a ação de transmissão de um valor a partir do processamento da lógica de um dispositivo até o processamento da lógica dentro de um segundo dispositivo como parte de um aplicativo”, ou seja, , conforme

96

Figura 20. O tempo de transmissão, segundo os autores, é definido como sendo o tempo de transferência mais o tempo da função f2 no destino, cuja duração, segundo os autores, “representa realmente a execução de uma ação como parte de um esquema de proteção ou automação”. Em outras palavras, é a “duração do tempo para publicar a informação do sinal do dispositivo físico 1 (PD1), entregá-lo através de uma mensagem de protocolo, e atuar sobre o mesmo no dispositivo físico 2

(PD2)”. O tempo de trânsito, tb , é definido como sendo a “duração do tempo que leva para a mensagem trafegar através da rede de comunicação". Os autores (Chelluri, et al., 2015) definem ainda o tempo da aplicação como sendo o tempo das funções f1 e f2 mais o tempo de transferência, ou seja, o tempo total desde o instante em que um evento que ocorreu é detectado até sua transmissão ao destino final que reconhece o sinal ou informação e toma a ação programada. Por exemplo, no caso de um evento de curto-circuito no sistema elétrico, o tempo da aplicação (proteção, neste caso) seria a duração do tempo desde o instante em que a falta que ocorreu é detectada pela função f1 de um relé de proteção (PD1), o sinal ou informação de trip é transferido de PD1 pela rede (meio de comunicação) e reconhecido pelo IED do disjuntor (PD2), até que PD2 execute a função f2 programada de abrir o disjuntor e isolar a falta para proteger o sistema. Para este trabalho, serão considerados os termos e as respectivas definições de tempo feitas por (Chelluri, et al., 2015), deixando clara a diferença entre tempo de transferência e tempo de transmissão. Com relação a tipos de mensagens, existem basicamente dois grupos de aplicações que permitem a definição dos tipos de mensagens (Hoz León, 2015):  o grupo formado por aplicações de controle e proteção (P1, P2 e P3); e  o grupo formado por aplicações de medição e estimação de qualidade de energia (M1, M2 e M3). Dependendo do contexto da aplicação, os tipos de mensagens são separados em várias classes de desempenho, conforme Quadro 12 e Quadro 13, considerando um sistema elétrico com frequência de 60 Hz. (Hoz León, 2015) destaca também que a comunicação entre camadas do mesmo dispositivo é considerada ideal (sem limite de largura de banda, sem perda ou corrupção das mensagens, etc.). DDS suporta isso, pois permite usar mecanismo de comunicação via memória compartilhada. 97

Quadro 12 – Classes de Desempenho Taxa Classe Característica Aplicação Amostragem P1 Tempo Transmissão = 10 ms 480 Dados bay distribuição secundária P2 Tempo Transmissão = 3 ms 960 Dados bay transmissão P3 Tempo Transmissão = 3 ms 1920 Dados bay transmissão com sincrofasores M1 Medição até 5º harmônico 1500 Medição qualidade energia residencial M2 Medição até 13º harmônico 4000 Medição qualidade energia industrial M3 Medição até 40º harmônico 12000 Medição qualidade energia sincrofasores Fonte: (Hoz León, 2015) - Quadro 4 (Fonte IEC 61850-5, 2003) Quadro 13 – Tipo de Mensagem e Classe de Desempenho Tipo Classe Requisito Tempo Interface/Aplicação Mensagem Desempenho 1A – Mensagens P1 Tempo transmissão <= 10 ms Rápidas, Trip P2/P3 Tempo transmissão <= 3 ms Interface 3 e 2: comutação disjuntores; trip; estado 1B – Mensagens P1 Tempo transmissão <= 100 ms disjuntores; etc Rápidas, Outras P2/P3 Tempo transmissão <= 20 ms 2 – Mensagens M1, M2, M3 Tempo transmissão <= 100 ms Interface 1: cálculo RMS ; etc Velocidade Média Todas as Interfaces: alarme; 3 – Mensagens N/A Tempo transmissão <= 500 ms medição grandezas não Velocidade Baixa elétricas 4 – Mensagens Ver Quadro 12 Interface 1 e 3: medição digital dados não Classes Desempenho M de grandezas elétricas tratados, Raw 5 – Mensagens N/A Tempo transmissão <= 1000 Interface 2, 3, 4 e 6: Configuração ms transferência de arquivos P1 Diferença sincronia ± 1 ms 6 – Mensagens P2/P3 ± 0,1 ms Todas as Interfaces: Sincronização sincronização de IEDs Tempo M1 ± 4 µs M2/M3 ± 1 µs Interface 6, 4 e 3: baseado 7 – Mensagens mensagens tipo 3 com Comando com N/A N/A informação adicional para Controle Acesso controle acesso (senha) Fonte: (Hoz León, 2015) - Quadro 5 (Fonte IEC 61850-5, 2003) Uma característica importante das mensagens SMV é não ter campos obrigatórios que armazenem informação sobre o tempo em que as amostras são geradas, diferentemente do GOOSE. A norma também assume que a taxa de amostragem é fixa (4800 amostras por segundo para aplicações de proteção e 15360 amostras por segundo para aplicações de medição de energia) e desta forma os campos “smpCnt” e “smpSynch” servem para obter informação de tempo da geração das amostras.

98

Para avaliação dos requisitos temporais, (Hoz León, 2015) desenvolveu um modelo de simulação de Switch de acordo com as exigências dos protocolos especificados pela norma, em especial pelos protocolos IEEE 802.3 e IEEE 802.1q. No modelo, foi incluída também a implementação de políticas de priorização de mensagem para suportar as classes de desempenho especificadas na norma (Quadro 13). As seguintes estatísticas são obtidas para mensagens GOOSE e SMV: quantidade de mensagens recebidas; quantidade de mensagens transmitidas; e end-to-end delay ou latência (Hoz León, 2015). A abordagem apresentada na norma IEC 61850-5 (no seu Anexo I, Cálculo de Desempenho) foi utilizada por (Hoz León, 2015) para definir o estudo de caso descrito no trabalho. Para avaliar o comportamento dos dispositivos modelados no trabalho, foram analisadas as mensagens que trafegam pelo barramento de processo sob o pior caso de operação das subestações escolhidas. Neste contexto, o conjunto SAS/subestação deve passar pelos seguintes quatro estados: seguro; alerta; emergência; e pós-falta. Segundo o autor (Hoz León, 2015), no caso das mensagens SMV, estas podem ser modeladas como tarefas periódicas, dado que a sua taxa de transmissão é fixa (são ativadas com período fixo, Ts). Por outro lado, as mensagens GOOSE, dependendo do estado de operação do sistema de potência (seguro, alerta ou emergência), podem ser consideradas tarefas esporádicas, pois estas são transmitidas com período variável e com um tempo mínimo entre duas transmissões consecutivas (este tempo é especificado pelo parâmetro TTL). Esta variação é chamada de jitter (Ji) e é definida como a diferença entre o menor e o maior tempo utilizado para colocar uma mensagem no buffer de transmissão. O jitter é um parâmetro importante para a correta medição do Ri (Tindell, 1994). Ainda segundo o autor (Hoz León, 2015), para que seja possível afirmar que um dispositivo possui conformidade com os conceitos definidos na norma IEC- 61850, este deve passar por uma série de testes especificados na sua Parte 10 (Capítulo 3). Neste contexto, os IED submetidos aos testes são chamados de DUT (Device Under Test). Como referência, (Hoz León, 2015) apresenta também algumas características gerais e configurações utilizadas pelo autor na rede de comunicação do estudo de caso, destacando o tamanho típico de 161 e 162 bytes de mensagens GOOSE e SMV, respectivamente. 99

Figura 19 – Pilha de Protocolo IEC 61850

Fonte: Figure 2 (Cisco, 2019) No contexto mais específico de infraestrutura de rede para TA, (Cisco, 2019) resume bem alguns pontos importantes da norma e seus desafios do ponto de visa mais prático de projeto. Primeiramente, a pilha de protocolos da norma IEC 61850 é separada sob a perspectiva de tempo real crítico e leve, conforme Figura 19. O Quadro 14 apresenta os requisitos de tempo e rede por tipo de função e mensagem. Quadro 14 – Protocolos IEC 61850 e Requisitos Barramento Tipo de Largura Protocolo Atraso Máx Prioridade Aplicação Comunicação Função/Mensagem Banda Processo 1A Trip Camada 2 < 3 ms Baixa Alta Proteção GOOSE Processo 1B Outro Multicast < 200 ms Baixa Alta Proteção Processo e 2 Velocidade < 100 ms Baixa Média Baixa Controle Subestação Média MMS IP/TCP Processo e 3 Velocidade < 500 ms Baixa Média Baixa Controle Subestação Baixa Processo 4 Dados brutos SMV Camada 2 < 208 ms Alta Alta Processo Multicast Processo e 5 Transferência MMS IP/TCP/FTP < 1000 ms Média Baixa Gerência Subestação Arquivos Processo e 6 Sincronismo Time PTP Baixa Média Alta Fasores, Subestação Tempo Sync (Camada2) SMV Subestação 7 Comando MMS IP Baixa Média Baixa Controle Fonte: Table 2 (Cisco, 2019)

100

Os desafios discutidos incluem: latência e jitter; convergência rápida ou tempo de recuperação após falhas; escalabilidade; e segurança. Latência em camada 2 é mantida em um mínimo pois os switches são projetados para encaminhar quadros (frames) usando pesquisas no nível de hardware. Em camada 3, roteamento, buscas no nível de software e buffers ocasionam latências maiores. A recomendação para lidar com requisitos de baixa latência é utilizar switches com capacidade suficiente de largura de banda e aplicar um modelo de QoS apropriado. Um desenho de QoS bem planejado minimizaria ainda a variação entre quadros/pacotes consecutivos, ou seja, o jitter seria mantido em um mínimo.

5.4.5 Definição de Tempo de Resposta Fim-a-Fim

Para este trabalho de doutorado, será considerado como tempo de resposta o tempo de transferência da Figura 20 conforme definido pela norma IEC 61850. A principal justificativa é que o tempo de transferência é normatizado pela IEC 61850, ou seja, são definidos limites conforme Quadro 12 e Quadro 13. Os tempos das funções f1 e f2 são específicos de cada tipo de aplicação e, portanto, dependem dos requisitos de tempo das mesmas, não sendo normatizados. Throughput e jitter podem ser obtidos também a partir das medições de tempo do DDS para ajudar a balizar e otimizar os ajustes de QoS do DDS. Figura 20 – Definição de Tempo de Transferência

Fonte: Figura 16 (IEC 61850-5) Com o uso do middleware DDS, esse tempo de transferência poderá ser obtido pela medição da latência no próprio DDS, pois o DDS como barramento de 101

comunicação unificado contempla implicitamente os tempos de transmissão ta, tb e tc, ou seja, os tempos de processamento da comunicação de cada lado ou fim, e o tempo de toda a infraestrutura de rede subjacente (tempo de trânsito) e camada de virtualização, ou seja, infraestrutura física e virtual, respectivamente. Do ponto de vista da arquitetura final, os tempos estarão relacionados com os componentes principais, ou seja, o middleware DDS, o Guest-OS, a camada de virtualização e a infraestrutura física propriamente dita. O framework IEC 61850, como camada de aplicação, ficaria de fora desse cômputo, a priori. Portanto, para avaliar melhor, agregaria muito para uma análise poder conseguir medir a parcela da contribuição de cada componente, ainda que o resultado principal seja conhecer o tempo de resposta fim a fim. Matematicamente, pode-se expressar o tempo de resposta como sendo:

(1) sendo:

– tempo fim-a-fim medido pelo DDS

– tempo de cada ponta / fim da camada DDS

– tempo da camada do Guest-OS

– tempo da camada de virtualização (VMM + hypervisor)

– tempo do host (SO + HW)

– tempo da rede Para evitar desvios na sincronização de relógios e facilitar as medições, deve-se considerar o cômputo do tempo de ida e volta (round-trip latency), prática bastante utilizada (Pérez, et al., 2014).

5.4.6 Medição de Desempenho & Tratamento Estatístico

As medições para testar o desempenho do OpenDDS, conforme (Martinez, 2010), incluem valores de: tempo; atrasos (diferença entre dois valores de tempo); quantidade e tamanho dos dados; e parâmetros do sistema. Na medição de tempo, o autor afirma que Linux fornece precisão de microssegundo, suficiente para os testes. Com relação a sincronização de relógios entre sistemas, testes laboratoriais indicam que o drift de relógio é da mesma ordem

102 de magnitude dos atrasos medidos, o que significa que erros devido o skew do relógio podem variar de 0-100%. Para evitar esta fonte de erro, segundo o autor, todas as medições a serem comparadas podem ser feitas usando o mesmo relógio. Medições de intervalo incluem a duração do teste, determinado pela diferença entre o tempo no ponto onde amostras começam a ser enviadas e o tempo no ponto onde a recepção termina. OpenDDS inclui a habilidade de medir intervalos de atraso por hop, sofrendo, porém, do skew de relógios. O atraso de latência, de maneira similar, é a diferença entre duas medidas para amostras individuais: o tempo quando a amostra é construída e enviada e o tempo quando a amostra é recebida. Como os intervalos de latência envolvem mais de um hop, a latência de um único hop é estimada dividindo a medida pelo número de hops, o que estatisticamente resulta em valores ligeiramente diferentes caso fosse possível medir com acurácia o desempenho de um único hop. Estatisticamente, assumindo que as latências são distribuídas normalmente, é possível combinar as variáveis randômicas para estimar o desempenho de um único hop. Matematicamente, avaliando-se os extremos de variáveis correlacionadas e não correlacionadas para dois hops obtém-se: . Mas segundo o autor, a densidade de distribuição para latências tende a ser distorcida para a parte alta e não reflete estatística normal. A distribuição se assemelha mais com a distribuição Rayleigh do que com a distribuição Gaussiana, pois possui um limite inferior fixo (Martinez, 2010). O autor ainda complementa que além da média e variância das medições, os valores extremos, mínimo e máximo, também tendem a não refletir precisamente os valores extremos reais para um único hop. Nos scripts de teste, outras medições feitas durante os testes incluem a quantidade de amostras enviadas e recebidas, o payload em bytes, parâmetros do sistema, como uso de CPU e memória, valendo-se de algumas ferramentas do Linux: comando vmstat é usado para obter parâmetros do sistema; comando top é usado para obter informações de processos individuais; e comando netstat é usado para obter informações de desempenho da rede. Além das medições diretas descritas acima, outros valores podem ser derivados, o que inclui jitter e throughput. O jitter, interpretado normalmente como a 103 variação do atraso entre amostras, nos testes do OpenDDS é simplesmente a diferença nas latências medidas entre amostras consecutivas. As medidas de throughput são derivadas das medições diretas do tempo total gasto para enviar amostras e o total de bytes enviados durante o teste. Na análise estatística dos dados coletados, a tentativa é descrever propriedades das medições de forma concisa. O autor assume medições de uma população descrita por uma distribuição de probabilidade e usa os parâmetros dessa distribuição para resumir os valores, o que resulta em estimativas de: localização (qual o valor mais provável); escala (quão espalhados estão os dados); e formato (quão simétricos são os dados). O autor enfatiza que métodos estatísticos clássicos tendem a ser sensíveis a dados que violam as hipóteses subjacentes, como ser normalmente distribuído. Estimadores estáticos robustos resolvem esta questão tentando produzir valores estimados que não sejam muito afetados por desvios das hipóteses do modelo. Como parte da bancada de testes do OpenDDS, o autor discute scripts de redução de dados como fonte para a análise estatística. Para localização, valores de mediana, estimativa mais robusta que a média aritmética, são obtidos. Para escala, ou espalhamento, podem-se usar métodos clássicos mais comuns como variância ou desvio padrão (medida clássica de dispersão), e algumas outras medidas como faixa (distância entre o valor menor ou mínimo e o maior ou máximo) e MAD (Median Absolute Deviation) que representa a mediana da distância entre cada dado e a mediana do conjunto de dados. Segundo o autor, faixa é uma medida fraca e não é usada. Desvio padrão, apesar de calculado, não é usado por não ser robusto, pois dependente fortemente das hipóteses dos dados serem normalmente distribuídos. Para medidas de jitter a suposição de normalidade é provavelmente justificada, mas para latência não. Dessa forma, MAD é usado por ser uma medida robusta da distribuição dos dados. Para forma, propriedades de pico e assimetria da distribuição são descritas, embora não sejam calculadas. O pico, ou achatamento da curva da função de distribuição de probabilidade, é descrito pela medida chamada curtose, que descreve a contribuição da variância de dados extremos na variância da distribuição.

104

A assimetria é descrita pela medida chamada skewness, cujo valor indica uma cauda longa para direita ou esquerda. Por fim, com relação a distribuição de probabilidade, o autor descreve formas de estimar a distribuição de densidade e sua função acumulada. A estimação de densidade de probabilidade Kernel é um mecanismo analítico para estimar a densidade de probabilidade de um conjunto de dados. Quantil representa uma função de distribuição acumulada, forma generalizada dos mais conhecidos quartil e percentil. Diversos scripts estão disponíveis como parte da bancada de teste de desempenho do OpenDDS, podendo auxiliar na criação de scripts de teste para o ambiente do sistema final.

5.5 CONSIDERAÇÕES FINAIS

O benchmark de teste aqui proposto, por assim dizer, adota uma abordagem mais empírica e fundamentada nos testes de benchmark do OpenDDS, o que do ponto de vista de engenharia de projeto, no entendimento do autor dessa tese, seria suficiente para demonstrar de forma prática a viabilidade ou não da solução proposta. A análise estatística ajuda a caracterizar melhor a natureza variável de um ambiente virtualizado e distribuído. Pode-se considerar mediana como valor mais provável, máximo como aproximação de WCET ou mesmo percentil 95 ou 99. Neste caso, não seria possível garantir deadlines de tarefas ou aplicações de tempo real crítico, mas seria possível atender com algum grau de confiança estatística como o percentil 95 ou 99. Lembrando que o próprio esquema de mensagens GOOSE prevê um mecanismo de constante publicação de mensagem, justamente para oferecer maior confiabilidade da comunicação diante de possíveis falhas da mesma. SMV, por sua vez, a perda do deadline de uma mensagem já não seria tolerável em muitos casos, para não dizer todos. A adoção de uma abordagem mais analítica, baseada em modelos, poderia agregar um referencial teórico, cuja efetividade poderia ser avaliada contrastando com resultados empíricos. De outra forma, uma vez definidos tempos limites, seria possível aplicar algum teste de escalonabilidade, por exemplo. 105

Como o interesse maior é verificar na prática o desempenho real, as medições permitem retratar mais fielmente e com maior confiança a caraterização temporal. Por isso, o benchmark proposto pode ser considerado uma forma eficaz de caracterização temporal, sem esconder suas limitações e deficiências que podem ser compensadas ou amenizadas quanto mais condições de teste forem avaliadas. Ou seja, avaliando-se condições mais severas como avalanche, sobrecarga, falhas de hardware, por exemplo, permitiria obter uma caracterização final cada vez melhor, buscando encontrar situações limites. Com relação à hipótese de tese levantada, deve ser possível executar aplicações PAC com IEC 61850 em ambiente virtualizado e distribuído, no que diz respeito a requisitos temporais. A implementação de um protótipo e avaliação de seu desempenho através da infraestrutura de experimentação a ser proposta no próximo capítulo, deverá permitir responder a esta questão ao final do doutorado, embora não seja esperada, obviamente, uma resposta simples do tipo sim ou não, mas sim uma identificação de limites, até que tipo de aplicação é viável (vide Quadro 11 – Requisitos de Desempenho – Perfil de Tempo Real Aplicações PAC), a partir de que tipo de aplicação fica improvável. Como a infraestrutura experimental que será usada é montada de forma ad hoc, caso a mesma apresente resultados de tempos não satisfatórios, será necessário analisar se a dificuldade é inerente ao IEC 61850 com virtualização, ou seja, se outra infraestrutura experimental mais apropriada para o contexto pretendido poderia ter atendido os requisitos temporais. Esta análise será subjetiva, mas ainda assim uma informação relevante.

106

6 ARQUITETURA DISTRIBUÍDA E VIRTUALIZADA PARA EXPERIMENTAÇÃO

Este capítulo define a arquitetura a ser seguida como base conceitual para construção da infraestrutura de experimentação.

6.1 CONSIDERAÇÕES INICIAIS

No trabalho (Mendes, 2011), o autor descreve de forma bem prática o domínio de aplicação considerado nesse trabalho de doutorado, com recomendações e requisitos que corroboram para fundamentar o porquê da escolha da norma IEC 61850 e que servem de referência para decisões a serem tomadas no desenho da arquitetura para implementação de aplicações PAC. Segundo o autor, a adoção da norma IEC 61850 é uma possível solução para atender duas características básicas que um sistema deve ter: ser padronizado e aberto. A adoção da norma, espera-se, proporcionaria “flexibilidade para manter o sistema operando adequadamente por muito tempo, permitindo realizar modificações, ajustes e futuras extensões sem depender de dispositivos ou equipamentos específicos”. O autor destaca que a “imposição de uso da comunicação por redes em todos os níveis do sistema de automação é a característica da norma que terá maior influência no projeto”. Por sistema aberto, o autor define que são sistemas que “usam padrões livremente disponíveis para utilização, geralmente independentes da tecnologia de hardware”. A abertura dos sistemas, segundo o autor, “está associada à facilidade para substituir o hardware e modificar o software”, ainda mais considerando que no pequeno tempo de vida dos sistemas digitais (autor usa o termo sistemas numéricos9) o software tende a evoluir mais rapidamente que o hardware. Esta característica desejável em sistemas atuais ou modernos10, de acordo com o autor, corrobora com a investigação neste trabalho de doutorado do uso de

9 2ª geração de sistemas de automação elétrica baseada em dispositivos digitais microprocessados e em redes de comunicação de dados no nível de estação e unidade 10 3ª geração de sistemas que têm as características de sistemas numéricos usando hardware comum em vez de dispositivos dedicados por função e são totalmente digitais e fazem uso intenso de redes de comunicação 107 ambientes virtualizados e distribuídos para alcançar a “abertura” através do desacoplamento do software e hardware. O autor afirma que o uso de hardware comum permitiria reduzir o número de peças sobressalentes necessárias na tecnologia moderna, mas na prática isso ainda não ocorre, pois “os fornecedores ainda têm dispositivos de famílias e modelos distintos e a tendência de harware comum por enquanto se restringe a algumas placas”. O uso de arquitetura x86, por exemplo, destaca-se como diferencial para uso como hardware comum, mais um bom motivo para avaliação de ambientes virtualizados. O autor completa dizendo que “um dos propósitos de se utilizar padrões abertos é alcançar a interoperabilidade11 (e quiça a intercambiabilidade12)”, premissa de projeto e principal objetivo da IEC 61850. Na prática, “dispositivos comercialmente disponíveis ainda não são interoperáveis de fato”. “O ideal seria a intercambiabilidade”, mas “infelizmente a intercambiabilidade mais ampla está longe de ser uma realidade”. A maior abstração e flexibilidade trazida pela virtualização e middlewares de comunicação podem mais uma vez ajudar a alcançar estes propósitos. No caso da padronização, o autor afirma que a mesma oferece vários benefícios, sendo um deles o de contribuir para o longo tempo de vida do sistema, e está fortemente presente na IEC 61850 para a modelagem do sistema. Sobre requisitos de sistemas de automação modernos, o autor faz uma importante colocação: “de nada adianta um sistema que tenha as funcionalidades (atende os requisitos funcionais), mas não faça no tempo necessário (não atende os requisitos de desempenho) ou não seja confiável e seguro (não atenda os requisitos de confiabilidade e segurança), e vice-versa”. Este trabalho de doutorado busca avaliar dois destes pontos: um sistema funcional que tenha desempenho temporal aceitável.

11 Depende da padronização da comunicação, que inclui a sintaxe e a semântica dos dados. Garante acessibilidade aos dados e funções dos dispositivos. Base para a intercambialidade. 12 Ou padronização em todos os sentidos, com a possibilidade de substituir um dispositivo por outro diferente sem necessidade de grandes ajustes (mantendo os demais componentes do sistema) e o sistema continuar cumprindo as funções para as quais ele foi projetado.

108

Mais especificamente, o autor destaca que a IEC 61850 não altera a funcionalidade básica do sistema, não padroniza as funções. “É requerido apenas que toda a comunicação entre as funções seja feita de acordo com a IEC 61850, usando os modelos de dados nela definidos”, ou seja, interoperabilidade. Aqui se destaca o foco na comunicação: o quê (modelo de dados) e como (modelo comunicação propriamente dito) para troca de dados. No contexto da proposta deste trabalho de doutorado, um framework IEC 61850 e um middleware de comunicação atenderiam estes dois pontos, respectivamente. Todas as funcionalidades do sistema, segundo o autor, devem ser especificadas sem referência à forma de realização, ou seja, uso de abstração para que a realização ou implementação seja independente dos dispositivos e equipamentos, oferecendo maior liberdade na escolha de componentes e tecnologias. Vê-se, portanto, a importância em definir interfaces e camadas que permitam blindar e abstrair a especificação da implementação. No caso de funções, o autor afirma que “uma das características marcantes da IEC 61850 é a capacidade de utilizar funções distribuídas”, possibilitando assim o uso de arquiteturas descentralizadas com inteligência do sistema distribuída, sem necessidade de coordenação de dispositivos centrais. Essa característica da norma reforça a possibilidade de avaliar o uso de sistemas distribuídos. O autor prossegue enfatizando que “é fundamental a existência da rede de processo” para a realização da arquitetura distribuída, com um “ganho adicional: facilidade para maior tempo de vida do sistema (uma premissa básica)”. Neste ponto fica claro que é preciso destacar na proposta da arquitetura a interface com o processo em si, fronteira entre o quê pode ou não ser virtualizado. Ou seja, Merging Units ou PIUs. No final pode haver uma rede de processo no plano virtual que faria interface com a rede de processo física, interligadas pelas PIUs. As PIUs como pontes entre físico e virtual. Ainda segundo o autor, “essa rede de processo deve ser fortemente padronizada e aberta. Isso reduz a necessidade de conversão de dados entre todos os níveis do sistema de automação”, ou seja, uso de gateways e impacto maior na confiabilidade do sistema. 109

Isso poderia ser atendido com o padrão DDS e a possibilidade de escolha (aberto) do protocolo de comunicação ou transporte: tcp; raw socket; udp; etc. Ou seja, um barramento de comunicação único. Por outro lado, o autor afirma que “com a distribuição de funções, a rede de comunicação torna-se um recurso crítico”. Neste caso, as ideias de Virtual Appliance, VM Affinity, vMove, tornam-se importantes, pois componetizando dessa forma tem-se o granho de poder configurar a distribuição das funções de maneira mais flexível e simplificada: bastaria mover VMs diante de falhas na infraestrutura subjacente. Além disso, a flexibilidade de poder construir redes virtuais permitiria virtualmente criar qualquer cenário que se deseje. O sincronismo de tempo é outro ponto fundamental destacado pelo autor para gerar as sequências de eventos, e para sincronizar os dispositivos envolvidos. Embora fundamental, a priori não será necessário usar sincronismo, pois será utilizada uma infraestrutura simplificada para testes. O foco não é a rede em si, apesar de parte crítica do sistema como já enfatizado. O foco é no software da aplicação e desempenho do barramento de comunicação, baseado no middleware de comunicação, e da camada de virtualização. Com relação a desempenho, o autor afirma que o “requisito básico de desempenho para o sistema de automação elétrica moderno é que ele seja no mínimo igual ao desempenho dos sistemas convencionais”, com os valores de desempenho definidos de acordo com a funcionalidade. Por ser um ponto central dessa tese, os detalhes de desempenho foram discutidos no capítulo 5 CARACTERIZAÇÃO TEMPORAL DE APLICAÇÃO PAC EM AMBIENTE VIRTUALIZADO, seção 5.4.4. Como destaque, o autor afirma que os “requisitos de desempenho devem ser especificados por grupos de funções considerando o pior caso (mais crítico)”, sendo importante também “especificar os tempos de transmissão de dados na rede aceitáveis durante uma condição avalanche, principalmente para os grandes sistemas”. Outro ponto abordado pelo autor é “a confiabilidade, a manutenibilidade, a disponibilidade e a segurança” como “requisitos fundamentais nos sistemas

110 industriais das empresas de energia elétrica”, fora do escopo dessa tese. No entanto, vale destacar a facilidade de arranjos que a virtualização proporciona, e fundamentalmente a questão chave de um ambiente em Nuvem que entrega tudo isso de forma intrínseca (vMove, etc). Mais especificamente, o autor discorre sobre redundância, afirmando que “dispositivos redundantes devem trabalhar “a quente” (ou em “hot stand-by”), com tempos de comutação (failover) preferencialmente nulos”. Com relação a montagem e instalação, o autor diz que “para que a redundância seja efetiva, o ideal é que exista separação física entre os componentes redundantes”, instalando-os em gabinetes ou painéis diferentes, salas diferentes, com cabeamento separado, etc. E a solução como um todo “deve ter bom desempenho de reconfiguração (switch- over)” com tempo preferencialmente nulo em caso de falha da rota principal ou reduzido (no máximo 1,0 ms) para uma configuração alternativa. Mais uma vez, embora fundamentais em aplicações práticas, esses pontos também estão fora do escopo desse trabalho de doutorado. Por fim, mas não menos importante, o autor destaca que “desde o início do projeto, já se deve pensar na redundância funcional”, e “tomar cuidado para que a redundância excessiva não torne o sistema muito complexo e acabe gerando outros problemas”. Nesse sentido, o uso de Virtual Appliances com algum mecanismo de failover torna-se mais facilitado. O uso de um middleware de comunicação como o DDS também facilitaria, podendo-se usar um tópico de HeartBeat ou flag simples. Uma solução assim, além de mais robusta, enriqueceria a arquitetura final.

6.1.1 Pirâmide de Automação

A pirâmide de automação é uma forma comumente utilizada para mostrar os níveis de automação normalmente aplicados para um determinado domínio de aplicação, guiando o processo de desenho da arquitetura de automação de uma planta com a divisão em níveis e facilitando sobremaneira o entendimento e a comunicação para discussão técnica e tomada de decisão entre diferentes níveis da organização. 111

Cada nível, em particular, representa o papel e o escopo ou abrangência de automação do respectivo nível e, portanto, os tipos de sistemas, equipamentos e dispositivos que compõem o nível e normas e padrões que podem ser aplicados, bem como sua interface com os níveis adjacentes, similar a uma arquitetura em camada. Como arquitetura de referência, (Mendes, 2011) apresenta um modelo para sistemas de automação de grandes usinas hidrelétricas. Como destaque, a “proposta unifica as redes de comunicação dos quatro primeiros níveis dos sistemas de automação” da pirâmide de automação da Figura 21 a seguir. Figura 21 – Níveis do sistema de automação elétrica

Fonte: Fig. 2.4 (Mendes, 2011) No caso do projeto básico de atualização tecnológica (PAT) da usina de ITAIPU (UHI), foram definidos os níveis de automação que serão seguidos na modernização da UHI. Para a subestação da margem direita (SEMD) foram definidos 4 níveis, conforme Quadro 15. Quadro 15 – Níveis de Automação da SEMD Nível Escopo 3 Supervisão e Controle da SEMD (SCADA-SEMD) 2 Supervisão e Controle dos Pátios (SDSC) 1 Supervisão, Controle e Proteção dos Bays (IEDs) 0 Sensores e Atuadores (Merging Unit, TCs, TPs, Disjuntores, Seccionadoras) Para a usina hidrelétrica (UHI) foram definidos 5 níveis, conforme Quadro 16.

112

Quadro 16 – Níveis de Automação da UHI Nível Escopo 4 Supervisão e Controle do Despacho de Carga (EMS) 3 Supervisão e Controle da Usina (SCADA) 2 Supervisão e Controle da Unidade Geradora e da GIS (SDSC) Regulação, Proteção e Controle da Unidade e Auxiliares da Unidade (UACs, 1 PLCs, IEDs, RTUs) 0 Instrumentação (Sensores e Atuadores Inteligentes)

6.1.2 Requisitos dos Usuários

De uma forma geral, conhecidos alguns dos problemas e dificuldades inerentes a um processo de atualização tecnológica, é preciso minimizar o impacto das atualizações, modernizações e expansão de sistemas existentes bem como a instalação de novos sistemas. Ainda que não seja consenso na indústria do setor elétrico, na visão e experiência desse autor, considerando os perfis de Engenharia de projeto, operação, manutenção e integrador, o Quadro 17 apresenta algumas características buscadas em projetos de sistemas PAC. Quadro 17 – Requisitos dos Usuários (Visão do Autor) Usuário Desejos  interfaces claras e bem definidas;  padrões abertos de modelo de dados e comunicação;  planos e procedimentos passo-a-passo de testes; Engenharia de  plataforma integrada de teste com simulação mais próxima das Projeto condições e comportamento dinâmico de campo visando:  testes de aceitação em fábrica (TAF)  ambiente de testes e treinamento em campo  documentação integrada e de alto nível.  interface humano máquina (IHM) mais moderna e pronta para Web e dispositivos móveis e recursos 3D;  flexível para permitir modificações e inclusão de novas funcionalidades; Operação  visibilidade para monitoração de toda a infraestrutura dos ativos do & sistema, buscando identificar pontos e situações de degradação e Manutenção realizar manutenção preditiva, evitando paradas indesejáveis que possam afetar a confiabilidade e disponibilidade do sistema;  integração e acesso fácil aos dados; e  hardware padrão de mercado (arquitetura x86), sem ficar dependente de fabricante e custos muito superiores.  interoperabilidade, flexibilidade e configuração unificada e padronizada; e Integrador  padrões abertos, tecnologias e linguagens consolidadas: .Net, C/C++, XML, SQL, ODBC, OPC, CIM, IEC 61131, IEC 61850. 113

6.1.3 Vantagens Esperadas

A tecnologia de computação em Nuvem disponível atualmente oferece vantagens significativas sobre tecnologias tradicionais, particularmente em relação à redundância e simplificação de projeto do sistema ou aplicação. Normalmente aplicada para projetos de Data Centers, o potencial em projetos de sistemas PAC pode se tornar um importante nicho de pesquisa e desenvolvimento. Nesse sentido, sistemas industriais usados na automação de SEPs, e particularmente sistemas baseados na norma IEC 61850, podem ser avaliados como casos de aplicação da tecnologia de virtualização e Nuvem em automação. As principais vantagens previstas com a adoção dessas tecnologias, corroborando com as características desejadas pelos usuários (Quadro 17), incluem:  Arquitetura padrão x86 / x64, ou seja, hardware padrão de mercado, além da consolidação de hardware que a virtualização proporciona, eliminando a dependência de IED’s de mercado do hardware do fabricante e reduzindo drasticamente custos de manutenção do sistema e tempo de reparo (MTTR);  Implementação mais próxima do desenho lógico da norma IEC 61850, ou seja, foco no funcional e na Engenharia de Software e não na rede, ou seja, foco maior nos requisitos de negócio do usuário;  Gestão centralizada e integrada dos ativos de TA do sistema;  Rede inteligente com provisionamento dinâmico de recursos;  Mecanismos intrínsecos de redundância e recuperação de desastre;  Ambiente mais integrado, flexível, escalável, confiável e simples; e  Ambientes de simulação, teste e treinamento mais facilmente adaptados e configurados. Em outras palavras, a evolução das tecnologias de computação, particularmente de sistemas distribuídos e virtualização e Nuvem, abrem um novo espaço de soluções a serem exploradas para aplicações de automação. Assim como redes Ethernet evoluíram a ponto de serem aplicadas em sistemas de automação, eventualmente tecnologias de virtualização e Nuvem se tornarão viáveis para atender os requisitos de confiabilidade e desempenho desses

114 sistemas. O intuito para explorar ambiente virtualizado e Nuvem nessa tese, partindo da ideia apresentada em (Ferreira, et al., 2012) (Ferreira, et al., 2013), é aproveitar as vantagens inerentes desse paradigma e avaliar suas características e desempenho para um sistema de automação IEC 61850. Conhecendo-se melhor o espectro dessas tecnologias com as revisões de middleware e virtualização e Nuvem feitas no capítulo 3, foi possível identificar a aderência da ideia dessa tese com trabalhos encontrados. Dentro deste contexto, entende-se que a solução de middleware DDS a ser adotada no desenho da arquitetura de referência atenderá a espinha dorsal da arquitetura, que é poder prover da forma mais simples e efetiva possível um verdadeiro barramento de dados virtual único como espaço de dados global. Com essa simplificação importantíssima de projeto, a infraestrutura subjacente de virtualização e Nuvem complementará a arquitetura com seu papel principal de poder criar um ambiente de implantação capaz de desacoplar todo hardware. Nesse sentido, vislumbra-se um potencial para avaliação do uso dessas tecnologias para compor uma arquitetura distribuída em nuvem capaz de executar sistemas de automação. Por fim, mas não menos importante, é válido definir melhor o entendimento dado neste texto da tese para os conceitos de virtualização apresentados. Sozinho, o hypervisor permite criar um ambiente virtualizado sobre um hardware convencional suportado. Para um ambiente de Nuvem como o definido pelo NIST, são necessários outros componentes de software para prover os serviços esperados além do próprio hypervisor que é o componente principal. No caso da VMware, por exemplo, o VMware vCloud Director13 é uma solução de Nuvem baseada no uso da solução de virtualização vSphere. Um serviço, em especial, oferecido por uma insfraestrutura de Nuvem desse tipo, é o vMove, que permite mover VMs para áreas sadias da Nuvem diante de falhas em componentes da infraestrutura subjacente na qual a VM estava executando. De maneira transparente, com um pequeno downtime devido o switch- over, o(s) serviço(s) executado(s) pela VM continua(m) funcionando sem maiores transtornos ou necessidade de arranjos complexos de redundância e tolerância a falhas. Algo impensável em uma infraestrutura convencional.

13 http://www.vmwarearena.com/vcloud-director-series-part-7-basic/ 115

Na visão desse autor, essa funcionalidade representa a melhor forma de demonstrar a abstração e poder que se pretende atingir com o conceito de Nuvem: um ambiente integrado de recursos computacionais unificados no qual os serviços virtuais implantados executam livremente de forma segura e transparente. Ou seja, uma infraestrutura plana (flat) para execução de aplicações e oferta de serviços, que é o objetivo final. Dentro deste contexto, é importante entender a diferença entre a parte fundamental que é a virtualização em si e a Nuvem. A virtualização tem como componente principal o hypervisor ou VMM, além da VM obviamente. A Nuvem, em maiúsculo, representa além da base de virtualização, modelos de serviços, características essenciais que todo serviço de nuvem deve exibir, e serviços para prover o grau de abstração pretendido, conforme descrito em 3.2.1 Conceituação. A nuvem, em minúsculo, é no sentido clássico de uma abstração que representa toda a infraestrutura subjacente, e não de uma arquitetura de Nuvem, propriamente dita, que como descrito anteriormente é mais complexa e engloba muitos outros serviços e camadas. Por esta razão é utilizado ao longo do texto o termo virtualização e Nuvem, para deixar explícito e separado o papel e abrangência de cada conceito, e nuvem quando se referir a uma abstração genérica de uma infraestrutura. Neste trabalho, dada à complexidade para se criar um ambiente de Nuvem e o foco em avaliar o desempenho em tempo real de aplicações virtualizadas, serão consideradas somente soluções de virtualização, como o KVM. Perdem-se importantes benefícios esperados em sistemas reais, mas mantem-se o foco principal da tese que é avaliar o desempenho de aplicações PAC virtualizadas. No tocante ao desempenho, é imprescindível escolher soluções robustas e contar com ferramentas e scripts capazes de gerar testes automatizados de acordo com cenários de testes pré-estabelecidos. Consequentemente, a escolha das implementações do middleware e da solução de virtualização e Nuvem precisa levar isso em consideração. Do ponto de vista das aplicações, em particular, é preciso conhecer o impacto fim-a-fim que todas as camadas de software do middleware, Guest-OS e virtualização têm sobre o desempenho do sistema.

116

6.2 RECOMENDAÇÕES PARA DESENHO DA ARQUITETURA

Para auxiliar o desenho da arquitetura distribuída e virtualizada, base para implementação computacional dos experimentos, são destacadas algumas referências e informações consideradas relevantes para esse trabalho. O livro sobre dependências no contexto de sistemas SOA (Service Oriented Architecture) (Prasad, 2013) aborda a importância de enxergar o negócio como um todo e identificar as dependências entre seus sistemas. Fazendo um exercício simplificado de aplicação do framework proposto, é possível compreender melhor onde se encaixa cada componente pensado para o desenho da arquitetura, conforme Quadro 18. Quadro 18 – Aplicação Framework SOA Camada Escopo Arquitetura Proposta (Tese) Negócio Lógicas de negócio e processos que Proteção, supervisão, controle, seguem a partir delas monitoração, medição Aplicação Capacidade e funções da IEC 61850-5 (LN) organização Informação Modelos de dados IEC 61850-7-1 (Princípios e Modelos), 7-2 (dados) (ACSI), 7-3 (Classes de Dados Comum) e 7-4 (Classes de Dados e LN) e IEC 61970 (CIM) Tecnologia Implementação da lógica: padrões, Enterprise Architect (Ferramenta UML pacotes, componentes, ferramentas CASE), C++ (com Qt), Middleware DDS, Virtualização & Nuvem Essa análise está restrita ao próprio escopo da norma IEC 61850 para SEP. Para um caso mais completo, como a ITAIPU, outros sistemas estariam envolvidos, como SCADA, hidrometereologia, segurança de barragem, dentre outros. Nesse sentido, a norma IEC 61850 já representará a especificação a ser seguida para as camadas de informação e aplicação. Para camada de negócio, pode-se considerar aplicações com restrição de tempo real mais leve, como supervisão, controle e monitoração, com tempos da ordem de 1 s a 16 ms (1 ciclo de um SEP de 60 Hz). Aplicações de proteção exigiriam tempos na ordem de 200 µs (4,8 kHz). Aplicações de oscilopertubografia chegariam a 65 µs (15,36 kHz) com taxa de amostragem de até 256 amostras/ciclo, e medição fasorial com taxas de até 60 amostras/ciclo ou 16 ms (60 Hz). Como infraestrutura pretende-se explorar e agregar as vantagens de um ambiente virtualizado e distribuído com middleware de comunicação. 117

Para camada de tecnologia, a escolha do DDS se justifica principalmente por se tratar de um padrão pensado e desenhado para tempo real, podendo ser aplicado tanto para tráfego segundo o paradigma publish-subscribe quanto cliente-servidor, além de poder ser aplicado em sistemas embarcados, ou seja, poderia ser usado até o nível das PIUs, criando efetivamente uma solução integrada e interoperável de um barramento único de comunicação entre o campo e a nuvem. A linguagem C++ foi escolhida por agregar OO e desempenho comprovado em aplicações de automação. A biblioteca Qt por oferecer um robusto framework C++ multiplataforma, boa documentação, e recursos que facilitam e simplificam a implementação. Como modelo de implantação da infraestrutura de nuvem, é mais natural e conveniente começar com nuvem privada interna. Pensando em um projeto real, essa seria certamente uma premissa inicial a ser especificada. Como modelo de serviço, IaaS oferece a flexibilidade e o controle necessários para criar o ambiente personalizado da arquitetura. No entanto, ambientes de nuvem modernos envolvem um conjunto maior de serviços e componentes, com soluções comumente comerciais, tornando muito mais complexa e demorada a sua implementação. Nesse sentido, recomenda-se focar mais em soluções de virtualização clássicas e abertas, de preferência, e na escolha do Guest-OS. No caso do DDS, em particular, o mapeamento proposto em (Calvo, et al., 2012) apresenta detalhes úteis, conforme Quadro 19 e Quadro 20. Quadro 19 – Mapeamento de Serviços ACSI e Tópicos DDS Topic Conteúdo Serviços ACSI Paradigma Distribuição (por variável) Filtrado GSE 1 Many to many Sim SMV Publish/Subscribe 1 Report/Logging 1 Many to one Não Request/Response 2 One to one Cliente/Servidor Sim Request/Non Response 1 One to one Quadro 20 – Configuração dos Parâmetros de QoS do DDS para Serviços ACSI Serviços ACSI QoS GSE SMV RL RNR RR Deadline Maximum - - - - process time Durability Persistent Volatile Volatile Volatile Volatile History Keep N Keep Last Keep N Keep N Keep N

118

Latency Budget Estimated urgency 33-50% of period - - - Ownership Shared Shared Exclusive Exclusive Exclusive Reliability Reliable Best effort Reliable Reliable Reliable Transport Priority Highest High Lowest Low Lowest O trabalho (Bi, et al., 2013) apresenta uma visão que ajuda a entender melhor o mapeamento da norma IEC 61850 para a arquitetura do padrão DDS, conforme Figura 22 a seguir. Figura 22 – Visão da Arquitetura do DDS para Mapeamento da Norma IEC 61850

Mapeamento Modelo de Dados Modelo de Comunicação do DDS Fonte: Fig. 3 (Bi, et al., 2013) Fonte: Fig. 4 (Bi, et al., 2013) Por fim, em (Pérez, et al., 2013) um ponto muito importante é destacado: DDS permite implementar protocolos específicos e até memória compartilhada para melhorar desempenho. Ou seja, a pilha IEC 61850 poderia ser adaptada para atender mensagens como GOOSE. No caso de comunicação entre aplicações em uma mesma VM ou entre VMs em uma mesma máquina física, seria possível otimizar a comunicação via memória, o que pode se tornar um diferencial para atender requisitos de desempenho exigidos. (Ardagna, 2014) destaca que a heterogeneidade de hardware e interferência entre VMs são causas primárias de variabilidade de desempenho. O tamanho da imagem do SO impactaria na variabilidade do tempo de arranque das VMs. Como boas práticas de desenho e implementação de sistemas seguros e previsíveis, é importante definir critérios claros e objetivos de desenvolvimento para permitir construir certo, ou o mais correto possível, os sistemas desde o início, o que consequentemente facilitará sua avaliação e o atendimento dos requisitos de QoS e tempo real. 119

Embora em aplicações embarcadas isso pareça mais natural, olhando as aplicações em x86 simplesmente com base nos recursos de hardware necessários e usando software base seguro com Trusted Computing Base (TCB) menor possível, os mesmos objetivos tornam-se naturalmente possíveis ou mais fáceis de alcançar. Em outras palavras, isso significa dizer que estaríamos considerando uma máquina x86 praticamente como um sistema embarcado. O esforço em construir um sistema de software bem pensado, desenhado, simplificado e otimizado compensaria em muito a dificuldade em conseguir modelar, avaliar e atender os requisitos de desempenho exigidos (Hoffmann, et al., 2007), mitigando ou eliminando provavelmente muitas limitações e restrições que seriam impostas por uma solução mais convencional. (García-Valls, et al., 2013) também destaca a questão de variabilidade de desempenho frente às camadas de virtualização e middleware de comunicação, cujo overhead afeta os tempos de resposta mínimo, máximo e médio, aumentando o jitter e overhead. Uma opção seria avaliar o uso de hypervisors de tempo real, como RT-Xen e XtratuM, seguindo um caminho mais convencional e oposto a proposta de um sistema mais enxuto e personalizado como descrito acima, porém com a possibilidade, a priori, de maior previsibilidade e obtenção de tempos de resposta no pior caso. As abordagens de escalonamento hierárquico, bem detalhada em (Cucinotta, et al., 2008) e descrita também em (García-Valls, et al., 2014) (Xi, 2014) (Groesbrink, 2014) (Delange, et al., 2014), e reservas de recursos, bem descrita em (Cucinotta, et al., 2008) e usada em (Groesbrink, 2014), parecem ter grande potencial de aplicação também. De qualquer forma, a opção de construir um sistema mais enxuto, ainda que não explicitamente de tempo real, parece ser um bom caminho a ser seguido, como o Genode e SO NOVA descritos a seguir. Uma comparação do desempenho entre essas opções e abordagens seria de grande valia, pois ajudaria a corroborar ou não com as suposições esperadas expostas aqui, enriquecendo a análise final, mas está fora do escopo deste trabalho.

120

6.2.1 Genode

Sistemas operacionais contemporâneos são extremamente complexos para acomodar a grande variedade de aplicações em um espectro cada vez mais diversificado de plataformas de hardware (Feske, 2010). O framework Genode (Feske, 2010), em particular, é a implementação da arquitetura do Genode. É um toolkit para criar SOs de propósito específico altamente seguros. Em outras palavras, Genode é uma alternativa criada para a construção de um sistema de software completo, do software base com diferentes opções de microkernel, ao ambiente de execução (RE – Runtime Environment) e integração de bibliotecas C/C++ já portadas, como Qt5, ou qualquer outra biblioteca externa, como OpenDDS. O resultado é uma imagem contendo o binário exclusivamente dos componentes de software que são efetivamente usados pela aplicação, obtendo-se um sistema final enxuto concebido para atender o que é estritamente necessário. O sistema é baseado em uma estrutura recursiva. Cada programa é executado em uma sandbox dedicada e tem concedido somente os direitos de acesso e recursos que são necessários para atender seu propósito específico. O framework alinha princípios de construção de microkernels com filosofia Unix. A arquitetura do Genode é desenhada para acomodar tipos de componentes de forma segura concorrentemente em uma máquina: device drives; serviços que multiplexam recursos; pilhas de protocolo, incluindo bibliotecas libc; aplicações; e ambientes de tempo de execução que permitem executar software de terceiros como subsistemas do Genode. O ambiente de execução seoul, por exemplo, é uma VMM desenvolvida para uso com a plataforma NOVA, também chamado de microhypervisor14 ou simplesmente microvisor, para executar Guest-OS baseado no Linux sem modificações. Ele virtualiza hardware x86 32 bits incluindo vários periféricos. virtualbox é outro exemplo de VMM que permite executar VirtualBox sobre o hypervisor NOVA. l4linux é um kernel Linux paravirtualizado que permite o uso do SO baseado em Linux como um subsistema do microkernel Fiasco.OC. Isso demonstra bem a versatilidade e o potencial de uso do Genode para construir ambientes com variados componentes, conforme a necessidade.

14 Combinação de um microkernel e uma plataforma de virtualização (hypervisor) 121

6.2.2 NOVA

O microvisor NOVA15 (NOVA OS Virtualization Architecture) (Steinberg, et al., 2010), em particular, é um projeto de pesquisa destinado a construir ambiente de virtualização seguro com um TCB pequeno. NOVA consiste em um microhypervisor e um ambiente de usuário multi-servidor sem privilégios que executa sobre ele. Cada VM tem seu próprio VMM associado que executa como uma aplicação do usuário sem privilégios sobre o microhypervisor. A Figura 23 a seguir ilustra bem a arquitetura do NOVA descrita detalhadamente em 4.2.5 NOVA: Arquitetura de Virtualização Segura baseada em Microhypervisor (Steinberg, et al., 2010). Figura 23 – Arquitetura do microhypervisor NOVA

Fonte: Fig. 2 (Steinberg, et al., 2010)

6.3 DESENHO PROPOSTO

Em uma visão de alto nível, idealizada, deseja-se poder criar um ambiente integrado com tecnologias de virtualização e sistemas distribuídos onde diferentes subsistemas pertencentes a um SEP possam:  ser modelados segundo a norma IEC 61850 através de uma ferramenta de configuração unificada e amigável;

15 http://www.hypervisor.org

122

 executar da forma mais flexível, ou seja, permitindo diferentes configurações e arranjos, e interoperável possível; e  ser testados da forma mais simples e completa. Essa visão pode ser sintetiza pela Figura 24 a seguir. Figura 24 – Visão Arquitetura Conceitual de Alto Nível

Configurador Visio like

Modelo Framework Infra

Nuvem maps deploys to to

Sample Values Binary I/O

PIU Pontos Campo

Sinais Analógicos & Digitais

Processo Equipamentos

O desenho, propriamente dito, da arquitetura distribuída e virtualizada aqui proposta, conforme considerações iniciais e recomendações anteriores baseadas nos estudos das tecnologias e aspectos de tempo real, é baseado em camadas bem definidas e componentes concebidos com características de tempo real e/ou TCB reduzidos. Esse desenho contempla somente a parte da visão de nuvem16 da Figura 24. A arquitetura dessa “Nuvem”, diferentemente da apresentada em 3.2.1 Conceituação, é caracterizada por seis camadas principais, conforme Figura 25. Neste diagrama pode-se destacar:  o ponto central é o framework IEC 61850;  aplicações são construídas no contexto da IEC 61850 e, nesse nível, independe se estão sobre VM ou hardware;  o middleware é para suportar a comunicação que a IEC 61850 demanda;  tudo executa sobre SO+VM; e  a infraestrutura de virtualização ou Nuvem fornece e gerencia as VM’s (boot, tolerância a faltas, storage, etc).

16 Uma arquitetura de Nuvem, propriamente dita, como da VMware, por exemplo, poderia ser usada também. 123

Figura 25 – Arquitetura em Camadas

Aplicações s o ç i

Framework IEC 61850 v r e a S

VM Middleware ç n a Guest-OS r u g

Máquina Virtual e S Virtualização / Nuvem Infra Recursos Físicos

As camadas são descritas no Quadro 21 abaixo. Quadro 21 – Componentes Arquitetura em Camadas Camada Componentes Descrição Aplicação Aplicação IEC 61850 Estudo de caso de uma aplicação que representa o benchmark da aplicação, utilizando o profile exigido da norma IEC 61850. Framework Modelo UML IEC 61850 Implementação do modelo UML da norma IEC 61850, a partir do qual aplicações PAC são construídas. Middleware DDS Software do sistema distribuído. Guest-OS Genode, TinyCore, Linux, Windows Software do sistema operacional Virtualização Seoul, VirtualBox, RT-Xen e QEMU Todo o conjunto do software da VM, Genode-NOVA, RT-Xen e KVM VMM e Hypervisor. Hardware Arquitetura x86-32 bits e x86-64 bits Infraestrutura de hardware subjacente. Quadro 22 – Ambientes de Implantação para Experimentos Ambiente Plataforma HW Hypervisor VMM Guest-OS DDS 1 Genode x86-32 bit Genode / NOVA Seoul 2 Tinycore 3 Genode 4 Genode / NOVA VirtualBox Tinycore 5 Windows OpenDDS 6 Tinycore OpenSlice RT-Xen RT-Xen 7 Linux CoreDX x86-64 bit 8 Tinycore RTI KVM QEMU 9 Linux 10 Nativo (Host-OS) – Tinycore 11 Nativo – Linux 12 Nativo – Genode / NOVA

124

Com base nas tecnologias e soluções encontradas, os ambientes propostos para os experimentos são apresentados no Quadro 22. A visão idealizada, por assim dizer, da arquitetura final virtualizada e distribuída com seus principais componentes e serviços pode ser visualizada no diagrama da Figura 26. Essa visão representa a ideia, do autor desta tese, de onde se poderia chegar no contexto de uma atualização tecnológica da ITAIPU. Figura 26 – Visão Idealizada da Arquitetura Final

Aplicações s o ç i

Framework v r Middleware e S CAT servidor.c OS ATCC cliente.c VM Controle Tensão Teste

Configurador Editor Telas AccessControl DisplayViewer SysMonitor Ferramentas AlarmViewer PerfMonitor IHM Monitoração Logger Log

DataManager Dados PISystem vDCManager API Historiador LDAP Infra DevTools TFTP SDK DHCP / DNS SGBD Desenvolvimento Rede

SMV Proteção RTDB Teste Config Base Dados SMV Medição PIUManager ProcessSimul Goose Binário Front-End Dados Campo Simulador

Nessa visão mais ampla, cada componente, serviço ou subsistema estaria disponível na infraestrutura virtualizada como uma máquina virtual de propósito específico, um Virtual Appliance de maneira mais genérica, com respectivo Guest- OS, seguindo o modelo de camadas proposto. A cor de cada vApp diferencia o tipo de aplicação ou serviço disponível: amarelo para serviços como base de dados, historiador de dados, ambiente de desenvolvimento e ferramentas de configuração em geral; azul para serviços de rede; e laranja para aplicação PAC, destacando em cinza serviços específicos do sistema PAC como Log, Monitoração e PIUs (dados campo e front-end), e em branca as aplicações PAC propriamente ditas, como controle de tensão (CAT). Considerando o contexto do trabalho discutido em 3.2.5 Virtualização e Nuvem no Contexto da Norma IEC 61850, e ilustrado nas Figura 15 e Figura 16, essa visão da Figura 26 se assemelharia mais com a abordagem P2V, apresentada 125 em (Ferreira, et al., 2014), com IEDs e hosts sendo convertidos para VMs ou vApps, vIED no caso da versão virtual do IED, demonstrando como uma infraestrutura típica de aplicações e serviços em arquitetura física convencional poderia ser migrada para ambiente de Nuvem. No entanto, com a evolução do próprio trabalho dessa tese, foi possível perceber que a abordagem P2V é clara no caso de migração de hosts, mas no caso de IEDs, com a abstração completa da infraestrutura de hardware, o foco é no modelo lógico e no LD, conforme concluído em 3.2.5. Obviamente, esse trabalho não tem a pretensão de construir essa arquitetura, mas apenas apresentar a ideia e visão particular.

6.4 CONSIDERAÇÕES FINAIS

Projetos mais complexos de infraestrutura computacional normalmente envolvem a definição de uma arquitetura de referência ou típica, termo mais comumente utilizado em Engenharia. No projeto base de atualização tecnológica da ITAIPU estão sendo definidas arquiteturas típicas de diferentes partes da automação da usina e subestações, como controle centralizado (SCADA) e controle local (Sistema Digital de Supervisão e Controle – SDSC e Unidade de Aquisição e Controle – UAC), antes de especificarem os sistemas para os respectivos projetos. Além de definir a base conceitual e modelo de referência de toda a infraestrutura, uma arquitetura permite expressar melhor o arranjo e interface dos principais componentes escolhidos. Neste trabalho de doutorado a arquitetura aqui proposta tem objetivos similares, sem a pretensão de se obter a arquitetura ótima, mas uma apropriada para permitir construir os ambientes de implantação elencados e realizar os experimentos e, satisfatoriamente, alcançar os resultados esperados.

126

7 ESTUDO DE CASO

A escolha de um estudo de caso tem por objetivo encontrar um problema ou aplicação PAC61850 em SEP que seja simples para entender, projetar e implementar e seja ao mesmo tempo típico e real para engenheiros de automação, proteção e controle. Um bay ou vão de subestação é um caso típico de aplicação em SEP. Apesar de ser um caso reduzido, visando simplificar o desenho e implementação da solução PAC61850, é representativo e fácil de entender, tornando-se um benchmark em potencial.

7.1 PROJETO

O projeto do estudo de caso engloba cinco etapas principais:  Projeto aplicação SEP;  Projeto PAC61850;  Projeto do desenho lógico IEC 61850;  Projeto modelo UML do framework IEC 61850; e  Projeto comunicação mapeamento para DDS. O projeto segue a visão idealizada nas Figura 24 – Visão Arquitetura Conceitual de Alto Nível e Figura 26 – Visão Idealizada da Arquitetura Final.

7.1.1 Projeto Aplicação SEP

O projeto da aplicação SEP de proteção de um bay ou vão de subestação é apresentado na Figura 27. O projeto contempla um problema típico em SEP de proteção de sobrecorrente, tanto instantânea (função 50) quanto temporizada (função 51), atuando sobre o disjuntor (função 5217). O circuito é composto de elementos ou equipamentos clássicos: barras ou barramento; seccionadoras (SC1 e SC2); disjuntor (DJ1); transformador de potencial (TP1); e transformador de corrente (TC1).

17 Numeração padronizada pela norma ANSI C-37-2 Números de Identificação e Funções dos Dispositivos Elétricos de Proteção, Regulação e Controle. 127

Figura 27 – Estudo de Caso: Projeto Aplicação SEP - Proteção de Bay SEP

SC1

DJ1 52

50 TC1 51

TP1

SC2

O funcionamento ou comportamento esperado pode ser resumido basicamente nas seguintes etapas: 1. Sinais primários de corrente do campo são adquiridos. 2. As funções de proteção 50/51 medem constantemente esse sinal do TC1 e processam o respectivo algoritmo de proteção de sobrecorrente instantânea e temporizada. 3. Caso ocorra alguma falta no circuito elétrico detectada por alguma das funções de proteção, um sinal de TRIP é enviado para acionar a abertura do dispositivo de proteção - disjuntor função 52. Uma vez atuada a proteção, o circuito é isolado eliminando a falta ocorrida, objetivo final. A função de proteção de sobrecorrente, propriamente dita, pode ser realizada por um algoritmo seguindo a norma ANSI C37.90 ou ANSI C37.112-1996, por exemplo.

7.1.2 Projeto PAC61850

Uma solução possível para o problema da aplicação SEP da Figura 27 é o projeto de um sistema PAC seguindo a norma IEC 61850 conforme Figura 28 a seguir. O primeiro passo é selecionar as funções normatizadas pela IEC 61850, ou seja, os nós lógicos (LNs).

128

Figura 28 – Estudo de Caso: Projeto Aplicação PAC61850 Desenho PAC61850 Controle PIUs GOOSE CSWI SC1 XSWI GOOSE MMS MMS CILO IOU GOOSE Medição MMS DJ1 52 XCBR MMS MMXU

TC1 TCTR SMV PTRC GOOSE TP1 TVTR PIOC

MU PTOC

SC2 Proteção

MMS

IHMI SCADA Para este problema foram utilizados os LNs descritos no Quadro 23 abaixo, conforme norma IEC 61850-7-4 e 7-5. Quadro 23 – Estudo de Caso: Nós Lógicos Utilizados LN Descrição TCTR Usado para transmitir corrente como valores amostrados (valores primários). TVTR Usado para transmitir tensão como valores amostrados (valores primários). XSWI Usado para modelar seccionadoras. Comandos Abrir/Fechar subscritos CSWI. XCBR Usado para modelar dispositivos de chaveamento com capacidade de abertura sob carga e curto-circuito, como disjuntores. Comandos de Abrir/Fechar são subscritos do CSWI. MMXU Usado para calcular valores rms, e.g. de tensão e corrente, bem como outras grandezas como potência e impedância de um sistema trifásico. Uso principal para aplicações de operação (e.g. SCADA). CILO Usado para permitir uma operação de chaveamento se condições de intertravamento são atendidas. Uma instância por dispositivo. Subscreve todas as posições do respectivo dispositivo de comando (switchgear). CSWI Usado para controlar todas as condições de chaveamento acima do nível de processo. PIOC Usado para proteção de sobrecorrente instantânea. PTOC Usado para modelar proteção de sobrecorrente temporizada ou tempo definido. PTRC Usado para conectar as saídas de operação (Op) de uma ou mais funções de proteção para um TRIP comum a ser transmitido para o XCBR. IHMI Usado para configurações, ajustes, modo de operação, operação manual (comandos). IHM de operador nível subestação. Para o problema básico de proteção descrito anteriormente seria suficiente utilizar os LNs TCTR, PIOC/ PTOC, PTRC, CILO, CSWI, XSWI e XCBR. 129

Os LNs TVTR, MMXU e IHMI foram incluídos para prover uma solução mais completa normalmente aplicada na prática, compondo assim uma solução mais prática com interface gráfica de operação (IHM de supervisão e controle a exemplo de um sistema tipo SCADA ou SDSC). A maioria das funções ou LNs são de nível de bay, enquanto o LN IHMI seria de nível de subestação. As mensagens SMV, GOOSE e MMS mostradas indicam o padrão de comunicação padronizado pela própria norma IEC 61850. As funções ou LNs são agrupados por blocos ou IEDs identificados como: MU (Merging Unit); IOU (Input-Output Unit); Controle; Proteção; Medição; e SCADA. A flexibilidade oferecida pelo modelo de dados e comunicação da norma permitiria outras configurações ou grupamentos de LNs, no limite até um único IED. Exceção seriam os LNs de processo como TCTR e XCBR que dependem de conexão física com os respectivos equipamentos de campo. No contexto da virtualização, a Figura 16 e seção 3.2.5 Virtualização e Nuvem no Contexto da Norma IEC 61850 destacam bem essa questão dos dispositivos amarrados ao campo, as chamadas PIUs, que não podem, portanto, ser virtualizadas na prática.

7.1.3 Projeto Desenho Lógico IEC 61850

A Figura 2918 apresenta o que seria o projeto do desenho lógico do projeto da aplicação PAC61850 anterior. O diagrama consegue descrever de forma unificada as características lógicas principais do projeto IEC 61850, contemplando o modelo de dados e o modelo de comunicação. Os LDs não são um requisito de aplicação, mas ajudam a modelar (IEC 61850-5). Cada LD deve incluir obrigatoriamente os LNs LLN0 e LPHD. A divisão dos LNs é feita em sete LDs:  TC1 que contem o LN TCTR1;  TP1 que contem o LN TVTR1;  SC1 que contem o LN XSWI1;  DJ1 que contem o LN XCBR1;

18 Embora não incluído por simplificação, para controle da seccionadora bastaria uma mensagem GOOSE do CSWI1 para XSWI1

130

Figura 29 – Estudo de Caso: Projeto Desenho Lógico IEC 61850

Desenho Lógico

LD:Medição PhV.phsA.instCVal.mag LD:SCADA MMXU1 M P10-LCD2 M LPHD1 DSLCD2 IHMI1 LLN01 S M P7-LCA4 DSLCA4 MMSCBLCA4 LPHD1 A.phsA.instCVal.mag G M M LLN01 MMXU2 M Com P9-LCE2 DSLCE2 MMSCBLCD2 MMSCBLCE2 S

LD:Proteção PTRC1 P6-LCC3 Op P8-LCA2 Pos DSLCA2 M LD:Controle LPHD1 G G CSWI1 G LPHD1 PIOC1 DSLCA3 G DSLCB2 S P5-LCA3 Pos LLN01 Op EnaOpn LLN01 GoCBLCA2 GoCBLCC2 PTOC1 CILO1 GoCBLCA3 GoCBLCB3

DSLCC2 DSLCB3 GoCBLCB2 S G MMSCBLCC3

Op Nuvem

PIU LD:TC1 LD:SC1

LLN01 TCTR1 XSWI1 LLN01 AmpSv Pos LPHD1 MSVCBLCA1 DSLCA1 S G DSLCC1 GoCBLCC1 LPHD1 P1-LCA1 P3-LCC1

LD:TP1 LD:DJ1

LLN01 TVTR1 G XCBR1 LLN01 VolSv Pos LPHD1 MSVCBLCB1 DSLCB1 DSLCD1 LPHD1 S M MMSCBLCD1 P2-LCB1 P4-LCD1  Controle que contem os LNs CSWI1 e CILO1;  Proteção que contem os LNs PIOC1, PTOC1, PTRC1;  Medição que contem os LNs MMXU1 e MMXU2; e  SCADA que contem o LN IHMI1. Esse diagrama lógico provê o nível de detalhamento das conexões entre os diversos LNs, as chamadas LCs (Logical Connections) e respectivos PICOM (Piece of Information for COMmunication), cuja descrição a parte fornece as seguintes informações, conforme IEC 61850-5: semântica; conexão ponto-a-ponto lógica; requisitos de desempenho; e tipo de dado. Ou seja, as LCs e PICOMs descrevem todos os detalhes de comunicação. As mensagens SMV, GOOSE e MMS são identificadas com um triângulo com a primeira sigla S, G e M, respectivamente. Para cada LC o publisher é representado pelo triângulo externo e subscriber pelo triângulo interno. Associado a cada LC é necessário definir ainda um ControlBlock, de acordo com o tipo de mensagem, que é criado no nível do LLN0, bem como um DataSet que é criado no nível do nó lógico da função PAC. 131

Troca de mensagens internas no mesmo LD são indicadas por conexões simples, por simplificação. A implementação, neste caso, pode se valer do uso de memória compartilhada (shared-memory) como transporte, suportado pelo DDS. O dado, propriamente dito, trocado em cada LC, é indicado pelo Data Object (tipo CDC - Common Data Class) do lado publisher. Cada DO contêm um ou mais DA - Data Attributes (tipo Constructed Attribute Class). A fronteira entre o que pode ser virtualizado e não é indicada pela linha tracejada com a separação entre PIU de campo e Nuvem.

7.1.4 Projeto Modelo UML IEC 61850

Conforme discutido na seção 2.3 CONSIDERAÇÕES FINAIS, será seguido o modelo UML proposto por (Kostic, et al., 2007) e (Kostic, et al., 2004). O modelo UML parcial da aplicação do estudo de caso é apresentado na Figura 30. Figura 30 – Estudo de Caso: Projeto Parcial Modelo UML IEC 61850

MetaModel:MCAA IEC61850Object Interpretado: 1 não explícito HierarchyIEC61850Object MetaModel:FCD na norma 1..* 1..* NamedIEC61850Object 1..* 1 Meta MetaModel:DS MetaModel:ControlBlock MetaModel:CDC MetaModel:FCDA MetaModel:DA 1..* Model Server MetaModel:LN 0..* 1 MetaModel:LNOwnedDS MetaModel:SVCB MetaModel:FCDA_CF MetaModel:ComposedDA

1..* 0..* MetaModel:LD MetaModel:LNPHD 1 MetaModel:LN0 MetaModel:LNDOM MetaModel:PersistentDS MetaModel:MSVCB MetaModel:PrimitiveCDC MetaModel:FCDA_MX MetaModel:PrimitiveDA 1 0..*

DomainLN:DomainLN CDCBase:C_PrimitiveCDC Domain Type LnGroupL:LPHD LnGroupL:LLN0 LnGroupT:GroupT CDCAnalogueInfo:PrimitiveMeasurandInfo Model

LnGroupT:TVTR CDCAnalogueInfo:SAV

1 SE_TP1 LPHD1 1 LLN01 TVTR1 DSLCB1 MSVCBLCB1 VolSv Instance Model

SCSM Mapping «classe de implementação» BayACSIServiceImpl BayACSIClientAPI Vendor BayACSIService Specific ACSI CoreACSI:ACSIService CoreACSI:ACSIEventListener CommonACSITypes:MulticastAddres CommonACSITypes:Authentication Por simplificação, esse modelo foca somente nos elementos ou objetos do nó lógico TVTR1, dispositivo lógico SE_TP1 e conexão lógica LCB1, mas mostra de forma bem completa os diversos níveis e classes envolvidos. O modelo é dividido em cinco partes. A parte comum que compõem o framework IEC 61850 é formada pelo Meta Modelo, Modelo do Domínio de Aplicação e ACSI. O Meta Modelo é apresentado por completo até o nível do DataSet, ControlBlock e CDC. O nível do Functional Constraint (FC) e Data Attribute (DA) são resumidos para simplificar o diagrama. O Modelo de Domínio mostra as

132 funções (LNs) e tipos de dados (CDC) específicos da aplicação. ACSI representa a API especificada pela norma. A aplicação, propriamente dita, é representada pelos objetos do Modelo de Instância, conforme desenho lógico, incluindo também o mapeamento SCSM das mensagens usadas (SMV, GOOSE e MMS).

7.1.5 Projeto DDS

Até então, todos os passos de projeto mostrados anteriormente são conforme e aderentes ao padronizado pela norma IEC 61850. O diferencial deste trabalho de doutorado ocorre no mapeamento SCSM para um mecanismo de comunicação não previsto e padronizado pela norma, o middleware de comunicação DDS, cujo projeto é descrito a seguir. Com a identificação e especificação dos dados (Data Objects) e conexões (LCs) no desenho lógico na Figura 29 e modelo UML do projeto PAC61850 da Figura 30, torna-se direto o mapeamento 1:1 para o desenho da solução DDS. Neste caso, seguindo o mapeamento proposto por (Bi, et al., 2013) conforme Figura 22, cada Data Object do modelo IEC 61850 identificado nas LCs é mapeado diretamente para um tópico DDS, conforme Figura 31 a seguir. Figura 31 – Estudo de Caso: Projeto DDS Mapeamento DDS

Globa Data Space Domain=SCADA IHMI1 Domain=Medição MMXU2 Topic=ihmi1Com Topic=mmxu2A Topic=mmxu1V CSWI1 Domain=Controle MMXU1 Topic=cswi1Pos CILO1 Topic=cilo1EnaOpn TCTR1 Domain=PIU PTRC1 Topic=tctr1AmpSv TVTR1 Domain=Proteção Topic=tvtr1VolSv Topic=ptrc1Op PIOC1 Topic=xswi1Pos XSWI1 Topic=pioc1Op Topic=xcbr1Pos Topic=ptoc1Op PTOC1 XCBR1

A simplificação de projeto obtida é nítida. No lugar de implementar a ACSI e o mapeamento SCSM para diferentes tipos de mensagens SMV, GOOSE e MMS, o projeto DDS mostra explicitamente o principal em qualquer problema de comunicação ou troca de dados, o dado. Mais especificamente, o conceito criado pelo DDS de um barramento virtual e espaço global de dados fica evidente no 133 contexto PAC61850 como alternativa ao complexo mecanismo de configuração com o uso da SCL (conjunto de arquivos de configuração XML) e de diferentes mensagens de comunicação previstos na norma IEC 61850. Com um projeto de comunicação simplificado, a implementação e testes tendem a ser mais fáceis e rápidos, focando o projeto PAC61850 no mais importante que são as funcionalidades e funções. Ou seja, problemas de comunicação e implementação de detalhes computacionais não devem ofuscar ou complicar o objetivo final, que é projetar uma aplicação para realizar e atender as lógicas e regras do negócio. Todo o resto é acessório, apesar de imprescindível. Em outras palavras, o tempo e energia dos projetistas e desenvolvedores têm de ser direcionados na maior parte ao desenho e implementação da solução mais simplificada e otimizada possível que realize o que se espera, atendendo os requisitos funcionais especificados com os requisitos de desempenho exigidos, como os temporais, foco deste trabalho de doutorado.

7.1.6 Nuvem IEC 61850

A visão idealizada na Figura 26 da Nuvem IEC 61850 para o estudo de caso é apresentada na Figura 32. Figura 32 – Estudo de Caso: Nuvem IEC 61850 Nuvem IEC 61850

Aplicação Framework

vIHMI1 Middleware Serviços SCADA Guest-OS VM vCSWI1 vCILO1 Controle vPIOC1 vPTOC1 vMMXU1 vPTRC1 vMMXU2 Proteção Medição

TCTR1 XCBR1 TVTR1 XSWI1 PIU PIU

134

O “v” em cada nó lógico denota explicitamente a versão virtualizada vLN, conforme ideia original apresentada na Figura 16. As PIUs são as funções que não podem ser virtualizadas.

7.2 IMPLEMENTAÇÃO

A implementação do estudo de caso engloba a criação dos seguintes artefatos de software:  Modelo UML do framework IEC 61850 na ferramenta Case EA (Enterprise Architect);  Biblioteca do framework no Linux e TinyCore;  Modelo DDS usando o plug-in do OpenDDS para Eclipse;  Aplicação PAC61850 no Linux e TinyCore; e  ISO das vApps para cada LD ou vLD. A linguagem C/C++ e biblioteca Qt foram escolhidas como base para a implementação de todo software do projeto. A IDE do Qt, Qt Designer, foi usada para todos os projetos dos códigos fonte em C/C++ da biblioteca IEC 61850, do modelo DDS e das aplicações PAC61850, e construção dos binários, tudo em ambiente Linux. No TinyCore, os códigos fonte precisam ser migrados para poderem ser construídos usando o GNU ToolChain19 específico da distribuição.

7.2.1 Modelo UML Framework IEC 61850

O framework IEC 61850 foi todo modelado em UML na ferramenta Case EA, que permite realizar mudanças de forma controlada no modelo e gerar código fonte correspondente em C++. A norma IEC 61850 ainda não possui um modelo UML formal disponível até o momento. Seguindo a documentação da norma, seria possível tentar obter um modelo UML, mas isso demandaria muito tempo e exigiria uma série de decisões de design fora do padrão, pois a documentação baseada principalmente em tabelas não facilita o trabalho de modelagem.

19 Coleção de ferramentas de programação para desenvolvimento de software, como compiladores e link editores para compilação e construção. 135

Em (Kostic, et al., 2004) (Kostic, et al., 2007) (Kostic, et al., 2003), foram apresentados resultados desse esforço de modelagem da norma IEC 61850 em UML. Ainda assim de forma incompleta, pois cada artigo foca uma parte da norma. Felizmente, em (ABB, 2009), foi possível encontrar um modelo de referência com versão datada de março de 2009, doado pela empresa ABB ao IEC TC5720. O modelo, disponibilizado através de uma ferramenta Case UML na Web, ajudou bastante a evitar ter de tomar decisões de design, mas não evitou o trabalhoso processo de construção do modelo em uma ferramenta Case UML. Graças a um projeto de P&D anterior, esse modelo foi feito no LASSE21.

7.2.2 Biblioteca Framework IEC 61850

A partir do modelo UML anterior construído na ferramenta Case EA, basta gerar automaticamente o código fonte em C++, fazer alguns ajustes de ambiente e codificação, gerar os códigos objeto e fazer a link edição para criação da biblioteca IEC 61850, componente fundamental para construção de aplicações PAC61850 aderentes ao modelo de dados da norma.

7.2.3 Modelo DDS

Para implementar o modelo DDS da Figura 31 foi utilizado o plug-in do OpenDDS para o Eclipse que permite modelar a aplicação e gerar o código correspondente. No caso dos tópicos, em especial, é necessário identificar nas partes 7-4 e 7-3 da norma IEC 61850 as CDCs dos dados dos nós lógicos, bem como os respectivos atributos com tipo e Functional Constraint aplicável, conforme Quadro 24. As CDCs aplicáveis são: SAV (Sampled Value); DPC (Controllable Double Point); WYE (Phase to ground related measured values of a three phase system);

20 Comite Técnico da IEC responsável por preparar padrões internacionais. Neste caso, para equipamentos e sistemas de controle aplicados a sistemas de potência. 21 Laboratório de Automação e Simulação de Sistemas Elétricos localizado no PTI (Parque Tecnológico ITAIPU), em Foz do Iguaçu.

136

CMV (Complex Measured Value); SPS (Single Point Status); e ACT (Protection Activation Information). Quadro 24 – CDCs, Atributos, Tipos e FC dos Dados dos LNs LN Dado CDC Atributos Tipo FC TCTR1 Amp SAV instMag AnalogueValue MX TVTR1 Vol q Quality MX t TimeStamp MX XSWI1 Pos DPC ctlVal Boolean CO XCBR1 Pos stVal Coded Enum ST q Quality ST CSWI Pos t TimeStamp ST MMXU1 PhV WYE phsA CMV MMXU2 A CMV instCVal Vector MX cVal Vector MX q Quality MX t TimeStamp MX CILO EnaOpn SPS stVal Boolean ST q Quality ST t TimeStamp ST PIOC Op ACT general Boolean ST PTOC Op q Quality ST t TimeStamp ST PTRC Op IHMI Com Única exceção é o LN IHMI que não tem dado definido, somente os herdados da classe comum LN. Neste caso, definiu-se o dado Com que conterá os atributos de interesse da aplicação. As FCs (Anexo B IEC 61850-7-3) aplicáveis são: MX (Measurand Information (analogue values) – não pode ser escrita); CO (Control Information – pode ser operado e lido); e ST (Status Information – não pode ser escrita).No modelo DDS cada tipo identificado é realizado como uma Struct, similar a uma classe, ou Union para tipos mais complexos, e como Typedef para tipos comuns como Boolean. Os tipos especiais do Quadro 24 definidos pela norma IEC 61850-7-3 e 7-2 são descritos no Quadro 25 a seguir. Quadro 25 – Definição dos Tipos Especiais Tipo Atributos Tipo Valor / Range AnalogueValue i INT32 inteiro f FLOAT32 flutuante Vector mag AnalogueValue ang AnalogueValue Packed List Lista ordenada de tipos 137

Coded Enum Conjunto ordenado valores Quality validity Coded Enum good|invalid|questionable detailQual Packed List overflow Boolean outOfRange Boolean badReference Boolean oscillatory Boolean failure Boolean oldData Boolean inconsistent Boolean inaccurate Boolean source Coded Enum process|substituted test Boolean Default False operatorBlocked Boolean Default False TimeStamp SecondSinceEpoch INT32 (0..Max)22 FractionOfSecond INT24U Resolução do IED TimeQuality TimeQuality TimeQuality LeapSecondsKnown Boolean True: corrige todos leaps ClockFailure Boolean True: ignorar TimeStamp ClockNotSynchronize Boolean True: não synch UTC TimeAccuracy Coded Enum n: Fonte: IEC 61850-7-3 e 7-2 A modelagem propriamente dita é feita em três partes após a criação do projeto do modelo:  DataLib: permite definir os tipos de dados do domínio de aplicação;  PolicyLib: permite definir os QoS padrões; e  DcpsLib: permite definir as entidades DDS e seus relacionamentos, caracterizando a aplicação DDS. O mapeamento de QoS (PolicyLib) segue o recomendado em (Calvo, et al., 2012), descrito no Quadro 20, conforme Figura 33 a seguir. Figura 33 – PolicyLib: Mapeamento OpenDDS de QoS GSE e SMV

22 Intervalo em segundos contado continuamente a partir do epoch 1970-01-01 00:00:00 UTC

138

O mapeamento dos tipos de dados no modelo do OpenDDS (DataLib) é apresentado na Figura 34. Figura 34 – DataLib: Mapeamento OpenDDS dos Tipos IEC 61850

Embora QoS definido dessa forma esteja ligado às mensagens padronizadas na norma, os mesmos podem ser aplicados diretamente aos tópicos, pois a qualidade de serviço para a troca de dados mantem-se. Além disso, fica mais explícito o tipo de comunicação da norma que o QoS está ligado. Ou seja, fica mais aderente à norma apesar do mapeamento SCSM ser para outro esquema de comunicação, o DDS. Na prática, o padrão DDS permite aplicar a configuração de QoS em diversos níveis do modelo: DomainParticipant (Logical Node); Publisher/Subscriber; DataReader/DataWriter; e/ou Tópico (dado). 139

Finalmente, o modelo OpenDDS resultante da aplicação (DcpsLib) do Bay PAC61850 é apresentado na Figura 35. Figura 35 – DcpsLib: Mapeamento OpenDDS da Aplicação PAC61850

140

Alguns pontos a destacar:  Domain: mapeado para o Logical Device;  DomainParticipant: mapeado para o Logical Node;  Publisher: nomeado com o ControlBlock da Logical Connection para designar explicitamente onde deve ser tratado o mecanismo e detalhes de comunicação previstos na norma;  Subscriber: nomeado com a Logical Connection ou PICOMs do(s) respectivo(s) Publisher(s) para explicitar a(s) conexão(ões);  DataReader e DataWriter: nomeados com a identificação do tópico; e  Topic: nomeado com LN e dado, conforme projeto Figura 31. O protocolo de transporte (TCP, UDP, mrel, mbe, RTPS) pode ser definido no nível do DomainParticipant, Publisher/Subscriber e/ou DataReader/DataWriter. O interessante a observar nesse diagrama é como a construção do modelo se assemelha muito ao projeto descrito anteriormente e apresentado nas Figura 29 e Figura 31, o que denota o ganho de desenho da aplicação que uma solução simplificada como o DDS proporciona. Em outras palavras, o problema de troca de dados torna-se mais natural e mais fácil de resolver, desenhar e entender. Dentro deste contexto, e diante de tantas evidências, é desejável esperar que uma solução similar de mapeamento DDS pudesse ser padronizada e fazer parte da norma IEC 61850, a exemplo do SCSM para GOOSE, SMV e MMS definido nas partes 8-2, 9-1 (Peer-to-peer), 9-2 e 8-1, respectivamente.

7.2.4 Aplicação PAC61850

O modelo do OpenDDS permite gerar automaticamente o código C/C++ correspondente, criando os seguintes arquivos ou artefatos de software:  .idl: inclui definições dos tipos de dados do modelo DataLib;  Traits.h|cpp: inclui definições da configuração de transporte definidas no editor Codegen. Este é o único cabeçalho que precisa ser incluído na aplicação;  _T.h|cpp: contém o modelo DcpsLib. Define a classe que fornece acesso às entidades especificadas do DDS e API; e 141

 .mpc .mpb _paths.mpb: arquivos usados para facilitar construção da biblioteca do modelo. Com o código e biblioteca do modelo DDS da aplicação e o framework IEC 61850, pode-se finalmente construir as aplicações PAC61850, propriamente ditas, e o sistema completo. Para simplificar e facilitar o desenvolvimento e implantação, foi implementado um único código fonte e criada uma única aplicação. Dessa forma, é possível construir uma única ISO das vApps contendo as aplicações PAC61850 e bibliotecas necessárias. A execução de cada vLD do sistema, conforme divisão feita na Figura 32 – Estudo de Caso: Nuvem IEC 61850, é feita por uma simples opção em linha de comando especificando o tipo da aplicação, ou seja:  ihm: para executar a aplicação gráfica do vLD SCADA;  control: para executar a aplicação da lógica de controle que implementa o vLD Controle;  prot: para executar a aplicação do vLD Proteção;  med: para executar a aplicação do vLD Medição; e  piu: para executar a aplicação dos vLDs MU e IOU.

7.2.5 ISO Virtual Appliances

Com os pacotes de software e aplicações construídos, basta separar cada parte do sistema em virtual appliances. A partição, conforme Figura 32 – Estudo de Caso: Nuvem IEC 61850, considera a criação de quatro vApps:  SCADA: aplicação da interface gráfica do sistema;  Medição: aplicação medições de tensão e corrente em valor eficaz (rms);  Controle: aplicação de controle que comanda o disjuntor, manualmente via IHM ou via proteção; e  Proteção: aplicação que verifica a condição operativa do SEP através da corrente, causando trip no circuito em caso de falha detectada pela função de sobrecorrente. Obviamente, qualquer outra divisão ou partição seria possível. Essa divisão proposta tem o intuito de separar mais claramente as funções e ter um sistema mais

142 distribuído, adaptado a um cenário mais real com várias VMs, permitindo assim avaliar melhor o comportamento temporal do sistema, objetivo principal do trabalho. Uma quinta vApp é criada para simular as PIUs. Em um cenário mais completo e prático poder-se-ia pensar em integrar o sistema virtualizado com PIUs reais, ou seja, MUs e IOUs de mercado. Ainda assim, faria sentido pensar em criar vPIUs que funcionariam como gateways para o DDS. Se houvessem PIUs construídas com SCSM e suporte ao DDS, a integração seria direta via rede. Eventualmente isso tenderia a ocorrer.

7.3 CONSIDERAÇÕES FINAIS

Conforme observado em 6.1.3 Vantagens Esperadas, com respeito ao trecho “entende-se que a solução de middleware DDS a ser adotada no desenho da arquitetura de referência atenderá a espinha dorsal da arquitetura, que é poder prover da forma mais simples e efetiva possível um verdadeiro barramento de dados virtual único como espaço de dados global”, a expectativa quanto ao DDS mostrou- se acertada, evidenciada pela estreita relação entre a Figura 29 – Estudo de Caso: Projeto Desenho Lógico IEC 61850 e a Figura 35 – DcpsLib: Mapeamento OpenDDS da Aplicação PAC61850. Em outras palavras, como esperado, o uso do DDS como mecanismo de comunicação para troca de dados mostrou-se fácil de projetar e implementar. A confiabilidade dessa solução, contudo, teria de ser avaliada. Com respeito à virtualização, a segunda observação de que com a simplificação importantíssima de projeto obtida com o barramento DDS, “a infraestrutura subjacente de virtualização e Nuvem complementará a arquitetura com seu papel principal de poder criar um ambiente de implantação capaz de desacoplar todo hardware”, também se mostrou verdadeira, como esperado, evidenciada pela flexibilidade oferecida com a construção de virtual appliances (vApps) desvinculados da ideia de um hardware dedicado, ou seja, o IED. Dessa forma, a visão idealizada inicialmente em (Ferreira, et al., 2012) (Ferreira, et al., 2013) de um mapeamento direto ou mais próximo de 1:1 do lógico para o virtual, foi significativamente alcançada com o estudo de caso aqui descrito do projeto lógico PAC61850 mapeado para uma solução de software com o 143 middleware de comunicação DDS e o hypervisor KVM, seguindo a Figura 25 – Arquitetura em Camadas. Dentro deste contexto, entende-se que o método de desenho e implementação de um projeto PAC61850 aqui proposto tenha potencial para evoluir em aplicações futuras da norma IEC 61850 com um possível mapeamento SCSM padronizado para o DDS. Ainda que isso não ocorra na prática, existe certamente muito espaço para pesquisas e testes, tomando como ponto de partida ou referência o estudo apresentado por este trabalho de doutorado.

144

8 RESULTADOS PRIMEIRA ETAPA – CARACTERIZAÇÃO A PARTIR DDS

O objetivo deste capítulo, a partir das propostas de arquitetura e caracterização temporal apresentadas anteriormente, é definir o ambiente de experimentação que será implementado e os cenários de teste a serem realizados para obtenção dos resultados de desempenho. Nesta primeira etapa, espera-se poder obter uma referência de desempenho de tempo a partir da camada do DDS, ou seja, caracterizar o desempenho temporal do meio de comunicação como um todo desde o DDS até a rede propriamente dita, fim-a-fim, em diferentes configurações de aplicações publish-subscribe se comunicando em diferentes níveis do sistema, ou seja, diferentes combinações Host-VM. O capítulo termina com uma análise dos resultados obtidos.

8.1 INFRAESTRUTURA DE EXPERIMENTAÇÃO

Como componente principal da arquitetura proposta, a experimentação inicial será focada no funcionamento e desempenho do DDS. O teste a partir da aplicação IEC 61850, que deve considerar os requisitos temporais apresentados anteriormente, fica para a implementação final deste trabalho de doutorado. Não obstante, esses requisitos serão usados como referência para confrontar com os resultados obtidos nos testes aqui propostos. Neste contexto inicial, o ambiente de experimentação considera duas máquinas físicas (hosts) com duas máquinas virtuais (VM) cada. Dessa forma, é possível testar o desempenho de aplicações DDS em várias combinações Host-VM, conforme Quadro 26 a seguir. Quadro 26 – Relação de Testes Host-VM Teste Descrição Host-Host Comunicação remota entre hosts. Host_Local Comunicação localhost entre duas aplicações. Host-VM_Local Comunicação local entre host e VM. Host-VM_Remote Comunicação remota entre host e VM. VM_Local Comunicação localhost entre duas aplicações. VM-VM_Local Comunicação local entre duas VMs. VM-VM_Remote Comunicação remota entre duas VMs. 145

Comunicações locais ocorrem no mesmo host ou VM. Comunicações remotas ocorrem necessariamente entre os dois hosts. Com essa cobertura de testes, entende-se ser possível mapear o desempenho da camada DDS, e, portanto, de toda camada de comunicação propriamente dita, nos diferentes cenários de comunicação que podem ocorrer na prática. Como aplicações, visando simplificar e focar nos resultados de desempenho do DDS, serão utilizadas as aplicações de benchmark da distribuição OpenDDS. Essas aplicações se dividem em dois tipos: latência e throughput. As aplicações dos testes de latência e throughput são executadas para cinco protocolos de transporte diferentes com diferentes tamanhos de mensagem. Os protocolos suportados são: multi-be ou mbe (multicast best- effort); multi-rel ou mrel (multicast reliable); RTPS; TCP; e UDP. Os tamanhos das mensagem são: 50; 100; 250; 500; 1000; 2500; 5000; 8000; 16000; e 32000 bytes. Os softwares considerados nesta etapa são descritos no Quadro 27. Quadro 27 – Softwares para Ambiente de Testes Teste Ambiente Host-Host Linux e TinyCore como Host-OS Host_Local Host-VM_L Linux como Host-OS Host-VM_R TinyCore como Guest-OS VM_Local KVM-QEMU como Hypervisor-VMM VM-VM_L Genode-Nova (Hypervisor) e Seoul/VBox (VMM) VM-VM_R KVM-QEMU é utilizado como hypervisor-VMM em todos os casos. Visando avaliar opções mais atuais, foi preparado um iso com microkernel NOVA (microvisor), Genode (framework SO), Seoul (VMM) e TinyCore (Guest-OS), mas dificuldades de implementação dada a complexidade da solução impediram a realização dos testes, e, portanto, nenhum resultado foi obtido. O Quadro 28 apresenta as configurações básicas de hardware das máquinas utilizadas. Quadro 28 – Configuração de Hardware Máquinas de Teste Recurso app.sinuv piu.sinuv Memória RAM 1.8 Gb 5.8 Gb CPU Intel® CoreTM i5-3470 Intel® CoreTM i5-2400 CPU @3.20GHz x 4 CPU @3.10GHz x 4 Rede 100 Mbps SO ubuntu 14.04 LTS 64-bit

146

O Quadro 29 resume as informações básicas de conexão da rede utilizada. Quadro 29 – Rede de Testes

IPv4 Descrição Endereços IP Hosts Linux: piu.sinuv 179.106.230.90 app.sinuv 179.106.230.91 VMs: vApp1.sinuv 179.106.230.93 vApp2.sinuv 179.106.230.94 vApp3.sinuv 179.106.230.95 vApp4.sinuv 179.106.230.96 Endereço Broadcast 179.106.230.127 Máscara Subrede 255.255.255.192 Gateway Padrão 179.106.230.65 A Figura 36 ilustra a arquitetura geral de testes proposta, com destaque dos sete testes levantados no Quadro 26 – Relação de Testes Host-VM. Figura 36 – Arquitetura de Testes

vApp1.sinuv vApp2.sinuv vApp3.sinuv vApp4.sinuv 179.106.230.93 179.106.230.94 179.106.230.95 179.106.230.96

VM1 VM-VM_L VM2 VM-VM_R VM3 VM4 VM_Local DDS DDS DDS DDS Guest-OS Guest-OS Guest-OS Guest-OS VMM VMM VMM VMM Host-VM_R vlocalhost / veth0 vlocalhost / veth0 vlocalhost / veth0 vlocalhost / veth0 Host-VM_L Hypervisor Hypervisor OS DDS OS DDS Host_Local HW HW Host-Host Host 1 localhost / eth0 Host 2 localhost / eth0

app.sinuv piu.sinuv 179.106.230.91 179.106.230.90 O Hypervisor como componente básico para virtualização, em particular, mostra as duas possibilidades: tipo 1 (nativo, unhosted ou bare metal) que executa diretamente sobre o hardware da máquina física; e tipo 2 (hosted) que executa sobre o SO do host. VMM mostra explicitamente o segundo componente exigido para virtualização (normalmente usado como sinônimo de Hypervisor), que é o monitor de cada VM. Em conjunto, Hypervisor e VMM emulam todo o hardware usado pela VM, abstraindo de forma virtual o que o Guest-OS acredita ser recursos reais, físicos. 147

A Figura 37 representa os testes para o ambiente com Linux (Host-OS), KVM-QEMU (Hypervisor tipo 2 e VMM), TinyCore (Guest-OS) e OpenDDS (middleware de comunicação DDS), ou seja, o ambiente de implantação 8 proposto no Quadro 22. Figura 37 – Arquitetura de Testes com Linux, KVM-QEMU, TinyCore e OpenDDS

vApp1.sinuv vApp2.sinuv vApp3.sinuv vApp4.sinuv 179.106.230.93 179.106.230.94 179.106.230.95 179.106.230.96

VM1 VM-VM_L VM2 VM-VM_R VM3 VM4 VM_Local OpenDDS OpenDDS OpenDDS OpenDDS TinyCore TinyCore TinyCore TinyCore QEMU QEMU QEMU QEMU Host-VM_R vlocalhost / veth0 vlocalhost / veth0 vlocalhost / veth0 vlocalhost / veth0 Host-VM_L KVM KVM Linux OpenDDS Linux OpenDDS Host_Local HW HW Host-Host Host 1 localhost / eth0 Host 2 localhost / eth0

app.sinuv piu.sinuv 179.106.230.91 179.106.230.90 A Figura 38 representa os testes para o ambiente com Genode-NOVA (Hypervisor ou microvisor tipo 1), Seoul/VBox (VMM), TinyCore (Guest-OS) e OpenDDS (DDS), ou seja, o ambiente de implantação 2 proposto no Quadro 22. Figura 38 – Arquitetura de Testes com Genode-NOVA, Seoul/VBox, TinyCore e OpenDDS

vApp1.sinuv vApp2.sinuv vApp3.sinuv vApp4.sinuv 179.106.230.93 179.106.230.94 179.106.230.95 179.106.230.96

VM1 VM-VM_L VM2 VM-VM_R VM3 VM4 VM_Local OpenDDS OpenDDS OpenDDS OpenDDS TinyCore TinyCore TinyCore TinyCore Seoul / VBox Seoul / VBox Seoul / VBox Seoul / VBox Host-VM_R vlocalhost / veth0 vlocalhost / veth0 vlocalhost / veth0 vlocalhost / veth0 Host-VM_L OpenDDS Genode OpenDDS Genode NOVA NOVA Host_Local HW HW Host-Host Host 1 localhost / eth0 Host 2 localhost / eth0

app.sinuv piu.sinuv 179.106.230.91 179.106.230.90

148

8.2 IMPLEMENTAÇÃO DO AMBIENTE DE TESTES

A implementação do ambiente de testes envolve duas etapas principais: 1. Preparação do host Linux, conforme descrito no APÊNDICE A – Ambiente de Software Host. 2. Criação da iso do Guest-OS, mesma para Host-OS, conforme descrito no APÊNDICE B – TinyCore, seção ISO TinyCore-Bench. A criação do ambiente para Genode, embora descrito no APÊNDICE C – Genode como referência do trabalho realizado, não faz parte do escopo de testes conforme frisado anteriormente.

8.3 TESTES REALIZADOS

Para simplificar e diminuir o tempo de execução, os testes foram configurados para tipo latência e tamanho de mensagem 250 bytes (maior que 161 bytes de mensagens GOOSE e SMV típicas) para todos os tipos de protocolos de transporte disponíveis no OpenDDS. Dessa forma, cada cenário de teste leva cerca de 15 minutos para completar. A execução de cada teste proposto é descrita no Quadro 30. Quadro 30 – Execução dos Testes Realizados

Teste Servidor – Publisher Cliente – Subscriber Host_Local Seguindo APÊNDICE A – Ambiente de Abrir outro XTerm na mesma Software Host com ajuste para teste local, máquina: abrir XTerm host app.sinuv: > cd DDS >vi bin/PerlDDS/Cross_Sync_Common.pm > source ./setenv.sh > export CROSS_GRP=3 > cd DDS > cd DDS/bin > source ./setenv.sh > ./auto_run_tests.pl –l > export CROSS_GRP=4 performance_tests-250.lst > cd DDS/bin > ./auto_run_tests.pl –l performance_tests- 250.lst > cd > mkdir –p SINUV/tests/Host_Local/latency > mkdir –p SINUV/tests/Host_Local/thru > cd DDS/performance-tests/Bench/tests > cd latency > cp –pr tcp/ udp/ rtps/ multi-be/ multi-rel/ /home/sinuv/SINUV/tests/Host_Local/latency > cd ../thru > cp –pr tcp/ udp/ rtps/ multi-be/ multi-rel/ /home/sinuv/SINUV/tests/Host_Local/thru Host-Host Idem no host app.sinuv corrigindo para teste Idem XTerm host piu.sinuv remoto: usando: 149

>vi bin/PerlDDS/Cross_Sync_Common.pm > export CROSS_GRP=2 e usando: > export CROSS_GRP=2 e copiando os arquivos para: SINUV/tests/Host-Host Host-VM_L Idem usando: Abrir XTerm na VM > export CROSS_GRP=5 vApp1.sinuv no host e copiando os arquivos para: app.sinuv: SINUV/tests/Host-VM_L > source ./dds-setenv.sh > export CROSS_GRP=5 > ./auto_run_tests.pl –l performance_tests-250.lst Host-VM_R Idem no host app.sinuv usando: Idem anterior no host > export CROSS_GRP=6 piu.sinuv usando: e copiando os arquivos para: > export CROSS_GRP=6 SINUV/tests/Host-VM_R VM_Local Seguindo APÊNDICE A – Ambiente de Abrir outro XTerm na mesma Software Host, para teste local, abrir XTerm VM: na VM vApp1.sinuv: > source ./dds-setenv.sh > vi > export CROSS_GRP=9 /usr/local/opendds/dds/bin/PerlDDS/Cross_Sync_ > ./auto_run_tests.pl –l Common.pm performance_tests-250.lst

> source ./dds-setenv.sh > export CROSS_GRP=10 > ./auto_run_tests.pl –l performance_tests- 250.lst Para cópia remota usar: > tce-load -wi openssh.tcz > cd /usr/local/opendds/share/dds/performance- tests/Bench/tests > cd latency > scp -pr tcp/ udp/ rtps/ multi-be/ multi-rel/ [email protected]:"/home/ sinuv/SINUV/tests/VM_Local/latency" VM-VM_L Na VM vApp2.sinuv no host piu.sinuv: Na VM vApp1.sinuv no host > source ./dds-setenv.sh piu.sinuv: > export CROSS_GRP=7 > source ./dds-setenv.sh > ./auto_run_tests.pl –l performance_tests- > export CROSS_GRP=7 250.lst > ./auto_run_tests.pl –l Para cópia remota usar: performance_tests-250.lst SINUV/tests/VM-VM_L VM-VM_R Na VM vApp3.sinuv no host piu.sinuv: Na VM vApp1.sinuv no host > source ./dds-setenv.sh app.sinuv: > export CROSS_GRP=8 > source ./dds-setenv.sh > ./auto_run_tests.pl –l performance_tests- > export CROSS_GRP=8 250.lst > ./auto_run_tests.pl –l Para cópia remota usar: performance_tests-250.lst SINUV/tests/VM-VM_R

8.4 RESULTADOS OBTIDOS

Os resultados da execução das aplicações de benchmark dos testes de desempenho do OpenDDS feitos anteriormente são salvos em arquivos por tipo de protocolo de transporte e tamanho da mensagem.

150

Nos testes realizados são obtidos arquivos do tipo latency-250.data para cada protocolo que contém as medições de tempo de cada mensagem. O APÊNDICE D – Resultados Benchmark OpenDDS mostra como obter os dados estatísticos a partir das medições realizadas. A Tabela 1 apresenta a tabulação de todos os resultados estatísticos, mediana (median), mínima, máxima e MAD (Median Absolute Deviation), obtidos a partir dos gráficos de distribuição de latência e jitter, por teste, por protocolo. Tabela 1 – Resultados Estatísticos de Latência e Jitter [µs] do DDS Latência [µs] Jitter [µs] Teste Proto Media Mín Máx MAD Media Mín Máx TCP 289 254 378 2,00 0,00 -93 10,4 UDP ------Host_Local RTPS 309 273 1550 5,00 0,00 -1220 1250 multi-be 260 156 1320 11,0 0,00 -1050 1080 multi-re 266 205 1390 9,00 0,00 -1060 1130 TCP 566 461 1180 8,00 1,00 -515 638 UDP 540 436 3380 9,00 1,00 -2830 2840 Host-Host RTPS 590 516 994 8,50 0,50 -317 426 multi-be 584 522 722 13,0 1,00 -94,5 148 multi-re 589 485 2810 12,0 0,50 -2170 2230 TCP 451 212 5850 7,5 -0,50 -4980 5400 UDP 397 332 673 9,50 0,00 -260 267 Host-VM_L RTPS 442 356 1890 17,0 0,00 -1420 1440 multi-be 443 362 1090 21,5 -0,50 -592 643 multi-re 434 346 462 22,5 -0,50 -3600 4030 TCP 740 659 950 11,5 0,50 -178 235 UDP 685 608 831 12,5 0,50 -150 117 Host-VM_R RTPS 735 652 1430 13,0 0,00 -562 704 multi-be 772 682 1040 12,0 0,00 -265 316 multi-re 764 682 1100 13,0 0,00 -267 357 TCP 309 186 749 16,0 0,00 -441 424 UDP ------VM_Local RTPS 343 295 615 18,5 0,00 -250 271 multi-be 581 333 1370 16,5 0,00 -780 755 multi-re 632 425 2500 24,5 -0,50 -1740 1820 TCP 638 510 2180 21,0 -1,00 -1420 1450 UDP 547 403 1420 13,0 0,00 -869 856 VM-VM_L RTPS 596 472 2100 16,5 0,00 -1470 1490 multi-be 619 351 1670 29,0 -1,00 -1010 1030 multi-re 635 531 3360 24,5 -1,00 -271 270 TCP 901 804 1070 14,5 -0,50 -145 151 UDP 817 754 2590 11,0 0,00 -1710 1780 VM-VM_R RTPS 873 725 3540 13,0 0,00 -2470 2730 multi-be 909 768 2900 13,5 -0,50 -1980 1910 multi-re 932 829 2070 14,5 0,00 -1040 1160 A Figura 39 apresenta os resultados obtidos com o teste Host_Local usando TCP como protocolo de transporte. 151

Figura 39 – Gráfico de Latência e Jitter para o Teste Host_Local

A latência é o tempo de round-trip medido pela aplicação de benchmark dos testes de desempenho do OpenDDS, conforme explicado em 5.4.6 Medição de Desempenho & Tratamento Estatístico. O jitter é calculado a partir de duas amostras consecutivas, ou seja, diferença entre duas latências consecutivas medidas, podendo ser positivo ou negativo. Apresentar explicitamente cada medida de latência e jitter calculado por amostra permite avaliar o comportamento dessas caraterísticas de tempo ao longo de todo o teste, e comparar com demais testes para avaliar melhor a influência dos diferentes componentes da arquitetura proposta. Quanto mais próximos os valores, maior a estabilidade do teste e menor a influência dos componentes, um comportamento esperado para um teste local. O gráfico de distribuição, por sua vez, mostra estatisticamente esse comportamento, incluindo medidas estatísticas, que apresentam de maneira mais clara uma maior ou menor dispersão dos dados resultante da maior ou menor variação do comportamento medido e estabilidade da infraestrutura. No APÊNDICE D – Resultados Benchmark OpenDDS são mostrados os gráficos para os demais protocolos de transporte. Comparando, não é possível inferir algo mais concreto, pois os protocolos RTPS e multicast-Best Effort e multicast-

152

Reliable apresentam algumas poucas amostras com latência alta muito superior à mediana, distorcendo os resultados estatísticos. Excluindo-se estas medidas, o comportamento seria muito similar, não havendo vantagem aparente de um ou outro protocolo para a infraestrutura computacional utilizada nos testes. Outro gráfico útil obtido é o que mostra a latência por quantile ou percentil, conforme Figura 40. Figura 40 – Gráfico de Quantiles de Latência por Tamanho de Mensagem para o Teste Host_Local

Este gráfico de distribuição acumulada facilita observar e comparar o comportamento dos diferentes testes com diferentes protocolos de comunicação, visando identificar a combinação mais adequada para atender os requisitos da aplicação. Neste caso do teste Host_Local, é possível ver mais claramente como a mediana se extende praticamente por uma faixa de percentil 20 a 80, como a faixa inicial de 0 a 20 parte do mínimo até se aproximar da mediana, e como na faixa final de 80 a 100 a mediana começa a dispersar até o máximo. Uma faixa maior e mais estável ao redor da mediana e valores mínimos e máximos não muitos dispersos indicaria a estabilidade esperada para o teste Host_Local, ao contrário dos testes que envolvem componentes de virtualização e comunicação remota. 153

Outro gráfico gerado é o de densidade que permite visualizar a distribuição com percentuais, conforme Figura 41. O ponto de densidade máxima do gráfico, em especial, corresponde a mediana que, neste caso, representa cerca de 1/3 ou 34% das amostras. Quanto maior essa percentagem e mais estreita ou menos dispersa a curva, melhor a estabilidade da infraestrutura do teste. Figura 41 – Gráfico de Densidade de Latência por Tamanho de Mensagem para o Teste Host_Local

Esses gráficos são gerados para cada cenário de teste realizado previsto no Quadro 26. As Figura 42, Figura 43, Figura 44, Figura 45, e Figura 47 apresentam os gráficos obtidos para os demais cenários de teste.

154

Figura 42 – Gráfico de Latência e Jitter para o Teste VM_Local

Figura 43 – Gráfico de Latência e Jitter para o Teste Host-VM_L

155

Figura 44 – Gráfico de Latência e Jitter para o Teste Host-VM_R

Figura 45 – Gráfico de Latência e Jitter para o Teste VM-VM_L

156

Figura 46 – Gráfico de Latência e Jitter para o Teste VM-VM_R

Figura 47 – Gráfico de Latência e Jitter para o Teste Host_Host

157

A Tabela 2 apresenta as latências medianas (median) em µs obtidas a partir da Tabela 1. Tabela 2 – Latência Mediana [µs]

Teste TCP UDP23 RTPS mbe Mrel Host_Local 289 - 309 260 266 Host-Host 566 540 590 584 589 Host-VM_L 451 397 442 443 434 Host-VM_R 740 685 735 772 764 VM_Local 309 - 343 581 632 VM-VM_L 638 547 596 619 635 VM-VM_R 901 817 873 909 932 Os gráficos de densidade e quantiles são usados para montar a Tabela 3 que apresenta a densidade máxima em % e o percentil 95 das latências em µs obtidos a partir da leitura visual desses gráficos, para cada protocolo de transporte. Tabela 3 – Densidade Máxima [%] e Percentil 95 das Latências [µs] por Protocolo Teste TCP24 UDP RTPS mbe Mrel Host_Local 35% 302 ------Host-Host 22% 590 16% 550 23% 625 19% 620 16% 590 Host-VM_L 12% 490 22% 425 15% 500 13% 510 12% 500 Host-VM_R 19% 775 19% 720 18% 770 19% 810 19% 800 VM_Local 19% 350 ------VM-VM_L 12% 690 19% 580 16% 620 9% 710 11% 700 VM-VM_R 17% 940 19% 850 18% 900 15% 950 17% 990 As latências máximas variam de 1 a 5 ms, mas representam menos de 1% das amostras. O gráfico de quantile, por sua vez, mostra que mais de 95% das amostras são muito próximas à mediana. O jitter mediano é praticamente 0 para todos os testes, o que mostra um comportamento bem regular das amostras, exceto pelo jitter mínimo e máximo que acabam distorcidos justamente em função das latências máximas muito fora da mediana em alguns casos.

8.5 ANÁLISE DOS RESULTADOS

De uma forma geral, a latência mediana dos diferentes protocolos de transporte é muito próxima em cada cenário de teste, exceto apenas no cenário

23 Não funciona para teste local (localhost). 24 Para teste local (localhost) somente para tcp são gerados esses gráficos.

158

VM_Local para multicast. Ou seja, a priori, não existe variação significativa que justifique o uso de um ou outro protocolo de transporte em detrimento dos demais. Os dados obtidos mostram coerência com tempos crescentes nessa ordem: comunicação local; comunicação entre Host e VM local; comunicação entre Hosts; comunicação entre VMs locais; comunicação entre Host e VM remota; e comunicação entre VMs remotas. A comunicação local (localhost), em particular, tanto para Host Linux quanto para VM com Guest-OS TinyCore mostraram os menores valores, o que era de se esperar, e muito próximos, exceto para multicast no cenário VM_Local. O custo maior da camada de virtualização pode ser evidenciado com o tempo maior de comunicação entre VMs locais e principalmente VMs remotas em comparação com a comunicação usual entre hosts. De qualquer forma, no pior caso, a mediana do tempo de comunicação entre VMs remotas ficou na faixa de 900 µs, ainda abaixo de 1 ms, o que não deixa de ser um bom resultado. Como mais de 95% das amostras tem latência muito próxima à mediana, o que pode ser comprovado pelos gráficos de densidade e quantiles, parece razoável considerar o percentil 95 como valor de referência para tempo de resposta. Dessa forma, serão considerados os seguintes tempos de referência em µs para cada cenário de teste, tomando-se o pior tempo percentil 95 dos protocolos de transporte da Tabela 3, conforme Tabela 4. Tabela 4 – Tempo de Referência [µs] por Cenário de Teste Tempo Teste Protocolo Resposta Host_Local 302 TCP Host-Host 625 RTPS Host-VM_L 510 mbe Host-VM_R 810 mbe VM_Local 350 TCP VM-VM_L 710 mbe VM-VM_R 990 mrel Condições tipo avalanche, sobrecarga de rede, falhas na rede, não foram contempladas. Testes desse tipo são normalmente executados para homologação e testes de aceitação de sistemas de missão crítica, conforme comentado na seção 6.1 CONSIDERAÇÕES INICIAIS. Importante frisar também que os testes foram executados em uma única sessão, não foram repetidos por várias sessões. No 159 entanto, como cada teste utiliza uma população de cerca de 11000 amostras ou mensagens, estatisticamente tem-se disponível uma boa representação de dados que caracterizam o experimento. Estes tempos, obviamente, não serviriam para o caso de tempo real crítico (hard real-time). Neste caso, poder-se-ia adotar o tempo máximo obtido na Tabela 1, ainda assim sem garantia de WCET. A repetibilidade poderia ajudar a obter um WCET como tempo máximo mais confiável, mas nunca exato. Outra possibilidade seria incluir mais pontos de medição, o que exigiria alterar código do SO e software de virtualização. Uma técnica baseada na teoria dos valores extremos, onde a curva de probabilidade obtida (histograma) é projetada na cauda até chegar em um pWCET (probabilistic WCET) com uma certa probabilidade, é apresentada em (Lima, et al., 2016) (K. P. Silva, 2017). De outra forma, só poderemos considerar aplicações PAC que aceitem um comportamento temporal dentro destes termos de 95%. Com o objetivo de tentar confrontar e de certa forma validar os resultados obtidos com testes similares do OpenDDS em ambiente virtualizado, foi feita também uma pesquisa inicial. De acordo com o site oficial25, “testes de desempenho da implementação do OpenDDS foram executados em vários ambientes”. Os resultados apresentados no site, no entanto, restringem-se a hosts com SO Linux Suse conectados em rede sem uso de virtualização. As latências informadas26 são inferiores a 40 µs, mesmo para mensagens maiores de até 32 kbytes, no caso de ambiente dedicado exclusivamente aos testes do OpenDDS com hardware de alta capacidade e SO Suse Linux Enterprise Server (SLES 10), ou seja, muito inferiores aos resultados aqui obtidos. No caso de ambiente onde os testes são executados com hardware e SO comuns, OpenSuse 9.1 compartilhando o host com outras atividades, similar ao ambiente de teste desta tese, a latência chega a 400 µs para mensagens de 32 kbytes, e cerca de 100 µs para mensagens de tamanho 250 bytes, usadas nos testes preliminares desta tese, ou seja, resultados mais coerentes e próximos aos resultados obtidos nesta tese. De trabalhos encontrados, (Rizano, et al., 2013) apresenta na Tabela I do artigo alguns resultados obtidos. Os testes realizados usaram placas panboard com

25 http://opendds.org/about/performance.html 26 http://opendds.org/perf/sgi100317/latency_results.html

160 plataforma de hardware embarcada baseada no OMAP4460 e núcleo ARM executando a 1Ghz e SO Linux Ubuntu 12.04, conectadas em rede, mas sem virtualização. No caso do OpenDDS, a latência média variou de 2 a 6 ms para três cenários de teste considerados, ou seja, bem acima dos resultados aqui obtidos. Embora não considerem virtualização, esses resultados permitem obter pelo menos um referencial numérico para comparação, uma ordem de grandeza. Uma análise mais detalhada exigiria, talvez, avaliar melhor o efeito da diferença de hardware, em particular, mas é possível considerar satisfatórios e representativos os resultados reportados na Tabela 2. Por fim, considerando a cadeia de medição (aplicação, DDS, Guest-OS, VM, Hypervisor e [Host-OS], Host-HW, rede) e as medições realizadas dos cenários de teste, foi feito um exercício para tentar inferir alguns resultados, ou mais especificamente, obter uma aproximação para os tempos de cada componente principal envolvido. Na seção 5.4.5 Definição de Tempo de Resposta Fim-a-Fim, foi proposto o seguinte cálculo para tempo de resposta:

(1) sendo:

– tempo fim-a-fim medido pelo DDS

– tempo de cada ponta / fim da camada DDS

– tempo da camada do Guest-OS

– tempo da camada de virtualização (VMM + hypervisor)

– tempo do host (SO + HW)

– tempo da rede Tomando-se os tempos medianos da Tabela 2 – Latência Mediana [µs] para tcp, podem-se considerar as aproximações da Tabela 5. Tabela 5 – Análise Tempo de Resposta

Teste TCP Componente Aproximação

Host_Local 289 DDS + Host-OS Host-Host 566 2 Host_Local + Rede Host-VM_L 451 VM_Local + VM + Host_Local Host-VM_R 740 VM_Local

VM_Local 309 DDS + Guest-OS VM-VM_L 638 2 VM_Local + Hypervisor VM-VM_R 901 161

Matematicamente, obtêm-se os seguintes resultados:

Fica claro que a determinação dos tempos por componente com base na fórmula proposta e aproximações feitas, sem medição explícita, não passa de um exercício teórico infrutífero, o que evidencia a aleatoriedade e dificuldade envolvidas. De qualquer forma, embora sejam resultados baseados em aplicação pura e simples do OpenDDS, é razoável considerar promissores esses resultados e o potencial da proposta, ou seja, da viabilidade de executar aplicações PAC IEC 61850 em ambiente distribuído e virtualizado, tese deste trabalho, ou pelo menos um subconjunto das mesmas.

162

9 RESULTADOS SEGUNDA ETAPA – CARACTERIZAÇÃO APLICAÇÃO PAC61850

Na primeira etapa (Capítulo 8) foi possível caracterizar o desempenho temporal fim-a-fim, a partir da camada do DDS, de aplicações publish-subscribe do OpenDDS se comunicando em diferentes níveis ou combinações Host-VM da arquitetura e ambiente de experimentação propostos. No final, a Tabela 4 – Tempo de Referência [µs] por Cenário de Teste permitiu definir um bound ou limite de tempo de referência que buscávamos, ainda que para aplicações PAC de tempo real mais leve ou que aceitem um comportamento temporal dentro do percentil 95% estabelecido. Esse limite de tempo conhecido de todo o meio de comunicação, aderente ao previsto na norma conforme Figura 20 – Definição de Tempo de Transferência, e atendendo os requisitos de tempo das aplicações PAC61850 com desempenho abaixo de 1 ms, a exceção de mensagens SMV, permite partir para a segunda etapa de caracterização do desempenho da aplicação PAC61850 definida no estudo de caso. O objetivo deste capítulo, portanto, a partir dos resultados satisfatórios obtidos na primeira etapa, é finalmente poder conhecer o comportamento temporal de todo um sistema PAC61850, seguindo, obviamente, a infraestrutura e ambiente de experimentação similares usados na primeira etapa, assim como a distribuição das aplicações em diferentes combinações de Host-VM.

9.1 CONSIDERAÇÕES INICIAIS

Durante a implementação do projeto descrito no estudo de caso (Capítulo 7), foi possível identificar duas funcionalidades importantes, não previstas inicialmente, para facilitar a verificação do comportamento esperado e a realização dos testes. A primeira diz respeito a implementação de um SOE (Sequence Of Events) ou sequência de eventos e inclusão de um monitor que permite registrar o SOE de todo sistema PAC61850, ou seja, registrar a sequência de todas as mensagens trocadas pelas aplicações. 163

A segunda diz respeito a necessidade de automatizar os testes para garantir a reprodução e alteração dos mesmos a qualquer momento. Para tanto, foi necessário criar um script que permite configurar os testes com os respectivos parâmetros, e um simulador que permite executar os testes de acordo com as configurações desejadas. Dessa forma, é possível reproduzir uma sequência de ações que seriam realizadas manualmente de forma automática, flexível, rápida e precisa, sem margem para erros. Outra funcionalidade crucial para a efetiva realização dos testes é o sincronismo de tempo.

9.2 CENÁRIOS DE TESTE

A caracterização temporal do estudo de caso será focada no comportamento do sistema PAC61850 proposto. Para tanto, são definidos os seguintes cenários de teste do Quadro 31 que visam definir o comportamento esperado. Quadro 31 – Cenários de Teste para o Estudo de Caso

Comportamento Esperado Teste SEP Sistema PAC61850 Normal Operação normal ou regime O sistema de automação PAC61850 deverá permanente do SEP. Nesta operar normalmente, com medições dos sinais, condição o sistema elétrico supervisão e controle. A proteção fica opera com a seccionadora SC1 continuamente verificando a corrente, sem e disjuntor DJ1 fechados. A atuar. corrente é a nominal ou IN. Comando Comando executado por um Nesta condição o sistema de automação deverá Manual operador a partir da IHM do bloquear a abertura da seccionadora SC1 caso sistema para abrir ou fechar a o circuito elétrico opere sob carga (regra de seccionadora SC1 ou disjuntor intertravamento para segurança operativa). O DJ1. disjuntor DJ1 poderá ser comandado a qualquer momento. Sobrecarga Situação de sobrecarga com Proteção temporizada 51 de tempo inverso corrente acima da nominal. através do vLN PTOC1 que deve atuar caso a corrente de pick-up (% sobrecarga) persistir por um tempo superior ao tempo de disparo . Falta Situação de curto-circuito Proteção instantânea 50 através do vLN PIOC1 oriunda de uma falta severa no que deve atuar imediatamente caso corrente de sistema elétrico. pick-up seja superada (Tempo Definido – DT). Em qualquer caso, as medições dos sinais de campo serão contínuas, através dos vLNs TVTR1 e TCTR1 para tensão e corrente, respectivamente, bem como a conversão dos valores amostrados através dos vLNs MMXU1 e MMXU2. No

164 caso de comandos manuais ou atuação TRIP da proteção, os vLNs XCBR1 e XSWI1 devem realizar a respectiva abertura ou fechamento do disjuntor DJ1 e seccionadora SC1, respectivamente. A IHM através do vLN IHMI1 deverá supervisionar continuamente o sistema e permitir os comandos manuais (SCADA).

9.3 IMPLEMENTAÇÃO DO AMBIENTE DE TESTES

Para cobrir as combinações possíveis identificadas no Quadro 26 – Relação de Testes Host-VM, é preciso ter ao menos cinco aplicações, ou cinco vApps. A partição feita no estudo de caso tem exatamente cinco vApps, não por acaso: SCADA; Medição; Proteção; Controle; e PIUs. A Figura 32 – Estudo de Caso: Nuvem IEC 61850 ilustra bem esse arranjo de vLDs mapeados para vApps. A alocação dessas vApps, baseada na Figura 37 – Arquitetura de Testes com Linux, KVM-QEMU, TinyCore e OpenDDS, foi feita da seguinte forma, incluindo o monitor do sistema:  PIUs e Simulador -> host app.sinuv; o Proteção -> VM1 ou vApp1.sinuv; e o Controle -> VM2 ou vApp2.sinuv.  Monitor -> host piu.sinuv; o Medição -> VM3 ou vApp3.sinuv; e o SCADA ou IHM -> VM4 ou vApp4.sinuv; A Figura 48 a seguir apresenta a arquitetura de testes resultante, com infraestrutura similar usada na primeira etapa baseada em duas máquinas físicas (hosts) com duas máquinas virtuais (VM) cada. A principal diferença é em relação às seis aplicações que serão executadas simultaneamente conforme divisão e alocação propostas. Outra diferença foi o uso do VirtualBox no lugar do KVM, visando avaliar outra alternativa de hypervisor hosted. A implementação do ambiente de testes, propriamente dito, é similar a realizada na primeira etapa. Detalhes mais específicos são apresentados no APÊNDICE E – Ambiente de Testes para o Estudo de Caso. Detalhes da lógica de negócio, funcionalidades e características especiais são descritos a seguir. 165

Figura 48 – Arquitetura de Testes do Estudo de Caso

vApp1.sinuv vApp2.sinuv vApp3.sinuv vApp4.sinuv 179.106.230.93 179.106.230.94 179.106.230.95 179.106.230.96 VM1 VM2 VM3 VM4 Protection Control Metering HMI OpenDDS OpenDDS OpenDDS OpenDDS TinyCore TinyCore TinyCore TinyCore QEMU QEMU QEMU QEMU vlocalhost / veth0 vlocalhost / veth0 vlocalhost / veth0 vlocalhost / veth0

KVM / VirtualBox KVM / VirtualBox PIU Linux OpenDDS Monitor Linux OpenDDS HW HW

Host 1 localhost / eth0 Host 2 localhost / eth0

app.sinuv NTP Time Server piu.sinuv 179.106.230.91 179.106.217.246 179.106.230.90

9.3.1 Funções de Proteção

No caso da proteção de sobrecorrente temporizada, o tempo “T” pode ser do tipo Tempo Definido (DT) ou Tempo Inverso, conforme Figura 49 abaixo27. Figura 49 – Exemplos de Curvas de Tempo Definido e Tempo Inverso para Proteção de Sobrecorrente (50/51)

Curva DT, normalmente aplicada na proteção contra curto-circuitos, significa que qualquer corrente acima do valor de partida ou pick-up irá fazer com que o relé ou função de proteção atue, dispare ou dê trip instantaneamente no tempo “T”. As curvas de tempo inverso, normalmente aplicadas para proteção contra sobrecarga, tem como característica diminuir o tempo de atuação conforme a

27 Schneider-Eletric: Boletim Técnico PMC – Novembro 2008

166

corrente do sistema aumenta acima de um determinado valor de pick-up ( ).

O ajuste de tempo “T” corresponde ao tempo de atuação para . Acima de

a curva de tempo inverso torna-se de tempo definido (constante), tratando a falta como um curto-circuito. Para tempo inverso, considerando uma curva IEC, pode-se calcular o tempo de disparo em função da corrente do sistema , como sendo:

(2) ( ) ( )

Para , conforme definido anteriormente. A questão, portanto, é definir os valores de e . Como o foco deste trabalho de doutorado é no comportamento temporal correto do sistema, não é necessário implementar algoritmos reais de proteção. É suficiente adotar um ajuste de corrente de pick-up que permita disparar a condição de falta e respeitar o tempo limite de atuação normalmente aplicado. Em outras palavras, não é necessário seguir curvas típicas de sobrecorrente, o que exigiria utilizar sinais de corrente que retratam condições reais de campo, e.g., um arquivo COMTRADE ou simulador de sistemas de potência tipo RTDS (Real-Time Digital Simulator), para maior efetividade dos testes. O uso diretamente da fórmula anterior ou uma simples tabela com tempo de disparo calculado para alguns pontos de atuação para diferentes valores de corrente do sistema seria uma abordagem simples e suficiente para implementar a função de sobrecorrente temporizada. A proteção instantânea para curto-circuito é um caso da curva de tempo definido, pois basta a corrente do sistema ultrapassar o ajuste de pick-up, ou

, para a proteção atuar instantaneamente, ou seja, . Por isso costuma-se plotar no mesmo gráfico ou coordegrama a curva de tempo definido logo após o ponto na sequência da curva de tempo inverso, comtemplando assim as duas funções 50/51. Na prática, a parametrização da função de proteção de sobrecorrente instantânea é feita com , embora as curvas ou coordegramas dos fabricantes de relés mostrem o tempo real da retirada da falha (na faixa de 30 ms ou menos e até 50 ms), pois levam em consideração alguns tempos envolvidos no processamento do sinal e fechamento da saída do relé. 167

9.3.2 Sequência de Eventos

Para permitir obter um comportamento medido de todo o sistema PAC61850 e comparar com o comportamento esperado, foi incluído um novo DomainParticipant no projeto do modelo DDS. Um monitor ou log do sistema que subscreve todos os tópicos, ou seja, que monitora por completo todo evento gerado no sistema pelos vLNs. Dessa forma, é possível implementar um SOE (Sequence of Events), funcionalidade muito importante e comum em sistemas tipo SCADA e outros sistemas de automação no setor elétrico com resolução de estampa de tempo normalmente próxima a 1 ms. Com um SOE deve ser possível reconstruir ou verificar exatamente tudo o que aconteceu no sistema automatizado, ou seja, os eventos na correta sequência temporal em que cada um ocorreu. Observa-se o comportamento medido vs esperado. Ou seja, eventuais falhas ou divergências do comportamento medido em relação ao esperado ficam mais fáceis de serem detectados com um SOE. No estudo de caso os eventos seriam cada mensagem ou dado publicado pelos vLNs nos tópicos que representam os DataObjects (DO) previstos no modelo de dados da norma IEC 61850. Dessa forma, o monitor coleta e apresenta o histórico completo de todos os eventos ou dados que são gerados em tempo real pelo sistema PAC61850. Cada evento é registrado com os seguintes campos:  TimeStamp que mostra a estampa de tempo da fonte (publisher) e da recepção (subscriber) com resolução de us (hh:mm:ss:uuuuuu), o que permite obter diretamente a latência;  # que mostra um número sequencial gerado por cada publisher, ou seja, vLN;  Topic que identifica qual a origem do evento - vLN e o DO; e  Mensagem que apresenta um ou mais atributos do Dado, conforme levantamento feito no Quadro 24 – CDCs, Atributos, Tipos e FC dos Dados dos LNs e Quadro 25 – Definição dos Tipos Especiais.

168

O SOE acaba sendo a fonte de dados de todos os testes. Por isso, todos os módulos do sistema fazem o registro dos eventos que são mostrados em uma GUI local da aplicação e exportados para um arquivo .csv ao final de cada teste. Os eventos recebidos ou subscritos indicam o tempo de origem no instante que a mensagem fonte foi enviada e o tempo no instante que essa mensagem é recebida, conforme descrito em 9.5 MEDIÇÃO DE LATÊNCIA. Eventos de mensagens publicadas mostram apenas o tempo no instante antes de serem enviadas, ou seja, o tempo de origem do lado que recebe ou subscreve essa mensagem. Abaixo um exemplo de evento registrado pelo módulo proteção com tempo de simulação 2 ms.

TimeStamp [hh:mm:ss:uuuuuu] Latência [us] # vLN-DO Topic Mensagem [13:12:24.046346][13:12:24.047545] 1199 487726 tctr1AmpSv 10000.1 [13:12:24.046346][13:12:24.047803] 1457 487726 tctr1AmpSv 10000.1 [13:12:24.048134] 149 pioc1Op 1 [13:12:24.048134][13:12:24.048518] 384 149 pioc1Op 1 [13:12:24.048951] 3310 ptrc1Op 1 [13:12:24.054828][13:12:24.055568] 740 487728 tctr1AmpSv 0 Este registro mostra uma condição de curto-circuito. A corrente do sistema medida pelo tópico tctr1AmpSv (DataObject (DO) AmpSv do vLN tctr1 usado para transmitir valores primários de corrente do TC1 como valores amostrados

(SMV)), está acima do valor de pick-up definido para . Dessa forma, a função 50 de proteção de sobrecorrente instantânea, representada pelo tópico pioc1Op (vLN pioc1), deve atuar, conforme registro do 3º evento que mostra o DO Op atuado em 1. O TRIP, propriamente dito, está registrado como o penúltimo evento no qual o tópico ptrc1Op (vLN ptrc1) recebeu a saída de operação (DO Op) da função de proteção pioc1, e transmite ou publica através da sua saída Op atuada em 1. Esse TRIP será recebido ou subscrito pelo tópico cswi1Pos (vLN cswi1) que irá atuar sobre o tópico xcbr1Pos (vLN xcbr1) que irá finalmente enviar o comando de abrir o disjuntor DJ1. O último evento indica que a corrente do sistema foi zerada, ou seja, que a abertura do disjuntor DJ1 ocorreu como desejado. Esse é o comportamento esperado conforme o design da Figura 29 – Estudo de Caso: Projeto Desenho Lógico IEC 61850 e modelo DDS da Figura 35 – DcpsLib: Mapeamento OpenDDS da Aplicação PAC61850 que realizam o sistema PAC61850 do sistema elétrico de potência (SEP) da Figura 27 – Estudo de Caso: Projeto Aplicação SEP - Proteção de Bay. 169

9.3.3 Simulador

A necessidade de repetição de testes ou simples sequências de ações resultou na criação de um script de testes. O script, baseado na estrutura simples de um arquivo de configuração tipo .ini, permite configurar diferentes testes com os seguintes parâmetros:  time que define o tempo de simulação do sistema;  samples que define a quantidade de repetições do teste;  curve que define o tipo curva de proteção de sobrecorrente (instantânea ou tempo inverso IEC / IEEE);  tdm ou multiplicador de tempo que define o tempo de atuação da proteção de acordo com a curva de tempo inverso selecionada; e  IfIpickup que define a relação entre corrente de falta e corrente de pick-up ou limiar acima do qual a função de proteção começa a contar o tempo. Abaixo um exemplo de script com 2 testes configurados: [tests] 0/time=20 0/curve=INSTANTANEOUS 0/tdm= 0/ifipickup= 0/samples=10 1/time=20 1/curve=IEEE_EI 1/tdm=0.5 1/ifipickup=2.0 1/samples=10 O simulador basicamente carrega os testes configurados no script e executa um a um com as respectivas configurações, que também podem ser feitas manualmente através da GUI do simulador. Por conveniência, o simulador foi implementado juntamente com o módulo ou aplicação das PIUs, uma vez que as mesmas são o ponto de interface do sistema PAC61850 com o processo ou campo, neste caso simulado.

9.3.4 Sincronismo de Tempo

Sincronismo de tempo é parte fundamental de sistemas de automação. A resolução ou padrão exigido depende dos requisitos da aplicação. Sincrofasores ou

170

Phasor Measument Unit (PMU), por exemplo, exigem resolução de até 1 µs através de IRIG-B, e mais recentemente o padrão IEEE 1588 ou Precision Time Protocol (PTP) oferece resolução de até 200 ns. Sistemas tipo SCADA, por sua vez, suportam Network Time Protocol (NTP) com resolução de até 1 ms. Para a aplicação do estudo de caso, a priori não seria usado um sistema de sincronismo de tempo. Porém, testes preliminares mostraram um escorregamento (skew) e variações significativas entre os relógios das VMs e hosts, comprometendo o cálculo da latência a partir da diferença entre o tempo da fonte e da recepção para mensagens subscritas. Na primeira etapa (Capítulo 8) dos testes isso não foi um problema, pois o cálculo da latência foi feito computando-se o tempo de ida e volta (round-trip) da mensagem, ou seja, relógio único e mesma aplicação. Para uma aplicação real, como a proposta do estudo de caso, não faz sentido enviar e esperar receber a mesma mensagem ou dado, ou mesmo um simples ACK (Acknowledge) que é suportado pelo DDS. Além de complicar desnecessariamente a implementação da aplicação, com threads no nível da aplicação, o processamento acaba sendo desviado e concorrendo com as funções esperadas. Dessa forma, buscando ser o mais fiel possível a sistemas similares reais, foi implantado sincronismo de tempo NTP:  Servidor de tempo Meinberg modelo M600 sincronizado com antena GPS;  Serviço ntpd nos hosts sincronizado com o servidor de tempo; e  Cliente ntpclient no Guest-OS TinyCore das VMs. Embora as medições sejam com resolução de µs, ou seja, não suportado pelo NTP, foi possível obter resultados satisfatórios nos testes realizados, com skews muito bons reportados pelo ntpclient variando na faixa de dezenas a centenas de µs e esporadicamente até 1 a 3 ms, possivelmente em função da rede simples de apenas 2 hosts, apesar do hypervisor. Alternativas como o PTP, por exemplo, que tem resolução muito superior e é suportado também pelo mesmo servidor de tempo, dependeriam de um cliente no nível do Guest-OS, além de uma placa dedicada no host. Ou seja, diante da impossibilidade imposta pelo Guest-OS TinyCore, só restou a opção pelo NTP. 171

Importante destacar que sem o cliente ntpclient, não seria possível obter resultados conclusivos. No lugar de corrigir os relógios, seria necessário pensar em alguma outra forma de compensar o escorregamento e variação dos relógios.

9.3.5 Programação Orientada a Eventos (Event-Driven)

Graças ao uso de um middleware de comunicação como o DDS, a programação da aplicação torna-se significativamente simplificada em vários aspectos. Particularmente no que diz respeito a recepção de mensagens, não é necessário criar threads para cada DataReader de cada tópico. Basta implementar listeners. Threads ficam restritas a implementação do OpenDDS.

9.3.6 Simplificações Adotadas

Com relação à adoção da norma IEC 61850, a concepção inicial, conforme Figura 25 – Arquitetura em Camadas proposta, previa a implementação de um framework IEC 61850 a partir do qual o modelo de instância (ver Figura 30 – Estudo de Caso: Projeto Parcial Modelo UML IEC 61850) da aplicação seria criado. Como o modelo DDS (ver Figura 35 – DcpsLib: Mapeamento OpenDDS da Aplicação PAC61850) já incorpora o modelo de dados definido pela norma, e como o foco da tese é a caracterização temporal centrada nos dados, a implementação da lógica de negócio, ou seja, funções de proteção de sobrecorrente e intertravamento, acabou sendo realizada em classes simples que foram integradas com o modelo do mapeamento SCSM DDS. Em outras palavras, a aderência à norma IEC 61850 limitou-se ao mapeamento do DDS. Embora esse design possa não ser o ideal do ponto de vista de engenharia de software e nem atenda a expectativa de maior aderência ou compatibilidade com a norma IEC 61850, alguns pontos merecem ser destacados. Primeiro, o SCSM DDS resolve de uma só vez o problema de comunicação em si (SCSM) e da ACSI, esperados em uma aplicação típica conforme Figura 30 – Estudo de Caso: Projeto Parcial Modelo UML IEC 61850. Segundo, embora mecanismos de QoS não tenham

172 sido explorados na implementação e testes do estudo de caso, os mesmos poderiam ser avaliados como alternativa ao mecanismo baseado em Control Blocks (CB). Ou mesmo protocolos de transporte mais confiáveis. Outras funcionalidades como Functional Constraints (FC), apesar de incorporadas no modelo DDS, mas não implementadas na aplicação, teriam de ser melhor avaliadas. Com relação ao OpenDDS, tcp foi o único protocolo de transporte utilizado. A razão principal é simplificar a quantidade e tempo com os testes realizados. QoS também acabou não sendo avaliado e testado, pois aumentaria significativamente a quantidade de testes e dependeria de infraestrutura adequada. Com relação à função de proteção de sobrecorrente, foram implementadas tabelas com pontos específicos de atuação em função da curva, multiplicador de tempo (tdm) e corrente de pick-up. Ou seja, a função de proteção atua somente em faixas ou valores fixos de correntes de falta. Com relação ao simulador, as correntes “geradas” são magnitude constante, ou seja, são valores fixos que disparam as funções de proteção de acordo com a configuração de proteção do teste executado. O tempo de simulação foi especificado para um sistema elétrico de 50 Hz, com o único propósito de obter valores inteiros para um ciclo de 20 ms, ao invés de 16,67 ms para um sistema elétrico de 60 Hz. Dessa forma, os testes foram realizados para 3 diferentes tempos:  20 ms ou 1 amostra por ciclo;  10 ms ou 2 amostras por ciclo; e  2 ms ou 10 amostras por ciclo. A razão desses valores é em função, primeiro, da limitação da infraestrutura computacional subjacente que não suportaria trabalhar com tempos abaixo de 1 ms, mas também da necessidade da aplicação principal de proteção de sobrecorrente. Muitos algoritmos de proteção conseguem trabalhar com 8 a 10 amostras por ciclo para realizar a função pretendida. Sobrecorrente sendo um dos mais simples. E valores múltiplos ou submúltiplos de um ciclo são comuns em SEP.

9.4 TESTES REALIZADOS

Dos comportamentos esperados no Quadro 31, foram feitos testes isolados de comandos de abertura e fechamento de disjuntor e seccionadora a partir da IHM, 173 com o simples intuito de verificar o intertravamento previsto. O que ocorreu corretamente. Os testes de proteção de sobrecorrente foram configurados em 3 scripts para 14 casos de teste que são executados 10 vezes (samples) consecutivas para os 3 diferentes tempos de simulação de 20 ms, 10 ms e 2 ms. Os casos de teste são os descritos na Tabela 6. Tabela 6 – Casos de Teste dos Experimentos com o Estudo de Caso

Caso Teste Curva tdm If/Ipick-up Tempo [s] 0 Instantâneo - - 0 1 IEEE_EI 0.5 2.0 4.761 2 IEEE_EI 4.0 6.0 3.707 3 IEEE_VI 1.0 4.0 1.797 4 IEEE_VI 8.0 8.0 6.415 5 IEEE_MI 2.0 4.0 3.891 6 IEEE_MI 6.0 8.0 7.961 7 IEC_A 0.05 2.0 0.501 8 IEC_A 1.0 4.0 4.980 9 IEC_B 0.10 6.0 0.270 10 IEC_B 0.80 8.0 1.543 11 IEC_C 0.20 2.0 5.333 12 IEC_C 0.40 4.0 2.133 13 IEC_SI 0.40 6.0 0.269 14 IEC_SI 0.60 8.0 0.345

9.5 MEDIÇÃO DE LATÊNCIA

A Figura 50 detalha como a latência fim-a-fim é medida para o estudo de caso a partir da camada do DDS, diferente da medida do tempo de round-trip realizada na caracterização preliminar do DDS. Os trechos de código destacam os pontos principais. Imediatamente antes de uma mensagem ser enviada pelo lado publisher, a função getNow() é chamada para obter o tempo corrente com resolução de µs. Este tempo é salvo na estrutura SampleInfo do tópico. Assim que essa mensagem é recebida pelo lado subscriber, o tempo corrente local é obtido também através da chamada getNow(). O tempo da fonte é obtido na info do tópico. A latência fim-a-fim em µs é a diferença entre esses tempos. O script ntp (clock) mostra que o sincronismo de tempo é realizado a cada 10 s.

174

Figura 50 – Medição de Latência para o Estudo de Caso

9.6 RESULTADOS OBTIDOS

Para obter os resultados do estudo de caso foram utilizados testes automatizados baseados nos 3 scripts de teste. Os resultados obtidos são apresentados para os tempos de simulação de 2 ms, 10 ms e 20 ms para ambos os cenários de teste host local e distribuído. Sincronismo de tempo para o cenário distribuído é realizado através do serviço NTP executando um cliente a cada 10 s. As Tabela 7, Tabela 8 e Tabela 9 apresentam os dados das medições e estatísticas calculadas para ambos os cenários Local | Distribuído e tempos de simulação de 2 ms, 10 ms e 20 ms, respectivamente. Essas tabelas mostram, para cada tópico de cada módulo do sistema, ou seja, para cada DO-vLN de cada vLD, a quantidade de amostras ou mensagens recebidas ou subscritas. Para as mensagens subscritas, as latências máxima, mínima, mediana, MAD (median absolute deviation) e percentils 95 e 99 são calculadas em µs. Do total de mensagens recebidas, calcula-se também a quantidade de mensagens que chegam com atraso. Para as mensagens publicadas, somente a quantidade de amostras publicadas é calculada. Não existe mensagem perdida. Mas algumas mensagens subscritas, com tempo de origem anterior, são recebidas com atraso, ou seja, após uma mensagem com tempo de origem posterior. 175

Tabela 7 – Latências para Tempo de Simulação de 2 ms (Local | Distribuído) Módulo Tópico Samples Max Min Mediana MAD Perc-95 Perc-99 cswi1Pos 598 | 3566 9040 | 8514 191 | 116 420 | 656 160 | 257 2644 | 2370 5160 | 4488 598 Delayed samples: 0/598 = 0% | 0/3566 = 0% ptoc1Params 14 Piu tctr1AmpSv 196485 | 219136 tvtr1VolSv 150 xcbr1Pos 0598 | 2083 pioc1Op 33 | 38 3356 | 1015 214 | 170 413 | 293 130 | 088 3276 | 0941 3351 | 1009 ptoc1Op 0266 | 1745 9547 | 2429 176 | 146 531 | 260 207 | 084 3759 | 0751 5417 | 1188 ptoc1Param 14 6850 | 2462 265 | 214 906 | 685 602 | 389 6486 | 1692 6777 | 2308 tctr1AmpSv 392970 | 438272 25161 | 10304 201 | 068 673 | 490 257 | 196 3770 | 1830 6902 | 2757 prot 393283 Delayed samples: 25/393283 ≈ 0,01% | 154/440069 ≈ 0,03% pioc1Op 33 | 38 ptoc1Op 0266 | 1745 ptrc1Op 0299 | 1783 ciloEnaOpn 0598 | 2083 8943 | 4403 173 | 152 446 | 338 202 | 116 2971 | 0942 6310 | 1867 ptrc1Op 0299 | 1783 07776 | 12425 183 | 479 419 | 969 133 | 335 1539 | 4145 3605 | 7839 xcbr1Pos 0598 | 2083 14160 | 09662 229 | 382 0543 | 1002 220 | 288 3496 | 3948 7142 | 7209 control 1495 Delayed samples: 54/1495 ≈ 3,61% | 230/5949 ≈ 3,87% cilo1EnaOpn 0598 | 2083 cswi1Pos 0299 | 1783 mmxu1PhV 150 16736 | 04571 188 | 373 560 | 784 283 | 306 3221 | 2429 10699 | 04286 mmxu2A 196485 | 219136 16506 | 33393 157 | 291 388 | 664 152 | 213 2507 | 2485 4919 | 3938 ihm xcbr1Pos 0598 | 2083 11120 | 09968 188 | -496 494 | 281 218 | 298 4670 | 2508 7602 | 4262 197233 Delayed samples: 42/197233 ≈ 0,02% | 349/221369 ≈ 0,16% tctr1AmpSv 196485 | 219136 14836 | 21490 178 | -487 503 | 219 194 | 276 3439 | 1871 6329 | 3400 tvtr1VolSv 150 11152 | 04414 234 | -435 411 | 151 117 | 276 4537 | 1971 8023 | 3510 med 196635 Delayed samples: 0/196635 = 0% | 0/219286 = 0% mmxu1PhV 150 mmxu2A 196485 | 219136 cilo1EnaOpn 0598 | 2083 24555 | 04564 156 | 238 1086 | 0731 751 | 213 7624 | 1874 14302 | 03088 cswi1Pos 0299 | 1783 16033 | 05709 157 | 129 1429 | 0463 1120 | 0137 9051 | 1638 14454 | 03392 mmxu1PhV 150 20989 | 02944 172 | 629 1817 | 0993 1152 | 0118 8640 | 1788 17235 | 02630 mmxu2A 196485 | 219136 25400 | 23236 141 | 615 498 | 967 277 | 105 3969 | 1672 7507 | 2969 pioc1Op 33 | 38 6221 | 2297 185 | 646 0425 | 1014 226 | 297 3518 | 1961 5414 | 2250 monitor ptoc1Op 0266 | 1745 20101 | 07474 155 | 446 1178 | 0867 886 | 188 8559 | 1926 15214 | 03053 ptrc1Op 0299 | 1783 19371 | 05095 158 | 406 996 | 737 750 | 144 7351 | 1829 13102 | 02791 tctr1AmpSv 196485 | 219136 26801 | 21482 154 | 142 700 | 527 349 | 122 4928 | 0950 8576 | 1957 tvtr1VolSv 150 27044 | 03005 188 | 183 1080 | 0431 793 | 103 7746 | 0886 13154 | 02784 xcbr1Pos 0598 | 2083 15461 | 04847 169 | 145 1056 | 0484 726 | 124 8511 | 1345 12080 | 02950 395363 Delayed samples: 21561/395363 ≈ 5,45% | 46816/448087 ≈ 10,45% Tabela 8 – Latências para Tempo de Simulação de 10 ms (Local | Distribuído) Módulo Tópico Samples Max Min Mediana MAD Perc-95 Perc-99 cswi1Pos 312 | 506 9040 | 4686 191 | 330 420 | 885 160 | 191 2644 | 1689 5160 | 4014 312 Delayed samples: 0/312 = 0% | 0/506 = 0% ptoc1Params 14 piu tctr1AmpSv 44445 | 44475 tvtr1VolSv 150 | 150 xcbr1Pos 456 | 553 pioc1Op 16 | 21 2998 | 0710 346 | 206 538 | 428 090 | 146 1752 | 0696 2749 | 0707 ptoc1Op 140 | 232 4096 | 1475 241 | 149 487 | 365 162 | 101 2369 | 0760 3769 | 1130 ptoc1Params 14 1351 | 1392 252 | -106 401 | 223 115 | 148 1347 | 0741 1350 | 1262 tctr1AmpSv 88890 | 88950 10631 | 05933 332 | -53 830 | 522 199 | 134 2579 | 1624 4330 | 2543 prot 89060 Delayed samples: 0/89060 = 0% | 5/89217 = 0,01% pioc1Op 16 | 21 ptoc1Op 140 | 232 ptrc1Op 156 | 253 cilo1EnaOp 456 | 553 7561 | 2534 190 | 152 578 | 437 225 | 126 2057 | 0987 3826 | 1686 ptrc1Op 156 | 253 2646 | 4202 257 | 658 0405 | 1264 087 | 227 1230 | 2793 2309 | 3838 control xcbr1Pos 456 | 553 15302 | 06470 183 | 262 575 | 967 241 | 287 3765 | 2642 6576 | 4519 1068 Delayed samples: 15/1068 ≈ 1,40% | 20/1359 ≈ 1,47%

176

cilo1EnaOpn 456 | 553 cswi1Pos 156 | 253 mmxu1PhV 150 5338 | 4115 185 | 528 0620 | 1000 207 | 330 1831 | 2658 4829 | 3552 mmxu2A 44445 | 44475 8993 | 9507 166 | 484 0570 | 1260 165 | 277 1500 | 2593 2923 | 3535 ihm xcbr1Pos 456 | 553 15235 | 05085 162 | -366 486 | 413 212 | 277 3687 | 1890 6126 | 3212 45051 Delayed samples: 13/45051≈ 0,03% | 21/45178 ≈ 0,05% tctr1AmpSv 44445 | 44475 8957 | 8598 220 | -307 632 | 469 103 | 236 2188 | 1725 3847 | 2743 tvtr1VolSv 150 5101 | 2927 219 | -475 423 | 166 133 | 159 3516 | 1457 4269 | 2470 med 44595 Delayed samples: 0/44595 = 0% | 0/44625 = 0% mmxu1PhV 150 mmxu2A 44445 | 44475 cilo1EnaOpn 456 | 553 10390 | 04845 152 | 310 641 | 958 272 | 236 3375 | 1773 6061 | 2381 cswi1Pos 156 | 253 7509 | 2610 201 | 163 365 | 574 141 | 170 3262 | 1085 6414 | 1352 mmxu1PhV 150 10314 | 03943 218 | 676 900 | 959 418 | 203 5364 | 1493 7512 | 2183 mmxu2A 44445 | 44475 10551 | 08585 186 | 645 0611 | 1126 204 | 179 2021 | 1566 3800 | 1930 pioc1Op 16 | 21 2697 | 1965 300 | 989 0513 | 1424 194 | 082 1987 | 1763 2555 | 1924 monitor ptoc1Op 140 | 232 4794 | 3401 213 | 664 0406 | 1142 157 | 219 2779 | 1864 4530 | 2447 ptrc1Op 156 | 253 6782 | 2949 162 | 591 0286 | 1168 116 | 197 2938 | 1773 4137 | 2540 tctr1AmpSv 44445 | 44475 11579 | 08452 214 | 167 757 | 660 209 | 066 2694 | 0872 4456 | 1313 tvtr1VolSv 150 7619 | 1528 217 | 140 627 | 269 295 | 067 4857 | 0538 6369 | 0715 xcbr1Pos 456 | 553 15260 | 02971 257 | 144 977 | 404 485 | 125 6293 | 0810 8393 | 1473 90570 Delayed samples: 831/90570 ≈ 0,92% | 1760/91115 ≈ 1,93% Tabela 9 – Latências para Tempo de Simulação de 20 ms (Local | Distribuído) Módulo Tópico Samples Max Min Mediana MAD Perc-95 Perc-99 cswi1Pos 302 | 300 6847 | 3530 284 | 660 0618 | 1006 189 | 111 2390 | 1388 5092 | 1516 302 Delayed samples: 0/302 = 0% | 0/300 = 0% ptoc1Params 14 piu tctr1AmpSv 22522 | 22523 tvtr1VolSv 150 xcbr1Pos 451 | 450 pioc1Op 11 | 10 813 | 800 304 | 268 373 | 460 67 | 94 774 | 749 805 | 790 ptoc1Op 140 3799 | 0781 222 | 251 375 | 326 117 | 062 1157 | 0575 1723 | 0757 ptoc1Params 14 5552 | 2081 302 | 019 446 | 263 129 | 140 3537 | 1296 5149 | 1924 tctr1AmpSv 45044 | 45046 08796 | 12228 416 | 046 795 | 659 143 | 193 1838 | 1592 3012 | 2594 prot 45209 Delayed samples: 0/45209 = 0% | 0/45210 = 0% pioc1Op 11 | 10 ptoc1Op 140 ptrc1Op 151 | 150 cilo1EnaOpn 451 | 450 5844 | 3689 167 | 150 500 | 452 156 | 104 1192 | 0928 3091 | 1515 ptrc1Op 151 | 150 2351 | 2799 0258 | 1025 0394 | 1224 059 | 116 0962 | 1779 1656 | 2579 xcbr1Pos 451 | 450 5825 | 6389 205 | 217 0667 | 1040 242 | 399 2341 | 3428 3849 | 4302 control 1053 Delayed samples: 20/1053 ≈ 1,90% | 6/1050 ≈ 0,57% cilo1EnaOpn 451 | 450 cswi1Pos 151 | 150 mmxu1PhV 150 5860 | 3699 213 | 659 0621 | 1269 176 | 260 2927 | 2682 5449 | 3517 mmxu2A 22522 | 22523 7307 | 9728 206 | 768 0393 | 1349 059 | 241 1024 | 3115 2248 | 3944 ihm xcbr1Pos 451 | 450 8788 | 3282 156 | -416 559 | 441 218 | 272 2814 | 1848 6076 | 2681 23123 Delayed samples: 12/23123 ≈ 0,03% | 15/23123 ≈ 0,06% tctr1AmpSv 22522 | 22523 6525 | 9139 318 | -133 626 | 552 059 | 175 1200 | 1352 2190 | 2755 tvtr1VolSv 150 3837 | 3537 195 | -427 403 | 072 101 | 144 2175 | 1464 3616 | 2463 med 22672 Delayed samples: 0/22672 = 0% | 0/22673 = 0% mmxu1PhV 150 mmxu2A 22522 | 22523 cilo1EnaOpn 451 | 450 7530 | 4496 215 | 487 0659 | 1159 201 | 195 3179 | 1833 5546 | 2875 cswi1Pos 151 | 150 8145 | 1645 268 | 505 881 | 665 437 | 074 4660 | 0896 6812 | 1309 mmxu1PhV 150 6519 | 2752 272 | 739 0758 | 1254 285 | 144 3004 | 1643 4589 | 2337 mmxu2A 22522 7708 | 8792 225 | 799 0414 | 1286 108 | 151 1450 | 1651 3402 | 1846 pioc1Op 11 1780 | 1953 0348 | 1264 0562 | 1534 201 | 133 1710 | 1952 1766 | 1953 monitor ptoc1Op 140 4488 | 3556 0280 | 1080 0614 | 1376 185 | 141 1663 | 1718 3402 | 2002 ptrc1Op 151 7332 | 2405 199 | 864 0521 | 1069 193 | 101 2947 | 1539 5353 | 2243 tctr1AmpSv 22522 7615 | 8499 309 | 423 649 | 831 83 | 74 1673 | 1049 3024 | 1217 tvtr1VolSv 150 5127 | 2359 222 | 107 618 | 322 276 | 064 3572 | 0644 4786 | 1548 xcbr1Pos 451 7497 | 2924 240 | 131 857 | 479 344 | 156 4074 | 0887 5786 | 1072 46699 Delayed samples: 501/46699 ≈ 1,07% | 86/46696 ≈ 0,18% 177

A Tabela 10 apresenta as variações mínima-máxima das latências mediana e percentil 95 obtidas no nível de tópicos a partir das Tabela 7, Tabela 8 e Tabela 9. Tabela 10 – Estudo de Caso: Latência Mediana e Percentil 95 [µs] nível Tópicos (DO-vLNs)

Tempo Mediana Percentil 95 Simulação Local Distribuído Local Distribuído 2 ms 388-1817 151-1014 1539-9051 751-4145 10 ms 286-977 166-1424 1230-6293 538-2793 20 ms 373-857 72-1534 774-4660 575-3428 A faixa de variação da mediana não apresenta diferenças significativas para os diferentes tempos de simulação. O percentil 95, por sua vez, apresenta valores máximos maiores para o tempo de simulação de 2 ms, o que denota a limitação da infraestrutura subjacente. Para ambos os cenários local e distribuído, gráficos das latências e jitter são plotados usando a ferramenta gnuplot para os 3 tempos de simulação diferentes. Dois tipos de gráficos são gerados: um que mostra as latências e jitter por amostra e a respectiva distribuição para cada módulo do sistema; e outro que mostra os quantiles das latências por módulo. Os resultados em forma gráfica apresentados aqui focam no tempo de simulação de 2 ms, pois trata-se do tempo mais crítico e mais próximo da aplicação real de proteção, suportando até 10 amostras por ciclo de 50 Hz. As Figura 51 e Figura 52 mostram os resultados obtidos no nível de cada módulo, ou vLD, que possui um mais tópicos (vLNs), para o cenário de teste local com tempo de simulação de 2 ms. As Figura 53 e Figura 54 para o cenário distribuído a 2 ms. O título dos gráficos também mostra entre parênteses o tempo total transcorrido do teste, superior a 7 minutos. O gráfico de quantiles também mostra o limiar do tempo de transferência da norma IEC 61850 (3 a 4 ms), ou requisito de tempo esperado, bem como os percentiles 95 e 99. A legenda desse gráfico mostra o nome do módulo e a respectiva quantidade de mensagens recebidas para cada curva plotada. O gráfico está ampliado a partir do percentil 80 para mostrar melhor a região crítica de interesse, ou seja, após a latência mediana. O APÊNDICE F – Resultados Estudo de Caso apresenta os gráficos dos demais módulos do sistema para o teste distribuído e tempo de simulação de 2 ms. O principal a se observar são algumas latências com valor mínimo negativo (vide

178

Tabela 7) devido ao uso de sincronismo de tempo para evitar erro sistemático e cumulativo de desvio de tempo, mas que alguns poucos casos ocasiona diferença negativa de tempo entre publishers e subscribers. Figura 51 – Estudo de Caso: Gráfico de Latência e Jitter para o Teste Local e Tempo Simulação de 2ms

Figura 52 – Estudo de Caso: Gráfico de Quantiles de Latência por Módulo para o Teste Local e Tempo Simulação de 2ms

179

Figura 53 – Estudo de Caso: Gráfico de Latência e Jitter para o Teste Distribuído e Tempo Simulação de 2ms

Figura 54 – Estudo de Caso: Gráfico de Quantiles de Latência por Módulo para o Teste Distribuído e Tempo Simulação de 2ms

180

9.7 ANÁLISE DOS RESULTADOS

De maneira direta e simples, o modelo DDS da Figura 35, descrito em 7.1.5 Projeto DDS e 7.2.3 Modelo DDS, mostra o problema de comunicação como um todo em um único diagrama a partir do ponto de vista de um sistema centrado nos dados (data-centric), ou seja, os tópicos. Na perspectiva de projeto, esta visão clara apresenta um conhecimento completo e nenhuma dúvida de quais e como os dados são trocados entre publishers e subscribers. Na perspectiva de implementação, DDS simplifica e padroniza a codificação. Threads são restritas a camada do middleware de comunicação graças ao uso de event-driven listeners. Na perspectiva do usuário ou operação, a instância do monitor, em particular, demonstra como o DDS torna mais fácil prover um sistema capaz de monitorar os dados de uma aplicação PAC, e calcular e mostrar estatísticas em tempo real em painéis de controle de um sistema centralizado de monitoração e gestão de ativos. Em outras palavras, DDS torna possível visualizar e rastrear em tempo real qualquer inconsistência ou degradação da comunicação que poderia afetar ou impactar o sistema PAC. Dessa forma, equipes de operação ou manutenção poderiam tomar medidas antes que um problema mais severo possa ocorrer. Esta capacidade deveria ser crucial para uma verdadeira e completa transformação digital em soluções e tecnologias PAC. O uso da capacidade de QoS do DDS, não explorado neste trabalho, poderia melhorar ainda mais a confiabilidade e segurança de um sistema PAC. Estes objetivos alcançados respondem a questão 2 do objetivo geral, ou seja, o ambiente de experimentação proposto foi capaz de permitir a avaliação da questão secundária de Engenharia de projeto (design), cujo objetivo era avaliar e comparar a arquitetura convencional versus a virtualizada, e a comunicação convencional via pilha de protocolos versus middleware de comunicação. Com relação à variação de latência entre os cenários de teste, não existe uma maneira direta de encontrar as razões ou causas. Existem muitas variáveis a serem consideradas, sendo o sincronismo de tempo uma questão importante para a medida da diferença de tempo ou latência. A quantidade de mensagens ou amostras geradas tem um impacto direto, tanto no nível do tópico quanto no desempenho de 181 um módulo como um todo. Para simulação de 2 ms ou 10 amostras por ciclo, a infraestrutura subjacente mostra claramente suas limitações. A latência máxima alcança mais de 4 ms e até 20 ms e 30 ms em alguns poucos casos. O uso de sincronismo de tempo pode levantar algumas questões. Valores mínimos negativos mostram a limitação do uso de NTP para medir latência. Desvios (skews) reportados por ferramenta cliente variam de dezenas de µs até alguns ms. Ou seja, é impossível manter um desvio controlado ou bem conhecido entre os relógios do sistema. Soluções de sincronismo de tempo de padrão industrial, como IEEE 1588 ou PTP poderiam dar uma melhor resolução de ms para ns. Contudo, dependem de hardware cliente específico no host e ainda demandariam um software cliente para Linux e TinyCore. Uma possibilidade seria medir a latência de round-trip, como realizado na primeira etapa (Capítulo 8). O problema é que sistemas PAC61850, a priori, não fariam isso, subscrever toda mensagem publicada ou aguardar por um ACK (acknowledge). Além de duplicar a troca de mensagens do sistema, essa carga desnecessária exigiria o uso de threads na aplicação e condições de espera (wait). Desnecessário dizer a complexidade e riscos envolvidos. Outra possibilidade seria encontrar uma maneira de rastrear os desvios de tempo entre hosts e VMs, e compensar ou corrigir o relógio no lado que mede a latência. Protocolos de tempo como o NTP fazem esta compensação no nível do relógio do SO. A aplicação poderia obter os desvios de tempo e aplicar a compensação, mas o desvio é relativo a mesma e única referência de tempo ou servidor de tempo. Considerando o ambiente computacional usado nos testes com VMs, não existe alternativa fácil além de usar NTP. Todas estas considerações foram feitas com o propósito de encontrar uma maneira de medir a latência mais exata e precisa possível. Entretanto, é importante destacar que sincronismo de tempo é uma solução padrão aplicada em sistemas PAC. O cenário de teste local não tem este problema, uma vez que depende somente do relógio do host. Por isso foi testado, para poder tomar as medidas de latência como uma referência de “valor verdadeiro”, ao menos sem os efeitos de desvio de tempo entre os relógios. A questão de poder conhecer o comportamento temporal de todo um sistema PAC61850 pode ser melhor evidenciada pelos gráficos de quantiles das

182

Figura 52 e Figura 54, pois o perfil do comportamento temporal de cada módulo do sistema é apresentado de forma completa e com as referências ou requisitos de tempo da norma IEC 61850. A funcionalidade do SOE também permite aferir o comportamento esperado com o registro da sequência dos eventos em ordem cronológica com estampa de tempo com resolução de µs. Dessa forma, a questão 1 do objetivo geral também foi respondida, pois o ambiente de experimentação mostrou-se capaz de permitir a avaliação da questão principal de caracterização temporal, ou seja, verificar se uma aplicação PAC funcionaria em ambiente virtualizado como funciona no convencional, ou se o comportamento temporal medido atenderia o esperado. 183

10 CONCLUSÃO

A seção 1.4 OBJETIVOS apresentou duas questões para investigação como objetivos da tese. A primeira questão, principal, diz respeito a caracterização temporal, cujo objetivo é verificar se uma aplicação PAC funcionará em ambiente distribuído e virtualizado como funciona no convencional, ou seja, se o comportamento temporal medido atende o esperado. A segunda questão, de engenharia de projeto, ou design, diz respeito a avaliação e comparação da arquitetura convencional com a distribuída e virtualizada, bem como a comunicação convencional via pilha de protocolo vs middleware de comunicação. Essas questões são discutidas separadamente em 10.1.1 Caracterização Temporal e 10.1.2 Arquitetura Proposta. Como destaque da implementação (Capítulo 9), com a aplicação definida no estudo de caso (Capítulo 7), recursos incorporados como o SOE facilitaram muito obter os dados de medição necessários para a caracterização temporal. A tese de que é possível executar aplicações PAC IEC 61850 em ambiente distribuído e virtualizado enquanto atendem-se seus requisitos temporais ou sem prejudicar seu comportamento temporal foi inicialmente analisada a partir da camada do DDS na primeira etapa dos testes. Os resultados obtidos e os argumentos apresentados a partir da implementação de um protótipo e avaliação de seu desempenho demonstram ser verdadeira a tese levantada. Na segunda etapa, que dependia dos resultados satisfatórios da primeira, os resultados obtidos demonstram claramente que para o ambiente computacional utilizado, não seria possível atender os requisitos de desempenho de tempo previstos na norma IEC 61850, considerando o tempo de transferência conforme Figura 20 – Definição de Tempo de Transferência, mesmo considerando tempo real mais leve (soft real-time) com percentil 95. Principalmente no nível dos tópicos (DO-vLN), cujos resultados superam o caso médio no nível dos módulos (vLD). Não obstante, os resultados indicam que existe o potencial de avaliar outras infraestruturas computacionais que possam melhorar o desempenho e, assim, atender os requisitos exigidos.

184

A relevância de um estudo dessa natureza, conforme já apontado em 1.2 MOTIVAÇÃO, é oferecer uma referência para que engenheiros de projeto, responsáveis pelo design de soluções de automação, possam avaliar o uso de arquiteturas e tecnologias modernas de computação, particularmente de virtualização e middlewares de comunicação, em projetos reais de engenharia, visando abstrair e simplificar de forma mais integrada e flexível o desenho e implantação da solução final. E com isso, poder elencar as soluções que tenham desempenho suficiente para atender os requisitos de desempenho exigidos. Por isso a importância de investigar a questão central de verificar o comportamento temporal no contexto aqui considerado.

10.1 CONTRIBUIÇÕES DO TRABALHO DE DOUTORADO

Conforme 1.7 CONTRIBUIÇÕES ORIGINAIS, essa tese teve como principal contribuição a caracterização temporal de uma aplicação PAC IEC 61850 (BAY61850) executando em ambiente virtualizado, descrevendo o comportamento de todo o sistema PAC a partir da medição da latência no nível de cada tópico DDS. Como contribuições adicionais, esta tese apresentou um possível benchmark para trabalhos futuros, composto pela proposta da arquitetura de referência de um ambiente distribuído e virtualizado para implantação de aplicações PAC, pela aplicação PAC em si e o conjunto de testes utilizado.

10.1.1 Caracterização Temporal

Como proposta de tese, a seção 5.1 CONSIDERAÇÕES INICIAIS estabeleceu que os resultados da pesquisa apontariam na direção da facilidade para obter os tempos requeridos, na impossibilidade de obtê-los, ou então na identificação de quais aspectos são problemáticos e quais são simples de resolver, sempre no contexto PAC, IEC 61850, DDS e virtualização, delimitando ainda que a caracterização temporal permitiria:  determinar o grau de facilidade/dificuldade em atingir os requisitos temporais das aplicações, através de um protótipo e uso de tecnologias e plataformas disponíveis, de propósito geral; e 185

 indicar os principais gargalos/dificuldades a serem vencidos para obter implementações satisfatórias. Na primeira etapa da avaliação, ou seja, excluindo a camada do framework IEC 61850 e aplicação PAC 61850, os resultados obtidos com os experimentos realizados no Capítulo 6 usando a aplicação de benchmark do OpenDDS mostram que tempos de resposta inferiores a 1 ms são possíveis em diferentes cenários de configuração, conforme Tabela 4. Ou seja, pode-se concluir que aplicações de tempo real mais leve (soft real-time) com requisitos de tempo de reposta de comunicação superiores a 1 ms tem potencial de serem executadas em ambiente distribuído e virtualizado. Para tempo real crítico a seção 8.5 ANÁLISE DOS RESULTADOS apresenta algumas sugestões. No caso da norma IEC 61850, conforme Figura 20 – Definição de Tempo de Transferência, Quadro 12 – Classes de Desempenho e Quadro 13 – Tipo de Mensagem e Classe de Desempenho, pode-se concluir que com 1 ms seria possível atender a todas as classes P1, P2, P3 e M1, M2 e M3 para os respectivos tipos de mensagens 1A, 1B, 2, 3, 5 e 6-P1, uma gama considerável de aplicações. Portanto, a caracterização temporal proposta permitiu mostrar que é possível atingir os requisitos temporais de uma gama de aplicações de tempo real mais leve (soft real-time) desde a camada do DDS, mesmo através do uso de plataformas disponíveis de propósito geral. Na segunda e principal etapa da avaliação, com um sistema ou aplicação PAC 61850 completa executando no ambiente virtualizado proposto, os resultados obtidos extrapolaram não somente o tempo de resposta de 1 ms obtido na primeira etapa, considerado como um limite mais seguro, mas também extrapolaram o tempo de transferência e limites da própria norma IEC 61850 de 3 a 4 ms. Portanto, a caracterização temporal da aplicação PAC 61850 não permitiu atender os requisitos esperados. Para tempo real crítico, em qualquer caso, como esperado, não foi possível atender os requisitos de tempo. Neste caso, o uso de plataformas convencionais é provavelmente o principal gargalo. Isto significa dizer que o uso de plataformas de tempo real ou de melhor desempenho de tempo precisaria ser avaliado para verificar as condições exigidas e identificar as dificuldades que poderiam ser vencidas para obter implementações satisfatórias.

186

10.1.2 Arquitetura Proposta

Conforme destacado na seção 6.4 CONSIDERAÇÕES FINAIS, uma arquitetura permite definir a base conceitual e modelo de referência de toda a infraestrutura, bem como expressar melhor o arranjo e interface dos principais componentes escolhidos. A arquitetura proposta nesta tese alcançou os objetivos esperados, sem a pretensão de se obter a arquitetura ótima, mas uma arquitetura apropriada para permitir construir os ambientes elencados e realizar os experimentos e, satisfatoriamente, alcançar os resultados apresentados. Na prática, a implementação dos ambientes de testes tornou-se uma tarefa bem mais demorada e trabalhosa do que se esperava, mesmo considerando as simplificações feitas. Comparando com uma implementação em host Linux, o uso de VM com Guest-OS não convencional como o TinyCore apresenta uma dificuldade a mais, pois embora baseado no kernel do Linux, o TinyCore tem seu próprio toolchain. Mas uma vez dominada e bem documentada, a personalização do TinyCore torna-se uma tarefa corriqueira. O uso do KVM ou VirtualBox como hypervisors se mostrou bem simples, contudo. A comparação com outras soluções de virtualização exigiria um trabalho ainda mais extenso de implementação, fora do escopo deste trabalho. Uma comparação com arquitetura convencional envolveria provavelmente sistemas embarcados, ou até mesmo um hardware padrão x86 / x64, mas possivelmente com SO de tempo real. A grande vantagem que se observa com a construção de um sistema de software em um iso é a padronização e flexibilidade. Considerando arquitetura x86 / x64 é possível implantar o mesmo iso em um PenDrive ou HD, inicializando o sistema como Host-OS, ou como Guest-OS para o sistema de virtualização usado. O padrão DDS, em particular, pensado e desenhado para desempenho em tempo real, tem soluções com footprint bem reduzido, ou seja, torna-se possível construir um iso ainda mais pequeno para dispositivos com recursos mais limitados. Em outras palavras, torna-se mais natural distribuir e implantar um sistema. Outro importante diferencial é a consolidação de hardware com a otimização dos 187 recursos que podem ser melhor dimensionados para atender as necessidades específicas. Em suma, as possibilidades e vantagens com o uso de virtualização e arquitetura x86 / x64, juntamente com um middleware de comunicação, tendem a sobrepujar as arquiteturas mais convencionais, desde que atendendo os requisitos de desempenho e tempo real, ainda que com garantias mais leves e não rígidas.

10.2 TRABALHOS FUTUROS

Das questões levantadas na seção 5.2 DESAFIOS – QUESTÕES EM ABERTO, a Tabela 4 – Tempo de Referência [µs] por Cenário de Teste foi o primeiro passo dado para permitir identificar quais aplicações PAC IEC 61850 teriam potencial para executar em ambiente virtualizado. O que medir e como medir, restrito à camada do OpenDDS, tanto nos testes de benchmark realizados na primeira etapa quanto nos testes finais com a aplicação PAC 61850, ainda é sem dúvida uma área aberta para aprimorar e avaliar novos pontos e formas de medição. Dimensionar a infraestrutura subjacente depende das escolhas feitas dos componentes principais da arquitetura, mas é possível perceber claramente a vantagem que a construção de um sistema de software traz com o uso de um SO enxuto como o TinyCore. Combinando exclusivamente os pacotes de software necessários com um SO pequeno, consegue-se produzir um iso enxuto que facilita a definição dos requisitos de recursos computacionais exigidos, basicamente memória, CPU, armazenamento e rede, em linha com o objetivo de construção de um sistema de software com TCB menor possível. Resumidamente, como trabalhos futuros pode-se sugerir:  avaliar e comparar desempenho para diferentes ambientes computacionais e redes de comunicação, por exemplo, diferentes implementações do DDS como Connext DDS da RTI (Real-Time Innovations) e Vortex OpenSlice da PrismTech; diferentes Guest-OS; diferentes Hypervisors como XtratuM; novas tecnologias de redes como SDN (Software Defined Network);

188

 avaliar condições adversas de carregamento da nuvem, tráfego de rede, e suporte para controle de QoS desde o DDS;  avaliar a capacidade de tolerância a falhas oferecida por soluções de virtualização e Nuvem;  avaliar diferentes arranjos de arquitetura da infraestrutura para considerar melhor aproveitamento e dimensionamento com esquemas de redundância ativo-ativo e tempo real firme no lugar de tempo real crítico; e  avaliar outras funcionalidades da norma IEC 61850 como Functional Constraints (FC).

10.3 PUBLICAÇÕES

Os seguintes artigos foram publicados, baseados na pesquisa realizada cujos resultados são apresentados nesta tese: 1. R. D. F. Ferreira and R. S. de Oliveira, "Cloud IEC 61850 A Case Study of a Software Defined Protection, Automation & Control System". IEEE 23rd International Conference on Emerging Technologies and Factory Automation (ETFA), Turin, 2018, pp. 75-82. doi: 10.1109/ETFA.2018.8502512 2. R. D. F. Ferreira and R. S. d. Oliveira, "Cloud IEC 61850: DDS Performance in Virtualized Environment with OpenDDS". IEEE International Conference on Computer and Information Technology (CIT), Helsinki, 2017, pp. 231-236. DOI: 10.1109/CIT.2017.17 3. R. D. F. Ferreira, M. F. Mendes, H. A. L. Samaniego and R. S. d. Oliveira, "Cloud IEC 61850: Architecture and Integration of Electrical Automation Systems". Brazilian Symposium on Computing Systems Engineering (SBESC’14), Manaus, 2014, pp. 13-18.

10.4 PATROCÍNIO

Este trabalho de doutorado foi patrocinado pela ITAIPU Binacional e apoiado pelo LASSE.

189

REFERÊNCIAS

61850, IEC. 2002. IEC Communication Networks and Systems for Power Utility Automation. IEC Standard 61850. 2002. Edition 1.0. ABB. 2009. IEC 61850 UML model. The Net is the Automation. [Online] 2009. http://www.nettedautomation.com/download/std/61850/uml/. Altus e Endesa. 2012. IEC 61850 X IEC 61131 – Dois Mundos Distintos Que Podem Ser Integrados – Sonho do Usuário de Ter Tudo Padronizado. XI STPC. 2012. Ardagna, D. et al. 2014. Quality-of-service in cloud computing: modeling techniques and their applications. Journal of Internet Services and Applications 2014, 5:11. 2014. Batista, B. et al e Reiff-Marganiec, S. 2014. Performance Evaluation in a Cloud with the Provisioning of Different Resources Configurations. IEEE 10th World Congrees on Services. 2014. Becker, D. 2010. Harmonizing the International Electrotechnical Commission Common Information Model (CIM) and 61850. s.l. : EPRI, 2010. Berndt, P. e Watzl, J. 2013. Unitizing Performance of IaaS Cloud Deployments. IEEE Ninth World Congress on Services. 2013. Bi, Y. B., et al. 2013. Mapping of IEC 61850 to Data Distribution Service for digital substation communication. IEEE - Power and Energy Society General Meeting (PES). 2013. Blackham, B. 2013. Towards Verified Microkernels for Real-Time Mixed-Criticality Systems. Tese Doutorado Universidade New South Wales. 2013. Bradley, J., Barbier, J. e Handler, D. 2013. Embracing the Internet of Everything. Cisco White Paper. [Online] 2013. https://www.cisco.com/c/dam/en_us/about/ac79/docs/innov/IoE_Economy.pdf. Calvo, I., Albéniz, O. G. e Pérez, F. 2012. A communication backbone for Substation Automation Systems based on the OMG DDS standard. PRZEGLĄD ELEKTROTECHNICZNY (Electrical Review). 2012. Chelluri, S., et al. 2015. Entendendo e Validando Redes Ethernet para Aplicações de Proteção, Automação e Controle de Missões Críticas. 2015.

190

Cisco. 2019. Substation Automation Local Area Network and Security Cisco Validated Design. Cisco. [Online] Cisco, 05 de Fevereiro de 2019. https://www.cisco.com/c/en/us/td/docs/solutions/Verticals/Utilities/SA/2-3-2/CU-2-3-2- DIG/CU-2-3-2-DIG.html. —. 2019. Substation Automation Local Area Network and Security: Design and Implementation Guide. Cisco. [Online] Fevereiro de 2019. https://www.cisco.com/c/en/us/td/docs/solutions/Verticals/Utilities/SA/2-3-2/CU-2-3-2- DIG.pdf. Version 2.3.2. Cucinotta, T., Anastasi, G. e Abeni, L. 2008. Real-Time Virtual Machines. RTSS. 2008. Delange, J. e Feiler, P. 2014. Incremental Latency Analysis of Heterogeneous Cyber-Physical Systems. Real-Time and Distributed Computing in Emerging Applications (REACTION). 2014. Fang Liu, et al. 2011. NIST Cloud Computing Reference Architecture. 2011. NIST SP 500-292. Ferreira, R. D. F. e al., et. 2013. Cloud IEC 61850. PAC World Conference. Junho de 2013. —. 2012. Cloud IEC 61850. PAC World Conference Latin America. Novembro de 2012. —. 2014. Cloud IEC 61850: Architecture and Integration of Electrical Automation Systems. Symposium on Computing Systems Engineering (SBESC). 2014. Feske, N. 2010. Genode 15.05 Foundations. Genode. [Online] Genode Labs, 2010. http://genode.org/documentation/genode-foundations-15-05.pdf. Foster, A. 2015. Messaging Technologies for the Industrial Internet and the Internet of Things Whitepaper: A Comparison Between DDS, AMQP, MQTT, JMS, REST and CoAP. Version 1.9. Prismtech. [Online] 2015. http://www.prismtech.com/sites/default/files/documents/Messaging-Whitepaper- 040615_1.pdf. Garcia, D. A.A. e Duzzi, F. E. 2012. Capítulo I - Aspectos de sistemas de geração, transmissão e distribuição de energia. Portal O Setor Elétrico. [Online] 2012. http://www.osetoreletrico.com.br/web/component/content/article/80-distribuicao-de- energia/796-capitulo-i-aspectos-de-sistemas-de-geracao-transmissao-e-distribuicao- de-energia.html. 191

—. 2012. Capítulo II - Tópicos de sistemas de transmissão e distribuição de energia elétrica. Portal O Setor Elétrico. [Online] 2012. http://www.osetoreletrico.com.br/web/component/content/article/80-distribuicao-de- energia/831-capitulo-ii-topicos-de-sistemas-de-transmissao-e-de-distribuicao-de- energia-eletrica.html. García-Valls, M., Basanta-Val, P. e Serrano-Torres, R. 2013. Benchmarking communication middleware for cloud computing virtualizer. Real-Time and Distributed Computing in Emerging Applications (REACTION). 2013. García-Valls, M., Cucinotta, T. e Lu, C. 2014. Challenges in real-time virtualization and predictable cloud computing. Journal of Systems Architecture 60 (2014) 726– 740. 2014. Gers, J. 2012. A PRIMER on IEC 61850 grid data communications. DNV GL - Energy in Transition. [Online] 2012. http://blogs.dnvgl.com/energy/a-primer-on-iec- 61850-grid-data-communications. Groesbrink, S. 2014. Virtual Machine Migration as a Fault Tolerant Technique for Embedded Real-Time Systems. Eighth International Conference on Software Security and Reliability. 2014. Gu, Z. e Zhao, Q. 2012. A State-of-the-Art Survey on Real-Time Issues in Embedded Systems Virtualization. Journal of Software Engineering and Applications, 2012, 5, 277-290. 2012. Hoffmann, G.A, Trivedi, K.S e Malek, M. 2007. A Best Practice Guide to Resource Forecasting for Computing Systems. IEEE Transactions on Reliability. 2007. Hoz León, H.E. 2015. Modelagem de Dispositivos Eletrônicos Inteligentes para Barramento de Processos Baseado na Norma IEC 61850. Florianópolis : Dissertação de Mestrado UFSC, 2015. IEB Media. 2013. IEC 61850 critical to smart grid designs. IEB Media. [Online] 2013. ISSN 1470-5745. http://www.iebmedia.com/IEBDigital/0213IEB74/pubData/source/IEB74_digital.pdf. K. P. Silva, L. F. Arcaro and R. S. d. Oliveira. 2017. On Using GEV or Gumbel Models When Applying EVT for Probabilistic WCET Estimation. 2017 IEEE Real- Time Systems Symposium (RTSS). Paris, 2017, Vols. pp. 220-230. Kasanen, L. et al. 2013. Into the Core: A look at Tiny Core Linux. 2013.

192

Khethavath, P., et al. 2013. Introducing a Distributed Cloud Architecture with Efficient Resource Discovery and Optimal Resource Allocation. IEEE Ninth World Congress on Services. 2013. Kostic, T. e Frei, C. 2007. Modelling and Using IEC 61850-7-2 (ACSI) as an API. IEEE PowerTech. 2007. —. 2003. Towards the Formal Integration of Two Upcoming Standards: IEC 61970 and IEC 61850. IEEE. 2003. Kostic, T., Preiss, O. e Frei, C. 2004. Understanding and using the IEC 61850: a case for meta-modelling. Elsevier - Computer Standards & Interfaces. 2004. Legout, V. e Lemerre, M. 2012. Paravirtualizing Linux in a real-time hypervisor. EWiLi - Embedded With Linux. 2012. Li, X., et al. 2013. Impacts of Scheduling Algorithms in Services on Collective End- to-End Execution Time Characteristics of Web Service Workflows. IEEE Ninth World Congress on Services. 9th, 2013. Liang, Y. e Campbell, R. H. 2008. Understanding and Simulating the IEC 61850 Standard. Department of Computer Science, University of Illinois at Urbana- Champaign. 2008. Lima, G., Dias, D. e Barros, E. 2016. Extreme Value Theory for Estimating Task Execution Time Bounds: A Careful Look. 28th Euromicro Conference on Real-Time Systems (ECRTS). 2016. Martinez, M. 2010. Interpreting OpenDDS Performance Testing Results. OCI. [Online] ociweb, 2010. [Citado em: 22 de 06 de 2015.] http://mnb.ociweb.com/mnb/MiddlewareNewsBrief-201003.html. Mendes, M. F. 2014. Modernizations of Automation Systems of Hydraulic Generating Units in Brazil. CIGRE. Session 45, 2014. —. 2011. Proposta de Metodologia e de Modelo para Modernizações de Sistemas de Automação de Unidades Geradoras Hidráulicas de Grande Porte. São Paulo : Tese de Doutorado USP, 2011. Mohagheghi, P. e Sæther, T. 2011. Software Engineering Challenges for Migration to the Service Cloud Paradigm : Ongoing Work in the REMICS Project . IEEE World Congress on Services. 2011. 193

Ozansoy, C.R. Zayegh, A. e Kalam, A. 2004. Interoperable CORBA middleware design for substation communication systems. . Eighth IEEE International Conference on Developments in Power System Protection. 2004. Ozansoy, C.R., Zayegh, A. e Kalam, A. 2004. Standard Interoperable Middleware Design for Substation Communication Systems. Australasian Universities Power Engineering Conference (AUPEC 2004). 2004. Pedersen, A. B. et al. 2010. Facilitating a generic communication interface to distributed energy resources: Mapping IEC 61850 to RESTful services. First IEEE International Conference on Smart Grid Communications (SmartGridComm). 2010. Pérez, H. e Gitiérrez, J. 2014. Data-centric distribution technology in ARINC-653 systems. Real-Time and Distributed Computing in Emerging Applications (REACTION). 2014. Pérez, H. e Gutiérrez, J. J. 2013. Towards the integration of data-centric distribution technology into partitioned embedded systems. Real-Time and Distributed Computing in Emerging Applications (REACTION). 2013. Pérez, H. e Gutiérrez, J. 2012. Real-time modelling of DDS for event-driven applications. Real-Time and Distributed Computing in Emerging Applications (REACTION). 2012. Prasad, G. 2013. Dependency-Oriented Thinking. Volume 1: Analysis and Design. s.l. : InfoQ, 2013. Rizano, T., Abeni, L. e Palopoli, L. 2013. Experimental Evaluation of the Real-Time Performance of Publish-Subscribe Middlewares. Real-Time and Distributed Computing in Emerging Applications (REACTION). 2013. Rutkowska, J. 2014. Software compartmentalization vs. physical separation. Invisible Things Lab. 2014. Samaniego, H. L. 2010. Análise de Interoperabilidade IEC 61850 entre Simulador em Tempo Real e IED’s de Proteção. Foz do Iguaçu : ITAIPU, 2010. Trabalho de conclusão do curso interno de pós em IEC 61850 oferecido pela ITAIPU.. Sanz, R. 2002. Specific Communication Service Mapping to CORBA. Version 2. Universidad Politécnica de Madrid - Autonomous Systems Laboratory. [Online] 2002. http://tierra.aslab.upm.es/~sanz/documents/IEC_61850_CORBA_SCSM.pdf.

194

Schwarz, K. 2005. IEC 61850 also Outside the Substation for the Whole Electrical Power System. 15th Power Systems Computation Conference PSCC. Agosto de 2005. Schwarz Consulting Company (SCC). Serrano-Torres, R., García-Valls, M. e Basanta-Val, P. 2014. Performance Evaluation of Virtualized DDS Middleware. IV Simposio de Sistemas de Tiempo Real. 2014. Souto, A. O. et al. 2009. Testes de Desempenho e Interoperabilidade Utilizando a Norma IEC 61850. 13° Seminário de Automação de Processos. 2009. Steinberg, U. e Kauer, B. 2010. NOVA: A Microhypervisor-Based Secure Virtualization Architecture. 5th European Conference on Computer Systems. 2010. TC57, IEC. Current IEC TC57 Reference Architecture – Scope and Layers. Xanthus Consulting International. [Online] http://xanthus- consulting.com/Publications/documents/TC57_reference_architecture.pdf. Twin Oaks Computing. 2011. What can DDS do for You? Learn how dynamic publish-subscribe messaging can improve the flexibility and scalability of your applications. Twin Oaks Computing Inc. . [Online] 2011. http://www.omg.org/hot- topics/documents/dds/CoreDX_DDS_Why_Use_DDS.pdf. TwinOaks Computing. 2011. Communications Middleware and DDS. Twin Oaks Computing, Inc. [Online] Dezembro de 2011. http://www.twinoakscomputing.com/wp/CoreDX_DDS_What_is_Middleware.pdf. Xi, S. 2014. Real-Tme Virtualization and Cloud Computing. Dissertação Washington University. St. Louis : s.n., 2014.

195

APÊNDICE A – Ambiente de Software Host

Preparação Host Linux As máquinas host foram configuradas com:  SO Linux Ubuntu 14.04 LTS;  Bridge como interface de rede das VMs;  KVM como hypervisor / VMM; e  OpenDDS 3.628 como middleware de comunicação DDS. Configurações de Rede Para que a VM do KVM seja integrada na rede Linux, é preciso criar uma bridge no host Linux: > sudo vi /etc/network/interfaces ## Bridge Name ## auto br1 ## Bridge Information ## iface br1 inet static bridge_ports eth0 bridge_stp on bridge_fd 0.0 ## Bridge IP ## address 179.106.230.91 netmask 255.255.255.192 gateway 179.106.230.65 dns-nameserver 8.8.8.8 Dessa forma, a VM pode ter uma única configuração de rede com IP da rede Linux que funciona tanto para o modo host quanto Guest-OS. O esquema pode ser resumido como: /------\ /----\ /----\ /----\ /------\ |Network|---|eth0|---|br0 |---|tap0|---|Guest NIC \------/ \----/ \----/ \----/ \------/ Para aplicar a configuração basta levantar a bridge29: > sudo ifup br1 e conferir: > ifconfig br1 Link encap:Ethernet HWaddr 16:c6:89:01:58:35 inet addr:179.106.230.91 Bcast:179.106.230.127 Mask:255.255.255.192 UP BROADCAST MULTICAST MTU:1500 Metric:1 eth0 Link encap:Ethernet HWaddr 3c:77:e6:d3:65:91 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1

28 Versão 3.7 testada apresentou problemas. 29 www.itzgeek.com/how-tos/linux/ubuntu-how-tos/configure-bridged-networking-for-kvm-on-ubuntu-14-10.html

196

Como são usados IPs fixos, é preciso configurar estaticamente em cada host piu.sinuv e app.sinuv: > sudo vi /etc/hosts 127.0.0.1 localhost

179.106.230.90 piu.sinuv 179.106.230.91 app.sinuv 179.106.230.93 vApp1.sinuv 179.106.230.94 vApp2.sinuv 179.106.230.95 vApp3.sinuv 179.106.230.96 vApp4.sinuv

KVM A instalação e configuração do KVM30 foram feitas da seguinte forma. HW precisa suportar virtualização: > egrep -c '(svm|vmx)' /proc/cpuinfo Pacotes: > sudo apt-get install qemu-kvm qemu-system libvirt-bin bridge-utils virt-manager Incluir usuário para acesso VM: > sudo adduser user_name libvirtd Teste: > sudo virsh -c qemu:///system list Para criar e configurar a VM, basta usar a aplicação Virtual Machine Manager: > sudo virt-manager As seguintes configurações foram usadas ao criar uma VM a partir da iso no host app.sinuv: Overview Hypervisor Details Hypervisor: kvm Architecture: x86_64 Operation System Hostname: unknown Product name: unknown Machine Settings Enable ACPI: √ Enable APIC: √ Clock Offset: localtime Processor CPUs Logical host CPUs: 4 Current allocation: 1 Maximum allocation: 2 Memory Total host memory: 1837 MB Current allocation: 800 MB Maximum allocation: 800 MB Boot Options Boot Device Order: CDROM IDE CDROM Virtual Disk Source path: /home/sinuv/tiny-core/tiny-bench/tc-bench.iso NIC Virtual Network Interface Source device: Host device eth0 (Bridge ‘br’)

30 http://www.howtogeek.com/117635/how-to-install-kvm-and-create-virtual-machines-on-ubuntu/ 197

Device model: rtl8139

OpenDDS A instalação e configuração do OpenDDS foram feitas seguindo os passos a seguir. Diretório base: > wget http://download.ociweb.com/OpenDDS/previous-releases/OpenDDS-3.6.tar.gz Se for necessário, instalar g++: > sudo apt-get update > sudo apt-get install g++ Descompacta na pasta DDS e compila: > tar xvf OpenDDS-3.6.tar.gz > cd DDS > ./configure --prefix=/usr/local/opendds31 > make O código do ACE+TAO é baixado como parte do processo de instalação: http://download.ociweb.com/TAO-2.2a/ACE+TAO-2.2a_with_latest_patches_NO_makefiles.tar.gz As aplicações de teste de Benchmark do OpenDDS que serão usadas estão localizadas em: ~/DDS> cd performance-tests/Bench Para a correta execução dos testes, foi necessário corrigir alguns arquivos de script. Um problema ocorre quando o serviço DCPSInfoRepo é executado com host completo (host e porta). Deve-se deixar sem host (*) para aceitar de qualquer. Para corrigir, é preciso editar o seguinte arquivo: > cd DDS > vi performance-tests/Bench/bin/run_test :set number 178 my $repoOpts = "$common_opts "; 179 my @repoPort = split( ':', $repoHost); 180 #$repoOpts .= "-ORBListenEndpoints iiop://$repoHost " if $repoHost; 181 $repoOpts .= "-ORBListenEndpoints iiop://:$repoPort[1] " if $repoHost; Outro problema é o teste do protocolo RTPS. É preciso incluir ! na opção RTPS: > cd DDS/bin > vi performance_tests.lst performance-tests/Bench/tests/latency/run_test.pl rtps 50: !DCPS_MIN !RTPS performance-tests/Bench/tests/thru/run_test.pl rtps : !RTPS Para executar os testes basta seguir a sequência descrita a seguir. A lista de testes padrão contém inúmeros testes para diferentes tamanhos de mensagem por tipo de protocolo de transporte, o que exige muito tempo para cada cenário de teste.

31 ACE_wrappers/include/makeinclude/platform_macros.GNU

198

Neste caso será dado foco para o tipo latência e mensagem de tamanho 250: > vi myimg/home/tc/performance_tests-250.lst ## Run inter-host tests first performance-tests/Bench/tests/latency/run_test.pl tcp 250: !DCPS_MIN performance-tests/Bench/tests/latency/run_test.pl udp 250: !DCPS_MIN performance-tests/Bench/tests/latency/run_test.pl multi-be 250: !DCPS_MIN performance-tests/Bench/tests/latency/run_test.pl multi-rel 250: !DCPS_MIN performance-tests/Bench/tests/latency/run_test.pl rtps 250: !DCPS_MIN Para configurar a variável de ambiente CROSS_GRP que define o papel da aplicação (servidor ou cliente) e hostnames, é preciso criar arquivo test_list.txt único: > cd DDS > vi performance-tests/Bench/tests/test_list.txt # group client server

# Testes entre hosts 1 app.sinuv piu.sinuv 2 piu.sinuv app.sinuv # Testes host-local 3 app.sinuv localhost 4 localhost app.sinuv # Testes host-vm 5 vApp1.sinuv app.sinuv# Host-VM_L 6 vApp1.sinuv app.sinuv# Host-VM_R # Testes vm-vm 7 vApp1.sinuv vApp2.sinuv# VM-VM_L 8 vApp1.sinuv vApp3.sinuv# VM-VM_R # Testes vm-local 9 vApp1.sinuv localhost# VM_Local 10 localhost vApp1.sinuv# VM_Local e substituir testes específicos por links simbólicos: > cd performance-tests/Bench/tests/latency > ln –sf ../test_list.txt . > cd performance-tests/Bench/tests/thru > ln –sf ../test_list.txt . Para executar esses testes localmente (Host_Local e VM_Local), usando a interface localhost, é preciso alterar o seguinte arquivo de configuração: >vi bin/PerlDDS/Cross_Sync_Common.pm :set number 348 if ($argv[1] =~ /$my_name/) { 349 $self->{ROLE} = CLIENT; 350 $self->{PEER} = $argv[1]; # Apontar mesma local 351 $self->{SELF} = $argv[1]; 352 } elsif ($argv[2] =~ /$my_name/) { 353 $self->{ROLE} = SERVER; 354 $self->{PEER} = $argv[2]; # Apontar mesma local 355 $self->{SELF} = $argv[2]; 356 } else { Para demais testes remotos deve-se manter a configuração original. A execução propriamente dita é feita em três passos. Primeiro deve-se configurar variáveis de ambiente: > cd DDS > source ./setenv.sh e escolher grupos (3 e 4 para local) em dois terminais distintos (mesma máquina para teste local): > export CROSS_GRP=x 199

Executar primeiro servidor: > cd DDS/bin > export CROSS_GRP=4 > ./auto_run_tests.pl –l performance_tests-250.lst Hostname: piu.sinuv Taking server role (piu.sinuv) e em seguida cliente: > cd DDS/bin > export CROSS_GRP=3 > ./auto_run_tests.pl –l performance_tests-250.lst Hostname: piu.sinuv Taking client role. client> connecting to piu.sinuv:55555 … Os resultados dos testes são salvos em: > cd DDS/performance-tests/Bench/tests > tree –d ├── latency │ ├── multi-be │ ├── multi-rel │ ├── rtps │ ├── tcp │ └── udp └── thru ├── multi-be ├── multi-rel ├── rtps ├── tcp └── udp Para guardar os resultados de cada teste executado, recomenda-se copiá- los em diretório separado. Para cópia remota de arquivos no Linux: > scp -r -r tcp/ udp/ rtps/ multi-be/ multi-rel/ [email protected]:"/home/sinuv/DDS/performance- tests/Bench/tests/latency|thru" Para obter as estatísticas a partir dos dados brutos, o OpenDDS disponibiliza scripts para geração automática de dados e gráficos estatísticos: > cd DDS > source setenv.sh

> cd performance-tests/Bench/bin > ./generate-test-results.sh /home/sinuv/DDS/performance-tests/Bench Os dados estatísticos gerados são salvos em: > cd DDS/performance-tests/Bench/tests > tree –d ├── latency │ └── data └── thru └── data Para gerar os gráficos e salvar na pasta results: > sudo apt-get install gnuplot > mkdir ../results > ./plot-test-results.sh /home/sinuv/DDS/performance-tests/Bench ../results

Montagem Disco de Imagem Para poder acessar e alterar o conteúdo de arquivos de imagens criadas é possível montar um arquivo de imagem como qualquer outra media.

200

Para recuperar esses arquivos do disco de imagem basta usar os comandos a seguir. Escolher um dispositivo de loop na imagem de disco cuja partição deseja-se montar: > losetup -f > losetup /dev/loop0 image.img Criar um mapa de dispositivo a partir das partições da imagem de disco: > kpartx -a /dev/loop0 Montar: > mount /dev/mapper/loop0p1 /mnt/image loop0p1 pode ser substituído com o número da partição que deseja-se montar, por exemplo, loop0p3 para montar a terceira partição na imagem de disco. Para desfazer: > umount /mnt/image > kpartx -d /dev/loop0 > losetup -d /dev/loop0 Outra forma mais simples e direta: > sudo kpartx -a image.img > sudo mount /dev/mapper/loop0p1 /mnt/image > sudo umount /mnt/image > sudo kpartx -d image.img 201

APÊNDICE B – TinyCore

Tinycore é uma distribuição extremamente reduzida (Tiny – minúsculo) do Linux de apenas 16 MB (versão gráfica TinyCore ISO), tornando-se, portanto, uma boa opção para criação de appliances de tamanho reduzido para aplicações PAC, ou seja, implantação dos IEDs em VMs com Guest-OS Tinycore, ou virtual appliances vIEDs. Os principais objetivos32 (Kasanen, 2013) do TinyCore é ser estável e ter a habilidade de ser fácil, rápido e simples de se renovar. O desenho concebido do SO para executar a partir da RAM protege os arquivos do sistema e garante um sistema incólume a cada reinicialização. No lugar de simplesmente inicializar sempre o TinyCore do zero (modo padrão cloud/internet), e ter de baixar todos pacotes necessários, para usar bibliotecas e aplicações armazenadas localmente e configurar a cada inicialização, existem os modos montar (mount) e copiar (copy). No modo montar, os pacotes ou extensões são armazenados em um diretório nomeado tce (TinyCore Extensions) em uma media persistente, podendo ser montados durante o boot (OnBoot) quando adicionados na lista onboot.lst, ou sob demanda (OnDemand) a partir de um menu especial. No modo copiar, as extensões são copiadas na RAM, em massa (copy2fs.flg), seletivamente (copy2fs.lst), ou ainda montadas como no modo montar. O tempo de inicialização é maior, pois copiar em memória demora mais que montar, mas velocidade de tempo de execução, especialmente na primeira inicialização, é muito maior. Como opções de backup/restore, o arquivo /opt/.filetool.lst permite listar os arquivos e diretórios a serem salvos durante desligamento (shutdown) e recuperados durante a inicialização. /opt/.xfiletool.lst permite listar o que deve ser excluído. Os dados são salvos no arquivo de backup mydata.tgz. A opção de backup torna-se padrão sempre que houver um diretório tce configurado (e.g. /mnt/sda1/tce), salvando arquivos pessoais no diretório home e arquivos de configuração do sistema localizados em /opt.

32 http://www.tinycorelinux.net/book.html

202

Atualizações do SO podem ser feitas facilmente baixando as últimas versões do vmlinuz e core.gz que serão aplicadas após uma reinicialização do sistema. Atualizações de extensões podem ser aplicadas pela ferramenta gráfica Apps (Maintenance -> Check for Updates) ou comando sudo tce-update. O desafio é preparar o Guest-OS desse appliance com os componentes exigidos pela arquitetura proposta, ou seja, DDS e framework IEC 61850, além de toda a infraestrutura de software necessária, como biblioteca Qt, e obviamente, a aplicação PAC. Uma forma é usar QEMU com um disco de imagem e um pendrive33 para inicializar o TC (TinyCore) e criar as extensões necessárias no diretório /tce do disco de imagem. Outra opção é fazer a instalação em um dispositivo USB, que permite construir as bibliotecas muito mais rapidamente, pois o sistema executa diretamente como host. Nesta opção, a vantagem é que toda parte customizada (extensões padrão e componentes específicos) fica separada do iso da distribuição padrão do TC no disco de imagem. Outra opção seria gerar um novo iso contendo os componentes desejados, o chamado Remaster34 da imagem do TinyCore (tinycore.gz - initrd) para criar uma nova imagem personalizada. Essa opção tem como vantagem permitir modificar arquivos de todo sistema. A extensão ezremaster, que pode ser descarregada e instalada e já vem incluída no iso da versão CorePlus do TinyCore, permite realizar essa tarefa. O método “Extract TCZ to in to initrd”, em particular, possui o melhor desempenho ao custo de consumir mais memória que as opções “Inside initrd apps” e “Outside initrd apps”. Diversos códigos de boot35 estão disponíveis. Estes códigos são uma forma de configurar o sistema, passando as informações que precisam estar disponíveis durante a inicialização. Com boot por CD, estas informações podem ser passadas em linha de comando (Core ISO) ou pressionando tab (TinyCore ou CorePlus ISOs).

33 USB só funciona em host Linux lançando qemu como root ou com sudo. O dispositivo USB tem de estar conectado no host Linux e montado para poder ser detectado pelo QEMU e montado no TC. 34 http://wiki.tinycorelinux.net/wiki:remastering_with_ezremaster 35 http://wiki.tinycorelinux.net/wiki:boot_codes_explained e http://wiki.tinycorelinux.net/wiki:boot_options 203

Para um sistema instalado, elas são armazenadas no arquivo de configuração do booloader (menu.lst ou extlinux.cfg). A media pode ser um CD, HD ou pendrive, ou em especial, como Guest-OS de uma VM. Outra opção interessante é o boot a partir de um servidor PXE (Preboot eXecution Environment), ou seja, boot a partir da rede, prática muito utilizada em ambientes virtualizados e Nuvem, dispensando a necessidade de dispositivos de armazenamento na máquina, pelo menos para o boot do sistema. A Figura 55 ilustra a arquitetura de arquivos do TinyCore36 que ajuda a entender melhor como o sistema é organizado e construído a partir do kernel do Linux. Figura 55 – Arquitetura de Arquivos do TinyCore

Com essa visão da arquitetura de arquivos, fica mais fácil entender como personalizar o TinyCore. Primeiro passo para criar um sistema de software personalizado com o TinyCore, é escolher uma das três formas apresentadas anteriormente, conforme descrito a seguir usando um host Linux com Ubuntu 14.04. Personalizando em Disco de Imagem Criando disco de imagem:

36 http://tinycorelinux.net/arch_core.html

204

> qemu-img create –f raw tc-disk.raw 6G Formatando disco de imagem: > kpartx –a tc-disk.raw > ln –s /dev/mappaer/loop0p1 /dev/loop0p1 > gparted /dev/loop0 Criar tabela partição Criar partição primária ext4 Formatar sistema de arquivos ext4 Para montar e desmontar o disco de imagem basta usar: > sudo kpartx –a tc-disk.raw > sudo mount /dev/mapper/loop0p1 /mnt/tc-img > sudo umount /mnt/tc-img > sudo kpartx –d tc-disk.raw Com o disco de imagem pronto e um pendrive conectado no host, pode-se então usar o QEMU para lançar o TinyCore e personalizar a instalação com a criação de extensões dos pacotes de software necessários: > lsusb ID 090c:1000 > sudo qemu-system-i386 –m 1024 –cdrom TinyCore-6.3.iso –boot d -hda tc-disk.raw -usb –usbdevice host:0x090c:0x1000 O pendrive é usado para conter os pacotes de software fonte que precisam ser construídos com o GNU ToolChain do TinyCore. Os binários resultantes podem ser salvos no disco de imagem ou mesmo no pendrive. Personalizando em Pendrive É preciso primeiro formatar o pendrive, podendo-se usar ferramenta Disks do Ubuntu ou gparted: > sudo apt-get install gparted Primeiro, deve-se conectar o dispositivo USB para que o Linux reconheça e seja possível obter sua referência: > lsusb ID 0781:5567 SanDisk Corp. Cruzer Blade Usando o QEMU: > sudo qemu-system-i386 –m 1024 –cdrom TinyCore-current.iso –boot d -usb –usbdevice host:0x0781:0x5567 Após o boot normal, para formatar e instalar o SO TinyCore no pendrive, é preciso baixar a extensão tc-install.tcz: > tce-load –wi tc-install.tcz Outra opção é usar diretamente o iso da versão CorePlus que já vem com o TC Install integrado e dispensa acesso a Internet. Executando-se a aplicação TC Install, basta selecionar: Path to core.gz: /mnt/das/boot/core.gz USB-HDD Select disk for core: sdb On a removable device. Formatting Options: ext4 Boot Options: default Install Type: Core and X/GUI Desktop 205

No final, o pendrive estará pronto para poder inicializar diretamente a máquina com o SO TinyCore a partir da porta USB. Outra forma útil, a partir de um iso, é formatar o pendrive e copiar a imagem através do comando dd. Com a unidade do pendrive conectada, mas sem estar montada no Linux, é preciso identificar o dispositivo com: > lsblk Para gravar a imagem: > sudo dd if=image.iso of=/dev/sdb bs=4M && sync

Personalizando em ISO No host Linux, a partir da distribuição corrente do TinyCore, copiar arquivos de boot: > sudo mount TinyCore-6.3.iso /mnt/tciso –o loop,ro > mkdir tiny-custom > cd tiny-custom > sudo cp –pR /mnt/tc-iso/boot ./boot Se houver pacotes adicionais criados anteriormente a partir da USB, por exemplo, pode-se copiar pacotes e aplicações específicas: > cp -p /usb/tce/optional ./cde > cp -p onboot.lst copy2fs.lst Para criar a ISO personalizada tc-core63-dds.iso propriamente dita a partir da cópia local tiny-custom: > cd .. > sudo mkisofs -l -J -R -r -V TC-CoreDDS \ -no-emul-boot -boot-load-size 4 \ -boot-info-table -b boot/isolinux/isolinux.bin \ -c boot/isolinux/boot.cat -o tc-core63-dds.iso \ tiny-custom Para testar basta usar o QEMU: > sudo qemu-system-i386 -m 768 -cdrom ./tc-core63-dds.iso -boot d

TinyCore como Guest-OS para VMM QEMU QEMU pode ser usado de diferentes maneiras para executar TinyCore como Guest-OS de forma simples e direta. A mais básica e direta é a opção cdrom com boot d a partir de uma iso: > sudo qemu-system-i386 -m 768 -cdrom ./tinycore.iso -boot d A opção hda permite boot a partir de um disco de imagem como se fosse um HD: > sudo qemu-system-i386 -m 768 -hda image-disk.img

TinyCore como Guest-OS para VMM Seoul

206

Para preparar uma VM com TinyCore Guest-OS e VMM Seoul é preciso seguir os passos a seguir obtidos por e-mail com equipe de desenvolvedores do Genode. A distribuição padrão CorePlus.iso do Tinycore para x86-32 bits é utilizada: > wget http://tinycorelinux.net/7.x/x86/release/CorePlus-current.iso Primeiro passo é preparar um disco virtual para o QEMU com tamanho suficiente e ajustado para as necessidades desejadas, e.g. 64M disk: > dd if=/dev/zero of=image.raw bs=1M count=64 > file image.raw image.raw: data Agora é possível iniciar o QEMU com a imagem da iso do TC CorePlus e o disco virtual vazio, e.g: > qemu -m 512 -cdrom CorePlus.iso -drive id=disk,file=image.raw,if=none,format=raw -device ahci,id=ahci -device ide-drive,drive=disk,bus=ahci.0 -boot d No menu bootloader selecione "Boot Core with X/GUI (TinyCore) + Installation Extension". Após a inicialização selecione na X/GUI o ícone Tc_install para iniciar a instalação do TinyCore no disco virtual. Deste ponto em diante pode-se seguir as instruções de instalação do TinyCore37. Deixar todas as opções como definidas por padrão, exceto:

 Escolha "Whole Disk" e use "sda" no Disk Menu View  Durante o Menu View "Boot Options Reference List" adicione "vga=0x314" a linha comando do kernel. Este parâmetro da linha de comando é primordial mais tarde para permitir inicializar configurações gráficas no Seoul – então, adicione-o! Após finalizar a instalação, desligue a VM no QEMU. Inicie novamente o QEMU, mas dessa vez sem a imagem do iso do TinyCore: > qemu -m 512 -drive id=disk,file=image.raw,if=none,format=raw -device ahci,id=ahci -device ide-drive,drive=disk,bus=ahci.0 Agora deve-se seguir as instruções para configuração da parte gráfica38: > tce-load -w -i Xfbdev.tcz > xsetup Execute: > cat .xsession e verifique se Xfbdev faz parte da saída – será usado no próximo boot. > sudo reboot Se a instalação aparecer agora no QEMU com o X/GUI, então o disco virtual image.raw está pronto para o VMM Seoul.

37 http://distro.ibiblio.org/tinycorelinux/install.html 38 http://tinycorelinux.net/faq.html - "How to use framebuffer X server? 207

Desligue a VM no QEMU e copie image.raw no diretório build do Genode: genode/build/nova_x86_32/bin No cenário seoul-wm-cli.run do Genode entre com o seguinte comando no terminal cli: > start seoul-img O Guest-OS TinyCore preparado no disco virtual deve aparecer de forma similar quando usado o VMM QEMU. Para personalizar a imagem com extensões e outros arquivos, basta seguir o procedimento descrito em APÊNDICE A – Ambiente de Software Host -> Montagem Disco de Imagem.

Imagem initrd Separada Conforme capítulo 12 do manual do TinyCore (Kasanen, 2013), é possível criar imagens separadas para initrd. Isso permite criar e manter personalizações do sistema de software em uma imagem separada, facilitando atualizações. O objetivo aqui é criar uma imagem para mydata.tgz, pois na versão ISO/CD restore não funciona. No host Linux: > sudo apt-get install advancecomp > mkdir –p tiny-imgs/myimg > cd tiny-imgs/myimg Descompactar mydata.tgz aqui e ajustar permissões (1001 para tc): > sudo chmod -R 1001:staff home/ > sudo chmod -R root:staff opt/ > sudo chown 1001 usr > sudo chown -R root usr/* > sudo chgrp -R staff usr/ > sudo chgrp root usr/share Criando a imagem propriamente dita: > sudo find | sudo cpio -o -H newc | gzip -2 > ../myimg.gz > advdef -z4 ../myimg.gz

Boot com mais de uma Imagem Editar arquivo de configuração de boot39 conforme capítulo 12.2 do manual do TinyCore (Kasanen, 2013). No host Linux: > cd tiny-custom > vi ./boot/isolinux.cfg

39 Nome da imagem não aceita caracteres especiais como -.

208

INITRD /boot/core.gz,/boot/myimg.gz ou APPEND initrd=/boot/core.gz,/boot/myimg.gz Outra opção é fundir as imagens: > cat core.gz myimg.gz > new.gz

Construção de Pacotes e Aplicações Embora seja baseado no Linux, o GNU ToolChain do TinyCore é adaptado para o ambiente mais restritivo de uma distribuição de apenas 15 Mb comparada com cerca de 800 Mb de uma distribuição Linux normal. Dessa forma, qualquer código não suportado pelo TinyCore (ou seja, não existe extensão tcz pré-construída) precisa ser construído a partir do código fonte com o ToolChain do TinyCore, disponível nas extensões: > tce-load –wi compiletc squashfs-tools Portanto, para cada novo pacote ou aplicação, basta instalar estas duas extensões e as extensões de bibliotecas específicas que cada pacote depende. A opção de personalização via USB (pendrive) é a mais rápida, pois o sistema executa diretamente sem necessidade de virtualização usando QEMU, por exemplo. A personalização em disco de imagem, por sua vez, é mais flexível, e se o host for Linux o tempo de execução do QEMU pode ficar aceitável. Se for com VMware Player executando Guest-OS Linux sobre host Windows, por exemplo, executar TinyCore com QEMU para compilar torna o processo de construção inaceitavelmente lento.

Biblioteca Qt A biblioteca Qt oferece poderoso conjunto de bibliotecas em C++ que facilita e agiliza o desenvolvimento de aplicações. Com o TinyCore executando, e com usuário padrão tc e grupo staff, é preciso primeiro baixar o pacote com código fonte: > cd /mnt/sdb1/tce > mkdir qt5 > wget http://download.qt-project.org/official_releases/qt/5.3/5.3.0/single/qt-everywhere- opensource-src-5.3.0.tar.gz Para instalar extensões necessárias basta abrir ferramenta gráfica Apps:  Selecionar mirror  Iniciar busca pacotes tcz: Apps->Cloud->Browse  Selecionar Download Only  Verificar pasta tce: /mnt/sda1/tce/optional  Para cada pacote / extensão clicar em Go 209

 Baixar pacotes / extensões exigidos pelo Qt: compiletc, squashfs-tools, libGL-dev, gtk2-dev, python e xkeyboard-config

Instalar extensões: > tce-load –i libGL-dev > tce-load –i gtk2-dev > tce-load –i python > tce-load –i compiletc > tce-load –i squashfs-tools > tce-load –i xkeyboard-config Descompactar, configurar e compilar o pacote: > cd /mnt/sdb1/tce/qt5 > tar xzvf qt-everywhere-opensource-src-5.3.0.tar.gz >./configure --prefix=/usr/local -qt-xcb > make –j3 Criar extensão: > INSTALL_ROOT=/tmp/qt5-sdk make install –j3 > cd .. > mksquashfs /tmp/qt5-sdk qt5-sdk.tcz Para carregar extensão: > tce-load –wi qt5-sdk.tcz Para inicializar o sistema e carregar de forma automática a extensão: > cp –p qt5-sdk.tcz /mnt/sdb1/tce/optional/. > echo “qt5-sdk.tcz” >> /mnt/sdb1/tce/onboot.lst Criar arquivo de dependências: > vi /mnt/sdb1/tce/optional/qt5-sdk.tcz.dep fontconfig.tcz xkeyboard-config.tcz python.tcz libGL.tcz

Biblioteca OpenDDS Com o TinyCore executando, e com usuário padrão tc e grupo staff, é preciso primeiro baixar o pacote com código fonte: > cd /mnt/sdb1/tce > mkdir opendds > wget http://download.ociweb.com/OpenDDS/previous-releases/OpenDDS-3.6.tar.gz O código do ACE+TAO é baixado como parte do processo de instalação: > wget http://download.ociweb.com/TAO-2.2a/ACE+TAO-2.2a_with_latest_patches_NO_makefiles.tar .gz Instalar e carregar extensões de dependência: > tce-load –i perl5 Como no TinyCore o perl é instalado em: > which perl /usr/local/bin/perl é preciso fazer um link simbólico para apontar para o padrão configurado nos scripts perl do OpenDDS: > sudo ln –s /usr/local/bin/perl /usr/bin/perl Descompactar pacote, configurar e compilar: > cd /mnt/sdb1/tce/opendds > tar xzvf OpenDDS-3.6.tar.gz

210

> cd DDS > ./configure --prefix=/usr/local/opendds --no-tests > make São criadas as pastas DDS e ACE_wrappers. Como foi necessário usar a opção --no-tests para simplificar o processo de construção (por alguma razão no meio do processo de construção o ponto de montagem /mnt/sdb1 é desfeito), é preciso fazer alguns ajustes. É preciso construir a parte os testes de Benchmark: > cd /mnt/sdb1/tce/opendds/DDS/performance-tests/Bench > make e após a instalação: > sudo make install é preciso copiar o ambiente de testes: > cd /usr/local/opendds/share/ace > sudo cp –pr /mnt/sdb1/tce/opendds/ACE_Wrappers/bin/PerlACE . > cd /usr/local/opendds/share/dds > sudo cp –pr /mnt/sdb1/tce/opendds/DDS/performance_tests . > cd performance-tests > rm –rf DCPS performance_tests* GNUMakefile e atualizar o arquivo test_list.txt para a configuração de rede existente. As máquinas (ou VMs) envolvidas nos testes devem ser configuradas em: > cd performance-tests/Bench/tests > vi test_list.txt # group client server

5 vApp1.sinuv app.sinuv# Host-VM_L 6 vApp1.sinuv app.sinuv# Host-VM_R 7 vApp1.sinuv vApp2.sinuv# VM-VM_L 8 vApp1.sinuv vApp3.sinuv# VM-VM_R 9 vApp1.sinuv localhost# VM_Local 10 localhost vApp1.sinuv# VM_Local sendo necessário ainda substituir os existentes para os tipos de teste: > cd latency > sudo rm –f test_list.txt > sudo ln –s ../test_list.txt . > cd ../thru > sudo rm –f test_list.txt > sudo ln –s ../test_list.txt . Outro ajuste se faz necessário também devido ao fato da instalação do OpenDDS usar link simbólico absoluto em alguns arquivos, neste caso para o prefixo de instalação especificado /usr/local/opendds que é o destino final da instalação. Para permitir a correta criação da extensão é preciso primeiro mover a instalação para uma área temporária: > mkdir –p /tmp/opendds/usr/local > sudo chown –R root:root /tmp/opendds/usr > sudo mv /usr/local/opendds /tmp/opendds/usr/local A criação da extensão do novo pacote pode então ser feita da seguinte forma: > cd /mnt/sdb1/tce > mksquashfs /tmp/opendds opendds.tcz -b 4k -no-xattrs –root-becomes /usr/local > unsquashfs –ll opendds.tcz | more Para inicializar o sistema e carregar de forma automática a extensão: 211

> cp –p opendds.tcz /mnt/sdb1/tce/optional > echo opendds.tcz >> /mnt/sdb1/tce/onboot.lst > echo perl5.tcz >> /mnt/sdb1/tce/onboot.lst Criar arquivo de dependências: > vi /mnt/sdb1/tce/optional/opendds.tcz.dep perl5.tcz É preciso também configurar o ambiente para execução de aplicações OpenDDS: > vi $HOME/dds-setenv.sh TAO_ROOT=/usr/local/opendds/share/tao ACE_ROOT=/usr/local/opendds/share/ace CIAO_ROOT=dont_use_ciao DDS_ROOT=/usr/local/opendds/share/dds MPC_ROOT=/usr/local/opendds/share/tao/MPC LD_LIBRARY_PATH=/usr/local/opendds/lib:$LD_LIBRARY_PATH PATH=/usr/local/opendds/bin:$ACE_ROOT/bin:$DDS_ROOT/bin:$PATH export TAO_ROOT ACE_ROOT CIAO_ROOT DDS_ROOT MPC_ROOT LD_LIBRARY_PATH PATH > chmod +x $HOME/dds-setenv.sh Para construir as aplicações pode-se criar o seguinte script: > vi build.sh # seta variáveis de ambiente source dds-setenv.sh # gera Makefile $ACE_ROOT/bin/mwc.pl -type gnuace # compila tudo make > chmod +x build.sh

Aplicação como Extensão Aplicações desenvolvidas para o TinyCore são melhor portadas como extensões. Para preparar a aplicação, são seguidos os passos conforme capítulo 14 do manual do TinyCore (Kasanen, 2013). No host Linux: > sudo apt-get install squashfs-tools Prepara estrutura de diretórios e arquivos da aplicação: > cd tiny-imgs > mkdir -p app/home/tc > cp –p DDS61850-POC libDDS61850.so libDDS61850.so.3.6.0 run-publisher.sh setenv.sh ./home/tc Ajusta permissões: > sudo chown 1001 app > sudo chgrp staff app > sudo chmod -R 1001:staff ./app/* Cria extensão da aplicação e verifica: > mksquashfs app dds-app.tcz -b 4k -no-xattrs > unsquashfs -ll dds-app.tcz

Configurações Especiais Alguns recursos especiais podem ser úteis e necessários para ajustar a personalização do TinyCore às necessidades do sistema de software desejado.

212

Hostname Alterar hostname com comando hostname causa problema: GUI se perde no TinyCore depois de alterado hostname. Não se consegue abrir mais nada. É preciso alterar o arquivo /etc/hostname, o que exigiria criar um novo core.gz, ou de forma mais simples usar o arquivo bootsynch.sh: > sudo vi myimg/opt/bootsynch.sh … /usr/bin/sethostname vApp1.sinuv Outra opção é usar o código de boot host: > sudo vi iso-host/boot/isolinux/isolinux.cfg … APPEND host=vApp1.sinuv

Teclado Um exemplo é o ajuste de teclado. Basta instalar a extensão kmaps.tcz. Para carregar automaticamente a cada inicialização: > vi /opt/bootlocal.sh loadkmap < /usr/share/kmap/qwerty/br-abnt2.kmap Para fazer backup da configuração: > vi /opt/.filetool.lst opt home usr/share/kmap/qwerty/br-abnt2.kmap

Backup / Restore Recurso útil para salvar e recuperar arquivos modificados e persistir durante reinicializações do sistema. Os dados das pastas e arquivos definidos em /opt/.filetool.lst são salvos no arquivo /tce/mydata.gz.

Modo Cópia Recurso que permite avaliar se carregar em memória melhora desempenho. Neste modo, no lugar de montar extensões, para carregar em memória basta criar o seguinte arquivo vazio: > touch /tce/copy2fs.flg O arquivo copy2fs.lst permite selecionar quais extensões são carregadas em memória.

Configuração Ambiente 213

Como no Linux, é possível ajustar variáveis de ambiente e outras configurações, particularmente quando se usa um XTerm. As opções são mais limitadas. O arquivo .ashrc permite configurar o ambiente no TinyCore: > vi ~/.ashrc # Proxy export http_proxy=”http://domain%5Cuser:passw@proxy:8080” # Qt env export QMAKESPEC=/usr/local/mkspecs/Linux-g++ # OpenDDS env source dds-setenv.sh

Cópia Remota Existe uma forma simples de copiar arquivos via rede: > tce-load -wi openssh.tcz > scp -r tcp/ udp/ rtps/ multi-be/ multi-rel/ [email protected]:"/home/lasse/Documentos/SINUV/Testes/Host-Host/latency|thru

ISO TinyCore-Bench Descrição tipo HOW-TO do passo a passo de toda preparação que foi feita para construir o ambiente de testes. Para executar os testes com as aplicações de benchmark do OpenDDS no TinyCore foi criado em um host Linux uma iso personalizada com todos os arquivos necessários: tc-host_bench.iso A descrição a seguir mostra o trabalhoso processo de personalização de um sistema de software com os componentes necessários. A seguinte estrutura de diretórios foi utilizada: > mkdir –p tiny-core/tiny-bench > cd tiny-core/tiny-bench > tree -d ├── iso-host │ ├── boot │ │ ├── extlinux │ │ └── isolinux │ ├── cde │ │ ├── ondemand │ │ └── optional │ └── dds-img ├── host-img └── myimg ├── home │ └── tc │ └── performance-tests │ └── Bench │ ├── bin │ ├── doc │ │ └── images │ ├── etc │ ├── lib │ ├── src

214

│ ├── tests │ │ ├── latency │ │ │ ├── multi-be │ │ │ ├── multi-rel │ │ │ ├── tcp │ │ │ └── udp │ │ ├── scaling │ │ ├── scenarios │ │ ├── shared │ │ ├── spray │ │ └── thru │ │ ├── multi-be │ │ ├── multi-rel │ │ ├── tcp │ │ └── udp │ └── tools ├── opt │ └── backgrounds └── usr └── share └── kmap └── qwerty boot contém os arquivos de imagem do sistema TinyCore e a imagem personalizada: > mkdir –p tiny-core/tiny-bench/iso-host > cd tiny-core > wget http://tinycorelinux.net/7.x/x86/release/TinyCore-current.iso > sudo mkdir /mnt/tciso > sudo mount TinyCore-current.iso /mnt/tciso –o loop,ro > cd tiny-bench/iso-host > sudo cp –pR /mnt/tciso/boot ./boot > cd boot > ls core.gz isolinux vmlinuz As configurações de boot são feitas em: > vi isolinux/isolinux.cfg DEFAULT tc …

LABEL tc … KERNEL /boot/vmlinuz INITRD /boot/core.gz,/boot/myimg.gz APPEND cde quiet vga=0x314 Para configurar e permitir escolher o nome da máquina virtual são criadas quatro opções: > sudo vi iso-host/boot/isolinux/isolinux.cfg DEFAULT tc-vapp1 … LABEL tc-vaap1 MENU LABEL Boot TinyCore – vApp1 … APPEND nodhcp host=vApp1.sinuv …

LABEL tc-vaap2 MENU LABEL Boot TinyCore – vApp2 … APPEND nodhcp host=vApp2.sinuv …

LABEL tc-vaap3 MENU LABEL Boot TinyCore – vApp3 … APPEND nodhcp host=vApp3.sinuv …

LABEL tc-vaap4 MENU LABEL Boot TinyCore – vApp4 … APPEND nodhcp host=vApp4.sinuv … 215

cde contém os pacotes ou extensões do TinyCore: > cd tiny-bench/iso-host > sudo cp –pR /mnt/tciso/cde ./cde Com o sistema mínimo do TinyCore, versão gráfica, é possível então personalizá-lo com os pacotes desejados. Neste caso, é preciso criar o pacote do OpenDDS, conforme descrito anteriormente. Usando um pendrive formatado (Disks ou gparted) e conectado e detectado pelo Linux: > lsusb ID 0781:5567 > sudo qemu-system-i386 –m 1024 –cdrom CorePlus-current.iso –boot d -usb –usbdevice host:0x0781:0x5567 Escolher opção de boot: Boot Core with X/GUI (TinyCore) + Installation Extension Basta executar a aplicação TC Install para preparar o pendrive: Path to core.gz: /mnt/das/boot/core.gz USB-HDD Select disk for core: sdb On a removable device. Formatting Options: ext4 Boot Options: waitusb=5 Install Type: Core and X/GUI Desktop Inicializando a máquina com o sistema do pendrive pode-se construir o pacote do OpenDDS: > tce-load –wi compiletc squashfs-tools > tce-load –wi perl5

> cd /mnt/sdb1/tce > mkdir opendds > cd opendds > wget http://download.ociweb.com/OpenDDS/previous-releases/OpenDDS-3.6.tar.gz > tar xzvf OpenDDS-3.6.tar.gz > rm OpenDDS-3.6.tar.gz > cd DDS > ./configure --no-tests --prefix=/usr/local/opendds

> make > cd /mnt/sdb1/tce/opendds/DDS/performance-tests/Bench > make

> sudo ln –s /usr/local/bin/perl /usr/bin/perl > sudo make install

> cd /usr/local/opendds/share/ace > sudo cp –pr /mnt/sdb1/tce/opendds/ACE_Wrappers/bin/PerlACE . > cd /usr/local/opendds/share/dds > sudo cp –pr /mnt/sdb1/tce/opendds/DDS/performance_tests . > cd performance-tests > rm –rf DCPS performance_tests* GNUMakefile

> cd performance-tests/Bench/tests > vi test_list.txt # group client server

5 vApp1.sinuv app.sinuv# Host-VM_L 6 vApp1.sinuv piu.sinuv# Host-VM_R 7 vApp1.sinuv vApp2.sinuv# VM-VM_L 8 vApp1.sinuv vApp3.sinuv# VM-VM_R 9 vApp1.sinuv localhost# VM_Local 10 localhost vApp1.sinuv# VM_Local

216

> cd latency > sudo rm –f test_list.txt > sudo ln –s ../test_list.txt . > cd ../thru > sudo rm –f test_list.txt > sudo ln –s ../test_list.txt .

> mkdir –p /tmp/opendds/usr/local > sudo chown –R root:root /tmp/opendds/usr > sudo mv /usr/local/opendds /tmp/opendds/usr/local

> cd /mnt/sdb1/tce > mksquashfs /tmp/opendds opendds.tcz -b 4k -no-xattrs –root-becomes /usr/local > vi opendds.tcz.dep perl5.tcz O pacote opendds.tcz é copiado para: > cd iso-host/cde/optional > sudo cp –p usb/tce/optional/perl5.tcz* . > sudo cp –p usb/tce/opendds/opendds.tcz* . > sudo chown root:root perl5.tcz* opendds.tcz* Para carregar automaticamente o pacote do OpenDDS é preciso atualizar o arquivo onboot.lst: > sudo echo opendds.tcz >> iso-host/cde/onboot.lst > sudo echo perl5.tcz >> iso-host/cde/onboot.lst Para carregar os pacotes em memória RAM: > sudo echo opendds.tcz >> iso-host/cde/copy2fs.lst > sudo echo perl5.tcz >> iso-host/cde/copy2fs.lst A pasta dds-img contém o disco de imagem de um sistema similar, mas para uso como Guest-OS no TinyCore via VMM QEMU ou no Genode via VMM Seoul. A imagem é criada em host-img com as permissões ajustadas no caso do TinyCore: > ls tiny-bench/host-img -rw-rw-r-- 1 roger roger 174063616 Out 20 2015 tc-ddsbench_img.raw > ls –l tiny-bench/iso-host/dds-img -rw-rw-r-- 1 1001 staff 174063616 Out 20 2015 tc-ddsbench_img.raw Essa imagem é criada conforme descrito em Imagem TinyCore. A imagem myimg.gz será criada para conter as principais personalizações do sistema. A imagem de referência mydata.tgz está disponível em usb/tce: > cd tiny-bench/myimg > tar xzvf usb/tce/mydata.tgz A estrutura base de diretórios deve conter: > mkdir –p myimg/home/tc > mkdir –p myimg/opt > mkdir –p myimg/usr/share/kmap/qwerty Deve-se ajustar corretamente os usuários: > sudo chown root:staff home/ > sudo chown -R 1001:staff home/tc > sudo chown -R root:staff opt/ > sudo chown -R root:root usr/ Os seguintes scripts de execução e arquivos de configuração dos testes a serem realizados: auto_run_tests.pl performance_tests.lst localizados por padrão em: DDS/bin 217

devem ser copiados para: > cd myimg/home/tc > cp –p ~/DDS/bin/auto_run_tests.pl . > cp –p ~/DDS/bin/performance_tests.lst . com ajuste de usuário para 1001:staff: > sudo chown 1001:staff auto_run_tests.pl performance_tests.lst A lista de testes padrão contém testes do tipo latência para mensagem de tamanho 250: > vi myimg/home/tc/performance_tests-250.lst ## Run inter-host tests first performance-tests/Bench/tests/latency/run_test.pl tcp 250: !DCPS_MIN performance-tests/Bench/tests/latency/run_test.pl udp 250: !DCPS_MIN performance-tests/Bench/tests/latency/run_test.pl multi-be 250: !DCPS_MIN performance-tests/Bench/tests/latency/run_test.pl multi-rel 250: !DCPS_MIN performance-tests/Bench/tests/latency/run_test.pl rtps 250: !DCPS_MIN Para correta execução das aplicações, é preciso configurar variáveis de ambiente da instalação do pacote opendds.tcz: > cd myimg/home/tc > sudo vi dds-setenv.sh TAO_ROOT=/usr/local/opendds/share/tao ACE_ROOT=/usr/local/opendds/share/ace CIAO_ROOT=dont_use_ciao DDS_ROOT=/usr/local/opendds/share/dds MPC_ROOT=/usr/local/opendds/share/tao/MPC LD_LIBRARY_PATH=/usr/local/opendds/lib:$LD_LIBRARY_PATH PATH=/usr/local/opendds/bin:$ACE_ROOT/bin:$DDS_ROOT/bin:$PATH export TAO_ROOT ACE_ROOT CIAO_ROOT DDS_ROOT MPC_ROOT LD_LIBRARY_PATH PATH > sudo chown 1001:staff dds-setenv.sh > sudo chmod +x dds-setenv.sh A pasta opt permite incluir importantes personalizações de inicialização após o boot principal. São criados: > ls myimg/opt backgrounds bootlocal.sh bootsync.sh eth0.sh shutdown.sh tcemirror Para configurações de rede da máquina virtual: > sudo vi myimg/opt/bootsynch.sh #!/bin/sh /opt/bootlocal.sh &

> sudo vi myimg/opt/bootlocal.sh #!/bin/sh # put other system startup commands here HOST="$(hostname)" case $HOST in vApp1.sinuv) IP=93;; vApp2.sinuv) IP=94;; vApp3.sinuv) IP=95;; vApp4.sinuv) IP=96;; esac

/opt/eth0.sh $IP &

> sudo vi eth0.sh #!/bin/sh #pkill udhcp ifconfig eth0 179.106.230.$1 netmask 255.255.255.192 broadcast 179.106.230.127 up route add default gw 179.106.230.65 echo nameserver 8.8.8.8 > /etc/resolv.conf echo 127.0.0.1 localhost.local > /etc/hosts echo 179.106.230.90 piu.sinuv >> /etc/hosts

218 echo 179.106.230.91 app.sinuv >> /etc/hosts echo 179.106.230.93 vApp1.sinuv >> /etc/hosts echo 179.106.230.94 vApp2.sinuv >> /etc/hosts echo 179.106.230.95 vApp3.sinuv >> /etc/hosts echo 179.106.230.96 vApp4.sinuv >> /etc/hosts Dessa forma, a partir da opção selecionada no menu de boot, é possível criar um único iso que permite escolher a VM desejada. Para configurações de teclado: > sudo vi bootlocal.sh … loadkmap < /usr/share/kmap/qwerty/br-abnt2.kmap /opt/eth0.sh $IP & Na pasta usr é copiado o arquivo de teclado: > ls /myimg/usr/share/kmap/qwerty br-abnt2.kmap O script build-myimg.sh é criado para automatizar a construção da imagem: > cd tiny-bench > vi build-myimg.sh sudo rm myimg.gz cd myimg sudo find | sudo cpio -o -H newc | gzip -2 > ../myimg.gz advdef -z4 ../myimg.gz cd .. sudo chown root:root myimg.gz sudo cp -p myimg.gz iso-host/boot/.

> chmod +x build-myimg.sh

< sudo apt-get update > sudo apt-get install advancecomp Finalmente, para a criação da iso é usado um segundo script: > vi build-iso.sh sudo rm tc-bench.iso sudo mkisofs -l -J -R -r -V TC-Bench -no-emul-boot -boot-load-size 4 \ -boot-info-table -b boot/isolinux/isolinux.bin \ -c boot/isolinux/boot.cat -o tc-bench.iso iso-host sudo chown libvirt-qemu:kvm tc-bench.iso > chmod +x build-iso.sh Com o KVM Virtual Machine Manager, basta criar uma VM usando a iso recém criada conforme explicado no APÊNDICE A – Ambiente de Software Host.

Personalizando a Extensão OpenDDS É possível personalizar no host Linux as extensões do TinyCore: > cd tiny-core > mkdir -p tiny-tcz/opendds > cd tiny-tcz > cp –p usb/tce/opendds.tcz* . > cd opendds > sudo unsquashfs –xattrs ../opendds.tcz O resultado é o pacote OpenDDS construído que pode ser modificado conforme necessário. 219

Para recriar a extensão do OpenDDS pode-se usar o script a seguir: > vi build-opendds_dev.sh rm opendds-dev.tcz mksquashfs opendds/squashfs-root opendds-dev.tcz -b 4k -no-xattrs sudo chown 1001:staff opendds-dev.tcz

220

APÊNDICE C – Genode

O framework de SO Genode tem integrado um sistema de construção escalável e uma infraestrutura de ferramentas desenhados para a criação de sistemas de software altamente modulares e portáveis. Com base na documentação disponível40, é possível preparar um ambiente para criação de sistemas de software a partir do framework de SO Genode.

Instalação em Host Linux Código fonte: > git clone https://github.com/genodelabs/genode Primeiro é feita a instalação do Genode toolchain41 que compõem o sistema de construção (build system)42 do Genode. Instalação GCC 4.7.4 e binutils 2.22 com patches: > cd genode > cd tool > ./tool_chain > sudo apt-get install autoconf2.64 ncurses-dev texinfo autogen > ./tool_chain x86 Construção do Genode propriamente dita: > sudo apt-get install libsdl-dev tcl8.5 expect > sudo apt-get install bison flex gperf libxml2-utils xsltproc Para plataforma Linux: > cd genode > ./tool/create_builddir linux_x86 > cd build/linux_x86/ > make run/demo Para poder executar os testes no host é necessário instalar o qemu-system- x86_64: > sudo apt-get install qemu -y Para criar imagem iso dos sistemas é necessário instalar: > sudo apt-get install genisoimage

Microkernels Como framework de SO, o Genode já vem com suporte para a escolha de diferente microkernels. NOVA microhypervisor: > cd repos/base-nova > make prepare > cd genode

40 http://genode.org/documentation/developer-resources/getting_started 41 http://genode.org/download/tool-chain 42 http://genode.org/documentation/developer-resources/build_system 221

> ./tool/create_builddir nova_x86_64 > cd build/nova_x86_64/ > make run/demo OKL4: > repos/base-okl4 > make prepare > cd genode > ./tool/create_builddir okl4_x86 > cd build/okl4_x86/ > make run/demo Fiasco-OC 32: > repos/base-foc > make prepare > cd genode > ./tool/create_builddir foc_x86_64 > cd build/foc_x86_64/ > make run/demo > sudo apt-get install gawk e 64-bits: > cd repos/dde_ipxe > make prepare > cd genode > ./tool/create_builddir foc_x86_32 > cd build/foc_x86_32 > nano etc/build.conf > make run/l4linux

Bibliotecas de Terceiros O Genode já vem com um conjunto de bibliotecas base: > cd genode/repos/libports > make > make prepare PKG=libc > make prepare PKG=x86emu > make prepare PKG="stdcxx icu mesa zlib libpng jpeg freetype qoost qt5" > make prepare PKG="openssl lwip" Precisa habilitar em build.conf gems: app/floating_window_layouter app/decorator O repositório ports depende de libc e libports: > cd genode/repos/ports > make > make prepare PKG="arora bash gcc gdb make netcat netperf binutils" Para incluir bibliotecas mais específicas, como suporte a TCP/IP e USB do Linux: > cd repos/dde_linux > make prepare Para suporte a NetBSD file-system: > cd repos/dde_rump > make prepare Para L4Linux: > cd repos/ports-foc > make prepare PGK=l4linux Para virtualização com Seoul e VirtualBox: > cd genode/repos/ports > make prepare PKG="seoul virtualbox"

222

Aplicação Teste Para testar o funcionamento do ambiente Genode instalado, é possível criar uma aplicação simples. A aplicação helloworld descrita na seção 2.5 do manual é apresentada aqui. Primeiro cria-se o componente Genode: > mkdir -p repos/sinuv/src/app/hello > nano main.cc #include int main() { Genode::printf( "Hello world\n" );

return 0; }

> nano target.mk TARGET = hello SRC_CC = main.cc LIBS += base Depois se faz o build da aplicação: > nano etc/build.conf REPOSITORIES += $(GENODE_DIR)/repos/sinuv > make app/hello > cd app/hello Para testar é preciso definir um cenário de sistema que incorpore o componente, ou seja, um script run: > mkdir /repos/lab/run > cd run > nano hello.run build "core init app/hello" create_boot_directory install_config { } build_boot_image "core init hello" append qemu_args "-nographic -m 64" run_genode_until {child "hello" exited with exit value 0} 10 Finalmente pode-se executar o sistema com a aplicação: > cd build > make run/hello [init -> hello] Hello world [init] virtual void Genode::Child_policy::exit(int): child "hello" exited with exit value 0 Run script execution successful.

Portando Bibliotecas Específicas 223

É possível portar (termo usado pelo Genode) bibliotecas ou pacotes de software não disponíveis na instalação padrão, como Qt e OpenDDS. A documentação disponível43 44 45 explica o processo do sistema de construção. Por se tratar de um ambiente bem específico, diferentemente do TinyCore baseado em Linux, a complexidade e o trabalho envolvido para portar código é bem significativa. O sistema de construção do Genode exige a criação de vários arquivos de configuração, makefile e patches46. Além disso, é preciso pesquisar e conhecer a fundo as características de configuração para construção do pacote específico para poder fazer os ajustes necessários (configurações de arquivos de cabeçalho e makefile específicos de plataforma/compilador) e conseguir finalmente compilar e construir as bibliotecas. No final, torna-se mais uma tarefa de tentativa e erro até conseguir, se conseguir.

Portando OpenDDS A tentativa de portar o pacote do OpenDDS se mostrou uma tarefa bem desafiadora e trabalhosa. Foi necessário pesquisar outros documentos do Genode47 48. Por ser composto por dezenas de bibliotecas, o processo de construção deve ser repetido para cada uma, tornando ainda mais trabalhoso e demorado o porte do OpenDDS para o Genode. Outro aspecto que dificulta ainda mais é quando existem ferramentas específicas do pacote que precisam ser construídas para o ambiente do Genode também, como no caso do OpenDDS com as ferramentas ace_gperf e tao_idl necessárias para construção do ACE e TAO. Neste caso, a melhor solução é

43 http://genode.org/documentation/developer-resources/porting 44 http://genode.org/documentation/developer-resources/porting_libraries 45 http://genode.org/documentation/developer-resources/porting_applications 46 Modificações do código padrão do pacote devido os ajustes de ambiente necessários que devem ser aplicadas para a correta construção do pacote no Genode 47 http://genode.org/files/53bcb8e33fe6602fed25edc3c7b922c5/manual-2015-04-27.pdf 48 http://genode.org/documentation/developer-resources/coding_style

224 construir essas ferramentas no host Linux onde o ambiente do Genode foi instalado, e, portanto, onde as aplicações OpenDDS para Genode serão construídas também. Não será detalhado aqui todo esse processo, até porque não foi possível concluir a construção de todo o pacote devido principalmente ao tempo exigido, alguns problemas encontrados e não menos importante devido a incerteza de não se saber se dará o resultado esperado. Um aspecto importante dessa experiência foi perceber a grande complexidade por trás do OpenDDS, construído a partir de código do CORBA, ou seja, mostra claramente que não é uma solução DDS “pura” construída do zero. Outras bibliotecas como o OpenSlice, por exemplo, podem ser mais simples de portar. Bibliotecas proprietárias, por sua vez, como o CoreDX e RTI, poderiam ser portadas também, mas dependeriam da disponibilização do código fonte, pois não existe ainda um binário disponível construído para o Genode. Mas a título de conhecimento, ficam as referências e considerações aqui destacadas. Em razão dessas dificuldades e incertezas para usar o Genode como Guest- OS, o foco do trabalho acabou se voltando para o TinyCore como Guest-OS. O Genode com Nova+Seoul, como microvisor e VMM ainda foi uma opção considerada também conforme descrito a seguir.

VMM Seoul e VirtualBox O Genode tem suporte para virtualização com Seoul ou VirtualBox. No caso do Seoul, foi necessário instalar um branch do seoul_wm_cli do projeto Genode contendo uma correção49: > mkdir alex-ab > git clone https://github.com/alex-ab/genode.git > git fetch > git checkout seoul_wm_cli

> cd tool > ./tool_chain x86

> cd repos/libports > make prepare PKG=libc x86emu libpng zlib Suporte para USB: > cd repos/dde_linux > make prepare Suporte a nic_drv:

49 Após contato por e-mail. Agradecimentos a Alexander Boettcher. 225

> cd repos/dde_ipxe > make prepare Seoul x86-32 VMM: > cd repos/ports > make prepare PKG=seoul Microkernel NOVA: > cd repos/base-nova > make prepare > ./tool/create_builddir nova_x86_32 > cd build/nova > vi ./etc/build.conf > make run/seoul-wm-cli > cp -p repos/gems/src/app/backdrop/genode_logo.png build/nova_x86_32/bin/. > cp -p grid.png Para criar a iso do sistema, é usado um script de run do Genode. Neste caso foi criado um a partir do script padrão seoul-wm-cli.run que basicamente exclui a parte relativa ao esquema multiboot de boot da VM baseado no bootloader munich que não funcionou com o módulo da imagem tc-image.gz do sistema TinyCore personalizado: … … … # # Download demo kernel, image and # munich (part of Oslo framework http://os.inf.tu-dresden.de/~kauer/oslo) # set guest_os_binaries { munich bzImage-3.1 tc-browser.gz } set sha1_os_binaries { 7ecb4ba634a0ecfa6429418ea73490d6f65afead 6b2ef2c5bf16db3ebcbe33ce134e4e0a96944f82 51aa53eb494b71d65f7fe3eb05e52af4616878bd} set uri "http://genode.org/files/seoul" foreach binary $guest_os_binaries { … } if {$guest_os_binary_missing} { exit 1 } append boot_modules image.raw append boot_modules $guest_os_binaries Abaixo as personalizações feitas baseadas no esquema de boot a partir de um disco de imagem: > cd /alex-ab/genode/repos/gems/run > vi seoul-wm-cli_tc-dds.run …

226

## aloca espaço suficiente para tamanho disco de imagem … … …

# Disc image for Seoul VM variant starting from a raw disc append boot_modules tc-dds_img.raw A imagem de disco tc-dds_img.raw do TinyCore personalizado precisa ser criada conforme descrito no APÊNDICE B – TinyCore -> TinyCore como Guest- OS para VMM Seoul. Para personalizar basta copiar as extensões .tcz para tce/optional, e onboot.lst e mydata.tgz para tce. Para o sistema construído para os testes, APÊNDICE B – TinyCore -> ISO TinyCore-Bench, a imagem construída conforme descrito em APÊNDICE B – TinyCore -> Imagem TinyCore, está localizada em: tiny-bench/host-img/tc-ddsbench_img.raw Como essa imagem faz parte integrante dos binários e arquivos de configuração do Genode que compõem o sistema gerado na iso: > ls alex-ab/genode/build/nova_x86_32/var/run/seoul-wm-cli_tc-dds/genode é preciso copiá-la no diretório base de build do microkernel: > cd genode/build/nova_x86_32/bin > ln –s tiny-bench/host-img/tc-ddsbench_img.raw tc-dds_img.raw Seoul só é suportado pelo NOVA 32-bits. Executando: > cd alex-ab/genode/build/nova_x86_32 > make run/seoul-wm-cli_tc-dds.run a iso do sistema é criada e fica disponível em: > cd alex-ab/genode/build/nova_x86_32/var/run > ls seoul-wm-cli_tc-dds seoul-wm-cli_tc-dds.iso podendo ser executada no QEMU, VM Player ou USB, por exemplo. Usando QEMU: > sudo qemu-system-i386 -m 1024 -cdrom seoul-wm-cli_tc-dds.iso -boot d

227

Comunidade O Genode tem uma comunidade bem ativa com profissionais desenvolvedores sempre disponíveis para tirar dúvidas. Existe uma mailing list: https://lists.sourceforge.net/lists/options/genode-main Para postar mensagens para todos os membros da lista, basta enviar um e- mail para: [email protected].

228

APÊNDICE D – Resultados Benchmark OpenDDS

Os resultados dos testes de benchmark do OpenDDS são apresentados a seguir. Para cada cenário de teste são obtidos os seguintes gráficos:  Latência e jitter por amostra ou mensagem e distribuição da latência e do jitter para cada tipo de protocolo de mensagem em uma única imagem;  Densidade de latência e quantiles por tamanho de mensagem para tcp e udp; e  Latência e jitter normalizado por tamanho de mensagem para todos os protocolos de transporte, melhor visualizado para o teste completo de todos os tamanhos de mensagem. Os gráficos mostram um mapa claro das medições de latência e cálculo de jitter por amostra, bem como os respectivos resultados estatísticos para uma média de 11000 mensagens ou amostras por teste. Para gerar os resultados a partir dos dados de medição salvos, é preciso criar o seguinte script: > vi /home/sinuv/SINUV/tests/generate-results.sh source /home/sinuv/DDS/setenv.sh

TESTDIR="/home/sinuv/SINUV/tests" for teste in Host-Host Host_Local Host-VM_L Host-VM_R VM_Local VM-VM_L VM-VM_R do ./generate-test-results.sh "$TESTDIR/$teste/latency"

DATADIR="$TESTDIR/$teste/latency/data"

OUTDIR="$TESTDIR/results/$teste"

mkdir -p "$OUTDIR"

./plot-test-results.sh $DATADIR $OUTDIR

#read input done > chmod +x generate-results.sh Os seguintes scripts padrão do OpenDDS precisam ser copiados localmente e alterados para ajustar a localização dos cenários de teste e restrição para mensagem de tamanho de 250: > cd /home/sinuv/SINUV/tests > cp –p ~/DDS/performance-tests/Bench/bin/generate-test-results.sh > vi generate-test-results.sh … process_latency_test () { # local TESTDIR="$BASEDIR/tests/latency" local TESTDIR="$BASEDIR" local DATADIR="$TESTDIR/data"

mkdir -p "$DATADIR"

# for sz in 50 100 250 500 1000 2500 5000 8000 16000 32000 229

for sz in 250 …

> cp –p ~/DDS/performance-tests/Bench/bin/plot-test-results.sh > vi plot-test-results.sh … plot_latency_results () { # local DATADIR="$BASEDIR/tests/latency/data" local DATADIR="$BASEDIR" … # for sz in 50 100 250 500 1000 2500 5000 8000 16000 32000 for sz in 250 … Basta executar o script criado para gerar os resultados desejados: > ./generate-results.sh Os resultados são salvos em: > tree –d └── thru ├── Host_Local ├── Host-Host ├── Host-VM_L ├── Host-VM_R ├── VM_Local ├── VM-VM_L └── VM-VM_R Abaixo são apresentados os resultados do teste Host_Local para os todos os protocolos de transporte suportados pelo OpenDDS. UDP não é suportado para teste local. Host_Local

230

231

232

APÊNDICE E – Ambiente de Testes para o Estudo de Caso

Conforme recomendado no projeto do estudo de caso, seção 7.2.4 Aplicação PAC61850, o desenvolvimento de um código fonte único da aplicação se mostrou uma decisão acertada, por manter uma estrutura única de projeto do código, e construção de um único executável. O modelo DDS, construído a parte como uma biblioteca, é link editado com o código objeto binário da aplicação para construir o executável final.

Ambiente de Desenvolvimento Para desenvolver as aplicações PAC61850, foi necessário seguir alguns passos específicos em função de mudanças do Host-OS para Linux Ubuntu 16.04 LTS, mudança de versão do pacote Qt, e algumas particularidades encontradas. Uma máquina Windows foi utilizada com a ferramenta Eclipse Luna e plug-in do OpenDDS para desenvolvimento do modelo DDS e geração do código fonte correspondente. O host app.sinuv foi configurado como máquina de desenvolvimento do código da aplicação, usando a ferramenta tipo IDE qtcreator, e criação da iso ou imagem da VM. O host piu.sinuv foi configurado como máquina de compilação e link- edição do código para o TinyCore. O SO TinyCore, versão TinyCore- current.iso, foi instalado em um pendrive usado para iniciar a máquina piu.sinuv: app > sudo apt-get install unetbootin app > sudo unetbootin Dessa forma, fica mais fácil e seguro construir os pacotes do OpenDDS e Qt, bem como a aplicação em si, mantendo os arquivos no sistema de arquivos do host a partir do ponto de montagem /home/lasse, principalmente pelo tamanho do pacote fonte e arquivos objeto.

Host app.sinuv Estrutura de diretórios utilizada no host app.sinuv: > cd ~/sinuv > tree –P “*.sh” . ├── ACE_wrappers 233

├── BAY61850 │ ├── BAY61850 │ │ ├── dds │ │ ├── sep │ │ ├── sim │ │ └── ui │ ├── model │ │ ├── build.sh │ │ └── setenv.sh │ ├── run-app.sh │ ├── run-dcps.sh │ └── run-sys.sh ├── clock │ ├── clock.sh │ └── plot.sh ├── datamash-1.2 ├── DDS │ └── setenv.sh ├── Number-FormatEng-0.03 ├── qt5-build-noex ├── qt-build ├── qt-everywhere-opensource-src-5.9.0 ├── tc │ ├── app │ │ └── home │ │ └── tc │ │ ├── run-app.sh │ │ ├── run-dcps.sh │ │ └── setenv.sh │ ├── build-app.sh │ ├── build-iso.sh │ ├── build-myimg.sh │ ├── cp-tc-bin.sh │ ├── iso-host │ │ ├── boot │ │ │ └── isolinux │ │ └── cde │ │ └── optional │ ├── myimg │ │ ├── home │ │ │ └── tc │ │ │ └── clock.sh │ │ ├── opt │ │ │ ├── bootlocal.sh │ │ │ ├── bootsync.sh │ │ │ └── eth0.sh │ │ └── usr │ │ └── share │ │ └── kmap │ │ └── qwerty │ └── tc-tcz └── testsdetalhado mais adiante Scripts criados: > ls ./ BAY61850/run-app.sh source /home/lasse/sinuv/DDS/setenv.sh export LD_LIBRARY_PATH=/home/lasse/sinuv/BAY61850/model:${LD_LIBRARY_PATH}

./BAY61850app $1 -DCPSConfigFile dds_tcp_conf.ini

> ls ./ BAY61850/run-sys.sh ./run-app.sh monitor & ./run-app.sh piu & ./run-app.sh control & ./run-app.sh ihm & ./run-app.sh med & ./run-app.sh prot &

Host piu.sinuv

234

Estrutura de diretórios utilizada no host piu.sinuv: > cd ~/sinuv > tree –P “*.sh” . ├── ACE_wrappers ├── app-build-tcbinários da aplicação para TinyCore │ ├── build.sh │ ├── qt-env.sh │ └── setenv-dev.sh ├── app-src │ └── BAY61850 │ ├── BAY61850 │ │ ├── dds │ │ ├── sep │ │ ├── sim │ │ └── ui │ ├── cp-app.sh │ └── model │ ├── build.sh │ └── setenv-dev.shln -s app-build-tc ├── BAY61850binários e biblioteca da aplicação para Host │ ├── clock.sh │ ├── cp-app.sh │ ├── model │ └── run-app.sh ├── DDS │ └── setenv.sh ├── opendds-tcbinários do OpenDDS para TinyCore │ ├── ACE_wrappers │ └── DDS ├── qt5-build-tcbinários do Qt para TinyCore └── tc ├── cp-iso.sh └── tczcontêm pacotes TinyCore Scripts criados: > ls ./app-build-tc/build.sh # seta variáveis de ambiente . ./setenv-dev.sh . ./qt-env.sh

# gera Makefile qmake ../app-src/BAY61850/BAY61850/BAY61850.pro -r -spec linux-g++

# compila tudo make

> ls ./app-build-tc/setenv-dev.sh BASE_DEV=/mnt/sda5/lasse/sinuv/opendds-tc

DDS_ROOT=$BASE_DEV/DDS ACE_ROOT=$BASE_DEV/ACE_wrappers MPC_ROOT=$ACE_ROOT/MPC CIAO_ROOT=dont_use_ciao TAO_ROOT=$ACE_ROOT/TAO

PATH=$ACE_ROOT/bin:$DDS_ROOT/bin:$PATH LD_LIBRARY_PATH=$ACE_ROOT/lib:$DDS_ROOT/lib:$LD_LIBRARY_PATH export ACE_ROOT TAO_ROOT CIAO_ROOT DDS_ROOT MPC_ROOT LD_LIBRARY_PATH PATH

> ls ./app-build-tc/qt-env.sh export QMAKESPEC=/usr/local/mkspecs/linux-g++

> ls ./app-src/BAY61850/cp-app.sh # fonte modelo cd model sudo rm BAY61850* GNUmakefile* sudo scp -p [email protected]:/home/lasse/sinuv/BAY61850/model/BAY61850_* . sudo scp -p [email protected]:/home/lasse/sinuv/BAY61850/model/BAY61850.* . 235 sudo scp -p [email protected]:/home/lasse/sinuv/BAY61850/model/BAY61850Traits.* . sudo chown 1001:staff *

# fonte aplicação cd .. sudo rm -r ./BAY61850/* sudo scp -rp [email protected]:/home/lasse/sinuv/BAY61850/BAY61850 . sudo chown -R 1001:staff ./BAY61850/**/* sudo chown -R 1001:staff ./BAY61850/*

> ls ./app-src/BAY61850/model/build.sh # seta variáveis de ambiente . ./setenv-dev.sh # gera Makefile $ACE_ROOT/bin/mwc.pl -type gnuace # compila tudo make

> ls ./BAY61850/clock.sh #!/bin/bash t1=`ssh app.sinuv date +"%S.%N"` t2=`date +"%S.%N"` echo "$t1-$t2" | bc

> ls ./BAY61850/cp-app.sh scp [email protected]:/home/lasse/sinuv/BAY61850/model/libBAY61850* ./model scp [email protected]:/home/lasse/sinuv/BAY61850/build-BAY61850-Desktop-Release/BAY61850 . scp [email protected]:/home/lasse/sinuv/BAY61850/build-BAY61850-Desktop-Release/run-app.sh . scp [email protected]:/home/lasse/sinuv/BAY61850/build-BAY61850-Desktop-Release/dds_tcp_conf.ini .

> ls ./BAY61850/run-app.sh source /home/lasse/sinuv/DDS/setenv.sh export LD_LIBRARY_PATH=/home/lasse/sinuv/BAY61850/model:${LD_LIBRARY_PATH}

./BAY61850 $1 -DCPSConfigFile dds_tcp_conf.ini

> ls ./tc/cp-iso.sh sudo scp [email protected]:~/sinuv/tc/tc-app.iso .

Sincronismo de Tempo UTC foi usado como timezone. Nos 2 hosts Linux, o sincronismo de tempo é realizado através do NTP: > sudo timedatectl set-timezone Etc/UTC Servidor NTP LASSE:

> sudo timedatectl set-ntp no > timedatectl Local time: Sex 2017-11-17 15:54:07 -02 Universal time: Sex 2017-11-17 17:54:07 UTC RTC time: Sex 2017-11-17 17:54:07 Time zone: America/Sao_Paulo (-02, -0200) Network time on: no NTP synchronized: yes RTC in local TZ: no

236

> sudo apt-get install ntp > nano /etc/ntp.conf server 179.106.217.246 maxpoll 1 iburst > sudo service ntp restart > sudo ntpq -pn remote refid st t when poll reach delay offset jitter ======*179.106.217.246 .GPS. 1 u 5 8 377 0.785 -0.037 0.214 No TinyCore foi necessário instalar o pacote ntpclient.tcz e criar o script clock.sh: tc > sudo vi sinuv/tc/app/home/tc/clock.sh sudo ntpclient -s -h $1 while [ 1 ] do sleep $2 sudo ntpclient -c 1 -t -h $1 done

Execução Antes de executar cada aplicação, é necessário preparar o ambiente. Primeiro é preciso lançar o serviço DCPSInfoRepo da interface Data-Centric Publish-Subscribe que prove o espaço global de dados dos tópicos ou barramento virtual de comunicação de todo o sistema. O host app.sinuv foi escolhido para hospedar este serviço: app > vi sinuv/BAY61850/run-dcps.sh source ~/sinuv/DDS/setenv.sh

DCPSInfoRepo -ORBEndpoint iiop://app.sinuv:12345 & app > ./run_dcps O script setenv.sh do OpenDDS define as variáveis de ambiente do mesmo de acordo com a localização da instalação do pacote. No host Linux: export DDS_ROOT=/home/lasse/sinuv/DDS export PATH=/home/lasse/sinuv/ACE_wrappers/bin:/home/lasse/sinuv/DDS/bin:${PATH} export ACE_ROOT=/home/lasse/sinuv/ACE_wrappers export MPC_ROOT=/home/lasse/sinuv/ACE_wrappers/MPC export CIAO_ROOT=dont_use_ciao export TAO_ROOT=/home/lasse/sinuv/ACE_wrappers/TAO export LD_LIBRARY_PATH=/home/lasse/sinuv/ACE_wrappers/lib:/home/lasse/sinuv/DDS/lib:${LD_LIBRARY_PATH } No Guest-OS TinyCore: BASE_RUN=/usr/local/opendds

DDS_ROOT=$BASE_RUN/share/dds ACE_ROOT=$BASE_RUN/share/ace CIAO_ROOT=dont_use_ciao TAO_ROOT=$BASE_RUN/share/tao MPC_ROOT=$TAO_ROOT/MPC

PATH=$BASE_RUN/bin:$ACE_ROOT/bin:$DDS_ROOT/bin:$PATH LD_LIBRARY_PATH=$BASE_RUN/lib:$LD_LIBRARY_PATH export TAO_ROOT ACE_ROOT CIAO_ROOT DDS_ROOT MPC_ROOT LD_LIBRARY_PATH PATH 237

O segundo passo para VM com Guest-OS TinyCore é executar o script de sincronismo de tempo: tc > ./clock.sh app.sinuv 10 usando o host app.sinuv como fonte de tempo e execução cíclica do ntpclient a cada 10 s. A execução da aplicação, seja no host Linux Ubuntu ou VM Guest-OS TinyCore, é simples e direta através do script a seguir. Host Linux: app > vi sinuv/BAY61850/run-app.sh source /home/lasse/sinuv/DDS/setenv.sh export LD_LIBRARY_PATH=/home/lasse/sinuv/BAY61850/model:${LD_LIBRARY_PATH}

./BAY61850app $1 -DCPSConfigFile dds_tcp_conf.ini Guest-OS TinyCore: tc > sudo vi sinuv/tc/app/home/tc/run-app.sh source setenv.sh export LD_LIBRARY_PATH=.:${LD_LIBRARY_PATH}

./BAY61850 $1 -DCPSConfigFile dds_tcp_conf.ini Para executar a aplicação: > ./run-app [mod] onde mod representa o módulo ou aplicação específica do sistema BAY61850: piu; prot; control; med; ihm; ou monitor. A conexão com o barramento virtual do OpenDDS é feita através do arquivo de configuração dds_tcp_conf.ini: # This "common" section configures the data in Service_Participant. [common]

# Debug Level DCPSDebugLevel=0

# IOR of DCPSInfoRepo process. DCPSInfoRepo=corbaloc::app.sinuv:12345/DCPSInfoRepo

# Sets the global transport configuration (used by default in the # process to config1, defined below DCPSGlobalTransportConfig=config1

# Transport configuration named config1, contains a single transport # instance named tcp1 (defined below) [config/config1] transports=tcp1

# Transport instance named tcp1, of type "tcp". Uses defaults for # all configuration paramaters. [transport/tcp1] transport_type=tcp

238

ISO A construção da iso ou imagem da máquina virtual com Guest-OS Tinycore é feita, na primeira vez, pelos seguintes scripts nesta sequência: app > cd ~/sinuv/tc > ./cp-tc-bin.sh > ./build-myimg.sh > ./build-app.sh > ./build-iso.sh O script build-myimg.sh cria a imagem com customizações da instalação, como diretório /home/tc, pacotes tcz a serem carregados e configurações de rede e teclado. sudo rm myimg.gz cd myimg sudo find | sudo cpio -o -H newc | gzip -2 > ../myimg.gz advdef -z4 ../myimg.gz cd .. sudo chown root:root myimg.gz sudo cp -p myimg.gz iso-host/boot/. O script build-app.sh cria o pacote da aplicação com os arquivos binários e de configuração: rm -f dds-app.tcz mksquashfs app dds-app.tcz -b 4k -no-xattrs sudo chown 1001:staff dds-app.tcz sudo cp -p dds-app.tcz iso-host/cde/optional/. O script build-iso.sh cria a iso propriamente dita: sudo rm tc-app.iso sudo mkisofs -l -L -R -r -V TC-App -no-emul-boot -boot-load-size 4 \ -boot-info-table -b boot/isolinux/isolinux.bin \ -c boot/isolinux/boot.cat -o tc-app.iso iso-host sudo chown libvirt-qemu:kvm tc-app.iso O script cp-tc-bin.sh foi criado para copiar os binários gerados para o TinyCore: sudo scp -p [email protected]:/home/lasse/sinuv/app-build-tc/BAY61850 ./app/home/tc/. sudo scp -p [email protected]:/home/lasse/sinuv/app-src/BAY61850/model/libBAY61850* ./app/home/tc/.

Resumo Passo a Passo O passo a passo para criação e execução de todo o sistema BAY61850 é resumido a seguir.

1. Host app.sinuv Código fonte aplicação e modelo DDS. Execução teste local. 2. Host Dev Copiar código fonte para host piu.sinuv: piu.sinuv piu > cd ~/sinuv/BAY61850 piu > ./cp-app.sh 239

Copiar código fonte para TinyCore: piu> cd ~/sinuv/app-src/BAY61850 piu> ./cp-appcode.sh 3. Compilar Guest-OS Bootar piu.sinuv com USB TinyCore: > mount /dev/sda5 > cd /mnt/sda5/lasse Instalar pacotes dev: > cd sinuv/tc/tcz > tce-load -i libGL-dev gtk2-dev python compiletc perl squashfs-tools xkeyboard-config fontconfig > cd sinuv > tce-load -i opendds-dev qt5-sdk a. Construindo modelo > sudo ln -s /usr/local/bin/perl /usr/bin/perl > cd sinuv/app-src/BAY61850/model > ./build.sh b. Construindo > cd sinuv/app-build-tc > vi app-src/BAY61850/BAY61850/commons.pri aplicação APPSRC=/mnt/sda5/lasse/sinuv/app-src/BAY61850 > ./build.sh 4. Cria iso No host app.sinuv: > cd sinuv/tc Copia binários gerados para TinyCore no host piu.sinuv: > ./cp-tc-bin.sh Cria pacote tcz da aplicação: > ./build-app.sh Cria customizações do Guest-OS TinyCore: > ./build-myimg.sh Cria iso propriamente dita: > ./build-iso.sh Distribui iso: piu > cd ~/sinuv/tc piu > ./cp-iso.sh 5. Lança Hypervisor KVM: > virt-manager & VBox: > virtualbox & a. Host app.sinuv Sincronismo de tempo com NTP: > sudo timedatectl set-ntp no > sudo apt-get install ntp > nano /etc/ntp.conf server 179.106.217.246 maxpoll 1 iburst > sudo service ntp restart > sudo ntpq -pn Lança serviço DCPS: > cd ~/sinuv/BAY61850 > ./run-dcps.sh Lança aplicação Simulador/PIU: > ./run-app.sh piu & Abre KVM ou VBox: > virtualbox & Executa VMs vApp1 (prot) e vApp2 (control). vApp1 > ./clock.sh app.sinuv 10 vApp1 > ./run-app prot &

vApp2 > ./clock.sh app.sinuv 10 vApp2 > ./run-app control &

240

b. Host piu.sinuv Sincronismo de tempo com NTP: > sudo timedatectl set-ntp no > sudo apt-get install ntp > nano /etc/ntp.conf server 179.106.217.246 maxpoll 1 iburst > sudo service ntp restart > sudo ntpq -pn Lança aplicação monitor: > cd ~/sinuv/BAY61850 > ./run-app.sh monitor & Abre KVM ou VBox: > virtualbox & Executa VMs vApp3 (med) e vApp4 (ihm). vApp3 > ./clock.sh app.sinuv 10 vApp3 > ./run-app med &

vApp4 > ./clock.sh app.sinuv 10 vApp4 > ./run-app ihm &

Tratamento Dados Para tratar os dados gerados pelos testes e automatizar a geração dos resultados, foram aproveitados diversos scripts disponíveis no pacote do OpenDDS: app > ls DDS/performance-tests/Bench/bin/ expandColors.pl plot-jitter.gpi extract-latency.pl plot-quantiles.gpi extract-throughput.pl plot-test-results.sh generate-perf-html.sh plot-throughput-testformats.gpi generate-test-results.sh plot-throughput-transports.gpi gen-latency-stats.pl plot-transports.gpi gen-latency-tables.pl plot-transports-scaling.gpi gen-run-info-table.pl reduce-latency-data.pl gen-throughput-tables.pl reduce-shared-data.pl lj-plots.gpi run_test mktable.pl testprocess plot-density.gpi Os seguintes scripts foram copiados e reconfigurados: app > ls -1 ~/sinuv/tests extract-latency.pl generate-results.sh generate-test-results.sh gen-latency-stats.pl lj-plots.gpi plot-density.gpi plot-jitter.gpi plot-quantiles.gpi plot-test-results.sh plot-transports.gpi reduce-latency-data.pl Além desses, os scripts a seguir foram criados para tratar melhor os dados: clean-results.sh latency-csv.sh latency-topic.sh stats.sh Os seguintes pacotes foram instalados para facilitar algumas ações: > wget http://ftp.gnu.org/gnu/datamash/datamash-1.2.tar.gz > tar -xzf datamash-1.2.tar.gz > cd datamash-1.2 > ./configure > make > make check > sudo make install 241

> wget http://search.cpan.org/CPAN/authors/id/G/GS/GSULLIVAN/Number-FormatEng-0.03.tar.gz > tar -xzf Number-FormatEng-0.03.tar.gz > cd Number-FormatEng-0.03 > perl Makefile.PL > make > make test > make install Para gerar todos os resultados, basta executar o script geral: app:~/sinuv/tests $ ./generate-results.sh que executa o seguinte: # baseado nos scripts: # - DDS/performance-tests/Bench/bin/generate-test-results.sh # - DDS/performance-tests/Bench/bin/plot-test-results.sh # set -o errexit source /home/lasse/sinuv/DDS/setenv.sh

TESTDIR="/home/lasse/sinuv/tests" for teste in Sys_t20 Sys_t10 Sys_t2 Sys_t20_ntp10 Sys_t10_ntp10 Sys_t2_ntp10 Host_local_t20 Host_local_t10 Host_local_t2 do DATADIR="$TESTDIR/$teste/latency"

OUTDIR="$TESTDIR/results/$teste"

mkdir -p "$OUTDIR"

./latency-csv.sh "$DATADIR/tcp"

./generate-test-results.sh $DATADIR

./plot-test-results.sh "$DATADIR/data" $OUTDIR

./stats.sh "$DATADIR/tcp" $OUTDIR done A estrutura de diretórios criada para conter os arquivos de dados de testes é a seguinte: > cd ~/sinuv > tree ./tests -d -L 2 ./tests ├── Host_local_t10 │ └── latency ├── Host_local_t2 │ └── latency ├── Host_local_t20 │ └── latency ├── results │ ├── Host_local_t10 │ ├── Host_local_t2 │ ├── Host_local_t20 │ ├── Sys_t10 │ ├── Sys_t10_ntp10 │ ├── Sys_t2 │ ├── Sys_t20 │ ├── Sys_t20_ntp10 │ └── Sys_t2_ntp10 ├── Sys_t10 │ └── latency ├── Sys_t10_ntp10 │ └── latency ├── Sys_t2 │ └── latency ├── Sys_t20

242

│ └── latency ├── Sys_t20_ntp10 │ └── latency └── Sys_t2_ntp10 └── latency Cada diretório latency contêm os diretórios data e tcp. 243

APÊNDICE F – Resultados Estudo de Caso

A partir dos resultados gerados pelo script geral: app:~/sinuv/tests $ ./generate-results.sh são obtidos, para cada cenário de teste, gráficos similares aos descritos no APÊNDICE D – Resultados Benchmark OpenDDS. Para o teste distribuído com tempo de simulação de 2 ms, as figuras a seguir mostram os gráficos das latências e jitter dos demais módulos do sistema.

244

245