ienergy - eficiência energética em edifícios

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íciosPedro Rafael Pimenta Saraiva

[email protected]

Orientador da ISA

Eng.º. Ricardo Clérigo

[email protected]

Orientador do ISEC

Doutor Viriato António Pereira Marinho Marques

[email protected]

mailto:[email protected]



iEnergy – Eficiência Energética em Edifícios Resumo

Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011 i

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 2011.

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.

iEnergy – Eficiência Energética em Edifícios Abstract

Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011 iii

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, 2011. 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.

iEnergy – Eficiência Energética em Edifícios Palavras-Chave

Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011 v

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

iEnergy – Eficiência Energética em Edifícios Símbolos e Abreviaturas

Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011 vii

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

Símbolos e Abreviaturas iEnergy – Eficiência Energética em Edifícios

viii Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

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

iEnergy – Eficiência Energética em Edifícios Agradecimentos

Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011 ix

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!

iEnergy – Eficiência Energética em Edifícios Índice

Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011 xi

Índice

1 INTRODUÇÃO ...................................................................................................................................... 1

1.1 ÂMBITO ............................................................................................................................................... 1

1.2 APRESENTAÇÃO DA EMPRESA ................................................................................................................... 3

1.3 OBJECTIVOS DO ESTÁGIO ......................................................................................................................... 3

1.4 CONTRIBUIÇÕES ..................................................................................................................................... 5

1.5 ORGANIZAÇÃO E TEMAS ABORDADOS NO PRESENTE RELATÓRIO ..................................................................... 5

2 ANÁLISE DO PROBLEMA ...................................................................................................................... 7

2.1 CONCEITOS FUNDAMENTAIS..................................................................................................................... 7

2.2 PLATAFORMA IENERGY ............................................................................................................................ 7

2.2.1 Principais Entidades do Sistema .............................................................................................. 8

2.2.2 Descrição Geral do Projecto de Estágio ................................................................................... 9

3 PLANO DE TRABALHOS DO ESTÁGIO .................................................................................................. 13

3.1 METODOLOGIA DE DESENVOLVIMENTO .................................................................................................... 13

3.1.1 Descrição do Scrum ............................................................................................................... 14

3.2 APLICAÇÃO DO SCRUM NO PROJECTO DE ESTÁGIO ...................................................................................... 15

3.2.1 Fases do Scrum ...................................................................................................................... 15

3.3 OPINIÃO PESSOAL ................................................................................................................................ 20

4 FASE DE INTEGRAÇÃO ........................................................................................................................ 21

4.1 EFICIÊNCIA ENERGÉTICA EM EMBARCAÇÕES .............................................................................................. 21

4.2 ANÁLISE DE REQUISITOS ........................................................................................................................ 22

4.3 REQUISITOS FUNCIONAIS ....................................................................................................................... 22

4.3.1 Definições Chave .................................................................................................................... 22

4.3.2 Módulo Associação de Mestres a Viagem ............................................................................. 23

4.3.3 Módulo Relatórios ................................................................................................................. 23

4.3.4 Módulo de Integração com Bilhética para Criação de Viagens ............................................. 28

4.3.5 Módulo de Criação de Alertas ............................................................................................... 28

4.3.6 Módulo de Validação de Viagens .......................................................................................... 29

4.4 IMPLEMENTAÇÃO ................................................................................................................................. 29

4.4.1 Ferramentas de Desenvolvimento ......................................................................................... 29

4.5 VERIFICAÇÃO E VALIDAÇÃO .................................................................................................................... 30

4.6 RESULTADOS OBTIDOS NESTA FASE ......................................................................................................... 30

5 REVISÃO TECNOLÓGICA ..................................................................................................................... 31

5.1 ESTADO DA ARTE ................................................................................................................................. 31

5.1.1 Soluções Existentes ou Semelhantes ..................................................................................... 31

5.1.2 Resumo Crítico ....................................................................................................................... 33

5.2 TECNOLOGIAS CONSIDERADAS ................................................................................................................ 34

5.2.1 Análise de Tecnologias da Concorrência ............................................................................... 34

5.2.2 Análise de Tecnologias para o Sistema.................................................................................. 35

5.2.3 Ferramentas de Construção de Relatórios............................................................................. 37

5.2.4 Ferramentas Web de Gráficos ............................................................................................... 38

Índice iEnergy – Eficiência Energética em Edifícios

xii Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

6 ESPECIFICAÇÃO .................................................................................................................................. 41

6.1 VISÃO GERAL ...................................................................................................................................... 41

6.2 CARACTERÍSTICAS DOS UTILIZADORES....................................................................................................... 42

6.3 ANÁLISE DE REQUISITOS ........................................................................................................................ 43

6.3.1 Metodologia Usada na Recolha de Requisitos ...................................................................... 43

6.4 REQUISITOS FUNCIONAIS ....................................................................................................................... 44

6.4.1 Módulo de Grupos Lógicos .................................................................................................... 46

6.4.2 Módulo de Análise de Dados ................................................................................................. 54

6.4.3 Módulo de Relatórios ............................................................................................................ 60

6.4.4 Módulo de Alertas ................................................................................................................. 63

6.4.5 Módulo de Actuação ............................................................................................................. 64

6.4.6 Módulo de Tarifários ............................................................................................................. 65

6.4.7 Módulo de Criação e Cálculo de Tarifas ................................................................................ 65

6.4.8 Módulo de Simulação de Tarifários ....................................................................................... 71

6.5 PROTÓTIPOS DE INTERFACE .................................................................................................................... 72

6.6 REQUISITOS NÃO - FUNCIONAIS .............................................................................................................. 81

6.6.1 Eficiência ................................................................................................................................ 81

6.6.2 Fiabilidade ............................................................................................................................. 81

6.6.3 Manutenção .......................................................................................................................... 82

6.6.4 Portabilidade ......................................................................................................................... 82

6.6.5 Segurança .............................................................................................................................. 82

6.6.6 Usabilidade ............................................................................................................................ 82

6.6.7 Requisitos Tecnológicos ......................................................................................................... 83

6.6.8 Requisitos de Documentação ................................................................................................ 84

6.7 OPINIÃO ............................................................................................................................................ 84

7 ARQUITECTURA E IMPLEMENTAÇÃO DA PLATAFORMA ..................................................................... 87

7.1 INTEGRAÇÃO COM OS VÁRIOS SISTEMAS ................................................................................................... 87

7.2 IMPLEMENTAÇÃO ................................................................................................................................. 88

7.2.1 Ferramentas .......................................................................................................................... 88

7.2.2 Organização do Código ......................................................................................................... 89

7.3 COMPONENTES ................................................................................................................................... 90

7.3.1 Base de Dados ....................................................................................................................... 92

7.3.2 Task Scheduler ....................................................................................................................... 96

7.3.3 Core da Aplicação .................................................................................................................. 97

7.3.4 Web Service ........................................................................................................................... 98

7.3.5 Aplicação Web ..................................................................................................................... 100

7.4 PROBLEMAS ENCONTRADOS ................................................................................................................. 110

7.4.1 Árvore de Grupos ................................................................................................................. 110

7.4.2 Acessos a Tabela de Dados .................................................................................................. 111

7.5 TESTES UNITÁRIOS .............................................................................................................................. 112

7.6 OPINIÃO .......................................................................................................................................... 112

8 VERIFICAÇÃO E VALIDAÇÃO ............................................................................................................. 113

8.1 REVISÃO........................................................................................................................................... 113

8.2 VALIDAÇÃO ....................................................................................................................................... 113

iEnergy – Eficiência Energética em Edifícios Índice

Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011 xiii

8.2.1 Ambiente de Testes ............................................................................................................. 113

8.3 VERIFICAÇÃO ..................................................................................................................................... 114

8.4 INSTALAÇÃO NO CLIENTE ..................................................................................................................... 115

9 CONCLUSÃO E PERSPECTIVAS FUTURAS .......................................................................................... 117

9.1 PLANEAMENTO EFECTIVAMENTE SEGUIDO .............................................................................................. 117

9.1.1 Planeamento Efectivamente Seguido no Primeiro Semestre............................................... 117

9.1.2 Planeamento Efectivamente Seguido no Segundo Semestre .............................................. 118

9.1.3 Justificação dos Desvios ....................................................................................................... 119

9.2 AVALIAÇÃO DO TRABALHO DESENVOLVIDO ............................................................................................. 119

9.3 TRABALHO FUTURO ............................................................................................................................ 121

9.4 CONSIDERAÇÕES PESSOAIS................................................................................................................... 121

REFERÊNCIAS .......................................................................................................................................... 127

iEnergy – Eficiência Energética em Edifícios Índice de Figuras

Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011 xv

Í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 ............................................................................................... 14

Figura 4 – Diagrama de Gantt com o planeamento inicial do trabalho a realizar no primeiro semestre. ........ 17

Figura 5 – Diagrama de Gantt com o planeamento do trabalho a realizar no segundo semestre ..................... 17

Figura 6 -Número de funcionalidades dos competidores ................................................................................. 32

Figura 7 - Tipo de tecnologias usadas pelos competidores .............................................................................. 34

Figura 8: Relação entre a complexidade (número de funcionalidades) e o tipo de tecnologias ....................... 35

Figura 9 - Hierarquia de Utilizadores .............................................................................................................. 43

Figura 10 - Exemplo de perguntas colocadas no Google Docs........................................................................ 44

Figura 11 - Casos de uso do sistema separados por pacotes ............................................................................ 45

Figura 12 - Termo fixo do tarifário .................................................................................................................. 67

Figura 13 - Descriminação de preços de energia activa ................................................................................... 67

Figura 14 - Descriminação de preços de potência ........................................................................................... 68

Figura 15 - Descriminação de preços de energia reactiva ................................................................................ 69

Figura 16 - Factores multiplicativos aplicados a energia reactiva ................................................................... 69

Figura 17 - Gráfico de linhas com representação dos períodos sazonais e períodos horários ......................... 73

Figura 18 - Opções de Gráfico e informação de análise .................................................................................. 73

Figura 19 - Tabela de Conclusões .................................................................................................................... 74

Figura 20 - Tabela Geral .................................................................................................................................. 74

Figura 21 - Análise de Custos .......................................................................................................................... 75

Figura 22 - Lista de Alertas ............................................................................................................................. 75

Figura 23 - Criação de alertas .......................................................................................................................... 76

Figura 24 - Lista de alertas disparados ............................................................................................................ 76

Figura 25 - Criação de actuações ..................................................................................................................... 77

Figura 26 - Lista de actuações ......................................................................................................................... 77

Figura 27 - Simulação de tarifários .................................................................................................................. 78

Figura 28 - Lista de tarifários .......................................................................................................................... 78

Figura 29 - Inserção de novo tarifário .............................................................................................................. 79

Figura 30 - Inserção de parâmetros do tarifário ............................................................................................... 79

Figura 31- Lista de grupos ............................................................................................................................... 80

Figura 32 - Página de edição de grupos ........................................................................................................... 80

Figura 33 - Esquema de funcionamento do ASP.NET MVC (retirado do msdn Webcast) ............................. 83

Figura 34 -Como é que o portal web e o iEnergy se enquadram na solução de medição ................................ 87 Figura 35 - Organização do código no Visual Studio. ..................................................................................... 90

Figura 36 - Módulos do iEnergy ...................................................................................................................... 91

Figura 37 - Fluxograma de cálculo de tarifários B2B ...................................................................................... 95

