UNIVERSIDADE ESTADUAL DO OESTE DO PARANÁ UNIOESTE CENTRO DE ENGENHARIAS E CIÊNCIAS EXATAS CAMPUS DE FOZ DO IGUAÇU CURSO DE ENGENHARIA ELÉTRICA

Transcrição

1 UNIVERSIDADE ESTADUAL DO OESTE DO PARANÁ UNIOESTE CENTRO DE ENGENHARIAS E CIÊNCIAS EXATAS CAMPUS DE FOZ DO IGUAÇU CURSO DE ENGENHARIA ELÉTRICA APLICAÇÃO DE TÉCNICAS DE BUSINESS INTELLIGENCE PARA ANÁLISE DE DADOS DE PRODUÇÃO DA USINA HIDRELÉTRICA DE ITAIPU FERNANDO MARCOS WITTMANN FOZ DO IGUAÇU PR 2013

2 FERNANDO MARCOS WITTMANN APLICAÇÃO DE TÉCNICAS DE BUSINESS INTELLIGENCE PARA ANÁLISE DE DADOS DE PRODUÇÃO DA USINA HIDRELÉTRICA DE ITAIPU Relatório de trabalho de conclusão de curso apresentado ao Curso de Engenharia Elétrica da Universidade Estadual do Oeste do Paraná, como parte dos requisitos para obtenção do título de Engenheiro Eletricista. Orientador: Prof. Dr. Marcos Fonseca Mendes Coorientador: M. Eng. Felipe Trevisan FOZ DO IGUAÇU 2013

3 FERNANDO MARCOS WITTMANN APLICAÇÃO DE TÉCNICAS DE BUSINESS INTELLIGENCE PARA ANÁLISE DE DADOS DE PRODUÇÃO DA USINA HIDRELÉTRICA DE ITAIPU Relatório de trabalho de conclusão de curso apresentado ao Curso de Engenharia Elétrica da Universidade Estadual do Oeste do Paraná, aprovado pela comissão julgadora: Foz do Iguaçu, 05 de agosto de 2013.

4 AGRADECIMENTOS Primeiramente à minha família, meus pais Ivo e Salete pelo apoio, exemplo e amor, à Maísa por tomar conta dos meus pais e aos meus irmãos Anderson, que fez sonhar em ser engenheiro desde criança e a Andrea que me ajudou a enfrentar momentos difíceis da faculdade. À Unioeste, aos professores pelo conhecimento compartilhado, em especial ao professor Lotero que me acompanhou desde o segundo ano e ao professor Marcos Mendes pela orientação, dedicação, paciência e planejamento. À Itaipu pelo estágio, à equipe da OP.DT pelo companheirismo, citando especialmente os engenheiros Felipe Trevisan, Paulo Neis e Rafael Deitos que acompanhavam as minhas atividades de perto e foram fundamentais para a produção desse trabalho. Em especial agradeço ao Felipe pelas incontáveis revisões, explicações e acompanhamentos. Agradeço também a todos aqueles que trouxeram contribuições diretas ou indiretas ao trabalho. E por último e não menos importante a todos os meus amigos, de dentro e de fora da faculdade, por compartilhar momentos, alegrias ou dificuldades, em especial aqueles que conviviam comigo no dia-dia fazendo assim parte de uma grande família. Agora cada um segue um rumo e deixarão saudades.

5 To achieve great things, two things are needed: a plan and not quite enough time. Leonard Bernstein

6 RESUMO WITTMANN, F. M. (2013). Aplicação de Técnicas de Business Intelligence para Análise de Dados de Produção da Usina Hidrelétrica de Itaipu. Trabalho de Conclusão de Curso (Graduação) Curso de Engenharia Elétrica, Universidade Estadual do Oeste do Paraná UNIOESTE, Foz do Iguaçu, Nos últimos anos vem-se constatando que o real valor de uma organização está na gestão de suas informações. Informação pode ser definida como dados estruturados de modo a ter significado. Neste contexto, o conceito de Business Intelligence propõe técnicas para transformação de dados em informações e conhecimento como subsídio para tomada de decisão. O objetivo deste trabalho é aplicar técnicas e ferramentas para extração de informações de grandes massas de dados. Como exemplo, são usados os dados históricos de produção da usina de Itaipu. A ferramenta utilizada para esta finalidade é o sistema Plant Information (PI) da Osisoft, que é um pacote que integra ferramentas desde armazenamento até visualização de dados. Essa ferramenta permite que os dados sejam vinculados a um modelo de dados para representação dos componentes da usina. É utilizada a norma Common Information Model (CIM) como base para a criação desse modelo de dados para representação de parte da usina. Este trabalho apresenta a sequência de etapas para transformação de dados em informações juntamente com dois estudos de caso. Palavras-chave: Usinas Hidrelétricas, Business Intelligence, Common Information Model, Plant Information.

7 ABSTRACT WITTMANN, Fernando Marcos (2013), Application of Business Intelligence Techniques for the Analysis of the Production Data of Itaipu Hydroelectric Power Plant. End of Course Paper (Graduation) - Course of Electrical Engineering, Universidade Estadual do Oeste do Paraná - UNIOESTE, Foz do Iguaçu, Over the last few years it is possible to realize that the real value of an organization is its information management. Information may be defined as data structured in a way that has meaning. In this context, the concept of Business Intelligence proposes techniques for transforming data into information and knowledge as an aid for decision making. The objective of this paper is to apply techniques and tools for extracting information from large data sets. As an example, it is used the historical data from Itaipu production. The tool used for this purpose is the system Plant Information (PI) by Osisoft which is a package that integrates tools from storage to data visualization. This tool allows data to be linked to a data model for the representation of the plant components. It is used the standard Common Information Model (CIM) as the basis for creating this data model that represents part of the power plant. This work presents the sequence of steps for transforming data into information along with two case studies. Keywords: Hydroelectric Power Plant, Business Intelligence, Common Information Model, Plant Information

8 LISTA DE ABREVIATURAS E SIGLAS AF Asset Framework BI Business Intelligence CIM Common Information Model EMS Energy Management System ETL Extract, Transform and Load PI Plant Information SQL Structured Query Language SCADA Supervisory Control and Data Acquisition UML Unified Modeling Language

