ienergy - Eficiência Energética em Edifícios

Transcrição

1 Coimbra, Dezembro, 2011 Instituto Politécnico de Coimbra Instituto Superior de Engenharia de Coimbra Departamento de Engenharia Informática e de Sistemas Mestrado em Informática e Sistemas Estágio Industrial/Projecto Industrial Relatório Final ienergy - Eficiência Energética em Edifícios Pedro Rafael Pimenta Saraiva a @alunos.isec.pt Orientador da ISA Eng.º. Ricardo Clérigo rclerigo@isa.com Orientador do ISEC Doutor Viriato António Pereira Marinho Marques viriato@isec.pt

2

3 ienergy Eficiência Energética em Edifícios Resumo RESUMO O presente relatório tem por objectivo apresentar e descrever de forma detalhada o projecto ienergy Eficiência Energética em Edifícios, realizado no âmbito do estágio curricular, do Mestrado em Informática e Sistemas - Ramo de Desenvolvimento de Software, do Instituto Superior de Engenharia de Coimbra. Este estágio decorreu nas instalações da empresa ISA - Intelligent Sensing Anywhere de 22 de Novembro de 2010 a 31 de Julho de Este projecto nasce da necessidade crescente de conceber novas formas de racionalizar a energia que utilizamos diariamente, gerindo-a de forma mais eficiente. Quase todos os equipamentos que temos em nossas casas, escritórios, lojas ou em qualquer outro local que frequentamos habitualmente para trabalho ou para lazer, consomem algum tipo de energia quer seja ela eléctrica, gás natural ou outra. A utilização abusiva das fontes de energia de origem fóssil em Portugal, como o petróleo (que representa 57% do consumo), o carvão (12%), o gás natural (14%) [1], contribuem para a libertação de dióxido de carbono para a atmosfera trazendo consequências desastrosas para o nosso planeta, bem como elevados custos para as empresas e para os particulares. Um passo importante para uma utilização racional da energia passa pela consciencialização das pessoas e empresas de onde e como gastam a sua energia por forma a eliminar os gastos desnecessários. Tendo em vista este pressuposto a aplicação a desenvolver durante o estágio pretende responder a duas perguntas essenciais Onde é que a energia é consumida? e Como é que a energia é consumida? para que possam ser planeadas medidas para reduzir esses consumos. A aplicação a desenvolver durante o estágio assenta sobre a plataforma de monitorização existente na ISA, uma solução constituída por software e hardware que adquire, trata e armazena dados de eficiência energética para serem analisados mais tarde por gestores de energia. Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011 i

4

5 ienergy Eficiência Energética em Edifícios Abstract ABSTRACT This report aims to present and describe in detail the project "ienergy - Energy Efficiency in Buildings", performed under the curricular internship of the MSc in Informatics and Systems - Software Development branch-, of the Instituto Superior de Engenharia de Coimbra. This internship took place at ISA - Intelligent Sensing Anywhere, from 22 November 2010 to July31, This project was born due to the increasing need of conceiving new ways to rationalize the energy we use every day. Almost all the equipment we have in our homes, offices, shops or anywhere else that we inttend to regularly use for work or leisure, consumes some kind of energy, whether it is electrical, natural gas or other. The misuse of fossil energy sources in Portugal such as oil (which represents 57% of consumption), coal (12%) and natural gas (14%) [1] contribute to the release of carbon dioxide to the atmosphere bringing disastrous consequences for our planet, as well as high costs for companies and private individuals. An important step in a rational use of energy passes through the awareness of people and businesses, where and how they use their energy in order to eliminate unnecessary energy expenditure. Given this assumption the software developed during this internship aims to answer two essential questions: "Where is the energy consumed?" and "How is the energy consumed?" so that actions can be planned to reduce such consumption. The software developed in this internship is based on the existing platform of ISA: the solution consists of hardware and software that acquires energy efficiency data, processes it and stores it to be analyzed in more detail, later, by energy managers. Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011 iii

6

7 ienergy Eficiência Energética em Edifícios Palavras-Chave Palavras-Chave Engenharia Informática Gestão de Energia ienergy ISA- Intelligent Sensing Anywhere.NET Framework SCRUM MVC Eficiência Energética Keywords Engineering Informatics Energy management ienergy ISA- Intelligent Sensing Anywhere.NET Framework SCRUM MVC Energy Efficiency Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011 v

8

9 ienergy Eficiência Energética em Edifícios Símbolos e Abreviaturas Lista de Abreviaturas e Acrónimos API Application programming interface ASP Active Server Pages ASP.NET -Active Server Pages.NET AVAC Aquecimento, ventilação e ar condicionado ACE - Requisitos análise de custos de energia ALM Requisitos de alarmes BU Unidade de negócio BD Base de Dados CRUD - Create, Read, Update and Delete CA Requisitos conclusões da analise COD Requisitos de configuração de opções de aquisição de dados CTAR Requisitos para calculo e criação de tarifários BI - Business Intelligent B2B - Bussines to Bussines B2C - Bussines to Consumer C# - CSharp CPU- Central Processing Unit CSAD Controlo de supervisão e aquisição de dados COD - Configuração de opções de aquisição de dados da BD CSS - Cascading Style Sheets DLL - Dynamic link library EDP - Electricidade de Portugal EF - Entity Framework FTP - File Transfer Protocol FK Foreign Key GPL General Public License GPRS - General packet radio service GPS - Global Positioning System GUI - Graphical User Interface HTML HyperText Markup Language HTTP Hypertext Transfer Protocol IEEE Institute of Electrical and Electronics Engineers IP Internet Protocol I&D Investigação e Desenvolvimento ISA Intelligent Sensing Anywhere ISEC Instituto Superior de Engenharia de Coimbra ISO International Organization for Standardization IDE - Integrated Development Environment JSON JavaScript Object Notation kw Kilowatt kwh Kilowatt hora Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011 vii

10 Símbolos e Abreviaturas ienergy Eficiência Energética em Edifícios kb - Kilobyte kvar - Kilovolt-amperes reactive KPI Key Performance Indicators M9M Monday 9 oclock Meeting M2M Machine to Machine Communication MA Requisitos do modulo de actuação MVC- Model-view-controller ORM - Object Relational Mapping PDF Portable Document Format PK Primary Key REL- Requisitos de Relatórios RFID- Radio Frequency Identification SGBD Sistema de Gestão de Base de dados SNMP Simple Network Management Protocol SOAP Simple Object Access Protocol SQL Structured Query Language SEO - Search engine optimization SVN - Subversion STAR Requisitos para simulação de tarifários TDD - Test-driven development TCP Transmission Control Protocol T-SQL Transact-Structured Query Language TG - Requisitos de tabela geral TI - Tecnologia da informação TARIFA MT - Tarifa Média Tensão URE- Utilização Racional de Energia UDP - User Datagram Protocol UML Unified Modeling Language UI User Interface URL - Uniform Resource Locator XML Extended Markup Language WCF- Windows Communication Foundation WSDL Web Services Description Language WWW - World Wide Web VAG- Requisitos de visualização de dados na forma de gráfico viii Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

11 ienergy Eficiência Energética em Edifícios Agradecimentos Agradecimentos Ao Professor Doutor Viriato António Pereira Marinho Marques pela competência com que orientou esta minha tese e o tempo que generosamente me dedicou transmitindo-me os melhores e mais úteis ensinamentos, com paciência, lucidez e confiança. Pelo acesso que me facilitou a uma pesquisa mais alargada e enriquecedora e pela sua crítica sempre tão atempada, como construtiva. A minha família e aos meus amigos, que me deram força desde o primeiro momento e sempre me desejaram a maior sorte do mundo para esta etapa da minha vida. Aos meus orientadores da ISA- Intelligent Sensing Anywhere, por todo o apoio e direcção que me deram no trabalho desenvolvido ao longo deste ano lectivo. A todos os elementos da equipa de energia da ISA que estiveram sempre dispostos a ajudar quando necessário. Aos restantes elementos da ISA, que me receberam da melhor maneira possível, proporcionando um ambiente de trabalho descontraído e acolhedor, Muito obrigado! Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011 ix

12

13 ienergy Eficiência Energética em Edifícios Índice Índice 1 INTRODUÇÃO ÂMBITO APRESENTAÇÃO DA EMPRESA OBJECTIVOS DO ESTÁGIO CONTRIBUIÇÕES ORGANIZAÇÃO E TEMAS ABORDADOS NO PRESENTE RELATÓRIO ANÁLISE DO PROBLEMA CONCEITOS FUNDAMENTAIS PLATAFORMA IENERGY Principais Entidades do Sistema Descrição Geral do Projecto de Estágio PLANO DE TRABALHOS DO ESTÁGIO METODOLOGIA DE DESENVOLVIMENTO Descrição do Scrum APLICAÇÃO DO SCRUM NO PROJECTO DE ESTÁGIO Fases do Scrum OPINIÃO PESSOAL FASE DE INTEGRAÇÃO EFICIÊNCIA ENERGÉTICA EM EMBARCAÇÕES ANÁLISE DE REQUISITOS REQUISITOS FUNCIONAIS Definições Chave Módulo Associação de Mestres a Viagem Módulo Relatórios Módulo de Integração com Bilhética para Criação de Viagens Módulo de Criação de Alertas Módulo de Validação de Viagens IMPLEMENTAÇÃO Ferramentas de Desenvolvimento VERIFICAÇÃO E VALIDAÇÃO RESULTADOS OBTIDOS NESTA FASE REVISÃO TECNOLÓGICA ESTADO DA ARTE Soluções Existentes ou Semelhantes Resumo Crítico TECNOLOGIAS CONSIDERADAS Análise de Tecnologias da Concorrência Análise de Tecnologias para o Sistema Ferramentas de Construção de Relatórios Ferramentas Web de Gráficos Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011 xi

14 Índice ienergy Eficiência Energética em Edifícios 6 ESPECIFICAÇÃO VISÃO GERAL CARACTERÍSTICAS DOS UTILIZADORES ANÁLISE DE REQUISITOS Metodologia Usada na Recolha de Requisitos REQUISITOS FUNCIONAIS Módulo de Grupos Lógicos Módulo de Análise de Dados Módulo de Relatórios Módulo de Alertas Módulo de Actuação Módulo de Tarifários Módulo de Criação e Cálculo de Tarifas Módulo de Simulação de Tarifários PROTÓTIPOS DE INTERFACE REQUISITOS NÃO - FUNCIONAIS Eficiência Fiabilidade Manutenção Portabilidade Segurança Usabilidade Requisitos Tecnológicos Requisitos de Documentação OPINIÃO ARQUITECTURA E IMPLEMENTAÇÃO DA PLATAFORMA INTEGRAÇÃO COM OS VÁRIOS SISTEMAS IMPLEMENTAÇÃO Ferramentas Organização do Código COMPONENTES Base de Dados Task Scheduler Core da Aplicação Web Service Aplicação Web PROBLEMAS ENCONTRADOS Árvore de Grupos Acessos a Tabela de Dados TESTES UNITÁRIOS OPINIÃO VERIFICAÇÃO E VALIDAÇÃO REVISÃO VALIDAÇÃO xii Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

15 ienergy Eficiência Energética em Edifícios Índice Ambiente de Testes VERIFICAÇÃO INSTALAÇÃO NO CLIENTE CONCLUSÃO E PERSPECTIVAS FUTURAS PLANEAMENTO EFECTIVAMENTE SEGUIDO Planeamento Efectivamente Seguido no Primeiro Semestre Planeamento Efectivamente Seguido no Segundo Semestre Justificação dos Desvios AVALIAÇÃO DO TRABALHO DESENVOLVIDO TRABALHO FUTURO CONSIDERAÇÕES PESSOAIS REFERÊNCIAS Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011 xiii

16

17 ienergy Eficiência Energética em Edifícios Índice de Figuras Índice de Figuras Figura 1 - Camadas da plataforma... 7 Figura 2 - Organização das principais Entidades do Sistema... 9 Figura 3 - Ciclo de desenvolvimento do Scrum Figura 4 Diagrama de Gantt com o planeamento inicial do trabalho a realizar no primeiro semestre Figura 5 Diagrama de Gantt com o planeamento do trabalho a realizar no segundo semestre Figura 6 -Número de funcionalidades dos competidores Figura 7 - Tipo de tecnologias usadas pelos competidores Figura 8: Relação entre a complexidade (número de funcionalidades) e o tipo de tecnologias Figura 9 - Hierarquia de Utilizadores Figura 10 - Exemplo de perguntas colocadas no Google Docs Figura 11 - Casos de uso do sistema separados por pacotes Figura 12 - Termo fixo do tarifário Figura 13 - Descriminação de preços de energia activa Figura 14 - Descriminação de preços de potência Figura 15 - Descriminação de preços de energia reactiva Figura 16 - Factores multiplicativos aplicados a energia reactiva Figura 17 - Gráfico de linhas com representação dos períodos sazonais e períodos horários Figura 18 - Opções de Gráfico e informação de análise Figura 19 - Tabela de Conclusões Figura 20 - Tabela Geral Figura 21 - Análise de Custos Figura 22 - Lista de Alertas Figura 23 - Criação de alertas Figura 24 - Lista de alertas disparados Figura 25 - Criação de actuações Figura 26 - Lista de actuações Figura 27 - Simulação de tarifários Figura 28 - Lista de tarifários Figura 29 - Inserção de novo tarifário Figura 30 - Inserção de parâmetros do tarifário Figura 31- Lista de grupos Figura 32 - Página de edição de grupos Figura 33 - Esquema de funcionamento do ASP.NET MVC (retirado do msdn Webcast) Figura 34 -Como é que o portal web e o ienergy se enquadram na solução de medição Figura 35 - Organização do código no Visual Studio Figura 36 - Módulos do ienergy Figura 37 - Fluxograma de cálculo de tarifários B2B Figura 38 - Fluxo de cálculo da baseline Figura 39 Fluxo de funcionamento dos alertas Figura 40 -Diagrama de classes Core (apenas a parte criada durante o estágio) Figura 41 Diagrama de classes End Point de edifícios Figura 42 - Visão Geral do Sistema Figura 43 - Arquitectura Web Service Figura 44 - Arquitectura lógica Figura 45 - Decomposição Horizontal Figura 46 - Decomposição Vertical Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011 xv

18 Índice de Figuras ienergy Eficiência Energética em Edifícios Figura 47- Diagrama de classes do Controller Figura 48 - Modelo de classes dos Action Filters Figura 49 - Diagrama de classes dos helpers do view Figura 50 - Modelos de classes dos Binders Figura 51 Diagrama de gantt com a distribuição temporal do trabalho realizado no primeiro semestre Figura 52 Diagrama de Gantt com a distribuição temporal do trabalho realizado no segundo semestre Figura 53 - Ciclo de Gestão de energia xvi Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

19 ienergy Eficiência Energética em Edifícios Índice de Tabelas Índice de Tabelas Tabela 1 - Fases do Game do Projecto Tabela 2 - Quadro parcial de funcionalidades da concorrência Tabela 3 - Comparação de ferramentas web de construção de gráficos Tabela 4 - Tempo de renderização de gráficos Tabela 5 - Tabela de requisitos do sistema Tabela 6 - Requisitos de grupos lógicos Tabela 7 - Tabela de Requisitos de Baseline Tabela 8 - Requisitos de KPIs Tabela 9 - Requisitos de indicadores de estado Tabela 10 - Requisitos de indicadores de poupança Tabela 11 - Requisitos de mensagens Tabela 12 - Requisitos de tags virtuais Tabela 13 Requisitos de configuração de opções de grupos e variáveis Tabela 14 - Requisitos de configuração da aquisição de dados Tabela 15 - Requisitos de visualização de dados Tabela 16 - Requisitos de análise de custos de energia Tabela 17 - Requisitos de conclusões da análise Tabela 18 - Requisitos de dados gerais Tabela 19 - Requisitos de Relatórios Tabela 20 - Requisitos para gestão de Alertas Tabela 21 Requisitos para a actuação Tabela 22 Requisitos para o cálculo de tarifários Tabela 23 Requisitos para simulação de tarifários Tabela 24 - Ligação de requisitos a protótipos Tabela 25 -Descrição sumária das entidades do diagrama da base de dados Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011 xvii

20

21 ienergy Eficiência Energética em Edifícios Índice de Anexos Índice de Anexos Anexo I Estado da Arte Anexo II Casos de Uso Anexo III Plano de Riscos Anexo IV Especificação Web Service de Edifícios Anexo V Especificação de Base de Dados Anexo VI Especificação de Requisitos para a Fase de Integração Anexo VII Manual do Utilizador Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011 xix

22

23 ienergy Eficiência Energética em Edifícios Introdução 1 Introdução Neste capítulo é inicialmente feita uma introdução ao âmbito do estágio seguindo-se uma breve apresentação da empresa onde foi realizado. Seguidamente descreve-se o projecto de estágio e enunciam-se os seus objectivos; em seguida são apresentados os contributos para o projecto. 1.1 Âmbito Actualmente o peso da factura energética nos custos de exploração de uma empresa do sector industrial é relativamente baixo por comparação com outros factores de produção como a mão-de-obra ou a matéria-prima. Por esse motivo a gestão de energia é frequentemente negligenciada, facto que pode gera significativos desperdícios de energia o que contribui para a redução da competitividade das empresas. Adicionalmente, continua presente na mente de algumas indústrias a ideia de que o crescimento económico acarreta necessariamente um aumento dos consumos de energia o que não é inteiramente verdade. O conceito de utilização racional de energia, surgido no seguimento dos chamados choques petrolíferos [2], veio alterar decisivamente a forma de encarar a energia, demonstrando ser possível crescer sem aumentar os consumos ou afectar a qualidade da produção. A chave da questão designa-se por gestão de energia. Como qualquer outro factor de produção, a energia deve ser gerida contínua e eficazmente. A utilização racional da energia (URE) consiste num conjunto de acções e medidas, que têm por objectivo melhorar a utilização da energia. A URE é cada vez mais um factor importante de economia energética e na redução de custos, tanto no sector doméstico como no sector de serviços e industria. Embora o argumento da competitividade continue naturalmente a ser aquele que mais sensibiliza a generalidade das indústrias, a crescente pressão ambiental veio reforçar a necessidade de utilizar de forma eficiente a energia. Seja por imposição legal, seja pela necessidade de cumprir requisitos ambientais como forma de aceder a sistemas de apoio ou simplesmente por uma questão de imagem ou pressão da opinião pública, cada vez mais a eficiência energética está na ordem do dia. Para além disso é unanimemente aceite que, mais cedo ou mais tarde, instrumentos políticos de mercado, como taxas ou impostos ambientais, introduzirão finalmente o princípio do poluidor pagador, penalizando fortemente as empresas menos preparadas. É assim que assumem particular importância o levantamento e a auditoria energética. Com efeito, qualquer processo de gestão de energia terá necessariamente que começar pelo conhecimento da situação energética das instalações. O princípio é óbvio - para gerir é indispensável conhecer o objecto de gestão. Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011 1

24 Introdução ienergy Eficiência Energética em Edifícios O levantamento energético pode interpretar-se como a primeira radiografia ao desempenho energético da empresa ou industria. Através dele, avalia-se quanta energia é efectivamente consumida e de que forma é essa energia utilizada, estabelecem-se os principais fluxos e identificam-se os sectores ou equipamentos onde é prioritário actuar. Por auditoria energética entende-se o exame detalhado das condições de utilização de energia nas instalações. A auditoria permite conhecer onde, quando e como a energia é utilizada, qual a eficiência dos equipamentos e onde se verificam desperdícios de energia, indicando igualmente soluções para as anomalias detectadas. A auditoria energética pode também constituir uma obrigação legal. Com efeito, estão abrangidas pelo regulamento de gestão do consumo de energia (R.G.C.E.)[2], todas as empresas ou instalações consumidoras intensivas de energia. A auditoria energética surge assim como um instrumento fundamental, que o gestor de energia possui para contabilizar os consumos de energia, a eficiência energética dos seus equipamentos e as perdas que se verificam, tendo como finalidade última reduzir essas perdas sem afectar a produção, isto é, economizar energia através do uso mais eficiente da mesma. No mundo de hoje as máquinas ocupam já um papel de destaque em todas as áreas da nossa vida. Por isso devem funcionar de forma a melhorar a sua eficiência energética, o que pressupõe uma recolha e análise de dados que possam ser consultados na forma de gráficos, relatórios, alarmes e outras formas de análise. A solução actual da ISA permite já a monotorização remota da energia através de um grande número de sensores espalhados pelos edifícios. Sendo ainda um produto em maturação tem como é óbvio algumas lacunas e algumas funcionalidades por implementar. Com este estágio pretendeu-se cobrir parcialmente uma dessas lacunas, um software para o mercado B2B, que dotasse a ISA de uma ferramenta de visualização e análise de dados, destinada a auxiliar o gestor de energia da ISA na sua tarefa diária. A função principal deste software é o de apoiar o gestor de energia da ISA na identificação de problemas energéticos nos edifícios e na identificação equipamentos menos eficientes por forma a poderem ser feitos investimentos conscientes na melhoria desses mesmos equipamentos, contribuindo assim para uma utilização racional da energia, reduzindo custos e aumentado a competitividade das empresas. As soluções de análise de eficiência energética têm actualmente pouca divulgação em Portugal, existem já algumas soluções no mercado em outros países, mas estas soluções têm a desvantagem em relação solução global da ISA, de a maior parte delas não oferecer uma solução completa desde os equipamentos de medição até ao software e de muitas delas não terem uma forma centralizada de ver a 2 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

25 ienergy Eficiência Energética em Edifícios Introdução informação disponibilizada. A ISA pretende oferecer essa solução com todas as funcionalidades necessárias a uma gestão eficiente da energia. 1.2 Apresentação da Empresa A ISA - Intelligent Sensing Anywhere é uma empresa global premiada e reconhecida internacionalmente, especializada na área da telemetria de comunicações M2M. É líder em diferentes segmentos desse mercado. Fundada em 1990 como spin-off da Universidade de Coimbra, a ISA conta com cerca de 100 colaboradores, escritórios em França, Espanha, Alemanha, Irlanda e Brasil, estando também presente em outros países através de agentes locais. O centro de I&D encontra-se em Portugal, onde cerca de metade da equipa da ISA se dedica permanentemente à inovação e desenvolvimento de produtos pioneiros. As principais áreas de aplicação são: Telemetria Óleo & Gás; Soluções de Gestão de Energia; Gestão Remota de Bens; Sistemas de Gestão Integrada de Edifícios; Solução de Gestão Remota para o Ambiente; Soluções Médicas e de Cuidados de Saúde; De entre todas estas áreas é de destacar a área de energia que inclui uma solução completa com sensores, contadores e toda a gama de dispositivos inovadores que estabelecem uma rede capaz de monitorizar à distância diversos parâmetros, tais como o consumo de água, gás e electricidade, qualidade do ar, entre muitas outras funcionalidades A informação recolhida pelos sensores é armazenada e tratada, sendo posteriormente disponibilizada ao utilizador, através de um qualquer computador, telemóvel, ou display dedicado. A versatilidade da solução imeter desenvolvida pela ISA permite o controlo remoto de qualquer electrodoméstico de forma a promover de forma efectiva a eficiência energética. Esta solução foi reconhecida várias vezes pelo carácter inovador do conceito e das tecnologias que incorpora. O estágio foi incluído nesta área da empresa que é chamada de área de energia, e na solução de medição remota de gastos energéticos em edifícios. 1.3 Objectivos do Estágio O objectivo principal deste estágio foi trabalhar sobre a plataforma de recolha e análise de dados de eficiência energética da ISA, nas diversas fases de desenvolvimento do projecto, bem como nas Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011 3

26 Introdução ienergy Eficiência Energética em Edifícios diversas camadas que constituem este software, de forma a implementar novas funcionalidades que permitissem a evolução da plataforma para melhor acomodar o mercado B2B da empresa. Neste projecto pretendeu-se desenvolver um portal de eficiência energética para o mercado B2B usando para tal toda a infra-estrutura já existente na ISA, uma solução constituída por software e hardware chamada - ienergy -. O software desenvolvido vai permitir a análise dos consumos energéticos em diversos edifícios de uma forma centralizada, sejam eles consumos eléctricos, água ou gás, sendo que o consumo eléctrico é o que tem maior relevância no projecto e é o mais usado para propósitos de teste e exemplos ao longo do presente relatório. A plataforma já existente o - ienergy - é uma plataforma que recebe leituras de centenas de sensores em diversas localizações geográficas. O tipo de leituras varia com o dispositivo: por exemplo no caso da electricidade são recolhidas leituras de consumos de energia activa, potência ou mesmo energia reactiva entre outros. O - ienergy - recebe esses dados, armazena-os e processa-os (transformaos por exemplo em consumo de energia por hora, dia, ano ou mês) disponibilizando-os depois aos seus clientes (domésticos e empresariais). Os principais objectivos da plataforma global - ienergy - são; Adquirir dados de sensores remotos; Guardar e processar esses dados; Monitorizar o equipamento e detectar anomalias; Oferecer uma API que possa ser usada para sistemas de terceiros. A plataforma de recolha e análise de dados encontra-se divida em vários módulos, desde o módulo de recolha de dados, módulo de acesso aos dados, até ao módulo de disponibilização de dados através de web services para aplicações clientes. Na primeira fase do estágio pretendeu-se fazer uma recolha de requisitos para a plataforma de análise de dados na sua vertente B2B com o cliente do software o gestor de energia da ISA. A segunda fase do projecto teve por objectivo desenvolver um interface web que permitisse analisar todos os dados disponibilizados pela plataforma bem como a implementação de novas funcionalidades no - ienergy - como por exemplo cálculo e simulação de tarifários de energia eléctrica, cálculo de indicadores, agrupamento de hardware separado geograficamente em grupos lógicos, entre outras. O objectivo final consistiu em obter um software que ajude a gerir melhor os consumos de energia nos edifícios, permitindo identificar e consciencializar as pessoas de onde e como gastam a energia, permitindo desta maneira actuar sobre os desperdícios energéticos. 4 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

27 ienergy Eficiência Energética em Edifícios Introdução 1.4 Contribuições Creio ser legítimo afirmar que o projecto ienergy Eficiência Energética em Edifícios alcançou os objectivos inicialmente traçados. Esta opinião é alicerçada no facto de ter sido implementada a aplicação pretendida (solicitada por cliente específico), tendo inclusivamente o software desenvolvido servido para detectar várias anomalias de consumos energéticos nos edifícios onde foi usado (por exemplo, sistemas AVAC e de iluminação a funcionarem sem necessidade). Além disso, a documentação produzida como suporte ao processo de implementação alcançou, na minha opinião, os níveis de qualidade pretendidos. Um dos alicerces desta opinião está na auditoria externa a que este projecto foi sujeito, e no qual passou com bons resultados. Outro motivo de satisfação é o facto de o software ter sido instalado juntamente com a solução - ienergy - num cliente bancário para permitir a gestão energética de todas as suas agências e edifícios. Neste momento o software está a funcionar com cerca de 400 grupos lógicos (agências e edifícios) com centenas de sensores a enviarem informação para a plataforma - ienergy Organização e Temas Abordados no Presente Relatório O presente documento encontra-se dividido em nove capítulos. Inclui também um conjunto de anexos com informação complementar que de uma forma ou outra ajudam a melhor compreender o problema e o trabalho realizado. Após este capítulo introdutório, no Capítulo 2, Análise do Problema, apresenta-se o problema em detalhe, num contexto global e no contexto do estágio. No Capítulo 3, Plano de Trabalhos do estágio, é introduzida a metodologia de desenvolvimento usada durante o projecto, bem como a sua implementação. Segue-se o planeamento inicial para o projecto bem como a sua justificação. No Capítulo 4, Fase de Integração, é feita a descrição do trabalho inicial executado antes de o projecto propriamente dito se ter iniciado, por forma a integrar-me na metodologia e nas tecnologias de desenvolvimento usadas pela empresa. No Capítulo 5, Revisão Tecnológica, analisa-se o estado da arte, fazendo uma análise crítica sobre as soluções existentes ou semelhantes, e as suas lacunas. Segue-se também uma análise crítica sobre as possíveis tecnologias a usar na implementação do sistema. No Capítulo 6, Especificação, descrevem-se os vários tipos de requisitos da solução a implementar, justificando-se também as tecnologias adoptadas. Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011 5

28 Introdução ienergy Eficiência Energética em Edifícios No Capítulo 7, Arquitectura e Implementação da Plataforma, começa-se por apresentar a arquitectura global da aplicação. De seguida é efectuada uma descrição pormenorizada da solução desenvolvida, na qual se refere os vários aspectos e detalhes do modelo de dados e da interface. No Capítulo 8,Verificação e Validação, são apresentados os testes e verificações que o software foi sujeito de forma a garantir que estava dentro dos parâmetros de qualidade desejados. No Capítulo 9, Avaliação de Resultados, faz-se uma análise e discussão sobre os resultados obtidos no estágio. 6 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

29 ienergy Eficiência Energética em Edifícios Análise do Problema 2 Análise do Problema Neste capítulo é feita a apresentação do problema num contexto global. São também apresentados alguns conceitos fundamentais para uma melhor compreensão do problema e do projecto. 2.1 Conceitos Fundamentais Para melhor se compreender o âmbito do projecto em estudo, existe um conjunto de tópicos referentes à plataforma - ienergy -, cuja apresentação é pertinente. Na secção de Glossário e Definições existem ainda um conjunto de definições relacionadas com a gestão de energia que também podem ser úteis para uma melhor compreensão do projecto. 2.2 Plataforma ienergy A solução - ienergy - é composta por vários módulos de software e hardware. O hardware é composto por sensores que recolhem vários tipos de dados de consumos energéticos. Este hardware comunica através da internet com uma plataforma de recolha de dados - o icenter -, que posteriormente passa esses dados para a camada de processamento de dados - o ienergy -, que os trata e os disponibiliza para plataformas clientes através de web services, como mostra a Figura 1. Fornecimento de dados Domestico Escolas Edifícios Tratamento de dados ienergy Recolha icenter Web Aquisição Figura 1 - Camadas da plataforma Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011 7

30 Análise do Problema ienergy Eficiência Energética em Edifícios Cada uma dessas camadas do software é descrita de seguida: Aquisição O harware da ISA que é instalado e configurado para monitorizar variáveis energéticas. O hardware depois de instalado envia os dados recolhidos para a plataforma - icenter -; Recolha A plataforma - icenter - recebe os dados e armazena-os localmente. Posteriormente encaminha-os para a camada superior, o - ienergy -, para que as análises de alto nível possam ser realizadas; Tratamento de dados Nesta camada encontra-se o core da plataforma - ienergy - que valida os dados e faz análises de alto nível aos dados recebidos; Fornecimento de dados Nesta camada encontram-se os vários end points de web service que são usados por GUIs clientes para receber e enviar dados da e para a plataforma. As camadas inferiores da plataforma, nomeadamente as camadas de aquisição e recolha de dados, estão fora do âmbito deste projecto, e são apenas apresentadas de forma a ser possível perceber como é que os dados chegam à plataforma - ienergy -. A solução desenvolvida durante o estágio passou pelas restantes camadas, a camada de processamento de dados e camada de fornecimento de dados e ainda pela camada de apresentação. Esta abordagem foi pensada tendo em conta que nem todas a funcionalidades necessárias ao software de edifícios estavam implementadas no core da aplicação. Por isso foi necessário desenvolver trabalho nesta camada de modo a obter suporte para uma nova aplicação web destinada a gestão energética em edifícios Principais Entidades do Sistema O sistema é constituído por várias entidades, sendo que para compreender o seu funcionamento se torna necessário introduzir aqui cada uma delas: Unidade: A unidade é o hardware situado nas instalações do cliente e que recebe leituras dos dispositivos. Estas leituras são posteriormente passados para a plataforma - ienergy - com a finalidade de os dados serem guardados e tratados. Dispositivos: São outra peça de hardware que se encontra no local a ser monitorizado. Os dispositivos podem ler diversos parâmetros (energia activa, energia reactiva, corrente, potência). Estes dispositivos enviam os dados que recolhem para a unidade que os controla. Uma unidade pode controlar mais do que um dispositivo. Os dispositivos podem também ser ligados a equipamentos específicos como por exemplo a sistemas AVAC com objectivo de medir os seus gastos energéticos individualmente ou mesmo actuar sobre eles ligando-os e desligando-os; 8 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

31 ienergy Eficiência Energética em Edifícios Análise do Problema Tag: É onde são guardados os parâmetros lidos pelos dispositivos. Se um dispositivo medir a corrente e a energia activa vão existir duas tags para esse dispositivo. Local - O local é a localização onde o hardware de monotorização remota está instalado. Pode corresponder a uma casa, a um edifício etc. Como podemos ver pela Figura 2, as unidades estão no topo de uma hierárquia, sendo uma peça de hardware. São responsáveis por recolher os dados de cada um dos dispositivos instalados num edifício, sendo que o edifício pode ter mais do que um dispositivo que comunica com as unidades através de Wireless ou ZigBee. No fim da hierárquica estão as tags que não são mais que tipos de medições, podendo ser de energia activa, temperatura, ou energia reactiva, entre outras. Unidades Edificio 1 Dispositivos Sala 1 Sala 2 Tags Energy Temperature Humidity Figura 2 - Organização das principais Entidades do Sistema Outra entidade importante são os grupos lógicos: com estes grupos pretende-se agrupar logicamente as unidades, os dispositivos ou as tags. Com os grupos pretende-se facilitar a vida ao utilizador organizando os dispositivos, tags e unidades de forma lógica e hierarquizada possibilitando uma visualização fácil da organização. Estes grupos podem mesmo agrupar edifícios separados geograficamente Descrição Geral do Projecto de Estágio O levantamento de informação que serviu de suporte ao estágio foi feito através da documentação da plataforma o - ienergy -, pesquisa de informação em várias páginas web acerca do tema, do estudo Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011 9

32 Análise do Problema ienergy Eficiência Energética em Edifícios dos trabalhos realizados na área (nomeadamente da concorrência), e reuniões com pessoas associadas ao projecto. Nesta secção realiza-se uma apresentação de todo o sistema num contexto geral, referindo os seus intervenientes Intervenientes Para este sistema identificou-se a existência de três classes de utilizadores: O Utilizador Geral é um utilizador não registado, que portanto nada pode fazer no sistema. Para um Utilizador Geral se tornar um utilizador registado terá de pedir acesso ao administrador do sistema. Nesta aplicação não existe o conceito de registo de utilizador: todos os utilizadores são adicionados ao sistema por um utilizador administrador. O Utilizador Registado, para além de usufruir dos privilégios de um Utilizador Geral, tem ainda permissão para introduzir novos objectos no sistema, assim como para os editar e remover. Existem dois tipos de utilizadores registados nesta plataforma: o Cliente e o Gestor de Energia: cada um deles tem permissões diferentes. O Cliente tem acesso à plataforma apenas para ver indicadores (não os pode alterar) e extrair relatórios predefinidos (não os pode alterar) dos projectos a que está alocado tendo restrições ao nível dos grupos lógicos que pode ver. O Gestor de Energia pode ver qualquer grupo lógico inserido no sistema bem como configurar indicadores, unidades, tags virtuais, entre outras opções de que falaremos mais à frente. Não pode adicionar nem remover utilizadores do sistema. Por último, o Administrador tem acesso total à plataforma e pode adicionar, remover e editar qualquer entidade. Apenas este utilizador especial pode gerir os Utilizadores Privilegiados, ou seja, criar novos utilizadores deste tipo, assim como editá-los e removê-los. Nenhum dos utilizadores precisa de ter um vasto conhecimento técnico pois toda a interacção com o sistema é feita intuitivamente através de um browser Solução Global O sistema desenvolvido no presente estágio tem como objectivo disponibilizar um método (semi-) automático para efectuar a análise de consumo energético em edifícios, e ao mesmo tempo detectar situações anómalas de consumos automaticamente, permitindo identificar eventuais desperdícios de forma a ser possível tomar medidas para os resolver. 10 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

33 ienergy Eficiência Energética em Edifícios Análise do Problema Com base no estudo realizado verificou-se que o sistema deveria ser constituído por várias partes e a interacção ser feita através de uma aplicação web, cujo intuito é de ser acessível online com acesso restrito. Como já foi referido este novo sistema será integrado na plataforma já existente, o - ienergy -. Portanto este estágio encontra-se dividido em duas partes: 1) Construção de raiz de uma plataforma web que permita a visualização e análise de consumos energéticos em edifícios; 2) Implementação de novas funcionalidades na plataforma - ienergy -,: pretende-se disponibilizar um conjunto de funcionalidades que ajudem as pessoas responsáveis pela gestão da energia em edifícios na sua tarefa do dia á dia. O sistema deve portanto satisfazer as seguintes áreas de requisitos: Aplicação Web o Área de análise e comparação Contém todas as funcionalidades de análise e comparação de variáveis energéticas. Navegação entre os grupos lógicos (edifícios). Selecção de variáveis energéticas nesses grupos lógicos. Escolha da unidade em que se pretende ver os consumos (KWh=> CO2). Visualização de consumos em forma gráfica e tabelas. Exportação de dados para Excel. o Área de alarmes Contém todas as funcionalidades para criação, edição e visualização de alarmes. Lista de alarmes disparados no sistema. Marcação de alarmes já resolvidos. o Área de Actuação Contém as funcionalidades de gestão de actuações sobre dispositivos que permitam essa funcionalidade (agendar acções como ligar e desligar dispositivos). Listar de actuações. o Simulação de tarifários Contém as funcionalidades de visualização de comparação de tarifários. o Relatórios Apresentação de relatórios de interesse para o gestor de energia. Plataforma ienergy Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

34 Análise do Problema ienergy Eficiência Energética em Edifícios o Tarifários de electricidade Contém toda a funcionalidade de criação e edição de tarifários de electricidade. Navegação entre tarifários. o Cálculo de Tarifários de Energia eléctrica Contém toda a funcionalidade de cálculo de tarifários de energia eléctrica. o Verificação de actuação Verificação de actuações que devem ser feitas sobre os dispositivos. o Gestão de Grupos Contém todas as funcionalidades de criação de grupos lógicos. Criação de Indicadores (operações sobre tags). Criação de Tags Virtuais (operações entre tags). Gestão de permissões nos grupos. o Verificação de Alarmes Verificação de lançamento de alarmes. o Simulação de tarifários Cálculo de custos de energia para cada um dos tarifários no sistema. Este sistema deve estar constantemente disponível e não deve permitir acessos indevidos, ou seja, deve permitir apenas as funcionalidades a que um utilizador de um dado nível tenha acesso. Pretendese que possa ser acedido através de qualquer browser instalado num computador pessoal. Em termos de desempenho pretende-se que as pesquisas sobre os dados sejam tão rápidas quanto possível. Deve ainda permitir um acesso multi-utilizador igualmente com bom desempenho. Estes requisitos serão descritos de forma mais detalhada na secção Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

35 ienergy Eficiência Energética em Edifícios Plano de Trabalhos 3 Plano de Trabalhos do Estágio Neste capítulo é apresentado o plano de trabalhos do estágio: em primeiro lugar, a metodologia de desenvolvimento de software; em seguida são mostradas as planificações feitas para as tarefas desenvolvidas no contexto deste projecto. Inicialmente efectuou-se uma análise do problema, já apresentada no capítulo anterior. Seguiu-se o levantamento do estado da arte, com vista a verificar as soluções existentes ou semelhantes. Foi também efectuada uma análise sobre as tecnologias existentes, a considerar para serem utilizadas no desenvolvimento da aplicação web. Após isso foi feita a especificação do sistema, detalhando fundamentalmente as partes que foram implementadas durante o estágio. Para finalizar esta primeira fase foram escolhidas as tecnologias a utilizar e foi feita uma aprendizagem intensiva com o auxílio de documentação apropriada. Na fase seguinte deu-se início à implementação do sistema começando pela base de dados e prosseguindo depois pela plataforma (core e web service) até a aplicação web durante os quatro meses seguintes. Finalmente procedeu-se à escrita do presente documento e à afinação do sistema e correcção de problemas. 3.1 Metodologia de Desenvolvimento Implementar software de dimensão significativa sem usar nenhuma metodologia para guiar o desenvolvimento poderá levar o projecto ao insucesso. Realizar desenvolvimento de software usando uma metodologia que não se adequa ao projecto, ou porque não foram tidas em conta as especificidades do projecto e da equipa, ou porque no decorrer do processo se revelou pouco adequada ao mesmo, também condena desde logo tal projecto ao fracasso. Existem já muitos estudos [3] que alicerçam esta opinião. Existem várias métricas que podem ser usadas na escolha da metodologia, neste caso a equipa de energia da ISA do departamento de software (o departamento onde se insere o projecto de estágio) utilizava já o scrum no desenvolvimento de software, e foi portanto essa a metodologia de desenvolvimento usada. Neste estágio apesar de a maior parte do tempo ter trabalhado sozinho era necessário ter grande contacto com a equipa de desenvolvimento do - ienergy -, devido ao facto de este ser um projecto no seu global muito complexo com várias camadas onde era necessária a ajuda de alguém com conhecimento da plataforma. Desta forma foi possível reduzir o tempo de estudo da plataforma, para além de que possibilitou a integração dos módulos construídos durante o estágio na solução global e permitiu actualizadar a documentação do projecto com o que ia sendo feito. Desta forma foi possível manter todos os elementos da equipa de desenvolvimento com o mesmo nível de conhecimento sobre o Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

36 Plano de Trabalhos ienergy Eficiência Energética em Edifícios que estava a ser feito e o que tinha sido feito de modo a não existirem grandes discrepâncias nos desenvolvimentos Descrição do Scrum O scrum é uma metodologia ágil para gestão e planeamento de projectos. As metodologias ágeis de desenvolvimento de software são iterativas, ou seja, o trabalho é dividido em iterações, que são chamadas de sprints no caso do scrum. Esta metodologia caracteriza-se pela elevada produtividade das equipas envolvidas, obtida através de diversas técnicas que vão desde a construção de um sólido espírito de equipa, a uma forte autoresponsabilização da mesma, e uma consistente componente de melhoria contínua dos processos de desenvolvimento. As funcionalidades a serem implementadas durante o projecto são mantidas numa lista que é conhecida como product backlog. No início de cada sprint, faz-se um sprint planning meeting, ou seja, uma reunião de planeamento na qual o product owner prioriza os itens do product backlog e a equipa selecciona as actividades que ela será capaz de implementar durante o sprint que se inicia. As tarefas alocadas a um sprint são transferidas do product backlog para o sprint backlog. A cada dia de um sprint, a equipa faz uma breve reunião (normalmente de manhã), chamada daily scrum. O objectivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia. No final de um sprint, a equipa apresenta as funcionalidades implementadas num sprint review meeting. Finalmente, faz-se um sprint retrospective e a equipa parte para o planeamento do próximo sprint. Assim reinicia-se o ciclo. Figura 3 - Ciclo de desenvolvimento do Scrum 14 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

37 ienergy Eficiência Energética em Edifícios Plano de Trabalhos 3.2 Aplicação do Scrum no Projecto de Estágio A abordagem que foi usada durante o projecto foi baseada no scrum, conforme já referido. Assim o projecto foi dividido em vários sprint s, e no final de cada um foi feita uma publicação do software para testes e para o cliente, de modo a que o sistema fosse validado e avaliado desde o início do seu desenvolvimento. Pretendeu-se desta forma desenvolver o sistema de forma gradual disponibilizando mais rapidamente as funcionalidades prioritárias, sendo alvo de uma maior verificação e teste, corrigindo os problemas de uma forma controlada e construindo os vários módulos do sistema tendo o que já estiver concretizado a funcionar correctamente e portanto evitando problemas maiores. Como já referi, ao longo do decorrer deste projecto trabalhei inserido numa equipa de desenvolvimento. Uma característica do scrum que foi muito explorada neste trabalho é o facto de este ter sido baseado fortemente em user stories e casos de uso. De facto, foram elaborados vários diagramas de casos de uso e foram elaboradas user stories para cobrir os requisitos identificados. Esse trabalho revelou-se fulcral para compreender exactamente aquilo que era esperado de mim a nível do comportamento da aplicação Fases do Scrum Nesta subsecção são apresentadas todas as fases pelas quais o projecto passou, e é explicada cada uma delas Pré- Game(Análise) O primeiro sprint do projecto foi dedicado ao estudo da plataforma existente das tecnologias a usar e da concorrência, finalizado com a recolha e análise de requisitos para a plataforma que se pretendia construir. Deu-se assim início à construção do product backlog com as user stories que constituem os requisitos do sistema. Nesta fase foram também apresentadas as ferramentas à equipa de projecto e os prazos a cumprir. O sprint backlog foi actualizado através da ferramenta JIRA pelo menos uma vez por dia actualizando sempre o tempo estimado para conclusão da tarefa e o tempo investido na realização de cada tarefa Product BackLog (Product owner) Nesta primeira fase foi criado o backlog. O backlog foi baseado na informação do cliente, situação de mercado (estudo da competição), requisitos competitivos e o conhecimento de que funcionalidades são mais necessárias. O backlog construído durante o estágio encontra-se na secção 6 contendo todas as funcionalidade implementadas durante o mesmo. Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

38 Plano de Trabalhos ienergy Eficiência Energética em Edifícios Ferramentas de Suporte Ao longo do estágio foram usadas várias ferramentas mas devem-se destacar em especial duas delas, visto terem sido, na minha opinião de vital importância para o sucesso do projecto e suporte do scrum: a ferramenta JIRA e o SVN. SVN Foi usado um repositório com todos os artefactos gerados durante o projecto: este foi um repositório SVN. Um repositório SVN permitir ter um histórico de alterações de código e de documentação. JIRA Ferramenta de gestão de projecto, onde é possível ver todas as tarefas atribuídas em cada um dos sprint s, atrasos, etc. Esta ferramenta foi usada diariamente, as tarefas foram sendo actualizadas e os bugs reportados. Balsamic Mockups Para construir protótipos de interface com o utilizador de modo a validar os requisitos do sistema. EnterpriseArchitect - Uma ferramenta que oferece capacidade de gestão. Foi utilizada para modelizar a solução de software nos seus vários domínios, desde a análise de requisitos ao desenho detalhado; Equipa e Papéis A equipa em que estive inserido é designada por equipa de energia e é constituída por oito elementos de diferentes perfis, desde o firmware, sistemas embutidos até ao software. Uma equipa com vastos conhecimentos na área, que me permitiu uma rápida integração no projecto e que muito ajudou durante o desenvolvimento. O team leader desta equipa assumiu o papel de scrum master. Já o papel de product owner foi assumido pelo gestor de energia da ISA Datas O projecto teve a duração nove meses. Em termos de scrum estava previsto o projecto estar divido em 4 sprints sendo que o último sprint seria apenas para correcção de bugs e preparação da release final. O primeiro sprint seria usado para o estudo da plataforma e das tecnologias Primeiro semestre O estágio " ienergy Eficiência Energética em Edifícios" teve início dia 22 de Novembro de 2010 no seio da empresa ISA, sediada em Coimbra, em regime de tempo parcial com uma carga horária média prevista de 16 horas por semana, conforme o dimensionamento feito para a disciplina de estágio neste semestre. 16 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

39 ienergy Eficiência Energética em Edifícios Plano de Trabalhos O objectivo inicial deste estágio seria o estudo da plataforma existente o - ienergy -, estudo de tecnologias e especificação de requisitos para a plataforma tendo como output desta fase a especificação técnica do software. O planeamento proposto inicialmente pode ser visualizado no diagrama de gantt da Figura 4. Figura 4 Diagrama de Gantt com o planeamento inicial do trabalho a realizar no primeiro semestre. Uma das primeiras tarefas a realizar durante este período de tempo deveria ser a definição das linguagem(s) de programação/tecnologia(s) que seriam utilizadas na fase de implementação para a aplicação web já que para os outros módulos a tecnologia já se encontrava escolhida. Previa-se, também, que seria realizada, nesta fase, a descrição detalhada da aplicação a desenvolver, nomeadamente em termos das funções/métodos a implementar (variáveis de entrada, variáveis de retorno, objectivo de cada uma, entre outros aspectos). Esta fase implicaria também a elaboração de um diagrama de classes (no caso de ser usada uma linguagem de programação orientada a objectos, naturalmente) e de um diagrama entidade-relacionamento para a novas tabelas que seriam necessárias, visto que se previa a integração de novas funcionalidades na plataforma - ienergy Segundo semestre No segundo semestre o estágio passou a ser regime de tempo inteiro (ou seja, com um esforço previsto de 40 horas semanais.o trabalho foi todo desenvolvido nas instalações da ISA, em Coimbra. Foi feito um planeamento cuidado do trabalho a realizar neste semestre. Como tal recorreu-se ao uso de um diagrama de gantt para distribuir temporalmente todas as tarefas a realizar, diagrama esse que pode ser visualizado na Figura 5. Figura 5 Diagrama de Gantt com o planeamento do trabalho a realizar no segundo semestre Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

40 Plano de Trabalhos ienergy Eficiência Energética em Edifícios Neste semestre previa-se a construção de protótipos fazendo uso das tecnologias analisadas no semestre anterior. Previa-se ainda a implementação dos requisitos especificados no semestre anterior em cada um dos módulos da aplicação. No final do semestre dar-se ia início aos testes da aplicação. Estava previsto que a fase de testes durasse cerca de um mês e meio, de acordo com o diagrama de gantt da Figura 5. Previa-se ainda que a escrita do relatório fosse feita ao longo de todo o semestre, documentando o trabalho à medida que este fosse sendo realizado e que o estágio fosse entregue na época normal, até dia 4 de Julho de Game (Análise, Desenho, Construção, Pré-produçao) Nesta fase foi iniciado o desenvolvimento do produto iterativamente. Na tabela seguinte é apresentado o loop que foi seguido até a conclusão da implementação que constitui cada um dos sprint s com as suas respectivas entradas e saidas. Fases Scrum Entrada Saida Análise Planeamento da Sprint Backlog Priorizado e Estimado Sprint Backlog, Objectivo da Sprint Desenho e Sprint = Iteração Sprint Backlog, Objectivo da Demo da Iteração Construção Sprint Pré- Revisão da Sprint Demo da Iteração Validação de Objectivos Produção Análise Retrospectiva Validação de Objectivos Lista de Impedimentos Tabela 1 - Fases do Game do Projecto Reunião de Planeamento Sprint Cada um dos sprint s que ocorreram durante o estágio iniciaram-se com uma reunião de planeamento. Nesta reunião o product owner (o gestor de energia) apresentou as prioridades dos trabalhos existentes no product backlog. Foram esclarecidas dúvidas sobre o trabalho a desenvolver, por forma a estimar cada um dos desenvolvimentos. No fim da reunião foram apresentados os compromissos para o sprint a iniciar, foi então criado o sprint backlog. Participantes: Equipa Técnica, Scrum Master, Product Owner Sprint Durante este período de desenvolvimento, a equipa focou-se no cumprimento dos objectivos por si definidos para cada sprint. Todos os dias, a equipa efectuou uma reunião (daily scrum meeting). No 18 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

41 ienergy Eficiência Energética em Edifícios Plano de Trabalhos gantt não é possível ver a divisão por sprint s. O gantt do segundo semestre não foi exactamente seguido já que se pretendia entregar partes do software já funcionais que pudessem ser vistas e testadas pelo cliente. O sprint inicial incluiu o estudo da plataforma, estado de arte, especificação dos requisitos e especificação técnica. O último sprint como já foi referido foi apenas dedicada a testes e correcções e preparação para a entrega do software. De cada sprint saiu uma demo que foi entregue ao cliente e a equipa de testes. Participantes: Equipa técnica, Scrum Master e Product Owner Reunião Diária Durante cada sprint foram realizadas reuniões diárias, cuja duração limite era de 15 minutos com todos os elementos da equipa de energia, cada elemento da equipa respondia a três perguntas colocadas pelo scrum master: Que foi feito desde a última reunião? ; Que vais fazer até à próxima reunião? ; Há algo que te impeça de trabalhar o máximo que consegues?. Apenas estas questões deveriam ser respondidas para manter a reunião rápida e objectiva. Deste modo, a equipa ficava sincronizada com o trabalho que estava a ser desenvolvido no âmbito do projecto. Participantes: Equipa e Scrum Master Revisão No final de cada um dos sprints foi feita uma sprint review para verificar se os requisitos tinham sido todos implementados e da maneira que especificada. Participantes: Equipa e scrum master Retrospectiva Nas reuniões de retrospectiva foram apresentadas ao product owner e aos stakeholders todos os produtos do sprint concluídos. Esta apresentação foi feita por mim, numa reunião com duração predefinida (time-boxed). A reunião foi pública, e todos os interessados puderam assistir PosGame (Operacionalização) Nesta fase o desenvolvimento esta concluído e os produtos foram preparados para a publicação final. Esta fase incluiu: Integração, testes (Aceitação, Sistema, Integração), documentação de Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

42 Plano de Trabalhos ienergy Eficiência Energética em Edifícios utilizador, manual de instalação, preparação de treino e de material de marketing. Uma vez concluída toda a fase de desenvolvimento, o sistema foi testado e validado na sua totalidade, corrigindo eventuais falhas. 3.3 Opinião pessoal O scrum foi uma experiencia interessante que permitiu que o projecto fluísse a boa velocidade e que envolvesse toda a gente. Permitiu também a rápida identificação de requisitos que não estavam de acordo com o esperado sendo melhorados nos sprint s seguintes. Verificaram-se alguns atrasos no projecto, sobretudo no início, visto que alguns pormenores do software que se pretendia desenvolver, demoraram algum tempo a estar totalmente definidos, até porque este foi um projecto em que se esteve a trabalhar numa área nova, e que foi começado de raiz com o presente estágio, sob direcção do meu orientador da ISA. E também porque na altura não existia na empresa, ninguém com o conhecimento necessário na área de negócio B2B de energia. Esta metodologia permitiu que quando tudo estava já normalizado, o projecto avançasse a ritmo elevado permitindo assim atingir os objectivos traçados. Ou seja, existiram mudanças de requisitos ao longo da evolução do projecto de software e todos os elementos do projecto tiveram, geralmente, uma palavra a dizer sobre esses mesmos requisitos e sobre a forma de os implementar. O scrum permitiu esta flexibilidade. Sendo que o - ienergy - é uma plataforma complexa que necessita de alguns conhecimentos tanto a nível técnico como a nível de negócio foi decido que devia ser integrado na equipa de energia da ISA. A metodologia scrum permitiu o fácil adaptar ao projecto com ajuda constante da equipa em que estava inserido. Penso que a abordagem flexível do scrum permitiu lidar com todas as vicissitudes e contrariedades que foram aparecendo ao longo do projecto coisa que num modelo rígido não funcionaria. Uma palavra também para equipa que no espírito do scrum foi de uma grande ajuda ao longo do projecto. Fui-se mantendo um contacto permanente entre a equipa, precisamente para esclarecer questões e para descrever e mostrar o trabalho que ia realizando ao longo do tempo, permitindo feedback constante. 20 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

43 ienergy Eficiência Energética em Edifícios Fase de Integração 4 Fase de Integração Na fase inicial do estágio fui inserido num projecto de monitorização energética em embarcações, onde tive oportunidade de me integrar no processo de desenvolvimento da ISA. Tive ainda a possibilidade de aprender as tecnologias utilizadas pela ISA para desenvolvimento das suas plataformas, já que nunca tinha trabalhado com as tecnologias usadas. Esta fase não estava prevista no planeamento inicial do projecto apresentado na secção 3. Esta fase justifica-se pelo atraso no arranque do projecto em que foi efectuado o meu estágio, atraso este devido a questões de negócio que a mim são alheias. Neste projecto tive a responsabilidade de construir relatórios de análise energética em ambiente web, validação de viagens de embarcações, inserção de viagens através do serviço de bilhética, bem como a implementação de alarmes num serviço de GPRS (já construído). 4.1 Eficiência Energética em Embarcações O projecto eficiência energética em embarcações era já um projecto em curso quando começou o meu estágio na ISA, e faz parte também dos projectos de monotorização energética. É um pouco diferente da monotorização energética em edifícios já que neste caso os consumos são de gasolina e não de electricidade ou gás. Este projecto usou a metodologia já mencionada no Capítulo 3, o scrum. O projecto esteve dividido em seis sprint s de quinze dias cada, estando eu apenas alocado nos tês últimas sprint s. Este sistema é inteiramente baseado em tecnologias TCP-IP. Todos os módulos de software a instalar nos diversos locais de interesse assim como a solução embarcada são baseados nessa tecnologia. Existem torniquetes que controlam a entrada de passageiros nas embarcações, que permitem o cálculo de cargas de cada percurso com base na informação estimada de passageiros e combustível. Existem também unidades de GPS que a cada instante guardam a posição, velocidade e outros dados relevantes. Existe também o caldalímetro que permite a monotorização do consumo instantâneo. Faz-se a monotorização do nível do combustível de cada tanque da embarcação e usam-se tags RFID que permitem detectar com exactidão as atracagens dos navios, permitindo a separação dos tempos das viagens. É também possível a detecção da localização da embarcação quando parada. Nesta secção não farei uma descrição exaustiva - já que este projecto sai um pouco do meu projecto de estágio-, mas apenas uma descrição geral. Este sistema perminte a gerir e analisar dados relativos à gestão energética de uma frota de embarcações dotadas de um equipamento de monitorização. Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

44 Fase de Integração ienergy Eficiência Energética em Edifícios Todos os dados recolhidos e armazenados na base de dados podem ser visualizados através deste sistema, que permite agrupar a informação de acordo com um conjunto de critérios, tais como: embarcação, mestre, carreira, data, etc. Além disso, podem ser extraídos vários indicadores relativos à situação energética das embarcações e relacioná-los com os serviços prestados indicadores estes especificados nas secções seguintes. 4.2 Análise de Requisitos Neste projecto fiquei encarregado da área de alarmística do serviço de GPRS e de relatórios. O módulo de alarmística já se encontrava especificado e foi só necessário proceder à sua implementação. No caso dos relatórios existiam protótipos e os requisitos foram recolhidos a partir desses mesmos protótipos e de conversas com o representante do cliente. O Anexo VI contém os requisitos em mais pormenor. 4.3 Requisitos Funcionais inicial. Nesta secção são apresentados os requisitos funcionais do sistema a desenvolver neste projecto Definições Chave Antes de falarmos dos requisitos para este projecto inicial de estágio vão ser introduzidos nesta secção definições importantes relacionadas com o mesmo Tipos de Viagem Os tipos de viagens que existem neste sistema são: Carreira - Viagens regulares de passageiros, com um horário pré-definido. Aquecimento - Período entre o momento em que o navio é ligado e a primeira viagem. Este período caracteriza-se pelo aquecimento dos motores. É iniciado quando os caudalímetros estão a zero e termina com o início de uma viagem. Manobras - O período de manobras está incluído na carreira e está relacionado com os movimentos de aproximação e afastamento dos pontões. É identificado quando a velocidade do navio é maior que zero e o valor das tags RFID são diferentes de zero. Tempo ao Cais - Período em que a embarcação está parada nos pontões. Outras Viagem - Todas as movimentações dos navios não incluídas nos pontos anteriores 22 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

45 ienergy Eficiência Energética em Edifícios Fase de Integração Serviço de Bilhética A bilhética é um serviço externo ligado aos torniquetes de forma a controlar a entrada de passageiros na embarcação. Este serviço guarda dados referentes a cada embarcação como o número passageiros por embarcação/viagem, o início e o fim da mesma e também as docas de partida e de chegada. Este serviço gera um ficheiro com os esses dados para cada uma das viagens realizadas ao logo do dia. No final do dia este ficheiro é enviado para um servidor FTP. Posteriormente o sistema de monitorização lê esse mesmo ficheiro de forma a recolher os dados contidos nele. Através do serviço de bilhética é possível saber o número de passageiros e em conjugação com o caldalímetro é também possível estimar o peso transportado em cada viagem (peso dos passageiros vezes o peso do combustível). Através destes dados é ainda possível calcular outros indicadores que são descritos nas secções seguintes Serviço de GPRS Através do serviço de GPRS é possível saber a velocidade e a distância percorrida em cada viagem. No serviço de GPRS existe ainda um sistema de classificação automática de viagens que através das tags RFID e do GPS permite separa cada tipo de viagem e os seus tempos, estes tempos são também usados no cálculo de indicadores Módulo Associação de Mestres a Viagem Este módulo tem por objectivo a associação de mestres a viagens através da importação de um ficheiro Excel contendo os dados da associação. Os mestres serão associados as viagens previamente inseridas na BD, através do turno e da embarcação. Este ficheiro pode ser importado através da UI, onde pode também ser especificado o dia no qual se inicia a importação do ficheiro Módulo Relatórios Neste módulo pretende-se a disponibilização de um conjunto de relatórios relativos a eficiência das embarcações. Este módulo tem como objectivo permitir a pré-visualização e exportação de relatórios relativos a indicadores gerais das embarcações para um mês ou um ano. Permite a exportação para os seguintes formatos XLS, DOC, PDF Relatórios das Embarcações, com Dados Mensais Este relatório permite ver alguns dados relativos a uma determinada embarcação, deforma a inferir a sua eficiência energética. Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

46 Fase de Integração ienergy Eficiência Energética em Edifícios De seguida é apresentada a forma que cada um destes indicadores é calculado: Consumo Horário (L/h) (caudalímetro) Consumo médio horário de uma embarcação numa viagem do tipo carreira; Consumo Horário (L/h) (Registos) Consumo médio horário de uma embarcação numa viagem do tipo carreira através dos registos de consumos inseridos; Consumo/Carreira (L) (caudalímetro) Consumo médio de uma embarcação por viagem do tipo carreira; Consumo/Carreira (L) (Registos) Consumo médio de uma embarcação por viagem do tipo carreira através dos registos de consumos inseridos; Consumo Total (L) (caudalímetro) Soma dos consumos de uma embarcação; Consumo Total (L) (Registos) Soma dos consumos de uma embarcação dos registos de consumos inseridos; Custo/Km (Euro/km) Custo médio da embarcação por Km percorrido; Distância/Carreira Distância media percorrida por viagem do tipo carreira; Eficiência da Oferta (pkm/l) - Eficiência média da oferta por pkm/l; Eficiência da Procura (pkm/l) Eficiência média da procura por pkm/l; Motores/Carreira (%) Percentagem de utilização dos motores em viagens do tipo carreira (( Tempo viagem tipo carreira - tempo viagem manobras)/( Tempo outras viagens Tempo carreira - Tempo manutenção)); Passageiros/Carreira (nº) - Número médio de passageiros por viagem do tipo carreira; Peso transportado (Kg) Peso médio transportado por viagem do tipo carreira; Tempo/Viagem (min) - Duração média de cada viagem do tipo carreira; Velocidade (nós) - Velocidade média das viagens do tipo carreira; Carreiras realizadas Soma das viagens do tipo carreira realizadas Relatórios do Uso da Embarcação Este Relatório vai estar divido em várias partes, cada uma dessas partes é descrita na secção seguinte. Em qualquer um dos casos, se a embarcação escolhida não possuir caudalímetro os indicadores que são afectados por isso devem conter as iniciais N/A (não aplicável), e caso não existam registos devem conter as iniciais S/D (sem dados). 24 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

47 ienergy Eficiência Energética em Edifícios Fase de Integração Dados Gerais Os indicadores da tabela para cada um dos meses do ano com os dados gerais da embarcação são calculados da seguinte forma: Consumo Horário (L/h) (caudalímetro) Consumo médio horário de uma embarcação numa viagem do tipo carreira; Consumo Horário (L/h) (Registos) Consumo médio horário de uma embarcação numa viagem do tipo carreira através dos registos de consumos inseridos; Consumo/Carreira (L) (caudalímetro) Consumo médio de uma embarcação por viagem do tipo carreira; Consumo/Carreira (L) (Registos) Consumo médio de uma embarcação por viagem do tipo carreira através dos registos de consumos inseridos; Consumo Total (L) (caudalímetro) Soma dos consumos de uma embarcação; Consumo Total (L) (Registos) Soma dos consumos de uma embarcação através dos dados inseridos; Custo/Km (Euro/km) Custo médio da embarcação por Km percorrido; Distância/Carreira Distância média percorrida por viagem do tipo carreira. Eficiência da Oferta (pkm/l) - Eficiência média da oferta por pkm/l; Eficiência da Procura (pkm/l) Eficiência média da procura por pkm/l; Motores/Carreira (%) Percentagem de utilização dos motores em viagens do tipo carreira; Passageiros/Carreira (nº) - Número médio de passageiros por viagem do tipo carreira; Peso transportado (Kg) Peso médio transportado por viagem do tipo carreira; Tempo/Viagem (min) - Duração média de cada viagem do tipo carreira; Velocidade (nós) - Velocidade média das viagens do tipo carreira durante um intervalo de tempo; Carreiras realizadas Número das viagens do tipo carreiras realizadas Percentagem de Gasto de Combustível Os indicadores para a tabela de tempos totais em percentagem gastos em cada um dos tipos de viagens, são calculados da seguinte forma: Outras viagens - Percentagem de tempo total gasto em viagens validas que não são cruzeiro, manobras, tempo em cais ou aquecimento; Aquecimento Percentagem de tempo total gasto em viagens validas do tipo aquecimento; Carreira - Percentagem de tempo total gasto em viagens validas do tipo Carreira; Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

48 Fase de Integração ienergy Eficiência Energética em Edifícios Manobras - Percentagem de tempo total gasto em viagens validas do tipo manobras; Por Validar - Percentagem de tempo total gasto em todas as viagens que ainda não estão validadas; Tempo ao cais - Percentagem de tempo total gasto em cais que ainda não estão validadas, em cada um dos meses do ano; Tempo geral Tempo total em horas gasto para cada uma das viagens acima descritas; Total registos Tempo total de funcionamento calculado a partir dos dados introduzidos Consumos Totais de Combustível Os indicadores da tabela de consumos totais gastos em cada um dos tipos de viagens, são calculados da seguinte forma: Outras viagens Consumo em viagens validas que não sejam viagens de carreira, manobra, tempo em cais ou aquecimento; Aquecimento Consumo em viagens validas do tipo aquecimento; Cruzeiro - Consumo em viagens validas do tipo carreira; Manobras - Consumo em viagens validas do tipo manobras; Por Validar - Consumo médio em viagens que não estão validadas; Tempo ao cais - Consumo médio em cais de viagens validadas; Tempo geral - Consumo total gasto para cada mês do ano; Consumo carreira Vs Velocidade VS peso VS mestre Os indicadores na tabela para cada um dos mestres por área geográfica em relação as carreiras realizadas, velocidade e peso, são calculados da seguinte forma: Consumo - Cálculo do consumo para cada um dos mestres Média Valor médio de consumo do mestre em viagens do tipo carreira para o intervalo de tempo especificado; Desvio padrão Desvio padrão da amostra de consumo de viagens do tipo carreira; Velocidade - Cálculo da velocidade para um mestre; Média Velocidade média do mestre em viagens do tipo carreira; Desvio padrão Desvio padrão da amostra de velocidade de viagens do tipo carreira. Peso - Cálculo do peso carregado por cada mestre nas viagens realizadas Média Media de pesos de viagens do tipo carreira por cada mestre; Desvio padrão Desvio padrão da amostra do peso de viagens do tipo carreira. 26 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

49 ienergy Eficiência Energética em Edifícios Fase de Integração Consumo total Consumo total de combustível em viagens do tipo carreira por cada mestre; Passageiros totais Número total de passageiros em viagens do tipo carreira para cada um dos mestres; Distância total percorrida Distância total percorrida em viagens do tipo carreira por cada um dos mestres; Nº Carreiras Total de viagens do tipo carreira realizadas por cada um dos mestres. Total registos Consumo total calculado a partir dos dados introduzidos Relatórios de Carreiras Estes relatórios são dividos em duas partes. Essas partes são descritas nas secções seguintes Análise de Carreiras Esta parte permite ter uma visão geral de todas as carreiras existentes para uma determinada área geográfica. Os indicadores calculados nesta secção são: Número Carreiras Número total de carreiras para a área geográfica em análise (número de viagens para a área geográfica escolhida). Consumo/Carreira Consumo médio por carreira (média de consumo por viagem do tipo carreira para a área geográfica). Desvio Padrão Desvio padrão da amostra de consumo por carreira. Consumo/Carreira (Registos) Consumo por carreira baseado nos registos inseridos através do ficheiro de consumos (media de consumo por viagem do tipo carreira para a área geográfica de registos inseridos pelo modulo de carregamento de ficheiros com dados sobre o consumo estimado das embarcações). Passageiros/Carreira Média de passageiros por carreira (média de passageiros em viagens do tipo carreira). Desvio Padrão Desvio padrão da amostra de passageiros por carreira Ligação Para cada uma das áreas geográficas existem ligações. Nesta secção são calculados os indicadores para essas ligações. Os indicadores estão divididos entre dias úteis, fim-de-semana e feriados. Para cada uma dessas divisões são calculados os respectivos indicadores: Passageiros/carreira Média de passageiros por carreira (média de passageiros em viagens do tipo carreira). Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

50 Fase de Integração ienergy Eficiência Energética em Edifícios Desvio padrão Diferença entre o valor máximo e mínimo de passageiros por carreira Módulo de Integração com Bilhética para Criação de Viagens Este módulo tem como objectivo permitir a inserção de viagens de embarcações sem caudalímetro (sem equipamentos de monitorização) a partir do serviço de bilhética. Os dados são importados do ficheiro de bilhética. Na inserção das viagens são também inseridos os indicadores possíveis sendo eles a distância estimada e do número de passageiros calculados a partir do ficheiro da bilhética. No fim da importação do ficheiro são também calculados os indicadores estimados de consumo e é feita a sua actualização, estes dados de consumo estimado são inseridos através de um ficheiro Excel preenchido todos os meses e carregado para o sistema quando necessário. O ficheiro de bilhética e enviado para o sistema todos os dias por uma aplicação externa, este tem de ser processado. As viagens criadas neste módulo são apenas as viagens que o serviço de GPRS não consegue criar automaticamente porque algumas das embarcações não têm GPRS. Este módulo lê o ficheiro carregado por FTP e cria viagens apenas para as embarcações que não tem ainda viagem criada. Este móduolo apenas cria viagens para embarcações sem equipamentos de monotorização já que os que tem as viagens são criadas automaticamente pelo serviço de GPRS Módulo de Criação de Alertas Este módulo tem como objectivo permitir a criação de alarmes pelos serviços (GPRS e Bilhética). No serviço de bilhética são gerados alarmes por falta de ficheiros de bilhética: O serviço de Bilhética processa ficheiros de bilhética a uma determinada hora. Se os ficheiros não existirem é inserido um novo alarme com uma mensagem que diz que o ficheiro não foi processado. Os alarmes lançados são para a inexistência dos ficheiros de bilhética. Os ficheiros devem estar na pasta configurada no app.config nos formatos T sendo que neste exemplo os ficheiros são para a data ou seja, se no dia estes ficheiros não existirem, é registado um alarme. O serviço de GPRS gera alarmes para: Falha de comunicação Não existe comunicação com o GPS durante um espaço de tempo; Falha de GPS Existe comunicação mas ouve falha na comunicação dos dados; Falha de caudalímetro Quando existe velocidade superior a tolerância mas não existem dados do caudalímetro; 28 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

51 ienergy Eficiência Energética em Edifícios Fase de Integração Falha de nível de combustível - O consumo é 0 mas percorreu uma distância superior a tolerância; Motores/Carreira menor que 30 Calcula os motores/carreira para um intervalo de tempo em dias e verifica se é menor que 30; Aquecimento No caso de viagens do tipo aquecimento os seguintes valores são considerados: Consumo/Viagem (aquecimento) inferior a 5 e superior a 60; Tempo/Viagem (aquecimento) maiores que 50 minutos; Velocidade instantânea superior a 2 nós (ou outro valor a definir) Módulo de Validação de Viagens Este módulo tem como objectivo validar as viagens (comerciais) criadas pelo serviço de GPRS, de acordo com os parâmetros definidos, sendo eles: Consumo/Viagem inferior a 20 e superior a 220 Distância/Carreira superior a metros Tempo/Viagem menor que 6 e maiores que 35 minutos Velocidade instantânea superior ou igual a 25 nós No portal foi incluída informação sobre o motivo pelo qual a viagem se encontra por validar, quando a viagem é editada. 4.4 Implementação Neste projecto a implementação estava já toda delineada. A implementação de cada um dos módulos seguiu sempre o que já tinha sido decidido pela equipa de desenvolvimento antes da minha entrada no projecto e segundo as ferramentas que tinham sido escolhidas Ferramentas de Desenvolvimento Para o desenvolvimento das plataformas foi usado o C#, Linq, Linq To SQL, ASP.NET Web Forms esta eram já as tecnologias usadas no projecto em que foi inserido IDE Durante o desenvolvimento foi usado o IDE Microsoft Visual Studio 2010 porque era o que se adequava mais as tecnologias em causa. Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

52 Fase de Integração ienergy Eficiência Energética em Edifícios Base de Dados Como sistema de gestão de base de dados foi usado o Microsoft SQL Server 2008 RC Ferramenta de Relatórios Para a construção dos relatórios foi usada a ferramenta Report Viewer da Microsoft. Esta escolha foi feita por mim depois de analisar outras alternativas gratuitas para aquilo que se pretendia fazer. O Report Viewer foi a ferramenta usada por ser uma ferramenta de relatórios que permitia fazer tudo o que se pretendia, tendo como principal vantagem poder ser feita uma previsualização do relatório de maneira fácil. 4.5 Verificação e Validação O software foi testado pela equipa de testes da ISA. Neste projecto não foram feitos testes unitários por opção da equipa. Os bugs reportados pela equipa de testes em cada um dos sprint s foram corrigidos e foi feita nova publicação do software. Todos os requisitos foram validados pelo representante do cliente, sendo que depois desta validação o sistema foi colocado em produção. 4.6 Resultados Obtidos Nesta Fase Com a integração neste projecto pudesse fazer um estudo mais aprofundado das tecnologias Microsoft usadas na ISA o que permitiu obter bons resultados na implementação do projecto de estágio. Com esta integração inicial pode-se dizer que se teve também o primeiro contacto sério com o scrum, já que a equipa de energia que estava encarregue do desenvolvimento deste projecto, trabalhou todos os dias para incutir os valores e características do scrum. Todos os dias pelas nove horas fazia-se a daily scrum que serviu para solucionar alguns problemas que se tinham em relação as tarefas. Alguns dos conceitos que se a aprenderam nesta fase ligos a eficiência energética também se mostraram importantes para a entrada inicial no projecto de estágio. 30 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

53 ienergy Eficiência Energética em Edifícios Revisão Tecnológica 5 Revisão Tecnológica Neste capítulo é inicialmente feita uma breve descrição do estado da arte no campo do software de gestão energética, após a qual é realizada uma análise crítica das várias soluções existentes ou semelhantes. De seguida faz-se uma análise de tecnologias consideradas para o projecto. Por último faz-se uma análise crítica das tecnologias que foram consideradas para serem utilizadas no desenvolvimento da aplicação e da base de dados. 5.1 Estado da Arte A gestão de energia em edifícios com recurso a soluções de software e hardware, é relativamente recente, e começa a ser cada vez a ser mais utilizada. Este tipo de soluções oferece enormes vantagens ao gestor de energia, já que lhe dá os dados tratados e organizados de forma a facilitar a sua árdua tarefa de identificar melhorias na gestão de energia. Actualmente existem vários sistemas de gestão de energia comerciais, mas essas soluções continuam a apresentar falhas quer ao nível das funcionalidades que oferecem quer ao nível da organização do sistema, sendo aplicações bastante complexas e confusas onde por exemplo a organização lógica dos dispositivos não é a mais fácil de perceber e em muitos deles nem sequer existe. Existem ainda dificuldades em encontrar soluções completas que tanto ofereçam o software como o hardware, já que a integração destes dois sistemas pode trazer complicações que numa solução construída e integrada de raiz, não existem. Uma grande diferença entre o software que se pretende construir neste projecto e as soluções oferecidas pela concorrência é mesmo essa: a solução do presente estágio é completa e inclui o hardware e o software; pretende ainda incluir funcionalidades que suportem melhor o mercado industrial como o cálculo de tarifários industriais, simulação de tarifários, actuação agendada sobre equipamentos a inclusão de indicadores de performance e de alertas que permitam que o gestor de energia seja avisado de consumos anormais por forma a intervir o mais rápido possível. Todas estas funcionalidades associadas a uma organização lógica dos dispositivos de medição, pretende oferecer uma solução completa e mais do que isso fácil de usar. De referir que muitos dos competidores aqui em estudo oferecem aplicações web, mas estas não permitem por exemplo gerir de forma centralizada vários edifícios como a solução aqui proposta Soluções Existentes ou Semelhantes Existem já no mercado algumas soluções parecidas com o software que se pretende implementar neste estágio. Este tipo de solução é relativamente recente sendo que nos Estados Unidos já têm algumas soluções integradas com a Energy Star esta integração permite a comparação dos gastos com Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

54 Revisão Tecnológica ienergy Eficiência Energética em Edifícios edifícios semelhantes permitindo saber se determinado edifício está dentro dos parâmetros de consumo para aquele tipo. Como pode ser visto no Anexo I, todas as soluções oferecem um grande número de funcionalidade como a visualização de consumos em tempo real, aplicação de tarifários entre outras. Mas poucas possuem a solução com todas as funcionalidades essenciais. Na figura 6 estão algumas empresas competidoras. A imagem mostra o número de funcionalidades oferecidas por cada uma destas competidoras. Figura 6 -Número de funcionalidades dos competidores Como podemos ver existem seis grandes competidoras já com muitas funcionalidades implementadas. Na Tabela 2 podemos ver um comparativo das principais funcionalidades oferecidas por cada um desses competidores com as funcionalidades pretendidas para o software da ISA. Tempo real Comparativos Relatórios Gráficos de histórico Alertas Exportação de dados Tarifários Simulação de Tarifários Actuação Indicadores ISA - X X X X X X X X X Pulse Energy X - X X X X Enigin X - X X X X X PlusEnergy - - X X - X X X Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

55 ienergy Eficiência Energética em Edifícios Revisão Tecnológica Raritan X X AgileWaves X - X X X Johnson Controls X X X X X X X X - - Tabela 2 - Quadro parcial de funcionalidades da concorrência Com esta tabela podemos concluir que a ISA, exceptuando a funcionalidade tempo real que não está prevista para este software, pretende inplementar todas as restantes funcionalidades. De referir que algumas funcionalidades, apesar de estarem marcadas como presentes, em algumas das empresas apresentam-se apenas parcialmente implementadas. O Anexo I contém mais informações sobre cada uma destas empresas Resumo Crítico Após a realização desta análise de soluções existentes no mercado actualmente, verifica-se a necessidade e interesse existente na continuação do desenvolvimento e estudo de novas soluções, que preencham as lacunas existentes e melhor satisfaçam as necessidades dos utilizadores. A análise efectuada tentou de certa forma cobrir exemplos das várias partes relacionadas com o sistema proposto, ou seja, aplicações de gestão de energia, para edifícios industriais, verificando ao mesmo tempo soluções livres e comerciais. O principal ponto fraco destas soluções é não oferecerem a solução completa, e algumas tem um interface pouco agradável ao utilizador. Tirando a Scheneider Eletric e a Johnson Controls nenhuma das outras empresas oferece o hardware necessário para o funcionamento do sistema tendo sempre que se adquirir o hardware à parte. Das funcionalidades que estas empresas oferecem, de destacar, em relação aos tarifários, a pouca flexibilidade, suportando apenas parcialmente os tarifários usados em Portugal. De destacar que estas empresas já oferecem visualização de consumos em tempo real, funcionalidade em que a equipa de energia da ISA se encontra a trabalhar neste momento mas que sai fora do âmbito deste estágio. Nenhum dos competidores aqui em estudo apresenta actuação sobre os dispositivos bem como o cálculo de indicadores de poupança, estado e performance, mas poderão eventualmente existir outros competidores não presentes nestes estudos que implementem essas funcionalidades. Todas estas soluções comerciais existentes no mercado actual têm maior foco em gestão de locais sem estrutura hierárquica o que dificulta a análise dos edifícios já que estes têm várias divisões e andares. E são também bastante dispendiosas em termos de custos: é por isso que uma versão do software mais de acordo com as possibilidades económicas de um país como Portugal seria bastante Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

56 Revisão Tecnológica ienergy Eficiência Energética em Edifícios apetecível. De destacar ainda que muitas destas empresas não oferecem uma solução centralizada que pode ser consultada de qualquer lado a qualquer hora, muitas delas tendo apenas acesso local á aplicação. Uma aplicação web com acesso de qualquer lugar, que permita a gestão centralizada de um grupo alargado de edifícios, é uma das vantagens do software implementado. 5.2 Tecnologias consideradas Nesta secção é feito um levantamento das várias alternativas que foram apreciadas em relação às tecnologias a usar no desenvolvimento. Um ponto importante a considerar na análise das tecnologias é o grupo a que pertencem, i.e., se são comerciais, livres ou código aberto. Será dada preferência à utilização de tecnologias código aberto, excepto se for mais indicado utilizar outra ou se houver outro tipo de restrições internas da empresa Análise de Tecnologias da Concorrência Para além de uma análise à concorrência ao nível das funcionalidades oferecidas, foi também feita uma análise às tecnologias utilizadas. Como podemos ver pela Figura 7, apenas uma solução é totalmente código aberto sendo que todas as outras ou são 100% código fechado ou usam ambas as tecnologias. Figura 7 - Tipo de tecnologias usadas pelos competidores 34 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

57 ienergy Eficiência Energética em Edifícios Revisão Tecnológica Na Figura 8 podemos analisar o uso de cada tipo de tecnologias pelo número de funcionalidades. As empresas com mais funcionalidades são aquelas com maior valor no eixo dos X por sua vez as que usam mais tecnologias código aberto são aquelas com mais valor no eixo dos Y. Conseguimos ver que existe algum equilíbrio no uso de tecnologias de código fechado e código aberto mesmo para os casos mais complexos (mais funcionalidades) existem empresas a usar muito código aberto. De realçar que as empresas com mais funcionalidades apenas a Johnson Controls usa somente tecnologias de código fechado. Figura 8: Relação entre a complexidade (número de funcionalidades) e o tipo de tecnologias De realçar que praticamente todas disponibilizam um interface web para o utilizador final. O uso de restrito a tecnologias código fechado pode encarecer a solução coisa que não se pretende para este projecto Análise de Tecnologias para o Sistema Nesta secção são apresentadas todas as tecnologias que foram consideradas para serem usadas na construção do projecto de estágio. De salientar que estas tecnologias tiveram bastantes restrições a nível de negocio e ao nível das tecnologias já usadas na plataforma - ienergy -. Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

58 Revisão Tecnológica ienergy Eficiência Energética em Edifícios Base de Dados A base de dados já se encontrava implementada sobre uma BD Sql Server 2008 RC2, portanto não foi objecto de estudo Plataforma Web A plataforma web foi restringida a tecnologias Microsoft pelo que o estudo apenas incidiu sobre essas mesmas tecnologias e também em tecnologias que pudessem ser usadas em conjunto com as tecnologias Microsoft. Neste caso a escolha esteve entre duas das tecnologias web da Microsoft, referentes ao ASP.NET, o modelo tradicional Web Forms e o padrão MVC. Desde o seu lançamento, a plataforma.net até as versões 3.5 tinha sido exclusivamente baseado no modelo Web Forms. Desde a versão 3.5 deu-se a mudança. O clássico tem vindo a ser deixado para trás em detrimento do novo padrão MVC. O ASP.NET possui uma série de características que o tornam simples de utilizar, mas não menos robusto. A quantidade de controlos ricos que o mesmo fornece é extremamente grande. Mesmo com essa facilidade e toda sua extensibilidade (como é caso dos Control Adapters), muitos programadores sentem a necessidade de ter um maior controlo sobre como o conteúdo que é renderizado para o cliente e como os dados que o cliente submete são enviados para a aplicação. Devido à estrutura do ASP.NET e seus controlos intrínsecos, a renderização final acaba por ser delegada para o RUNTIME do ASP.NET e é neste momento que programadores sentem a necessidade de uma maior flexibilidade. O padrão MVC(Model-View-Controller) garante isso. Este padrão não nasceu agora, já existe em vários frameworks que podem ser acopladas ao ASP.NET e permitem desenvolver aplicações baseadas neste modelo. O que acontece neste momento é uma implementação deste padrão pela própria Microsoft, integrando fortemente a infra-estrutura do ASP.NET. Vantagens do Web Forms Requer poucos conhecimentos de HTML; Oferece componentes ricos; Oferece desenvolvimento rápido de aplicações. Vantagens do MVC O MVC obriga a um melhor desenho do código possibilitando a melhor separação de responsabilizadas; Possibilita o controlo total sobre o HTML renderisado para a vista; O Web Forms é difícil de testar o MVC foi desenhado com a facilidade de teste em mente Test Driven Development (TDD); 36 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

59 ienergy Eficiência Energética em Edifícios Revisão Tecnológica Integração fácil com Frameworks JavaScript nomeadamente o JQuery; Suporta motores de vista de terceiros NVelocity, Brail, NHaml entre outros; Não existe ViewState e eventos PostBack; Segue a natureza sem estado da Web; Ideal para aplicações Web Web Service Já existia um web service implementado em SOAP sobre o WCF. Este web service foi mantido sendo criado nele um novo end point para suportar a plataforma web desenvolvida, sendo que este end point foi construído de raiz Core O core já se encontrava implementado com recurso a ADO. Entity Framework, todos os desenvolvimentos feitos durante este estágio mantiveram a tecnologia usada e os princípios pelos quais o core da aplicação foi desenvolvido Ferramentas de Construção de Relatórios Nesta secção é apresentado de forma resumida as ferramentas estudadas para construção de relatórios, este estudo foi restrito a ferramentas gratuitas e compatíveis com as tecnologias web da Microsoft Report Viewer O Report Viewer é uma ferramenta da Microsoft, integrada no Visual Studio.NET e permite a geração de relatórios. Os relatórios são implementados de maneira simples e possuem algumas funcionalidades interessantes como a previsualização e a exportação para serem abertos em outras aplicações NPOI O NPOI é uma versão do POI originalmente construído para Java. O POI é um projecto código aberto que permite ajudar a ler/escrever ficheiros XLS, DOC, PTT. Actualmente o NPOI apenas suporta ficheiros no formato Excel Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

60 Revisão Tecnológica ienergy Eficiência Energética em Edifícios Vantagens do Report Viewer em relação ao NPOI Acesso aos vários componentes suportados pelo Report Viewer, ToolBar (Paginação, zoom, exportação, Impressão), suporte Ajax, tabelas, matrizes, etc; Exportação para vários formatos incluindo PDF; Simples de usar após aprender como funciona; Fácil adaptação a mudanças nos requisitos dos relatórios (as mudanças não implicaram mudanças drásticas de código); Boa documentação de apoio Desvantagens do Report Viewer em relação ao NPOI É difícil atribuir uma formatação diferente ao relatório daquela que esta definida nos ficheiros (.RDLC) aquando da exportação; A inexistência de um DataSet implica a edição do (.RDLC) através do XML. A curva de aprendizagem poderá ser elevada no início Ferramentas Web de Gráficos Tal como as ferramentas de relatórios as ferramentas de construção de gráficos foram também limitadas a ferramentas gratuitas. De entre todas a ferramentas gratuitas estudadas de destacar as que são apresentadas na Tabela 3. Zoo Panning Múltipl Diferentes Mostrar Possibilidad Custo m os eixos tipos de detalhes de e de s gráficos pontos exportação para Excel Flot X X X X X - 0 Flotr X X - X X X 0 JqPlot X X X X X - 0.Net Chart Control - - X X X X 0 Tabela 3 - Comparação de ferramentas web de construção de gráficos 38 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

61 ienergy Eficiência Energética em Edifícios Revisão Tecnológica Protótipos Construídos Foram construídos dois protótipos com as tecnologias de gráficos, estes dois protótipos foram feitos usando as tecnologias que mais se enquadravam no que se pretendia. Tecnologias gratuitas que permitissem gerar gráficos ricos visualmente e em que o utilizador pudesse interagir facilmente (zoom, detalhes de pontos do gráfico etc). Os protótipos foram construídos usando uma base de dados de produção do - ienergy - por forma a validar que estes componentes responderiam em tempo útil a uma situação real Condições de Teste Para efectuar os testes retratados neste documento foram utilizados dois nós: um servidor Windows e um cliente em máquina Windows Servidor CPU: Intel Core2 Duo a 2,40GHz Memória: 4GB Cliente CPU: Intel Core2 Duo a 2,40GHz Memória: 2GB Medidas Extraídas Neste estudo foi apenas usada uma medida de performance o tempo de renderização dos componentes de dois Frameworks diferentes. Não é de prever que estejam muitos utilizadores a usar a aplicação ao mesmo tempo nesta fase, portanto estes protótipos apenas validaram a performance em relação ao tempo de espera até o gráfico ser renderisado. Outros indicadores que poderiam interessar seriam a percentagem de CPU utilizada pelo processo, memória utilizada, número de threads, page faults/s entre outros Performance Os dois componentes usados para o estudo de performance foram o Jqplot e o.net Chart Control os outros controlos foram excluídos devido ao tempo que seria necessário para criar um protótipo com todos eles e porque tanto o flot como o flotr são todos frameworks de gráficos JavaScript que apresentam praticamente as mesmas funcionalidades e em princípio desempenhos muitos semelhantes. Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

62 Revisão Tecnológica ienergy Eficiência Energética em Edifícios Agregados horários de 1 mês (744 horas) Agregados horários de 3 mêses (2232 horas) Agregados horários de 6 mêses (4464 horas) Agregados horários de 9 mêses (6696 horas) Agregados horários de 1 Ano (8760 horas) JqPlot 1s 2s 10s 24s 30s.Net Chart 1s 2s 10s 20s 29s Control Tabela 4 - Tempo de renderização de gráficos Conclusão O tempo de resposta começou a degradar-se a partir dos seis meses em agregação horária o que equivale a muitos dados. Não é previsível que o utilizador queira chegar a estes valores de agregação já que o gráfico se tornaria praticamente elegível. O.Net Chart mostrou-se mais rápido apesar de não existirem diferenças significativas. Estas diferenças devem-se em tudo a forma como os dados são renderizados nos dois componentes. O jqplot renderiza um elemento HTML5 chamado Canvas que permite renderização dinâmica através de scripts de bitmaps 2D, já o componente Net Chart renderiza uma imagem estática. Poderá estar aqui a diferença para os valores apresentados na tabela Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

63 ienergy Eficiência Energética em Edifícios Especificação 6 Especificação Este capítulo tem como objectivo apresentar a especificação da solução proposta. É efectuada uma análise, primeiramente em geral e depois em detalhe, sobre os requisitos do sistema total, com todas as características que os mesmos deverão ter no final do projecto. Os requisitos encontram-se agrupados em subsecções, de acordo com as suas especificidades. Na subsecção dos requisitos funcionais são apresentados os casos de uso do sistema, na subsecção de requisitos não funcionais são apresentados os requisitos de qualidade, performance e segurança. Como será dada mais importância à parte do sistema a desenvolver durante o estágio, será esta parte que estará mais em foco. Para cada requisito em particular será atribuída uma prioridade em relação à sua importância no desenvolvimento do sistema, dada pelo cliente como já foi explicado na secção 3. Essa prioridade será Must Have, Shoud Have ou Nice to Have. Um requisito com prioridade Must Have significa que no final do projecto terá de se encontrar completo e funcional. Se um requisito tiver prioridade Shoud Have terá de existir, mas poderá ainda não estar totalmente completo, e se a prioridade for Nice to Have significa que só será implementado se houver tempo, sendo algo adicional que não é fundamental no sistema para esta fase, mas que lhe acrescenta valor. Contudo, é necessário salientar que para alguns requisitos considerados com prioridade Must Have, devido à sua complexidade, o seu desenvolvimento será gradual durante o desenvolvimento do projecto (continuando mesmo após o estágio). Este estágio prevê o desenvolvimento de uma aplicação web de raiz, a integrar na plataforma - ienergy - já existente, através de um web service. Este web service vai fazer uso de algumas funcionalidades já existentes bem como incluir outras novas. 6.1 Visão Geral Uma aplicação de gestão de energia para edifícios, permite reconhecer e identificar desperdícios a partir dos dados recolhidos pelos sensores instalados nas várias divisões. Estes sensores permitem medir os consumos de uma divisão, de um edifício inteiro ou até mesmo de um sistema de AVAC, sendo que estes sistemas são a principal fonte de desperdícios nos edifícios, principalmente por falta de zelo na sua utilização. Um sistema de gestão de energia permite ver estes consumos de forma isolada ou em conjunto, sendo assim possível identificar onde estão as fontes de desperdício. Os dados são recolhidos, tratados e armazenado no sistema de forma a posteriormente serem apresentados ao utilizador na forma de relatórios, gráficos, indicadores ou mesmo alarmes. Os dispositivos são organizados em grupos lógicos para serem facilmente reconhecidos e manipuláveis pelo utilizador, estes grupos podem representar um edifício e os seus vários pisos e Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

64 Especificação ienergy Eficiência Energética em Edifícios divisões. O utilizador pode seleccionar esses edifícios e ver o consumo de um piso, ou de vários pisos de forma a compará-los em termos de consumos e de custos. Estes dados podem ser posteriormente exportados para Excel para posterior análise. Um dos problemas actuais deste tipo de software de análise é a falta de liberdade que o utilizador tem para analisar os consumos, quer por falta possibilidades de escolha dos períodos em análise e de agregação dos dados, quer pela falta de organização lógica dos vários sensores. Nesta aplicação todos os dados são apresentados através de uma aplicação web por via online, em oposição a algumas das soluções já existentes, que em muitos dos casos são aplicações web usadas em modo offline. Este sistema permite a consulta centralizada através da internet dos vários edifícios a serem monitorizados. O sistema deverá incluir uma forte componente financeira de forma a ser possível analisar os consumos em termos de custos, sendo esta uma funcionalidade decisiva no sucesso da aplicação. Também deverão existir alarmes para consumos fora de um certo padrão, já que é previsível que existam muitos edifícios no sistema e não seria fácil percorrê-los a todos manualmente, procurando desvios no padrão de consumo. Deste modo o gestor de energia pode configurar alarmes que serão disparados quando ocorrerem consumos anormais, facilitando muito o seu trabalho. Por fim existirá uma componente de actuação sobre os equipamentos instalados no edifício: por exemplo, é detectado que os reclames luminosos de um determinado edifício se encontram acesos mesmo quando ainda é de dia; nesse caso o gestor de energia pode criar um agendamento semanal para ligar ou desligar esses equipamentos a horas fixas. O sistema será estruturado em vários módulos, permitindo um estudo mais detalhado e rigoroso. Deles fazem parte, num primeiro nível, a aplicação web, em seguida o web Service e o - ienergy -, e por fim o armazenamento (base de dados). 6.2 Características dos Utilizadores Para este sistema foram identificados três actores, de acordo com o que foi dito na secção 2.2. O acesso ao software é feito por login e password. Isto permite ter contas diferentes para cada utilizador e perfis diferentes de utilizador. Cada perfil acede a determinadas funcionalidades do software. Os diferentes perfis de utilizador são: Cliente: Tem acesso à plataforma apenas para ver indicadores (não os pode alterar) e extrair relatórios predefinidos (não os pode alterar) dos projectos a que está alocado. Este utilizador apenas tem acesso aos grupos lógicos aos quais tem permissões para aceder. Gestor de energia: Acesso total à plataforma não podendo no entanto gerir utilizadores nem permissões nos grupos lógicos. 42 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

65 ienergy Eficiência Energética em Edifícios Especificação Administrador: Acesso total à plataforma. Pode ser vista de seguida a hierarquia entre eles no seguinte diagrama (Figura 9): uc Actors Cliente Gestor de energia Administrador Figura 9 - Hierarquia de Utilizadores 6.3 Análise de Requisitos Nesta secção é descrita a fase de estudo e recolha de requisitos que coincide com o Pre-Game do scrum que consistiu na aquisição dos requisitos funcionais e não funcionas para a plataforma Metodologia Usada na Recolha de Requisitos Durante a fase de análise de requisitos foram usadas várias técnicas para recolha e análise dos mesmos, sendo de destacar nesta etapa o grande envolvimento do cliente neste processo. Este envolvimento só foi possível por se tratar de um cliente interno à empresa, representante de uma área da própria empresa, que esteve sempre pronto a esclarecer as dúvidas que iam surgindo durante esta fase e até mesmo já na fase de desenvolvimento. Este envolvimento de alguém com conhecimento do negócio foi decisivo no meu entender para o sucesso da aplicação. Foram feitas algumas sessões de brainstorming com o cliente da aplicação e com pessoas da área de negócio da ISA. Estas sessões tiveram por intenção alargar as fronteiras do espaço do problema dos participantes e obter soluções não convencionais para alguns dos requisitos abordados. Depois destas Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

66 Especificação ienergy Eficiência Energética em Edifícios reuniões de brainstorming foi feita uma prototipagem através de interfaces de utilizador de forma a serem validados pelo cliente da aplicação. Durante a análise de requisitos, a prototipagem deu forma concreta aos requisitos e assistiu à sua clarificação e determinação. Foram também elaboradas um conjunto de questões para servirem como esclarecimento de dúvidas. Estas questões foram enviadas para o cliente usado a ferramenta Google Docs e respondidas nessa mesma ferramenta (um exemplo na Figura 10). Em muitas situações esta interacção através da ferramenta Google Docs não se mostrou eficaz e tiveram mesmo de ser feitas reuniões para entender melhor certos requisitos. Figura 10 - Exemplo de perguntas colocadas no Google Docs Depois da primeira Release do software, e devido a algumas queixas de usabilidade da aplicação, foram feitas algumas observações de comportamento com os utilizadores no seu ambiente natural de trabalho, enquanto executavam tarefas específicas no software, o que permitiu detectar várias melhorias a incorporar nas versões seguintes da aplicação. Segundo a metodologia adoptada estes requisitos são elementos do product backlog e estão na forma de user stories. Todos os requisitos presentes nesta secção são requisitos finais. No entanto, muitos destes requisitos sofreram alterações de um sprint para o outro porque foram identificadas melhorias principalmente a nível de interface. 6.4 Requisitos funcionais Os requisitos foram aprovados e priorizados pelo cliente (o gestor de energia da ISA) em todas as sprint s do projecto, primeiro através do product backlog e posteriormente através do sprint backlog. 44 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

67 ienergy Eficiência Energética em Edifícios Especificação O desenvolvimento divide-se em várias partes e inclui a integração de todas elas, podendo ser usados módulos já existentes, na sua totalidade, parcialmente ou mesmo como base para o desenvolvimento de cada um. Por exemplo, para visualizar custos de energia de um edifício, é necessário o cálculo dos custos tendo em conta o tarifário em vigor, pelo que é fundamental utilizar o módulo de cálculo de tarifários, e logo de seguida o módulo de visualização de dados. Tentou-se fazer uma divisão bem estruturada dos vários módulos com vista a uma leitura fácil de todas as funcionalidades do sistema e permitir uma maior facilidade na implementação e integração das várias partes. Essa estruturação pode ser observada no diagrama de casos de uso do sistema completo, na Figura 11, no qual as funcionalidades estão estruturadas por pacotes devido à quantidade de casos de uso existentes. Esses pacotes representam os módulos do sistema, fazendo todos eles parte da aplicação web e da plataforma - ienergy -. Estão representados também dois actores de sistema, o do módulo da aplicação de cálculo de tarifários do módulo de verificação de actuações e de alertas. Encontram-se representados dessa forma simplificada uma vez que podem ser vistos como externos ao sistema. uc Primary Use Cases Sistema de gestão de energia Visualização de dados(alertas, actuação,grupos, indicadores, tarifários) Análise de dados Gestão de tarifários Cliente Visualização de ralatórios Simulação de tarifários Gestor de energia Gestão de grupos Cálculo de tarifário Verificação de actuações Gestão de alertas Administrador Gestão de Indicadores Verificação de alertas Sistema Cálculo da baseline Gestão de virtual tags Gestão da baseline Gestão de actuação Figura 11 - Casos de uso do sistema separados por pacotes Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

68 Especificação ienergy Eficiência Energética em Edifícios O sistema deverá possuir as funcionalidades apresentadas na Tabela 5. No entanto, uma vez que o sistema global é constituído por vários módulos, para melhor se poder estudar os requisitos de cada um e de uma forma mais detalhada, estes irão ser abordados de seguida em várias subsecções. Os requisitos aqui apresentados serão portanto detalhados nas subsecções que se seguem. Para maior detalhe os diagramas de casos de uso de cada pacote/módulo e actor de sistema podem ser consultado no Anexo II. Requisitos por módulos Prioridade Visualizar dados agregados em forma de gráficos e tabelas Must Have Efectuar a gestão de actuações Shoud Have Efectuar a gestão de alertas Shoud Have Efectuar a gestão de grupos Shoud Have Efectuar a gestão de tags virtuais Must Have Efectuar a gestão de indicadores Shoud Have Cálculo de KPIs Shoud Have Permitir a geração de relatórios predefinidos Must Have Efectuar a gestão de tarifários na plataforma. Shoud Have Simular tarifários Shoud Have Reconhecer consumos fora dos parâmetros configurados e lançar alertas. Must Have Calcular os tarifários de energia. Must Have Tabela 5 - Tabela de requisitos do sistema Módulo de Grupos Lógicos Os grupos lógicos não são mais do que a organização lógica de tags, unidades ou utilizadores, de forma hierárquica, dependendo do que o utilizador pretender agrupar (por exemplo agrupar os sensores de energia, humidade e temperatura de um piso), permitido assim identificar edifícios e os seus subgrupos, que podem ou não estar separados geograficamente. A estes grupos podem também ser associadas tags virtuais ou indicadores: por exemplo, uma tag virtual pode ser definida como a soma de todas as tags de energia activa de um grupo. Desta forma obtemos o consumo total do grupo. O indicador é um conceito semelhante mas depende de outros valores constantes para além dos valores dados pela tag, tais como os valores da baseline ou dos detalhes dos grupos. Por exemplo, pode-se criar um indicador que é a soma dos kwh de todas as tags de um piso (virtual tag) e dividir esse valor pelo número de pessoas que ocupam o espaço. Esta métrica vai dar o consumo de energia por pessoa, sendo que o número de pessoas é uma constante que nada tem a ver com o valor da tag. Quando essa 46 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

69 ienergy Eficiência Energética em Edifícios Especificação constante é usada numa operação aritmética com uma tag, é chamado indicador. Sendo estes os indicadores de estado, existem outros indicadores que medem a performace de determinado grupo lógico de forma a sabermos se determinado grupo está ou não dentro de determinados valores de eficiência energética Criação de grupos lógicos Um grupo, como já foi referido anteriormente, serve para agrupar logicamente as vários entidades principais que constituem o sistema. Requisito Descrição Prioridade CGL1 Deve ser possível criar, editar e apagar grupos lógicos. Must Have CGL2 Deve ser possível associar tags, utilizadores, dispositivos a Must Have grupos lógicos. CGL3 Deve ser possível criar uma hierarquia de grupos lógicos. Must Have CGL4 Só utilizadores adicionados ao grupo lógico podem ver a Must Have informação associada a estes grupos não podem ver mais nenhum grupo lógico que não seja seu. Os utilizadores administradores e os gestores de energia podem ver todos os grupos e toda a informação associada a eles. CGL4 Cada grupo deve ter um tipo associado, cada um desses tipos tem um conjunto de parâmetros associados: Projecto: O Projecto é o tronco da árvore e tem de ser configurado antes de se poder configurar a árvore do projecto. Grupos gerais: Os grupos gerais são os ramos do projecto que servem para organizar e ordenar as instalações do projecto. Instalações: As instalações dos projectos são os nós principais da árvore e têm de ser configuradas antes de se poder configurar os pisos, os grupos particulares, e as folhas. Na fase de configuração das instalações, é especificado o nº de pisos. Piso: A cada Instalação corresponde um ou mais pisos. Grupos particulares: Os grupos particulares funcionam como os grupos gerais mas dizem respeito apenas a um piso de uma instalação em vez de dizerem respeito a um projecto. Folha: As folhas são os nós finais da árvore. Dizem respeito Shoud have Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

70 Especificação ienergy Eficiência Energética em Edifícios CGL6 CGL7 CGL8 a um piso que, por sua vez, diz respeito a uma instalação que, por sua vez, diz respeito a um projecto. Cada um destes tipos de grupos tem um conjunto de parâmetros associados. Estes devem ser dinamicamente criados pelo utilizador podendo estar identificados de forma diferente da especificada anteriormente. Cada grupo pode ter associado vários tipos de horários, horário de funcionamento, manutenção etc. Cada um destes horários tem uma hora de início e de fim e um dia da semana associado. Os grupos lógicos podem ter associada uma baseline do respectivo grupo, os dados dessa base line são: Consumo de energia activa para cada um dos meses do ano separado por tipos de( horas de ponta horas de cheia, horas de vazio e horas de super vazio).ao ano 0 corresponde o ano civil anterior ao ano de configuração da instalação. Consumo de energia do sistema AVAC. Consumo de energia de cada um dos utensílios existentes no grupo lógico (maquina de café etc) Depois de configurada a baseline, ela fica guardada no sistema. A baseline para o ano zero é fixa sendo que para os anos posteriores podem ser introduzidas actualizações a baseline, como novos dispositivos ou mudanças no no sistema de AVAC. Com estas actualizações o sistema calcula a nova baseline tendo em conta as alterações que existiram no edifício. Deve ser possível inserir informações associadas aos grupos que serão posteriormente usados para calcular indicadores de estado. Área total sujeita a climatização e/ou iluminação permanente (m2) Nº de funcionários permanentes Nº de utensílios Must Have Must Have Must Have 48 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

71 ienergy Eficiência Energética em Edifícios Especificação CGL9 CGL10 Nº de PC s Para o nº de utensílios, é aberto um quadro com o nº de linhas igual ao nº de utensílios no qual o utilizador tem de especificar qual o tipo de utensílios e a sua potência nominal (exemplo: máquina de café Nexpresso 16 W ) Deve ser possível associar tags virtuais a grupos lógicos de forma a efectuar uma operação lógica entre as tags desse grupo. Deve ser possível associar indicadores a grupos lógicos de forma a efectuar uma operação lógica sobre as tags desse grupo e outros detalhes do grupo. Tabela 6 - Requisitos de grupos lógicos Must Have Must Have Criação da Baseline (CBE) Uma baseline representa um padrão de consumo registado numa determinada data e serve para nos dizer se realmente estão a ocorrer poupanças de consumos relativamente a períodos homólogos. A baseline olha não apenas para os consumos registados mas também para as alterações que foram feitas nos edifícios: por exemplo, se aumentarmos o número de AVACs temos de ter em conta essa alteração para determinar a poupança que existiu. Nesta situação estamos a gastar mais porque temos mais AVACs a funcionar, mas podemos estar a registar poupança já que em proporção o consumo se manteve ou diminuiu. Requisito Descrição Prioridade CBE1 CBE2 Deve ser possível criar uma baseline associada a um grupo lógico (edifício) essa baseline deve conter informação relativa ao consumo de energia activa por tipo de horas. Deve conter também a potência nominal e o horário de funcionamento do AVAC no edifício. Por fim de ter uma área onde se podem inserir aparelhos (maquina de café por exemplo) inserindo para tal a potência nominal e horário de funcionamento (consultar requisito CGL7). Deve ser possível editar a baseline, com algumas restrições, apenas é possível editar a baseline do ano zero para os consumos de energia activa. É sempre possível editar os dados do AVAC e dos aparelhos. Sempre que uma baseline é editada os valores devem ser recalculados (devem ser recalculados os valores das baselines seguintes). Must have Must have Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

72 Especificação ienergy Eficiência Energética em Edifícios CBE3 CBE4 Em cada altura podem ser introduzidos actualizações a baseline, modificações no quadro de AVAC e também nos aparelhos. Estas actualizações influenciam o cálculo da baseline. As actualizações da baseline são feitas a partir do ano zero e podem ser mensais. Quando existe qualquer alteração todo o resto deve ser recalculado. O utilizador pode actualizar a baseline quando quiser. Seja por opção, ou solicitação ao final de seis meses, o quadro que aparece para actualizar a baseline é o seguinte: Área total sujeita a climatização e/ou iluminação permanente (m2); Nº de funcionários permanents; Nº de appliances; Tarifário aplicado; Alterações no sistema AVAC (kwh); Instalação/Desactivação de equipamentos com consumos energéticos significativos (kwh); Para o nº de utensílios, é aberto um quadro com o nº de linhas igual ao nº de utensílios no qual o utilizador tem de especificar qual o tipo de utensílios e a sua potência nominal (exemplo: máquina de café Nexpresso 16 W ). Apenas é possível apagar a última baseline introduzida no sistema. Para apagar um conjunto de baselines o utilizadore deve começar por apagar da última. Tabela 7 - Tabela de Requisitos de Baseline Must have Must have Indicadores de Performance (KPI s) Os KPIs são indicadores predefinidos sobre a performance dos grupos lógicos (que correspondem a edifícios). Estes indicadores permitem saber se determinado edifício está a ter uma boa performance a nível energético. Requisito Descrição Prioridade IND1 Indicador de performance: Indicador diário, com o valor percentual que corresponde ao desvio entre o consumo efectuado e o consumo objectiva. Os objectivos serão definidos através da funcionalidade de Alertas da plataforma. Must have 50 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

73 ienergy Eficiência Energética em Edifícios Especificação IND2 IND3 IND4 IND5 IND6 IND7 IND8 Para este requisito será usado, como objectivo de referência, o objectivo definido no alerta como MajorThreshold. Apenas será carregada informação para as tags que tenham pelo menos um objectivo associado. Medida Kw/h consumido: Indicador horário, com o valor do consumo para tags do tipo energia activa e visíveis para o utilizador. Medida Kw/h consumido com abstracção para CO2: Indicador horário, com o valor do consumo para tags do tipo energia activa e visíveis para o utilizador, com abstracção para CO2. Indicador de temperatura: Indicador horário, com o último valor instantâneo disponível, para a temperatura. Indicador de humidade: Indicador horário, com o último valor instantâneo disponível, para a humidade. Indicador diário de comparação com períodos homólogos: A comparação é feita com a média de consumos dos últimos x dias homólogos. Não serão tidos em conta distinções entre períodos de Verão/Inverno. Indicador mensal de comparação com períodos homólogos: A comparação é feita com o consumo do mês homólogo do ano anterior. Nota: Será necessário carregar os dados de histórico para a tabela de consumo mês. Indicador com % de poupança global relativa ao mesmo período do ano anterior: A comparação é feita usando o consumo dentro do ano civil até à data actual com o período homólogo do ano anterior. Tabela 8 - Requisitos de KPIs Must have Must have Must have Must have Must have Must have Must have Indicadores de Estado Os indicadores de estado são indicadores que reflectem o consumo específico, ou seja, consumo por unidade dos indicadores de estado presentes nos detalhes do grupo. Podemos por exemplo saber o Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

74 Especificação ienergy Eficiência Energética em Edifícios consumo por pessoa, o que é possível de calcular através da divisão da tag de energia activa do edifício pelo número de pessoas que usam o edifício. Requisito Descrição Prioridade IND09 Deve ser possível criar, editar e apagar indicadores de estado. Must have Estes indicadores devem estar associados aos grupos lógicos. IND10 As operações possíveis na criação de um indicador de estado são a Must have adição, multiplicação, subtracção e divisão. Estas operações são feitas sobre uma tag em relação a um detalhe de um grupo ou a uma constante. IND11 Os indicadores de estado podem ser vistos da mesma maneira que as tags. Através da aplicação web na forma de gráficos e relatórios. Must have Notas Exemplo de indicadores de estado: Consumo de Energia por área: o Consumo de energia (kwh) / Área total sujeita a climatização e/ou iluminação permanente (m2). Consumo de Energia por funcionário: o Consumo de energia (kwh) / Nº de funcionários permanentes Tabela 9 - Requisitos de indicadores de estado Indicadores de Poupança Os indicadores de poupança são indicadores que estão directamente relacionados com a baseline. Dizem o quanto estamos a poupar em relação a um ano anterior. Estes indicadores têm em conta não só os consumos mas também as alterações que o edifício sofre. Por exemplo, se consumimos 10kWh em 2010 e em 2011 estamos a consumir 15kWh isto não quer dizer que estamos a gastar mais, porque podem ter existido alterações ao edifício (por exemplo, ter sido acrescentado um AVAC). Com estes indicadores temos a poupança real em relação à baseline registada. Requisito Descrição Prioridade INP-001 INP-002 Os indicadores de poupança são indicadores predefinidos que Must have são vistos nos relatórios gerados pela aplicação e têm como base de cálculo a baseline. Sempre que uma baseline é actualizada os valores dos Must have 52 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

75 ienergy Eficiência Energética em Edifícios Especificação indicadores de poupança devem ser actualizados também. INP-003 Os indicadores de poupança são obtidos através do relacionamento dos valores da baseline e dos valores medidos pelos equipamentos que fazem parte da solução ienergy. O utilizador pode ver na área principal de indicadores os seguintes indicadores de poupança: 1. Poupança mensal de energia = Consumo de energia (kwh) da baseline actualizada consumo de energia mensal (kwh) medido 2. Poupança mensal de dinheiro = Poupança de energia Custo médio do kwh Poupança mensal de emissões = Poupança de energia Factor de emissão do kwh Notas O cálculo da poupança é o cálculo da poupança obtida no final de um mês, com a baseline actualizada, de modo a evitar dados desactualizados, ou seja: Poupança mensal = Valor da Baseline actualizada Valor medido mensal Baseline actualizada = Baseline do ano 0 +- Actualização Exemplo: Poupança de Energia em Janeiro = Energia consumida de Baseline em Janeiro Energia registada em Janeiro Energia consumida de Baseline em Janeiro = Energia consumida em Janeiro no ano kwh (Desactivação de Chiller) Tabela 10 - Requisitos de indicadores de poupança Mensagens (MNS) As mensagens servem como forma de comunicação entre o gestor de energia e o gestor de determinado edifício. Requisito Descrição Prioridade MNS1 Deverá ser possível ao gestor de energia enviar mensagens para as agências, com dicas para promover a redução do consumo energético. Estas mensagens são caracterizadas por: Data: data de inserção da mensagem no sistema; Severidade: classificação da severidade da mensagem, Alto, Must Have Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

76 Especificação ienergy Eficiência Energética em Edifícios Médio ou Baixo; Titulo: título da mensagem a disponibilizar à agência; Corpo: corpo da mensagem a disponibilizar à agência; Agência: identificador da agência [<código>-<nome>]. MNS2 Listagem de todas as mensagens enviadas pelo operador, com Nice to filtro por agência. Have Notas Uma vez que as mensagens são introduzidas na base de dados e posteriormente lidas por uma aplicação externa, não está a ser contemplado o editar e eliminar de mensagens. Tabela 11 - Requisitos de mensagens Tags Virtuais Existem casos em que o valor de uma tag não nos dá a informação do consumo total de um edifício, sendo então necessário somar o consumo de todas as tags para chegar ao valor pretendido. Uma tag virtual corresponde a uma operação entre duas tags ou mesmo duas tags virtuais. Requisito Descrição Prioridade TV1 Deve ser possível criar editar apagar tags virtuais. Must have TV2 As operações suportadas sobre as tags são a multiplicação, divisão, Must have soma e subtracção. As operações são sempre feitas sobre duas ou mais tags. TV3 O resultado desta operação deve poder ser visto da mesma forma que Must have são vistas as tags normais. Devem também aparecer na hierarquia de grupos na aplicação web. TV4 As tags virtuais devem também ser agregadas segundo as agregações Must have especificadas para esta aplicação (Hora, dia, mês). Tabela 12 - Requisitos de tags virtuais Módulo de Análise de Dados É necessário poder operar sobre informação histórica relevante, e analisar períodos específicos de consumo e/ou registo, de modo a perceber quando, como, e onde é que a energia é consumida, quais os parâmetros que afectam esse consumo, e onde se encontram as oportunidades de melhoria de eficiência 54 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

77 ienergy Eficiência Energética em Edifícios Especificação energética. Esta secção encontra-se dividida em várias sub-secções já que existem muitos requisitos associados a análise de dados Configuração de Opções de Grupos e Variáveis (VAG) Neste requisito pretende clarificar-se como são feitas as pesquisas de dados na base de dados. Aqui, os grupos lógicos são apresentados numa árvore que permite seleccionar o que se pretende ver a cada instante. Requisito Descrição Prioridade COGV1 COGV2 COGV3 COGV4 O gestor de energia pode ver os grupos lógicos (edifícios, agências, AVAC, etc) e respectivos parâmetros energéticos monitorizados (energia, tensão, corrente, etc) numa vista em árvore hierarquizada. O gestor de energia pode filtra os grupos lógicos e respectivos parâmetros através do seu nome ou código. Somente grupos lógicos ou parâmetros que preencham os critérios de filtragem devem ser mostrados, toda a hierarquia superior caso exista deve ser mantida. O gestor de energia pode manipular livremente os parâmetros monitorizados. Seleccionar e desseleccionar os parâmetros associadas aos grupos lógicos através uma checkbox. O Interface Web deve permitir ter no máximo 10 parâmetros seleccionadas, destes 10 apenas dois podem ter unidades diferentes. O gestor de energia pode seleccionar uma tag e escolher a suar conversão para outra unidade (por exemplo ver o consumo de energia em CO2). Must Have Nice to Have Shoud Have Shoud Have Notas O interface web deve apresentar uma árvore com a seguinte hierarquia base com este formato: Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

78 Especificação ienergy Eficiência Energética em Edifícios Tabela 13 Requisitos de configuração de opções de grupos e variáveis Configuração de Opções de Aquisição de Dados da BD (COD) A aquisição de dados é também um parâmetro configurável, podem ser analisados consumos de dias isolados ou até intervalos de tempo. É também possível especificar o que se pretende ver como por exemplo ver o consumo de kwh convertido ema CO2. Requisito Descrição Prioridade COD1 COD2 COD3 COD4 COD5 O gestor de energia pode seleccionar vários dias para monotorização num calendário de dias seleccionáveis (o Interface web deve colocar por defeito a selecção no dia anterior a data actual). Os dias podem ser seleccionados em semanas, meses ou anos diferentes. O gestor de energia deve ter uma opção no calendário para seleccionar todos os dias da semana de um mês (excluindo assim os fins de semana). O gestor de energia pode escolher um intervalo de monotorização através de uma data de início e fim (por defeito a data de fim deve ser a data actual e a data de inicio 7 dias inferior). O gestor de energia deve poder optar pela escolha da data através da funcionalidade CO1 ou CO2. Por defeito deve estar activa a funcionalidade CO1. O gestor de energia deve igualmente poder configurar o intervalo de horas para visualização gráfica, através da introdução de uma hora de início e de fim para uma análise com granularidade diária (por defeito a hora de inicio deve ser as 00:00 Must Have Nice to Have Must Have Must Have Must Have 56 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

79 ienergy Eficiência Energética em Edifícios Especificação COD6 COD7 COD8 e a hora fim 23:59). O gestor de energia deve ter a possibilidade de configurar a obtenção de dados agregados (hora, dia, Mês). O gestor de energia deve poder minimizar a área de opções para ter maior área de análise. O gestor de energia deve poder ter a opção de criar gráficos de regressão linear simples para os parâmetros seleccionados. Tabela 14 - Requisitos de configuração da aquisição de dados Must Have Must Have Must Have Visualização de Dados na Forma de Gráfico (VDG) Depois de escolhidos todos os parâmetros, o software apresenta um gráfico que está de acordo com as opções escolhidas. Requisito Descrição Prioridade VDG1 O gestor de energia pode gerar um gráfico quando tiver no Must Have mínimo um parâmetro energético e um dia seleccionado. VDG2 O gestor de energia pode gerar um gráfico com base nas Must Have opções escolhidas. Os parâmetros energéticos seleccionados devem estar sobrepostos no mesmo gráfico bem como os diferentes dias seleccionados (ex. se for seleccionado o dia 1 de Março e o dia 1 de Abril estes dois devem aparecer sobrepostos). VDG3 Os eixos do gráfico devem estar identificados com as suas Must Have unidades (o eixo do x representa sempre o tempo com excepção para o gráfico de regressão linear, o eixo dos y representa a unidade dos parâmetros seleccionadas). VDG4 O gestor de energia deve ser informado do período sazonal Nice to Have dos dados representados no gráfico (o gráfico pode ter informação de vários períodos sazonais). VDG5 O gestor de energia deve ter a indicação dos diferentes Must Have períodos horários dentro do intervalo diário. Quando existe uma sazonalidade diferente entre os dias seleccionados é necessário mostrar os períodos horários de maneira alternativa (Cores quando possível, pedaços e séries diferentes). VDG6 O gráfico deve conter uma legenda elucidativa de todas as Must Have Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

80 Especificação ienergy Eficiência Energética em Edifícios VDG7 VDG8 VDG9 VDG10 VDG11 séries de dados representados nele. O gestor de energia deve poder ver no gráfico informação do valor mínimo, máximo, médio e desvio padrão ou custos para o intervalo de tempo, caso se justifique. Esta opção deve poder ser activa e desactiva. O gestor de energia pode ver representado no gráfico caso active a opção, uma linha de média, mínimo e máximo. O gestor de energia pode ver representado no gráfico uma linha de tendência linear. Esta linha deve estar sempre representada para gráficos de regressão linear. Com a respectiva equação y=mx+b e R. O gestor de energia pode seleccionar o tipo de gráfico (linhas, barras, Stacked Bar). O gestor de energia deve poder exportada o gráfico e toda informação contida nele, bem como a tabela geral para Excel. Tabela 15 - Requisitos de visualização de dados Must Have Must to Have Must Have Nice to Have Must Have Análise de Custos de Energia (ACE) A análise de custo é uma funcionalidade importante do software e é com esta análise que o gestor de energia pode efectivamente ver o que está a ser gasto em cada um dos seus edifícios ou mesmo em cada um dos sistemas. Requisito Descrição Prioridade ACE1 ACE2 ACE3 O gestor de energia pode consultar uma representação gráfica com a relação consumo/custos. Os períodos horários repartidos em Horas de Cheia, Ponta, Vazio e Super Vazio devem estar identificados de forma a poderem ser distinguidos (Cores). Para cálculo dos custos deve ser tido em conta o tarifário associado. O gestor de energia pode ver também uma tabela com o resumo da representação gráfica de ACE1, com informação da data, valor de consumo/ custo, e consumos/custos totais. O gestor de energia deve também poder ver uma segunda tabela com os custos e consumos por tipo de hora (Cheia, Vazio, Must have Must have Must have 58 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

81 ienergy Eficiência Energética em Edifícios Especificação ACE4 etc) e o tarifário. O gestor de energia pode exportar estas tabelas para o formato Excel. Tabela 16 - Requisitos de análise de custos de energia Must have Conclusões da Análise (CA) As conclusões da análise permitem que o gestor de energia tenha ao seu dispor um conjunto de análises estatísticas mais frequentes em relação aos dados em análise. Requisito Descrição Prioridade CA1 CA2 CA3 O gestor de energia pode também consultar uma tabela com conclusões retiradas dos dados representados no gráfico. Esta tabela deve conter informação sobre valor médio, máximo, mínimo, sobre o desvio padrão, hora de máximo, hora de mínimo, frequência, moda, média, mediana, variância, erro padrão, precisão. O gestor de energia pode também consultar uma tabela com o resumo de consumos em horas de ponta. O gestor de energia pode exportar esta tabela para o formato Excel. Tabela 17 - Requisitos de conclusões da análise Must have Must have Must have Tabela Geral (TG) A tabela geral representa os dados em bruto, é constituída por todos os dados do intervalo de tempo seleccionado e para a granularidade seleccionada sem qualquer tipo de tratamento. Requisito Descrição Prioridade TG1 O gestor de energia deve poder consultar os dados contidos no Must have gráfico na forma de uma tabela. Esta tabela deve contar com os seguintes campos (Data/Hora, Edifício, Grupo (ex. AVAC, Geral), parâmetro, valor, unidades). TG2 O gestor de energia pode exportar a tabela para o formato Excel. Must have Tabela 18 - Requisitos de dados gerais Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

82 Especificação ienergy Eficiência Energética em Edifícios Módulo de Relatórios No módulo de relatórios é possível gerar dois tipos de relatórios prefinidos com análises relevantes para o gestor de energia como análise de consumo de energia activa, energia reactiva, potência contratada etc. Requisito Descrição Prioridade REL1 Deverá ser possível um utilizador gerar um relatório de um grupo lógico. Este relatório pode ter 4 tipos de agregação diferentes: Must have Diário Semanal Mensal Anual REL2 REL3 No grupo da agência deveram existir as tags de Energia Activa e as três tags virtuais de Energia Reactiva (dependendo do contador instalado), tag de Factor de Potência e tag de Voltagem. Relatório Diário terá de apresentar os seguintes campos para o dia seleccionado: Gráfico, tabela de consumos e tabela de custos da energia activa Gráfico, tabela de consumos e tabela de custos da energia reactiva Gráfico, tabela de consumos do Facto de Potência Gráfico, tabela de consumos da Voltagem Tabela de alarmes para o Factor de Potência com valores inferiores a 0,94. Relatório Semanal terá de apresentar os seguintes campos para a semana seleccionada: Must have Must have Gráfico, tabela de consumos e tabela de custos da energia activa Gráfico, tabela de consumos e tabela de custos da energia reactiva Gráfico, tabela de consumos do Facto de Potência Gráfico, tabela de consumos da Voltagem 60 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

83 ienergy Eficiência Energética em Edifícios Especificação REL4 REL5 Tabela de alarmes para o Facto de Potência com valores inferiores a 0,94. Tabela com os indicadores do grupo Tabelas de poupança de energia, custo e emissões com base na baseline da agência. Gráfico e tabela da Potência tomada e contratada Relatório Mensal terá de apresentar os seguintes campos para o mês seleccionado: Gráfico, tabela de consumos e tabela de custos da energia activa Gráfico, tabela de consumos e tabela de custos da energia reactiva Gráfico, tabela de consumos do Facto de Potência Gráfico, tabela de consumos da Voltagem Tabela de alarmes para o Facto de Potência com valores inferiores a 0,94. Tabela com os indicadores do grupo Tabelas de poupança de energia, custo e emissões com base na baseline da agência. Gráfico e tabela da Potência tomada e contratada Relatório Anual terá de apresentar os seguintes campos para o ano seleccionado: Must have Must have Gráfico, tabela de consumos e tabela de custos da energia activa. Gráfico, tabela de consumos e tabela de custos da energia reactiva Gráfico, tabela de consumos do Facto de Potência Gráfico, tabela de consumos da Voltagem Tabela de alarmes para o Factor de Potência com valores inferiores a 0,94. Tabela com os indicadores do grupo Tabelas de poupança de energia, custo e emissões com base na baseline da agência. Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

84 Especificação ienergy Eficiência Energética em Edifícios REL6 Gráfico e tabela da Potência tomada e contratada Na secção de energia activa o gráfico utiliza o seguinte tipo de agregação consoante a sua periodicidade: Diário -> Horária Semanal -> Diária Mensal -> Diária Anual -> Mensal A tabela de consumos terá os seguintes campos consoante a periodicidade do relatório: Must have Diário: Moda, Média, Mediana, Variância, Desvio Padrão, Máximo, Mínimo e Total. Semanal: Frequência (entre dias de semana e fim-de-semana), Moda, Média, Mediana, Variância, Desvio Padrão, Máximo, Mínimo e Total. Mensal: Média, Desvio Padrão, Máximo, Mínimo e Total. Anual: Frequência (entre meses), Média, Desvio Padrão, Máximo, Mínimo e Total. REL7 REL8 REL9 REL10 A tabela terá os seguintes campos: percentagens de consumo, percentagem de custo e custo especifico em cada tipo de intervalo, e o custo total, médio, mínimo e máximo. Semelhante a REL6 mas para energia reactiva. As secções de Factor de Potência e de Voltagem são semelhantes às anteriores apenas não possuem tabela custos. Na secção de alarmes são apresentados todos os alarm triggers que apontam para a tag de Factor de Potência em que o seu valor é inferior a 0,94. Na secção de indicadores de poupança são apresentadas 3 tabelas: Poupança de energia Poupança de custos Must have Must have Must have Must have 62 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

85 ienergy Eficiência Energética em Edifícios Especificação REL11 Poupança de emissões Estes valores são calculados fazendo a diferenciação dos valores da baseline homologa (ano anterior) com os da tag de Energia Activa para cada mês do relatório. Para o custo multiplica-se a poupança de energia pelo custo da energia activa média em cada mês. Para a emissão multiplica-se a poupança de energia pela unidade de conversão kw -> kg/co2. Na secção de análise de Potência o gráfico apresenta a potência contratada em cada mês (máximo valor da potência tomada nos 8 meses anteriores) e a potência tomada em cada mês para cada tipo de intervalo (obtida através da divisão dos valores da tag de Energia Activa em cada tipo de hora). Tabela 19 - Requisitos de Relatórios Must have Módulo de Alertas Os alarmes são situações anómalas, ou de referência, que são reportadas pelo software de forma automática, caso se verifiquem. Estes alertas ajudam a chamar a atenção do gestor de energia para edifícios com consumos anormais de forma a poder intervir. Requisito Descrição Prioridade ALM1 ALM2 ALM3 Esta funcionalidade deve funcionar da mesma maneira que os validadores no ienergy sendo estes plugins (dll s) que são carregados para o ienergy. Deve ser possível ver todos os alarmes configurados no sistema, activar, desactivar, criar, editar e apagar alarmes. Os alarmes são criados sobre tags, grupos ou unidades. Os tipos de alarmes que podem ser configurados no ienergy são: Alarme de patamares Os valores das tags devem estar entre dois patamares um inferior e outro superior se forem ultrapassados é lançado um alerta. Em três níveis de gravidade (pouca gravidade, grave e muito grave). Must have Must have Must have Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

86 Especificação ienergy Eficiência Energética em Edifícios ALM4 ALM5 Funcionamento de unidades Alarme lançado quando uma unidade deixa de comunicar consumos. Alarme de objectivo É fixado um objectivo e se esse objectivo não for atingido é lançado um alarme. Existem três tipos de graus neste alarme (pouca gravidade, grave e muito grave) os alertas são lançados segundo estes graus. Quando o alarme é disparado deve ser enviado um para a Must have lista configurada nos parâmetros do alerta com a descrição do alarme. Deve ser possível no ienergy listar todos os alarmes disparados Must pelo have sistema. Deve também ser possível marca-los como lidos. Tabela 20 - Requisitos para gestão de alertas Módulo de Actuação A actuação é uma acção sobre determinado dispositivo, permite ligar e desligar esse mesmo dispositivo. A actuação pode ser agendada para uma determinada hora e para um determinado dia e será disputada automaticamente pelo sistema. Requisito Descrição Prioridade MA1 MA2 MA3 Deve ser possível agendar actuações para cada um dos dias da semana para uma determinada hora. Deve ser possível ver a lista de actuações, registadas no sistema vem como gerir essas actuações (adicionar, editar e apagar). O sistema deve reconhecer automaticamente quando deve enviar uma actuação, e quando necessário deve enviar a actuação para a camada inferior da plataforma. É da responsabilidade da camada inferior enviar a mensagem para o dispositivo em tempo útil. Must have Must have Must have Notas As actuações não são instantâneas devido a limitações que existem actualmente no hardware e software. Deve no entanto ser garantido um tempo máximo para que a actuação seja enviada para os dispositivos. Tabela 21 Requisitos para a actuação 64 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

87 ienergy Eficiência Energética em Edifícios Especificação Módulo de Tarifários As duas maiores vantagens do - ienergy - é que os utilizadores finais podem ver o impacto do seu consumo energético em termos financeiros e ecológicos. Com esta informação os utilizadores podem conduzir decisões informadas destinadas a optimizar o consumo energético e reduzir os custos e a produção de carbono. De forma a produzir uma vista financeira dos consumos de energia, o - ienergy - tem de ter uma fonte de informação sobre as tarifas que são aplicadas por cada fornecedor Módulo de Criação e Cálculo de Tarifas Os tarifários são o que permite saber o custo real de um consumo de energia num edifício. Neste módulo pretende-se especificar a introdução e cálculo de tarifários de energia. Requisito Descrição Prioridade CTAR1 Deve ser possível criar tarifários industriais de energia no sistema, estes tarifários são diferentes dos que existem actualmente no ienergy, já Must have que tem em conta mais parâmetros, como a energia reactiva e as potências (potência contratada e potência em horas de ponta). Os tarifários actuais devem ser alterados de forma a suportar estes tarifários, mantendo os tarifários já existentes. Pretende-se cobrir os tarifários industriais sendo eles os tarifários: MAT (Muito Alta Tensão) AT (Alta Tensão); MT (Média Tensão); BTE (Baixa Tensão Especial) CTAR2 Cada um dos parâmetros que podem ser adicionados aos tarifários tem os seguintes parâmetros associados: Must have Nome - Nome do parâmetro; Período de Cálculo Em que período é calculado (horário, diário, mensal); Parâmetro - Parâmetro a que se refere (energia activa, energia reactiva, potência); Tipos de hora - Tipos de horas em que o parâmetro deve ser verificado; Preço - Custo associado ao parâmetro. Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

88 Especificação ienergy Eficiência Energética em Edifícios CTAR3 CTAR4 CTAR5 CTAR6 No caso do parâmetro de energia reactiva indutiva existe ainda associado a ele um factor de multiplicação. Este factor de multiplicação tem associados os seguintes parâmetros. Descrição Descrição do factor de multiplicação; Máximo Valor máximo; Mínimo Valor mínimo; Factor de multiplicação Factor de multiplicação associado que vai ser multiplicado pelo preço. Deve ser possível associar custos fixos aos tarifários industriais que seram aplicados ao custo no fim de cada mês. Deve ser possível introduzir intervalos e temporadas associadas a esses intervalos. Os parâmetros associados aos intervalos são: Hora de início Hora de fim Dia da semana Temporada As temporadas têm associadas duas datas a data de início e de fim. Estes valores devem ser calculados de forma individual, de maneira a existir sempre uma separação de custos e ser possível saber o que é gasto em cada parâmetro. Os valores de energia reactiva são guardados na tag de energia reactiva (pode ser uma virtual tag) esta tag deve ter o respectivo tipo de medida associada, para ser reconhecida como uma energia reactiva de tarifário. Os valores de potência são considerados KPIs e são armazenados nos indicadores. Devido a existência de várias energias activas nos dispositivos a energia activa que é usada no tarifário deve ser identificada da mesma forma que as tags de energia reactiva, através do tipo de medida associado a tag. Must have Must have Must have Must have Notas Devido a complexidade relacionada com o cálculo dos tarifários esta vai ser explicada na próxima secção deste documento. Tabela 22 Requisitos para o cálculo de tarifários 66 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

89 ienergy Eficiência Energética em Edifícios Especificação Componentes Tarifárias A estrutura geral das opções tarifárias de MAT (Muito Alta Tensão), AT (Alta Tensão), MT (Média Tensão) e BTE (Baixa Tensão Especial) são compostas pelas várias partes especificadas neste capítulo Termo Fixo A cada opção tarifária, é aplicado um termo tarifário fixo, definido em Euros por mês. Como exemplo, apresenta-se este valor para a opção tarifária de MAT. Figura 12 - Termo fixo do tarifário Energia Activa O tarifário apresenta um custo associado a energia activa, definido em Euros por kwh isto significa que por cada kwh vamos ter um custo em Euros associado dependendo do período do consumo e do tipo de hora (Figura 13). Os preços da energia activa nas opções tarifárias de MAT, AT e MT são discriminados em quatro períodos trimestrais e em quatro períodos horários. A definição destes períodos encontra-se no artigo 26º do Regulamento Tarifário do Sector Eléctrico [4]. Como exemplo, apresenta-se a discriminação dos preços para a opção tarifária de MAT. Figura 13 - Descriminação de preços de energia activa Potência Relativamente às necessidades de potência, são aplicados dois preços em cada opção tarifária: um relativo à Potência Contratada e outro relativo à Potência em Horas de Ponta, descritos nas secções e Como exemplo, apresentam-se ambos os preços para a opção tarifária de MAT. Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

90 Especificação ienergy Eficiência Energética em Edifícios Figura 14 - Descriminação de preços de potência Potência Contratada Cada opção tarifária apresenta um termo relativo a preços de potência contratada, definidos em Euros por kw, por mês. A definição de potência contratada é indicada no artigo 130º do Regulamento de Relações Comerciais do Sector Eléctrico [5], podendo resumir-se no valor indicado no ponto 4 deste artigo: Sem prejuízo do disposto nos números anteriores, o valor da potência contratada nos pontos de entrega em MAT, AT, MT e BTE, referido no n.º 1 é actualizado para a máxima potência tomada, registada nos 12 meses anteriores, incluindo o mês a que a factura respeita Por sua vez, a potência tomada é definida no artigo 129º do Regulamento de Relações Comerciais do Sector Eléctrico [4], como: A potência tomada é o maior valor da potência activa média, registado em qualquer período ininterrupto de 15 minutos, durante o intervalo de tempo a que a factura respeita Potência em Horas de Ponta Cada opção tarifária apresenta um termo relativo a preços de potência em horas de ponta, definidos em Euros por kw, por mês. A potência em horas de ponta é definida no artigo 131º do Regulamento de Relações Comerciais do Sector Eléctrico [4], como: A potência em horas de ponta (Pp) é a potência activa média calculada de acordo com a fórmula seguinte: Pp = Ep / Hp em que: Ep - energia activa no ponto de medição em horas de ponta, durante o intervalo de tempo a que a factura respeita. Hp - número de horas de ponta, durante o intervalo de tempo a que a factura respeita Energia Reactiva As opções tarifárias apresentam ainda um termo relativo a preços da energia reactiva, definidos em Euros por kvarh. 68 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

91 ienergy Eficiência Energética em Edifícios Especificação Os preços da energia reactiva são discriminados em preços da energia reactiva indutiva (ou energia reactiva fornecida) e preços da energia reactiva capacitiva (ou energia reactiva recebida), sendo discriminada a sua fórmula de cálculo nas secções e Como exemplo, apresentam-se ambos os preços para a opção tarifária de MAT. Figura 15 - Descriminação de preços de energia reactiva Energia Reactiva Fornecida (Indutiva) De acordo com o Despacho 3/2010 da ERSE [6], a facturação da energia reactiva indutiva deverá ser facturada nos períodos horários fora de vazio (Horas de Ponta e Horas Cheias) de acordo com os factores multiplicativos seguintes: Factores multiplicativos a aplicar ao preço de referência da energia reactiva indutiva, em 2011, de acordo com os Despachos 7253/2010 de 26 Abril e 10/2010 de 29 Julho, da ERSE: Descrição Factor multiplicativo Energia reactiva não cobrada tgφ < 0,3 0 Escalão 1 (a partir de ) Para 0,3 tgφ < 0,4 0,33 Escalão 2 Para 0,4 tgφ < 0,5 1 Escalão 3 Para tgφ 0,5 3 Figura 16 - Factores multiplicativos aplicados a energia reactiva O valor de tg φ é obtido pela equação: Em que é o total de energia reactiva indutiva registada nos períodos horários fora de vazio durante o período de facturação actual e representa o total de energia activa registada para o mesmo período. Até 31/Dez/2011 o Escalão 1 não é cobrado. Após essa data entra em vigor o Escalão 1 e o período de cálculo do escalão passa a ser diário, em vez do actual período igual ao de facturação Energia Reactiva Recebida (Capacitiva) De acordo com o Despacho 3/2010 da ERSE [5], a facturação da energia reactiva capacitiva pode ser facturada nos períodos horários de vazio (Horas de Vazio Normal e Horas de Super Vazio) embora não seja obrigatória esta facturação. Os operadores de rede deverão tornar públicos os fundamentos e as situações que podem justificar a facturação de energia capacitiva. Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

92 Especificação ienergy Eficiência Energética em Edifícios Distinção de Tarifários nas Regiões Autónomas Deve ter-se em atenção que nas Regiões Autónomas (Madeira e Açores) os tarifários são diferentes e têm características de facturação diferentes. Por exemplo, a partir de 01/Jan/2012 o período de integração da energia reactiva indutiva passa a ser diário em Portugal Continental e mantém-se mensal nas regiões autónomas da Madeira e dos Açores Medições Os tarifários industriais apresentados neste documento baseiam-se em mais medições do que as usadas nos anteriores tarifários domésticos, que eram apenas relativos a opções tarifárias de BTN (Baixa Tensão Normal). Para poder efectuar os cálculos de preços associados a estes tarifários, será necessário garantir que temos: Energia Activa recolhida com uma periodicidade de 15 minutos (ou um submúltiplo); Energia Reactiva Indutiva recolhida com uma periodicidade de 60 minutos (ou um submúltiplo); Energia Reactiva Capacitiva recolhida com uma periodicidade de 60 minutos (ou um submúltiplo); Cálculo do Valor da Potência Tomada O valor de potência tomada (para cálculo da potência contratada) indica ser baseado numa potência activa média para um período de 15 minutos, pelo que o seu valor pode (e deve) ser obtido directamente do valor de consumo da energia activa ( ) para o período específico: ( ) Cálculo das Energias Reactivas (contadores Hexing) No caso particular dos contadores da Hexing HXE34AS-CT, instalados numa grande maioria dos clientes industriais, estes medem quatro componentes da energia reactiva (energia reactiva nos quatro quadrantes) e o que pretendemos é apenas a distinção entre energia reactiva indutiva e energia reactiva capacitiva. 70 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

93 ienergy Eficiência Energética em Edifícios Especificação Para obter estes valores de energia a partir dos valores de energia reactiva nos quatro quadrantes, deverão ser criadas as tags virtuais que respeitem as seguintes equações: Módulo de Simulação de Tarifários Por forma a identificar melhorias na redução de custos num certo grupo lógico, este módulo deve permitir a simulação de tarifários em relação a todos os tarifários inseridos na aplicação permitido desta forma dizer qual seria o melhor tarifário para certo edifício. Requisito Descrição Prioridade STAR1 STAR2 STAR3 Deve ser possível comparar os vários tarifários existentes no ienergy aplicados aos consumos de energia em históricos relativos aos grupos lógicos. Deve ser possível seleccionar o grupo lógico para a qual se pretende a simulação de tarifários. A simulação de tarifários e relativa a cada uma das componentes de cada tarifário: Must have Must have STAR4 STAR5 STAR6 Energia activa dividida por tipos de hora; Potência Contratada; Potência em Horas de ponta; Energia reactiva indutiva e capacitiva; Custo fixo aplicado ao tarifário; Total de custos do tarifário. Os tipos de horas usados pela simulação são configurados na área de Must have tarifários bem como o preço das potências e das energias capacitiva e indutiva. O resultado da simulação pode ser positivo ou negativo sendo que um Must have resultado positivo significa que se estivesse a usar aquele tarifário pouparia em relação ao outro tarifário. Deve ser possível exportar esta informação para Excel. Nice to Have Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

94 Especificação ienergy Eficiência Energética em Edifícios Notas Apenas são feitas simulações em relação aos grupos que são as raízes das árvores de grupos lógicos. A simulação deve ser feita sobre o quadro geral de cada edifício, neste cálculo não interessa que exista a separação por quadro AVAC, Iluminação apenas interessa o consumo total do edifício (grupo lógico). Tabela 23 Requisitos para simulação de tarifários 6.5 Protótipos de Interface Nesta secção encontram-se alguns protótipos de interface com o utilizador construídos inicialmente para validação dos requisitos apresentados nesta secção. Com base nos requisitos funcionais apresentados neste capítulo, foram feitos vários protótipos de interface que foram posteriormente mostrados aos clientes a fim de validar alguns dos requisitos e de orientar a implementação. A descrição exaustiva de todos os protótipos construídos seria demasiado extensa e de interesse reduzido. Por esse motivo, nesta secção tentou-se apresentar e explicar exemplos que melhor demonstrem a generalidade do funcionamento e visual da aplicação, assim como os casos particulares mais importante. Estes protótipos foram construídos numa fase inicial, alguns não reflectem a aparência final na aplicação, serviram apenas para validar alguns requisitos. Ao longo do desenvolvimento foram adaptados as necessidades, quer para utilização quer para apressar o desenvolvimento já que devido aos atrasos iniciais não foi possível perder muito tempo a especificar exaustivamente estes protótipos de interface. Tabela de Mapeamento entre requisitos e ecrãs de protótipos de interface: Módulo Ecrã Módulo de Análise de dados Figura 17, 18,19, 20 e 21. Módulo de Alertas Figura 22, 23 e 24. Módulo de Actuação Figura 25 e 26. Módulo de Tarifários Figura 27, 28, 29 e 30 Módulo de Grupos Lógicos Figura 31 e 32 Tabela 24 - Ligação de requisitos a protótipos 72 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

95 ienergy Eficiência Energética em Edifícios Especificação Figura 17 - Gráfico de linhas com representação dos períodos sazonais e períodos horários Figura 18 - Opções de Gráfico e informação de análise Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

96 Especificação ienergy Eficiência Energética em Edifícios Figura 19 - Tabela de Conclusões Figura 20 - Tabela Geral 74 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

97 ienergy Eficiência Energética em Edifícios Especificação Figura 21 - Análise de Custos Figura 22 - Lista de Alertas Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

98 Especificação ienergy Eficiência Energética em Edifícios Figura 23 - Criação de alertas Figura 24 - Lista de alertas disparados 76 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

99 ienergy Eficiência Energética em Edifícios Especificação Figura 25 - Criação de actuações Figura 26 - Lista de actuações Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

100 Especificação ienergy Eficiência Energética em Edifícios Figura 27 - Simulação de tarifários Figura 28 - Lista de tarifários 78 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

101 ienergy Eficiência Energética em Edifícios Especificação Figura 29 - Inserção de novo tarifário Figura 30 - Inserção de parâmetros do tarifário Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

102 Especificação ienergy Eficiência Energética em Edifícios Figura 31- Lista de grupos Figura 32 - Página de edição de grupos 80 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

103 ienergy Eficiência Energética em Edifícios Especificação 6.6 Requisitos Não - Funcionais Existem vários requisitos de qualidade que se explicitam de seguida Eficiência Os requisitos funcionais devem ser implementados tendo em vista uma utilização eficiente dos recursos do sistema, tais como a memória, processamento e largura de banda no acesso online. A resposta do sistema em geral deverá ser apenas o necessário para poder ser o mais eficiente possível, sem gastar mais recursos do que seja realmente necessário. No entanto, não é um sistema crítico. O sistema deve conseguir responder a pedidos referentes a dados agregados em menos de 1 segundo. O sistema deve conseguir enviar a mensagem para as camadas inferiores com um atraso inferior a 5 minutos (no caso do comando de actuação). O sistema deve conseguir construir a árvore de grupos lógicos em menos de 1 segundo Fiabilidade O sistema deverá estar preparado para que no caso de ocorrerem falhas durante o seu funcionamento, este possa tentar garantir que não haja perdas de dados e deverá também, sempre que necessário e possível, emitir mensagens de erro claras, permitindo ao utilizador compreender o que se passa. Ou seja, deverá ser realizado um correcto tratamento de erros. Os resultados obtidos com o módulo de simulação de tarifários deverão ser os mais fiáveis possíveis, sendo fieis aos consumos registados e aos tarifários inseridos, já que não poderemos garantir que os consumos registados pelos equipamentos são os mesmos que os registados pela EDP. Não se pode exigir uma fiabilidade da ordem dos 100%, mas é necessário que pelo menos se consiga justificar e despertar o interesse pela sua utilização. No módulo de actuação é aceitável que existam atrasos no envio da mensagem para a camada inferior, mas nunca superiores a 2 minutos. A mensagem deverá todavia ser sempre enviada. O mesmo se aplica ao módulo de alertas. No que respeita à aplicação web, sendo ela o ponto de acesso a todo o sistema e às suas demais funcionalidades, deverá ser fiável no sentido de produzir os resultados esperados e evitar a perda de dados, nomeadamente dos dados armazenados na base de dados. Sempre que se realizarem inserções estas não deverão interferir com os restantes dados da base de dados, e sempre que se proceder à actualização de uma tarifário não deve igualmente interferir no restante. Por último, a remoção de uma Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

104 Especificação ienergy Eficiência Energética em Edifícios tarifário não deve comprometer a integridade dos restantes dados armazenados. O mesmo deverá ser tido em conta em relação à gestão dos alertas registados no sistema Manutenção O sistema deverá ser projectado segundo padrões de desenvolvimento de software estabelecidos, devendo ser correctamente documentado. Deve também em geral ser orientado a objectos de forma a ter classes ou objectos reutilizáveis tornando assim fácil a sua manutenção. As alterações à base de dados existente devem ser controladas de forma a não comprometer os dados já existentes. Do ponto de vista da utilização, o sistema deverá ser facilmente mantido através da aplicação web, sem necessidade de conhecimentos técnicos profundos mas com os óbvios conhecimentos de gestão de energia Portabilidade O sistema deverá permitir o acesso a partir de qualquer sistema ou plataforma com ligação à internet através de um browser (Internet explore 9+, FireFox 3.5+, Google Chrome 11+), independentemente do sistema operativo no qual seja executado Segurança Neste sistema é importante considerar questões de segurança entre os vários tipos de utilizadores, para não permitir acessos indevidos à informação armazenada. Por isso o acesso é controlado através de registo por um administrador do sistema (no Back Office) e autenticação no sistema da aplicação web. Todo o acesso pela internet à base de dados só deverá ser possível através da aplicação web e respectivos módulos. Na realização de pesquisas nunca deverá ser mostrada informação que não pertença ao nível de acesso do utilizador que a efectuou. E no caso de acontecerem erros não deverá ser mostrada informação comprometedora, tal como palavras-passe Usabilidade É razoável que seja preciso algum tempo, mas nunca demasiado, para aprender a usar o módulo de análise de dados. Contudo, o sistema em geral deverá ser facilmente utilizável por quem o vá usar pela primeira vez. No entanto, deverá ser disponibilizada um manual de utilizador. 82 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

105 ienergy Eficiência Energética em Edifícios Especificação É necessário ter em conta também que será um sistema usado por várias gerações de pessoas, umas mais novas e com conhecimentos mais alargados sobre a informática e outros com poucos conhecimentos e menos habituados ao seu uso Requisitos Tecnológicos As tecnologias a usar no sistema foram seleccionadas de entre as várias analisadas na secção 5.2. A escolha recaiu sobre o ASP.NET MVC em conjugação com o jquery por duas razões principais: a sua arquitectura com responsabilidades bem definidas, e por permitir que seja facilmente testada. Esta plataforma foi feita a pensar no desenvolvimento web moderno, fazendo uso intenso das tecnologias HTML, CSS, AJAX e Javascript / jquery. Uma das principais vantagens que vejo no MVC em relação ao web forms, é que o primeiro foi desenvolvido directamente para trabalhar já aplicando padrões de projectos (design patterns) e desenvolvimento orientado a testes (TDD) enquanto o segundo está mais focado no desenvolvimento orientado a componentes (entenda-se, como server controls) e eventos. Tanto o ASP.NET MVC como o web forms contêm o mesmo núcleo, que é o ASP.NET CORE, o que permite o uso de diversos recursos aplicados em web forms, tais como chaching, logging, etc. Figura 33 - Esquema de funcionamento do ASP.NET MVC (retirado do msdn Webcast) O ASP.NET MVC utiliza um esquema de tabela de rotas onde os URLs estão directamente ligados aos Controllers que por sua vez retornam para o browser renderizar uma view, podendo passar um model, mantendo URLs mais amigáveis aos utilizadores além de ter maior facilidade para se integrar com optimizadores de buscas e SEO. Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

106 Especificação ienergy Eficiência Energética em Edifícios Outra das grandes vantagens é o acesso ao web service (WCF) que é muito simplificado, não sendo necessário na grande parte dos casos a criação de modelos do lado da aplicação web nem de estabelecer as ligações explicitamente, dado que a própria plataforma trata disso. Toda a plataforma inclui inúmeras facilidades mesmo para facilitar a escrita de HTML (helpers) e existe um elevado número de plugins jquery livres que podem ser usados e são facilmente instalados. Possui também com uma popularidade crescente, com uma comunidade bastante activa. Desta forma existem inúmeros fóruns e tutoriais, assim como bastante documentação acerca da utilização da mesma. Uma outra característica importante é que esta plataforma ajuda o programador a criar uma aplicação web de uma forma lógica e organizada, uma vez que segue uma estrutura bem definida, de acordo com o modelo MVC (Model-View-Controller). Dessa forma o código pode ser melhor estruturado e é mais fácil de ser continuado o desenvolvimento por outras pessoas. A linguagem de programação usada, o C#, é uma linguagem que pareceu ser bastante adequada e até preferível a outras como Visual Basic. É uma linguagem simples de perceber e facilmente aprendida para quem já usar programação orientada a objectos. É não só uma linguagem orientada a objectos pura e muito completa como suporta também multithreading. Resumindo, o facto de ser uma plataforma completa, madura, com bom suporte, uma comunidade crescente e activa, e que simplifica a criação de aplicações web através da utilização de uma linguagem de programação orientada a objectos poderosa, pareceu ser a plataforma ideal de entre as duas escolhas possíveis. Inclusive, sendo uma plataforma a ganhar bastante terreno, pareceu uma interessante e boa aposta pensando no futuro e no futuro da web Requisitos de Documentação Deverá ser fornecido um Manual de Utilizador em português, bem como uma checklist de instalação também em português. Devem ainda ser actualizados os documentos relacionados com a Base de dados e com os web services. 6.7 Opinião Durante esta fase foram sentidas várias dificuldades ao nível da percepção do que o cliente realmente pretendida. Esta foi uma área nova, dado que desconhecia-se totalmente muitos dos conceitos chave desta área, sendo no entanto essenciais para perceber o que se pretendia implementar. Assim, teve-se que dedicar muitas horas para se familiarizar com os conceitos por detrás da gestão de energia, principalmente no que diz respeito ao cálculo dos tarifários, em que existe inúmera 84 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

107 ienergy Eficiência Energética em Edifícios Especificação documentação e legislação. Também do lado do cliente foi sentido durante algum tempo a falta de alguém com conhecimento do negócio da energia. Um membro com este perfil foi mais tarde integrado no projecto e foi um factor decisivo no sucesso desta especificação de requisitos. O estudo inicial da concorrência foi muito importante para esta fase, já que permitiu ter uma ideia do que é que existia e o que é que se pretendia exactamente fazer. Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

108

109 ienergy Eficiência Energética em Edifícios Arquitectura e Implementação da Plataforma 7 Arquitectura e Implementação da Plataforma A plataforma - ienergy - é constituída por diversos subsistemas que estão integrados e articulados de maneira a satisfazer os requisitos funcionais e não funcionais do sistema. Nesta secção serão mais focados os módulos que fizeram parte do projecto de estágio nomeadamente a aplicação web o web service e também o core do - ienergy - onde também foi desenvolvido trabalho, bem como a base de dados. Nesta secção são focados os detalhes de estrutura, modelos de dados e arquitectura do código desenvolvido, assim como as interfaces principais. A aplicação web foi implementada de raiz e no web service foi criado um novo end point para suportar esta plataforma web. Na base de dados apenas algumas coisas foram criadas de novo ou melhoradas ampliando a sua funcionalidade, como é o caso dos tarifários. Um dos módulos da aplicação web, a simulação e o cálculo dos tarifários, devido à sua complexidade foi parcialmente implementado já que apenas suporta tarifários de energia eléctrica. Nesta fase do projecto esses módulos permitem apenas simulação e cálculo de tarifários de electricidade, e só numa fase posterior, já fora do âmbito do estágio, é que foi implementada toda a componente de tarifários. No entanto, mesmo com o pouco tempo disponível para realizar a implementação do sistema, foi possível apresentar uma solução completa e todos os casos de uso se encontram implementados. 7.1 Integração com os Vários Sistemas A Figura 34 mostra como o - ienergy - e a aplicação web estão posicionados em relação a outros componentes de hardware e software e que interagem com eles directamente ou indirectamente. Figura 34 -Como é que o portal web e o ienergy se enquadram na solução de medição Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

110 Arquitectura e Implementação da Plataforma ienergy Eficiência Energética em Edifícios Como é visível existe uma pilha de serviços que compõem toda a solução de medição. Como seria de esperar cada camada tem os seus interfaces perfeitamente definidos o que permite que a camada directamente acima ou abaixo interagir com ela. O interface entre o hardware e a camada de recepção de dados está fora do âmbito deste estágio, assim como o interface entre o ienergy e o icenter. A camada de processamento de dados recebe, guarda e processa os dados recebidos das camadas inferiores. Esta camada, apesar de já estar construída também recebeu novas funcionalidades. Finalmente, na camada de apresentação é usado um web service para interagir com o ienergy e disponibilizar informação aos seus clientes. Foi construído um novo end point no web service já existente aproveitando assim algumas funcionalidades essenciais que este já tinha implementadas, caso da autenticação com o ienergy. Por cima dessa camada de web service está a aplicação web, que interage com esta para receber e enviar dados para a plataforma - ienergy Implementação Neste capítulo pretende-se explicar como foi organizada a implementação do software, assim como detalhes pertinentes sobre a mesma, os problemas encontrados e respectivas soluções Ferramentas Para o desenvolvimento do software foram usadas diversas ferramentas não só para o desenvolvimento em si, mas também para a realização dos testes sobre esses desenvolvimentos. De seguida serão apresentadas as ferramentas usadas, divididas em duas secções desenvolvimento e testes Ferramentas de Desenvolvimento Para o desenvolvimento das plataformas foi usado o C#, Linq, ADO.NET Entity Framework, ASP.NET MVC, WCF, jquery. A justificação para o uso destas tecnologias foi apresentado na secção 5.2 e IDE Durante o desenvolvimento foi usado o IDE Microsoft Visual Studio 2010 porque era o que se adequava mais as tecnologias em causa Base de Dados A base de dados assenta sobre o Microsoft SQL Server 2008 RC2. 88 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

111 ienergy Eficiência Energética em Edifícios Arquitectura e Implementação da Plataforma Ferramentas de Teste Usadas Foram usadas algumas ferramentas de teste de para que o software fosse testa de forma a garantir a sua fiabilidade sendo elas: NUnit Ferramenta para testes unitários para C#; SoapUI Ferramenta para testar serviços disponíveis na web Organização do Código Nesta secção é descrita a forma como o código da aplicação está organizado, quando necessário é usado code snippets para clarificar os problemas em discussão. ISA.iEnergy.Core Dynamic link library que é partilhada pelos diferentes subsistemas apresentados anteriormente. Esta biblioteca contém a lógica necessária para manipular os dados armazenados na base de dados e em outros sistemas com que o - ienergy - comunica. ISA.iEnergy.Service.WebService Aplicação web que contém o web service de edifícios e que é exposto por este para ser usado por aplicações clientes da plataforma - ienergy -. ISA.iEnergy.Alert Pasta em que se encontram todas as DLL que implementam os alertas especificados na secção de requisitos que posteriormente são carregadas para o - ienergy -. ISA.iEnergy.Utilities.TariffSimulator Um programa utilitário que é usado para cálcular a melhor tarifa (em termos de redução de custos) para um certo padrão de consumo. ISA.iEnergy.Web.Backoffice Aplicação web que é usada para gerir o sistema. ISA.iEnergy.Tests DLL que contém os testes unitários que foram criados durante o desenvolvimento do sistema. ISA.iEnergy.Web.iEnergy4Buildings Aplicação web que serve de interface para o utilizador. O código da aplicação web segue a estrutura geral de uma aplicação feita em ASP.NET MVC constituído por Views, Controllers, Models, Shared, Helpers e Binders todas elas vão ser apresentadas nas secções seguintes. A configuração da aplicação e do ambiente de execução é realizada no ficheiro config na raiz. É neste ficheiro que se define a configuração do acesso ao web service. Em Content/images/ localizam-se todas as imagens usadas pela aplicação e em Content/stylesheets/ encontra-se o código CSS de definição dos estilos usados. Ainda na pasta Content, temos a pasta Scripts que contém não só as funções que o próprio ASP.NET MVC cria na criação do projecto mas também algumas funções criadas para a aplicação. Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

112 Arquitectura e Implementação da Plataforma ienergy Eficiência Energética em Edifícios Após esta análise sobre a estrutura da pasta da aplicação web serão analisados alguns tópicos relativos ao código e decisões de desenho. Todos estes módulos estão agrupados logicamente dentro de uma pasta virtual no IDE (Visual Studio 2010). O agrupamento é simplesmente lógico não têm nenhum efeito em como o software é implementado. Todo o código encontra-se documentado com RDoc, o qual permite gerar documentação navegável num browser em HTML através do código, mais os comentários e descrições existentes. Figura 35 - Organização do código no Visual Studio. Como se pode ver, o software é constituído por vários módulos independentes que facilitam a integração e desenvolvimento de novas funcionalidades ou de novos sistemas. Nas secções seguintes vão ser descritas as implementações feitas em cada um desses módulos do sistema. 7.3 Componentes A solução tem uma arquitectura modelar que facilita o desenvolvimento. A Figura 36 mostra os diferentes módulos da solução que foram criados ou usados durante o desenvolvimento com excepção para o módulo de integração com o - icenter - que foi apenas usado para enviar a mensagem de actuação aos dispositivos. 90 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

113 ienergy Eficiência Energética em Edifícios Arquitectura e Implementação da Plataforma Figura 36 - Módulos do ienergy Segue-se uma breve descrição de cada módulo e o que foi feito em cada um deles: Web Service Este módulo é responsável por gerir a interacção entre sistemas remotos e o - ienergy -. Neste módulo foi criado um novo end point que serviu para dar suporte ao portal web. BackOffice Este módulo é responsável por ter um interface gráfico de gestão da plataforma - ienergy -. Neste módulo foram criadas novas áreas de maneira a ser possível responder aos requisitos supra citados com por exemplo a criação de novos tarifários entre outras funcionalidades. Task Scheduler Este módulo faz uso do windows task scheduler de forma a executar código C# em horários específicos ou procedimentos na base de dados. O uso deste modulo para execução de procedimentos na base de dados prende-se essencialmente com as restrições paresentadas pela versão standard do Sql Server (instalada em alguns clientes) que não permite a criação de Jobs. Aplicação Web Este módulo é responsável por mostrar todas análises realizadas pela plataforma - ienergy -. É uma aplicação cliente que serve de interface com o utilizador final. Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

114 Arquitectura e Implementação da Plataforma ienergy Eficiência Energética em Edifícios CORE / Business Logic Este módulo é responsável por gerir toda a lógica de dados e de negócio ligada a plataforma - ienergy -. icenter Integration Este módulo é responsável por gerir toda a interacção entre o - icenter - e o - ienergy -. O - icenter - é a plataforma que recolhe todos os dados dos dispositivos remotos. Nas secções seguintes cada um dos módulos do sistema de interesse para o estágio são descritos mais detalhadamente, apenas nas componentes que a ele dizem respeito Base de Dados A especificação das tabelas criadas na base de dados encontra-se em anexo. A base dados já existia, mas durante o projecto foram adicionadas/modificadas algumas entidades para suportar as novas funcionalidades pretendidas, tais como os tarifários de energia, os grupos lógicos, os indicadores, alertas e a actuação sobre novas entidades, conforme especificado no Anexo V. Na Tabela 25 descreve-se as principais tabelas da base de dados, representada no respectivo diagrama. Tabelas Descrição alert Tabela que armazena os alertas carregados no sistema. alert_parameter Tabela que armazena os parâmetros dos alertas existentes nos sistemas. alert_trigger Tabela que armazena os alertas que foram disparados pelo sistema. alert_trigger_parameter Tabela que armazena os parâmetros que fizeram dispara os alertas que foram disparados pelo sistema. tariff Tabela que guarda os dados referentes aos tarifários de energia. tariff_parameter Tabela que guarda os dados referentes aos parâmetros que estão associados aos tarifários. multiplication_factor Tabela que guarda os dados dos factores de multiplicação associados aos parâmetros dos tarifários. fixed_costs Tabela que guarda os custos fixos aplicados aos tarifários. Esses custos dependem da potência contratada. interval Tabela que armazena os diversos intervalos para um tarifário baseado em intervalos. season Tabela que armazena os períodos de facturação dos tarifários. season_series Tabela que armazena os diversos períodos de facturação de cada temporada. 92 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

115 ienergy Eficiência Energética em Edifícios Arquitectura e Implementação da Plataforma supplier Tabela que armazena todos os fornecedores de tarifários de energia. virtual_tag_parameter Tabela que guarda as formulas usadas no cálculo das tags virtuais. indicator Tabela que guarda os dados referentes ao cálculo de indicados de estados. action Tabela que guarda os dados referentes as actuações agendadas no sistema. group Tabela que guarda os dados referentes aos grupos. group_details Tabela que guarda os dados referentes aos detalhes dos grupos que são usados no cálculo de indicadores de estado. group_type Tabela que armazena dados relativos aos tipos de grupos que estão armazenados no sistema. group_schedule Tabela que armazena dados relativos aos horários de funcionamento do grupo (segurança, limpeza etc). group_baseline Tabela que armazena dados relativos os baselines de cada ano referentes à energia activa, reactiva e potência. baseline Tabela que armazena todas as baselines do sistema. baseline_value Tabela que armazenam todos os valores associados as baselines do sistema. baseline_appliance Tabela que armazena todos os electrodomésticos associados a uma baseline. hierarchy Tabela que armazena dados relativos a hierarquia existente entre os grupos lógicos. indicators Tabela que armazena dados relativos aos indicadores configurados na plataforma. kpi_error_log Tabela que armazena o registo de erros durante à execução dos procedimentos de cálculo de KPI. kpi_conf Tabela que armazena as configurações usadas pelos procedimentos de cálculo de KPI. kpi_nessage Tabela que armazena as mensagens enviadas pelo gestor de energia. kpi_data Tabela que armazena dados associados aos KPI s. kpi Tabela que armazena os dados associados aos KPI existentes para os quais será feito carregamento de dados. Tabela 25 -Descrição sumária das entidades do diagrama da base de dados Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

116 Arquitectura e Implementação da Plataforma ienergy Eficiência Energética em Edifícios Esquema Relacional A partir do diagrama de entidade relação da BD especificou-se o esquema relacional com as tabelas contendo as respectivas chaves primárias (PKs Primary Keys) e chaves estrangeiras (FKs Foreign Keys). A ISA segue uma série de convenções próprias relativamente ao esquema relacional, por forma a normalizar a BD para que todos a possam perceber sem grande dificuldade. Estas convenções foram aplicadas às tabelas criadas durante o estágio. Todas as tabelas do esquema relacional da base de dados podem ser visualizadas no Anexo V Procedimentos Criados De forma a obter maior performance devido à complexidade e ao tempo necessário para processar alguns dados, foram criados procedimentos na base de dados que podem ser agendados para correr de tempos a tempos. Foram construídos quatro procedimentos: Calcular Tags Virtuais Procedimento que serve para calcular as tags virtuais configuradas no sistema. Calcular Indicadores Procedimento que serve para calcular os KPI s que foram definidos na secção de requisitos. Calcular Tarifários Procedimento que calcula os tarifários de energia que estão configurados no sistema e ligados a um dispositivo. Os tarifários B2B são constituídos por vários parâmetros que têm de ser calculados individualmente e em diferentes períodos do tempo (por hora, por dia ou por mês). O fluxograma seguinte mostra como este cálculo é feito: na sua execução o procedimento procura por tags configuradas como tags de tarifário (como é o caso da energia activa) e esta energia activa é usada para calcular os custos das potências como está descrito no documento de especificação de tarifários. De seguida são procuradas as tags de energia reactiva e são executados os mesmos procedimentos para o cálculo dos respectivos custos (Figura 37). Cálculo da Baseline A baseline é calculada de tempos a tempos por forma a estar de acordo com as alterações que eventualmente forem introduzidas nos grupos lógicos. Para cada conjunto sequencial de baselines executa-se o algoritmo ná Figura Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

117 Não Não ienergy Eficiência Energética em Edifícios Arquitectura e Implementação da Plataforma Inicio Ler dados das tag Tag de Tarifário? Ler Tarifário da Tag Sim (Data de fim- data de inicio)=período de calculo? Calcular custos do parâmetro Sim O tarifário tem parâmetros configurados? SIm Ler os Parâmetros do tarifário Ler período de calculo Não Fim Figura 37 - Fluxograma de cálculo de tarifários B2B Início Ler conjunto sequencial de baselines Fim Não Existe próxima? Sim Sim Baseline do Ano 0? Não Não Já calculada? Sim Baseline mais recente? Não Sim Calcular intervalo de funcionamento da baseline Intervalo superior a 1 mês? Sim Calcular Baseline Figura 38 - Fluxo de cálculo da baseline Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

118 Arquitectura e Implementação da Plataforma ienergy Eficiência Energética em Edifícios Todos estes procedimentos correm como Jobs na base de dados com uma periocidade configurável ou através do agendador de tarefas do Windows Scripts de Migração de Base de dados Como a base de dados já existia foi necessário a criação de scripts de forma a migrar a base de dados onde a nova versão do software fosse instalada, já que existem outras versões do software em produção. Foi então criado um ficheiro.bat que mediante a sua execução migra a base de dados para a nova versão do software. A explicação deste procedimento encontra-se no Manual de Instalação Task Scheduler Este módulo usa o Windows Task Scheduler Service para executar os procedimentos necessárias na base de dados ou algum método C#, como é o caso da verificação de alarmes e actuações. A instalação deste módulo adiciona as entradas necessárias ao Windows Scheduler Service e instala os programas que vão invocar os procedimentos na base de dados ou executar métodos C#. Neste módulo foram acrescentadas duas novas tarefas, uma para os alertas e outra para a actuação sobre dispositivos. O que este Scheduler faz é uma verificação periódica das tarefas que se encontram agendadas. Estas tarefas são: Verificar Alarmes Rotina que verifica a existência de alarmes: caso encontre alguma situação relevante, dispara o respectivo alarme. Os alertas correm numa tarefa do Windows ininterruptamente, com um determinado intervalo de tempo, e verificam-se os alertas configurados no sistema com os respectivos parâmetros. Caso os valores estejam dentro dos parâmetros definidos no alerta é enviado um a confirmar essa situação; em caso de anormalidade é lançado um alerta para o sistema e é também enviado um a avisar do sucedido. Os alertas estão sempre a ser avaliados e a sua validação só termina quando a sua data de avaliação é ultrapassada (Figura 39). Verificar Actuações Esta rotina verifica a existência de actuações: quando é detectada que uma nova actuação deve ser enviada, o sistema envia de seguida uma mensagem para a camada inferior de forma a ser efectuada a actuação sobre determinado dispositivo. 96 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

119 ienergy Eficiência Energética em Edifícios Arquitectura e Implementação da Plataforma Inicio Ler alarmes configurados no sistema Não Não Passou o período de verificação? Sim Sim Não Enviar O alarme esta dentro dos parâmetros? Lançar alarme e enviar mail Terminou o período de avaliação do alarme? Sim Fim Figura 39 Fluxo de funcionamento dos alertas Core da Aplicação O core é o módulo mais importante do software: ele disponibiliza as funções necessárias para manipular as entidades da plataforma, garantindo que os outros sistemas são informados das mudanças que aconteçam nas entidades. O core está implementado sobre a entity framework que é um ORM que permite reduzir em muito o tempo de implementação do mesmo. Contudo, é preciso ter em atenção que este tipo de framework pode ter custos em termos de performance e deve ser considerada a sua utilização em certas situações. O core providencia um repositório para cada tipo de entidade da plataforma. O repository é um design pattern conhecido que faz a mediação entre o domínio da aplicação e a camada de mapeamento de dados, actuando como uma colecção de objectos do domínio em memória. Todas as acções nos repositórios são transaccionais, o que garante a consistência dos dados. Quando uma acção é invocada com sucesso no repositório especificado, o objecto chamado garante que todos os sistemas de terceiros são actualizados com sucesso na sua BD local. Em caso de erro as mudanças são desfeitas. Todos os repositórios são acedidos por uma instância do CoreHandler. Este providencia o acesso aos repositórios e usa a estratégia de lazy loading garantindo que apenas repositórios que são mesmo necessários são instanciados. Esta estratégia já estava a ser seguida pela equipa de energia da ISA. Nos Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

120 Arquitectura e Implementação da Plataforma ienergy Eficiência Energética em Edifícios desenvolvimentos que foram efectuados no core da aplicação foi mantida esta estratégia, sendo criados novos repositórios para suportar as funcionalidades criadas. Estes repositórios foram posteriormente usados pelo web service para retornar os dados necessários à aplicação web. Foram também usados no BackOffice do software para construir os interfaces necessários aos CRUD das entidades. Figura 40 -Diagrama de classes Core (apenas a parte criada durante o estágio) Web Service Como já foi mencionado já existia um web service implementado para lidar com aplicações clientes. Este web service está construído de forma orientada a serviços, com a.net Framework usado 98 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

121 ienergy Eficiência Energética em Edifícios Arquitectura e Implementação da Plataforma o WCF com uma arquitectura SOA. O WCF é uma arquitectura orientada a serviços que permite o suporte a computação distribuída onde os serviços têm consumidores remotos. Clientes podem consumir múltiplos serviços e serviços podem ser consumidos por múltiplos clientes. Estes serviços tem tipicamente um interface WSDL que qualquer cliente WCF pode consumir independentemente da plataforma em que está hospedado End Points Os clientes do WCF conectam-se ao web service através de um end point. Cada serviço expõe os seus contractos através de um ou mais end points. Um end point é um endereço (com um URL que especifica como o end point pode ser acedido) e liga as propriedades que especificam como os dados podem ser transferidos. Durante este estágio foi implementado um end point no web service específico para edifícios. Como é óbvio existem muitas funções em comum entre as diferentes APIs que foram implementadas num único módulo e são herdadas por todas APIs (sendo que o end point de edifícios faz uso desses métodos comuns a todos). A especificação dos métodos expostos pelo web service de edifícios pode ser encontrada no Anexo IV. Figura 41 Diagrama de classes End Point de edifícios Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

122 Arquitectura e Implementação da Plataforma ienergy Eficiência Energética em Edifícios Aplicação Web Neste capítulo pretende-se apresentar a arquitectura da aplicação web que foi construída de raiz durante o estágio Arquitectura Geral O sistema actual é constituído por vários componentes, que permitem a aquisição e tratamento de dados relacionados com o consumo de energia (todos estes componentes estão descritos nas secções anteriores). Nesta secção o foco será na plataforma web que interage com o web service disponibilizado pela plataforma - ienergy -. Figura 42 - Visão Geral do Sistema O - ienergy - é de forma geral constituído por uma plataforma de aquisição de dados e por dispositivos físicos que permitem a monitorização de consumos de variáveis energéticas. Consumidor Fornecedor HTML,JSON XML XML Browser ienergy4buildings IIS.NET Framework Consumer API Intranet ienergy2 Server Services Provider Figura 43 - Arquitectura Web Service 100 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

123 ienergy Eficiência Energética em Edifícios Arquitectura e Implementação da Plataforma O web service disponibilizado pelo - ienergy - permite que aplicações se conectem e interajam pela rede. Construído no topo dos protocolos de internet existentes como o HTTP e o XML, estes permitem a partilha de informação na rede: Internet, Intranet, ou Extranet. Este Web Service e constituído por componentes de software que podem ser chamados remotamente com Simple Object Access Protocol (SOAP). Este web service esta descrito em mais pormenor na secção Arquitectura Lógica A solução tem vários módulos lógicos, cada um com uma funcionalidade específica. Na figura 45 encontra-se uma imagem desta arquitectura. Web Browser Web Application Services HTML Lógica de Apresentação Lógica da Aplicação Camada de Acesso aos Dados Figura 44 - Arquitectura lógica O portal web segue o design partner MVC usado pelo ASP.NET MVC. Cada uma das camadas do modelo MVC tem uma responsabilidade específica definida, neste caso os Models contêm a lógica de acesso ao web service construído em WCF, os Views representam as vista da aplicação, os Controllers encapsulam toda a lógica de negócio. Tal como foi especificado no capítulo anterior, o sistema divide-se em vários módulos principais: Aplicação Web; Web Service; Core; Armazenamento Decomposição Horizontal O sistema segue uma decomposição horizontal com base no modelo MVC, separado em três camadas distintas, como pode ser visto na Figura 45. Essas três camadas são: Interface com o Utilizador (View): O que o utilizador do sistema vê e com o qual interage. Esta camada comunica com a seguinte enviando-lhe os dados introduzidos e recebendo os dados requeridos; Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

124 Arquitectura e Implementação da Plataforma ienergy Eficiência Energética em Edifícios Lógica de Negócio (Controller): É a camada intermédia na qual se faz a comunicação com o web service e com o interface do sistema. Nesta camada é onde os dados são processados e tratados, sendo também feita a comunicação com os vários módulos que compõem o sistema. Esta camada é responsável por garantir um bom funcionamento, no geral; Base de Dados (Model): Camada na qual é feito o armazenamento da informação. Essa informação inclui as tags, informação associada e informação dos tarifários, entre outros. uc Use Case Model Interface com o utilizador(view) Logica de negocio(contoller) Base de dados (Model) Figura 45 - Decomposição Horizontal Decomposição Vertical A decomposição vertical é feita por subsistemas, de forma hierárquica, em que cada subsistema corresponde a um grupo de funcionalidades e abrange todas as camadas da implementação. No fundo, a decomposição vertical aqui apresentada coincide com os módulos e sob módulos já apresentados na especificação de requisitos. A Figura 46 dá uma ideia geral da arquitectura lógica por detrás deste sistema (nem todos os módulos foram incluídos na imagem). Neste diagrama pode-se verificar a organização do sistema em termos de camadas físicas, ou seja, máquinas e componentes clientes e servidores. Pretende documentar-se a estrutura física de alto nível do software, no que respeita a máquinas, conexões, componentes instalados nas máquinas e dependências entre componentes. Em relação ao local onde o web service e a aplicação web ficam alojados, optou-se por colocá-los no mesmo servidor, pois o acesso é directo, permitindo à partida um melhor desempenho. 102 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

125 ienergy Eficiência Energética em Edifícios Arquitectura e Implementação da Plataforma Figura 46 - Decomposição Vertical Camada da Interface com o Utilizador A primeira camada é a camada de Interface com o Utilizador. Quando um utilizador realiza uma acção invoca um método nesta camada e é accionado o pedido correspondente na camada Lógica de Negócio (no web service) Camada de Lógica de Negócio Grande parte do desenvolvimento do projecto insere-se nesta camada, sendo esta responsável por processar os métodos provenientes dos eventos da interface. Nesta camada encontram-se os diversos módulos funcionais que agregam todas as funcionalidades constituintes do sistema referidos na secção 6. Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

126 Arquitectura e Implementação da Plataforma ienergy Eficiência Energética em Edifícios Camada de Acesso a Dados Esta camada manuseia a comunicação entre a camada superior, a lógica de negócio e a camada de Dados. É uma das camadas de maior importância, uma vez que é nesta camada que são feitos os pedidos (select, insert, update etc.) à base de dados, de acordo com as regras e lógica do negócio. Para a comunicação entre a lógica de negócio e a camada de dados, foi utilizado o ADO.NET Entity Framework Camada de Dados Esta camada representa a localização física de todos os dados essenciais ao sistema. Na componente de base de dados encontram-se armazenadas as tabelas do modelo relacional, sendo que, o SGBD utilizado é o Microsoft SQL Server Camada Transversal de Autenticação Para poder aceder às várias funcionalidades do sistema tem de se garantir que o cliente se autenticou anteriormente na aplicação através de web service com o Servidor Camadas da Aplicação Web A aplicação web segue o modelo MVC, e como tal tem-se a aplicação dividida nas três camadas já mencionadas: model, view e controller. Nas subsecções seguintes detalha-se cada uma dessas camadas, dizendo como estão organizadas e os seus modelos de classes. A camada controller é descrita antes da camada view uma vez que é mais fácil explicar por essa ordem. Numa aplicação em ASP.NET MVC, como é o caso, é criada com uma estrutura bem definida, que segue precisamente este modelo. No entanto existe uma parte associada ao view, os helpers, os quais servem para melhor separar a interface do código em C#. Podem-se criar métodos em helpers que depois podem ser usados nas vistas do view Model Esta camada é a camada que acede aos dados no web service, e como tal no geral representa o conteúdo da BD disponibilizado através dos web services. Existe um mapeamento entre os objectos que estão no web service e na aplicação web. 104 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

127 ienergy Eficiência Energética em Edifícios Arquitectura e Implementação da Plataforma Figura 12 - Diagrama de classes do Model Todo o código encontra-se documentado através do uso de NDoc, contendo as definições de todos os métodos e classes Controller Nesta camada encontra-se toda a lógica da aplicação, ou seja, as classes e métodos que comunicam com o model para aceder e manipular os dados e também com a view para mostrar o output ao utilizador e receber o seu input. Nesta camada existe a classe BaseController, a qual contém filtros e métodos acessíveis por todas as outras classes terminadas em Controller. É nesta classe que são definidos os métodos que controlam os acessos dos utilizadores da aplicação, assim como se faz a gestão do acesso ao web service através do override de alguns métodos herdados da classe controller como o OnActionExecuting, OnActionExecuted, Dispose. A maior parte das classes aqui existentes vão de encontro aos módulos que se tinham definido, o que pode ser facilmente visto pelos seus nomes. No entanto, tal como a classe já descrita, existem várias outras com outras funções. Uma breve descrição de cada uma será feita de seguida. Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

128 Arquitectura e Implementação da Plataforma ienergy Eficiência Energética em Edifícios Em relação às classes referentes aos módulos dos casos de uso da aplicação, contêm os métodos referentes a cada caso de uso. Nestas classes cujo nome termina em Controller são disponibilizados métodos para listas com paginação, criar, pesquisar editar e remover os objectos que essa classe gere. A classe ExcelController permite exportar todo o tipo de dados para ficheiros Excel. A AccountController disponibiliza métodos para realizar a autenticação com a camada model assim como métodos para fazer a gestão da própria conta de utilizador. Na Figura 47 pode-se analisar o diagrama de classes desta camada, contendo os nomes dos vários métodos de cada classe (sem os parâmetros, para simplificar o diagrama). Figura 47- Diagrama de classes do Controller 106 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

129 ienergy Eficiência Energética em Edifícios Arquitectura e Implementação da Plataforma Todo o código encontra-se documentado através do uso de NDoc, contendo lá as definições de todos os métodos e classes Action Filters O action filter é um atributo que pode ser aplicado a um controller todo ou a uma acção individual de um controller de forma a correr algum código antes ou depois de uma acção ser executada. A autenticação com o web service do - ienergy - tem a particularidade de o token apenas ter a duração de uma hora tendo de ser refrescado para não expirar. Um dos action filters implementados faz precisamente isso, i.e. refresca o token. Existe ainda outro que trata eventuais excepções que aconteçam de forma inesperada de forma a não enviar uma mensagem com conteúdo não desejável para o cliente. Figura 48 - Modelo de classes dos Action Filters View Esta camada está na sua maioria organizada de acordo com o controller. No entanto não se trata de classes, como nas outras duas camadas. Como se trata de uma interface web, o ASP utiliza um tipo de ficheiro (ASPX no caso das views ou ASCX no caso das partial views) para cada vista, que contém HTML com código C# embutido assim como métodos de ASP que geram HTML. Dessa forma a estruturação é feita por pastas e ficheiros em que cada pasta corresponde a um controller, e no interior de cada pasta encontra-se um ficheiro aspx para cada action que tem uma vista associada. Por exemplo, para o método Add da classe ActionController existe a pasta Actions e lá dentro o ficheiro Add.aspx contendo a vista para essa acção. No entanto, para além desses ficheiros existem ainda outros que terminam em ascx, chamados de parcials views. Esses últimos não contêm uma vista completa mas sim uma parte apenas e podem ser usados noutras views. Os parcials que podem ser usados em vistas fora da própria pasta são colocados numa pasta shared, e no caso desta aplicação essa pasta contém os Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

130 Arquitectura e Implementação da Plataforma ienergy Eficiência Energética em Edifícios parcials para listagem, entre outras. Com excepção para a pasta de layouts, ou seja: a pasta de layouts contém o layout da aplicação web, existindo um master layout que é usado por todas as outras vistas HTML Helpers Do view fazem ainda parte os helpers, localizados na pasta de Helpers. Trata-se de classes especiais nas quais se pode criar métodos para utilizar nas vistas por forma a separar melhor o código C# do código HTML. No entanto faz parte desta camada e tal como nome indica, servem para ajudar o interface, sem misturar o código demasiado. Os html helpers podem ser usados nas vistas do modelo MVC, e são apenas um método que retorna uma string. A string pode representar tipo de conteúdo que quisermos. Por exemplo, podemos usar os helpers para renderizar qualquer tag HTML standard como o <input> ou <img>. Podemos usar os helpers também para renderizar dados mais complexos como uma tabela de dados da base de dados. public class LabelHelper { public static string Label(string target, string text) { return String.Format("<label for='{0}'>{1}</label>", target, text); } } Código 1 - Exemplo de um Helper Nesta aplicação foram usados alguns helpers, sendo um dos principais o PaginatedList, que é o helper cujos métodos ficam disponíveis para todas as vistas e que permite a paginação das tabelas. Um desses métodos é o método que devolve os links para andar para a frente e para trás nas páginas, o PaginationLinks. Na Figura 50 pode-se analisar o diagrama de classes de helpers desta camada, contendo os nomes dos vários métodos de cada classe (sem os parâmetros, para simplificar o diagrama). 108 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

131 ienergy Eficiência Energética em Edifícios Arquitectura e Implementação da Plataforma Figura 49 - Diagrama de classes dos helpers do view Todo o código encontra-se documentado através do uso de NDoc, contendo lá as definições de todos os métodos e classes Binders Um grande desafio nas aplicações web é passar tipos complexos e ainda mais difícil passar objectos stateful de uma página para outra. Esta dificuldade existe devido a natureza desligada da web. Têm existido várias tentativas para resolver este problema (sessions, ViewState, etc), mas o novo modelo do ASP.NET MVC os Model Binders é definitivamente uma maneira simples, limpa e poderosa de resolver este problema. No Código 2 está um exemplo de um helper usado neste projecto para construir um objecto, neste caso fixed_cost, fazendo também algumas validações, sendo que algumas destas validações são também feitas do lado do cliente através de plugins jquery. public object BindModel(ControllerContext controllercontext, ModelBindingContext bindingcontext) { HttpContextBase context = controllercontext.httpcontext; ModelStateDictionary modelstate = bindingcontext.modelstate; var fx = (fixed_cost)(bindingcontext.model?? new fixed_cost()); // fxc_description string temp =controllercontext.httpcontext.request.form["fxc_description"]; fx.fxc_description = Validations.ValidateRangeString(context, modelstate, temp, "fxc_description", Properties.Resources.FIXEDCOST_DESC_MIN_LENGTH, Properties.Resources.FIXEDCOST_DESC_MAX_LENGTH); // fxc_price temp = controllercontext.httpcontext.request.form["fxc_price"]; fx.fxc_price = Validations.ValidateDecimal(context, modelstate, temp, "fxc_price", false); // contracted_power temp = controllercontext.httpcontext.request.form["contracted_power"]; if (!string.isnullorempty(temp)) { fx.contracted_power = Validations.ValidateDecimal(context, modelstate, temp, "contracted_power", false); } else { fx.contracted_power = null; } // tar_id temp = controllercontext.httpcontext.request.form["tar_id"]; fx.tar_id = Validations.ValidateInteger(context, modelstate, temp, "tar_id", false); return fx; } Código 2 - Exemplo de um Binder Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

132 Arquitectura e Implementação da Plataforma ienergy Eficiência Energética em Edifícios estágio. Na Figura 50 é apresentado o modelo de classes dos binders construídos durante o projecto de Figura 50 - Modelos de classes dos Binders Jquery Plugins Por forma a não se reinventar a roda, utilizaram-se plugins específicos para algumas tarefas (jquery). Um plugin é adicionado directamente na pasta do projecto, na pasta /Scripts/. Durante a implementação da aplicação web houve a necessidade de recorrer a vários plugins jquery para além dos que o ASP.MVC contém por omissão. Para validação de dados do lado do cliente, construção de gráficos, componentes de calendários entre outros plugins que permitiram simplificar em muito a implementação do portal web. 7.4 Problemas Encontrados Nesta secção são descritos alguns problemas encontrados durante o desenvolvimento da aplicação, bem como a solução para eles encontrada Árvore de Grupos Durante o primeiro sprint do desenvolvimento não foi possível ter acesso a uma base de dados de produção com dados mais aproximados da realidade. Durante os testes efectuados pela equipa da ISA já sobre uma base de dados de produção foi notado que a árvore de grupos com 40 grupos estava um pouco lenta, e tendo em conta que se pretendia atingir os 400 grupos de topo, e juntado a estes os grupos inferiores, isto tornaria a situação insustentável. Foi então decidido na segunda fase efectuar um 110 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

133 ienergy Eficiência Energética em Edifícios Arquitectura e Implementação da Plataforma teste de carga à árvore criando os 400 grupos de forma a ser possível identificar possíveis optimizações. Neste teste de carga foi possível ver que a árvore não suportaria o número de grupos que estavam definidos Solução A solução arranjada para este problema foi a utilização de lazzy loading no carregamento dos grupos, sendo que assim os grupos iam sendo carregados à medida que iam sendo necessários. Aliado a isto foram também feitas optimizações do lado do - ienergy - com a introdução de índices nestas tabelas. Com estas modificações foi possível responder às necessidades em termos de performance no carregamento dos grupos lógicos Acessos a Tabela de Dados Um dos principais problemas encontrados durante a fase de testes foi o acesso concorrente à tabela de dados. Esta tabela é onde são guardados os dados vindos das unidades referentes as variáveis energéticas já com algum tratamento e validação. Estes dados são posteriormente agregados de forma a serem disponibilizados ao utilizador. Mas como não existem algumas agregações necessárias a algumas funcionalidades, por exemplo para os tarifários industriais são necessários dados agregados de 15 minutos é então necessário aceder directamente a esta tabela para fazer alguns cálculos demorados. Esta tabela já tinha alguns problemas antes deste desenvolvimento, mas foi com este desenvolvimento que se tornou evidente que esta tabela tinha graves problemas de concorrência já que está sempre a ser escrita e é lida por vários módulos deste desenvolvimento e de outros. Este acesso provoca deadlocks na tabela que torna a aplicação mais lenta em algumas situações Solução Para resolver esta situação foram criados procedimentos na base de dados que diariamente vão précalculando alguns dados. Estes são armazenados em tabelas auxiliares que posteriormente são consultadas pelas funcionalidades que deles necessitam. Estes procedimentos correm apenas durante a noite de forma a permitir que o sistema esteja operacional durante o dia. Esta é apenas uma solução temporária já que não existia tempo para proceder a uma modificação profunda no armazenamento dos dados. Mas esta mudança já esta prevista para futuras versões do software. Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

134 Arquitectura e Implementação da Plataforma ienergy Eficiência Energética em Edifícios 7.5 Testes unitários Durante o desenvolvimento foram elaborados testes unitários para validar as funcionalidades que iam sendo construídas. Estes testes visaram apenas cada um dos módulos individualmente. Serviram para ter um conjunto de testes de regressão com cobertura de código próxima dos 80%. Nem tudo foi submetido a testes unitários, mas sim apenas os módulos em que se justificava, tais como, por exemplo, o cálculo de tarifários assim como os novos repositórios implementados no core da aplicação e os métodos do web service. Na aplicação web não foram realizados testes unitários já que a maior parte da lógica estava do lado do web service e não me pareceu que se justificasse o esforço que seria testar a mesma coisa duas vezes. 7.6 Opinião Todos os requisitos que foram especificados na secção 6 foram implementados com sucesso, apesar de haver espaço para a melhoria de alguns deles e para a introdução de outros. A maior dificuldade na implementação prendeu-se com o facto da pouca experiência que se tinha com as tecnologias de desenvolvimento usadas durante o projecto de estágio, tendo por isso sido necessário algum tempo suplementar. Foram também sentidas dificuldades na implementação de alguns requisitos por não terem uma especificação completa, pelo que se teve muitas vezes de esclarecer requisitos na fase de implementação de forma a certificar-me que o que era implementado era o que o cliente realmente pretendia. 112 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

135 ienergy Eficiência Energética em Edifícios Verificação e Validação 8 Verificação e Validação A qualidade do projecto foi sendo controlada, tendo passado por um conjunto de testes e revisões. 8.1 Revisão O software passou por várias revisões, uma por cada iteração na fase de desenvolvimento, de forma a obter-se uma imagem de como se encontrava a implementação dos requisitos definidos. Esta revisão é uma avaliação qualitativa, uma apreciação sobre o estado da implementação de um determinado requisito ou funcionalidade, escrita de documentação, etc... Exemplo: A aplicação efectua Autenticação mas o visual pode ser melhorado. No que diz respeito às revisões feitas durante o projecto, o software passou sempre a fase de teste, o que não quer dizer que não foram encontras anomalias na implementação dos requisitos, mas apenas que não eram muito graves e não impediam a sua realização. 8.2 Validação No fim de cada sprint o sistema foi testado por uma equipa de testes da ISA, que fez tanto os testes de sistema como os testes de aceitação. Após a implementação do software ter sido concluída era crucial testá-lo para validar o seu correcto funcionamento e garantir que este cumpria os requisitos especificados inicialmente Ambiente de Testes Para fins de teste, foi feita uma publicação do software num servidor de testes da ISA, com uma base de dados que era um backup de uma base de dados de produção. Foram também instaladas algumas unidades de hardware para comunicarem para o sistema validando assim a aplicação dos tarifários, funcionalidade crucial no software bem como a actuação. A especificação dos testes a executar ao software implementado foi feita pela equipa de testes da ISA (não foi portanto da minha responsabilidade). Após a execução dos testes os defeitos foram reportados na ferramenta JIRA e foram corrigidos. Os respectivos testes foram realizados outra vez, para determinar se essa correcção foi efectivamente feita com sucesso. O software desenvolvido foi submetido a casos de teste de vários tipos, usando diferentes métodos e que foram executados a vários níveis. Para a realização dos testes funcionais e de sistema foi alocado tempo com um engenheiro de testes da ISA, que efectuou esses mesmos testes. Desta forma, não estive directamente envolvido no teste da aplicação, tendo participado apenas na execução dos testes unitários. Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

136 Verificação e Validação ienergy Eficiência Energética em Edifícios Tipos de teste Cada um dos casos de teste efectuados ao software está associado a um ou mais requisitos de um desses programas. Uma vez que o software possui requisitos funcionais e não funcionais, foram igualmente especificados testes destes dois tipos para serem executados sobre todo o software desenvolvido. Métodos de teste Geralmente são considerados três métodos diferentes para a realização de testes os testes de caixa preta, os de caixa branca e os de caixa cinza: Testes de caixa preta Testes efectuados sem conhecimento da implementação interna da aplicação que é testada [23]. Testes de caixa branca Testes realizados com conhecimento prévio do código fonte que implementa o software que é testado [23]. Testes de caixa cinza Testes que partilham características dos testes de caixa preta e de caixa branca, uma vez que apenas é testado o comportamento exterior do programa (tal como nos testes de caixa preta) mas em que existe conhecimento do seu código fonte (tal como nos testes de caixa branca), o que permite escolher os casos de teste a fazer de uma forma mais informada [23]. Níveis de teste Existem diversos níveis a que podem ser realizados casos de teste a software. No caso da aplicação a desenvolver no âmbito do estágio ienergy - Eficiência energética em edifícios considerei que faria sentido submetê-las a testes unitários (já mencionados na secção de implementação), de componentes, de regressão, de aceitação, de integração e de sistema (testes funcionais) e de carga, de estabilidade e de segurança (testes não funcionais). Os testes funcionais testam partes do código (geralmente funções ou métodos e classes, se o software tiver sido implementado com recurso a programação orientada a objectos). Ainda dentro dos testes funcionais justifica-se fazer testes de integração de sistema, uma vez que a aplicação desenvolvida está integrada com um sistema complexo. Em termos de testes não funcionais, os testes de carga procuraram, sobretudo, avaliar a escalabilidade do software desenvolvido. 8.3 Verificação O software foi entregue ao cliente, pelo que este realizou uma verificação que consistiu numa avaliação da solução implementada. O resultado desta verificação foi que o software estava pronto para produção. Contudo foi retirada a funcionalidade de actuação desta publicação já que não foi possível testá-la a fundo. Tratando-se de uma funcionalidade que poderia trazer alguns problemas, foi decidido não a incluir na produção nesta 114 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

137 ienergy Eficiência Energética em Edifícios Conclusões e Perspectivas Futuras fase. Depois desta verificação final o software foi instalado e entregue o manual de utilizador, presente no Anexo VII. Deste manual apenas fazem parte as funcionalidades que constituíram este estágio e algumas funcionalidades de suporte (como é o caso dos códigos postais, que apenas foram usados na funcionalidade de tarifários). 8.4 Instalação no Cliente Depois do software estar devidamente validado foi preparada a sua instalação no cliente, e criado um pacote de instalação. Foi também redigido um guia de instalação. O software foi instalado num servidor dedicado gerido por uma entidade externa, tendo a instalação sido feita por esta entidade com o acompanhamento de um elemento da ISA. As componentes de hardware levaram vários meses a instalar devido à quantidade de locais, sensivelmente 400 separados geograficamente. Assim, foram instaladas cerca de 400 unidades, cada uma composta por um número variável de dispositivos (cerca de cinco por unidade). Estes dispositivos são industriais e permitem ler cerca de 27 váriaveis energéticas diferentes, desde energia activa, energia reactiva, factor de potência e temperatura, entre outras. No total o sistema inclui cerca de tags (variáveis energéticas). Actualmente, as tabelas de dados já contém milhões de registos. Depois da instalação foi dada formação aos utilizadores do software, com foco nos tarifários e alarmes por se tratar de duas componentes muito importantes para esta fase inicial do projecto. O objectivo final deste software é o de auxiliar os gestores de energia na redução de 25% do consumo energético destes edifícios. Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

138

139 ienergy Eficiência Energética em Edifícios Conclusões e Perspectivas Futuras 9 Conclusão e Perspectivas Futuras 9.1 Planeamento Efectivamente Seguido Como é habitual, o planeamento de um projecto de software não é tarefa fácil! E muitas vezes o planeamento inicial não é conseguido, por diversos factores. Esta secção pretende justificar os atrasos ocorridos quer no primeiro semestre, quer no segundo. O período de estágio decorreu sempre nas instalações da ISA, com excepções pontuais tais como trabalho realizado esporadicamente fora da empresa, e reuniões com o orientador do DEIS/ISEC Planeamento Efectivamente Seguido no Primeiro Semestre O trabalho realizado neste intervalo de tempo foi feito em regime de tempo parcial mas com recurso a horas extra para fazer face a algumas das tarefas realizadas neste período inicial. Este esforço inicial foi necessário para me ambientar às metodologias e ao trabalho na empresa, já que possuia apenas um background académico e encontrei uma realidade nova. Foi feita uma análise temporal do trabalho feito até aqui, que pode ser visualizada no diagrama de gantt presente na Figura 51. Figura 51 Diagrama de gantt com a distribuição temporal do trabalho realizado no primeiro semestre. Os atrasos verificados no decurso do primeiro semestre da realização deste estágio deveram-se, sobretudo, a alguns atrasos no arranque do projecto devido a questões de negócio (que a mim são alheias), e também a dificuldades na aquisição dos requisitos, quer por dificuldades do cliente em explicar aquilo que pretendia, quer pela minha dificuldade em entender alguns dos requisitos, já que a área de energia não estava dentro dos meus conhecimentos na altura. O primeiro passo dado, como normalmente se faz nestes casos, foi estudar as aplicações que de alguma forma fossem parecidas com aquela que se pretendia implementar inicialmente, ou seja, fazer o levantamento do estado da arte nesta área. Depois deste estudo inicial estive momentaneamente integrado na equipa do projecto de Monotorização energética em embarcações, para me integrar com o processo de desenvolvimento da Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

140 Conclusões e Perspectivas Futuras ienergy Eficiência Energética em Edifícios empresa e para estudo das tecnologias que iriam ser usadas durante o estágio e também pelas questões de negócio já mencionadas anteriormente. Foi este o passo que mais atrasou o projecto. Depois de o projecto de estágio ter sido desbloqueado, o primeiro passo foi fazer o estudo das tecnologias a utilizar, o que devia ter sido feito logo após o estudo do estado de arte. O segundo passo foi a recolha de requisitos com o cliente da plataforma. Esta recolha de requisitos foi bastante demorada, tendo existido várias dificuldades de comunicação entre a equipa de desenvolvimento e a BU de energia. Porque existiam vários stakeholder s para o projecto, estas dificuldades foram eliminadas quando se decidiu colocar apenas uma pessoa como stakeholder que posteriormente sincronizava com todos os outros stakeholder s. Por tudo isto, o estágio a que este relatório se refere sofreu bastantes atrasos e desvios ao planeamento delineado inicialmente. É de notar que ao longo de todo este processo o tema base do estágio (gestão energética) foi sempre mantido. Essa foi, aliás, uma preocupação constante da direcção da ISA, visto que o era esse o tema do meu estágio ienergy Eficiência Energética em Edifícios, tal como já foi explicado na secção Planeamento Efectivamente Seguido no Segundo Semestre O trabalho realizado neste intervalo de tempo foi feito em regime de tempo inteiro mas com recurso à utilização de horas extra para fazer face às tarefas necessárias (ou seja, com um esforço superior a 40 horas semanais). Foi feita uma análise temporal cuidada do trabalho realizado ao longo deste último semestre, recorrendo-se a um diagrama de gantt. Esse diagrama pode ser visualizado na Figura 52. Figura 52 Diagrama de Gantt com a distribuição temporal do trabalho realizado no segundo semestre. Tal como se pode ver na Figura 52, o segundo semestre iniciou-se com a finalização do documento de requisitos, durante cerca de duas semanas. De seguida, foi aprofundada a especificação técnica da 118 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

141 ienergy Eficiência Energética em Edifícios Conclusões e Perspectivas Futuras aplicação desenvolvida (que já tinha sido iniciada no primeiro semestre), o que demorou cerca de cinco semanas. Durante esse período de tempo foram definidas as linguagens de programação e tecnologias que foram posteriormente utilizadas na fase de implementação. De seguida foram construídos alguns protótipos com as tecnologias de gráficos e de relatórios. A implementação demorou cerca de três meses e, por fim, a escrita do relatório foi feita ao longo de todo o semestre, documentando o trabalho à medida que este foi realizado. Nesta fase não existiram desvios para o planeamento que feito inicialmente Justificação dos Desvios Os desvios que se verificaram na planificação proposta inicialmente deveram-se, sobretudo, a dois aspectos: O facto do projecto de estágio ter sido iniciado com algum atraso. O tempo extra que foi dispendido na análise da especificação dos requisitos para a plataforma. No que diz respeito ao segundo factor apresentado na lista acima, o facto da especificação da aplicação ter sido iniciada ao mesmo tempo que o estágio e o facto de eu não ter grande formação na área da energia e de durante algum tempo não ter sido possível ao cliente da aplicação especificar de forma mais detalhada os requisitos, contribuíram decisivamente para o atraso geral de todo o projecto, tendo sido consumido precioso tempo extra que poderia ter sido usado para realizar outras tarefas. Existiram ainda outros atrasos, não tão graves, em outras tarefas realizadas, mas que são perfeitamente aceitáveis no decurso de um projecto de desenvolvimento de software. A maior dificuldade que encontrei no decurso do primeiro semestre deste estágio foi a indefinição nos objectivos do projecto, especialmente no início do semestre. De facto, tal como é descrito detalhadamente nas secções anteriores, o estágio sofreu diversas alterações desde o seu início, e apenas numa fase adiantada do semestre soube concretamente o trabalho que iria desenvolver no segundo semestre. No fundo, acabei por experienciar directamente as vicissitudes inerentes ao trabalho no seio de empresas da área das TI, em que nem sempre as coisas correm como planeado inicialmente e em que projectos que aparentemente se vão realizar, no fim acabam por não se concretizar ou então decorrem com calendarizações diferentes das definidas no seu início. 9.2 Avaliação do Trabalho Desenvolvido A experiência numa empresa que actua em vários países e já com vários prémios nas áreas em que actua proporcionou uma maior responsabilidade e entendimento das características do mercado Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

142 Conclusões e Perspectivas Futuras ienergy Eficiência Energética em Edifícios relativamente às empresas de Tecnologias da Informação. Com esta experiência obtiveram-se diversos ganhos tanto na área tecnológica como na pessoal. Para que o se tenha obtido a eficiência desejada, contribuiu em grande parte a afinidade existente com as actividades realizadas e mesmo com o software desenvolvido na empresa, dado que esta é uma área em que se tinha bastante interesse. A preocupação da empresa em garantir a qualidade dos seus produtos e em garantir a colaboração e comunicação entre todos os seus colaboradores foi algo sempre presente e observável. Isto proporcionou que adquirisse muito rapidamente maior qualidade pessoal e profissional no desenvolvimento prático das técnicas que já conhecia. Uma das características marcantes neste projecto e que talvez seja o seu principal factor de sucesso, foi a multidisciplinaridade. Desde a fase de concepção, diversos profissionais das áreas de energia, hardware, software e marketing estiveram envolvidos. Estas múltiplas visões acerca do problema possibilitaram que a aprendizagem fosse guiada com maior heterogeneidade, observando as várias dimensões envolvidas, garantindo o alinhamento estratégico entre tecnologia, usabilidade, gestão de energia, parcerias comerciais e anseios do mercado consumidor. Este estágio iniciou o estudo e especificação de requisitos do mercado B2B na área de energia da ISA. Este estudo e especificação ocuparam uma grande parte do tempo útil do estágio, havendo inicialmente apenas o documento inicial elaborado pelo departamento de marketing da ISA. Pode-se dizer, em suma, que durante o estágio se concluiu com sucesso a criação do sistema previsto, tendo-se implementado o que era mais prioritário por forma a ter-se um sistema base completo, que poderá no futuro ser complementado com novas funcionalidades. As tecnologias que foram utilizadas revelaram-se adequadas à solução proposta, e permitem ainda realizar um melhoramento significativo numa próxima fase, uma vez que disponibiliza um grande leque de facilidades. Estas facilidades passam pela existência abundante de plugins, os quais devido à sua enorme quantidade e complexidade não foram possíveis de estudar durante os nove meses de estágio. No entanto, serão certamente uma mais-valia no melhoramento do sistema desenvolvido. O modelo MVC adoptado na divisão da aplicação em camadas distintas com funcionalidades bem definidas, foi crucial para se realizar um melhor desenvolvimento do sistema, onde a detecção e correcção de erros foram mais facilmente realizados. Desta forma, o trabalho desenvolvido durante o estágio cumpriu todos os objectivos a que se propunha. Por último, após todos os pontos enunciados, pode concluir-se que o projecto se está a revelar de grande sucesso, na sua área. 120 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

143 ienergy Eficiência Energética em Edifícios Conclusões e Perspectivas Futuras 9.3 Trabalho Futuro Como já foi referido nas secções anteriores, esta plataforma é constituída por vários módulos por si só de uma complexidade considerável. No futuro imediato pretende continuar-se o desenvolvimento da plataforma - ienergy - acrescentando-lhe novas funcionalidades: por um lado, evoluir o software e incluir características tais associadas a tempo real; por outro lado, evoluir as funcionalidades já implementadas (como é o caso da actuação), de forma a permitir não só a do tipo agendada mas também a automática, em caso de ocorrências anormais, em estreita relação com os alarmes. Existe ainda espaço para introdução de melhorias nas funcionalidades que foram construídas no âmbito deste estágio. A curto prazo, deverão ser claramente identificadas e introduzidas no software. Devido ao tempo reduzido do estágio não foi possível realizar testes de carga exaustivos. Por esse motivo e como se pretende que o sistema responda eficazmente, tendo em simultâneo muitas funcionalidades, será também necessário efectuar testes mais exaustivos e com maior carga do que aquela a que o sistema já foi sujeito. Num futuro próximo a plataforma irá evoluir para outros mercados como o mercado B2C, chegando desta forma ao consumidor final. Oferecendo um leque alargando de funcionalidades inovadoras, como a visualização de consumos em tempo real, melhorias à actuação entre muitas outras coisas, permitirá ao consumidor final racionalizar a sua utilização de energia. A longo prazo pretende-se evoluir a plataforma para produzir uma melhor análise dos consumos energéticos, pretendendo-se introduzir técnicas de BI de forma a melhor tratar os dados recebidos, identificando assim mais facilmente comportamentos desviantes. 9.4 Considerações Pessoais Posso dizer que a realização deste estágio, com a duração de nove meses, foi uma experiência não só muito gratificante como também de elevada importância, quer a nível pessoal quer a nível profissional. Foi uma oportunidade única de conhecer por dentro o mundo real da engenharia informática e poder conhecer de perto todo o processo de concepção e desenvolvimento de software. Com este estágio tive a excelente oportunidade de trabalhar na equipa de energia da ISA em Coimbra. Gostaria de destacar o bom ambiente de equipa e a camaradagem nela vivida, havendo apoio e entreajuda entre os vários colaboradores, ambiente no qual fui bem recebido. Tive ainda o privilégio de melhorar significativamente os meus conhecimentos na área de concepção e desenvolvimento de sistemas de informação. A utilização da plataforma ASP.NET MVC e a Entity Framework, que são bastante recentes e têm suscitado um interesse crescente por toda a comunidade, foi também uma grande uma mais-valia.no entanto, a aprendizagem das tecnologias Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

144 Conclusões e Perspectivas Futuras ienergy Eficiência Energética em Edifícios utilizadas foi autodidacta, embora tenha tido sempre a disponibilidade de ajuda por parte dos colaboradores da equipa de energia e o apoio indispensável do meu orientador na ISA. As maiores dificuldades que senti foram principalmente devidas ao facto de ter de tomar várias decisões com as quais fui confrontado pela primeira vez, nomeadamente a escolha das tecnologias a usar, bem como o estudo, implementação e recolha de requisitos. O facto de o software ter como objectivo ser entregue a cliente e ser operacionalizado, traduziu-se, também, num enorme sentido de responsabilidade colocado sobre mim e num sentimento extra de dedicação e entrega da minha parte para que tudo corresse como planeado. Por tudo isto, posso afirmar sem sombra de dúvida que o trabalho realizado no contexto deste estágio contribuiu de forma inequívoca para o meu crescimento, tanto a nível pessoal como a nível profissional. 122 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

145 Glossário de Definições ienergy Eficiência Energética em Edifícios Glossário e definições Infra-estrutura de medição avançada Compreende todo o hardware e software de comunicações e o software de sistema e de gestão de dados associados que criam uma rede entre os contadores inteligentes e os sistemas de negócio de uma empresa geradora/fornecedora de energia que permitem a recolha e distribuição de informação aos clientes e a outras partes tais como fornecedores a retalho concorrentes, para além da empresa de utilidade pública em si. Leitura automática de contadores Sistema onde o uso (e em alguns casos a procura) agregado de energia em kilowatts por hora é obtido através de meios automáticos, tais como um veículo ou um sistema portátil capaz de ser transportado na mão. Utilização Racional de Energia (URE) - Acções conducentes à redução dos custos da energia para o consumidor e para a economia, numa perspectiva técnico-económica de custo benefícios. Baseline Uma baseline é uma 'imagem' de uma versão anterior no caso da eficiência energética de consumos passados. Ela funciona como um padrão oficial básico para outros estudos. Somente mudanças autorizadas podem ser efetuadas na baseline. Depois de se estabelecer uma baseline inicial, toda as mudanças feitas na baseline serão registadas como um elemento delta até a próxima baseline ser definida. Gestão de energia - De uma forma simples podemos dizer que a gestão de energia: é conhecer os consumos energéticos: o porquê se consome a energia o como se consome a energia o onde se consome a energia o quanto se consome de energia é contabilizar e seguir a evolução dos consumos de energia é dispor de dados para tomar decisões é agir para optimizar é controlar o resultado das acções e investimentos realizado Recolha de dados Contabilização dos consumos energéticos Tomada de medidas correctivas e preventivas Tratamento de informação Elaboração de relatórios

146 Glossário de Definições ienergy Eficiência Energética em Edifícios Figura 53 - Ciclo de Gestão de energia Eficiência energética - Eficiência energética é um conceito generalizado para referir as medidas a implementar (ou implementadas) bem como os resultados alcançados na redução do crescimento da procura de energia ou, mais genericamente, na melhor utilização da energia. As medidas de eficiência energética estão normalmente associadas a medidas políticas ou ao resultado de actos de gestão energética. Os instrumentos mais usuais para medir a forma como a energia é utilizada, quer ao nível micro quer ao nível macroeconómico, são os indicadores energéticos. Existe, assim, um universo de indicadores que permitem, no seu conjunto, estabelecer uma série de avaliações e comparações, quer estáticas quer dinâmicas, sobre o estado da eficiência energética. Gestão da procura de Energia - Acções de Gestão cujo objectivo é modificar a estrutura da procura de energia com vista à redução de custos. Conservação de Energia - Redução da quantidade de energia consumida para uma determinada prestação energética. Economias de Energia - Quantifica as reduções no consumo de energia, relativamente a um valor de referência. Eficiência Energética - Caracteriza a forma como a energia é usada na economia Melhorias na Eficiência Energética Resultado de acções de Utilização Racional de Energia. Indicadores Energéticos - Relações e variáveis usadas para medir a eficiência energética. Web Methods- Motor de integração de aplicações, com capacidades de comunicação e transformação de mensagens. Windows - Família de sistemas operativos da Microsoft. WEB - Aplicação da Internet baseada em páginas de hiper-texto, com conteúdos multimédia. Torniquetes - Controlam a entrada de passageiros na embarcação permitindo ao sistema calcular as cargas de cada percurso com base em informação estimada de passageiros e combustível. Unidade GPS - Permite saber a cada instante a posição, velocidade e outros dados de interesse relativos às diversas embarcações a monitorizar. Caudalímetro - Permite a monitorização de consumos instantâneos. Em conjunto com o datalogger permitirá o cálculo dos consumos entre horários. Será a fonte da informação de consumos energéticos a utilizar na solução. 124 Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

147 ienergy Eficiência Energética em Edifícios Glossário de Definições Monitorização de nível de combustível - Permite a monitorização dos níveis de combustível em cada tanque da embarcação. Terá associada uma plataforma de gestão de alarmes que permite a notificação instantânea das falhas de combustível. TAGs RFID - para ancoradouros permitem detectar com exactidão as atracagens dos navios, permitindo a separação clara dos tempos em carreira de outros tempos. Instalados nas oficinas ou outros ancoradouros permite igualmente detectar com exactidão a posição da embarcação quando parada. É um complemento ao DGPS facilitando a detecção da localização/estado do navio. Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

148

149 ienergy Eficiência Energética em Edifícios Referências Referências 1. ISA - Intelligent Sensing Anywhere, S.A. ISA Products. Sítio web da ISA - Intelligent Sensing Anywhere, S.A. [Online] [Citação: 6 de Agosto de 2010.] 2. PORTUGAL Folha de dados de diversificação de energias. European Commission. [Online] Janeiro de Oil and Gas Emergency Policy - Portugal 2011 update. International Energy Agency (IEA). [Online] 4. Plano de Racionalização dos Consumos de Energia. Plano de Racionalização dos Consumos de Energia. [Online] Energia e Ambiente. LDA THE STANDISH GROUP REPORT. s.l. : The Standish Group, Regulamento Tarifário Do Sector Eléctrico, ERSE, Dezembro de [Online] %202009_vers%C3%A3o%20INTERNET.pdf. 7. Regulamento de Relações Comerciais Do Sector Eléctrico, ERSE, Agosto de [Online] Regulamento% 20de%20Rela%C3%A7%C3%B5es%20Comerciais% 20-%20Agosto% pdf. 8. Nota informativa sobre as novas regras de facturação da energia reactiva, ERSE, 21 de Abril de [Online] _21Abril2010.pdf && 9. PulseEnergy. PulseEnergy. [Online] plus-energy. plus-energy. [Online] advanced telemetry. advanced telemetry. [Online] energymeteringtechnology. [Online] energymeteringtechnology.com/. 13. agile waves. agile waves. [Online] Vision BMS. Vision BMS. [Online] Synapsense. Synapsense. [Online] Schneider Electric. Schneider Electric. [Online] Raritan. Raritan. [Online] Enigin. Enigin. [Online] Johnson Controls. Johnson Controls. [Online] Henriques, João. clubeinvest. A História do Petróleo. [Online] Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/

150 Refêrencias ienergy Eficiência Energética em Edifícios Goldenberg, Michel. Scrum. Scrum. [Online] Kniberg, Henrik. Scrum and XP from the Trenches. How we do Scrum. 23. Patton, Ron. Software Testing Pedro Saraiva Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

151 ienergy Eficiência Energética em Edifícios Anexo I Estado de Arte Anexo I Estado da Arte

152

153 Estudo de Estado de Arte Out

154

155 Estado da arte Índice 1 INTRODUÇÃO FUNCIONALIDADES TECNOLOGIAS ANÁLISE GRÁFICA SOFTWARE DE GESTÃO ENERGÉTICA... 8

156

157 Estado da arte 1 Introdução Neste documento é apresentado o estudo detalhado de alguns Softwares de gestões energéticas existentes no mercado. Os principais competidores da plataforma ienergy e os seus produtos (funcionalidades e tecnologias usadas) estão descritos neste documento. Sendo que os principais competidores presentes neste documento são: PulseEnergy, Enigin, Plus-Energy, Advanced Telemetry, Energy Metering Technology Ltd, AgileWaves, Vision BMS, Noveda, Synapsense, Schneider Electric, Johnson Controls. Não foi possível para nenhuma destas empresas saber os custos para utilização das suas soluções. PulseEnergy oferece tecnologia para melhorar a gestão de energia e assim aumentar a produtividade nos edifícios. A solução da PulseEnergy combina Hardware com Software que recolhe informações referente a variáveis enérgicas e permite que os utilizadores consultem esses dados através de uma aplicação Web, os utilizadores podem consultar comparativos e custos de energia através da internet. Plus-Energy é uma empresa portuguesa de ESCO (Energy Services Company) especializada investigação, desenvolvimento e implementação de soluções adaptadas as necessidades dos seus clientes nas áreas da gestão de energia e gestão de edifícios. Os seus serviços envolvem actividades de auditoria, implementação de medidas de racionalização de energia, desenho e escala de locais de produção energeticamente mais eficientes (energia tradicionais e renováveis), manutenção de sistemas de energia, leasing de equipamentos e financiamento de projectos. Advanced Telemetry oferece soluções para ajudar os seus clientes a reduzir o seu consumo de energia e aumentar as poupanças. A sua linha de produtos chamada EcoView permite aos utilizadores que facilmente vejam, giram, e reduzam o seu consumo de energia através de uma aplicação Web. Energy Metering Technology Ltd oferece soluções para gestão de consumo de energia e água através do uso de tecnologias emergentes de monotorização e comunicação. A sua solução é composta por quatro produtos: DATACHICK que é um sistema de monotorização automática para edifícios, DATABIRL para vários edifícios, DYNAMAT para monitorar e orientar os consumos de energia e TURNKEY, uma solução final que inclui o Hardware, Software e outros serviços para gerir todo o processo desde a consulta até a instalação e suporte. AgileWaves é uma empresa sediada em Menlo Park, California que oferece um sistema de monotorização e gestão de energia. A sua solução oferece um sistema de optimização de edifícios que oferece ao gestor do edifício e aos donos dos mesmos dados em tempo real, métricas rigorosas para aumentar a eficiência energética, reduzindo os custos e atender as exigências de controlo de CO2. Vision BMS é uma companhia formada em 2007 como vinda do Barco group. BMS fornece serviços de execução de sistemas de fabrico para produção discreta, com foco no sector têxtil, plástico e industria farmacêutica. Sob a marca BarcoVision, BMS oferece uma gama de sensores e sistemas que visam a produtividade e melhoria da qualidade. Eles têm uma solução de energia que segue o princípio de monitoramento e visionamento. 1

158 Estado da arte Synapsenseoferece uma solução baseada em Wireless de sensores que oferece uma redução do consumo de energia e da pegada de carbono em data centers e empresas. Schneider Electric é uma especialista em gestão de energia com operações em mais de 100 países, Schneider Electric oferece soluções para diferentes segmentos do Mercado, incluem posições em energia e infra-estruturas, processos industriais, automação de edifícios e data centers/networks, é também com grande presença em aplicações residenciais. Raritan oferece uma solução de gestão de potência e energia, Kernel based virtual machine (KVM) e soluções de acesso. Enigin oferece produtos para controlar, reduzir e eliminar as enormes contas de energia. Eles têm uma solução para poupar energia em controlos de motores, controlos de luz, ar condicionado e refrigeração. A sua solução oferece Software e Hardware para visualização de dados em tempo real e para análise de informação. A informação em tempo real e disponibilizada por uma aplicação desktop e as análises são fornecidas por uma aplicação Web. Johnson Controls é um fornecedor de equipamentos, controlos e serviços para aquecimento, ventilação, ar-condicionado, refrigeração e segurança em edifícios. Oferecem uma solução Metasys building management que integra Hardware e Software com capacidade Wireless. Os gestores dos edifícios são capazes de perceber e melhorar o consumo e custo da energia nos seus edifícios. 2

159 Estado da arte 2 Funcionalidades Nesta secção estão listadas as funcionalidades dos competidores e uma breve descrição dessas mesmas funcionalidades. As principais funcionalidades da competição são: Dashboard View Os utilizadores podem ver numa única página várias análises/indicadores relevantes para a análise energética. Aqui alguns dos competidores oferecem a possibilidade de configuração deste dashboard com outras análises que sejam relevantes. Real time análise Esta funcionalidade permite que os utilizadores possam ver exactamente para onde a energia esta ir, Segundo a Segundo. o Consumo e custos de energia ao minuto. Alertas Se o utilizador exceder o consume ideal o mostrador muda de cor para avisar de potencial desperdícios. o Alarmes configuráveis O utilizador pode configurar alertas para serem enviados quando alguma coisa de invulgar acontecer. o Os alertas podem ser enviados por SMS ou Correio electrónico. Carbon Footprint Os utilizadores podem seguir e reduzir a sua pegada de carbono através da observação dos efeitos de decisões inteligentes e percebendo o seu impacto. Gerações de relatórios As análises podem ser mostradas de várias formas: o Análises de tendência e histórico de comparativos. o O histórico de consumo de energia pode ser comparado em através de dias, semanas, meses ou até anos. o Qualquer informação mostrada pode ser impressa para criar um relatório ou descarregada para um spreadsheet para posterior análise. o Detalhes de análises por piso, sala, dispositivo, circuito ou utilidade. o Análise de gráficos pode ser configurada pelos utilizadores. Análises de custos Os utilizadores podem converter dados numa linguagem que todos entendem - dinheiro. o Os utilizadores podem reproduzir a conta de energia de acordo com uma estrutura de tarifário. o Os utilizadores podem aceder a previsões daquilo que poderão gastar na próxima semana ou mês de forma a poderem fazer o seu orçamento de acordo ou tomar medidas para reduzir o consumo. o Os utilizadores podem aceder a contas passadas e comparar com as mais recentes. o Os utilizadores podem analisar e simular a optimização do tarifário. Os Amps, Voltagem & Factor Potência Os utilizadores podem observar e entender o consumo de energia de uma forma melhor. São a fases desequilibradas a ponto de expor o sistema a falha do equipamento em massa? Está a tensão for a dos limites aceitáveis adicionar 10% a mais a conta de energia? É o fraco factor potência que esta a diminuir a capacidade e provocando multas desnecessárias de a empresa concessionária? o Simulação do factor potência O factor potência pode ser simulado para correcção. 3

160 Estado da arte A tabela seguinte mostra os competidores em análise e as funcionalidades que oferecem: Pegada de carbono Dashboard View Consumos em tempo real Relatórios (gráficos e análises) Gráficos customizados Alarmes configuráveis Alertas de aletas por Envio de alertas por SMS Alertas no ecrã Vista de alertas com detalhes Download de análises em vários formatos Custos de energia Previsão de custos de energia Análise de custos para optimização Comparação de vários locais Opções de tarifários Simulação de factor potência Comparação de várias divisões Detalhes por divisão Google Mpaps para seleccionar local Pulse Energy Enigin X X X X X X X X X X X X X X X X X X X Plus-Energy X X X X X X X X Advanced Telemetry Energy Metering Technology AgileWaves X X X X X X X X X X X X X X X X X Visionbms X X X X X X X Noveda Synapsense (Data Centers) Schneider Electric X X X X X X X X X X X X X X X X Johnson X X X X X X X X X X X X Controls Raritan X X X X X Tabela 1 -Funcionalidades dos principais concorrentes 4

161 Estado da arte 3 Tecnologias Nesta secção é feito um breve resumo do estudo das tecnologias usadas pelos principais competidores nos seus produtos. A tabela seguinte mostra a comparação entre cada um dos competidores em termos de tecnologias. Aplicação Aplicação Aplicação Tecnologias DB móvel Web desktop Pulse Energy NA A NA Flash, NS Spring(J2EE) Enigin A A A PHP,.NET, NS Flash, JavaScript and PERL Plus-Energy NA A NA NS Advanced NA A NA ASP.net/C# NS Telemetry Energy Metering NS NS NS.NET SqlServer Technology Visionbms NA NA A. NET MySQL/Or acle/sqlser ver AgileWaves API for 3rd A API for 3rd Flash NS party party Noveda NA A NA PHP, Perl, MySQL Flash Synapsense NA NA A NS NS Schneider Electric NA NA A (Windows) NS Raritan NA A NA J2EE, NS Ajax/Flash/Fle x Johnson Controls A A A JAVA,JSP/J2E NS E Tabela 2 - Tecnologias dos principais concorrentes Legenda: A Disponível NA Não disponível NS Não especificado 5

162 Estado da arte 4 Análise gráfica Nesta secção são apresentadas uma série de análises gráficas que mostram a relação entre funcionalidades e tipo de tecnologias usadas pelos competidores. Na primeira imagem podemos ver que os competidores que têm menos funcionalidades; por análise do gráfico podemos ver que a Enigin é a companhia com mais funcionalidades implementadas e a Synapsense com menos. Figura 1: Competidores por número de funcionalidades A próxima imagem mostra que tipo de tecnologias são usadas pelos competidos nos seus produtos: Fechadas ou abertas. Pela análise do gráfico podemos concluir que as fechadas são usadas com mais frequência. Figura 2: Tipo de tecnologias Na última imagem podemos observar um gráfico que junta as duas análises anteriores: o tipo de tecnologias usadas e o número de funcionalidades dos competidores. O eixo horizontal 6

163 Estado da arte representa a complexidade dos produtos em número de funcionalidades o eixo vertical representa as tipo tecnologias usadas: tecnologias abertas ou fechadas. Para cada competidor, quanto maior for o valor no eixo vertical, mais fechadas são as tecnologias que usa. Como podemos ver, quatro companhias usam apenas tecnologias fechadas e apenas uma usa só tecnologias abertas. Todos os outros competidores usam uma mistura de tecnologias abertas e fechadas nas suas soluções. Figura 3: Relação entre tecnologias e complexidade (número de funcionalidades) 7

164 Estado da arte 5 Software de gestão energética Nesta secção são apresentadas mais algumas soluções de outras empresas já presentes no mercado. Aplicação Descrição Sistemas operativos Versão web? Preço PowerMeter Ferramenta de monitorização dos gastos de electricidade e gás numa habitação. Todos (à partida, uma vez que é web based). Disponível para o público em geral? Necessita de ligação à Internet? Notas Ainda não. Sim. Sim. Grátis. Encontra-se em versão beta e neste momento apenas pode ser testado pelos empregados do Google e por um grupo restrito de clientes. Necessita que as habitações onde seja utilizado tenha um contador inteligente para funcionar. Energy Lens Metrix 4 Utility Accounting System EnergyCAP Energy Expert 8 Ferramenta de monitorização dos gastos de electricidade num edifício. Ferramenta de monitorização dos gastos de energia (electricidade, gás natural, água, óleo para aquecimento, gás propano, gás LP, resíduos sólidos, águas residuais) num edifício. Ferramenta de monitorização e gestão do consumo de energia (água e gás, pelo menos) e de processamento das contas associadas. Ferramenta de monitorização e de Windows 98 ou mais recente. Windows 2000 ou mais recente. Sim. Não. Não. 345 por licença. Precisa do Excel 97 ou mais recente para funcionar. Sim. Penso que não. Não. Não especificado. Precisa do Excel 2003 ou mais recente para funcionar. Não especificado. Sim. Não necessariamente (só algumas versões necessitam). Todos (à partida, uma vez que é. Sim Sim. Sim. Sim. O preço varia muito com a versão da aplicação e com outros parâmetros. Versão client/server: desde $50,000 até $200,000. Versão online: a partir de $3,000 por ano para organizações mais pequenas. Versão Desktop and Campus: Desde $15,000 até $40,000. Não especificado; depende de alguns

165 Estado da arte 9 previsão dos gastos de energia (mais eficientemente electricidade mas também gás) e de picos de corrente num edifício. Permite também calcular a poupança energética realizada. MarketManager Ferramenta que permite monitorar e simular os gastos energéticos em edifícios e prever o efeito da aplicação de determinadas medidas energéticas nos mesmos. Hohm Ferramenta de monitorização dos gastos de energia numa habitação que fornece conselhos personalizados sobre poupança de energia. Power Management Ferramenta que permite gerir a energia consumida por vários computadores ligados em rede de forma centralizada. NightWatchman Ferramenta que permite gerir a energia consumida por vários computadores ligados em rede de forma centralizada. Surveyor Ferramenta que permite gerir a energia consumida por vários computadores ligados em rede de forma centralizada. web based). parâmetros. Windows. Sim. Não. Penso que não $1095. Windows Azure. Sim. Sim. Sim. Grátis. Ainda só há versão beta e esta apenas se encontra disponível para os utilizadores dos Estados Unidos da América. Windows 2000 ou mais recente e Apple Mac OS X. Windows Vista (Business, Enterprise, Enterprise x64 e Ultimate) e Windows XP SP2 e mais recentes. Windows Vista, Vista x64, Windows XP e Windows 2000 Professional SP4 (ou mais recente). Sim. Penso que não. Penso que não. Sim. Não. Não. Não especificado, mas não é grátis. Sim. Penso que não. Penso que não. Não especificado. Pode também ser adquirido como parte da suite Systems Lifecycle Management. Não especificado, mas não é grátis. Precisa do Windows Server 2008, 2008 (x64) ou Windows Server 2003 SP2 para o servidor e do SQL Server 2008, SQL Server 2005 SP2 & Express Edition ou Microsoft SQL Server 2000 para a base de dados

166 Estado da arte Edison EZ GPO EZ Wizard Client energy calculator Power Save Online energy savings calculator Advanced Power Save ROI Calculator Hewlett-Packard Power To Change Ferramenta de gestão energética em computadores (apenas para um). Ferramenta que permite controlar as opções de gestão energética de forma centralizada de vários computadores usando group policy objects. (GPO). Ferramenta de gestão energética em computadores (apenas para um) Ferramenta de cálculo de poupança energética em computadores (para um ou vários). Ferramenta que permite fazer a gestão energética de vários computadores. Ferramenta de cálulo de poupança energética em computadores (para um ou vários). Ferramenta de cálculo de poupança energética em computadores (para um ou vários). Widget que recolhe os dados da poupança energética acumulada associada ao desligamento dos computadores dos utilizadores quando estes não estão a ser utilizados. Windows XP (SP2) ou Windows Vista. Windows 2000 e XP. Windows 2000 e XP. Todos (à partida, uma vez que é web based). Windows e Mac OS X. Todos (à partida, uma vez que é web based). Todos (à partida, uma vez que é web based). Windows, Linux e Mac OS X. para funcionar. Sim. Não. Não. Grátis. Versão grátis e mais leve do Surveyor. Sim. Não. Não. Grátis. Os administradores de rede têm de correr Windows Active Directory. Sim. Penso que não. Penso que não. Grátis. Sim. Sim. Sim. Grátis. Só permite simular o consumo em sistemas Hewllett-Packard (e não todos). licença e um ano de Power Save Maintenance Package, para Portugal, na categoria educação). Sim. Não. Não. A partir de 5.29 (para uma Sim. Sim. Sim. Grátis. Sim. Sim. Sim. Grátis. Sim. Sim. Não. Grátis. Widget que recolhe dados e envia-os para um servidor via Internet embora necessite de interacção com o utilizador. Energy Saver Gadget de gestão Windows Sim. Sim, pelo menos para Não. Grátis. Gadget para o Google 10

167 Estado da arte 11 energética em computadores (apenas para um). Vista/XP, Linux e Mac OS X ver a quantidade de energia poupada pela comunidade de utilizadores do programa. Tabela 3 Resumo das características mais importantes das principais aplicações de gestão energética existentes no mercado Desktop. Necessita do Google Desktop 5 ou mais recente para funcionar.

168

169 ienergy Eficiência Energética em Edifícios Anexo II Casos de uso Anexo II Casos de Uso

170

171 Documento de casos de uso Jan. 2011

172

173 Casos de Uso Índice 1 INTRODUÇÃO CARACTERÍSTICAS DOS UTILIZADORES CASOS DE USO DO SISTEMA... 3

174

175 Casos de Uso 1 Introdução Neste documento são apresentados os casos de uso do software de gestão energética que se pretende implementar. O software é composto por vários módulos que contem diferentes funcionalidades dentro de si, com este documento pretende-se apresentar os principais casos de uso do sistema. 1

176 Casos de Uso 2 Características dos Utilizadores Para este sistema foram identificados três actores como se descreve de seguida, com base nos requisitos de utilizador do sistema. Os diferentes perfis de utilizador são: Cliente: Tem acesso à plataforma apenas para ver indicadores (não os pode alterar) e extrair relatórios predefinidos (não os pode alterar) dos projectos a que está alocado. Gestor de energia: Acesso total à plataforma não podendo no entanto gerir utilizadores nem permissões nos grupos lógicos. Administrador: Acesso total à plataforma. Pode ser vista de seguida a hierarquia entre eles no seguinte diagrama: uc Actors Cliente Gestor de energia Administrador Imagem 1 - Hierarquia de Utilizadores 2

177 Casos de Uso 3 Casos de Uso do Sistema Nesta secção são detalhados todos os pacotes de casos de utilização do sistema, através dos seus respectivos diagramas de casos de utilização. Alguns desses diagramas contêm casos de utilização mais complexos - com a descrição Extension points - que representam funcionalidades pertencentes a outros pacotes. Ou seja, são uma espécie de apontadores para outro caso de utilização existente num outro pacote. Tanto o caso de utilização como o pacote onde se encontra são especificados nesse mesmo caso de uso mais complexo. Na imagem 2 estão representados todos os módulos do sistema bem como os utilizadores que acedem a eles. uc Primary Use Cases Sistema de gestão de energia Visualização de dados(alertas, actuação,grupos, indicadores, tarifários) Análise de dados Gestão de tarifários Cliente Visualização de ralatórios Simulação de tarifários Gestor de energia Gestão de grupos Cálculo de tarifário Gestão de alertas Verificação de actuações Administrador Gestão de Indicadores Verificação de alertas Sistema Cálculo da baseline Gestão de virtual tags Gestão da baseline Gestão de actuação Imagem 2 - Casos de uso do sistema separados por pacotes 3

178 Casos de Uso uc Class Model Visualisação de Dados Exportar Dados Escolher Agregação de dados Cliente «extend» «include» Configurar Parâmetros de Aquisição Visualizar Dados de Histórico «include» «include» Escolher Grupo Lógico «include» «include» Gestor de Energia Comparar Dados de Histórico Escolher Unidade de Medida «include» Escolher Tag «include» Administrador Gerar Regressão Linear Imagem 3- Diagrama de casos de uso para visualização de dados 4

179 Casos de Uso uc Cálculo da baseline Baseline Gerir Baseline Gestor de energia (from Actors) Cálcular Baseline «include» Ver indicadores de poupança Sistema Imagem 4 - Casos de uso de gestão de baseline uc Gestão de grupos Gestão de Grupos Criar Sub Grupos «extend» Gerir Grupos Gestor de energia (from Actors) «extend» «extend» Adicionar Utilizadores a grupos Gerir Indicadores «extend» Adicionar Tags a Grupos Gerir Virtual tags Adicionar detalhes Imagem 5- Casos de uso para gestão de grupos 5

180 Casos de Uso uc Gestão de alertas Gestão de alertas Ver alertas disparados Cliente (from Actors) Env iar com o estado do alerta «include» Gerir alertas Verificar alertas Sistema Gestor de energia (from Actors) Carregar alerta Administrador (from Actors) Imagem 6 - Casos de uso para gestão de alertas uc Cálculo de tarifário Gestão de tarifários Consultar tarifários Cliente (from Actors) Cálcular simulação de tarifários Ver Simulação de tarifários «include» Gestor de energia (from Actors) Criar novas versões «extend» Cálcular tarifários Gerir tarifários Sistema Imagem 7 - Casos de uso para gestão de tarifários 6

181 Casos de Uso uc Gestão de actuação Gestão de actuação Gerir actuação Gestor de energia (from Actors) Actuar sobre o despositiv o «include» Verificar actuação Sistema Imagem 8 - Casos de uso para gestão de actuação 7

182 ienergy Eficiência Energética em Edifícios Anexo III Plano de Risco Anexo III Plano de Riscos

183

184 ienergy Eficiência Energética em Edifícios Anexo III Plano de Risco No decorrer do projecto foram identificados alguns riscos para o mesmo, para cada um desses riscos foi identificada uma estratégia de contingência. A tabela seguinte mostra os maiores riscos do projecto: Risco A carga a que o sistema vai ser sujeita. Esperar demasiado da plataforma pode levar a alguns mal entendidos entre o que a plataforma já é vs. Aquilo que é esperado da plataforma Pouca experiencia nas tecnologias usadas para a implementação. Estratégia de contingência Testes iniciais com uma base de dados de produção de forma a perceber como pode ser optimizado o sistema. Deve existir uma apresentação da solução para que toda a gente saiba o que é a solução. Documentação da solução em termos comerciais para identificar qual é a solução faz e não faz e pontos críticos. Estudo cuidado de todas as tecnologias que são usadas na implementação, através da internet ou livros. Implementação de protótipos usando as tecnologias em causa. 1

185 ienergy Eficiência Energética em Edifícios Anexo IV Especificação do Web Service Anexo IV Web Service de edifícios

186

187 Especificação do Web Service Mai. 2011

188

189 Especificação Web Service Índice ANEXO IV WEB SERVICE DE EDIFÍCIOS INTRODUÇÃO ESTRUTURAS DE DADOS RESULTADO DE UMA OPERAÇÃO INDICADOR GRUPO DETALHES DE GRUPO TIPO DE GRUPO COLUNAS DE UM TIPO DE GRUPO VALORES DAS COLUNAS DE UM TIPO DE GRUPO TIPO DE HÓRARIO DE GRUPO HÓRARIO DE GRUPO TAG PARÂMETRO DA VIRTUAL TAG TARIFA PARÂMETRO DE TARIFÁRIO CUSTOS FIXOS INTERVALO FACTOR DE MULTIPLICAÇÃO TEMPORADA SIMULAÇÃO DE TARIFA LINHA DE SIMULAÇÃO DE TARIFA UNIDADE DE MEDIDA CONVERSÃO DE MEDIDA ALERTA PARÂMETRO DO ALERTA ALERTA DISPARADO ACTUAÇÃO BASELINE VALORES DA BASELINE UTENSÍLIOS DA BASELINE MÉTODOS ACESSO A DADOS GRUPOS UNIDADES DE MEDIDA TARIFAS ALERTS MESSAGES BASELINE RELATÓRIOS ACTUAÇÃO... 20

190

191 Especificação Web Service 1 Introdução Este documento tem por objectivo apresentar a especificações dos métodos criados no novo End Point do Web Service do ienergy (end point de edifícios). Web Service de Edíficios 1

192 Especificação Web Service 2 Estruturas de dados Nesta secção são apresentadas todas as estruturas de dados e enumerações que são usadas no end point de edifícios. Estas estruturas são específicas para um método ou para um conjunto de métodos que as podem utilizar. 2.1 Resultado de uma operação Todas as invocações de métodos retornam um código que indica o sucesso ou insucesso da uma operação. Os valores possíveis estão codificados na seguinte enumeração: public enum ResultCode : byte { Success = 1, UnexpectedError = 2, InvalidUser = 3, InvalidParameter = 4, NoData = 5, UnAuthorized = 6, ImpossibleConversion = 7 } Os primeiros três valores são comuns a todas as operações, os restantes são específicos para cada método e serão explicados em detalhe em cada caso. A descrição desses valores é: Valor Descrição Success UnexpectedError InvalidUser A operação teve sucesso. Erro durante a execução. Utilizador inválido. Token errado ou expirado. Acesso não autorizado a este método. InvalidParameter NoData UnAuthorized ImpossibleConversion Parâmetro inválido. Não existem dados para a operação desejada. O utilizador não tem as permissões necessárias para a operação desejada. A unidade de medida pedida não pode ser convertida. 2.2 Indicador A classe Indicator é usada para representa um indicador de estado e para fazer a sua serialização entre o cliente e a plataforma. A classe é definida por: public class Indicator { public int Id { get; set; } public string Name { get; set; } public int TagId { get; set; } 2 Web Service de Edíficios

193 Especificação Web Service public byte TagMeasurementType{ get; set; } public bool IsAccumulate{ get; set; } } 2.3 Grupo A classe Group é usada para representa um grupo e para fazer a sua serialização entre cliente e a plataforma. A classe é definida por: public class Group { public int Id { get; set; } public string Name { get; set; } public string Description { get; set; } public int ParentId { get; set; } public int IsBuilding { get; set; } } 2.4 Detalhes de Grupo A classe GroupDetails é usada para representa um detalhe de um grupo que pode ser usada em indicadores de estado e para fazer a sua serialização entre cliente e a plataforma. A classe é definida por: public class GroupDetails { public int GroupId { get; set; } public string Name { get; set; } public decimal Value { get; set; } } 2.5 Tipo de Grupo A classe GroupType é usada para representa um tipo de grupo e para fazer a sua serialização entre cliente e a plataforma. A classe é definida por: public class GroupType { public int Id { get; set; } public string Name { get; set; } } 2.6 Colunas de um Tipo de Grupo A classe GroupColumns é usada para representa os parâmetros de um tipo de grupo e para fazer a sua serialização entre cliente e a plataforma. A classe é definida por: public class GroupColumns { public int Id { get; set; } public int GroupId { get; set; } public string Name { get; set; } public string Index { get; set; } } Web Service de Edíficios 3

194 Especificação Web Service 2.7 Valores das Colunas de um Tipo de Grupo A classe GroupColumnsValues é usada para representa um valor de uma coluna de um tipo de grupo e para fazer a sua serialização entre cliente e a plataforma. A classe é definida por: public class GroupColumnsValues { public int Id { get; set; } public string GroupId { get; set; } public string ColumnId { get; set; } public decimal Value { get; set; } } 2.8 Tipo de Hórario de Grupo A classe GroupScheduleType é usada para representa um tipo de hórario de um grupo e para fazer a sua serialização entre cliente e a plataforma. A classe é definida por: public class GroupColumns { public int Id { get; set; } public int GroupId { get; set; } public int ColumnId { get; set; } public string Value { get; set; } } 2.9 Hórario de Grupo A classe GroupScheduleé usada para representar um horário de um grupo e para fazer a sua serialização entre cliente e a plataforma. A classe é definida por: public class GroupColumns { public int Id { get; set; } public int GroupId { get; set; } public int ColumnId { get; set; } public string Value { get; set; } } 2.10 Tag A classe Tag é usada para representa uma Tag(variável medida) e para fazer a sua serialização entre cliente e a plataforma. A classe é definida por: public class Tag { public int Id { get; set; } public string Name { get; set; } public int UnitId { get; set; } public int DeviceId { get; set; } public int RemoteId { get; set; } public int TagTypeId { get; set; } public int LocalId { get; set; } public int IsVirtual { get; set; } } 4 Web Service de Edíficios

195 Especificação Web Service 2.11 Parâmetro da Virtual Tag A classe Tag é usada para representa uma Tag(variável medida) e para fazer a sua serialização entre cliente e a plataforma. A classe é definida por: public class TagVirtualParameter { public int Id { get; set; } public string TagId { get; set; } public string VirtualParameterType { get; set; } } 2.12 Tarifa A classe Tariff é usada para representar uma tarifa e é serializada entre o cliente e a plataforma. A classe tariff é definida por: public class Tariff { public int Id { get; set; } public int Supid { get; set; } public string Name { get; set; } public int AquisitionPeriods { get; set; } public int SeasonSeries { get; set; } public int Identification { get; set; } public int UserId { get; set; } public short Version { get; set; } public bool IsPublic { get; set; } public DateTime Start{ get; set; } public DateTime End{ get; set; } public List<Interval> Intervals { get; set; } public List<FixedCosts> FixedCosts { get; set; } public List<TariffParameter> Parameter{ get; set; } } 2.13 Parâmetro de Tarifário A classe TariffParameter é usada para representar um parâmetro do tarifário e é serializada entre o cliente e a plataforma. A classe TariffParameter é definida por: public class TariffParamter { public int Id { get; set; } public int Type { get; set; } public string Name { get; set; } public int Period { get; set; } public int Price { get; set; } public List<int> Hours{ get; set; } public List<MultiplicationFactor> Factor{ get; set; } public List<Season> Seasons{ get; set; } } 2.14 Custos Fixos A classe FixedCosts é usada para representar um custo fixo associado ao tarifário e é serializada entre o cliente e a plataforma. A classe FixedCosts é definida por: public class FixedCosts Web Service de Edíficios 5

196 Especificação Web Service { } public int Id { get; set; } public string Description { get; set; } public decimal ContractedPower { get; set; } public decimal Price { get; set; } 2.15 Intervalo A classe Interval é usada para representar um intervalo do tarifário e é serializada entre o cliente e a plataforma. A classe Interval é definida por: public class Interval { public int Id { get; set; } public TimeSpan Start { get; set; } public TimeSpan End { get; set; } public int Season { get; set; } public byte WeekDay { get; set; } public decimal Price { get; set; } public byte Type { get; set; } } 2.16 Factor de Multiplicação A classe MultiplicationFactor é usada para representar um factor de multiplicação e é serializada entre o cliente e a plataforma. A classe MultiplicationFactor é definida por: public class MultiplicationFactor { public int Id { get; set; } public string Name { get; set; } public decimal? Min { get; set; } public decimal? Max { get; set; } public decimal Factor { get; set; } } 2.17 Temporada A classe Season é usada para representar uma temporada associada aos parametros do tarifário e é serializada entre o cliente e a plataforma. A classe MultiplicationFactor é definida por: public class Season { public int Id { get; set; } public string Name { get; set; } public int StartDate { get; set; } public int EndDate { get; set; } } 2.18 Simulação de tarifa A classe TariffSimulation é usada para representar uma simulação e é serializada entre clientes e a plataforma. A classe TariffSimulation é definida por: public class TariffSimulation { public string Name { get; set; } 6 Web Service de Edíficios

197 Especificação Web Service } public List<TariffSimulationRow> Costs { get; set; } public int Id { get; set; } 2.19 Linha de Simulação de tarifa A classe TariffSimulationRow é usada para representar uma linha da simulação e é serializada entre clientes e a plataforma. A classe TariffSimulation é definida por: public class TariffSimulationRow { public decimal? RushHourCosts { get; set; } public decimal? FloodHourCosts { get; set; } public decimal? EmptyHourCosts { get; set; } public decimal? SuperEmptyHouCostsr { get; set; } public decimal? InductiveEnergyCosts { get; set; } public decimal? CapacitiveEnergyCosts { get; set; } public decimal? ContractedPowerCosts { get; set; } public decimal? RushPowerCosts { get; set; } } 2.20 Unidade de medida A classe MeasurementUnit é usada para representa uma unidade de medida (kwh, etc) e para fazer a sua serialização entre cliente e a plataforma. A classe é definida por: public class MeasurementUnit { public int Id { get; set; } public string Name { get; set; } public string SmallName { get; set; } } 2.21 Conversão de medida A classe MeasurementConversion é usada para representa uma conversão de uma unidade de medida (kwh, etc) para outra (CO2,Car etc) e para fazer a sua serialização entre cliente e a plataforma. A classe é definida por: public class MeasurementConversion { public int Id { get; set; } public Tuple<int,string,decimal> Source { get; set; } public Tuple< int,string,decimal> Destination { get; set; } } 2.22 Alerta A classe Alert é usada para representa um alerta e para fazer a sua serialização entre cliente e a plataforma. A classe é definida por: public class Alert { public int Id { get; set; } public Dictionary<string, string> Properties { get; set; } public string Type { get; set; } public bool HasEnable { get; set; } Web Service de Edíficios 7

198 Especificação Web Service } public string Name { get; set; } public int? EntityId { get; set; } public datetime StartDate { get; set; } public datetime EndDate { get; set; } 2.23 Parâmetro do alerta A classe AlertParameterParameters é usada para representa um parâmetro de um alerta e para fazer a sua serialização entre cliente e a plataforma. A classe é definida por: public class AlertTriggerParameters { public int Id { get; set; } public int AlertTriggerId { get; set; } public string Name { get; set; } public string ValueString { get; set; } public decimal Value { get; set; } } 2.24 Alerta disparado A classe AlertTrigger é usada para representa um alerta que foi disputado e para fazer a sua serialização entre cliente e a plataforma. A classe é definida por: public class AlertTrigger { public int Id { get; set; } public List< AlertTriggerParameters> Parameter { get; set; } public string AlertName { get; set; } public AlertType Type { get; set; } public int AlertId { get; set; } public bool HasChecked{ get; set; } public int16 Priority { get; set; } public bool HasSent { get; set; } public datetime Date { get; set; } } Os tipos de alerta que existem são: public enum AlertType: byte { Tag = (byte)0, Unit = (byte)1, Group = (byte)2, System = (byte) 3 } 2.25 Actuação A classe Action é usada para representa uma actuação e para fazer a sua serialização entre cliente e a plataforma. A classe é definida por: public class Action { public int Id { get; set; } public int Weekday { get; set; } public timespan Hour{ get; set; } public bool Action { get; set; } } 8 Web Service de Edíficios

199 Especificação Web Service 2.26 Baseline A classe Baseline é usada para representa uma baseline e para fazer a sua serialização entre cliente e a plataforma. A classe é definida por: public class Baseline { public int Id { get; set; } public datetime Date { get; set; } public decimal AvacPower{ get; set; } public timespan AvacStartTime { get; set; } public timespan AvacEndTime { get; set; } public List<BaselineValue> BaselineValues { get; set; } public List<BaselineAppliance> BaselineAppliances{ get; set; } } 2.27 Valores da Baseline A classe BaselineValue é usada para representar um valor da baseline e para fazer a sua serialização entre cliente e a plataforma. A classe é definida por: public class BaselineValue { public int Id { get; set; } public datetime Date { get; set; } public decimal Rush { get; set; } public decimal Full { get; set; } public decimal Empty { get; set; } public decimal SuperEmpty { get; set; } } 2.28 Utensílios da baseline A classe BaselineAppliance é usada para representar um utensílio e para fazer a sua serialização entre cliente e a plataforma. A classe é definida por: public class BaselineAppliance { public int Id { get; set; } public string Name { get; set; } public decimal Power{ get; set; } public timespan StartTime { get; set; } public timespan EndTime { get; set; } } Web Service de Edíficios 9

200 Especificação Web Service 3 Métodos Nesta secção encontram-se todos os métodos que podem ser chamados no Web Service de edifícios para retornar informação sobre as entidades armazenadas no sistema. Nesta secção existe um método que é usado para listar algumas entidades no sistema segundo alguns criterios: ResultCode Search{Entidade} (string token, string? columnname, int? pagesize, int? page, string searchtext, string filter, out List<Entidade> entidade); Descrição dos parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. ColumnName In Nome da coluna para ordenação. Pagesize In Número de resultados por página. Page In Página actual. SearchText In Texto que vai ser procurado. Filter In Coluna da entidade que vai servir de filtro a pesquisa. Entidade Out Lista com as entidades que preenchem o critério. 3.1 Acesso a dados O método seguinte permite aceder a dados de consumos agregados para uma dada tag num intervalo de tempo específico. Os valores são retornados numa unidade de medida específica: ResultCode GetAggregatedConsumptions(string token, int tagid, DateTime begindate, DateTime enddate, byte measurementunitid, AggType aggregation, out List<Tuple<DateTime, decimal>> data); Descrição dos parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. TagId In Id da tag BeginDate In Data de início EndDate In Data de fim MeasurementUnitId In Unidade de medida em que os dados devem ser retornados. Aggregation In Tipo de agregação. (INSTANT, HOURLY, DAILY, MONTHLY, YEARLY) Data Out Lista de tuples que contem os dados. Cada tuple contém uma data e um decimal que representa o valor em cada momento. Explicação dos códigos retornados: Código de resultado Descrição NoData Não existem dados para os parâmetros especificados. 10 Web Service de Edíficios

201 Especificação Web Service O método seguinte permite aceder a dados de consumos agregados (valores instantâneos) para uma dada tag num intervalo de tempo específico. Os valores são retornados numa unidade de medida específica: ResultCode GetAggregatedInstants(string token, int tagid, DateTime begindate, DateTime enddate, byte measurementunitid, Core.Structures.AggType aggregation, Core.Structures.InstantType instant, out List<Tuple<DateTime, decimal>> data); Descrição dos parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. TagId In Id da tag BeginDate In Data de início EndDate In Data de fim MeasurementUnitId In Unidade de medida em que os dados devem ser retornados. Aggregation In Tipo de agregação. (INSTANT, HOURLY, DAILY, MONTHLY, YEARLY) Instants In Operação estatística que deve ser aplicada aos dados. (AVERAGE, MIN, MAX, STDEV) Data Out Lista de tuples que contem os dados. Cada tuple contém uma data e um decimal que representa o valor em cada momento. 3.2 Grupos Este método pesquisa por grupos com um nome ou descrição específicos: ResultCode SearchGroup(string token, string text, out List<Group> groups); Descrição de parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. Text In Texto a pesquisar. Groups Out Lista de grupos. Método usado para retorna todos os grupos raiz: ResultCode GetRootGroups (string token, out List<Group> groups); Descrição de parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. Groups Out Lista dos grupos raiz. Este método verifica se um determinado grupo tem grupos filhos: ResultCode HasChild (string token, int groupid, out bool haschild); Descrição de parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. GroupId In Group id. Web Service de Edíficios 11

202 Especificação Web Service HasChild Out Returna verdadeiro ou falso. Este método retorna as tag de um determinado grupo: ResultCode GetTagsFromGroup (ing token, int groupid, out List<Tag> tags); Descrição de parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. GroupId In Id do grupo. Tags Out Lista de tags. Os códigos de retorno que podem ser retornados por este método são: Código de resultado Descrição InvalidParameter groupid é nulo ou vazio groupid inválido Método que retorna os indicadores de um determinado grupo: ResultCode GetIndicatorsFromGroup (ing token, int groupid, out List<Tag> tags); Descrição de parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. GroupId In Group id Indicators Out Lista de indicadores do grupo. Os códigos de retorno que podem ser retornados por este método são: Código de resultado Descrição InvalidParameter groupid é nulo ou vazio groupid inválido O método seguinte permite ao utilizador adicionar um novo grupo no sistema: ResultCode AddGroup(string token, Group group, out int id); Descrição dos parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. Group In O grupo á adicionar. Os grupos estão organizados hierarquicamente á informação referente ao seu parente (id) deve ser também fornecido no grupo. Se não será um novo grupo raiz. Id Out O id do novo grupo criado. O método seguinte permite adicionar tags a um determinado grupo: ResultCode AddTagsToGroup(string token, int[] tags, int group); Descrição dos parâmetros: 12 Web Service de Edíficios

203 Especificação Web Service Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. Tags In Um array com os ids das tags para serem adicionadas ao grupo. Group In Id do grupo. Este método permite editar informação de um determinado grupo: ResultCode EditGroup(string token, Group g); Descrição dos parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. Group In Grupo a ser editado. O método seguinte permite apagar um grupo: ResultCode DeleteGroup(string token, int id); Nota: Apenas grupos folha podem ser apagados. Descrição dos parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. Id In Id do grupo apagar. O método seguinte permite linkar dois grupos um ao outro numa relação hierárquica. ResultCode LinkGroups(string token, int parentid, int childid); Descrição dos parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. ParentId In Id do grupo pai. Childid In Id do grupo filho. O método seguinte permite que dois grupos sejam separados: ResultCode UnLinkGroups(string token, int parentid, int childid); Descrição dos parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. ParentId In Id do grupo pai. Childid In Id do grupo filho. O método seguinte permite ao utilizador listar todos os grupos que tem acesso: ResultCode GetGroups(string token, out List<Group> groups); Descrição dos parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. Groups out Lista de grupos. Web Service de Edíficios 13

204 Especificação Web Service O método seguinte permite ao utilizador obter todos os grupos filhos de um determinado grupo. ResultCode GetDirectGroupChilds(string token, int groupid, out List<Group> children); Descrição dos parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. GroupId In Id do grupo. Children Out Lista de grupos filhos. O método seguinte permite ao utilizador obter todos os grupos filhos de um determinado grupo. ResultCode GetAllGroupChilds(string token, int groupid, out List<Group> children); Descrição dos parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. GroupId In Id do grupo. Children Out Lista de grupos filhos. O método seguinte permite ao utilizador obter todas as tags dos grupos filhos de um determinado grupo. ResultCode GetAllTagsFromGroup(string token, int groupid, out List<Tag> tags); Descrição dos parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. GroupId In Id do grupo. Tags Out Lista de tags dos grupos filhos. O método seguinte permite que sejam listadas grupos por um certa condição: ResultCode SearchGroups(string token, string? columnname, int? pagesize, int? page, string searchtext, string filter, out List<Group> entidade); Explicação dos códigos retornados: Código de resultado Descrição InvalidUser Success UnexpectedError Token errado. Token expirado. Acesso não autorizado ao método. Operação com sucesso. Erro inesperado no acesso a base de dados. 3.3 Unidades de medida O método seguinte permite ao utilizador obter uma lista de unidades de conversão: ResultCode GetMeasurementConversions(string token, out List<MeasurementConversions> conversions); 14 Web Service de Edíficios

205 Especificação Web Service Uma conversão representa o factor pelo qual a unidade deve ser multiplicada para obter uma outra unidade. Descrição dos parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. MeasurementUnits Out Lista de unidades de medida. O método seguinte permite obter uma lista de tipos de medida (Gás, Água, Temperatura ): ResultCode GetMeasurementTypes(string token, out List<Tuple<int, string>> measurementtypes); Descrição dos parâmetros Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. MeasurementTypes Out Lista de tuples onde cada um deles contém o id e uma string que representam o id e o nome do tipo, respectivamente O método seguinte permite que o utilizador possa obter as unidades de medida (Volt, Kilowatt/h, CO2, ): ResultCode GetMeasurementUnits(string token, out List<Tuple<int, string>> measurementunits); Descrição dos parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. MeasurementUnits Out Lista de tuples onde cada um deles contém o id e uma string que representam o id e o nome do tipo, respectivamente 3.4 Tarifas O método seguinte permite obter o tarifário aplicado a uma determinada tag: ResultCode GetDeviceTariff(string token,int tagid, out tariff Tariff); Descrição dos parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. TagId In Id da tag. Tariff Out Tarifa aplicada a tag. O método seguinte permite actualizar um tarifário de uma tag. ResultCode UpdateDeviceTariff(string token,int tagid,int tarid out tariff Tariff); Descrição dos parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. TagId In Id da tag. Web Service de Edíficios 15

206 Especificação Web Service TarId In Id do tarifário. Tariff Out Tarifa aplicado a tag. O método seguinte retorna a lista de tarifários aplicados num determinado local ou para todos os locais: ResultCode GetTariffs(string token,string zipcode, out List<tariff> tariffs); Descrição dos parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. Zipcode In Id do código postal onde se pretende consultar os tarifários. Tariff Out Lista de tarifários. O método seguinte permite adicionar um novo tarifário a base de dados: ResultCode AddTariffs(string token, tariff tariff); Descrição dos parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. Tariff In Tarifário a ser adicionado. O método seguinte permite adicionar um novo versão do tarifário a base de dados: ResultCode AddTariffVersion(string token,int lasttariffid tariff tariff); Descrição dos parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. LastTariffId In Id do tarifário para o qual se pretende criar nova versão do tarifário. Tariff In Tarifário a ser adicionado. O método seguinte permite obter uma simulação de tarifário com todos os tarifários inseridos no sistema. ResultCode GetTariffSimulation(string token,int grupid, string? columnname, int? pagesize, int? page, out List<TariffSimulation> simulation); Descrição dos parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. GroupId In Id do grupo que se pretende obter a simulação. Simulation Out Lista de simulações com cada um dos tarifários. 3.5 Alerts O método seguinte retorna uma lista de alertas configurados no sistema: ResultCode GetAlerts(string token, string? columnname, int? pagesize, int? page, out List<alert> alerts); 16 Web Service de Edíficios

207 Especificação Web Service Descrição dos parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. Alerts Out Lista de alertas configurados no sistema. O método seguinte permite adicionar novos alertas ao sistema. ResultCode AddAlert (string token, Alert alert); Descrição dos parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. Alert Out Novo alerta a ser adicionado. O método seguinte permite ao utilizador apagar alertas definidos no sistema ResultCode DeleteAlert (string token, int alertid) Descrição dos parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. AlertId In Id do alerta. O método seguinte permite listar todos os alertas lançados pelo sistema. ResultCode GetAlertTriggers (string token, string? columnname, int? pagesize, int? page, out List<Tuple<int, string>> alerttriggers); Descrição dos parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. Triggers Out Lista de alertas lançados no sistema. O método seguinte permite listar todos os alertas lançados pelo sistema, filtrados por grupo ou por tipo. ResultCode GetAlertTriggersByGroup (string token, int? groupid, int? groupid, int? type, out List<Tuple<int, string>> measurementunits); Descrição dos parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. GroupId In Id do grupo na qual se pretende listar os alertas. Triggers Out Lista de alertas lançados no sistema. O método seguinte permite que sejam listadas alertas disparados por um certa condição: ResultCode SearchAlertTriggers(string token, string? columnname, int? pagesize, int? page, string searchtext, string filter, out List<AlertTriggers> entidade); O método seguinte permite colocar um alerta como lido. ResultCode SetAlertHasRead (string token, int alertid); Web Service de Edíficios 17

208 Especificação Web Service Descrição de parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. AlertId In Id do alerta. 3.6 Messages O método seguinte permite que sejam inseridas novas mensagens no sistema: ResultCode AddMessage(string token, int groupid, string? columnname, int? pagesize, int? page, Message message); Descrição de parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. GroupId In Id do grupo a que pertence a mensagem Message In Mensagem a ser adicionada ao grupo. O método seguinte permite apagar uma mensagem do sistema, esta mensagem é introduzida para determinado grupo. ResultCode DeleteMessage (string token,int messageid); Descrição de parâmetros: Parâmetro Fluxo Descrição Token In O token de autenticação usado para verificar as credenciais do utilizador. MessageId Out Id da mensagem. O método seguinte permite listar todas a mensagens no sistema. ResultCode GetMessage (string token,out Message message); Descrição de parâmetros: Parâmetro Fluxo Descrição Token In O token de autenticação usado para verificar as credenciais do utilizador. Message Out Mensagens registadas no sistema. O método seguinte permite listar todas as mensagens para um determinado grupo. ResultCode GetMessageFromGroup string token, int groupid, out List<Message> message); Descrição de parâmetros: Parâmetro Fluxo Descrição Token In O token de autenticação usado para verificar as credenciais do utilizador. GroupId In Id d grupo. Message Out Lista de mensagens. O método seguinte permite que sejam listadas mensagens por um certa condição: 18 Web Service de Edíficios

209 Especificação Web Service ResultCode SearchMessage(string token, string? columnname, int? pagesize, int? page, string searchtext, string filter, out List<Message> entidade); 3.7 Baseline O método seguinte permite que sejam inseridas novas baselines no sistema. ResultCode AddBaseline(string token, int groupid,baseline baseline); Descrição de parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. GroupId In Id do grupo a que pertence a baseline Baseline In Baseline a ser adicionada ao grupo. O método seguinte permite actualizar uma baseline: ResultCode UpdateBaseline(string token, int lastid, baseline baseline); Descrição de parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. LastId In Id da última baseline. Baseline In Nova baseline. O método seguinte permite obter as baselines de um determinado grupo: ResultCode GetBaselines(string token,groupid, out List<Baseline> baselines); Descrição de parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. GroupId In Id do grupo. Baselines Out Lista de baselines do grupo. O método seguinte permite apagar uma baseline do sistema, apenas é possível apagar a ultima baseline introduzida para determinado grupo: ResultCode DeleteBaseline(string token,int baselineid); Descrição de parâmetros: Parâmetro Fluxo Descrição Token In O token de autenticação usado para verificar as credenciais do utilizador. BaselineId Out Id da baseline. 3.8 Relatórios O método seguinte permite ao utilizador obter um relatório para um determinado grupo: ResultCode GetReport(string token,int id,int type, out bytes[] report); Descrição de parâmetros: Web Service de Edíficios 19

210 Especificação Web Service Parâmetro Fluxo Descrição Token In O token de autenticação usado para verificar as credenciais do utilizador. Id In Id do grupo para o qual se pretende obter o relatório. Type In Tipo de relatório (1 Completo, 2 - Resumido). Report Out Lista de bytes que representa o relatório. 3.9 Actuação O método seguinte permite que sejam listadas todas as actuações do sistema: ResultCode GetActions(string token, string? columnname, int? pagesize, int? page, List<Action> actions); Descrição de parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. Action In Lista de actuações no sistema. O método seguinte permite que sejam listadas as actuações de um grupo. ResultCode GetGroupActions(string token, int groupid, string? columnname, int? pagesize, int? page, List<Action> action); Descrição de parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. GroupId In Id do grupo a que pertencem as actuações. Action In Lista de actuações no sistema. O método seguinte permite que sejam inseridas novas actuações no sistema ResultCode AddAction(string token,action action); Descrição de parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. Action In Actuação a ser adicionada. O método seguinte permite que sejam apagadas actuações do sistema: ResultCode DeleteAction(string token, int actionid); Descrição de parâmetros: Parâmetro Fluxo Descrição Token In Token usado para verificar as credenciais do utilizador. ActionId In Id da actuação a ser adicionada. O método seguinte permite que sejam listadas actuações por um certa condição: ResultCode SearchAction(string token, string? columnname, int? pagesize, int? page, string searchtext, string filter, out List<Action> entidade); 20 Web Service de Edíficios

211 Anexo V Especificação da Base de Dados

212

213 Modelo de dados Abril. 2011

214

215 Especificação da base de dados Índice 1 INTRODUÇÃO TABELAS DE ALERTAS ALERT ALERT_PARAMETER ALERT_TRIGGER ALERT_TRIGGER_PARAMETER TABELAS DE ACTUAÇÃO ACTION TABELAS BASELINE BASELINE BASELINE_VALUES BASELINE_APPLIANCE TABELAS GRUPOS HIERARCHY INDICADOR GROUP GROUP_TYPE GROUP_COLUMNS GROUP_COLUMNS_VALUES GROUP_SCHEDULE GROUP_DETAILS GROUP_TAG GROUP_USER TABELAS TARIFÁRIOS TARIFF TARIFF_PARAMETER MULTIPLICATION_FACTOR SEASON SEASON_SERIES INTEVAL FIXED_COSTS TABELAS KPI S KPI KPI_DATA KPI_MESSAGE KPI_CONF KPI_ERROR_LOG... 20

216

217 Especificação da base de dados 1 Introdução Neste documento são especificadas alterações feitas a base de dados no decorrer do desenvolvimento do estágio bem como o modelo entidade relação, apenas da parte que faz parte do estágio. Especificação da base de dados 1

218 Especificação da base de dados 2 Tabelas de alertas Secção com a descrição das tabelas referentes a funcionalidade de alertas. 2.1 Alert Entidade que representa um alerta irá conter as configurações dos alertas que podem ser configurados no sistema. Tabela interna de sistema. Nome Tipo Def. Null Idx Descrição alr_id int Chave primaria. alr_type int Tipo do alerta (unidades, patamares, objectivos). tag_id int Id da tag de associada ao alerta. unt_id int Id da unidade de associada ao alerta. alr_enabled bit Diz se o alerta está activo ou não. alr_schedule bit Dias em que o alerta ocorre. alr_last_exec datetime Data da última execução dll_id int Id da dll em que o alerta está implementado. alr_name string Nome do alerta. alr_data datetime Data de início do alerta. alr_stop_date datetime Data de fim do alerta. Dependencies Dependent Tables unit, tag, dll Dependent Procedures 2.2 Alert_Parameter Entidade que representa um parâmetro do alerta que pode representar um valor que faz disparar certo alerta. Nome Tipo Def. Null Idx Descrição ap_id int Chave primaria. ap_name int Nome do parâmetro. 2 Especificação da base de dados

219 Especificação da base de dados ap_value decimal Valor associado ao parâmetro. ap_value_string string String associada ao parâmetro. Dependencies Dependent Tables alert Dependent Procedures 2.3 Alert_Trigger Entidade que representa um parâmetro do alerta que foi disparado. Nome Tipo Def. Null Idx Descrição at_id int Chave primaria. at_date datetime Data em que o alerta foi disparado. at_checked bit Diz se o alerta já foi verificado. at_priority alr_id smallint int Prioridade(Depende do plugin que implementa) Chave estrangeira que referencia o alerta. at_mail string s para onde foi enviado o alerta. Dependencies Dependent Tables alert Dependent Procedures 2.4 Alert_Trigger_Parameter Entidade que representa um parâmetro do alerta que fez disparar um determinado alerta. Nome Tipo Def. Null Idx Descrição atp_id int Chave primaria. atp_name atp_value datetime bit Nome do parâmetro que fez disparar o alerta. Valor decimal que fez disparar o alerta. Especificação da base de dados 3

220 Especificação da base de dados atp_string_value at_id smallint int String que representa um parâmetro do alerta. Chave estrangeira que referencia o alerta_trigger. Dependencies Dependent Tables Alert_trigger Dependent Procedures alert_trigger at_id at_date at_checked at_priority alr_id at_ alert alr_id alr_type unt_id g_id tag_id alr_enabled alr_schedule alr_last_exec dll_id alr_name alr_data alr_stop_date alert_trigger_parameter atp_id atp_name atp_value atp_string_value at_id alert_parameter ap_id ap_name ap_value alr_id ap_value_string 4 Especificação da base de dados

221 Especificação da base de dados 3 Tabelas de actuação Secção com a descrição das tabelas referentes a funcionalidade de actuação. 3.1 Action A tabela action irá conter as configurações das actuações agendadas no sistema. Tabela interna de sistema. Nome Tipo Def. Null Idx Descrição act_id int Chave primaria. uni_id int Id da unidade que vai ser usada para actuar. tag_id int Id da tag de actuação. act_weekday act_hour bit timestamp Bit que diz em que dias da semana a actuação deve ser feita. Hora em que a actuação vai ser efectuada. act_action bit Acção a realizar (On/off) act_next datetime Data da próxima actuação Dependencies Dependent Tables unit, tag Dependent Procedures action act_id uni_id tag_id act_weekday act_hour act_action act_next Figura 1 Diagrama ER relativo a actuação Especificação da base de dados 5

222 Especificação da base de dados 4 Tabelas Baseline Secção com a descrição das tabelas referentes a funcionalidade de baseline. 4.1 Baseline A tabela Baseline irá conter as configurações das baselines armazenada na BD. Tabela interna de sistema. Nome Tipo Def. Null Idx Descrição bl_id int Chave primaria. g_id int Id do grupo a que pertence a baseline. bl_date datetime Data da baseline. bl_last_id int Id da última baseline. bl_next_id int Id da próxima baseline. open_time timestamp Hora de abertura da instalação. close_time timestamp Hora de fecho da instalação avac_power decimal(15, 5) Potência nominal do AVAC. avac_start_time avac_stop_time timestamp timestamp Hora de início de funcionamento do AVAC. Hora em que o AVAC é desligado. bl_calculated bit Diz se a baseline já foi ou não calculada. Dependencies group Dependent Tables Dependent Procedures 4.2 Baseline_Values A tabela baseline_values irá conter os valores para cada uma das baselines do sistema. Tabela interna de sistema. Nome Tipo Def. Null Idx Descrição 6 Especificação da base de dados

223 Especificação da base de dados bv_id int Chave primaria. bv_date datetime Data a que o valor diz respeito. bv_ae_rush decimal(15, 5) bv_ae_full decimal(15, 5) bv_ae_empty decimal(15, 5) bv_ae_superempty decimal(15, 5) Valor de consumo em horas de ponta. Valor de consumo em horas de cheira. Valor de consumo em horas de vazio normal. Valor de consumo em horas de super vazio. bl_id int Id da baseline. Dependencies baseline Dependent Tables Dependent Procedures 4.3 Baseline_Appliance A tabela Baseline_Appliance irá conter os electrodomésticos configurados para cada baseline. Nome Tipo Def. Null Idx Descrição ap_id int Chave primaria. ap_name nvarchar(100) Nome do electrodoméstico. ap_power decimal(15, 5) Potência nominal. ap_start timespan Hora de início de funcionamento. ap_end timespan Hora de fim de funcionamento dtt_index int Index no interface. bl_id int Id da baseline a que esta associada ao electrodomésticos. Dependencies baseline Dependent Tables Especificação da base de dados 7

224 Especificação da base de dados Dependent Procedures baseline bl_id g_id bl_date bl_last_id bl_next_id bl_last_date open_time close_time avac_power avac_start_time avac_stop_time bl_calculated baseline_value bv_id bv_date bv_ae_rush bv_ae_full bv_ae_empty bv_ae_superempty bl_id baseline_appliance ap_id ap_name ap_power ap_start ap_end bl_id dttt_index Figura 2 - Diagrama ER relativo a baseline 8 Especificação da base de dados

225 Especificação da base de dados 5 Tabelas Grupos Secção com as tabelas que constituem a funcionalidade de grupos. 5.1 Hierarchy Tabela que armazena a relação hierarquizada dos grupos. Nome Tipo Def. Null Idx Descrição Chave estrangeira que referencia h_parent int (pai) group Chave estrangeira que referencia h_group int (filho) group h_level tinyint Distância entre pai e filho h_references tinyint Número de referência devido a herança múltipla g_private bit Flag que indica se o grupo filho é privado ou não. Dependencies Dependent Tables Dependent Procedures group 5.2 Indicador Entidade relacionar que armazena indicadores. Nome Tipo Def. Null Idx Descrição ind_id int Chave primaria ind_operation nchar(3) String que representa a operação (sum, sub, avg ) String que representa o nome do group_details ou dos local_details ind_field nvarchar(50) (dependendo da flag isgroup) ind_name nvarchar(50) Nome do indicador. Valor constante que pode ser usado ind_constant decimal(15,5) no indicador Flag que indica que o indicador vai usar para cálculo o group_details ou ind_isgroup bit local_details Dependencies Dependent Tables Dependent Procedures group_indicator 5.3 Group Entidade que armazena todas as instâncias de um grupo. Especificação da base de dados 9

226 Especificação da base de dados Nome Tipo Def. Null Idx Descrição g_id int Chave primaria g_name nvarchar(20) Nome do grupo g_description nvarchar(100) Descrição do grupo g_deleted bit Flag que indica se o grupo esta a pagado. g_private bit Flag que indica que o grupo é privado (Pertence a um único utilizador). Dependencies Dependent Tables Dependent Procedures local group_tag, group_user, hierarchy, user 5.4 Group_Type Entidade que armazena todas as instâncias de um tipo de grupo. Nome Tipo Def. Null Idx Descrição gt_id int Chave primária. gt_name nvarchar(20) Nome do tipo de grupo. Dependencies Dependent Tables Dependent Procedures group 5.5 Group_Columns Entidade que armazena todas as instâncias dos parâmetros de um tipo de grupo. Nome Tipo Def. Null Idx Descrição gc_id int Chave primária. gc_name nvarchar(20) Nome do parâmetro. gt_id int Chave estrangeira que referencia o tipo de grupo. dttt_index int Index do parâmetro no tipo de grupo. Dependencies Dependent Tables Dependent Procedures group_type 5.6 Group_Columns_Values Entidade que armazena todas as instâncias dos valores associados aos tipos de grupo. Nome Tipo Def. Null Idx Descrição gtc_id int Chave primária. 10 Especificação da base de dados

227 Especificação da base de dados gtc_value nvarchar(20) Valor do parâmetro. gt_id int Chave estrangeira que referencia o tipo de grupo. g_id int Chave estrangeira que referencia o grupo. Dependencies Dependent Tables Dependent Procedures Group, group_type 5.7 Group_Schedule Entidade que armazena todas as instâncias de um hórario de um grupo. Nome Tipo Def. Null Idx Descrição sh_id int Chave primária. start_hour time Hora de início do turno. weekday int Dia da semana end_hour time Hora de fim do turno Dependencies Dependent Tables Dependent Procedures group 5.8 Group_Details Entidade que armazena detalhes do grupo que são usados no cálculo de indicadores. Nome Tipo Def. Null Idx Descrição Chave estrangeira que referencia um g_id int grupo. gd_name nvarchar(20) Nome do detalhe. gd_value Decimal(15,3) Valor do detalhe Dependencies Dependent Tables Dependent Procedures group 5.9 Group_Tag Entidade relacional que armazena todas as tags que pertencem a um certo grupo. Nome Tipo Def. Null Idx Descrição g_id tag_id int int Chave estrangeira que referencia o grupo. Chave estrangeira que referencia o tag Especificação da base de dados 11

228 Especificação da base de dados Dependencies Dependent Tables Dependent Procedures tag, group 5.10 Group_Indicator Entidade relacional que armazena todas os indicadores que pertencem a um certo grupo. Nome Tipo Def. Null Idx Descrição g_id tag_id Ind_id int int int Chave estrangeira que referencia o grupo. Chave estrangeira que referencia o tag Chave estrangeira que referencia o indicador Dependencies Dependent Tables Dependent Procedures tag, group, indicator 5.11 Group_User Entidade relacional que armazena todos os utilizadores que tem acesso a um certo grupo. Nome Tipo Def. Null Idx Descrição g_id usr_id int int Chave estrangeira que referencia o grupo. Chave estrangeira que referencia o utilizador Dependencies Dependent Tables Dependent Procedures tag, user 12 Especificação da base de dados

229 Especificação da base de dados group_columns_values gtc_id gtc_value g_id gc_id group_columns gc_id gc_name gt_id dttt_index group_type gt_id gt_name group_types_values g_id gt_id group_details g_id gd_name gd_value group_schedule_type sh_id sh_name g_id hierarchy h_parent h_group h_level h_references g_private group g_id g_name g_description g_deleted g_private gt_id group_schedule sh_id s_id weekday start_hour end_hour group_tag g_id tag_id indicator ind_id ind_operation ind_field ind_name ind_constant ind_isgroup group_indicator ind_id g_id tag_id gi_id group_user g_id usr_id Figura 3 - Diagrama ER relativo aos grupos Especificação da base de dados 13

230 Especificação da base de dados 6 Tabelas Tarifários Secção corresponde as tabelas dos tarifários. 6.1 Tariff Esta entidade armazena dados relativos aos tarifários. Nome Tipo Def. Null Idx Descrição tar_id int Chave primária. tar_name nvarchar(100) Nome do tarifário sup_id int Chave estrangeira a referencia o fornecedor. tar_deleted bit Flag que indica se o tarifário esta apagado ou não. tar_version smallint Número que indica a versão do tarifário. tar_start smalldatetime Data em que o tarifário começa a estar activo Data que indica quando a tarifária tar_end smalldatetime deixa de estar activo. Chave estrangeira que referencia a sse_id int tabela season_series Número que identifica as diferentes tar_tariff_identification int versões do mesmo tarifário usr_id int Chave estrangeira que identifica o utilizador que criou o tarifário. tar_ispublic Bit Flag que indica se a tarifa é publica. Dependencies Dependent Tables Dependent Procedures supplier interval, fixed_cost 6.2 Tariff_Parameter A tabela tariff_parameter irá conter os parâmetros associados a um determinado tarifário. Tabela interna de sistema. Nome Tipo Def. Null Idx Descrição tp_id int Chave primária. tp_type smallint Tipo de parâmetro (energia activa, potência, energia reactiva). tp_name ) nvarchar(100 Nome do parâmetro. 14 Especificação da base de dados

231 Especificação da base de dados tp_price smallmoney Custo associado ao parâmetro. tp_period smallint De quanto em quanto tempo é calculado o parâmetro (horário, mensal, diário) Dependencies tariff Dependent Tables Dependent Procedures 6.3 Multiplication_Factor A tabela multiplication_factor irá conter os factores de multiplicação associados a um determinado parâmetro de um tarifário. Tabela interna de sistema. Nome Tipo Def. Null Idx Descrição mf_id int Chave primária. mf_name nvarchar(100) Nome do factor de multiplicação mf_factor Decimal(15,5) Factor de multiplicação mf_min Decimal(15,5) mf_max Decimal(15,5) Valor mínimo para activar o factor. Valor máximo para activar o factor. tp_id int Ida do parâmetro do tarifário a que o factor de multiplicação pertence. Dependencies tariff_parameter Dependent Tables Dependent Procedures 6.4 Season Entidade que armazena o inicio e o fim que cada temporada. Nome Tipo Def. Null Idx Descrição s_begindate smalldatetime Data de início da temporada s_enddate smalldatetime Data de fim da temporada s_id int Chave primária Especificação da base de dados 15

232 Especificação da base de dados s_deleted bit Flag se a temporada foi apagada Chave estrangeira para a sse_id int season_series Indice da temporada. (e.x. 1, 2, ) Onde 1=1 st trimestre 2= 2 nd trimestre s_season tinyint 3=3 rd trimestre Dependencies Dependent Tables Dependent Procedures season_series 6.5 Season_Series Entidade que armazena os tipos de temporadas que podem ser usadas nos tarifários. Nome Tipo Def. Null Idx Descrição sse_id int Primary Key sse_type nvarchar(50) Descrição do tipo de temporada. sse_number_seasons tinyint Número de temporadas nesta serie. Dependencies Dependent Tables Dependent Procedures tariff 6.6 Inteval Entidade que armazena os intervalos de facturação de um tarifário. Nome Tipo Def. Null Idx Descrição int_id int Chave primária int_start time(0) Hora de início do intervalo. int_end time(0) Hora de fim de fim do intervalo s_season int Índex da temporada nas séries int_weekday tinyint Dias da semana (bit mask) int_price smallmoney Preço por unidade Chave estrangeira que referencia a tar_id int tarifa. h_type tinyint Tipo de hora. Dependencies Dependent Tables Dependent Procedures tariff 6.7 Fixed_Costs Entidade que armazena os custos fixos associados a um tarifário. 16 Especificação da base de dados

233 Especificação da base de dados Nome Tipo Def. Null Idx Descrição fxc_id int Chave primária fxc_description nvarchar(50) Descrição do custo fixo fxc_price smallmoney Valor do custo Chave estrangeira que referencia a tar_id int tarifa Dependencies Dependent Tables Dependent Procedures tariff season_series sse_id sse_type sse_number_seasons season s_season s_begindate s_enddate s_id sse_id fixed_cost fxc_id fxc_description fxc_price tar_id contracted_power tariff tar_id tar_name sup_id tar_intervals tar_deleted tar_version tar_start tar_end tar_issingle_step sse_id tar_isstepbased tar_tariff_identification usr_id tar_ispublic interval int_id int_start int_end s_season int_weekday tar_id int_type tariff_parameter tp_id tp_type tar_id tp_price tp_period tp_name p_id multiplication_factor mf_id mf_name mf_min mf_max mf_factor tp_id tariff_parameter_season tp_id s_season tps_id Figura 4 - Diagrama ER relativo aos tarifários Especificação da base de dados 17

234 Especificação da base de dados 7 Tabelas KPI s Nesta secção encontram-se todas as tabelas relacionadas com os KPI s. 7.1 KPI A tabela KPI irá conter informação sobre os KPIs existentes e para os quais serão feitos carregamentos de dados. Nome Tipo Def. Null Idx Descrição kpi_id int Chave primária. kpi_name nvarchar(100) Nome do KPI. kpi_description nvarchar(4000) Descrição do KPI. kpi_type mu_id nchar(10) tinyint Tipo de KPI, valores possíveis: Hourly, Daily, Weekly, Monthly, Yearly Unidade de medida para os valores do KPI. kpi_last_load datetime A última data usada para ler valores para um KPI específico. Quando for null vai ser usado como defeito. kpi_active bit Flag que indica se o KPI está activo. Activo 1 Inactivo -0 Dependencies Dependent Tables KPI_DATA, KPI_ERROR_LOG Dependent Procedures 7.2 KPI_DATA A tabela KPI_DATA irá conter todos os dados associados aos KPIs. O carregamento de dados para esta tabela será feito através de Stored Procedures, que serão escalonados através de SQL Server Job. Nome Tipo Def. Null Idx Descrição kpi_id int Chave estrangeira que referência o KPI. 18 Especificação da base de dados

235 Especificação da base de dados kpid_value decimal(15, 5) Valor do KPI. kpid_current_value decimal(15, 5) kpid_reference_value decimal(15, 5) Valor current lido para calcular o KPI (kpid_value). O valor de referência lido para calcular o KP (kpid_value). Este é usado quando é definido um objectivo. kpid_date datetime Data a qual o KPI está associado. tag_id unt_id kpid_branch_code kpid_branch_name int int nvarchar(50) nvarchar(50) ID da tag a qual o KPI esta associado. ID da unidade a qual o KPI esta associado. Código do grupo ao qual a mensagem esta associada. Nome do grupo ao qual a mensagem esta associada. Dependencies Dependent Tables Dependent Procedures KPI 7.3 KPI_MESSAGE A tabela KPI_MESSAGE irá conter as mensagens registadas pelo gestor de energia para notificação das agências relativamente a problemas encontrados. Nome Tipo Def. Null Idx Descrição kpim_id int Primary Key. kpim_date datetime Data de criação da mensagem. kpim_severity nchar(10) Gravidade da mensagem: Grande, Média and pequena. kpim_title nvarchar(100) Título da menssagem. kpim_body nvarchar(4000) Corpo da mensagem. kpim_branch_code nvarchar(50) Código do grupo ao qual a mensagem esta associada. Especificação da base de dados 19

236 Especificação da base de dados kpim_branch_name nvarchar(50) Nome do grupo ao qual a mensagem esta associada. Dependencies Dependent Tables Dependent Procedures 7.4 KPI_CONF A tabela KPI_CONF irá conter configurações que serão usadas pelos procedimentos durante a execução. Tabela interna de sistema. Nome Tipo Def. Null Idx Descrição kpic_code nvarchar(100) Primary Key. Código da configuração. kpic_value nvarchar(100) Valor da configuração. kpic_description nvarchar(4000) Descrição da configuração do KPI. Dependencies Dependent Tables Dependent Procedures 7.5 KPI_ERROR_LOG A tabela KPI_ERROR_LOG irá registar os problemas encontrados durante a execução dos Stored Procedures de forma a facilitar a identificação e correcção de problemas. Tabela interna de sistema. Nome Tipo Def. Null Idx Descrição kpi_id int Chave estraneira que referencia o KPI. kel_error_number int Número do erro. kel_error_severity int Gravidade do erro. kel_error_state int Estado do erro. kel_error_line int Linha do erro. 20 Especificação da base de dados

237 Especificação da base de dados kel_error_procedure nvarchar(200) Procedimento do erro. kel_error_message nvarchar(4000) Mensagem do erro. kel_date datetime Data de ocorrencia do erro. Dependencies KPI Dependent Tables Dependent Procedures Figura 5 - Diagrama ER relativo aos KPI Especificação da base de dados 21

238 ienergy Eficiência Energética em Edifícios Anexo VI Fase de Integração Anexo VI Requisitos Fase de Integração

239

240 ienergy Eficiência Energética em Edifícios Anexo VI Fase de Integração Este anexo apresenta os requisitos detalhados para a fase de integração relativos ao projecto de eficiência energética em embarcações. Associar Mestres a Viagem (RFMV) No módulo Gestão -> Mestres e Viagens" deve ser possível associar mestres a viagens, bem como consultar os já existentes no sistema. Requisito Descrição RFA01 Introdução deve ser feita através da importação de um ficheiro Excel. RFA02 RFA03 RFA04 RFA05 RFA06 RFA07 RFA08 Deve ser possível seleccionar o ficheiro a importar. O ficheiro deve conter a seguinte informação: o Nome do mestre o Embarcação (nome da embarcação) o Data inicial o Data final Após seleccionar o ficheiro para importar, caso existam erros, deve aparecer um menu intermédio apresentando os mesmos. Caso existam erros, deve inserir os registos possíveis, indicando os registos que apresentam erros. A tabela de erros deve ter as seguintes colunas: o Nome do mestre o Embarcação (nome da embarcação) o Data inicial o Data final o Descrição do erro Se a associação a introduzir já existir no sistema, deve sobrepor à existente, actualizando o portal. Após importação do ficheiro deverá aparecer uma mensagem a apresentar o resultado da operação (sucesso ou insucesso). Notas Caso ocorram erros na validação do ficheiro, antes de importar, é apresentado um menu intermédio ao utilizador indicando os conflitos no ficheiro. Um erro pode ter origem em falta de dados ou dados inválidos. Um exemplo pode ser Embarcação não existente. A edição de uma associação é realizada através de nova introdução do ficheiro. Integração com bilhética para criação de viagens (RFBL) O sistema deve permitir criar viagens com base em ficheiros de bilhética. Requisito Descrição RFBL01 Serviço deve processar ficheiros de bilhética. RFBL02 RFBL03 Para cada viagem existente no ficheiro, o serviço deve verificar se essa viagem já existe no sistema. Caso uma viagem não exista no sistema, esta deve ser inserida. Os dados Especificação de requisitos 1

241 Anexo VI Fase de Integração ienergy Eficiência Energética em Edifícios necessários para inserir uma viagem são: o Data o Hora o Terminal partida o Carreira o Embarcação o Passageiros o Tipo Viagem (Carreira) o Estado da viagem (Válida) Notas O formato dos dados dos ficheiros de bilhética contém a seguinte informação: <dia value=" "> <cais value="1501"> <hora value="10:20"> <horaprevista>10:20</horaprevista> <navio>51</navio> <carreira>7</carreira> <passageiros>44</passageiros> </hora> </cais> </dia> Sempre que existam viagens de bilhética por criar, deve-se verificar na tabela de Abastecimentos se existem registos por processar para as datas das viagens a inserir. Caso existam deve-se cruzar a informação e efectuar o cálculo dos consumos. Após este processo deve-se marcar o abastecimento como processado. Gestão de Alarmística - Web (RFAL) A aplicação deve permitir ao utilizador visualizar os alarmes existentes no sistema. Requisito RFAL01 Descrição Na página inicial, deve ser apresentada uma mensagem indicando o número de alarmes Por processar. RFAL02 RFAL03 RFAL04 RFAL05 RFAL06 RFAL07 Deverá existir um link na mensagem por forma a redireccionar para o módulo Operações -> Gestão de Alarmes. Na página inicial, deverá ser apresentada uma tabela com os alarmes Por processar. Na tabela com os alarmes não processados deve ser possível seleccionar alarmes, colocando-os no estado Em processamento. Para tal deve ser possível aceder à página de edição da viagem. As colunas da tabela de alarmes Por processar são: o Data/Hora o Embarcação o Mensagem o Estado No módulo Operações -> Gestão de Alarmes deve ser possível pesquisar alarmes. A pesquisa deve permitir filtragem por: o Data 2 Especificação de requisitos

242 ienergy Eficiência Energética em Edifícios Anexo VI Fase de Integração o o Embarcação Estado RFAL08 RFAL09 RFAL10 RFAL11 RFAL12 Possibilidade de visualizar os alarmes resultantes da pesquisa através de uma tabela. As colunas a apresentar na tabela são: o Data/Hora o Embarcação o Mensagem o Estado A tabela de alarmes deve ter paginação. Deve ser possível editar o estado do alarme. Deve ser possível editar as notas relativas ao alarme. Notas Devem existir três estados distintos para os alarmes: o Por processar o Em processamento o Processado Para os alarmes do navio, só são exibidos como novos (Por processar), caso não exista nenhum alarme com o estado Em Processamento ou Por processar para o navio em causa. Podemos ter os seguintes tipos de alarme de navio: o Falha de comunicação o Falha de GPS (existe comunicação mas sem informação de localização) o Falha de caudalímetro (se houver velocidade e caudalimetro for zero) o Falha de nível de combustível o Aquecimento o Motores/Carreira menor que 30 Os alarmes da bilhética, são sempre exibidos. Podemos ter os seguintes tipos: o Ficheiros de bilhética não existentes (em caso de atraso ou falha do sistema de bilhética) No caso do aquecimento do navio, devem ser tidos em conta os seguintes parâmetros anormais: o Consumo/Viagem (aquecimento) inferior a 5 e superior a 60 o Tempo/Viagem (aquecimento) maiores que 50 minutos Velocidade instantânea superior a 2 nós (ou outro valor a definir) o Mecanismo de criação de alarmes (RFMA) Deverá existir um mecanismo responsável pela geração de alarmes do sistema. Desse mecanismo fazem parte os serviços de recolha de dados e de bilhética. Requisito RFMA01 Descrição O serviço de recolha de dados tem de distinguir entre os diferentes tipos de alarme RFMA02 RFMA03 O serviço de recolha tem de identificar se o alarme já ocorreu e/ou o seu estado. O serviço de bilhética tem de gerar alarmes. Notas Especificação de requisitos 3

243 Anexo VI Fase de Integração ienergy Eficiência Energética em Edifícios Os alarmes do navio, só são gerados, caso não exista nenhum alarme com o estado Em Processamento ou Por processar para o navio em causa. Os alarmes da viagem, só são gerados, caso não exista nenhum alarme com o estado Em Processamento ou Por processar, para a viagem em causa. Os alarmes da bilhética, são sempre gerados. Mecanismo de validação de viagens novas regras Abaixo estão descritas as novas regras para validação de viagens. Notas No módulo de validação de viagens devem ser incluídos os seguintes parâmetros como sendo necessária validação: o Consumo/Viagem inferior a 20 e superior a 220 o Distância/Carreira superior a metros o Tempo/Viagem menor que 6 e maiores que 35 minutos o Velocidade instantânea superior ou igual a 25 nós Neste módulo, deve ser incluído a informação pela qual a viagem foi considerada invalida e um campo de observações para que o operador possa colocar qualquer comentário que ache necessário. Relatório embarcação dados gerais (REDG) O sistema deverá permitir a criação de relatórios com os dados gerais das embarcações para um determinado mês/ano ou para todo o ano. Requisito REDG01 REDG02 REDG03 REDG04 REDG05 REDG06 Descrição Deverá existir no portal duas páginas dedicadas a criação de relatórios sobre os dados gerais das embarcações, uma para relatórios anuais, outra para relatórios mensais. Na página de relatórios mensais deverá ser possível seleccionar o ano e o mês para o qual se pretende criar um novo relatório. Na página de relatórios anuais deverá ser possível seleccionar o ano para o qual se pretende criar um novo relatório. O relatório para o mês ou ano escolhido e apresenta uma tabela com as seguintes colunas: Nome da embarcação; Consumo Horário (L/h) (caudalímetro); Consumo Horário (L/h) (Registos); Consumo/Carreira (L) (caudalímetro); Consumo/Carreira (L) (Registos; Consumo Total (L) (caudalímetro); Consumo Total (L) (Registos); Custo/Km (Euro/km); Distância/Carreira; Eficiência da Oferta (pkm/l); Eficiência da Procura (pkm/l); Motores/Carreira (%); Passageiros/Carreira (nº); Peso transportado (Kg); Tempo/Viagem (min); Velocidade (nós); Carreiras realizadas Deve ser possível pré-visualizar o relatório na página. Deve ser possível exportar o relatório criado para um dos seguintes formatos: DOC, XLS, PDF. 4 Especificação de requisitos

244 ienergy Eficiência Energética em Edifícios Anexo VI Fase de Integração Notas Todos os cálculos são baseados na tabela Indicators, alguns dos valores são médias outros são somas. De seguida é apresentada a forma que cada um destes indicadores é calculado: Consumo Horário (L/h) (caudalímetro) Consumo médio horário de uma embarcação numa viagem do tipo carreira; Consumo Horário (L/h) (Registos) Consumo médio horário de uma embarcação numa viagem do tipo carreira através dos registos de consumos inseridos; Consumo/Carreira (L) (caudalímetro) Consumo médio de uma embarcação por viagem do tipo carreira; Consumo/Carreira (L) (Registos) Consumo médio de uma embarcação por viagem do tipo carreira através dos registos de consumos inseridos; Consumo Total (L) (caudalímetro) Soma dos consumos de uma embarcação; Consumo Total (L) (Registos) Soma dos consumos de uma embarcação dos registos de consumos inseridos; Custo/Km (Euro/km) Custo médio da embarcação por Km percorrido; Distância/Carreira Distância media percorrida por viagem do tipo carreira; Eficiência da Oferta (pkm/l) - Eficiência média da oferta por pkm/l; Eficiência da Procura (pkm/l) Eficiência média da procura por pkm/l; Motores/Carreira (%) Percentagem de utilização dos motores em viagens do tipo carreira (( Tempo viagem tipo carreira - tempo viagem manobras)/( Tempo outras viagens Tempo carreira - Tempo manutenção)); Passageiros/Carreira (nº) - Número médio de passageiros por viagem do tipo carreira; Peso transportado (Kg) Peso médio transportado por viagem do tipo carreira; Tempo/Viagem (min) - Duração média de cada viagem do tipo carreira; Velocidade (nós) - Velocidade média das viagens do tipo carreira; Carreiras realizadas Soma das viagens do tipo carreira realizadas. Os dados que não e possível adquirir através do cauldalímetro são assinaladas com N/A (Não aplicável) os dados que não e possível calcular por não existirem dados são assinaladas com S/D (Sem dados). Relatório de uso de embarcação (RUE) O sistema deverá permitir a criação de relatórios com os dados de uso de uma embarcação para um determinado intervalo de datas. Requisito RUE01 RUE02 RUE03 RUE04 Descrição Deverá existir no portal uma página dedicada a criação de relatórios sobre o uso de uma embarcação. Na página do relatório mensal deverá ser possível seleccionar uma data inicial e final para criação do relatório. Na página do relatório mensal deverá ser possível seleccionar a embarcação para criar o relatório. Deverá existir uma tabela para cada um dos meses do ano com os dados gerais da embarcação. As linhas da tabela são: Nome da embarcação Consumo Horário (L/h) (caudalímetro); Consumo Horário (L/h) (Registos; Consumo/Carreira (L) (caudalímetro); Consumo/Carreira (L) (Registos); Consumo Total (L) (caudalímetro; Consumo Total (L) (Registos); Custo/Km (Euro/km); Distância/Carreira. Eficiência da Oferta (pkm/l); Eficiência da Procura (pkm/l); Motores/Carreira (%); Passageiros/Carreira (nº); Peso transportado (Kg); Tempo/Viagem (min); Velocidade (nós); Carreiras realizadas. Especificação de requisitos 5

245 Anexo VI Fase de Integração ienergy Eficiência Energética em Edifícios RUE05 REDG06 REDG07 REDG08 REDG09 Deverá existir uma tabela para cada um dos meses do ano com os tempos totais em percentagem gastos em cada um dos tipos de viagens. As linhas da tabela são: Outras viagens; Aquecimento; Carreira; Manobras; Por Validar; Tempo ao cais; Tempo geral; Total registos. Deverá existir uma tabela para cada um dos meses do ano com os consumos totais gastos em cada um dos tipos de viagens. As linhas da tabela são: Outras viagens; Aquecimento; Cruzeiro; Manobras; Por Validar; Tempo ao cais; Tempo geral; Total registos. Deverá existir uma tabela com dados para cada um dos mestres por área geográfica em relação as carreiras realizadas, velocidade e peso. As colunas da tabela são: Mestre Nome dos mestres; Consumo o Média; o Desvio padrão. Velocidade o Média; o Desvio padrão. Peso o Média; o Desvio padrão. Consumo total; Passageiros totais; Distância total percorrida; Nº Carreiras. Deve ser possível pré-visualizar o relatório na página. Deve ser possível exportar o relatório criado para um dos seguintes formatos: DOC, XLS, PDF. Notas Todos os cálculos são baseados na tabela Indicators, alguns dos valores são médias outros são somas. Este relatório está dividido por várias tabelas. De seguida é apresentada a forma que cada um destes indicadores dessas tabelas é calculado. Os indicadores da tabela para cada um dos meses do ano com os dados gerais da embarcação são calculados da seguinte forma: Consumo Horário (L/h) (caudalímetro) Consumo médio horário de uma embarcação numa viagem do tipo carreira; Consumo Horário (L/h) (Registos) Consumo médio horário de uma embarcação numa viagem do tipo carreira através dos registos de consumos inseridos; Consumo/Carreira (L) (caudalímetro) Consumo médio de uma embarcação por viagem do tipo carreira; Consumo/Carreira (L) (Registos) Consumo médio de uma embarcação por viagem do tipo carreira através 6 Especificação de requisitos

246 ienergy Eficiência Energética em Edifícios Anexo VI Fase de Integração dos registos de consumos inseridos; Consumo Total (L) (caudalímetro) Soma dos consumos de uma embarcação; Consumo Total (L) (Registos) Soma dos consumos de uma embarcação através dos dados inseridos; Custo/Km (Euro/km) Custo médio da embarcação por Km percorrido; Distância/Carreira Distância média percorrida por viagem do tipo carreira. Eficiência da Oferta (pkm/l) - Eficiência média da oferta por pkm/l; Eficiência da Procura (pkm/l) Eficiência média da procura por pkm/l; Motores/Carreira (%) Percentagem de utilização dos motores em viagens do tipo carreira; Passageiros/Carreira (nº) - Número médio de passageiros por viagem do tipo carreira; Peso transportado (Kg) Peso médio transportado por viagem do tipo carreira; Tempo/Viagem (min) - Duração média de cada viagem do tipo carreira; Velocidade (nós) - Velocidade média das viagens do tipo carreira durante um intervalo de tempo; Carreiras realizadas Número das viagens do tipo carreiras realizadas. Os indicadores para a tabela de tempos totais em percentagem gastos em cada um dos tipos de viagens, são calculados da seguinte forma: Outras viagens - Percentagem de tempo total gasto em viagens validas que não são cruzeiro, manobras, tempo em cais ou aquecimento; Aquecimento Percentagem de tempo total gasto em viagens validas do tipo aquecimento; Carreira - Percentagem de tempo total gasto em viagens validas do tipo Carreira; Manobras - Percentagem de tempo total gasto em viagens validas do tipo manobras; Por Validar - Percentagem de tempo total gasto em todas as viagens que ainda não estão validadas; Tempo ao cais - Percentagem de tempo total gasto em cais que ainda não estão validadas, em cada um dos meses do ano; Tempo geral Tempo total em horas gasto para cada uma das viagens acima descritas; Total registos Tempo total de funcionamento calculado a partir dos dados introduzidos. Os indicadores da tabela de consumos totais gastos em cada um dos tipos de viagens, são calculados da seguinte forma: Outras viagens Consumo em viagens validas que não sejam viagens de carreira, manobra, tempo em cais ou aquecimento; Aquecimento Consumo em viagens validas do tipo aquecimento; Cruzeiro - Consumo em viagens validas do tipo carreira; Manobras - Consumo em viagens validas do tipo manobras; Por Validar - Consumo médio em viagens que não estão validadas; Tempo ao cais - Consumo médio em cais de viagens validadas; Tempo geral - Consumo total gasto para cada mês do ano; Os indicadores na tabela para cada um dos mestres por área geográfica em relação as carreiras realizadas, velocidade e peso, são calculados da seguinte forma: Consumo - Cálculo do consumo para cada um dos mestres o Média Valor médio de consumo do mestre em viagens do tipo carreira para o intervalo de tempo especificado; o Desvio padrão Desvio padrão amostral de consumo de viagens do tipo carreira. Velocidade - Cálculo da velocidade para um mestre o Média Velocidade média do mestre em viagens do tipo carreira; o Desvio padrão Desvio padrão amostral de velocidade de viagens do tipo carreira. Peso - Cálculo do peso carregado por cada mestre nas viagens realizadas o Média Media de pesos de viagens do tipo carreira por cada mestre; o Desvio padrão Desvio padrão amostral do peso de viagens do tipo carreira. Consumo total Consumo total de combustível em viagens do tipo carreira por cada mestre; Passageiros totais Número total de passageiros em viagens do tipo carreira para cada um dos mestres; Distância total percorrida Distância total percorrida em viagens do tipo carreira por cada um dos mestres; Nº Carreiras Total de viagens do tipo carreira realizadas por cada um dos mestres. Total registos Consumo total calculado a partir dos dados introduzidos. Os tempos são calculados a partir da hora de partida e chegados registados na tabela journey. O intervalo de datas deve ser no máximo um ano. Os dados que não e possível adquirir através do cauldalímetro são assinaladas com N/A (Não aplicável) os dados que não e possível calcular por não existirem dados são assinaladas com S/D (Sem dados). A fórmula usada para calcular o desvio padrão é a seguinte: S 1 k i1 f k i i1 (( x x) i 2 f ) i Especificação de requisitos 7

247 Anexo VI Fase de Integração ienergy Eficiência Energética em Edifícios Relatório de carreiras por área geográfica (RCAG) O sistema deverá permitir a criação de relatórios com dados relativos as carreiras realizadas para cada área geográfica para um determinado intervalo de datas. Requisito RCAG01 RCAG02 RCAG03 RCAG04 RCAG5 RCAG6 RCAG7 Descrição Deverá existir no portal uma página dedicada a criação de relatórios sobre o uso de uma embarcação. Na página do relatório deverá ser possível seleccionar uma data inicial e final para criação do relatório. Na página do relatório deverá ser possível seleccionar a área geográfica. Deverá existir uma tabela com alguns dados da embarcação. As colunas da tabela são: Número Carreiras; Consumo/Carreira o Desvio Padrão Consumo/Carreira (Registos); Passageiros/Carreira o Desvio Padrão Deverá existir uma tabela com alguns dados das ligações para a área geográfica. As colunas da tabela estão divididas fim-de-semana e feriados para cada uma dessas divisões são calculados os indicadores: Passageiros/carreira; Desvio padrão. Deve ser possível pré-visualizar o relatório na página. Deve ser possível exportar o relatório criado para um dos seguintes formatos: DOC, XLS, PDF. Notas Todos os cálculos são baseados na tabela Indicators, alguns dos valores são médias outros são somas. Este relatório está dividido em duas tabelas. Estas tabelas são apresentadas de seguida. Os indicadores na tabela com dados de embarcação, são calculados da seguinte forma: Número Carreiras Número total de carreiras para a área geográfica em análise; Consumo/Carreira Consumo médio por carreira (media de consumo por viagem do tipo carreira para a área geográfica). o Desvio Padrão Desvio padrão amostral de consumo por carreira. Consumo/Carreira (Registos) Consumo por carreira baseado nos registos inseridos através do ficheiro de consumos; Passageiros/Carreira Média de passageiros por carreira (média de passageiros em viagens do tipo carreira) o Desvio Padrão Desvio padrão amostral de passageiros por carreira. Os indicadores na tabela com as medias e desvio padrão de passageiros, são calculados da seguinte forma: Passageiros/carreira Média de passageiros por carreira (média de passageiros em viagens do tipo carreira). Desvio padrão Diferença entre o valor máximo e mínimo de passageiros por carreira. Os dados que não e possível adquirir através do cauldalímetro são assinaladas com N/A (Não aplicável) os dados que não e possível calcular por não existirem dados são assinaladas com S/D (Sem dados). A fórmula usada para calcular o desvio padrão é a seguinte: S 1 k i1 f k i i1 (( x x) i 2 f ) i 8 Especificação de requisitos

248

249 ienergy Eficiência Energética em Edifícios Anexo VII Manual de Utilizador Anexo VII Manual de Utilizador

250

251 Manual de utilizador Jul. 2011

252

253 Manual de Utilizador Índice 1 INTRODUÇÃO ÍCONES DA APLICAÇÃO VISUALIZAÇÃO ÁRVORE DE AGÊNCIAS E EDIFÍCIOS CAMPOS DE FILTRAGEM Calendário Intervalo de Datas Granularidade Tipos de Hora Horas Intervalos Opções de Visualização Operações VISUALIZAÇÃO DO GRÁFICO (E TABELAS DE DADOS) Gráfico Tabela Geral Tabela De Conclusões Análise de Custos MENSAGENS SIMULAÇÃO RESULTADOS RELATÓRIOS SECÇÃO DE ENERGIA ACTIVA SECÇÃO DE ENERGIA REACTIVA SECÇÃO DE FACTOR DE POTÊNCIA SECÇÃO DE ANÁLISE DE POTÊNCIA SECÇÃO DE INDICADORES DE ESTADO SECÇÃO DE INDICADORES DE POUPANÇA POUPANÇA DE ENERGIA ACTIVA POUPANÇA DE DINHEIRO POUPANÇA DE EMISSÕES OPERAÇÕES DE BACK OFFICE ALERTAS TIPOS DE GRUPOS Listar Detalhes Editar Adicionar Tipo de Grupo GRUPOS Listar Detalhes Adicionar Grupo Alertas... 32

254 6.4 FACTURAÇÃO Fornecedores Tarifas ESTAÇÕES PLUGINS ALERTAS LISTAGEM EDITAR ADIÇÃO... 49

255 Manual de Utilizador 1 Introdução O portal ienergy4buildings é um portal de eficiência energética que permite fazer análise de consumo, simulações de tarifários e produzir relatórios que permitam analisar os gastos e proveitos associados ao comportamento energético de edifícios. Existe ainda um back office que permite fazer administração de algumas entidades do sistema. O portal divide-se em quatro secções distintas que são as seguintes: Visualização secção que permite fazer a análise e comparação de consumos com diferentes intervalos de tempo; Mensagens secção que permite as mensagens que aparecem nos aplicativos disponíveis aos utilizadores do sistema; Simulação secção que permite fazer simulações para identificar a melhor tarifa a ser aplicada a cada edifício; Relatórios secção que permite gerar relatórios que possibilitam analisar o comportamento energético de um edifício. Tarifários Permite fazer gestão dos tarifários existentes no sistema. Grupos Permite fazer a gestão dos grupos existentes no sistema. Alertas Permite gerir e ver os alertas disparados no sistema. Neste documento são descritas as secções indicadas em detalhe para que o utilizador consiga tirar um melhor proveito do sistema. Manual de Utilizador 1

256 Manual de Utilizador 1.1 Ícones da aplicação Ícone Funcionalidade Adicionar um registo. Indicação que uma acção está a ser executada. Representa um campo do tipo booleano marcado com o valor falso. Representa um campo do tipo booleano marcado com o valor verdadeiro. Acesso ao componente calendário. Botões para expandir e encolher. Apagar um registo. Editar um registo. Atribuir nova password. Indicação do estado OK de uma Unidade, Dispositivo ou Tag. Exportar dados para um ficheiro do tipo excel. Executar pesquisa. Exportar os dados para um ficheiro excel. Indica que está a ser feito um pedido ao servidor. 2 Visualização A secção de visualização é a secção que permite analisar os consumos de um ou mais edifícios/agências. Ao aceder a esta secção é apresentada uma janela semelhante à seguinte: 2 Manual de Utilizador

257 Manual de Utilizador Imagem 1 - Janela de Visualização A secção de Visualização divide-se em 3 áreas: Árvore das Agências e Edifícios Campos de Filtragem do Gráfico Visualização do Gráfico (e Tabelas de dados) 2.1 Árvore de Agências e Edifícios A caixa de pesquisa: Imagem 2 - Caixa de Pesquisa permite filtrar, na árvore, a(s) agência(s) e edifício(s) pelo seu nome, reduzindo assim o tempo que o utilizador demora a localizar uma agência em específico. A Árvore apresenta vários níveis: Manual de Utilizador 3

258 Manual de Utilizador Imagem 3 Árvore - Nível Topo : Estão localizadas as agências e edifícios; - Nível Intermédio : Estão localizados os grupos das agências e edifícios; - Nível Folha : Estão localizadas as variáveis de medida (que contêm os consumos de energia) Pode navegar-se na árvore expandido os nós de nível superior (topo) até ao nível mais inferior (folha). Para cada grupo é permitida a selecção de variáveis de medida para posteriormente serem apresentados os respectivos dados no gráfico gerado, conforme os parâmetros de filtragem seleccionados. Nota: Pode seleccionar de 1 a 10 variáveis de medida para serem representadas no gráfico tendo de ter no máximo 2 unidades diferentes entre as variáveis seleccionadas. As variáveis de medida podem ser de 3 tipos: Variáveis de medida primárias (Ex. Temperatura, Energia Activa, ); Variáveis de medida secundárias (Ex. Energia Activa Dispositivo 1 + Energia Activa Dispositivo 2); Indicadores (Ex. Energia Activa / Nº de Pessoas). Nota: As variáveis de medida primárias e secundárias e os indicadores têm de ser previamente configurados no sistema para poderem ser visualizados na árvore. Ao seleccionar determinadas variáveis de medida, o utilizador pode ter de escolher a Unidade a visualizar como se apresenta na seguinte janela: Imagem 4 - Selecção de Unidades Nesta janela o utilizador pode escolher que unidades irá aparecer representadas no gráfico. Pode escolher a unidade por defeito da variável de medida (1ª escolha) ou outra unidade de medida, que resulta da aplicação de um factor de conversão sobre a unidade da variável de medida. Nota: Os factores de conversão têm de ser previamente configurados no BackOffice. 2.2 Campos de Filtragem Nesta secção encontram-se todos os campos que permitem a filtragem dos resultados apresentados nos gráficos (e tabelas) gerados Calendário Ao escolher a opção os resultados do gráfico serão filtrados por intervalos de tempo contínuos e/ou descontínuos. Pode-se seleccionar 1 ou vários dias do calendário podendo estar localizados em meses e anos diferentes (Imagem 5): 4 Manual de Utilizador

259 Manual de Utilizador Imagem 5 - Calendário Nota: Por definição, no calendário, está seleccionado o dia anterior ao dia actual Intervalo de Datas Ao escolher a opção os resultados do gráfico serão filtrados por um intervalo de tempo contínuo entre uma data inicial e uma data final (Imagem 6): Imagem 6 - Intervalo de Datas Granularidade O campo Granularidade permite definir o detalhe do gráfico gerado. O utilizador pode escolher entre três opções (Imagem 7): Granularidade Horária: Gráfico gerado apresenta os resultados com detalhe horário (As unidades do eixo XX do gráfico são representadas em horas); Granularidade Diária: Gráfico gerado apresenta os resultados com detalhe diário. (As unidades do eixo XX do gráfico são representadas em dias); Granularidade Mensal: Gráfico gerado apresenta os resultados com detalhe mensal. (As unidades do eixo XX do gráfico são representadas em meses) Tipos de Hora Imagem 7 Granularidade Ao escolher a opção de Granularidade Horária o utilizador pode filtrar os resultados do gráfico nos diferentes tipos de hora existentes na aplicação (Imagem 8). Imagem 8 - Tipos de Hora Por exemplo, estando só seleccionado o tipo Horas de Ponta só serão apresentados dados no gráfico, de horas que estejam configuradas como horas de ponta no tarifário do dispositivo que esteja seleccionado na árvore Horas Os campos Hora Início e Hora Final permitem filtrar os dados do gráfico pelo intervalo definido entre as mesmas (Imagem 9) Intervalos Imagem 9 Horas O utilizador pode ainda definir vários intervalos de tempo contínuos a serem representados no gráfico e com várias opções na apresentação dos resultados sobre os dados desses mesmos intervalos (Imagem 10): Manual de Utilizador 5

260 Manual de Utilizador Imagem 10 - Intervalos de Tempo Podem acrescentar-se intervalos à listagem de intervalos de duas formas: - Usando a opção a Data de Início do intervalo será o dia mais antigo seleccionado no calendário e a Data de Fim será o dia mais recente seleccionado no calendário; - Usando a opção a Data de Início será igual ao valor de Data Início e a Data de Fim será igual ao valor de Data Fim. O utilizador pode escolher entre 4 opções (operações) de amostragem dos dados no gráfico nos intervalos de tempo definidos na listagem: A opção irá apresentar os dados no gráfico fazendo a média dos valores em cada intervalo de tempo definido; A opção irá apresentar os dados no gráfico fazendo a soma dos valores em cada intervalo de tempo definido; A opção irá apresentar os dados no gráfico fazendo a média sobre os valores de todos os intervalos de tempo definidos; A opção irá apresentar os dados no gráfico fazendo a soma sobre os valores de todos os intervalos de tempo definidos Opções de Visualização São ainda possibilitadas outras opções de configuração da visualização do gráfico a ser gerado. As opções (Imagem 11) são as seguintes: Imagem 11 - Opções de Visualização Gráfico de regressão linear - O gráfico gerado apresenta a relação entre 2 variáveis de medida, com unidades diferentes. Ao seleccionar esta opção a selecção Inverter fica disponível. Seleccionando a opção Inverter o gráfico gerado representa a relação invertida das mesmas variáveis; Linhas de Média, Máximo e Mínimo - O gráfico gerado apresenta as linhas de média, máximo e mínimo para os dados apresentados no gráfico; Trendline? - O gráfico gerado apresenta as linhas de tendência para os dados apresentados no gráfico; Custos de energia? - Caso a opção Granularidade Horária esteja seleccionada são identificados no gráfico os vários tipos de horas (com símbolos e cores diferentes para cada tipo de hora); 6 Manual de Utilizador

261 Manual de Utilizador Tipo de Gráfico - Existem três possibilidades de escolha: o o o Linhas - Gráfico gerado com linhas; Barras - Gráfico gerado com barras; Stacked Bars - Gráfico gerado com barras cumulativas Operações Nesta área estão disponíveis 2 botões que permitem executar as seguintes acções: limpa os dados que foram seleccionados nos campos de filtragem e as selecções na árvore de agências e edifícios; gera o gráfico conforme os parâmetros de filtragem seleccionados e as selecções na árvore de agências e edifícios. 2.3 Visualização do Gráfico (e Tabelas de dados) A área de visualização do gráfico está dividida por várias secções (Gráfico, Tabela Geral, Tabela de Conclusões e Análise de Custos). O link Exportar Dados permite exportar os dados visualizados nesta área para um ficheiro no formato excel Gráfico A secção Gráfico apresenta o gráfico gerado: Esta secção permite ver a seguinte informação: Imagem 12 - Gráfico Período sazonal; Legenda com as várias variáveis de medida seleccionadas; Descrição do período temporal que foi configurado na secção de filtragem; Gráfico gerado (eixo YY Unidade de medida, eixo XX Granularidade Temporal) Tabela Geral A secção Tabela Geral permite visualizar a informação detalhada dos dados obtidos e representados no gráfico: Manual de Utilizador 7

262 Manual de Utilizador Imagem 13 - Tabela Geral A tabela apresenta os dados detalhados por data (granularidade definida na filtragem), o edifício, o grupo, o parâmetro (variável de medida), o valor (para cada ponto de dados no gráfico) e a unidade de medida da variável Tabela De Conclusões gráfico: A secção Tabela de Conclusões permite visualizar a informação estatística dos dados obtidos e representados no As informações apresentadas são: Imagem 14 - Tabela de Conclusões Máximo O valor de máximo e quando ocorreu; Mínimo O valor de mínimo e quando ocorreu; Média A medida usada mais frequentemente da tendência central de uma série de observações; Desvio padrão Isto é simplesmente a raiz quadrada da variância. Isto traz de volta a medida de variabilidade às unidades dos dados; Frequência Peso da amostra na população total; Moda o valor que surge com mais frequência se os dados são discretos, ou o intervalo de classe com maior frequência se os dados são contínuos; Mediana - Ordenados os elementos da amostra, a mediana é o valor (pertencente ou não à amostra) que a divide ao meio, isto é, 50% dos elementos da amostra são menores ou iguais à mediana e os outros 50% são maiores ou iguais à mediana; Variância - Variância mede o ponto no qual os valores observados diferem uns dos outros, isto é, a variabilidade ou a dispersão. Quanto maior a variabilidade, maior a incerteza na média; Erro padrão Esta medida é usada para estimar a precisão; Precisão - A precisão é a medida da extensão absoluta ou relativa dentro da qual se espera que o valor verdadeiro ocorra com algum intervalo de confiança específico; Total O somatório dos dados da mesma variável em análise Manual de Utilizador

263 Manual de Utilizador Esta secção apresenta ainda a informação dos consumos divididos por tipos de hora: Imagem 15 - Consumos por tipo de hora A informação mostra o tipo de hora, a data, o edifício/agência, o grupo, o parâmetro (variável de medida) e o valor correspondente ao consumo nesse período temporal Análise de Custos A secção Análise de Custos permite visualizar os custos correspondentes aos consumos registados nas variáveis de medida seleccionadas e respectivo período temporal escolhido. O gráfico (Imagem 16) apresenta a informação dos custos associados aos consumos para o período temporal escolhido. O detalhe temporal é correspondente à granularidade seleccionada na área de campos de filtragem. Imagem 16 - Gráfico de Custos A tabela de custos (Imagem 17) apresenta a informação detalhada dos custos associados aos consumos para o período temporal escolhido. A informação mostra o dia, o edifício/agência, o grupo, o tipo de dia da semana, o custo e consumo para a posição temporal correspondente. Imagem 17 - Tabela de Custos 3 Mensagens A secção de mensagens permite criar mensagens que são guardadas no sistema e que podem ser consumidas por outros aplicativos para as apresentar ao utilizador final. Quando o utilizador acede a esta secção visualiza um ecrã semelhante ao da imagem seguinte: Manual de Utilizador 9

264 Manual de Utilizador Imagem 18 - Secção de Mensagens Ao aceder a esta secção o utilizador pode ver uma lista das mensagens existentes no sistema. Para facilitar a pesquisa o utilizador pode filtrar as mensagens por agência/edifício, para isso basta seleccionar a agência/edifício pretendida da lista do campo Agência e clicar no botão Pesquisar. Para cada mensagem da listagem o utilizador pode apagar clicando em ou pode editar clicando em. Quando o utilizador tenta apagar uma mensagem é apresentada uma janela, como a seguinte, para o utilizador confirmar que quer apagar: Imagem 19 - Confirmar que pretende apagar mensagem Quando o utilizador clica em Editar ou em Nova Mensagem, aparece uma janela semelhante à seguinte: 10 Manual de Utilizador

265 Manual de Utilizador Imagem 20 - Janela de editar e criar mensagem Para criar uma mensagem é necessário o utilizador inserir a seguinte informação: Agência O utilizador deve seleccionar uma agência/edifício entre as que já existem no sistema; Severidade O nível de importância da mensagem. Existem no sistema três níveis: Alta, média e baixa; Título O título que é atribuído à mensagem; Corpo O conteúdo extenso da mensagem. Ao clicar em Guardar é guardada a mensagem no sistema, ou se não foi preenchido nenhum campo obrigatório é apresentada uma mensagem de aviso indicando qual o campo obrigatório em falta. 4 Simulação A secção de simulação permite simular os custos dos consumos de uma agência/edifício em determinado período de tempo para as várias tarifas configuradas no BackOffice. Ao aceder a esta secção é apresentada uma janela semelhante à seguinte: Manual de Utilizador 11

266 Manual de Utilizador Para fazer uma simulação o utilizador tem que: Imagem 21 - Janela de simulações 1. Seleccionar uma agência ou edifício (no máximo só pode seleccionar um item) apresentado na árvore de agências e edifícios - barra lateral esquerda; 2. Seleccionar o período temporal (Data Inicio e Data Fim) em que quer fazer a simulação; 3. Clicar no botão Submeter. Nota: Para a correcta apresentação de resultados os tarifários têm de estar devidamente configurados e atribuídos devidamente a cada agência no BackOffice. 4.1 Resultados Depois de clicar em Submeter o resultado apresentado da simulação terá um aspecto semelhante ao seguinte: 12 Manual de Utilizador

267 Manual de Utilizador Imagem 22 - Resultado de Simulação As linhas da tabela de resultados da simulação apresentam os custos dos tarifários e respectivas versões, combinados com os custos fixos associados a cada um dos tarifários. A informação apresentada em cada linha distribui-se por: Custos pelos Tipos de Hora; Custo de Potência Contratada; Custo de Potência em Horas de Ponta; Custo de Energia Reactiva Indutiva; Custo de Energia Reactiva Capacitiva; Custo Fixo; Custo Total: Soma dos valores das colunas prévias; Poupança: Apresenta a diferença entre o custo do tarifário actual da agência e o custo simulado do tarifário da linha. Um valor a verde significa que houve poupança e a vermelho significa que houve mais gasto. Na legenda aparece referenciado o tarifário activo (*) e por (#) os tarifários que não podem ser usados por não terem potência contratada suficiente para as necessidades da agência/edifício. Devem ser visualizadas estes tarifários nas linhas da tabela de resultados. Nota: Os tarifários devem estar previamente parametrizados no BackOffice, nomeadamente devem estar parametrizados os tipos de hora, os custos de energia activa pelos tipos de hora, os custos de energia reactiva e indutiva pelos tipos de hora, os custos da potência pelos tipos de hora, e os vários custos fixos associados ao tarifário. Dados. Caso o utilizador pretenda exportar os resultados da simulação para um ficheiro excel basta clicar no link Exportar 5 Relatórios A secção de relatórios permite gerar relatórios por agência ou edifício para fazer uma análise mais detalhado dos padrões de consumo. Ao aceder à zona de relatórios é apresentada uma janela semelhante à seguinte: Manual de Utilizador 13

268 Manual de Utilizador Imagem 23 - Janela de relatórios Para gerar um relatório o utilizador tem de: 1. Seleccionar uma agência ou edifício (no máximo só pode seleccionar um item) apresentado na árvore de agências e edifícios - barra lateral esquerda; 2. Seleccionar a data inicial (Data Início) e seguidamente um tipo de período (diário, semanal, mensal ou anual). Consoante o tipo escolhido automaticamente é encontrado o dia final (Data Fim). É esse período temporal que vai ser usado na geração do relatório; 3. Seleccionar a tipo de relatório: Completo Toda a informação é exibida: Secção de Energia Activa, Secção de Factor de Potência, Secção de Energia Reactiva, Secção de Análise de Potência, Secção de Indicadores de Estado, Secção de Indicadores de Poupança; Resumido Secção de Energia Activa, Secção de Energia Reactiva, Secção de Indicadores de Estado, Secção de Indicadores de Poupança. 4. Clicar no botão Submeter. O relatório gerado no formato PDF pode ser impresso ou guardado em disco. 5.1 Secção de Energia Activa É apresentado o gráfico e tabela de dados da variável de medida de energia activa associada à agência/edifício que foi seleccionada para a geração do relatório, para o período temporal escolhido. 14 Manual de Utilizador

269 Manual de Utilizador Os valores apresentados na tabela de dados incluem: Imagem 24 - Energia Activa Média; Desvio Padrão; Máximo; Mínimo. É apresentada uma tabela com os custos da energia activa por tipos de intervalo. Os dados correspondem a: Tipo do intervalo; Percentagem - de custo da energia, no tipo de intervalo, em relação ao total; Custo Especifico valor do custo para o tipo de intervalo; Total Média Máximo Mínimo Nota: É necessária a prévia configuração da variável de medida de energia activa no BackOffice assim como da correcta configuração do tarifário (tipos de hora e respectivos custos) associado à agência seleccionada para a geração do relatório. 5.2 Secção de Energia Reactiva É apresentado o gráfico e tabela de dados das variáveis de medida de energia reactiva (capacitiva, indutiva e total) associadas à agência/edifício, que foi seleccionada para a geração do relatório, para o período temporal escolhido. Manual de Utilizador 15

270 Manual de Utilizador Imagem 25 - Energia Reactiva Os valores apresentados na tabela por cada variável de medida de energia reactiva são: Média; Desvio Padrão; Máximo; Mínimo; Total; Frequência. É também apresentada a tabela de custos (por tipos de hora) das variáveis de medida de energia reactiva. Os dados correspondem a: Tipo do intervalo; Percentagem - de custo da energia, no tipo de intervalo, em relação ao total; Custo Específico valor do custo para o tipo de intervalo; Total; Média; Máximo; Mínimo. Nota: É necessária a prévia configuração das variáveis de medida de energia reactiva no BackOffice (criação de variáveis de medida secundárias com base em variáveis de medida primárias do tipo energia reactiva) assim como da correcta configuração do tarifário (tipos de hora e respectivos custos) associado à agência seleccionada para a geração do relatório. 5.3 Secção de Factor de Potência É apresentado o gráfico e tabela de dados da variável de medida de factor de potência associada à agência/edifício, que foi seleccionada para a geração do relatório, para o período temporal escolhido. 16 Manual de Utilizador

271 Manual de Utilizador Os valores apresentados na tabela de dados incluem: Imagem 26 - Factor de Potência Média; Moda; Máximo; Mínimo. Nota: É necessária a prévia configuração da variável de medida do factor de potência no BackOffice. 5.4 Secção de Análise de Potência É apresentado o gráfico e tabela de dados das potências tomadas, pelos vários tipos de hora e da potência contratada para a agência/edifício, que foi seleccionada para a geração do relatório, para o período temporal escolhido. Os valores apresentados na tabela de dados incluem: Imagem 27 - Análise de Potência Potência Tomada (Tipo de Hora): o o o o o Média; Desvio Padrão; Máximo; Mínimo; Total; o Frequência. Potência Contratada: Manual de Utilizador 17

272 Manual de Utilizador o o o o o o Média; Desvio Padrão; Máximo; Mínimo; Total; Frequência. É ainda apresentada a tabela de custos da potência contratada com o custo específico por mês em análise. 5.5 Secção de Indicadores de Estado É apresentada uma tabela de dados com os indicadores de estado, e respectivos valores, associados à agência/edifício, que foi seleccionada para a geração do relatório, para o período temporal escolhido. Imagem 28 - Indicadores de Estado A tabela apresenta uma listagem com o nome do indicador e o respectivo valor, para o período temporal escolhido. Nota: Para a apresentação da Secção de Indicadores de Estado estes indicadores devem ser previamente configurados no BackOffice para cada agência/edifício seleccionada. 5.6 Secção de Indicadores de Poupança É apresentada uma tabela de dados com os indicadores de poupança, e respectivos valores, associados à agência/edifício, que foi seleccionada para a geração do relatório, para o período temporal escolhido. 5.7 Poupança de Energia Activa É apresentado na tabela as diferenças entre os valores medidos e os valores expectáveis (valores da Baseline) para cada mês e pelos vários tipos de hora existentes no sistema. Imagem 29 - Poupança de Energia Activa Nota: Para a apresentação dos Indicadores de Poupança de Energia Activa, no BackOffice, deve ser configurada previamente a Baseline associada a cada agência/edifício. Esta configuração envolve caracterizar os consumos por mês e por tipo de hora. 5.8 Poupança de Dinheiro Os valores das poupanças de dinheiro resultam da multiplicação dos valores da tabela de poupança de consumos de energia activa, pelo custo (por tipo de hora) parametrizado para o tarifário do mês em análise. 18 Manual de Utilizador

273 Manual de Utilizador Imagem 30 - Poupança de Dinheiro Nota: Para a apresentação dos Indicadores de Poupança de Dinheiro, no BackOffice, deve ser configurada previamente a Baseline associada a cada agência/edifício além de ter-se de configurar correctamente os custos pelos tipos de hora do tarifário associado à agência para a qual se está a gerar o relatório. 5.9 Poupança de Emissões A tabela de dados de Poupança de Emissões resulta da multiplicação dos valores da tabela de poupança de consumos de energia activa, pelo factor de conversão configurado no BackOffice. Imagem 31 - Poupança de Emissões Nota: Para a apresentação dos Indicadores de Poupança de Emissões, no BackOffice, deve ser configurada previamente a Baseline associada a cada agência/edifício além de ter de se configurar correctamente o factor de conversão de energia por CO2, no BackOffice. 6 Operações de Back Office 6.1 Alertas No painel Alertas Disparados, o utilizador pode consultar os alertas disparados por unidade, tipo de alerta, nome, data e hora. Imagem 32 - Painel de Alertas Manual de Utilizador 19

274 Manual de Utilizador O painel oferece a possibilidade de filtrar os dados através de vários campos relativos ao Alerta: Tipo de Alerta, Novo, Alerta, Prioridade, Data, Unidade, Grupo e Tag. Imagem 33 - Alertas filtrados por Prioridade Miníma Neste painel, além do utilizador conseguir ver os detalhes dos alertas disparados, pode também verificar a data, se foi ou não enviado e se o alerta é novo ou recorrente. A coluna Prioridade apresenta, de forma visual, o Tipo de Prioridade do alerta disparado. 6.2 Tipos de Grupos e TAGs. Os Tipos de Grupos permitem ao utilizador estabelecer parâmetros partilhados entre várias Unidades, Dispositivos Listar A imagem seguinte apresenta o ecrã de listagem de Tipos de Grupos onde o utilizador pode Adicionar um Tipo de Grupo, pesquisar pelos tipos existentes, consultar e editar os detalhes de um tipo e até remove-lo Detalhes Imagem 34 - Listagem de Tipos de Grupos Ao clicar sobre o nome de um Tipo de Grupo da listagem, o utilizador é redireccionado para a página de detalhes do registo escolhido. 20 Manual de Utilizador

275 Manual de Utilizador Imagem 35 - Ecrã de detalhes do Tipo de Grupo Na zona superior é possível encontrar ainda as seguintes acções: Listar Esta acção remete o utilizador para a listagem de Tipos de Grupo Editar Esta acção dá acesso aos detalhes do Tipo de Grupo em modo de edição Editar A imagem que se segue apresenta o ecrã de edição de um Tipos de Grupo. Imagem 36 - Edição de um Tipo de Grupo O formulário de edição permite ao utilizador alterar os seguintes campos: Nome O nome que identifica o Tipo de Grupo; Colunas São os parâmetros que serão partilhados entre todos os Grupos deste tipo. Podem ser adicionados ou removidos na quantidade desejada. Se o utilizador desejar regressar à listagem de Tipos de Grupos basta escolher a acção Voltar. Se pelo contrário desejar efectivar as alterações efectuadas deve escolher a acção Guardar. Após enviar os dados à Base de Dados, a aplicação redirecciona o utilizador para a listagem inicial de Tipos de Grupos. Manual de Utilizador 21

276 Manual de Utilizador Adicionar Tipo de Grupo A próxima imagem apresenta o ecrã de adição de Tipo de Grupo. seguir: Imagem 37 - Adicionar Tipo de Grupo O formulário de adição de Tipo de Grupo permite ao utilizador definir algumas propriedades como as descritas a Nome O nome que identifica o Tipo de Grupo; Colunas São os parâmetros que serão partilhados entre todos os Grupos deste tipo. Podem ser adicionados ou removidos na quantidade desejada. Se o utilizador desejar regressar à listagem de Tipo de Grupo basta escolher a acção Voltar. Se pelo contrário desejar adicionar o Tipo de Grupo deve escolher a acção Guardar. Após enviar os dados à Base de Dados, a aplicação redirecciona o utilizador para a listagem inicial de Tipos de Grupo. 6.3 Grupos A página de Grupos permite ao utilizador criar Grupos para adicionar Unidades, Dispositivos ou TAGs. Os Grupos podem servir para definir permissões sobre todos os membros do Grupo ou visualizar consumos e TAGs Virtuais associadas ao Grupo Listar Ao aceder a esta página o utilizador tem acesso à listagem de registos tal como na imagem seguinte. 22 Manual de Utilizador

277 Manual de Utilizador Detalhes Imagem 38 - Listagem de Grupos Para aceder aos detalhes de um Grupo basta clicar sobre o nome do mesmo na listagem de registos. De seguida o utilizador é redireccionado para um ecrã semelhante ao seguinte. Imagem 39 - Detalhes de um Grupo No canto superior direito dos detalhes do Grupo, o utilizador tem as seguintes acções disponíveis: Listar Esta acção permite voltar à listagem de Grupos inicial Virtual Tags Esta acção disponibiliza a lista de Tags Virtuais associadas a este Grupo Indicadores Esta acção disponibiliza a lista de Indicadores associadas a este Grupo. Manual de Utilizador 23

278 Manual de Utilizador Alertas Esta acção disponibiliza a lista de Alertas associados a este Grupo Alertas Disparados Esta acção disponibiliza a lista de Alertas Disparados associadas a este Grupo Adicionar Grupo Ao escolher a opção Adicionar Grupo, o ecrã de seguinte é apresentado. Imagem 40 - Criar um novo Grupo No ecrã acima apresentado, o utilizador pode definir o nome do Grupo, atribuir-lhe uma Descrição e associar-lhe um Tipo de Grupo. Pode ainda definir se será um Grupo principal ou subgrupo. Para adicionar definitivamente o Grupo basta escolher a acção Guardar. Após guardar os dados o utilizador é redireccionado para a página de detalhes do Grupo recém-criado. Neste novo ecrã o utilizador pode verificar todas as configurações inerentes ao Grupo que foram automaticamente associadas. Entre elas estão por exemplo os utilizadores do Grupo e o equipamento do Grupo. Sob o nome do novo Grupo existem inúmeras acções disponíveis. Se o utilizador clicar com o botão direito do rato sobre o nome do Grupo, vai encontrar um conjunto de acções como se apresenta de seguida. Imagem 41 - Acções sobre o Grupo 24 Manual de Utilizador

279 Manual de Utilizador Criar TAG Virtual Esta opção disponibiliza ao utilizador o ecrã de criação da TAG Virtual como se demonstra a seguir. Imagem 42 - Criar um TAG Virtual Neste painel o utilizador pode definir a seguinte informação: Nome da tag Nome que quer atribuir à virtual tag; Tipo de tag Tipo de tag que estará associado à virtual tag; Tipo de Medida - Tipo de unidade de medida que deve estar associado à tag; Campo Neste campo pode ser definido se a virtual tag recebe valores de consumo (Consumo) ou valores instantâneos (Valor Absoluto); Fórmula Local onde se constrói a fórmula que define os valores da virtual tag e que contém as opções: o Limpar Tudo limpa todos os dados da fórmula; o o Limpa últimos limpa o último dado da fórmula; Operações: (+ soma), (- subtracção), (* multiplicação), (/ divisão) que podem ser feitas sobre as tags e são acrescentadas ao campo Fórmula; Pesquisa de tags Permite pesquisar as tags que podem ser adicionadas ao campo Fórmula. Estas tags são todas as tags que estejam no grupo ou nos seus sub-grupos; Acrescento de tags acessíveis do tipo O utilizador selecciona na caixa de selecção a sua escolha e ao carregar no botão da operação que pretende automaticamente á adicionada à fórmula todas as tags acessíveis do tipo escolhido (isto é, tags do grupo e sub-grupos) com a respectiva operação. Acrescento de Todos os grupos de tags do tipo O utilizador selecciona na caixa de selecção a sua escolha e ao carregar no botão da operação que pretende automaticamente á adicionada à fórmula todas as tags do grupo e do tipo escolhido (isto é, tags do grupo) com a respectiva operação. Ao clicar no botão Guardar é criada uma nova virtual tag, no botão Re-iniciar o formulário e limpo Criar Indicador Esta opção disponibiliza ao utilizador o ecrã de criação da Indicador como se demonstra a seguir. Manual de Utilizador 25

280 Manual de Utilizador Imagem 43 - Criar Indicador Neste painel o utilizador pode definir a seguinte informação: Nome Nome que quer dar ao Indicador; Pesquisa de tags Permite pesquisar as tags que podem ser associadas ao Indicador. Estas tags são todas as tags que estejam no grupo ou nos seus sub-grupos; Fórmula Local onde se constrói a fórmula que define os valores da virtual tag e que contém as opções: o o o Limpar Tudo limpa todos os dados da fórmula; Limpa últimos limpa o último dado da fórmula; Operações: (+ soma), (- subtracção), (* multiplicação), (/ divisão) que podem ser feitas sobre as tags e são acrescentadas ao campo Fórmula; Calcular indicador Valor sobre o qual será calculado o indicador que pode ser uma constante (valor numérico) ou um detalhe de grupo (ver cap ). Ao clicar no botão Guardar é criado um novo indicador, no botão Re-iniciar o formulário e limpo Criar Sub-Grupo Esta acção permite ao utilizador criar um novo Grupo que automaticamente ficará em hierarquia com o Grupo em edição. Ao escolher esta opção a seguinte janela surge. Imagem 44 - Criar subgrupo O utilizador deve preencher os campos obrigatórios como Nome e Descrição. Premir o botão OK para guardar os dados. A aplicação reage actualizando a árvore de Grupo com o mais novo grupo criado sob o Grupo principal. Se for 26 Manual de Utilizador

281 Manual de Utilizador activa a opção principal o grupo passa a ser considerado como grupo principal e tem obrigatoriamente que ter um sub-grupo geral Adicionar Utilizador Para adicionar um utilizador este deve já existir no sistema. Assim, após escolher a opção Adicionar Utilizador uma janela, semelhante à que se apresenta de seguida, surge. O utilizador escreve o nome e a aplicação vai apresentando os registos que validem os dados inseridos. Imagem 45 - Adicionar utilizador Apenas se pode indicar um utilizador de cada vez, pelo que após escolher o desejado deve premir OK e o registo é de imediato visível nos detalhes do Grupo Adicionar Unidade Para adicionar uma Unidade o processo é semelhante ao anteriormente descrito para utilizadores. Uma janela semelhante surge, onde o utilizador insere o Identificador ou o Nome ou Local da Unidade. Após o sistema encontrar o registo, o utilizador confirma clicando no OK e a aplicação redirecciona para a página de detalhes do Grupo onde já se encontra a nova Unidade disponível Adicionar Dispositivo Para adicionar um Dispositivo o processo é semelhante ao anteriormente descrito para Unidades. Uma janela semelhante surge, onde o utilizador insere o Nome ou Local do Dispositivos. Após o sistema encontrar o registo, o utilizador confirma clicando no OK e a aplicação redirecciona para a página de detalhes do Grupo onde já se encontra o novo Dispositivos disponível Adicionar Tag Para adicionar uma TAG o processo é semelhante ao anteriormente descrito para Dispositivos. Uma janela semelhante surge, onde o utilizador insere o Nome ou Local da TAG. Após o sistema encontrar o registo, o utilizador confirma clicando no OK e a aplicação redirecciona para a página de detalhes do Grupo onde já se encontra a nova TAG disponível Editar Grupo Esta acção também escolhida a partir da listagem na página inicial de Grupos. Após escolher a opção editar Grupo, os detalhes do Grupo ficam disponíveis em modo de edição, sendo possível alterar alguns detalhes como se exemplifica na imagem seguinte. Manual de Utilizador 27

282 Manual de Utilizador Imagem 46 - Editar Grupo Ligar Grupo Esta opção permite ao utilizador adicionar um Grupo existente como um subgrupo. Ou seja, um Grupo pode estar ligado a muitos outros sem a sua estrutura ter de ser replicada. Este mecanismo é feito da mesmo forma que a adição de Utilizadores, Unidade, Dispositivos e TAGs Adicionar Baseline O grupo não possuindo nenhuma Baseline associada ao utilizador é lhe apresentada a opção de criar uma nova Baseline Ano 0: Imagem 47 - Baseline Ano 0 Ao carregar no botão é-lhe apresentado a janela de introdução de dados duma nova Baseline do Ano 0. O utilizador deve preencher todos os campos relevantes: Data Ano da Baseline Ano 0; Consumos divididos por Tipos de Hora (Horas de Ponta, Cheia, Vazio, Vazio Normal, SuperVazio), para cada mês do Ano 0; Avac - Sistema Avac associado ao grupo: o o o Potência Nominal (kw) potência do AVAC em Kw Hora Inicio - Hora em que o AVAC entrou em funcionamento Hora Fim Hora em que o AVAC finalizou o funcionamento Equipamentos Lista de Equipamentos que entraram em funcionamento, associados ao grupo: o Nome Nome do Equipamento o o o Potência Nominal (Kw) Potência do Equipamento em Kw Inicio - Hora em que o Equipamento entrou em funcionamento Fim Hora em que o Equipamento finalizou o funcionamento 28 Manual de Utilizador

283 Manual de Utilizador Imagem 48 - Adição de Baseline do Ano 0 No final o utilizador ao clicar em Ok é guardada a Baseline no sistema, se carregar em Cancel é descartada a informação que foi introduzida no formulário da Baseline. Ao guardar a Baseline ao utilizador é apresentada a Baseline na listagem de Baselines do Grupo, como demonstrado na imagem seguinte. Imagem 49 - Listagem de Baselines Actualizar Baseline Depois de criada a Baseline do Ano 0 só pode ser actualizada essa Baseline com dados para os meses do Ano 1 (automaticamente definido como o ano posterior ao Ano 0). Clicando no botão do registo da Baseline do ano 0 é-lhe apresentada a janela de actualização. Manual de Utilizador 29

284 Manual de Utilizador Imagem 50 - Actualização de Baseline Nesta janela o utilizador pode escolher o mês da actualização, no campo Data. Automaticamente é restringido o mês começando no mês de início do ano ou o mês posterior ao último mês de actualização da Baseline do Ano 1. O utilizador pode preencher de seguida os campos com as alterações de consumos que aconteceram desde o mês do ano 0 para o mês do ano 1, nomeadamente: AVAC Sistema Avac associado ao grupo: o o o Potência Nominal (kw) potência do AVAC em Kw; Hora Inicio - Hora em que o AVAC entrou em funcionamento; Hora Fim Hora em que o AVAC finalizou o funcionamento. Equipamentos Lista de Equipamentos que entraram em funcionamento, associados ao grupo: o Nome Nome do Equipamento; o o o Potencia Nominal (Kw) Potência do Equipamento em KW; Inicio - Hora em que o Equipamento entrou em funcionamento; Fim Hora em que o Equipamento finalizou o funcionamento. No final o utilizador ao clicar em Ok é guardada a actualização da Baseline no sistema, e se carregar em Cancel é descartada a informação que foi introduzida no formulário. De notar que depois de criadas as actualizações de consumos do AVAC e Equipamentos da Baseline do Ano 1, existe um serviço que actualizará os consumos globais para os respectivos meses do ano 1. Clicando no botão de edição sobre uma das Baselines do ano 1 é apresentado uma janela que apresentará os valores actualizados sobre os consumos globais dos meses da Baseline do ano 1 (depois de ter sido executado o serviço de actualização das Baselines). 30 Manual de Utilizador

285 Manual de Utilizador Imagem 51 - Edição de Baseline Ano Adicionar Detalhe Esta opção faz aparecer uma nova janela, semelhante à seguinte, onde o utilizador pode preencher os campos Nome e Valor. Estes dados funcionam como um Parâmetro do Grupo. Imagem 52 - Adicionar Detalhe Após o preenchimento dos campos pode premir OK. A aplicação guarda os dados e redirecciona o utilizador para a página de detalhes do Grupo, com a separa dor Detalhes do Grupo em foco onde se pode visualizar o recém-criado Detalhes. A imagem seguinte exemplifica o resultado Final. Imagem 53 - Visualizar Detalhes do Grupo Separar Grupo Esta opção permite ao utilizador exterminar a ligação entre Grupos. Ao escolher esta acção num determinado Grupo, a ligação ao outro será eliminada. Se por um lado a ligação pode ser removida por outro lado os Grupos não Manual de Utilizador 31

286 Manual de Utilizador podem deixar de pertencer a uma hierarquia. Assim, se o Grupo não possuir nenhuma outra ligação, a separação não pode ser efectuada Apagar Grupo Se o utilizador deseja remover um Grupo do sistema então deve escolher esta opção. Note-se que apenas Grupos simples (sem subgrupos ou ligações a outros Grupos) podem ser apagados. Em alternativa a esta acção, o utilizador pode escolher a opção presente na página inicial de Grupos Alertas Para realizar a gestão dos alertas o utilizador deve clicar no link Plugin de Alertas no menu da aplicação Listagem A listagem apresenta os campos referentes a cada Alerta: Nome, Algoritmo, Tipo de Tag (ao qual se aplica a validação), Tag (à qual se aplica a validação), Activo (se a Validação está activa ou não). Este painel Imagem 54 ainda oferece a possibilidade de pesquisar por alertas específicos pelo seu nome. Imagem 54 - Listagem de Alarmes Adicionar Alerta Se o utilizador desejar adicionar um novo alerta ele pode fazê-lo premindo o botão Adicionar Alerta Edição O utilizador pode desactivar ou activar o alerta seleccionando ou não o campo Activo. Depois de alterar as informações do painel de edição Imagem 55 o utilizador pode simplesmente pressionar o botão Guardar, a fim de confirmar as alterações na base de dados. Pressionando o botão Voltar o utilizador voltará para a página anterior. 32 Manual de Utilizador

287 Manual de Utilizador Imagem 55 - Edição de Alerta Adição No painel de adição Imagem 56 de validação o utilizador tem de introduzir o nome do alerta. De seguida deve escolher o tipo de alerta que deseja criar: Sistema alerta avaliado sobre todo o sistema; Grupo alerta avaliado sobre todas as tags desse grupo; Unidade alerta avaliado sobre a unidade; Tag alerta avaliado sobre uma tag específica. A seguir deve introduzir no campo Id o identificador respectivo de grupo, tag ou unidade conforme a escolha anterior. O campo Data de Inicio será o tempo em que o alerta ficará activo e o campo Parar o tempo será o tempo em que alerta ficará desactivo. Seguidamente o utilizador terá de escolher um plugin do tipo alerta na caixa de selecção Plugin. Conforme os parâmetros codificados em cada plugin eles irão aparecer no painel para serem preenchidos os respectivos valores. O utilizador ao carregar em Guardar é criado o alerta. Imagem 56 - Adição de Alerta Manual de Utilizador 33

288 Manual de Utilizador 6.4 Facturação Fornecedores Listar Depois de clicar no link de administração o painel da Imagem 57 é mostrado. Imagem 57 - Painel de Fornecedores Nesta secção o utilizador pode ver a lista de fornecedores existentes, procurar por um fornecedor específico e fazer as operações de gestão usuais. Na pesquisa o utilizador tem duas possibilidades de pesquisa: pesquisa por nome ou por tipo. No primeiro caso o utilizador pode escrever uma palavra que identifique o fornecedor. No segundo caso o utilizador necessita simplesmente de mudar o tipo de procura e depois escolher o tipo da lista de tipos fornecida. No grupo de fornecedores está disponível uma opção que permite ver os fornecedores que foram removidos do sistema. Se o utilizador desejar ver os fornecedores anteriores deve activar esta opção e depois fazer a pesquisa. A Imagem 58 mostra um exemplo da pesquisa filtrada por tipo gás com a opção Mostrar fornecedores eliminados activada. Imagem 58 - Lista de Fornecedores 34 Manual de Utilizador

289 Manual de Utilizador Apagar fornecedores ( ) Na lista de fornecedores o utilizador pode clicar no ícone de apagar para remover um fornecedor Editar fornecedores ( ) Na lista de fornecedores o utilizador pode clicar no ícone de editar para ter acesso ao painel de edição do fornecedor Adicionar Fornecedor Este botão dá acesso ao formulário de adicionar fornecedor Detalhes No painel de listagem o utilizador pode aceder aos detalhes de um fornecedor específico, clicando no nome do fornecedor. Esta acção vai mostrar o painel da Imagem 599. Imagem 59 - Detalhes do Fornecedor No painel de detalhes o utilizador pode ver todos os tarifários associados a um fornecedor específico. Como no caso da listagem de fornecedores o utilizador pode também seleccionar a opção Mostrar tarifas eliminadas para ver as tarifas apagadas. Na secção esquerda o utilizador tem três botões que dão acesso a acções diferentes: Editar Este botão dá acesso ao formulário de edição de tarifários. Adicionar tarifa Este botão dá acesso ao formulário de adição de tarifa. Manual de Utilizador 35

290 Manual de Utilizador Listagem Este botão dá acesso a lista de fornecedores Editar Para editar um fornecedor já existente o utilizador deve carregar no botão de edição. O processo de edição e parecido com processo de adição explicado em baixo. De acordo com isso, e para evitar repetições, vamos explicar o painel envolvido nestes processo na próxima secção Adicionar Para adicionar um novo fornecedor o utilizador deve usar o botão Adicionar fornecedor, que depois de clicado, da acesso ao painel mostrado na Imagem 600 Imagem 60 - Adição de Fornecedor Neste painel o utilizador precisa simplesmente de preencher o nome e tipo de fornecedor e moeda em qual o fornecedor trabalha. Se o utilizador desejar cancelar a operação pode clicar no botão de retroceder. Clicando no botão guardar a informação do fornecedor será guardada na base de dados e direcciona o utilizador para o painel de detalhes que permite ao utilizador adicionar tarifas e códigos postais a um fornecedor ou mudar a informação inserida Tarifas Listar Depois de clicar no link de administração o painel da Imagem 61 é mostrado. 36 Manual de Utilizador

291 Manual de Utilizador Imagem 61 - Listagem de Tarifas Adicionar Tarifa Tipo Intervalo Para adicionar uma tarifa o utilizador tem de, no painel de Detalhe de um fornecedor, clicar no botão Adicionar Tarifa que ira redireccionar para o painel na Imagem 62. Imagem 62 - Adição de Tarifa Neste painel o utilizador pode definir a seguinte informação: Nome nome da tarifa; Período de facturação período de facturação associado com a tarifa; Data de início da tarifa Data em que a tarifa começa; Tipo de Temporada Associação da tarifa as estações da secção de estações; Publico Se a tarifa tem visibilidade publica ao não; Tipo Tipo de tarifa (escalões ou intervalos); Depois de adicionar a informação o utilizador será redireccionado para o painel mostrado na Imagem 63. Manual de Utilizador 37

292 Manual de Utilizador Imagem 63 - Detalhe de Tarifa Nota que o sistema indica que não foram encontrados períodos nem escalões nem parâmetros nem factores de multiplicação, para adicionar qualquer uma destas entidades o utilizador pode clicar no Adicionar Período, Adicionar Passo ou Adicionar Custos Fixos, Adicionar Parâmetro respectivamente. Quando o utilizador clica no botão de adicionar período o painel da Imagem 64 é mostrado ao utilizador. Imagem 64 - Adição de Período Como é visível no painel de adição de intervalos o utilizador terá de preencher a seguinte informação: Inicio Hora de início do intervalo. Fim Hora de fim do intervalo. Temporada Um inteiro que indica a estação em que o intervalo é aplicado. As estações são definidas em separado. Por agora, a estação 0 é o verão e a estação 1 é o inverno. 38 Manual de Utilizador

293 Manual de Utilizador Tipo de hora Tipo de hora a que o intervalo pertence. Preço Valor numérico que indica o preço. Dias da semana Dias da semana em que o intervalo é aplicado. Depois de preenchida a informação requerida o utilizador pode clicar em guardar e guardar o intervalo na base de dados. Esta acção vai então redireccionar o utilizador para os detalhes da tarifa Imagem 65. Imagem 65 - Listagem de Períodos por Tipo de Hora Note de que depois de inserir a informação dos intervalos a mensagem de aviso anterior desaparece. Para adicionar um custo fixo o processo é semelhante. O utilizador clica no botão Adicionar custo fixo o que lhe vai mostrar o painel na Imagem 66. Imagem 66 - Adição de Custo Fixo Como é visível no painel de adição de custos fixos o utilizador terá de preencher a seguinte informação: Descrição Descrição do custo fixo; Preço Valor numérico que indica o preço; Potência contractada Potência que esta associada ao custo fixo; Depois de preenchida a informação requerida o utilizador pode clicar em guardar e guardar o custo fixo na base de dados. Esta acção vai então redireccionar o utilizador para os detalhes da tarifa Imagem 67. Imagem 67 - Listagem de Custo Fixo Para adicionar um parâmetro ao tarifário o processo é semelhante. O utilizador clica no botão Adicionar parâmetro o que lhe vai mostrar o painel na Imagem 68. Manual de Utilizador 39

294 Manual de Utilizador Imagem 68 - Adição de Parâmetro Como é visível no painel de adição de parâmetros o utilizador terá de preencher a seguinte informação: Nome Nome do parâmetro tarifário; Período de cálculo De quanto em quanto tempo o parâmetro deve ser calculado; Parâmetro Parâmetro que vai ser associado ao tarifário; Tipos de horas Tipos de hora em que o parâmetro vai ser avaliado; Preço Preço associado ao parâmetro; Depois de preenchida a informação requerida o utilizador pode clicar em guardar e guardar o parâmetro na base de dados. Esta acção vai então redireccionar o utilizador para os detalhes da tarifa Imagem 69. Imagem 69 - Listagem de Parâmetros Nos parâmetros do tarifário para além das opções de edição, apagar existe ainda uma opção associada ao parâmetro de energia reactiva indutiva, que permite adicionar novos factores de multiplicação. O utilizador clica no botão de adição de factor de multiplicação ( mostra a Imagem 70. ) sendo mostrado a formulário de factores de multiplicação como 40 Manual de Utilizador

295 Manual de Utilizador Imagem 70 - Factor de Multiplicação Como é visível no painel de adição de factores de multiplicação o utilizador terá de preencher a seguinte informação: Descrição Descrição do factor de multiplicação; Máximo Valor máximo do factor; Mínimo Valor mínimo do factor; Factor de multiplicação Factor de multiplicação atribuído. Depois de preenchida a informação requerida o utilizador pode clicar em guardar e o factor de multiplicação é adicionado na base de dados. Esta acção vai então redireccionar o utilizador para os detalhes da tarifa Imagem 711. Imagem 71 - Listagem de Factor de Multiplicação Adicionar Tarifa De Tipo Escalão Para adicionar uma tarifa por escalões basta seleccionar o tipo escalão no painel de adição de tarifas já descrito anteriormente. Quando se selecciona esta opção aparece mais uma opção como se pode ver na Imagem 72 o tipo de escalão que pode ser singular ou múltiplo. Manual de Utilizador 41

296 Manual de Utilizador Imagem 72 - Adição de Tarifa de Tipo Escalão Depois de adicionada a tarifa de escalão é mostrado um painel em tudo parecido com o painel de tarifas por intervalos como mostra a Imagem 73. escalão. Imagem 73 - Detalhe de Tarifa de Tipo Escalão Nas tarifas por escalões existem as opções já referidas anteriormente e ainda a opção para adição de um novo 42 Manual de Utilizador

297 Manual de Utilizador Imagem 74 - Adicionar Escalão Adicionar novo escalão requer que o utilizador preencha o campo de mínimo, máximo com uma identificação numérica e indicar o custo do novo escalão. Depois de preencher os dois campos o utilizador pode pressionar guardar o que vai guardar a informação na base de dados e redirecciona para o painel de detalhes de tarifa da Imagem 75. Note que os avisos sobre os escalões desapareceram. Imagem 75 - Detalhe de Tarifa por Escalão Editar No painel de detalhes de tarifa o utilizador pode usar o botão de editar para mudar as configurações de qualquer parâmetro do tarifário e pode usar o botão de apagar para remover qualquer parâmetro. Se o utilizador desejar modificar outros detalhes sobre o tarifário pode usar o botão de editar que vai abrir o painel de edição de tarifa como é mostrado na Imagem 76. Manual de Utilizador 43

298 Manual de Utilizador Imagem 76 - Edição de Tarifa Neste ponto acabamos a adição de informação sobre uma tarifa específica do fornecedor, mais tarifas podem ser adicionas seguindo os passos anteriores. Outra informação importante que pode ser adicionada ao fornecedor é o código postal onde estes oferecem os seus serviços. No painel de detalhes de fornecedor na imagem 66 existe uma secção que permite o utilizador adicionar, remover e procurar por códigos postais que foram associados aos fornecedores. Para adicionar um código postal o utilizado precisa simplesmente de especificar o número do código postal e clicar no botão de adicionar. Note que o código postal tem dois números separados por traço, o primeiro número contém sempre 4 dígitos e o segundo contém sempre 3 dígitos (ex ). O primeiro número identifica um país específico e o segundo identifica uma rua no país. O interface permite ao utilizador adicionar apenas o código do país o que significa que o sistema vai associar todos os códigos postais do país, aquele fornecedor. Na Imagem 77 o utilizador esta adicionar o país identificado por 3000 no sistema. Imagem 77 - Códigos Postais Depois de pressionado no botão para adicionar o utilizador terá a opção de confirmar o seu pedido. Neste ponto o utilizador pode procurar na base de dados pelo código postal associado ao fornecedor. A Imagem 78 mostra o resultado da pesquisa por códigos postais começados por Imagem 78 - Pesquisa por código postal 44 Manual de Utilizador

299 Manual de Utilizador Se o utilizador desejar apagar um código postal específico ou todos os códigos postais apenas tem de preencher a caixa de texto de apagar e pressionar o botão de apagar. Outra opção para apagar um código postal específico é usar o botão de apagar na lista de códigos postais. 6.5 Estações Listar Depois de clicar no link de estações o painel da Imagem 79 é mostrado. Imagem 79 - Listagem de Estações Nesta secção o utilizador pode ver a lista de estações existentes, procurar por uma estação específica e fazer as operações de gestão usuais. Na pesquisa o utilizador tem a possibilidade de pesquisar por nome. O utilizador pode escrever uma palavra que identifique as estações e os resultados serão filtrados por essa palavra Apagar Estação ( ) Na lista de estações o utilizador pode clicar no ícone de apagar para remover uma estação Editar Estação ( ) Na lista de estações o utilizador pode clicar no ícone de editar para ter acesso ao painel de edição das estações Adicionar Estação Este botão dá acesso ao formulário de adição de estação Detalhes No painel de listagem o utilizador pode aceder aos detalhes de uma estação específica, clicando no nome da estação. Esta acção vai mostrar o painel da Imagem 80. Manual de Utilizador 45

300 Manual de Utilizador Imagem 80 - Detalhe de Estação No painel de detalhes, o utilizador pode ver todas as temporadas associados a uma estação específica. Na secção esquerda o utilizador tem três botões que dão acesso a acções diferentes: Editar Este botão dá acesso ao formulário de edição de estação Adicionar Temporada Este botão dá acesso ao formulário de adição de uma temporada à estação. Imagem 81 - Adição de Temporada No painel de adição de temporada é possível adicionar uma temporada a uma estação, uma temporada não é mais do que um período de tempo em que a estação está associada. Sendo que o início é a data em que a estação se inicia e a ordem por ano é uma valor inteiro que se refere a estação, existindo duas estações o valor 1 seria o verão e o 2 o inverno Listagem Este botão dá acesso à listagem de estações Editar Para editar uma estação já existente o utilizador deve carregar no botão de edição. O processo de edição e parecido com processo de adição explicado em baixo. De acordo com isso, e para evitar repetições, vamos explicar o painel envolvido nestes processo na próxima secção. 46 Manual de Utilizador

301 Manual de Utilizador Adicionar Para adicionar uma nova estação o utilizador deve usar o botão Adicionar Estação, que depois de clicado, dá acesso ao painel mostrado na Imagem 82 Imagem 82 - Adição de Estação Neste painel o utilizador precisa simplesmente de preencher o tipo e o número de temporadas por ano de uma estação. Se o utilizador desejar cancelar a operação pode clicar no botão de listar para regressar a listagem de estações. Clicando no botão Guardar a informação da estação será guarda na base de dados e direcciona o utilizador para o painel de detalhes da estação que permite ao utilizador adicionar temporadas a uma estação, sendo que cada estação deve ter sempre uma pelo menos uma temporada. 7 Plugins Alertas 7.1 Listagem Esta secção permite a gestão de todas as Dlls que vão servir de suporte aos validadores e alertas. A listagem apresenta os campos referentes a cada Plugin: Nome, Peso, Tipo, Nome da Classe (Dll), Utilizações (número de vezes que o plugin foi usado em validações\alertas). Este painel Imagem 83 ainda oferece a possibilidade de pesquisar por plugins específicos pelo seu nome. Imagem 83 - Listagem de Plugins Manual de Utilizador 47