Figura 38 - Fluxo de cálculo da baseline ......................................................................................................... 95

Figura 39 – Fluxo de funcionamento dos alertas ............................................................................................. 97

Figura 40 -Diagrama de classes Core (apenas a parte criada durante o estágio) ............................................. 98

Figura 41 – Diagrama de classes End Point de edifícios ................................................................................. 99

Figura 42 - Visão Geral do Sistema ............................................................................................................... 100

Figura 43 - Arquitectura Web Service ............................................................................................................ 100

Figura 44 - Arquitectura lógica ...................................................................................................................... 101

Figura 45 - Decomposição Horizontal ........................................................................................................... 102

Figura 46 - Decomposição Vertical ............................................................................................................... 103

Índice de Figuras iEnergy – Eficiência Energética em Edifícios

xvi Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

Figura 47- Diagrama de classes do Controller ............................................................................................... 106

Figura 48 - Modelo de classes dos Action Filters .......................................................................................... 107

Figura 49 - Diagrama de classes dos helpers do view.................................................................................... 109

Figura 50 - Modelos de classes dos Binders .................................................................................................. 110

Figura 51 – Diagrama de gantt com a distribuição temporal do trabalho realizado no primeiro semestre. ... 117

Figura 52 – Diagrama de Gantt com a distribuição temporal do trabalho realizado no segundo semestre.... 118

Figura 53 - Ciclo de Gestão de energia .......................................................................................................... 124

iEnergy – Eficiência Energética em Edifícios Índice de Tabelas

Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011 xvii

Índice de Tabelas

Tabela 1 - Fases do Game do Projecto ................................................................................................................. 18

Tabela 2 - Quadro parcial de funcionalidades da concorrência ............................................................................ 33

Tabela 3 - Comparação de ferramentas web de construção de gráficos ............................................................... 38

Tabela 4 - Tempo de renderização de gráficos ..................................................................................................... 40

Tabela 5 - Tabela de requisitos do sistema ........................................................................................................... 46

Tabela 6 - Requisitos de grupos lógicos ............................................................................................................... 49

Tabela 7 - Tabela de Requisitos de Baseline ........................................................................................................ 50

Tabela 8 - Requisitos de KPIs .............................................................................................................................. 51

Tabela 9 - Requisitos de indicadores de estado .................................................................................................... 52

Tabela 10 - Requisitos de indicadores de poupança ............................................................................................. 53

Tabela 11 - Requisitos de mensagens ................................................................................................................... 54

Tabela 12 - Requisitos de tags virtuais ................................................................................................................. 54

Tabela 13 – Requisitos de configuração de opções de grupos e variáveis ............................................................ 56

Tabela 14 - Requisitos de configuração da aquisição de dados ............................................................................ 57

Tabela 15 - Requisitos de visualização de dados .................................................................................................. 58

Tabela 16 - Requisitos de análise de custos de energia ........................................................................................ 59

Tabela 17 - Requisitos de conclusões da análise .................................................................................................. 59

Tabela 18 - Requisitos de dados gerais ................................................................................................................. 59

Tabela 19 - Requisitos de Relatórios .................................................................................................................... 63

Tabela 20 - Requisitos para gestão de Alertas ...................................................................................................... 64

Tabela 21 – Requisitos para a actuação ................................................................................................................ 64

Tabela 22 – Requisitos para o cálculo de tarifários .............................................................................................. 66

Tabela 23 – Requisitos para simulação de tarifários ............................................................................................ 72

Tabela 24 - Ligação de requisitos a protótipos ..................................................................................................... 72

Tabela 25 -Descrição sumária das entidades do diagrama da base de dados ........................................................ 93

iEnergy – Eficiência Energética em Edifícios Índice de Anexos

Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011 xix

Í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

iEnergy – Eficiência Energética em Edifícios Introdução

Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011 1

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.

Introdução iEnergy – Eficiência Energética em Edifícios

2 Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011

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



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



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 (transforma-

os 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.



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 -.

1.5 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.



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.

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.

Figura 1 - Camadas da plataforma

Aquisição

Recolha

Tratamento de

dados

Fornecimento

de dados

Web

iCenter

iEnergy

Domestico Escolas Edifícios

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.

2.2.1 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;



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.

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.

2.2.2 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

Tags

Dispositivos

Unidades Edificio 1

Sala 1

Energy Temperature

Sala 2

Humidity



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.

2.2.2.1 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.

2.2.2.2 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.



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



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. Pretende-

se 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 6.

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

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.

3.1.1 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 auto-

responsabilizaçã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

http://improveit.com.br/xp/manifesto_agil

http://improveit.com.br/xp/manifesto_agil

http://improveit.com.br/scrum/product_backlog

http://improveit.com.br/scrum/sprint_planning_meeting

http://improveit.com.br/scrum/product_owner



http://improveit.com.br/scrum/sprint_backlog

http://improveit.com.br/scrum/daily_scrum

http://improveit.com.br/scrum/daily_scrum

http://improveit.com.br/scrum/sprint_review_meeting

http://improveit.com.br/scrum/sprint_review_meeting

http://improveit.com.br/scrum/sprint_retrospective



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.

3.2.1 Fases do Scrum

Nesta subsecção são apresentadas todas as fases pelas quais o projecto passou, e é explicada cada

uma delas.

3.2.1.1 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.

3.2.1.1.1 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.



3.2.1.1.2 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;

3.2.1.1.3 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.

3.2.1.1.4 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.

3.2.1.1.4.1 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.



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 -.

3.2.1.1.4.2 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



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 2011.

3.2.1.2 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

Construção

Sprint = Iteração Sprint Backlog, Objectivo da

Sprint

Demo da Iteração

Pré-

Produção

Revisão da Sprint Demo da Iteração Validação de Objectivos

Análise Retrospectiva Validação de Objectivos Lista de Impedimentos

Tabela 1 - Fases do Game do Projecto

3.2.1.2.1 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

3.2.1.2.2 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



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.

3.2.1.2.2.1 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.

3.2.1.2.3 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.

3.2.1.2.4 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.

3.2.1.3 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



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.

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.

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

Nesta secção são apresentados os requisitos funcionais do sistema a desenvolver neste projecto

inicial.

4.3.1 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.

4.3.1.1 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



4.3.1.2 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.

4.3.1.3 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.

4.3.2 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.

4.3.3 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.

4.3.3.1 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.



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.

4.3.3.2 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).



4.3.3.2.1 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) (Registos) – Soma dos consumos de uma embarcação através dos dados

inseridos;


Distância/Carreira – Distância média percorrida por viagem do tipo carreira.



Motores/Carreira (%) – Percentagem de utilização dos motores em viagens 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.

4.3.3.2.2 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;



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.

4.3.3.2.3 Consumos Totais de Combustível

Os indicadores da tabela de consumos totais gastos em cada um dos tipos de viagens, são


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;

4.3.3.2.4 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.



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.

4.3.3.3 Relatórios de Carreiras

Estes relatórios são dividos em duas partes. Essas partes são descritas nas secções seguintes.

4.3.3.3.1 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.

4.3.3.3.2 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).



Desvio padrão – Diferença entre o valor máximo e mínimo de passageiros por carreira.

4.3.4 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.

4.3.5 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 “T20110209” sendo que neste

exemplo os ficheiros são para a data 2011-02-09 ou seja, se no dia 2011-02-10 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;



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).

4.3.6 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 12000 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.

4.4.1 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.

4.4.1.1 IDE

Durante o desenvolvimento foi usado o IDE Microsoft Visual Studio 2010 porque era o que se

adequava mais as tecnologias em causa.



4.4.1.2 Base de Dados

Como sistema de gestão de base de dados foi usado o Microsoft SQL Server 2008 RC2.

4.4.1.3 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.

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.

5.1.1 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

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.

Tem

po

rea

l

Co

mp

ara

tiv

os

Rel

ató

rio

s

Grá

fico

s d

e

his

tóri

co

Ale

rta

s

Ex

po

rta

ção

de

da

do

s

Ta

rifá

rio

s

Sim

ula

ção

de

Ta

rifá

rio

s

Act

ua

ção

Ind

ica

do

res

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 - -



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.

5.1.2 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



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.

5.2.1 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



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.

5.2.2 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 -.




A base de dados já se encontrava implementada sobre uma BD Sql Server 2008 RC2, portanto não

foi objecto de estudo.

5.2.2.2 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);

http://weblogs.asp.net/scottgu/archive/2005/12/21/asp-net-2-0-control-adapter-architecture.aspx

http://weblogs.asp.net/scottgu/archive/2005/12/21/asp-net-2-0-control-adapter-architecture.aspx

http://en.wikipedia.org/wiki/Model-view-controller



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 2.0.

5.2.2.3 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.

5.2.2.4 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.

5.2.3 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.

5.2.3.1 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.

5.2.3.2 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 2003.



5.2.3.3 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.

5.2.3.4 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.

5.2.4 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

m

Panning Múltipl

os eixos

Diferentes

tipos de

gráficos

Mostrar

detalhes de

pontos

Possibilidad

e de

exportação

para Excel

Custo

s

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

http://www.google.pt/aclk?sa=l&ai=Cnpis4FZETpPWDoiehQfc0oD4A_GrzIICgf3PiBP1tYMJCAAQAVCwkr_n_P____8BYO3U3IWYG6ABmYKH_wPIAQGqBBtP0DCxMr8NE9emgWxmxuoFR4AQ4H8xjyCIzt66BRMIs73JtKTIqgIViUDhCh2oWtGZygUA&ei=31ZETvPRGImBhQeotcXOCQ&sig=AOD64_37DFdHkoKxWsmbxYATxKTx8bw4lg&sqi=2&ved=0CAoQ0Qw&adurl=http://www.devexpress.com/go/Google_2_Chart_Control_Google_2010_6_03.aspx




5.2.4.1 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.

5.2.4.1.1 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.

5.2.4.1.2 Servidor

CPU: Intel Core2 Duo a 2,40GHz

Memória: 4GB

5.2.4.1.3 Cliente

CPU: Intel Core2 Duo a 2,40GHz

Memória: 2GB

5.2.4.1.4 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.

5.2.4.1.5 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.



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

Control

1s 2s 10s 20s 29s

Tabela 4 - Tempo de renderização de gráficos

5.2.4.2 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 4.



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

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.



Administrador: Acesso total à plataforma.

Pode ser vista de seguida a hierarquia entre eles no seguinte diagrama (Figura 9):

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.

6.3.1 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

uc Actors

Cliente

Gestor de energia

Administrador



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.



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.

Figura 11 - Casos de uso do sistema separados por pacotes

uc Primary Use Cases

Sistema de gestão de energia

Cliente

Visualização de dados(alertas, actuação,grupos, indicadores, tarifários)

Análise de dados

Gestão de actuação

Gestão de grupos

Gestão de alertas

Gestão de Indicadores

Gestão de v irtual tags

Gestão de tarifários

Cálculo de tarifário

Verificação de actuações

Verificação de alertas

Simulação de tarifários

Cálculo da baseline

Gestão da baseline

Visualização de ralatórios

Gestor de energia

Administrador

Sistema



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

6.4.1 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



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.

6.4.1.1 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

grupos lógicos.

Must Have

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

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.

Must Have

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



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.

CGL6 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.

Must Have

CGL7 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.

Must Have

CGL8 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



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 )

CGL9 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.

Must Have

CGL10 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.

Must Have