9 SUMÁRIO 1. INTRODUÇÃO Contextualização Descrição do Problema Objetivos Estrutura do trabalho REVISÃO BIBLIOGRÁFICA Modelagem Orientada a Objetos Notação UML Objeto Classe Tipos de relacionamentos Common Information Model (CIM) Norma IEC CIM Profile Sistema PI Sistemas PI na Usina Hidrelétrica de Itaipu PI AF Business Intelligence (BI) Ferramenta PowerPivot Considerações finais METODOLOGIA Modelagem de dados Escopo do modelo Definição de um perfil CIM Acomodação de equipamentos e sistemas no perfil CIM Mapeamento CIM/PI AF Extração de dados Dados do modelo hierárquico (Asset) Dados de históricos de produção Obtenção combinada de dados do modelo e dados históricos Análise de dados Considerações Finais... 28

10 4. RESULTADOS Estudo de Caso I Disponibilidade de Unidades Geradoras Estudo de Caso II Perfil de Operação de Bombas de Drenagem da Turbina Considerações finais CONCLUSÕES Sugestões para trabalhos futuros REFERÊNCIAS APÊNDICE A... 36

11 1 1. INTRODUÇÃO 1.1. Contextualização Nos últimos anos organizações se deparam com uma crescente demanda por informações que seus funcionários necessitam para tomar decisões. Define-se informação como dados transformados e estruturados de forma a possuir significado. Dado por sua vez é qualquer registro ou fato a respeito de um estado na natureza (VALENTIM, 2002). Nesse contexto, as ferramentas e metodologias de Business Intelligence (BI) objetivam a transformação de dados em informação e conhecimento como subsídio para a tomada de decisão (VERCELLIS, 2009). Os dados normalmente existem em grandes quantidades e provêm de variadas fontes. Muitas vezes são inconsistentes e podem ter diferentes definições e nomes, acrescentando considerável complexidade até mesmo para análises simples. Para criar informações úteis e aproveitar plenamente o potencial desses dados as organizações precisam de uma forma consistente, significativa e intuitiva de representar seus dados (OSISOFT, 2012) Descrição do Problema A usina hidrelétrica de Itaipu fornece mais de 17% da energia consumida no Brasil. No Paraguai essa parcela chega a mais de 70% (ITAIPU BINACIONAL, 2013). Portanto, a usina de Itaipu tem um papel fundamental na economia dos dois países. Em Itaipu, desde 2002, utiliza-se um sistema de Supervisão, Controle e Aquisição de Dados (Supervisory Control and Data Aquisition SCADA) e outro de Gerenciamento de Energia (Energy Management System EMS). Os sistemas SCADA fazem a supervisão e controle centralizado de equipamentos primários 1 e supervisionam sistemas secundários 2 (MENDES, 2011). Dentre as funções presentes na arquitetura de um sistema SCADA, destacam-se a aquisição de dados e registro. Aquisição de dados consiste na coleta de variáveis provenientes de várias partes do processo. Registro consiste no armazenamento de histórico de variáveis do processo (REGINATTO, 2007). Na usina de Itaipu, mais de 20 mil variáveis (analógicas ou de estado) são armazenadas em diferentes intervalos de tempo. 1 Relacionado à infraestrutura da usina, desde equipamentos típicos como geradores e transformadores até equipamentos auxiliares como bombas e válvulas. 2 Sistemas de automação, proteção, monitoramento, controle e supervisão constituído de equipamentos como transformadores de corrente (TCs) e controladores lógicos programáveis (CLPs).

12 2 A consulta ao banco de dados históricos da usina nem sempre pode ser feita de forma fácil e rápida. Muitas vezes há um considerável trabalho para a obtenção de uma informação relativamente simples. Os pontos de supervisão e controle adquiridos pelo sistema SCADA são historiados em tags, que é qualquer variável envolvida na aplicação, estruturados em apenas dois níveis hierárquicos. Quando se deseja obter os dados históricos a respeito de um tag, há a necessidade de realização de uma pesquisa direta dentre os mais de 20 mil pontos. Resumidamente, realiza-se uma busca manual do tag, de acordo com o nome que foi atribuído ao mesmo quando houve a instalação do equipamento que faz o monitoramento em campo. Essa busca muitas vezes exige um conhecimento das regras de nomenclatura utilizadas. Ante a necessidade de simplificação ao acesso aos dados do SCADA, estuda-se o uso da ferramenta computacional Plant Information Asset Framework (PI AF). Essa ferramenta permite a definição de uma estrutura que represente os ativos 1 de uma planta (OSISOFT, 2012). A consulta a esta estrutura torna-se mais amigável porque evita a necessidade do usuário conhecer de antemão o nome dos tags. Com a possibilidade de criação desta estrutura, cabe avaliar qual a melhor forma de organizá-la. Questionou-se se existia alguma definição universalmente aceita para a organização dos dados no domínio desta aplicação. Neste contexto, avalia-se a utilização da norma IEC parte 301, também conhecida como Common Information Model (Modelo de Informação Comum - CIM), a qual define um modelo de informação, baseado em diagramas de classe UML (Unified Modeling Language) para representação de componentes empregados em sistemas elétricos de potência (ELECTRIC POWER RESEARCH INSTITUTE, 2011). Sendo assim, este trabalho estuda a aplicação dessa norma para a estruturação dos dados relativos ao processo de operação da usina de Itaipu. Dispondo-se de um modelo que facilite o acesso aos dados da usina, é possível portanto a utilização de ferramentas para a extração de dados do modelo e transformação desses dados em informações. Essa transformação de dados em informações é a principal vantagem desse modelo e está relacionado com o conceito de BI. O trabalho contempla três etapas relacionadas à modelagem de dados e extração de informações. A primeira é a criação de um modelo de dados para representação de parte dos componentes da usina. Este modelo será criado a partir de um estudo da norma CIM e um mapeamento para a ferramenta PI AF. A segunda etapa objetiva a consulta aos dados deste 1 Conjunto de bens e valores de uma organização. 3