Tabela 6 - Requisitos de grupos lógicos

6.4.1.2 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.


CBE1 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).

Must have

CBE2 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



CBE3 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 ).

Must have

CBE4 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.

Must have

Tabela 7 - Tabela de Requisitos de Baseline

6.4.1.3 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.


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



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.

IND2 Medida Kw/h consumido:

Indicador horário, com o valor do consumo para tags do tipo energia

activa e visíveis para o utilizador.

Must have

IND3 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.

Must have

IND4 Indicador de temperatura:

Indicador horário, com o último valor instantâneo disponível, para a

temperatura.

Must have

IND5 Indicador de humidade:

Indicador horário, com o último valor instantâneo disponível, para a

humidade.

Must have

IND6 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.

Must have

IND7 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.

Must have

IND8 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.

Must have

Tabela 8 - Requisitos de KPIs

6.4.1.4 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



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.


IND09 Deve ser possível criar, editar e apagar indicadores de estado.

Estes indicadores devem estar associados aos grupos lógicos.

Must have

IND10 As operações possíveis na criação de um indicador de estado são a

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.

Must have

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

6.4.1.5 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.


INP-001 Os indicadores de poupança são indicadores predefinidos que

são vistos nos relatórios gerados pela aplicação e têm como base de

cálculo a baseline.

Must have

INP-002 Sempre que uma baseline é actualizada os valores dos Must have



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 0 – 1340 kWh

(Desactivação de Chiller)

Tabela 10 - Requisitos de indicadores de poupança

6.4.1.6 Mensagens (MNS)

As mensagens servem como forma de comunicação entre o gestor de energia e o gestor de

determinado edifício.


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



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

filtro por agência.

Nice to

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

6.4.1.7 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.


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,

soma e subtracção. As operações são sempre feitas sobre duas ou mais

tags.

Must have

TV3 O resultado desta operação deve poder ser visto da mesma forma que

são vistas as tags normais. Devem também aparecer na hierarquia de

grupos na aplicação web.

Must have

TV4 As tags virtuais devem também ser agregadas segundo as agregações

especificadas para esta aplicação (Hora, dia, mês).

Must have

Tabela 12 - Requisitos de tags virtuais

6.4.2 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



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.

6.4.2.1.1 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.


COGV1 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.

Must Have

COGV2 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.

Nice to Have

COGV3 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.

Shoud Have

COGV4 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).

Shoud Have

Notas

O interface web deve apresentar uma árvore com a seguinte hierarquia base com este formato:



Tabela 13 – Requisitos de configuração de opções de grupos e variáveis

6.4.2.1.2 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.


COD1 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.

Must Have

COD2 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).

Nice to Have

COD3 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).

Must Have

COD4 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.

Must Have

COD5 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



e a hora fim 23:59).

COD6 O gestor de energia deve ter a possibilidade de configurar a

obtenção de dados agregados (hora, dia, Mês).

Must Have

COD7 O gestor de energia deve poder minimizar a área de opções

para ter maior área de análise.

Must Have

COD8 O gestor de energia deve poder ter a opção de criar gráficos

de regressão linear simples para os parâmetros seleccionados.

Must Have

Tabela 14 - Requisitos de configuração da aquisição de dados

6.4.2.1.3 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.


VDG1 O gestor de energia pode gerar um gráfico quando tiver no

mínimo um parâmetro energético e um dia seleccionado.

Must Have

VDG2 O gestor de energia pode gerar um gráfico com base nas

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).

Must Have

VDG3 Os eixos do gráfico devem estar identificados com as suas

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).

Must Have

VDG4 O gestor de energia deve ser informado do período sazonal

dos dados representados no gráfico (o gráfico pode ter informação

de vários períodos sazonais).

Nice to Have

VDG5 O gestor de energia deve ter a indicação dos diferentes

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).

Must Have

VDG6 O gráfico deve conter uma legenda elucidativa de todas as Must Have



séries de dados representados nele.

VDG7 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.

Must Have

VDG8 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.

Must to Have

VDG9 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.

Must Have

VDG10 O gestor de energia pode seleccionar o tipo de gráfico (linhas,

barras, Stacked Bar).

Nice to Have

VDG11 O gestor de energia deve poder exportada o gráfico e toda

informação contida nele, bem como a tabela geral para Excel.

Must Have

Tabela 15 - Requisitos de visualização de dados

6.4.2.1.4 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.


ACE1 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.

Must have

ACE2 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.

Must have

ACE3 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



etc) e o tarifário.

ACE4 O gestor de energia pode exportar estas tabelas para o

formato Excel.

Must have

Tabela 16 - Requisitos de análise de custos de energia

6.4.2.1.5 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.


CA1 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.

Must have

CA2 O gestor de energia pode também consultar uma tabela com o

resumo de consumos em horas de ponta.

Must have

CA3 O gestor de energia pode exportar esta tabela para o formato

Excel.

Must have

Tabela 17 - Requisitos de conclusões da análise

6.4.2.1.6 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.


TG1 O gestor de energia deve poder consultar os dados contidos no

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).

Must have

TG2 O gestor de energia pode exportar a tabela para o formato Excel. Must have

Tabela 18 - Requisitos de dados gerais



6.4.3 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.


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:

Diário

Semanal

Mensal

Anual

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.

Must have

REL2 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.

Must have

REL3 Relatório Semanal terá de apresentar os seguintes campos para a

semana seleccionada:



reactiva



Must have



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

REL4 Relatório Mensal terá de apresentar os seguintes campos para o mês

seleccionado:



reactiva



Tabela de alarmes para o Facto de Potência com valores

inferiores a 0,94.





Must have

REL5 Relatório Anual terá de apresentar os seguintes campos para o ano

seleccionado:

Gráfico, tabela de consumos e tabela de custos da energia activa.


reactiva



Tabela de alarmes para o Factor de Potência com valores

inferiores a 0,94.




Must have




REL6 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:

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.

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.

Must have

REL7 Semelhante a REL6 mas para energia reactiva. Must have

REL8 As secções de Factor de Potência e de Voltagem são semelhantes às

anteriores apenas não possuem tabela custos.

Must have

REL9 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.

Must have

REL10 Na secção de indicadores de poupança são apresentadas 3 tabelas:

Poupança de energia

Poupança de custos

Must have



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.

REL11 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).

Must have

Tabela 19 - Requisitos de Relatórios

6.4.4 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.


ALM1 Esta funcionalidade deve funcionar da mesma maneira que os

validadores no iEnergy sendo estes plugins (dll’s) que são carregados

para o iEnergy.

Must have

ALM2 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.

Must have

ALM3 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



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.

ALM4 Quando o alarme é disparado deve ser enviado um email para a

lista configurada nos parâmetros do alerta com a descrição do alarme.

Must have

ALM5 Deve ser possível no iEnergy listar todos os alarmes disparados pelo

sistema. Deve também ser possível marca-los como lidos.

Must have

Tabela 20 - Requisitos para gestão de alertas

6.4.5 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.


MA1 Deve ser possível agendar actuações para cada um dos dias da

semana para uma determinada hora.

Must have

MA2 Deve ser possível ver a lista de actuações, registadas no sistema vem

como gerir essas actuações (adicionar, editar e apagar).

Must have

MA3 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

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



6.4.6 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.

6.4.7 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.


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á

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)

Must have

CTAR2 Cada um dos parâmetros que podem ser adicionados aos tarifários

tem os seguintes parâmetros associados:

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.

Must have



CTAR3 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.

Must have

CTAR4 Deve ser possível associar custos fixos aos tarifários industriais que

seram aplicados ao custo no fim de cada mês. Must have

CTAR5 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.

Must have

CTAR6 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

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



6.4.7.1 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.

6.4.7.2 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

6.4.7.3 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

6.4.7.4 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

6.4.7.5.7.5 e 6.4.7.5.7.6.

Como exemplo, apresentam-se ambos os preços para a opção tarifária de MAT.



Figura 14 - Descriminação de preços de potência

6.4.7.5 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.”

6.4.7.6 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.”

6.4.7.7 Energia Reactiva

As opções tarifárias apresentam ainda um termo relativo a preços da energia reactiva, definidos em

Euros por kvarh.



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 6.4.7.8 e 6.4.7.8.

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

6.4.7.8 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 01.01.2012) 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.

6.4.7.9 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.



6.4.7.10 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.

6.4.7.11 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);

6.4.7.12 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:

(

)

6.4.7.13 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.



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:

6.4.8 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.


STAR1 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.

Must have

STAR2 Deve ser possível seleccionar o grupo lógico para a qual se pretende

a simulação de tarifários.

STAR3 A simulação de tarifários e relativa a cada uma das componentes de

cada tarifário:

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.

Must have

STAR4 Os tipos de horas usados pela simulação são configurados na área de

tarifários bem como o preço das potências e das energias capacitiva e

indutiva.

Must have

STAR5 O resultado da simulação pode ser positivo ou negativo sendo que um

resultado positivo significa que se estivesse a usar aquele tarifário

pouparia em relação ao outro tarifário.

Must have

STAR6 Deve ser possível exportar esta informação para Excel. Nice to Have



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



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



6.6 Requisitos Não - Funcionais

Existem vários requisitos de qualidade que se explicitam de seguida.

6.6.1 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.

6.6.2 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



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.

6.6.3 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.

6.6.4 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.

6.6.5 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.

6.6.6 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.



É 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.

6.6.7 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.



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.

6.6.8 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



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.

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

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 -.

7.2 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.

7.2.1 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.

7.2.1.1 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 6.6.7.

7.2.1.2 IDE

Durante o desenvolvimento foi usado o IDE Microsoft Visual Studio 2010 porque era o que se

adequava mais as tecnologias em causa.


A base de dados assenta sobre o Microsoft SQL Server 2008 RC2.



7.2.1.4 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.

7.2.2 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.



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.



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.



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.

7.3.1 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.



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



7.3.1.1 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.

7.3.1.2 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 38.



Inicio

Fim

Tag de Tarifário?

Calcular custos do parâmetro

(Data de fim- data de inicio)=Período de

calculo ?

Sim

Não

Não

Sim

Ler dados das tag

Ler Tarifário da Tag

Ler os Parâmetros do tarifário

O tarifário tem parâmetros

configurados?

SIm

Não

Ler período de calculo

Figura 37 - Fluxograma de cálculo de tarifários B2B

Início

Ler conjunto

sequencial

de

baselines

Existe

próxima?Fim

Baseline do

Ano 0?

Já calculada?

Calcular intervalo

de funcionamento

da baseline

Baseline mais

recente?

Intervalo

superior a 1

mês?

Calcular Baseline

Sim

NãoSim

Não

Sim

Não Sim

Não

Sim

Figura 38 - Fluxo de cálculo da baseline



Todos estes procedimentos correm como Jobs na base de dados com uma periocidade configurável

ou através do agendador de tarefas do Windows.

7.3.1.3 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.

7.3.2 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 e-mail a confirmar essa situação; em caso de

anormalidade é lançado um alerta para o sistema e é também enviado um e-mail 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.



Inicio

Lançar alarme e enviar mail

O alarme esta dentro dos parâmetros?

FimTerminou o período de avaliação do alarme?

Não

Sim

Não

Enviar Email

Sim

Passou o período de verificação?

Não

Sim

Ler alarmes configurados no sistema

Figura 39 – Fluxo de funcionamento dos alertas

7.3.3 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



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)

7.3.4 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



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.

7.3.4.1 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



7.3.5 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.

7.3.5.1 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.

iEnergy4Buildings

IIS

.NET Framework

Consumer API

iEnergy2 Server

Services ProviderIntranet

XMLXML

ConsumidorFornecedor

Browser

HTML,JSON

Figura 43 - Arquitectura Web Service



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 7.2.

7.3.5.2 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.

ServicesServicesWeb Browser

HTML

Web Application

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.

7.3.5.2.1 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;



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.

Figura 45 - Decomposição Horizontal

7.3.5.2.2 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.

uc Use Case Model

Interface com o utilizador(View)

Logica de negocio(contoller)

Base de dados (Model)



Figura 46 - Decomposição Vertical

7.3.5.2.2.1 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).

7.3.5.2.2.2 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.



7.3.5.2.2.3 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.

7.3.5.2.2.4 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.

7.3.5.2.2.5 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.

7.3.5.3 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.

7.3.5.3.1 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.



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.

7.3.5.3.2 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.



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



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.

7.3.5.3.2.1 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

7.3.5.3.3 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



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.

7.3.5.3.3.1 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).



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.

7.3.5.3.3.2 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



Na Figura 50 é apresentado o modelo de classes dos binders construídos durante o projecto de

estágio.

Figura 50 - Modelos de classes dos Binders

7.3.5.3.4 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.

7.4.1 Á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



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.

7.4.1.1 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.

7.4.2 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.

7.4.2.1 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.



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.

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.

8.2.1 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.

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

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

50000 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.



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.

9.1.1 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

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 3.

9.1.2 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



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.

9.1.3 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



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.



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



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.

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

Elaboração

de relatórios

Recolha de dados

Contabilização

dos consumos energéticos

Tratamento

de informação

Tomada de medidas

correctivas

e preventivas

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.

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.

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.]

http://www.isasensing.com/documentation/iMeterPlug_PT.pdf.

2. PORTUGAL – Folha de dados de diversificação de energias . European Commission.

[Online] Janeiro de 2007.

http://ec.europa.eu/energy/energy_policy/doc/factsheets/country/pt/mix_pt_pt.pdf.

3. Oil and Gas Emergency Policy - Portugal 2011 update. International Energy Agency

(IEA). [Online] http://www.iea.org/publications/free_new_Desc.asp?PUBS_ID=2413.

4. Plano de Racionalização dos Consumos de Energia . Plano de Racionalização dos

Consumos de Energia . [Online] Energia e Ambiente. LDA.

http://www.cmfg.pt/Serv/Energ/rgce.htm.

5. THE STANDISH GROUP REPORT. s.l. : The Standish Group , 1995.

6. Regulamento Tarifário Do Sector Eléctrico, ERSE, Dezembro de 2009. [Online]

http://www.erse.pt/pt/electricidade/regulamentos/tarifario/Documents/RT%20Dez

%202009_vers%C3%A3o%20INTERNET.pdf.

7. Regulamento de Relações Comerciais Do Sector Eléctrico, ERSE, Agosto de 2009.

[Online]

http://www.erse.pt/pt/electricidade/regulamentos/relacoescomerciais/Documents/

Regulamento% 20de%20Rela%C3%A7%C3%B5es%20Comerciais%

20-%20Agosto%202009.pdf.

8. Nota informativa sobre as novas regras de facturação da energia reactiva, ERSE, 21 de

Abril de 2010. [Online]

http://www.erse.pt/pt/consultaspublicas/consultas/Documents/31_4/Comunicado_reactiva

_21Abril2010.pdf &&

http://www.erse.pt/pt/consultaspublicas/consultas/Documents/31_4/Despacho_3_2010.pdf.

9. PulseEnergy . PulseEnergy . [Online] www.pulseenergy.com/.

10. plus-energy. plus-energy. [Online] www.plus-energy.com.

11. advanced telemetry. advanced telemetry. [Online] www.advancedtelemetry.com/ .

12. energymeteringtechnology. [Online] energymeteringtechnology.com/.

13. agile waves. agile waves. [Online] www.agilewaves.com/ .

14. Vision BMS . Vision BMS . [Online] www.visionbms.com/.

15. Synapsense . Synapsense . [Online] www.synapsense.com/.

16. Schneider Electric . Schneider Electric . [Online] www.schneider-electric.com.

17. Raritan . Raritan . [Online] www.raritan.com/.

18. Enigin . Enigin . [Online] www.enigin.com/ .

19. Johnson Controls . Johnson Controls . [Online] www.johnsoncontrols.com/.

20. Henriques, João. clubeinvest. A História do Petróleo. [Online]

Refêrencias iEnergy – Eficiência Energética em Edifícios


http://www.clubeinvest.com/bolsa/show_futures_technical_analysis.php?id=148.

21. Goldenberg, Michel. Scrum. Scrum. [Online]

http://www.scrumalliance.org/profiles/38596-michel-goldenberg.

22. Kniberg, Henrik. Scrum and XP from the Trenches. How we do Scrum.

23. Patton, Ron. Software Testing. 2005.

iEnergy – Eficiência Energética em Edifícios Anexo I – Estado de Arte

Anexo I – Estado da Arte

3

Estudo de Estado de Arte

Out. 2010

Estado da arte

Índice

1 INTRODUÇÃO ........................................................................................................................ 1

2 FUNCIONALIDADES ............................................................................................................... 3

3 TECNOLOGIAS ....................................................................................................................... 5

4 ANÁLISE GRÁFICA.................................................................................................................. 6

5 SOFTWARE DE GESTÃO ENERGÉTICA ..................................................................................... 8

Estado da arte

1

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.

Estado da arte

2

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.

Estado da arte

3

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.

Esta

do d

a a

rte

4

A tab

ela segu

inte m

ostra o

s com

petid

ores em

análise e as fu

ncio

nalid

ades q

ue o

ferecem:

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

email

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

Pu

lse En

ergy

X

X

X

X

X

X

X

X

En

igin

X

X

X

X

X

X

X

X

X

X

X

Plu

s-En

ergy

X

X

X

X

X

X

X

X

A

dv

an

ced

Tele

metry

X

X

X

X

En

ergy

Meterin

g

Tech

nolo

gy

X

X

X

X

Ag

ileWa

ves

X

X

X

X

X

X

X

X

X

Visio

nb

ms

X

X

X

X

X

X

X

N

oved

a

X

X

X

X

X

X

X

X

Sy

nap

sense

(Data

Cen

ters)

X

X

Sch

neid

er

Electric

X

X

X

X

X

X

Joh

nso

n

Con

trols

X

X

X

X

X

X

X

X

X

X

X

X

Rarita

n

X

X

X

X

X

T

abela 1

-Funcio

nalid

ades d

os p

rincip

ais conco

rrentes

Estado da arte

5

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

móvel

Aplicação

Web

Aplicação

desktop

Tecnologias DB

Pulse Energy NA A NA Flash,

Spring(J2EE)

NS

Enigin A A A PHP,.NET,

Flash,

JavaScript and

PERL

NS

Plus-Energy NA A NA NS

Advanced

Telemetry

NA A NA ASP.net/C# NS

Energy Metering

Technology

NS NS NS .NET SqlServer

Visionbms NA NA A . NET MySQL/Or

acle/SqlSer

ver

AgileWaves API for 3rd

party

A API for 3rd

party

Flash… NS

Noveda NA A NA PHP, Perl,

Flash

MySQL

Synapsense NA NA A NS NS

Schneider Electric NA NA A (Windows) NS

Raritan NA A NA J2EE,

Ajax/Flash/Fle

x

NS

Johnson Controls A A A JAVA,JSP/J2E

E

NS

Tabela 2 - Tecnologias dos principais concorrentes

Legenda:

A – Disponível

NA – Não disponível

NS – Não especificado

Estado da arte

6

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

Estado da arte

7

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)

Esta

do d

a a

rte

8

5

So

ftwa

re de g

estão

energ

ética

Nesta secção

são ap

resentad

as mais alg

um

as solu

ções d

e ou

tras emp

resas já presen

tes no

mercad

o.

Ap

licação D

escrição S

istemas

op

erativo

s D

ispo

nív

el

para o

pú

blico

em

geral?

Necessita d

e

ligação

à

Intern

et?

Versão

web

? P

reço N

otas

Po

werM

eter F

erramen

ta de

mo

nito

rização d

os g

astos

de electricid

ade e g

ás

nu

ma h

abitação

.

To

do

s (à partid

a,

um

a vez q

ue é

web

ba

sed).

Ain

da n

ão.

Sim

. S

im.

Grátis.

En

contra-se em

versão

beta

e neste m

om

ento

apen

as

po

de ser testad

o p

elos

emp

regad

os d

o G

oo

gle e p

or

um

gru

po

restrito d

e

clientes. N

ecessita qu

e as

hab

itações o

nd

e seja

utilizad

o ten

ha u

m co

ntad

or

intelig

ente p

ara fun

cion

ar.

Energ

y L

ens

Ferram

enta d

e

mo

nito

rização d

os g

astos

de electricid

ade n

um

edifício

.

Win

do

ws 9

8 o

u

mais recen

te.

Sim

. N

ão.

Não

. 3

45€

po

r licença.

Precisa d

o E

xcel 9

7 o

u m

ais

recente p

ara fun

cion

ar.

Metrix

4 U

tility

Acco

untin

g

Syste

m

Ferram

enta d

e

mo

nito

rização d

os g

astos

de en

ergia (electricid

ade,

gás n

atural, ág

ua, ó

leo

para aq

uecim

ento

, gás

pro

pan

o, g

ás LP

, resídu

os

sólid

os, ág

uas resid

uais)

nu

m ed

ifício.

Win

do

ws 2

000

ou

mais recen

te.

Sim

. P

enso

qu

e não

. N

ão.

Não

especificad

o.

Precisa d

o E

xcel 2

00

3 o

u

mais recen

te para fu

ncio

nar.

Energ

yC

AP

F

erramen

ta de

mo

nito

rização e g

estão d

o

con

sum

o d

e energ

ia (águ

a

e gás, p

elo m

eno

s) e de

pro

cessamen

to d

as con

tas

associad

as.

Não

especificad

o.

Sim

. N

ão n

ecessariam

ente

(só alg

um

as versõ

es

necessitam

).

Sim

.

O p

reço v

aria mu

ito co

m a

versão

da ap

licação e co

m

ou

tros p

arâmetro

s. Versão

client/serv

er: desd

e $50

,00

0

até $2

00

,000

. Versão

on

line: a p

artir de $

3,0

00

po

r ano

para o

rgan

izações

mais p

equ

enas. V

ersão

Desk

top

and

Cam

pu

s:

Desd

e $1

5,0

00

até $40

,00

0.

Energ

y E

xp

ert F

erramen

ta de

mo

nito

rização e d

e

To

do

s (à partid

a,

um

a vez q

ue é

Sim

. S

im.

Sim

.

Não

especificad

o;

dep

end

e de alg

un

s

Est

ado d

a a

rte

9

pre

vis

ão d

os

gas

tos

de

ener

gia

(m

ais

efic

ien

tem

ente

elec

tric

idad

e m

as t

am

bém

gás

) e

de

pic

os

de

corr

ente

nu

m e

dif

ício

. P

erm

ite

tam

bém

cal

cula

r a

po

up

ança

en

ergét

ica

real

izad

a.

web

ba

sed

).

par

âmet

ros.