13 3 modelo para obtenção dos dados de interesse. A terceira parte trata da análise e visualização dos dados extraídos a partir deste modelo sendo possível dessa forma a visualização de informações que possam ser de interesse para os especialistas da usina Objetivos O objetivo principal deste trabalho é avaliar técnicas e ferramentas que permitam extrair informações de grandes massas de dados de maneira rápida e facilitada. Objetivos específicos: Avaliar ferramentas e técnicas de BI como ferramenta para extração de informações a partir de grandes massas de dados; Avaliar o uso da norma CIM como base para a criação de um modelo de dados para representação dos principais componentes da usina; Realizar casos de uso para extração de informações utilizando técnicas de modelagem de dados e BI visando validar os conceitos estudados Estrutura do trabalho Este trabalho está dividido em cinco capítulos: introdução, revisão bibliográfica, metodologia, resultados e conclusões. A revisão bibliográfica apresenta conceitos e ferramentas computacionais utilizadas no trabalho. O capítulo 3, metodologia, exibe as etapas para o desenvolvimento do trabalho. O capítulo 4 apresenta resultados práticos obtidos em dois estudos de casos utilizando a modelagem desenvolvida. Por fim, o capítulo 5 apresenta as conclusões acerca dos resultados obtidos no trabalho.

14 4 2. REVISÃO BIBLIOGRÁFICA O presente capítulo apresenta os principais conceitos e ferramentas computacionais envolvidas no desenvolvimento do trabalho. Primeiramente são vistos conceitos relacionados à modelagem orientada a objetos. Em seguida é apresentada a norma Common Information Model (CIM), a qual define um modelo para representação de componentes de sistemas de potência e é utilizada como base para a modelagem desenvolvida no trabalho. A terceira subseção apresenta o sistema Plant Information (PI) e a ferramenta Asset Framework (AF), componente integrante desse sistema, usado para o armazenamento de dados históricos de produção e criação de um modelo de informação para o gerenciamento de ativos. A quarta subseção aborda o conceito de Business Intelligence (BI) e introduz a ferramenta computacional Microsoft PowerPivot utilizada para este fim Modelagem Orientada a Objetos Os conceitos de modelagem orientada a objetos são necessários para o entendimento da norma CIM. Será apresentada brevemente a notação UML (Unified Modeling Language), utilizada para representação gráfica de projetos orientados a objetos além dos conceitos de objetos, classes, herança, associação, agregação e composição Notação UML A notação UML é uma linguagem para a representação gráfica de componentes de software e suas inter-relações. Aspectos estruturais, comportamentais e de interação podem ser descritos por diversos tipos de diagramas. Um dos principais diagramas da notação UML é o diagrama de classes, a partir do qual é possível representar a modelagem estática dos dados de uma aplicação (ELECTRIC POWER RESEARCH INSTITUTE, 2011) Objeto Os objetos são conceitualmente constituídos de estados e comportamentos. Os estados podem ser armazenados em atributos e expor seu comportamento através de métodos. Os métodos servem como um mecanismo de interação entre múltiplos objetos (HOFFER, 2010).

15 Classe Uma classe define a estrutura a partir da qual um objeto, ou um conjunto deles, pode ser criado (HOFFER, 2010). Em termos de orientação a objeto, pode-se dizer que um objeto é uma instância de uma determinada classe. Por exemplo, uma classe Círculo pode ser representada através da seguinte notação UML: -x -y -raio Circulo +mudarraio() +mudarposicao() Figura 1 Exemplo de classe em notação UML. FONTE: ELECTRIC POWER RESEARCH INSTITUTE, Na Figura 1, tem-se os atributos x, y, raio e os métodos mudarraio() e mudarposicao(). O sinal + em frente a atributos e métodos significa que o mesmo é do tipo público, ou seja, pode ser visto e acessado por outras classes. Já o sinal de - indica que o atributo, ou método, não pode ser visto nem acessado por outras classes Tipos de relacionamentos A programação orientada a objetos permite que as classes tenham diferentes tipos de relações entre si, que podem ser definidas de acordo com o nível de força de relação. Esta força de relação pode ser classificada em relação a mais fraca até a mais forte, sendo elas: Associação (mais fraca), Agregação, Composição e Herança (mais forte) Associação Associação é um tipo de relacionamento no qual o objeto de uma classe contém uma referência a um ou mais objetos de outra classe. Utiliza-se a relação associação quando se diz que uma classe trabalha com um objeto de outra classe. Em diagramas UML, a representação pode ser feita através de uma linha contínua, conforme a Figura 2.

16 6 Figura 2 Exemplo de Associação (diagrama de classes UML) FONTE: ELECTRIC POWER RESEARCH INSTITUTE, No início da linha que liga as classes, tem-se a multiplicidade ou cardinalidade, que indica o número de associações que uma classe faz em relação à outra. Na Figura 2 tem-se que a classe forma tem multiplicidade 0..* enquanto que a classe estilo possui multiplicidade 1. Isto significa que cada objeto de Estilo pode ser associado com 0 ou mais objetos da classe Forma, enquanto cada Forma, será associada a um único Estilo Agregação Agregação é um tipo de associação com uma relação mais estreita, utilizada para indicar que uma classe possui objetos de outras classes. Esses objetos podem ser compartilhados com outras classes. Sua representação é feita através de um diamante vazio, conforme a Figura 3. Figura 3 Exemplo de agregação (diagrama de classes UML) FONTE: ELECTRIC POWER RESEARCH INSTITUTE, No exemplo da Figura 3, pode-se dizer que uma camada pode ter 0 ou um número qualquer de formas. Por outro lado, verifica-se que a multiplicidade da classe camada é 0..1, ou seja, cada forma pode ser possuída por uma ou nenhuma camada. Este tipo de relação não cria uma dependência direta entre as classes, ou seja, se um objeto da classe Camada for destruído, nenhum objeto da classe Forma será destruído.

17 Composição Composição constitui uma relação mais forte ainda do que agregação, e significa que determinados objetos de classes são partes de outros objetos de classes. A representação pode ser feita através de um diamante cheio, conforme a Figura 4. Figura 4 Exemplo de composição em notação UML FONTE: ELECTRIC POWER RESEARCH INSTITUTE, No exemplo da Figura 4 tem-se que uma forma pode conter nenhuma ou mais âncoras. Esse tipo de relação cria uma dependência direta entre as classes, ou seja, tem-se que os objetos da classe Âncora são partes dos objetos da classe Forma. Se um objeto da classe Forma for destruído, os objetos da classe Âncora, que fazem parte do mesmo, também serão destruídos Herança Herança ou generalização é o tipo mais forte de relação entre classes e é utilizada para descrever a relação na qual uma classe é um tipo de outra classe. Nesse tipo de relação, ocorre a herança de atributos da classe superior. Sua representação é feita através de um triângulo, que indica a partir de que classe os atributos serão herdados. Na Figura 5, por exemplo, tem-se que as três classes: Círculo, Retângulo e Triângulo, são tipos da classe Forma. Essas três classes, portanto, herdarão os atributos x, y e o método mudarposição(), que fazem parte da classe superior, Forma, definida como superclasse.