Mar

ket

Man

ager

F

erra

men

ta q

ue

per

mit

e

mo

nit

ora

r e

sim

ula

r o

s

gas

tos

ener

gét

ico

s em

edif

ício

s e

pre

ver

o e

feit

o

da

apli

caçã

o d

e

det

erm

inad

as m

edid

as

ener

gét

icas

no

s m

esm

os.

Win

do

ws.

S

im.

Não

. P

enso

qu

e n

ão

$1

09

5.

Ho

hm

F

erra

men

ta d

e

mo

nit

ori

zaçã

o d

os

gas

tos

de

ener

gia

nu

ma

hab

itaç

ão

qu

e fo

rnec

e co

nse

lho

s

per

son

aliz

ado

s so

bre

po

up

ança

de

ener

gia

.

Win

do

ws

Azu

re.

Sim

. S

im.

Sim

. G

ráti

s.

Ain

da

só h

á ver

são

bet

a e

esta

ap

enas

se

enco

ntr

a

dis

pon

ível

par

a o

s

uti

liza

do

res

do

s E

stad

os

Un

ido

s d

a A

mér

ica.

Po

wer

Man

agem

ent

Fer

ram

enta

qu

e p

erm

ite

ger

ir a

en

ergia

co

nsu

mid

a

po

r vár

ios

com

pu

tado

res

ligad

os

em r

ede

de

form

a

cen

tral

izad

a.

Win

do

ws

20

00

ou

mai

s re

cen

te e

Ap

ple

Mac

OS

X.

Sim

. P

enso

qu

e n

ão.

Pen

so

qu

e n

ão.

Não

esp

ecif

icad

o.

Po

de

tam

bém

ser

ad

qu

irid

o

com

o p

arte

da

suit

e S

yst

ems

Lif

ecycl

e M

anag

emen

t.

Nig

htW

atch

man

F

erra

men

ta q

ue

per

mit

e

ger

ir a

en

ergia

co

nsu

mid

a

po

r vár

ios

com

pu

tado

res

ligad

os

em r

ede

de

form

a

cen

tral

izad

a.

Win

do

ws

Vis

ta

(Bu

sin

ess,

En

terp

rise

,

En

terp

rise

x64

e

Ult

imat

e) e

Win

do

ws

XP

SP

2

e m

ais

rece

nte

s.

Sim

. N

ão.

Não

. N

ão e

spec

ific

ado

, m

as n

ão

é grá

tis.

Surv

eyo

r F

erra

men

ta q

ue

per

mit

e

ger

ir a

en

ergia

co

nsu

mid

a

po

r vár

ios

com

pu

tado

res

ligad

os

em r

ede

de

form

a

cen

tral

izad

a.

Win

do

ws

Vis

ta,

Vis

ta x

64,

Win

do

ws

XP

e

Win

do

ws

20

00

Pro

fess

ion

al S

P4

(ou

mai

s re

cen

te).

Sim

. P

enso

qu

e n

ão.

Pen

so

qu

e n

ão.

Não

esp

ecif

icad

o,

mas

não

é grá

tis.

Pre

cisa

do

Win

do

ws

Ser

ver

20

08

, 2

00

8 (

x6

4)

ou

Win

do

ws

Ser

ver

20

03

SP

2

par

a o

ser

vid

or

e d

o S

QL

Ser

ver

20

08,

SQ

L S

erver

20

05

SP

2 &

Exp

ress

Ed

itio

n

ou

Mic

roso

ft S

QL

Ser

ver

20

00

par

a a

bas

e d

e d

ado

s

Esta

do d

a a

rte

10

para fu

ncio

nar.

Ed

ison

F

erramen

ta de g

estão

energ

ética em

com

pu

tado

res (apen

as

para u

m).

Win

do

ws X

P

(SP

2) o

u

Win

do

ws V

ista.

Sim

. N

ão.

Não

. G

rátis. V

ersão g

rátis e mais lev

e do

Su

rvey

or.

EZ

GP

O

Ferram

enta q

ue p

ermite

con

trolar as o

pçõ

es de

gestão

energ

ética de fo

rma

centralizad

a de v

ários

com

pu

tado

res usan

do

gro

up

po

licy ob

jects.

(GP

O).

Win

do

ws

20

00

e XP

.

Sim

. N

ão.

Não

. G

rátis. O

s adm

inistrad

ores d

e rede

têm d

e correr W

ind

ow

s

Activ

e Directo

ry.

EZ

Wizard

F

erramen

ta de g

estão

energ

ética em

com

pu

tado

res (apen

as

para u

m)

Win

do

ws 2

000

e

XP

.

Sim

. P

enso

qu

e não

. P

enso

qu

e não

.

Grátis.

Clie

nt en

ergy

calculato

r F

erramen

ta de

cálculo

de p

ou

pan

ça

energ

ética em

com

pu

tado

res (para u

m o

u

vário

s).

To

do

s (à partid

a,

um

a vez q

ue é

web

ba

sed).

Sim

. S

im.

Sim

. G

rátis. S

ó p

ermite sim

ular o

con

sum

o em

sistemas

Hew

llett-Pack

ard (e n

ão

todo

s).

Po

wer S

ave

Ferram

enta q

ue

perm

ite fazer a gestão

energ

ética de v

ários

com

pu

tado

res.

Win

do

ws e M

ac

OS

X.

Sim

. N

ão.

Não

. A

partir d

e 5.2

9€

(para u

ma

licença e u

m an

o d

e Po

wer

Sav

e Main

tenan

ce Pack

age,

para P

ortu

gal, n

a catego

ria

edu

cação).

Onlin

e energ

y

savin

gs

calculato

r

Ferram

enta d

e cálulo

de

po

up

ança en

ergética em

com

pu

tado

res (para u

m o

u

vário

s).

To

do

s (à partid

a,

um

a vez q

ue é

web

ba

sed).

Sim

. S

im.

Sim

. G

rátis.

Ad

van

ced P

ow

er

Sav

e RO

I

Calcu

lator

Ferram

enta d

e cálculo

de

po

up

ança en

ergética em

com

pu

tado

res (para u

m o

u

vário

s).

To

do

s (à partid

a,

um

a vez q

ue é

web

ba

sed).

Sim

. S

im.

Sim

. G

rátis.

Hew

lett-Pack

ard

Po

wer T

o

Chan

ge

Wid

get q

ue reco

lhe o

s

dad

os d

a po

up

ança

energ

ética acum

ulad

a

associad

a ao d

esligam

ento

do

s com

pu

tado

res do

s

utilizad

ores q

uan

do

estes

não

estão a ser u

tilizado

s.

Win

do

ws, L

inu

x e

Mac O

S X

.

Sim

. S

im.

Não

. G

rátis. W

idg

et qu

e recolh

e dad

os e

envia-o

s para u

m serv

ido

r

via In

ternet em

bo

ra

necessite d

e interacção

com

o u

tilizado

r.

Energ

y S

aver

Ga

dg

et de g

estão

Win

do

ws

Sim

. S

im, p

elo m

eno

s para

Não

. G

rátis. G

ad

get p

ara o G

oo

gle

Est

ado d

a a

rte

11

ener

gét

ica

em

com

pu

tad

ore

s (a

pen

as

par

a u

m).

Vis

ta/X

P,

Lin

ux e

Mac

OS

X

ver

a q

uan

tid

ade

de

ener

gia

po

up

ada

pel

a

com

un

idad

e d

e

uti

liza

do

res

do

pro

gra

ma.

Des

kto

p.

Nec

essi

ta d

o

Go

ogle

Des

kto

p 5

ou m

ais

rece

nte

par

a fu

nci

on

ar.

Tab

ela

3 –

Res

um

o d

as c

arac

terí

stic

as m

ais

imp

ort

ante

s d

as p

rin

cip

ais

apli

caçõ

es d

e ges

tão

en

erg

étic

a ex

iste

nte

s n

o m

erca

do

iEnergy – Eficiência Energética em Edifícios Anexo II – Casos de uso

Anexo II – Casos de Uso

Documento de casos de uso

Jan. 2011

Casos de Uso

Índice

1 INTRODUÇÃO ........................................................................................................................ 1

2 CARACTERÍSTICAS DOS UTILIZADORES .................................................................................. 2

3 CASOS DE USO DO SISTEMA .................................................................................................. 3

Casos de Uso

1

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.

Casos de Uso

2

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:

Imagem 1 - Hierarquia de Utilizadores

uc Actors

Cliente

Gestor de energia

Administrador

Casos de Uso

3

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.

Imagem 2 - Casos de uso do sistema separados por pacotes

uc Primary Use Cases

Sistema de gestão de energia

Cliente

Visualização de dados(alertas, actuação,grupos, indicadores, tarifários)

Análise de dados


Gestão de grupos

Gestão de alertas

Gestão de Indicadores

Gestão de v irtual tags


Cálculo de tarifário

Verificação de actuações

Verificação de alertas

Simulação de tarifários

Cálculo da baseline

Gestão da baseline

Visualização de ralatórios

Gestor de energia

Administrador

Sistema

Casos de Uso

4

Imagem 3- Diagrama de casos de uso para visualização de dados

uc Class Model

Visualisação de Dados

Visualizar Dados de

Histórico

Escolher Agregação

de dados

Configurar

Parâmetros de

Aquisição

Escolher Grupo

Lógico

Escolher Tag

Comparar Dados de

Histórico

Exportar Dados

Cliente

Gestor de Energia

Administrador

Gerar Regressão

Linear

Escolher Unidade de

Medida

«include»

«include»

«include»

«include»

«include»

«extend»

«include»

«include»

Casos de Uso

5

Imagem 4 - Casos de uso de gestão de baseline

Imagem 5- Casos de uso para gestão de grupos

uc Cálculo da baseline

Baseline

Gestor de energia

(from Actors)

Gerir Baseline

Cálcular Baseline

Sistema

Ver indicadores de

poupança

«include»

uc Gestão de grupos

Gestão de Grupos

Gestor de energia

(from Actors)

Gerir Grupos

Gerir Indicadores

Gerir Virtual tags

Criar Sub Grupos

Adicionar

Utilizadores a grupos

Adicionar Tags a

Grupos

Adicionar detalhes

«extend»

«extend»

«extend»

«extend»

Casos de Uso

6

Imagem 6 - Casos de uso para gestão de alertas

Imagem 7 - Casos de uso para gestão de tarifários

uc Gestão de alertas

Gestão de alertas

Carregar alerta

Gerir alertas

Administrador

(from Actors)

Cliente

(from Actors)

Gestor de energia

(from Actors)

Ver alertas

disparados

Verificar alertas

Sistema

Env iar email com o

estado do alerta

«include»

uc Cálculo de tarifário


Gerir tarifários

Gestor de energia

(from Actors)

Consultar tarifários

Cliente

(from Actors)

Criar nov as v ersões

Cálcular tarifários

Sistema

Ver Simulação de

tarifários

Cálcular simulação

de tarifários

«extend»

«include»

Casos de Uso

7

Imagem 8 - Casos de uso para gestão de actuação

uc Gestão de actuação


Gerir actuação

Verificar actuação

Actuar sobre o

despositiv o

Gestor de energia

(from Actors)

Sistema

«include»

iEnergy – Eficiência Energética em Edifícios Anexo III – Plano de Risco

Anexo III – Plano de Riscos

iEnergy – Eficiência Energética em Edifícios Anexo III – Plano de Risco

1

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 Estratégia de contingência

A carga a que o sistema vai ser sujeita. Testes iniciais com uma base de dados de

produção de forma a perceber como pode ser

optimizado o sistema.

Esperar demasiado da plataforma pode

levar a alguns mal entendidos entre o que a

plataforma já é vs. Aquilo que é esperado

da plataforma

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.

Pouca experiencia nas tecnologias usadas

para a implementação.

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.

iEnergy – Eficiência Energética em Edifícios Anexo IV – Especificação do Web Service

Anexo IV – Web Service de edifícios

Especificação do Web Service

Mai. 2011

Especificação Web Service

Índice

ANEXO IV – WEB SERVICE DE EDIFÍCIOS .......................................................................................... 1

1 INTRODUÇÃO ........................................................................................................................... 1

2 ESTRUTURAS DE DADOS ........................................................................................................... 2

2.1 RESULTADO DE UMA OPERAÇÃO ................................................................................................... 2

2.2 INDICADOR ............................................................................................................................... 2

2.3 GRUPO .................................................................................................................................... 3

2.4 DETALHES DE GRUPO ................................................................................................................. 3

2.5 TIPO DE GRUPO......................................................................................................................... 3

2.6 COLUNAS DE UM TIPO DE GRUPO ................................................................................................. 3

2.7 VALORES DAS COLUNAS DE UM TIPO DE GRUPO .............................................................................. 4

2.8 TIPO DE HÓRARIO DE GRUPO ....................................................................................................... 4

2.9 HÓRARIO DE GRUPO .................................................................................................................. 4

2.10 TAG ........................................................................................................................................ 4

2.11 PARÂMETRO DA VIRTUAL TAG ...................................................................................................... 5

2.12 TARIFA .................................................................................................................................... 5

2.13 PARÂMETRO DE TARIFÁRIO .......................................................................................................... 5

2.14 CUSTOS FIXOS ........................................................................................................................... 5

2.15 INTERVALO ............................................................................................................................... 6

2.16 FACTOR DE MULTIPLICAÇÃO ........................................................................................................ 6

2.17 TEMPORADA ............................................................................................................................. 6

2.18 SIMULAÇÃO DE TARIFA ................................................................................................................ 6

2.19 LINHA DE SIMULAÇÃO DE TARIFA .................................................................................................. 7

2.20 UNIDADE DE MEDIDA.................................................................................................................. 7

2.21 CONVERSÃO DE MEDIDA ............................................................................................................. 7

2.22 ALERTA .................................................................................................................................... 7

2.23 PARÂMETRO DO ALERTA.............................................................................................................. 8

2.24 ALERTA DISPARADO .................................................................................................................... 8

2.25 ACTUAÇÃO ............................................................................................................................... 8

2.26 BASELINE ................................................................................................................................. 9

2.27 VALORES DA BASELINE ................................................................................................................ 9

2.28 UTENSÍLIOS DA BASELINE ............................................................................................................. 9

3 MÉTODOS .............................................................................................................................. 10

3.1 ACESSO A DADOS ..................................................................................................................... 10

3.2 GRUPOS ................................................................................................................................ 11

3.3 UNIDADES DE MEDIDA .............................................................................................................. 14

3.4 TARIFAS ................................................................................................................................. 15

3.5 ALERTS .................................................................................................................................. 16

3.6 MESSAGES ............................................................................................................................. 18

3.7 BASELINE ............................................................................................................................... 19

3.8 RELATÓRIOS ........................................................................................................................... 19

3.9 ACTUAÇÃO ............................................................................................................................. 20


Web Service de Edíficios 1 1

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).


2 Web Service de Edíficios

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 A operação teve sucesso.

UnexpectedError Erro durante a execução.

InvalidUser Utilizador inválido.

Token errado ou expirado.

Acesso não autorizado a este método.

InvalidParameter Parâmetro inválido.

NoData Não existem dados para a operação desejada.

UnAuthorized O utilizador não tem as permissões necessárias para a operação

desejada.

ImpossibleConversion 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; }



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; }

}



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



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 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


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; }

}



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


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



{ 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; }



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; }



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


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


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; }

}



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


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


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; }

}



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);



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.



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);




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:



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);




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);




GroupId In Group id.



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);




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:


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);




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:


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);




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);






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);




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.




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);




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);




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);




Groups out Lista de grupos.



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);





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);





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);





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:


Descrição

InvalidUser Token errado.

Token expirado.

Acesso não autorizado ao método.

Success Operação com sucesso.

UnexpectedError 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);



Uma conversão representa o factor pelo qual a unidade deve ser multiplicada para obter uma

outra unidade.




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



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);




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);




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);




TagId In Id da tag.



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);




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);




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);




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);




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);






Alerts Out Lista de alertas configurados no sistema.

O método seguinte permite adicionar novos alertas ao sistema.

ResultCode AddAlert (string token, Alert alert);




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)




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);




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);




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);






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);




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);



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);





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);





GroupId In Id d grupo.

Message Out Lista de mensagens.

O método seguinte permite que sejam listadas mensagens por um certa condição:



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);




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);




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);





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);





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);







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);




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);




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);




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);




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);

Anexo V – Especificação da Base de Dados

Modelo de dados

Abril. 2011

Especificação da base de dados

Índice

1 INTRODUÇÃO ........................................................................................................................................... 1

2 TABELAS DE ALERTAS ............................................................................................................................... 2

2.1 ALERT....................................................................................................................................................... 2

2.2 ALERT_PARAMETER .................................................................................................................................... 2

2.3 ALERT_TRIGGER ......................................................................................................................................... 3

2.4 ALERT_TRIGGER_PARAMETER ...................................................................................................................... 3

3 TABELAS DE ACTUAÇÃO ........................................................................................................................... 5

3.1 ACTION .................................................................................................................................................... 5

4 TABELAS BASELINE ................................................................................................................................... 6

4.1 BASELINE .................................................................................................................................................. 6

4.2 BASELINE_VALUES ...................................................................................................................................... 6

4.3 BASELINE_APPLIANCE ................................................................................................................................. 7

5 TABELAS GRUPOS ..................................................................................................................................... 9

5.1 HIERARCHY ................................................................................................................................................ 9

5.2 INDICADOR ................................................................................................................................................ 9

5.3 GROUP ..................................................................................................................................................... 9

5.4 GROUP_TYPE .......................................................................................................................................... 10

5.5 GROUP_COLUMNS ................................................................................................................................... 10

5.6 GROUP_COLUMNS_VALUES ....................................................................................................................... 10

5.7 GROUP_SCHEDULE ................................................................................................................................... 11

5.8 GROUP_DETAILS ...................................................................................................................................... 11

5.9 GROUP_TAG ........................................................................................................................................... 11

5.10 GROUP_USER .......................................................................................................................................... 12

6 TABELAS TARIFÁRIOS ............................................................................................................................. 14

6.1 TARIFF .................................................................................................................................................... 14

6.2 TARIFF_PARAMETER ................................................................................................................................. 14

6.3 MULTIPLICATION_FACTOR ......................................................................................................................... 15

6.4 SEASON .................................................................................................................................................. 15

6.5 SEASON_SERIES ....................................................................................................................................... 16

6.6 INTEVAL .................................................................................................................................................. 16

6.7 FIXED_COSTS........................................................................................................................................... 16

7 TABELAS KPI’S ........................................................................................................................................ 18

7.1 KPI ........................................................................................................................................................ 18

7.2 KPI_DATA ............................................................................................................................................. 18

7.3 KPI_MESSAGE ...................................................................................................................................... 19

7.4 KPI_CONF ............................................................................................................................................. 20

7.5 KPI_ERROR_LOG .................................................................................................................................. 20


Especificação da base de dados 1

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.


2 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.


ap_id int Chave primaria.

ap_name int Nome do parâmetro.



ap_value decimal Valor associado ao parâmetro.

ap_value_string string String associada ao parâmetro.

Dependencies

Dependent Tables alert


2.3 Alert_Trigger Entidade que representa um parâmetro do alerta que foi disparado.


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 smallint Prioridade(Depende do plugin que

implementa)

alr_id int Chave estrangeira que referencia o

alerta.

at_mail string Emails para onde foi enviado o

alerta.

Dependencies

Dependent Tables alert


2.4 Alert_Trigger_Parameter Entidade que representa um parâmetro do alerta que fez disparar um determinado alerta.


atp_id int Chave primaria.

atp_name datetime Nome do parâmetro que fez

disparar o alerta.

atp_value bit Valor decimal que fez disparar o

alerta.



atp_string_value smallint String que representa um

parâmetro do alerta.

at_id int Chave estrangeira que referencia o

alerta_trigger.

Dependencies

Dependent Tables Alert_trigger


alertalr_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_parameterap_id

ap_name

ap_value

alr_id

ap_value_string

alert_triggerat_id

at_date

at_checked

at_priority

alr_id

at_email

alert_trigger_parameteratp_id

atp_name

atp_value

atp_string_value

at_id



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.


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 bit Bit que diz em que dias da semana

a actuação deve ser feita.

act_hour timestamp 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


Figura 1 – Diagrama ER relativo a actuação

actionact_id

uni_id

tag_id

act_weekday

act_hour

act_action

act_next



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.


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

timestamp

Hora de início de funcionamento

do AVAC.

avac_stop_time

timestamp Hora em que o AVAC é desligado.

bl_calculated bit Diz se a baseline já foi ou não

calculada.

Dependencies group

Dependent Tables


4.2 Baseline_Values A tabela baseline_values irá conter os valores para cada uma das baselines do sistema. Tabela

interna de sistema.




bv_id int Chave primaria.

bv_date datetime Data a que o valor diz respeito.

bv_ae_rush decimal(15, 5) Valor de consumo em horas de

ponta.

bv_ae_full decimal(15, 5) Valor de consumo em horas de

cheira.

bv_ae_empty decimal(15, 5) Valor de consumo em horas de

vazio normal.

bv_ae_superempty decimal(15, 5) Valor de consumo em horas de

super vazio.

bl_id int Id da baseline.

Dependencies baseline

Dependent Tables


4.3 Baseline_Appliance A tabela Baseline_Appliance irá conter os electrodomésticos configurados para cada baseline.


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




Figura 2 - Diagrama ER relativo a baseline

baselinebl_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_applianceap_id

ap_name

ap_power

ap_start

ap_end

bl_id

dttt_index

baseline_valuebv_id

bv_date

bv_ae_rush

bv_ae_full

bv_ae_empty

bv_ae_superempty

bl_id



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.


h_parent int

Chave estrangeira que referencia

(pai) group

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 group

Dependent Tables


5.2 Indicador Entidade relacionar que armazena indicadores.


ind_id int Chave primaria

ind_operation nchar(3)

String que representa a operação

(sum, sub, avg …)

ind_field nvarchar(50)

String que representa o nome do

group_details ou dos local_details

(dependendo da flag isgroup)

ind_name nvarchar(50) Nome do indicador.

ind_constant decimal(15,5)

Valor constante que pode ser usado

no indicador

ind_isgroup bit

Flag que indica que o indicador vai

usar para cálculo o group_details ou

local_details

Dependencies

Dependent Tables group_indicator


5.3 Group Entidade que armazena todas as instâncias de um grupo.




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 local

Dependent Tables group_tag, group_user, hierarchy, user


5.4 Group_Type Entidade que armazena todas as instâncias de um tipo de grupo.


gt_id int Chave primária.