18 8 Figura 5 Exemplo de herança em notação UML. FONTE: ELECTRIC POWER RESEARCH INSTITUTE, Common Information Model (CIM) O Common Information Model (CIM) é um modelo de informação 1 para a representação de componentes empregados em sistemas elétricos de potência. Esse modelo de informação é baseado em diagramas de classe UML e já é adotado como padrão para troca de informação entre várias empresas e órgãos reguladores do setor elétrico, especialmente na Europa e EUA (ELECTRIC POWER RESEARCH INSTITUTE, 2011). O CIM é constituído por um conjunto de três partes de normas, sendo a norma IEC a principal, utilizada para representação dos componentes elétricos, e as partes das normas IEC e IEC extensões da anterior, utilizadas para comunicação entre agentes do setor elétrico. A norma IEC parte 301 é apresentada com mais detalhes na subseção seguinte Norma IEC A norma IEC parte 301 permite a integração em todos os domínios nos quais é necessário um modelo de sistema de potência em comum para facilitar a interoperabilidade e 1 Modelos de informação compreendem conceitos, relações, restrições, regras e operações para especificar dados semânticos em um determinado domínio (LEE, 1999). 2 Energy management system application program interface (EMS-API) Part 301: Common Information Model (CIM) Base 3 Application integration at electric utilities System interfaces for distribution management Part 11: Common Information Model (CIM) 4 Framework for energy market communications Part 301: Common Information Model (CIM) Extensions for Markets

19 9 a compatibilidade de conexões entre aplicações e sistemas de maneira independente (INTERNATIONAL ELECTROTECHNICAL COMMISSION, 2009). A norma é constituída por pacotes de classes, dentre os quais, se citam: CORE: utilizado para identificação e representação dos elementos organizacionais como área e subárea geográfica, subestações, vãos, níveis de tensão; WIRES: contém elementos de conexão entre equipamentos de sistemas de potência tais como transformadores, linhas de transmissão e chaves; GENERATION: é dividido em dois subpacotes, Production e GenerationDynamics utilizados para modelagem de unidades geradoras e seus componentes, tais como, motores e turbinas; MEASUREMENT: pacote utilizado para relacionar medições às classes que modelam componentes do sistema de potência; PROTECTION: pacote para modelagem de componentes de proteção, como disjuntores e seccionadores; CIM Profile Um Profile do CIM trata-se de um subconjunto do CIM que inclui somente as classes, atributos e associações essenciais para um domínio de aplicação específico. Pode-se também adicionar restrições, quanto à multiplicidade, por exemplo. Em resumo, os profiles do CIM limitam o escopo do CIM, permitindo apenas a utilização de elementos selecionados (como classes) e suas inter-relações pré-definidas (USLAR et al., 2012) Sistema PI O sistema PI (do inglês Plant Information) é um sistema desenvolvido pela OSISoft, que integra ferramentas armazenamento de dados históricos, busca, análise e visualização de dados. O sistema pode ser integrado a diversos sistemas de supervisão e controle e utiliza algoritmos de compressão para armazenamento de grandes massas de dados de produção Sistemas PI na Usina Hidrelétrica de Itaipu A usina de Itaipu possui dois sistemas PI em produção:

20 10 PI do SCADA (Historian), fornecido junto com o sistema SCADA/EMS para armazenamento dos dados históricos de produção e disponível apenas na rede SCADA (isolada); PI do SIRI (Sistema Integrado de Redes Industriais), que tem uma ligação com o PI do SCADA via Interface PI-to-PI e mantém uma réplica dos dados de produção. O SIRI, apesar de também ser isolado da rede corporativa, pode ser acessível por máquinas da rede corporativa via conexões VPN. A Figura 6 ilustra a interligação entre esses dois sistemas Scada network SIRI Corporative Network Scada/EMS Scada/EMS Historian (PI System) Interface PI-to-PI SIRI Data Server (PI System) VPN Gateway Figura 6 Redes relacionadas aos sistemas PI da usina. Corporative Station Corporative Station PI AF O PI AF (Plant Information Asset Framework) permite a definição de uma representação consistente de ativos organizacionais e/ou equipamentos e utiliza estas representações em análises simples ou complexas que produzem informações críticas e acionáveis. Uma de suas vantagens é que permite a compressão de dados através da atribuição de contexto, fazendo assim os dados centralizados, significativos e relevantes para usuários. Para se trabalhar com o PI AF, utiliza-se duas ferramentas computacionais, uma para construção de um modelo e outro para fazer consultas ao modelo: PI System Explorer e o PI SQL Commander: PI System Explorer Ferramenta que fornece uma interface gráfica para criação, edição e manutenção de objetos do PI AF. A Figura 7 mostra um exemplo de hierarquia de elementos do PI AF criada no PI System Explorer.

21 11 Figura 7 Exemplo de hierarquia de elementos PI SQL Commander PI SQL 5 Commander é uma ferramenta utilizada para visualizar, criar e executar consultas em SQL no AF. Com essa ferramenta pode-se realizar consultas à estrutura de elementos criados pelo PI System Explorer. Essa ferramenta pode ser utilizada para realizar o cruzamento entre duas bases de dados: PI Archive, que mantém os dados históricos do SCADA e os metadados que contemplam o modelo de informação do PI AF. A Figura 8 exemplifica o cruzamento realizado entre as duas bases de dados. Figura 8 - Cruzamento de informações entre as duas bases de dados 2.4. Business Intelligence (BI) Define-se Business Intelligence (BI) como um conjunto de modelos matemáticos e metodologias de análise que exploram os dados disponíveis para a recuperação de informações e conhecimento úteis no apoio à tomada de decisão (VERCELLIS, 2009). 5 Structured Query Language (SQL) ou Linguagem de Consulta Estruturada é uma linguagem de programação projetada para a realização de consultas e atualizações de tabelas de informação (IBM, 2013).