gt_name nvarchar(20) Nome do tipo de grupo.

Dependencies group

Dependent Tables


5.5 Group_Columns Entidade que armazena todas as instâncias dos parâmetros de um tipo de grupo.


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 group_type

Dependent Tables


5.6 Group_Columns_Values Entidade que armazena todas as instâncias dos valores associados aos tipos de grupo.


gtc_id int Chave primária.



gtc_value nvarchar(20) Valor do parâmetro.

gt_id int


tipo de grupo.

g_id int


grupo.

Dependencies Group, group_type

Dependent Tables


5.7 Group_Schedule Entidade que armazena todas as instâncias de um hórario de um grupo.


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 group

Dependent Tables


5.8 Group_Details Entidade que armazena detalhes do grupo que são usados no cálculo de indicadores.


g_id int

Chave estrangeira que referencia um

grupo.

gd_name nvarchar(20) Nome do detalhe.

gd_value Decimal(15,3) Valor do detalhe

Dependencies group

Dependent Tables


5.9 Group_Tag Entidade relacional que armazena todas as tags que pertencem a um certo grupo.


g_id int


grupo.

tag_id int


tag



Dependencies tag, group

Dependent Tables


5.10 Group_Indicator Entidade relacional que armazena todas os indicadores que pertencem a um certo grupo.


g_id int


grupo.

tag_id int


tag

Ind_id int


indicador

Dependencies tag, group, indicator

Dependent Tables


5.11 Group_User Entidade relacional que armazena todos os utilizadores que tem acesso a um certo grupo.


g_id int


o grupo.

usr_id int


o utilizador

Dependencies tag, user

Dependent Tables




Figura 3 - Diagrama ER relativo aos grupos

groupg_id

g_name

g_description

g_deleted

g_private

gt_id

group_columnsgc_id

gc_name

gt_id

dttt_index

group_columns_valuesgtc_id

gtc_value

g_id

gc_id

group_detailsg_id

gd_name

gd_value

group_indicatorind_id

g_id

tag_id

gi_id

group_schedulesh_id

s_id

weekday

start_hour

end_hour

group_schedule_typesh_id

sh_name

g_id

group_tag

g_id

tag_id

group_type

gt_id

gt_name

group_types_values

g_id

gt_id

group_user

g_id

usr_id

hierarchyh_parent

h_group

h_level

h_references

g_private

indicatorind_id

ind_operation

ind_field

ind_name

ind_constant

ind_isgroup



6 Tabelas Tarifários Secção corresponde as tabelas dos tarifários.

6.1 Tariff Esta entidade armazena dados relativos aos tarifários.


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

tar_end smalldatetime

Data que indica quando a tarifária

deixa de estar activo.

sse_id int

Chave estrangeira que referencia a

tabela season_series

tar_tariff_identification int

Número que identifica as diferentes

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 supplier

Dependent Tables 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.


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.



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


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.


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) Valor mínimo para activar o

factor.

mf_max Decimal(15,5) 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


6.4 Season Entidade que armazena o inicio e o fim que cada temporada.


s_begindate smalldatetime Data de início da temporada

s_enddate smalldatetime Data de fim da temporada

s_id int Chave primária



s_deleted bit Flag se a temporada foi apagada

sse_id int

Chave estrangeira para a

season_series

s_season tinyint

Indice da temporada. (e.x. 1, 2, …)

Onde 1=1st trimestre

2= 2nd

trimestre

3=3rd

trimestre

Dependencies season_series

Dependent Tables


6.5 Season_Series Entidade que armazena os tipos de temporadas que podem ser usadas nos tarifários.


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 tariff

Dependent Tables


6.6 Inteval Entidade que armazena os intervalos de facturação de um tarifário.


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

tar_id int


tarifa.

h_type tinyint Tipo de hora.

Dependencies tariff

Dependent Tables


6.7 Fixed_Costs

Entidade que armazena os custos fixos associados a um tarifário.




fxc_id int Chave primária

fxc_description nvarchar(50) Descrição do custo fixo

fxc_price smallmoney Valor do custo

tar_id int


tarifa

Dependencies tariff

Dependent Tables


Figura 4 - Diagrama ER relativo aos tarifários

multiplication_factormf_id

mf_name

mf_min

mf_max

mf_factor

tp_id

seasons_season

s_begindate

s_enddate

s_id

sse_id

season_seriessse_id

sse_type

sse_number_seasons

tarifftar_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

tariff_parametertp_id

tp_type

tar_id

tp_price

tp_period

tp_name

p_id

tariff_parameter_seasontp_id

s_season

tps_id

intervalint_id

int_start

int_end

s_season

int_weekday

tar_id

int_typefixed_cost

fxc_id

fxc_description

fxc_price

tar_id

contracted_power



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.


kpi_id int Chave primária.

kpi_name nvarchar(100) Nome do KPI.

kpi_description nvarchar(4000) Descrição do KPI.

kpi_type nchar(10)

Tipo de KPI, valores possíveis:

Hourly, Daily, Weekly, Monthly,

Yearly

mu_id tinyint 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 2005-01-01 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


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.


kpi_id int Chave estrangeira que referência

o KPI.



kpid_value decimal(15, 5) Valor do KPI.

kpid_current_value decimal(15, 5) Valor current lido para calcular o

KPI (kpid_value).

kpid_reference_value decimal(15, 5)

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 int ID da tag a qual o KPI esta

associado.

unt_id int ID da unidade a qual o KPI esta

associado.

kpid_branch_code nvarchar(50) Código do grupo ao qual a

mensagem esta associada.

kpid_branch_name nvarchar(50) Nome do grupo ao qual a


Dependencies KPI

Dependent Tables


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.


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




kpim_branch_name nvarchar(50) Nome do grupo ao qual a


Dependencies

Dependent Tables


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.


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


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.


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.



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


Figura 5 - Diagrama ER relativo aos KPI

iEnergy – Eficiência Energética em Edifícios Anexo VI – Fase de Integração

Anexo VI – Requisitos Fase de Integração


Especificação de requisitos 1

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 Deve ser possível seleccionar o ficheiro a importar.

RFA03 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

RFA04 Após seleccionar o ficheiro para importar, caso existam erros, deve aparecer um

menu intermédio apresentando os mesmos.

RFA05 Caso existam erros, deve inserir os registos possíveis, indicando os registos que

apresentam erros.

RFA06 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

RFA07 Se a associação a introduzir já existir no sistema, deve sobrepor à existente,

actualizando o portal.

RFA08 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.


RFBL01 Serviço deve processar ficheiros de bilhética.

RFBL02 Para cada viagem existente no ficheiro, o serviço deve verificar se essa viagem

já existe no sistema.

RFBL03 Caso uma viagem não exista no sistema, esta deve ser inserida. Os dados

Anexo VI – Fase de Integração iEnergy – Eficiência Energética em Edifícios

2 Especificação de requisitos

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="2010-10-21">

<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.


RFAL01 Na página inicial, deve ser apresentada uma mensagem indicando o número de

alarmes “Por processar”.

RFAL02 Deverá existir um link na mensagem por forma a redireccionar para o módulo

“Operações -> Gestão de Alarmes”.

RFAL03 Na página inicial, deverá ser apresentada uma tabela com os alarmes “Por

processar”.

RFAL04 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.

RFAL05 As colunas da tabela de alarmes “Por processar” são:

o Data/Hora

o Embarcação

o Mensagem

o Estado

RFAL06 No módulo “Operações -> Gestão de Alarmes” deve ser possível pesquisar

alarmes.

RFAL07 A pesquisa deve permitir filtragem por:

o Data



o Embarcação

o Estado

RFAL08 Possibilidade de visualizar os alarmes resultantes da pesquisa através de uma

tabela.

RFAL09 As colunas a apresentar na tabela são:

o Data/Hora

o Embarcação

o Mensagem

o Estado

RFAL10 A tabela de alarmes deve ter paginação.

RFAL11 Deve ser possível editar o estado do alarme.

RFAL12 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

o Velocidade instantânea superior a 2 nós (ou outro valor a definir)

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.


RFMA01 O serviço de recolha de dados tem de distinguir entre os diferentes tipos de

alarme

RFMA02 O serviço de recolha tem de identificar se o alarme já ocorreu e/ou o seu estado.

RFMA03 O serviço de bilhética tem de gerar alarmes.

Notas



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 12000 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.


REDG01 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.

REDG02 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.

REDG03 Na página de relatórios anuais deverá ser possível seleccionar o ano para o qual

se pretende criar um novo relatório.

REDG04 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

REDG05 Deve ser possível pré-visualizar o relatório na página.

REDG06 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. 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) (Registos) – Soma dos consumos de uma embarcação dos registos de consumos inseridos;


Distância/Carreira – Distância media percorrida por viagem do tipo carreira;



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));




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.


RUE01 Deverá existir no portal uma página dedicada a criação de relatórios sobre o uso

de uma embarcação.

RUE02 Na página do relatório mensal deverá ser possível seleccionar uma data inicial e

final para criação do relatório.

RUE03 Na página do relatório mensal deverá ser possível seleccionar a embarcação

para criar o relatório.

RUE04 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.



RUE05 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.

REDG06 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.

REDG07 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.

REDG08 Deve ser possível pré-visualizar o relatório na página.

REDG09 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



dos registos de consumos inseridos;


Consumo Total (L) (Registos) – Soma dos consumos de uma embarcação através dos dados inseridos;


Distância/Carreira – Distância média percorrida por viagem do tipo carreira.



Motores/Carreira (%) – Percentagem de utilização dos motores em viagens 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


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.



A fórmula usada para calcular o desvio padrão é a seguinte:

k

i

iik

i i

fxxf

S1

2

1

))((1



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.


RCAG01 Deverá existir no portal uma página dedicada a criação de relatórios sobre o uso

de uma embarcação.

RCAG02 Na página do relatório deverá ser possível seleccionar uma data inicial e final

para criação do relatório.

RCAG03 Na página do relatório deverá ser possível seleccionar a área geográfica.

RCAG04 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

RCAG5 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.

RCAG6 Deve ser possível pré-visualizar o relatório na página.

RCAG7 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.



A fórmula usada para calcular o desvio padrão é a seguinte:

k

i

iik

i i

fxxf

S1

2

1

))((1

iEnergy – Eficiência Energética em Edifícios Anexo VII – Manual de Utilizador

Anexo VII – Manual de Utilizador

Manual de utilizador

Jul. 2011

Manual de Utilizador

Índice

1 INTRODUÇÃO ........................................................................................................................... 1

1.1 ÍCONES DA APLICAÇÃO ......................................................................................................... 2

2 VISUALIZAÇÃO ........................................................................................................................ 2

2.1 ÁRVORE DE AGÊNCIAS E EDIFÍCIOS ...................................................................................... 3

2.2 CAMPOS DE FILTRAGEM ....................................................................................................... 4

2.2.1 Calendário .................................................................................................................. 4

2.2.2 Intervalo de Datas ...................................................................................................... 5

2.2.3 Granularidade ............................................................................................................ 5

2.2.4 Tipos de Hora ............................................................................................................. 5

2.2.5 Horas .......................................................................................................................... 5

2.2.6 Intervalos .................................................................................................................... 5

2.2.7 Opções de Visualização .............................................................................................. 6

2.2.8 Operações ................................................................................................................... 7

2.3 VISUALIZAÇÃO DO GRÁFICO (E TABELAS DE DADOS) ........................................................... 7

2.3.1 Gráfico ....................................................................................................................... 7

2.3.2 Tabela Geral............................................................................................................... 7

2.3.3 Tabela De Conclusões ................................................................................................ 8

2.3.4 Análise de Custos ....................................................................................................... 9

3 MENSAGENS .............................................................................................................................. 9

4 SIMULAÇÃO ............................................................................................................................ 11

4.1 RESULTADOS ...................................................................................................................... 12

5 RELATÓRIOS .......................................................................................................................... 13

5.1 SECÇÃO DE ENERGIA ACTIVA ............................................................................................. 14

5.2 SECÇÃO DE ENERGIA REACTIVA ......................................................................................... 15

5.3 SECÇÃO DE FACTOR DE POTÊNCIA ...................................................................................... 16

5.4 SECÇÃO DE ANÁLISE DE POTÊNCIA .................................................................................... 17

5.5 SECÇÃO DE INDICADORES DE ESTADO ................................................................................ 18

5.6 SECÇÃO DE INDICADORES DE POUPANÇA ........................................................................... 18

5.7 POUPANÇA DE ENERGIA ACTIVA ........................................................................................ 18

5.8 POUPANÇA DE DINHEIRO .................................................................................................... 18

5.9 POUPANÇA DE EMISSÕES .................................................................................................... 19

6 OPERAÇÕES DE BACK OFFICE ......................................................................................... 19

6.1 ALERTAS ............................................................................................................................ 19

6.2 TIPOS DE GRUPOS ............................................................................................................... 20

6.2.1 Listar ........................................................................................................................ 20

6.2.2 Detalhes .................................................................................................................... 20

6.2.3 Editar ........................................................................................................................ 21

6.2.4 Adicionar Tipo de Grupo .......................................................................................... 22

6.3 GRUPOS .............................................................................................................................. 22

6.3.1 Listar ........................................................................................................................ 22

6.3.2 Detalhes .................................................................................................................... 23

6.3.3 Adicionar Grupo ....................................................................................................... 24

6.3.4 Alertas ...................................................................................................................... 32

6.4 FACTURAÇÃO ...................................................................................................................... 34

6.4.1 Fornecedores ............................................................................................................. 34

6.4.2 Tarifas ....................................................................................................................... 36

6.5 ESTAÇÕES ............................................................................................................................ 45

7 PLUGINS ALERTAS ................................................................................................................ 47

7.1 LISTAGEM ............................................................................................................................ 47

7.2 EDITAR ................................................................................................................................ 48

7.3 ADIÇÃO ............................................................................................................................... 49


Manual de Utilizador 1

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.


2 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:



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:



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.

2.2.1 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):



Imagem 5 - Calendário

Nota: Por definição, no calendário, está seleccionado o dia anterior ao dia actual.

2.2.2 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

2.2.3 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).

Imagem 7 – Granularidade

2.2.4 Tipos de Hora

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.

2.2.5 Horas

Os campos Hora Início e Hora Final permitem filtrar os dados do gráfico pelo intervalo definido entre as mesmas

(Imagem 9).

Imagem 9 – Horas

2.2.6 Intervalos

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):



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.

2.2.7 Opções de Visualização

São ainda possibilitadas outras opções de configuração da visualização do gráfico a ser gerado.

Imagem 11 - Opções de Visualização

As opções (Imagem 11) são as seguintes:

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);



Tipo de Gráfico - Existem três possibilidades de escolha:

o Linhas - Gráfico gerado com linhas;

o Barras - Gráfico gerado com barras;

o Stacked Bars - Gráfico gerado com barras cumulativas.

2.2.8 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.

2.3.1 Gráfico

A secção Gráfico apresenta o gráfico gerado:

Imagem 12 - Gráfico

Esta secção permite ver a seguinte informação:

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).

2.3.2 Tabela Geral

A secção Tabela Geral permite visualizar a informação detalhada dos dados obtidos e representados no gráfico:



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.

2.3.3 Tabela De Conclusões

A secção Tabela de Conclusões permite visualizar a informação estatística dos dados obtidos e representados no

gráfico:

Imagem 14 - Tabela de Conclusões

As informações apresentadas são:

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.

1.



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.

2.3.4 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:



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:



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:



Imagem 21 - Janela de simulações

Para fazer uma simulação o utilizador tem que:

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:



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.

Caso o utilizador pretenda exportar os resultados da simulação para um ficheiro excel basta clicar no link Exportar

Dados.

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:



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.



Imagem 24 - Energia Activa

Os valores apresentados na tabela de dados incluem:

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.



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.



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.

Imagem 27 - Análise de Potência


Potência Tomada (Tipo de Hora):

o Média;

o Desvio Padrão;

o Máximo;

o Mínimo;

o Total;

o Frequência.

Potência Contratada:



o Média;

o Desvio Padrão;

o Máximo;

o Mínimo;

o Total;

o 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 à


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 à


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.



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



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 Email 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

Os Tipos de Grupos permitem ao utilizador estabelecer parâmetros partilhados entre várias Unidades, Dispositivos

e TAGs.

6.2.1 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.

Imagem 34 - Listagem de Tipos de Grupos

6.2.2 Detalhes

Ao clicar sobre o nome de um Tipo de Grupo da listagem, o utilizador é redireccionado para a página de detalhes

do registo escolhido.



Imagem 35 - Ecrã de detalhes do Tipo de Grupo

Na zona superior é possível encontrar ainda as seguintes acções:

6.2.2.1 Listar

Esta acção remete o utilizador para a listagem de Tipos de Grupo.

6.2.2.2 Editar

Esta acção dá acesso aos detalhes do Tipo de Grupo em modo de edição.

6.2.3 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.



6.2.4 Adicionar Tipo de Grupo

A próxima imagem apresenta o ecrã de adição de Tipo de Grupo.

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

seguir:

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.

6.3.1 Listar

Ao aceder a esta página o utilizador tem acesso à listagem de registos tal como na imagem seguinte.



Imagem 38 - Listagem de Grupos

6.3.2 Detalhes

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:

6.3.2.1 Listar

Esta acção permite voltar à listagem de Grupos inicial.

6.3.2.2 Virtual Tags

Esta acção disponibiliza a lista de Tags Virtuais associadas a este Grupo.

6.3.2.3 Indicadores

Esta acção disponibiliza a lista de Indicadores associadas a este Grupo.



6.3.2.4 Alertas

Esta acção disponibiliza a lista de Alertas associados a este Grupo.

6.3.2.5 Alertas Disparados

Esta acção disponibiliza a lista de Alertas Disparados associadas a este Grupo.

6.3.3 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



6.3.3.1 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 Limpa últimos – limpa o último dado da fórmula;

o 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.

6.3.3.2 Criar Indicador

Esta opção disponibiliza ao utilizador o ecrã de criação da Indicador como se demonstra a seguir.



Imagem 43 - Criar Indicador


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 Limpar Tudo – limpa todos os dados da fórmula;

o Limpa últimos – limpa o último dado da fórmula;

o 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. 6.3.3.11).

Ao clicar no botão Guardar é criado um novo indicador, no botão Re-iniciar o formulário e limpo.

6.3.3.3 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



activa a opção principal o grupo passa a ser considerado como grupo principal e tem obrigatoriamente que ter um

sub-grupo geral.

6.3.3.4 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.

6.3.3.5 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.

6.3.3.6 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.

6.3.3.7 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.

6.3.3.8 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.



Imagem 46 - Editar Grupo

6.3.3.9 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.

6.3.3.10 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 Potência Nominal (kw) – potência do AVAC em Kw

o Hora Inicio - Hora em que o AVAC entrou em funcionamento

o 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 Potência Nominal (Kw) – Potência do Equipamento em Kw

o Inicio - Hora em que o Equipamento entrou em funcionamento

o Fim – Hora em que o Equipamento finalizou o funcionamento



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.



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 Potência Nominal (kw) – potência do AVAC em Kw;

o Hora Inicio - Hora em que o AVAC entrou em funcionamento;

o 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 Potencia Nominal (Kw) – Potência do Equipamento em KW;

o Inicio - Hora em que o Equipamento entrou em funcionamento;

o 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).



Imagem 51 - Edição de Baseline Ano 1

6.3.3.11 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

6.3.3.12 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



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.

6.3.3.13 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.

6.3.4 Alertas

Para realizar a gestão dos alertas o utilizador deve clicar no link Plugin de Alertas no menu da aplicação.

6.3.4.1 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.

6.3.4.2 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.



Imagem 55 - Edição de Alerta

6.3.4.3 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



6.4 Facturação

6.4.1 Fornecedores

6.4.1.1 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



6.4.1.2 Apagar fornecedores

( ) Na lista de fornecedores o utilizador pode clicar no ícone de apagar para remover um fornecedor.

6.4.1.3 Editar fornecedores

( ) Na lista de fornecedores o utilizador pode clicar no ícone de editar para ter acesso ao painel de edição do

fornecedor.

6.4.1.4 Adicionar Fornecedor

Este botão dá acesso ao formulário de adicionar fornecedor

6.4.1.5 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.



Listagem

Este botão dá acesso a lista de fornecedores.

6.4.1.6 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.

6.4.1.7 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.

6.4.2 Tarifas

6.4.2.1 Listar

Depois de clicar no link de administração o painel da Imagem 61 é mostrado.



Imagem 61 - Listagem de Tarifas

6.4.2.2 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


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.



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.



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


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.



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


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 ( ) sendo mostrado a formulário de factores de multiplicação como

mostra a Imagem 70.



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

6.4.2.3 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.



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.

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

escalão.



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.

Imagem 75 - Detalhe de Tarifa por Escalão

Note que os avisos sobre os escalões desapareceram.

6.4.2.4 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.



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. 3000-247). 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 3000.

Imagem 78 - Pesquisa por código postal



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

6.5.1.1 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.

6.5.1.1.1 Apagar Estação

( ) Na lista de estações o utilizador pode clicar no ícone de apagar para remover uma estação.

6.5.1.1.2 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.

6.5.1.1.3 Adicionar Estação

Este botão dá acesso ao formulário de adição de estação

6.5.1.2 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.



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:

6.5.1.2.1 Editar

Este botão dá acesso ao formulário de edição de estação.

6.5.1.2.2 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.

6.5.1.2.3 Listagem

Este botão dá acesso à listagem de estações.

6.5.1.3 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.



6.5.1.4 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



7.1.1.1 Adicionar PLugin

Se o utilizador desejar adicionar um novo plugin ele pode fazê-lo premindo o botão Adicionar Plugin.

7.1.1.2 Detalhes

Neste painel Imagem 84 o utilizador pode validar os dados do plugin e consultar a listagem de alertas ou

validações associados a esse plugin.

Imagem 84 - Detalhe de Plugin

7.2 Editar

O link permite editar os campos do plugin

7.2.1.1 Adicionar Alerta/Validação

Dependo do tipo de plugin este link permite criar um alerta\validação automaticamente associado ao plugin.

7.2.1.2 Edição

Depois de alterar as informações do painel de edição Imagem 85 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.

Imagem 85 - Edição do Plugin



7.3 Adição

Neste painel Imagem 86 o utilizador pode definir as informações para a criação de um plugin. Os campos são:

Nome - Nome do plugin;

Peso - peso do plugin;

Nome da Classe – nome da classe da Dll usada pelo plugin.

Imagem 86 - Adição do Plugin