22 12 Os termos dado, informação e conhecimento, utilizados no conceito de BI, podem ser confundidos entre si, mas existem características peculiares de cada um dos três termos, apresentado a seguir (VALENTIM, 2002): Dado: conjunto de registros conhecidos (qualitativos ou quantitativos) que, quando organizados, agrupados, categorizados e padronizados adequadamente, podem ser transformados em informação; Informação: dados organizados de modo que possuam significado; Conhecimento: conjunto de informações que caracteriza o saber disponível ou o acúmulo de saber prático sobre determinado assunto. A Figura 9 apresenta a arquitetura de um sistema de BI (VERCELLIS, 2009). Figura 9 Principais componentes de um sistema de BI. As partes dessa arquitetura são apresentadas a seguir (VERCELLIS, 2009): 1. Fonte de Dados: numa primeira fase, é necessário recolher e integrar os dados armazenados em várias fontes primárias e secundárias. A maior parte das fontes de dados consistem de dados pertencentes a sistemas operacionais, mas pode também incluir documentos e dados externos; 2. Data Warehouse e Data Marts: usando ferramentas de extração e transformação conhecidas como extração, transformação e carga (mais popularmente conhecido como ETL Extract, Transform, Load), os dados provenientes das diferentes fontes são armazenados em bancos de dados destinados a apoiar as análises de BI; 3. Data Exploring: ferramentas para realização de análise passiva de BI, que consiste em consultas e sistemas de informação. Refere-se à metodologias

23 13 pelas quais os responsáveis por tomar decisões geram hipóteses prévias e definem critérios para extração de dados. Em seguida, usam ferramentas de análise para encontrar respostas e confirmar a sua intuição originária; 4. Data Mining: metodologias ativas de BI cujo propósito é a extração de informação e conhecimento de dados. Incluem modelos matemáticos para reconhecimento de padrões, aprendizagem de máquina e técnicas de mineração de dados; 5. Otimização: modelos de otimização permitem a determinação da melhor solução entre um conjunto de alternativas de ações, o qual pode ser bastante extenso; 6. Decisão: adoção e escolha real de uma decisão específica que, de alguma forma, representa a conclusão natural do processo de tomada de decisão. Este trabalho utiliza as três primeiras etapas dessa estrutura. Como fonte de dados, utiliza-se o Sistema Integrado de Redes Industriais (SIRI) que mantém uma réplica dos dados históricos de produção do SCADA. Já a segunda parte, Data Warehouse, é atendida através da infra-estrutura do sistema PI AF. Por fim, as análises passivas de BI são realizadas utilizando-se a ferramenta PowerPivot por meio de tabelas dinâmicas Ferramenta PowerPivot O PowerPivot é um complemento gratuito do MS Excel voltado para uso em BI. Essa ferramenta permite a transformação de grandes quantidades de dados em informações e acrescenta ferramentas para análise de dados baseadas em tabelas dinâmicas. Dentre seus principais recursos, tem-se (MICROSOFT, 2010): importação de milhões de linhas de várias fontes de dados: pode-se importar milhões de linhas de dados de várias fontes de dados para uma única pasta de trabalho do Excel, criar relações entre dados heterogêneos, criar colunas e medidas calculadas usando fórmulas, criar tabelas e gráficos dinâmicos, e analisar os dados para poder tomar decisões em negócios; rapidez em cálculos e análises: processamento de milhões de linhas praticamente no mesmo tempo necessário para processar milhares, e extrair o máximo de processadores com vários núcleos e dos gigabytes de memória para realização de processamentos mais velozes nos cálculos;

24 14 suporte praticamente ilimitado a fontes de dados: fornece uma base para importar e combinar fontes de dados de qualquer local para fins de análise de dados massivos na área de trabalho, incluindo bancos de dados relacionais, fontes multidimensionais, serviços de nuvem, arquivos do Excel, arquivos de texto e dados da Web; DAX (Data Analysis Expressions): linguagem de fórmula, que amplia os recursos de manipulação de dados do Excel para permitir mais sofisticação e complexidade em agrupamentos, cálculos e análises. A Figura 10 apresenta, à esquerda, a tela do PowerPivot com dados extraídos e à direita, um exemplo de representação dos dados em forma de tabelas dinâmicas, para visualização de informações, utilizando o Excel. Figura 10 Exemplo de utilização da ferramenta PowerPivot 2.5. Considerações finais Neste capítulo foram apresentados os conceitos de orientação a objetos, modelo de informação, uma pequena introdução ao CIM e BI. Também foram vistas as principais ferramentas computacionais que serão utilizadas no trabalho.

25 15 3. METODOLOGIA Este capítulo mostra a metodologia utilizada no trabalho. O processo resume-se a três etapas globais: modelagem, extração e análise de dados. A primeira etapa trata da criação de um modelo que represente e descreva os componentes de parte da usina. A segunda trata da extração e transformação de dados de interesse disponíveis no modelo. A terceira etapa trata da carga, análise e visualização desses dados estruturados na segunda parte. O diagrama apresentado na Figura 11 resume essas três etapas com alguns detalhes que serão vistos nas próximas subseções. 1 - MODELAGEM Definição de escopo; Perfil CIM; Mapeamento para o PI AF. 2 - EXTRAÇÃO Consulta ao modelo utilizando SQL; Cruzamento de dados históricos com o modelo. 3 - ANÁLISE Visualização e análise de informações; Criação de gráficos, tabelas e segmentações. Figura 11 Principais tópicos deste capítulo Modelagem de dados Esta parte mostra a metodologia para criação de um modelo de dados. Um modelo de dados permite um acesso facilitado aos dados, pois não necessita do conhecimento de nomenclaturas de tags, ao invés disso, navega-se em uma estrutura hierárquica. De forma resumida, as etapas para criação desse modelo são: criação de um escopo (limitação do que se deseja modelar); criação de um perfil CIM (adequação do escopo com a norma CIM) e mapeamento para o sistema PI (implementação do modelo em uma ferramenta computacional) Escopo do modelo O escopo é definido a partir do conhecimento das necessidades de informações de especialistas da usina. A seguir foram levantadas algumas perguntas a serem respondidas com o auxílio do modelo de dados considerando um determinado período de tempo: por quanto tempo as unidades geradoras permaneceram disponíveis/indisponíveis?

26 16 por quanto tempo a usina operou com diferentes números de unidades sincronizadas? quais bombas de drenagem têm mais manobras (ligado/desligado)? quais as bombas de drenagem permanecem ligadas durante mais tempo? qual o tempo médio entre partidas/paradas das bombas de drenagem? Com o objetivo de responder a essas perguntas, define-se o escopo do trabalho para a modelagem. Para esse trabalho, o escopo da modelagem é composto pelos seguintes equipamentos: as unidades geradoras e as bombas de drenagem do sistema de tampa da turbina. A Tabela 1 apresenta os equipamentos do escopo juntamente com os dados (tags) disponíveis a partir do sistema SCADA que possibilitam responder às perguntas. Tabela 1: Equipamentos do escopo e dados usados na modelagem. Componente Dado usado na Nome do tag no SCADA* modelagem Unidade Geradora Estado (Sincronizada/Em Vazio Parada/Em Manutenção) U01.ESTADO.SV Bombas de Drenagem Estado (Ligado/Desligado) U01.TURBINA BOMBA 1 DRENAJE.SV * Exemplos de tag para um equipamento específico. A nomenclatura do tag pode apresentar variações inclusive do idioma (Português/Espanhol) Definição de um perfil CIM O trabalho de modelagem também busca formas de organizar os componentes da usina dentro de uma estrutura hierárquica. Neste contexto utiliza-se a norma CIM. A partir de um estudo da norma CIM pode-se criar um perfil CIM que é um subconjunto da norma contendo apenas os componentes de interesse. Esse perfil servirá de modelo para criação da estrutura hierárquica na ferramenta PI AF. A Figura 12 apresenta as principais etapas do desenvolvimento de um perfil CIM (USLAR et al., 2012). Em resumo, primeiramente definem-se pacotes, classes e atributos relevantes. Em seguida, especificam-se restrições como cardinalidades para associações, bem como atributos obrigatórios e opcionais. Por fim, se necessário, adicionam-se classes e atributos personalizados.

27 17 Subconjunto da CIM Subconjunto melhorado da CIM Perfil da CIM Identificar os pacotes relevantes; Identificar as classes, atributos e associações importantes. Especificar restrições (como cardinalidade, elementos mandatórios e opcionais); Adicionar novas classes e atributos personalizados. Testar o perfil; Publicar o perfil. Figura 12 Passos para a criação de um perfil CIM FONTE: USLAR, et al., 2012 Para o primeiro passo, identificação dos pacotes relevantes, estudou-se a norma CIM. O estudo consiste em examinar os diagramas de classe UML da norma e as relações entre classes (agregação, herança, etc.). Cada classe tem uma descrição que explica a função da classe e como ela deve ser utilizada. No modelo completo da CIM, todas as classes são opcionais, cabendo ao profissional responsável pela definição do perfil CIM a seleção das classes mais relevantes ao escopo do projeto. A título de exemplo, a Figura 13 apresenta as classes mais relevantes do diagrama de classes Main do pacote Core da norma, o qual contém classes utilizadas para identificação e estruturação dos componentes. Dentre as classes apresentadas na Figura 13, destacam-se as seguintes: IdentifiedObject: classe genérica para identificação de outras classes; PowerSystemResource: qualquer componente relacionado ao sistema elétrico de potência (equipamentos e entidades organizacionais); Equipment: uma parte se um sistema que potência que pode ser um dispositivo físico, eletrônico ou mecânico; GeographicalRegion e SubGeographicalRegion: classes usadas para organização de regiões e sub-regiões geográficas.

28 18 Figura 13 Classes relevantes do pacote Core, utilizadas para identificação e organização do modelo. Em continuidade, realiza-se a seleção de atributos e relações entre classes. A Figura 14, por exemplo, apresenta apenas as classes e atributos relevantes do pacote Hydro. Para esse pacote, utiliza-se apenas a classe HydroGenerationUnit que segundo definição da norma representa uma unidade geradora na qual o motor primário é uma turbina hidráulica.

29 19 class HydroGeneratingUnit Production:: HydroGeneratingUnit + Discrete: state + IdentifiedObject: mrid Figura 14 Classe HydroGeneratingUnit e atributos mais relevantes (pacote Hydro). Vale ressaltar que a norma CIM é mais completa quando se trata da representação de aspectos sistêmicos de equipamentos de sistemas de potência. Verifica-se que a norma não prevê a modelagem de componentes auxiliares, como bombas e válvulas. Para esses casos, no entanto, a norma permite que seja realizada uma extensão do modelo de dados original. A extensão do modelo de dados permite acrescentar componentes não contemplados pela norma. Diversos trabalhos de extensão de modelo CIM vêm sendo realizados nos grupos de trabalho da IEC, dentre os quais se pode destacar o trabalho de harmonização (ELECTRIC POWER RESEARCH INSTITUTE, 2010) da norma CIM com a norma IEC , que trata da padronização da modelagem e comunicação entre equipamentos de proteção e automação (MENDES, 2011). Para este trabalho, realiza-se uma extensão da norma CIM para a representação da tampa da turbina e das bombas de drenagem das unidades geradoras. Através da seleção das classes relevantes da norma CIM e criação de extensões do modelo com base no escopo inicial, foi criado um perfil da norma CIM apresentado na Figura 15. As partes em contorno vermelho são extensões do modelo de dados original. 6 Communication Networks and Systems for Power Utility Automation.

30 20 class ITAIPU GeographicalRegion SubGeographicalRegion Substation 0..1 VoltageLev el * 0..* 0..* 1 0..* Pump + Discrete: state + flow TurbineCov er HydroTurbine 1..* Production::HydroGeneratingUnit + Discrete: state + IdentifiedObject: mrid Figura 15 Perfil da CIM utilizado no trabalho Acomodação de equipamentos e sistemas no perfil CIM Após a criação do perfil, é necessário acomodar os equipamentos e sistemas associados ao processo nas classes definidas pelo perfil. A Tabela 2 apresenta as classes do perfil CIM com seus respectivos equipamentos ou sistemas associados. Tabela 2: Acomodação de equipamentos/sistemas nas classes do perfil CIM. Classes do perfil CIM GeographicalRegion SubgeographicalRegion Substation VoltageLevel HydroGeneratingUnit HydroTurbine Equipamentos/sistemas UHI (elemento raiz) Setor50Hz Setor60Hz SF6 50 SF kV U01, U02,... U08, U09, U9A, U10, U12, U17, U18, U18A. Turbina TurbineCover Tampa Pump Bomba 1, Bomba 2, Bomba 3 A Tabela 2 também serve como base para criação da estrutura hierárquica.

31 Mapeamento CIM/PI AF Uma vez definido o perfil CIM, inicia-se a etapa de realização do perfil na plataforma PI AF para que possa ser utilizado por outros programas. Sendo assim, é necessário um mapeamento dos componentes da norma CIM para a forma de representação na ferramenta PI AF. A Tabela 3 apresenta o mapeamento de classes da norma CIM para elementos do PI AF. Tabela 3: Mapeamento entre elementos do CIM e do PI AF. CIM PI AF Classes Objetos Atributos Templates Elements Atributes/PI Point/PI Formula O processo de mapeamento para o PI AF contempla a criação de Templates com os mesmos nomes de classes contidas no perfil da CIM. Para cada Template devem ser criados os atributos identificados nas classes do perfil CIM. geradora. A título de exemplo, a Figura 16 apresenta o Template correspondente à unidade Figura 16 Template da unidade geradora. Após a criação dos Templates, inicia-se a construção de um modelo hierárquico para a organização dos componentes. A hierarquia é definida a partir das relações entre as classes do perfil CIM. Esse modelo hierárquico é construído a partir da criação de elementos do PI AF.

32 22 Durante o processo de instanciação dos elementos do PI AF, devem ser definidos os atributos dos objetos. Os atributos podem ser valores constantes (dados de placa ou características operativas de equipamentos) bem como dados de tempo real obtidos de tags PI (valores ou cálculos). A Figura 17 apresenta a estrutura de elementos construídos para representar parte da usina de Itaipu no contexto do trabalho. À esquerda está a estrutura hierárquica enquanto que à direita estão os atributos da unidade geradora 1. Figura 17 Estrutura hierárquica construída no âmbito do trabalho. Utilizando o caso ilustrado na Figura 17, o estado da unidade geradora U01, armazenado no tag PI U01. ESTADO AV pode ser identificado de maneira estruturada no AF pelo seguinte caminho: UHI.Setor50Hz.SF650.18kV.U01.state.

33 Extração de dados Na seção anterior foi estudada a criação de um modelo para representação dos dados. Esta seção estuda o acesso e estruturação dos dados provenientes deste modelo. Utiliza-se ferramentas ETL 7 para esta finalidade. O PI contém dois principais esquemas 8 de banco de dados, quais sejam: Asset e Data. O esquema Asset mantém os metadados 9 que descrevem o modelo, como a estrutura hierárquica, os Templates e elementos. Já o esquema Data contém os dados históricos do SCADA em uma base temporal. Relações entre tabelas desses dois esquemas permitem o cruzamento de dados temporais com a estrutura do modelo. A Figura 18 apresenta o diagrama de entidade relacional com as principais tabelas desses dois esquemas e as relações entre elas. A tabela Archive mantém basicamente uma lista com identificadores de tags PI, timestamps e valores, ou seja, trata-se dos dados brutos historiados pelo sistema PI. As tabelas ElementTemplate, Element, ElementHierarchy e ElementAttribute, por sua vez, são responsáveis por armazenar a estrutura do modelo de dados definido no AF. Nota-se que a associação entre os dados de produção e o modelo de dados se dá pela relação entre o campo ElementAttributeID da tabela Archive (esquema Data) e o campo ID da tabela ElementAttribute (esquema Asset). 7 Extração, Transformação e Carga (em Inglês: Extraction, Transformation and Loading - ETL) referem-se a ferramentas de software para coleta de dados de diferentes fontes, transformação dos dados de acordo com as regras e necessidades e carga dos dados em uma base de dados de destino (USLAR, 2012). 8 Coleção de objetos de um banco de dados que estão disponíveis para um determinando usuário ou grupo (ORACLE, 2013). 9 Metadados são dados utilizados para descrição de outros dados (BARGMEYER, et al., 2012)

34 24 Figura 18 Diagrama de entidade relacional que mostra como os dados do PI AF são organizados Dados do modelo hierárquico (Asset) O primeiro esquema, Asset, contém um conjunto de tabelas com dados a respeito do modelo. A seguir, tem-se algumas das principais tabelas. Element: contém a lista de elementos criadas no PI AF, ou seja, os componentes (UGs, Bombas, Setores); ElementHierarchy: contém a hierarquia de elementos criadas no PI AF para representação dos componentes; ElementTemplate: contém os templates, ou seja, as classes do perfil CIM (HydroGeneratingUnit, Pump, SubGeographicalRegion); ElementAtribute: contém os nomes dos atributos dos elementos, ou seja, uma lista com os tags vinculados com os elementos (state, mrid).

35 25 A Figura 19 contém a lista de tabelas da base de dados Asset acessada pela ferramenta PI SQL Commander e em detalhes as colunas presentes na tabela ElementHierarchy. Figura 19 Conteúdo da tabela ElementHierarchy. A Figura 20 apresenta a título de exemplo parte do conteúdo da tabela ElementHierarchy no destaque em vermelho. A parte de cima mostra o código SQL utilizado para acesso a essa tabela. Figura 20 Parte do conteúdo da tabela ElementHierarchy Dados de históricos de produção A tabela Archive contém os dados replicados do SCADA. A Figura 21 apresenta as colunas da tabela Archive. Abaixo da tabela Archive há uma lista dos campos desta tabela. Destaque para as colunas ElementAttributeID, Time e Value. A coluna ElementAttributeID contém uma identificação que pode ser utilizada para relacionar esta tabela com outras

36 26 tabelas. Os campos Time e Value contém a estampa de tempo e os valores dos dados replicados. Figura 21 Colunas da tabela Archive Obtenção combinada de dados do modelo e dados históricos Através do atributo de identificação, realiza-se o cruzamento entre os dois esquemas de dados. A Figura 22 apresenta um exemplo de consulta SQL que relaciona os dois esquemas de dados para obtenção de uma tabela com dados a respeito de um componente. A sintaxe completa está disponível no Anexo A com a utilização dos dois esquemas. Figura 22 Relação entre as duas bases de dados.

37 Análise de dados Esta subseção trata da análise e visualização de dados provenientes da extração feita na subseção anterior utilizado a ferramenta MS Excel em conjunto o suplemento PowerPivot. As tabelas criadas no PI SQL Commander podem ser importadas pelo PowerPivot, que por sua vez, funciona como base de dados para a criação de telas de análise no MS Excel. Essas telas permitem a criação de tabelas e gráficos, assim como permitem a segmentação dos dados. A Figura 23 apresenta um exemplo de tabela importada a partir do PI SQL Commander para o PowerPivot. Figura 23 Exemplo de tabela importada para o PowerPivot. Os campos Bomba, Estado, UG, Setor e Dia podem ser usados para a segmentação dos dados, ou seja, permitem que os resultados obtidos a partir dessa tabela sejam filtrados pelo usuário. A Figura 24 apresenta uma tela para visualização e análise de dados criada no MS Excel. À direita está a lista de campos para construção dos gráficos, tabelas e segmentação. Figura 24 Tela criada para visualização de dados.

38 Considerações Finais Neste capítulo foram vistas as três etapas empregadas para transformação de dados em informações. A primeira tratou da criação de um modelo no qual permite o acesso aos dados através de uma estrutura hierárquica. A segunda tratou de como é feito o acesso aos dados deste modelo, e como estruturá-lo para criação de tabelas. A terceira parte tratou do acesso às tabelas criadas na segunda parte, análise e visualização dos dados. A Figura 25 reforça o processo detalhado anteriormente. Figura 25 Resumo das etapas abordadas na metodologia para modelagem, extração e visualização dos dados.

39 29 4. RESULTADOS Com o objetivo de avaliar o potencial das ferramentas utilizadas nesse trabalho, a seguir serão apresentados dois estudos de caso realizados em Itaipu. O primeiro avalia a disponibilidade das unidades geradoras enquanto o segundo avalia a operação das bombas do sistema de drenagem das unidades geradoras Estudo de Caso I Disponibilidade de Unidades Geradoras Do ponto de vista de operação, uma unidade geradora (UG) pode estar em um dos quatro estados, quais sejam: sincronizada, em vazio, parada ou em manutenção. O estado em manutenção caracteriza que a unidade está indisponível para uso, ou seja, está impedida de ser sincronizada de imediato. Já os outros três estados ( sincronizada, em vazio e parada ) caracterizam que a UG está disponível para uso. As unidades no estado sincronizada estão conectadas ao sistema elétrico, sendo este estado caracterizado como em funcionamento. As unidades que estão em vazio ou paradas não estão conectadas ao sistema, mas estão disponíveis para conexão imediata, sendo esses dois estados caracterizados como em Reserva (TUFAILE, et al., 2011). A Figura 26 resume esta relação de nomenclaturas. Conectada ao sistema. Desconectada, mas disponível para conexão imediata ao sistema. Indisponível para conexão imediata ao sistema. FUNCIONAMENTO Síncronizada RESERVA Parado ou em Vazio MANUTENÇÃO Manutenção DISPONÍVEL INDISPONÍVEL Figura 26 Nomenclatura utilizada para representação dos possíveis estados de uma unidade geradora. Este estudo objetiva responder às seguintes questões: Percentual do tempo em que a usina operou com 1, 2 ou n máquinas indisponíveis em cada setor (50Hz e 60Hz). Percentual do tempo em que a usina operou com 1, 2 ou n unidades em reserva em cada setor (50Hz e 60Hz).

40 30 A primeira questão reflete o tempo e o número de unidades de Itaipu que deixaram de ser utilizadas por estarem em manutenção. A Figura 27 apresenta o gráfico criado para a visualização desta informação. Um exemplo de informação que se pode obter a partir de uma análise deste gráfico é que ao longo dos meses de janeiro a junho de 2013, o setor de 60Hz de Itaipu operou durante 76% do tempo com todas as suas unidades disponíveis. As opções de segmentação do lado esquerdo permitem a visualização de informações por setor, mês e dia. Figura 27 Tela para visualização do número de UGs indisponíveis de Itaipu. Vale ressaltar que as ferramentas utilizadas reduzem o esforço para a consulta dessa informação. Resumidamente, os passos seguidos para a obtenção desses resultados foram: criação do modelo no PI AF, consulta ao modelo e criação de tabelas no PI SQL Commander e criação de tabelas e gráficos dinâmicos para a visualização e análise de dados através do PowerPivot + Excel. Não houve a necessidade de conhecimento da nomenclaturas de tags do SCADA, uma vez que esses tags são representados no modelo. A segunda questão avalia o tempo e o número de unidades que permaneceram em reserva, ou seja, as unidades que estavam disponíveis para uso, mas que não estavam conectadas à rede. A Figura 28 apresenta uma tabela e um gráfico dinâmico para a visualização das unidades em reserva em Itaipu.

41 31 Figura 28 Gráfico para visualização das UGs de Itaipu em reserva. Um exemplo de informação obtida a partir da análise desse gráfico revela que entre janeiro e junho de 2013, durante 81% do tempo, nenhuma unidade esteve em reserva no setor de 50Hz. Isso significa que ao longo desse período, todas as unidades que estavam disponíveis, estavam conectadas ao sistema Estudo de Caso II Perfil de Operação de Bombas de Drenagem da Turbina A usina possui um sistema de drenagem junto às tampas das turbinas das unidades geradoras. Este sistema é um componente crítico. O não funcionamento desse sistema implica em parada automática da unidade geradora. A Figura 29 mostra a seção da turbina e em destaque vermelho a região da tampa da turbina onde fica o sistema de drenagem. Figura 29 Seção da turbina com destaque na tampa. FONTE: ITAIPU, 2001.

42 32 Cada unidade geradora possui três bombas, uma pequena com vazão de 400 m³/h e duas grandes com vazão de 2600 m³/h, totalizando-se assim 60 bombas. A área de operação da usina tem interesse em conhecer o perfil de funcionamento destas bombas com o objetivo de identificar preventivamente eventuais problemas nesses equipamentos. O estado de funcionamento dessas bombas é supervisionado pelo sistema SCADA e historiados em tags do PI. Utilizando-se estes tags, se tem no PI AF um modelo que representa o sistema de drenagem da tampa de cada unidade geradora. A Figura 30 apresenta uma tabela e um gráfico criado para representar o perfil de operação das bombas de drenagem. Figura 30 Tela para apresentação de informações do perfil de operação das bombas de drenagem. A partir da tabela e do gráfico criados é possível obter informações relevantes no que diz respeito ao perfil de operação das bombas de drenagem, quais sejam: tempo em que as bombas permaneceram ligadas, número de trocas de estados das bombas (ligado/desligado) e, tempo médio entre mudanças de estado. Analisando-se os resultados obtidos verificou-se, por exemplo, que a bomba 3 da unidade 04 permaneceu 93% do tempo ligado ao longo do mês de junho. Constatou-se ainda que a bomba 3 da unidade 01 ligou mais de 5 mil vezes ao longo do mês, apresentando um tempo médio de 4 minutos entre partidas. Essa informação indica que pode haver um número