Coimbra, Dezembro, 2011
Instituto Politécnico de Coimbra
Instituto Superior de Engenharia de Coimbra
Departamento de Engenharia Informática e de Sistemas
Mestrado em Informática e Sistemas
Estágio Industrial/Projecto Industrial
Relatório Final
iEnergy - Eficiência Energética em
Edifícios
Pedro Rafael Pimenta Saraiva
[email protected]
Orientador da ISA
Eng.º. Ricardo Clérigo
[email protected]
Orientador do ISEC
Doutor Viriato António Pereira Marinho Marques
[email protected]
iEnergy – Eficiência Energética em Edifícios
Resumo
RESUMO
O presente relatório tem por objectivo apresentar e descrever de forma detalhada o projecto
“iEnergy – Eficiência Energética em Edifícios”, realizado no âmbito do estágio curricular, do Mestrado
em Informática e Sistemas - Ramo de Desenvolvimento de Software , do Instituto Superior de
Engenharia de Coimbra. Este estágio decorreu nas instalações da empresa ISA - Intelligent Sensing
Anywhere de 22 de Novembro de 2010 a 31 de Julho de 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.
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
i
iEnergy – Eficiência Energética em Edifícios
Abstract
ABSTRACT
This report aims to present and describe in detail the project "iEnergy - Energy Efficiency in
Buildings", performed under the curricular internship of the MSc in Informatics and Systems Software Development branch-, of the “Instituto Superior de Engenharia de Coimbra”. This internship
took place at ISA - Intelligent Sensing Anywhere, from 22 November 2010 to July31, 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.
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iii
iEnergy – Eficiência Energética em Edifícios
Palavras-Chave
Palavras-Chave
Engenharia
Informática
Gestão de Energia
iEnergy
ISA- Intelligent Sensing Anywhere
.NET Framework
SCRUM
MVC
Eficiência Energética
Keywords
Engineering
Informatics
Energy management
iEnergy
ISA- Intelligent Sensing Anywhere
.NET Framework
SCRUM
MVC
Energy Efficiency
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
v
iEnergy – Eficiência Energética em Edifícios
Símbolos e Abreviaturas
Lista de Abreviaturas e Acrónimos
API – Application programming interface
ASP – Active Server Pages
ASP .NET -Active Server Pages .NET
AVAC – Aquecimento, ventilação e ar condicionado
ACE - Requisitos análise de custos de energia
ALM – Requisitos de alarmes
BU – Unidade de negócio
BD – Base de Dados
CRUD - Create, Read, Update and Delete
CA – Requisitos conclusões da analise
COD – Requisitos de configuração de opções de aquisição de dados
CTAR – Requisitos para calculo e criação de tarifários
BI - Business Intelligent
B2B - Bussines to Bussines
B2C - Bussines to Consumer
C# - CSharp
CPU- Central Processing Unit
CSAD – Controlo de supervisão e aquisição de dados
COD - Configuração de opções de aquisição de dados da BD
CSS - Cascading Style Sheets
DLL - Dynamic link library
EDP - Electricidade de Portugal
EF - Entity Framework
FTP - File Transfer Protocol
FK – Foreign Key
GPL – General Public License
GPRS - General packet radio service
GPS - Global Positioning System
GUI - Graphical User Interface
HTML – HyperText Markup Language
HTTP – Hypertext Transfer Protocol
IEEE – Institute of Electrical and Electronics Engineers
IP – Internet Protocol
I&D – Investigação e Desenvolvimento
ISA – Intelligent Sensing Anywhere
ISEC – Instituto Superior de Engenharia de Coimbra
ISO – International Organization for Standardization
IDE - Integrated Development Environment
JSON – JavaScript Object Notation
kW – Kilowatt
kWh– Kilowatt hora
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
vii
Símbolos e Abreviaturas
iEnergy – Eficiência Energética em Edifícios
kB - Kilobyte
kVar - Kilovolt-amperes reactive
KPI – Key Performance Indicators
M9M – Monday 9’oclock Meeting
M2M – Machine to Machine Communication
MA – Requisitos do modulo de actuação
MVC- Model-view-controller
ORM - Object Relational Mapping
PDF – Portable Document Format
PK – Primary Key
REL- Requisitos de Relatórios
RFID- Radio Frequency Identification
SGBD – Sistema de Gestão de Base de dados
SNMP – Simple Network Management Protocol
SOAP – Simple Object Access Protocol
SQL – Structured Query Language
SEO - Search engine optimization
SVN - Subversion
STAR – Requisitos para simulação de tarifários
TDD - Test-driven development
TCP – Transmission Control Protocol
T-SQL – Transact-Structured Query Language
TG - Requisitos de tabela geral
TI - Tecnologia da informação
TARIFA MT - Tarifa Média Tensão
URE- Utilização Racional de Energia
UDP - User Datagram Protocol
UML – Unified Modeling Language
UI – User Interface
URL - Uniform Resource Locator
XML – Extended Markup Language
WCF- Windows Communication Foundation
WSDL – Web Services Description Language
WWW - World Wide Web
VAG- Requisitos de visualização de dados na forma de gráfico
viii
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Agradecimentos
Agradecimentos
Ao Professor Doutor Viriato António Pereira Marinho Marques pela competência com que
orientou esta minha tese e o tempo que generosamente me dedicou transmitindo-me os melhores e
mais úteis ensinamentos, com paciência, lucidez e confiança. Pelo acesso que me facilitou a uma
pesquisa mais alargada e enriquecedora e pela sua crítica sempre tão atempada, como construtiva.
A minha família e aos meus amigos, que me deram força desde o primeiro momento e sempre me
desejaram a maior sorte do mundo para esta etapa da minha vida.
Aos meus orientadores da ISA- Intelligent Sensing Anywhere, por todo o apoio e direcção que me
deram no trabalho desenvolvido ao longo deste ano lectivo.
A todos os elementos da equipa de energia da ISA que estiveram sempre dispostos a ajudar quando
necessário.
Aos restantes elementos da ISA, que me receberam da melhor maneira possível, proporcionando
um ambiente de trabalho descontraído e acolhedor,
Muito obrigado!
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
ix
iEnergy – Eficiência Energética em Edifícios
Índice
Índice
1
INTRODUÇÃO ...................................................................................................................................... 1
1.1
1.2
1.3
1.4
1.5
2
ÂMBITO ............................................................................................................................................... 1
APRESENTAÇÃO DA EMPRESA ................................................................................................................... 3
OBJECTIVOS DO ESTÁGIO ......................................................................................................................... 3
CONTRIBUIÇÕES..................................................................................................................................... 5
ORGANIZAÇÃO E TEMAS ABORDADOS NO PRESENTE RELATÓRIO ..................................................................... 5
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
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
xi
Índice
6
iEnergy – Eficiência Energética em Edifícios
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
8.2
xii
REVISÃO........................................................................................................................................... 113
VALIDAÇÃO....................................................................................................................................... 113
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Índice
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
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
xiii
iEnergy – Eficiência Energética em Edifícios
Índice de Figuras
Índice de Figuras
Figura 1 - Camadas da plataforma ..................................................................................................................... 7
Figura 2 - Organização das principais Entidades do Sistema ............................................................................ 9
Figura 3 - Ciclo de desenvolvimento do Scrum ............................................................................................... 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
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
xv
Índice de Figuras
iEnergy – Eficiência Energética em Edifícios
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
xvi
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Índice de Tabelas
Í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
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
xvii
iEnergy – Eficiência Energética em Edifícios
Índice de Anexos
Índice de Anexos
Anexo I – Estado da Arte
Anexo II – Casos de Uso
Anexo III – Plano de Riscos
Anexo IV – Especificação Web Service de Edifícios
Anexo V – Especificação de Base de Dados
Anexo VI – Especificação de Requisitos para a Fase de Integração
Anexo VII – Manual do Utilizador
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
xix
iEnergy – Eficiência Energética em Edifícios
Introdução
1 Introdução
Neste capítulo é inicialmente feita uma introdução ao âmbito do estágio seguindo-se uma breve
apresentação da empresa onde foi realizado. Seguidamente descreve-se o projecto de estágio e
enunciam-se os seus objectivos; em seguida são apresentados os contributos para o projecto.
1.1 Âmbito
Actualmente o peso da factura energética nos custos de exploração de uma empresa do sector
industrial é relativamente baixo por comparação com outros factores de produção como a mão-de-obra
ou a matéria-prima. Por esse motivo a gestão de energia é frequentemente negligenciada, facto que
pode gera significativos desperdícios de energia o que contribui para a redução da competitividade das
empresas. Adicionalmente, continua presente na mente de algumas indústrias a ideia de que o
crescimento económico acarreta necessariamente um aumento dos consumos de energia o que não é
inteiramente verdade.
O conceito de utilização racional de energia, surgido no seguimento dos chamados choques
petrolíferos [2], veio alterar decisivamente a forma de encarar a energia, demonstrando ser possível
crescer sem aumentar os consumos ou afectar a qualidade da produção. A chave da questão designa-se
por gestão de energia. Como qualquer outro factor de produção, a energia deve ser gerida contínua e
eficazmente. A utilização racional da energia (URE) consiste num conjunto de acções e medidas, que
têm por objectivo melhorar a utilização da energia.
A URE é cada vez mais um factor importante de economia energética e na redução de custos, tanto
no sector doméstico como no sector de serviços e industria.
Embora o argumento da competitividade continue naturalmente a ser aquele que mais sensibiliza a
generalidade das indústrias, a crescente pressão ambiental veio reforçar a necessidade de utilizar de
forma eficiente a energia. Seja por imposição legal, seja pela necessidade de cumprir requisitos
ambientais como forma de aceder a sistemas de apoio ou simplesmente por uma questão de imagem ou
pressão da opinião pública, cada vez mais a eficiência energética está na ordem do dia. Para além disso
é unanimemente aceite que, mais cedo ou mais tarde, instrumentos políticos de mercado, como taxas
ou impostos ambientais, introduzirão finalmente o princípio do poluidor pagador, penalizando
fortemente as empresas menos preparadas.
É assim que assumem particular importância o levantamento e a auditoria energética. Com efeito,
qualquer processo de gestão de energia terá necessariamente que começar pelo conhecimento da
situação energética das instalações. O princípio é óbvio - para gerir é indispensável conhecer o objecto
de gestão.
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
1
Introdução
iEnergy – Eficiência Energética em Edifícios
O levantamento energético pode interpretar-se como a primeira radiografia ao desempenho
energético da empresa ou industria. Através dele, avalia-se quanta energia é efectivamente consumida e
de que forma é essa energia utilizada, estabelecem-se os principais fluxos e identificam-se os sectores
ou equipamentos onde é prioritário actuar.
Por auditoria energética entende-se o exame detalhado das condições de utilização de energia nas
instalações. A auditoria permite conhecer onde, quando e como a energia é utilizada, qual a eficiência
dos equipamentos e onde se verificam desperdícios de energia, indicando igualmente soluções para as
anomalias detectadas.
A auditoria energética pode também constituir uma obrigação legal. Com efeito, estão abrangidas
pelo regulamento de gestão do consumo de energia (R.G.C.E.)[2], todas as empresas ou instalações
consumidoras intensivas de energia.
A auditoria energética surge assim como um instrumento fundamental, que o gestor de energia
possui para contabilizar os consumos de energia, a eficiência energética dos seus equipamentos e as
perdas que se verificam, tendo como finalidade última reduzir essas perdas sem afectar a produção, isto
é, economizar energia através do uso mais eficiente da mesma.
No mundo de hoje as máquinas ocupam já um papel de destaque em todas as áreas da nossa vida.
Por isso devem funcionar de forma a melhorar a sua eficiência energética, o que pressupõe uma recolha
e análise de dados que possam ser consultados na forma de gráficos, relatórios, alarmes e outras formas
de análise. A solução actual da ISA permite já a monotorização remota da energia através de um
grande número de sensores espalhados pelos edifícios. Sendo ainda um produto em maturação tem
como é óbvio algumas lacunas e algumas funcionalidades por implementar. Com este estágio
pretendeu-se cobrir parcialmente uma dessas lacunas, um software para o mercado B2B, que dotasse a
ISA de uma ferramenta de visualização e análise de dados, destinada a auxiliar o gestor de energia da
ISA na sua tarefa diária.
A função principal deste software é o de apoiar o gestor de energia da ISA na identificação de
problemas energéticos nos edifícios e na identificação equipamentos menos eficientes por forma a
poderem ser feitos investimentos conscientes na melhoria desses mesmos equipamentos, contribuindo
assim para uma utilização racional da energia, reduzindo custos e aumentado a competitividade das
empresas.
As soluções de análise de eficiência energética têm actualmente pouca divulgação em Portugal,
existem já algumas soluções no mercado em outros países, mas estas soluções têm a desvantagem em
relação solução global da ISA, de a maior parte delas não oferecer uma solução completa desde os
equipamentos de medição até ao software e de muitas delas não terem uma forma centralizada de ver a
2
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Introdução
informação disponibilizada. A ISA pretende oferecer essa solução com todas as funcionalidades
necessárias a uma gestão eficiente da energia.
1.2 Apresentação da Empresa
A ISA - Intelligent Sensing Anywhere é uma empresa global premiada e reconhecida
internacionalmente, especializada na área da telemetria de comunicações M2M. É líder em diferentes
segmentos desse mercado. Fundada em 1990 como spin-off da Universidade de Coimbra, a ISA conta
com cerca de 100 colaboradores, escritórios em França, Espanha, Alemanha, Irlanda e Brasil, estando
também presente em outros países através de agentes locais. O centro de I&D encontra-se em Portugal,
onde cerca de metade da equipa da ISA se dedica permanentemente à inovação e desenvolvimento de
produtos pioneiros.
As principais áreas de aplicação são:

Telemetria Óleo & Gás;

Soluções de Gestão de Energia;

Gestão Remota de Bens;

Sistemas de Gestão Integrada de Edifícios;

Solução de Gestão Remota para o Ambiente;

Soluções Médicas e de Cuidados de Saúde;
De entre todas estas áreas é de destacar a área de energia que inclui uma solução completa com
sensores, contadores e toda a gama de dispositivos inovadores que estabelecem uma rede capaz de
monitorizar à distância diversos parâmetros, tais como o consumo de água, gás e electricidade,
qualidade do ar, entre muitas outras funcionalidades
A informação recolhida pelos sensores é armazenada e tratada, sendo posteriormente
disponibilizada ao utilizador, através de um qualquer computador, telemóvel, ou display dedicado. A
versatilidade da solução iMeter desenvolvida pela ISA permite o controlo remoto de qualquer
electrodoméstico de forma a promover de forma efectiva a eficiência energética. Esta solução foi
reconhecida várias vezes pelo carácter inovador do conceito e das tecnologias que incorpora.
O estágio foi incluído nesta área da empresa que é chamada de área de energia, e na solução de
medição remota de gastos energéticos em edifícios.
1.3 Objectivos do Estágio
O objectivo principal deste estágio foi trabalhar sobre a plataforma de recolha e análise de dados de
eficiência energética da ISA, nas diversas fases de desenvolvimento do projecto, bem como nas
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
3
Introdução
iEnergy – Eficiência Energética em Edifícios
diversas camadas que constituem este software, de forma a implementar novas funcionalidades que
permitissem a evolução da plataforma para melhor acomodar o mercado B2B da empresa.
Neste projecto pretendeu-se desenvolver um portal de eficiência energética para o mercado B2B
usando para tal toda a infra-estrutura já existente na ISA, uma solução constituída por software e
hardware chamada - iEnergy -.
O software desenvolvido vai permitir a análise dos consumos energéticos em diversos edifícios de
uma forma centralizada, sejam eles consumos eléctricos, água ou gás, sendo que o consumo eléctrico é
o que tem maior relevância no projecto e é o mais usado para propósitos de teste e exemplos ao longo
do presente relatório.
A plataforma já existente o - iEnergy - é uma plataforma que recebe leituras de centenas de
sensores em diversas localizações geográficas. O tipo de leituras varia com o dispositivo: por exemplo
no caso da electricidade são recolhidas leituras de consumos de energia activa, potência ou mesmo
energia reactiva entre outros. O - iEnergy - recebe esses dados, armazena-os e processa-os (transformaos por exemplo em consumo de energia por hora, dia, ano ou mês) disponibilizando-os depois aos seus
clientes (domésticos e empresariais).
Os principais objectivos da plataforma global - iEnergy - são;

Adquirir dados de sensores remotos;

Guardar e processar esses dados;

Monitorizar o equipamento e detectar anomalias;

Oferecer uma API que possa ser usada para sistemas de terceiros.
A plataforma de recolha e análise de dados encontra-se divida em vários módulos, desde o módulo
de recolha de dados, módulo de acesso aos dados, até ao módulo de disponibilização de dados através
de web services para aplicações clientes.
Na primeira fase do estágio pretendeu-se fazer uma recolha de requisitos para a plataforma de
análise de dados na sua vertente B2B com o cliente do software o gestor de energia da ISA.
A segunda fase do projecto teve por objectivo desenvolver um interface web que permitisse
analisar todos os dados disponibilizados pela plataforma bem como a implementação de novas
funcionalidades no - iEnergy - como por exemplo cálculo e simulação de tarifários de energia eléctrica,
cálculo de indicadores, agrupamento de hardware separado geograficamente em grupos lógicos, entre
outras.
O objectivo final consistiu em obter um software que ajude a gerir melhor os consumos de energia
nos edifícios, permitindo identificar e consciencializar as pessoas de onde e como gastam a energia,
permitindo desta maneira actuar sobre os desperdícios energéticos.
4
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Introdução
1.4 Contribuições
Creio ser legítimo afirmar que o projecto “iEnergy – Eficiência Energética em Edifícios” alcançou
os objectivos inicialmente traçados. Esta opinião é alicerçada no facto de ter sido implementada a
aplicação pretendida (solicitada por cliente específico), tendo inclusivamente o software desenvolvido
servido para detectar várias anomalias de consumos energéticos nos edifícios onde foi usado (por
exemplo, sistemas AVAC e de iluminação a funcionarem sem necessidade). Além disso, a
documentação produzida como suporte ao processo de implementação alcançou, na minha opinião, os
níveis de qualidade pretendidos. Um dos alicerces desta opinião está na auditoria externa a que este
projecto foi sujeito, e no qual passou com bons resultados. Outro motivo de satisfação é o facto de o
software ter sido instalado juntamente com a solução - iEnergy - num cliente bancário para permitir a
gestão energética de todas as suas agências e edifícios. Neste momento o software está a funcionar com
cerca de 400 grupos lógicos (agências e edifícios) com centenas de sensores a enviarem informação
para a plataforma - iEnergy -.
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.
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
5
Introdução
iEnergy – Eficiência Energética em Edifícios
No Capítulo 7, Arquitectura e Implementação da Plataforma, começa-se por apresentar a
arquitectura global da aplicação. De seguida é efectuada uma descrição pormenorizada da solução
desenvolvida, na qual se refere os vários aspectos e detalhes do modelo de dados e da interface.
No Capítulo 8,Verificação e Validação, são apresentados os testes e verificações que o software foi
sujeito de forma a garantir que estava dentro dos parâmetros de qualidade desejados.
No Capítulo 9, Avaliação de Resultados, faz-se uma análise e discussão sobre os resultados obtidos
no estágio.
6
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Análise do Problema
2 Análise do Problema
Neste capítulo é feita a apresentação do problema num contexto global. São também apresentados
alguns conceitos fundamentais para uma melhor compreensão do problema e do projecto.
2.1 Conceitos Fundamentais
Para melhor se compreender o âmbito do projecto em estudo, existe um conjunto de tópicos
referentes à plataforma - iEnergy -, cuja apresentação é pertinente. Na secção de “Glossário e
Definições” existem ainda um conjunto de definições relacionadas com a gestão de energia que
também podem ser úteis para uma melhor compreensão do projecto.
2.2 Plataforma iEnergy
A solução - iEnergy - é composta por vários módulos de software e hardware. O hardware é
composto por sensores que recolhem vários tipos de dados de consumos energéticos. Este hardware
comunica através da internet com uma plataforma de recolha de dados - o iCenter -, que posteriormente
passa esses dados para a camada de processamento de dados - o iEnergy -, que os trata e os
disponibiliza para plataformas clientes através de web services, como mostra a Figura 1.
Fornecimento
de dados
Domestico
Escolas
Tratamento de
dados
iEnergy
Recolha
iCenter
Edifícios
Web
Aquisição
Figura 1 - Camadas da plataforma
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
7
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;
8
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios

Análise do Problema
Tag: É onde são guardados os parâmetros lidos pelos dispositivos. Se um dispositivo medir a
corrente e a energia activa vão existir duas tags para esse dispositivo.

Local - O local é a localização onde o hardware de monotorização remota está instalado. Pode
corresponder a uma casa, a um edifício etc.
Como podemos ver pela Figura 2, as unidades estão no topo de uma hierárquia, sendo uma peça de
hardware. São responsáveis por recolher os dados de cada um dos dispositivos instalados num edifício,
sendo que o edifício pode ter mais do que um dispositivo que comunica com as unidades através de
Wireless ou ZigBee. No fim da hierárquica estão as tags que não são mais que tipos de medições,
podendo ser de energia activa, temperatura, ou energia reactiva, entre outras.
Unidades
Edificio 1
Dispositivos
Tags
Sala 1
Energy
Sala 2
Temperature
Humidity
Figura 2 - Organização das principais Entidades do Sistema
Outra entidade importante são os grupos lógicos: com estes grupos pretende-se agrupar
logicamente as unidades, os dispositivos ou as tags. Com os grupos pretende-se facilitar a vida ao
utilizador organizando os dispositivos, tags e unidades de forma lógica e hierarquizada possibilitando
uma visualização fácil da organização. Estes grupos podem mesmo agrupar edifícios separados
geograficamente.
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
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
9
Análise do Problema
iEnergy – Eficiência Energética em Edifícios
dos trabalhos realizados na área (nomeadamente da concorrência), e reuniões com pessoas associadas
ao projecto. Nesta secção realiza-se uma apresentação de todo o sistema num contexto geral, referindo
os seus intervenientes.
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.
10
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Análise do Problema
Com base no estudo realizado verificou-se que o sistema deveria ser constituído por várias partes e
a interacção ser feita através de uma aplicação web, cujo intuito é de ser acessível online com acesso
restrito. Como já foi referido este novo sistema será integrado na plataforma já existente, o - iEnergy -.
Portanto este estágio encontra-se dividido em duas partes:
1) Construção de raiz de uma plataforma web que permita a visualização e análise de consumos
energéticos em edifícios;
2) Implementação de novas funcionalidades na plataforma - iEnergy -,: pretende-se disponibilizar
um conjunto de funcionalidades que ajudem as pessoas responsáveis pela gestão da energia em
edifícios na sua tarefa do dia á dia.
O sistema deve portanto satisfazer as seguintes áreas de requisitos:

Aplicação Web
o
Área de análise e comparação

Contém todas as funcionalidades de análise e comparação de variáveis
energéticas.
o

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.
Área de alarmes

Contém todas as funcionalidades para criação, edição e visualização de
alarmes.
o

Lista de alarmes disparados no sistema.

Marcação de alarmes já resolvidos.
Á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).

o
Simulação de tarifários

o
Contém as funcionalidades de visualização de comparação de tarifários.
Relatórios


Listar de actuações.
Apresentação de relatórios de interesse para o gestor de energia.
Plataforma iEnergy
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
11
iEnergy – Eficiência Energética em Edifícios
Análise do Problema
o
Tarifários de electricidade

Contém toda a funcionalidade de criação e edição de tarifários de
electricidade.

o
Cálculo de Tarifários de Energia eléctrica

o
o
Verificação de actuações que devem ser feitas sobre os dispositivos.
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.
Verificação de Alarmes

o
Contém toda a funcionalidade de cálculo de tarifários de energia eléctrica.
Verificação de actuação

o
Navegação entre tarifários.
Verificação de lançamento de alarmes.
Simulação de tarifários

Cálculo de custos de energia para cada um dos tarifários no sistema.
Este sistema deve estar constantemente disponível e não deve permitir acessos indevidos, ou seja,
deve permitir apenas as funcionalidades a que um utilizador de um dado nível tenha acesso. Pretendese que possa ser acedido através de qualquer browser instalado num computador pessoal. Em termos
de desempenho pretende-se que as pesquisas sobre os dados sejam tão rápidas quanto possível. Deve
ainda permitir um acesso multi-utilizador igualmente com bom desempenho. Estes requisitos serão
descritos de forma mais detalhada na secção 6.
12
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Plano de Trabalhos
3 Plano de Trabalhos do Estágio
Neste capítulo é apresentado o plano de trabalhos do estágio: em primeiro lugar, a metodologia de
desenvolvimento de software; em seguida são mostradas as planificações feitas para as tarefas
desenvolvidas no contexto deste projecto.
Inicialmente efectuou-se uma análise do problema, já apresentada no capítulo anterior. Seguiu-se o
levantamento do estado da arte, com vista a verificar as soluções existentes ou semelhantes. Foi
também efectuada uma análise sobre as tecnologias existentes, a considerar para serem utilizadas no
desenvolvimento da aplicação web. Após isso foi feita a especificação do sistema, detalhando
fundamentalmente as partes que foram implementadas durante o estágio. Para finalizar esta primeira
fase foram escolhidas as tecnologias a utilizar e foi feita uma aprendizagem intensiva com o auxílio de
documentação apropriada.
Na fase seguinte deu-se início à implementação do sistema começando pela base de dados e
prosseguindo depois pela plataforma (core e web service) até a aplicação web durante os quatro meses
seguintes. Finalmente procedeu-se à escrita do presente documento e à afinação do sistema e correcção
de problemas.
3.1 Metodologia de Desenvolvimento
Implementar software de dimensão significativa sem usar nenhuma metodologia para guiar o
desenvolvimento poderá levar o projecto ao insucesso. Realizar desenvolvimento de software usando
uma metodologia que não se adequa ao projecto, ou porque não foram tidas em conta as
especificidades do projecto e da equipa, ou porque no decorrer do processo se revelou pouco adequada
ao mesmo, também condena desde logo tal projecto ao fracasso. Existem já muitos estudos [3] que
alicerçam esta opinião. Existem várias métricas que podem ser usadas na escolha da metodologia, neste
caso a equipa de energia da ISA do departamento de software (o departamento onde se insere o
projecto de estágio) utilizava já o scrum no desenvolvimento de software, e foi portanto essa a
metodologia de desenvolvimento usada.
Neste estágio apesar de a maior parte do tempo ter trabalhado sozinho era necessário ter grande
contacto com a equipa de desenvolvimento do - iEnergy -, devido ao facto de este ser um projecto no
seu global muito complexo com várias camadas onde era necessária a ajuda de alguém com
conhecimento da plataforma. Desta forma foi possível reduzir o tempo de estudo da plataforma, para
além de que possibilitou a integração dos módulos construídos durante o estágio na solução global e
permitiu actualizadar a documentação do projecto com o que ia sendo feito. Desta forma foi possível
manter todos os elementos da equipa de desenvolvimento com o mesmo nível de conhecimento sobre o
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
13
iEnergy – Eficiência Energética em Edifícios
Plano de Trabalhos
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 autoresponsabilização da mesma, e uma consistente componente de melhoria contínua dos processos de
desenvolvimento.
As funcionalidades a serem implementadas durante o projecto são mantidas numa lista que é
conhecida como product backlog. No início de cada sprint, faz-se um sprint planning meeting, ou seja,
uma reunião de planeamento na qual o product owner prioriza os itens do product backlog e a equipa
selecciona as actividades que ela será capaz de implementar durante o sprint que se inicia. As tarefas
alocadas a um sprint são transferidas do product backlog para o sprint backlog.
A cada dia de um sprint, a equipa faz uma breve reunião (normalmente de manhã), chamada daily
scrum. O objectivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar
impedimentos e priorizar o trabalho do dia que se inicia.
No final de um sprint, a equipa apresenta as funcionalidades implementadas num sprint review
meeting. Finalmente, faz-se um sprint retrospective e a equipa parte para o planeamento do próximo
sprint. Assim reinicia-se o ciclo.
Figura 3 - Ciclo de desenvolvimento do Scrum
14
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Plano de Trabalhos
3.2 Aplicação do Scrum no Projecto de Estágio
A abordagem que foi usada durante o projecto foi baseada no scrum, conforme já referido. Assim o
projecto foi dividido em vários sprint’s, e no final de cada um foi feita uma publicação do software
para testes e para o cliente, de modo a que o sistema fosse validado e avaliado desde o início do seu
desenvolvimento. Pretendeu-se desta forma desenvolver o sistema de forma gradual disponibilizando
mais rapidamente as funcionalidades prioritárias, sendo alvo de uma maior verificação e teste,
corrigindo os problemas de uma forma controlada e construindo os vários módulos do sistema tendo o
que já estiver concretizado a funcionar correctamente e portanto evitando problemas maiores. Como já
referi, ao longo do decorrer deste projecto trabalhei inserido numa equipa de desenvolvimento. Uma
característica do scrum que foi muito explorada neste trabalho é o facto de este ter sido baseado
fortemente em user stories e casos de uso. De facto, foram elaborados vários diagramas de casos de
uso e foram elaboradas user stories para cobrir os requisitos identificados. Esse trabalho revelou-se
fulcral para compreender exactamente aquilo que era esperado de mim a nível do comportamento da
aplicação.
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.
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
15
Plano de Trabalhos
iEnergy – Eficiência Energética em Edifícios
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.
16
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Plano de Trabalhos
O objectivo inicial deste estágio seria o estudo da plataforma existente o - iEnergy -, estudo de
tecnologias e especificação de requisitos para a plataforma tendo como output desta fase a
especificação técnica do software.
O planeamento proposto inicialmente pode ser visualizado no diagrama de gantt da Figura 4.
Figura 4 – Diagrama de Gantt com o planeamento inicial do trabalho a realizar no primeiro semestre.
Uma das primeiras tarefas a realizar durante este período de tempo deveria ser a definição das
linguagem(s) de programação/tecnologia(s) que seriam utilizadas na fase de implementação para a
aplicação web já que para os outros módulos a tecnologia já se encontrava escolhida. Previa-se,
também, que seria realizada, nesta fase, a descrição detalhada da aplicação a desenvolver,
nomeadamente em termos das funções/métodos a implementar (variáveis de entrada, variáveis de
retorno, objectivo de cada uma, entre outros aspectos). Esta fase implicaria também a elaboração de um
diagrama de classes (no caso de ser usada uma linguagem de programação orientada a objectos,
naturalmente) e de um diagrama entidade-relacionamento para a novas tabelas que seriam necessárias,
visto que se previa a integração de novas funcionalidades na plataforma - iEnergy -.
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
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
17
iEnergy – Eficiência Energética em Edifícios
Plano de Trabalhos
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
Análise
Planeamento da Sprint
Backlog Priorizado e
Sprint Backlog, Objectivo
Estimado
da Sprint
Sprint Backlog, Objectivo da
Demo da Iteração
Desenho e
Sprint = Iteração
Sprint
Construção
Pré-
Saida
Revisão da Sprint
Demo da Iteração
Validação de Objectivos
Retrospectiva
Validação de Objectivos
Lista de Impedimentos
Produção
Análise
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
18
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Plano de Trabalhos
gantt não é possível ver a divisão por sprint’s. O gantt do segundo semestre não foi exactamente
seguido já que se pretendia entregar partes do software já funcionais que pudessem ser vistas e testadas
pelo cliente. O sprint inicial incluiu o estudo da plataforma, estado de arte, especificação dos requisitos
e especificação técnica. O último sprint como já foi referido foi apenas dedicada a testes e correcções e
preparação para a entrega do software. De cada sprint saiu uma demo que foi entregue ao cliente e a
equipa de testes.
Participantes: Equipa técnica, Scrum Master e Product Owner.
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
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
19
Plano de Trabalhos
iEnergy – Eficiência Energética em Edifícios
utilizador, manual de instalação, preparação de treino e de material de marketing. Uma vez concluída
toda a fase de desenvolvimento, o sistema foi testado e validado na sua totalidade, corrigindo eventuais
falhas.
3.3 Opinião pessoal
O scrum foi uma experiencia interessante que permitiu que o projecto fluísse a boa velocidade e
que envolvesse toda a gente. Permitiu também a rápida identificação de requisitos que não estavam de
acordo com o esperado sendo melhorados nos sprint’s seguintes.
Verificaram-se alguns atrasos no projecto, sobretudo no início, visto que alguns pormenores do
software que se pretendia desenvolver, demoraram algum tempo a estar totalmente definidos, até
porque este foi um projecto em que se esteve a trabalhar numa área nova, e que foi começado de raiz
com o presente estágio, sob direcção do meu orientador da ISA. E também porque na altura não existia
na empresa, ninguém com o conhecimento necessário na área de negócio B2B de energia. Esta
metodologia permitiu que quando tudo estava já normalizado, o projecto avançasse a ritmo elevado
permitindo assim atingir os objectivos traçados.
Ou seja, existiram mudanças de requisitos ao longo da evolução do projecto de software e todos os
elementos do projecto tiveram, geralmente, uma palavra a dizer sobre esses mesmos requisitos e sobre
a forma de os implementar. O scrum permitiu esta flexibilidade.
Sendo que o - iEnergy - é uma plataforma complexa que necessita de alguns conhecimentos tanto a
nível técnico como a nível de negócio foi decido que devia ser integrado na equipa de energia da ISA.
A metodologia scrum permitiu o fácil adaptar ao projecto com ajuda constante da equipa em que estava
inserido.
Penso que a abordagem flexível do scrum permitiu lidar com todas as vicissitudes e contrariedades
que foram aparecendo ao longo do projecto coisa que num modelo rígido não funcionaria.
Uma palavra também para equipa que no espírito do scrum foi de uma grande ajuda ao longo do
projecto. Fui-se mantendo um contacto permanente entre a equipa, precisamente para esclarecer
questões e para descrever e mostrar o trabalho que ia realizando ao longo do tempo, permitindo
feedback constante.
20
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Fase de Integração
4 Fase de Integração
Na fase inicial do estágio fui inserido num projecto de monitorização energética em embarcações,
onde tive oportunidade de me integrar no processo de desenvolvimento da ISA. Tive ainda a
possibilidade de aprender as tecnologias utilizadas pela ISA para desenvolvimento das suas
plataformas, já que nunca tinha trabalhado com as tecnologias usadas.
Esta fase não estava prevista no planeamento inicial do projecto apresentado na secção 3. Esta fase
justifica-se pelo atraso no arranque do projecto em que foi efectuado o meu estágio, atraso este devido
a questões de negócio que a mim são alheias. Neste projecto tive a responsabilidade de construir
relatórios de análise energética em ambiente web, validação de viagens de embarcações, inserção de
viagens através do serviço de bilhética, bem como a implementação de alarmes num serviço de GPRS
(já construído).
4.1 Eficiência Energética em Embarcações
O projecto eficiência energética em embarcações era já um projecto em curso quando começou o
meu estágio na ISA, e faz parte também dos projectos de monotorização energética. É um pouco
diferente da monotorização energética em edifícios já que neste caso os consumos são de gasolina e
não de electricidade ou gás. Este projecto usou a metodologia já mencionada no Capítulo 3, o scrum. O
projecto esteve dividido em seis sprint’s de quinze dias cada, estando eu apenas alocado nos tês
últimas sprint’s. Este sistema é inteiramente baseado em tecnologias TCP-IP. Todos os módulos de
software a instalar nos diversos locais de interesse assim como a solução embarcada são baseados
nessa tecnologia.
Existem torniquetes que controlam a entrada de passageiros nas embarcações, que permitem o
cálculo de cargas de cada percurso com base na informação estimada de passageiros e combustível.
Existem também unidades de GPS que a cada instante guardam a posição, velocidade e outros dados
relevantes. Existe também o caldalímetro que permite a monotorização do consumo instantâneo. Faz-se
a monotorização do nível do combustível de cada tanque da embarcação e usam-se tags RFID que
permitem detectar com exactidão as atracagens dos navios, permitindo a separação dos tempos das
viagens. É também possível a detecção da localização da embarcação quando parada. Nesta secção não
farei uma descrição exaustiva - já que este projecto sai um pouco do meu projecto de estágio-, mas
apenas uma descrição geral.
Este sistema perminte a gerir e analisar dados relativos à gestão energética de uma frota de
embarcações dotadas de um equipamento de monitorização.
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
21
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.
22

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
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
4.3.1.2
Fase de Integração
Serviço de Bilhética
A bilhética é um serviço externo ligado aos torniquetes de forma a controlar a entrada de
passageiros na embarcação. Este serviço guarda dados referentes a cada embarcação como o número
passageiros por embarcação/viagem, o início e o fim da mesma e também as docas de partida e de
chegada. Este serviço gera um ficheiro com os esses dados para cada uma das viagens realizadas ao
logo do dia. No final do dia este ficheiro é enviado para um servidor FTP. Posteriormente o sistema de
monitorização lê esse mesmo ficheiro de forma a recolher os dados contidos nele. Através do serviço
de bilhética é possível saber o número de passageiros e em conjugação com o caldalímetro é também
possível estimar o peso transportado em cada viagem (peso dos passageiros vezes o peso do
combustível). Através destes dados é ainda possível calcular outros indicadores que são descritos nas
secções seguintes.
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.
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
23
Fase de Integração
iEnergy – Eficiência Energética em Edifícios
De seguida é apresentada a forma que cada um destes indicadores é calculado:

Consumo Horário (L/h) (caudalímetro) – Consumo médio horário de uma embarcação numa
viagem do tipo carreira;

Consumo Horário (L/h) (Registos) – Consumo médio horário de uma embarcação numa
viagem do tipo carreira através dos registos de consumos inseridos;

Consumo/Carreira (L) (caudalímetro) – Consumo médio de uma embarcação por viagem do
tipo carreira;

Consumo/Carreira (L) (Registos) – Consumo médio de uma embarcação por viagem do tipo
carreira através dos registos de consumos inseridos;

Consumo Total (L) (caudalímetro) – Soma dos consumos de uma embarcação;

Consumo Total (L) (Registos) – Soma dos consumos de uma embarcação dos registos de
consumos inseridos;

Custo/Km (Euro/km) – Custo médio da embarcação por Km percorrido;

Distância/Carreira – Distância media percorrida por viagem do tipo carreira;

Eficiência da Oferta (pKm/L) - Eficiência média da oferta por pKm/L;

Eficiência da Procura (pKm/L) – Eficiência média da procura por pKm/L;

Motores/Carreira (%) – Percentagem de utilização dos motores em viagens do tipo carreira ((
Tempo viagem tipo carreira - tempo viagem manobras)/( Tempo outras viagens – Tempo
carreira - Tempo manutenção));

Passageiros/Carreira (nº) - Número médio de passageiros por viagem do tipo carreira;

Peso transportado (Kg) – Peso médio transportado por viagem do tipo carreira;

Tempo/Viagem (min) - Duração média de cada viagem do tipo carreira;

Velocidade (nós) - Velocidade média das viagens do tipo carreira;

Carreiras realizadas – Soma das viagens do tipo carreira realizadas.
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).
24
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Fase de Integração
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) (caudalímetro) – Soma dos consumos de uma embarcação;

Consumo Total (L) (Registos) – Soma dos consumos de uma embarcação através dos dados
inseridos;

Custo/Km (Euro/km) – Custo médio da embarcação por Km percorrido;

Distância/Carreira – Distância média percorrida por viagem do tipo carreira.

Eficiência da Oferta (pKm/L) - Eficiência média da oferta por pKm/L;

Eficiência da Procura (pKm/L) – Eficiência média da procura por pKm/L;

Motores/Carreira (%) – Percentagem de utilização dos motores em viagens do tipo carreira;

Passageiros/Carreira (nº) - Número médio de passageiros por viagem do tipo carreira;

Peso transportado (Kg) – Peso médio transportado por viagem do tipo carreira;

Tempo/Viagem (min) - Duração média de cada viagem do tipo carreira;

Velocidade (nós) - Velocidade média das viagens do tipo carreira durante um intervalo de
tempo;

Carreiras realizadas – Número das viagens do tipo carreiras realizadas.
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;
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
25
Fase de Integração
iEnergy – Eficiência Energética em Edifícios

Manobras - Percentagem de tempo total gasto em viagens validas do tipo manobras;

Por Validar - Percentagem de tempo total gasto em todas as viagens que ainda não estão
validadas;

Tempo ao cais - Percentagem de tempo total gasto em cais que ainda não estão validadas, em
cada um dos meses do ano;

Tempo geral – Tempo total em horas gasto para cada uma das viagens acima descritas;

Total registos – Tempo total de funcionamento calculado a partir dos dados introduzidos.
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
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;
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;
26

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.
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Fase de Integração

Consumo total – Consumo total de combustível em viagens do tipo carreira por cada mestre;

Passageiros totais – Número total de passageiros em viagens do tipo carreira para cada um dos
mestres;

Distância total percorrida – Distância total percorrida em viagens do tipo carreira por cada um
dos mestres;

Nº Carreiras – Total de viagens do tipo carreira realizadas por cada um dos mestres.

Total registos – Consumo total calculado a partir dos dados introduzidos.
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).
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
27
iEnergy – Eficiência Energética em Edifícios
Fase de Integração

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;
28
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios

Fase de Integração
Falha de nível de combustível - O consumo é 0 mas percorreu uma distância
superior a tolerância;

Motores/Carreira menor que 30 – Calcula os motores/carreira para um
intervalo de tempo em dias e verifica se é menor que 30;

Aquecimento – No caso de viagens do tipo aquecimento os seguintes valores
são considerados:

Consumo/Viagem (aquecimento) inferior a 5 e superior a 60;

Tempo/Viagem (aquecimento) maiores que 50 minutos;

Velocidade instantânea superior a 2 nós (ou outro valor a definir).
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.
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
29
Fase de Integração
4.4.1.2
iEnergy – Eficiência Energética em Edifícios
Base de Dados
Como sistema de gestão de base de dados foi usado o Microsoft SQL Server 2008 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.
30
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
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
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
31
iEnergy – Eficiência Energética em Edifícios
Revisão Tecnológica
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
Indicadores
Actuação
Tarifários
Simulação de
Tarifários
dados
Exportação de
Alertas
histórico
Gráficos de
Relatórios
Comparativos
Tempo real
por cada um desses competidores com as funcionalidades pretendidas para o software da ISA.
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
-
-
32
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Revisão Tecnológica
Raritan
X
X
AgileWaves
X
-
X
X
X
-
-
-
-
-
Johnson Controls
X
X
X
X
X
X
X
X
-
-
Tabela 2 - Quadro parcial de funcionalidades da concorrência
Com esta tabela podemos concluir que a ISA, exceptuando a funcionalidade “tempo real” que não
está prevista para este software, pretende inplementar todas as restantes funcionalidades. De referir que
algumas funcionalidades, apesar de estarem marcadas como presentes, em algumas das empresas
apresentam-se apenas parcialmente implementadas.
O Anexo I contém mais informações sobre cada uma destas empresas.
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
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
33
iEnergy – Eficiência Energética em Edifícios
Revisão Tecnológica
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
34
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Revisão Tecnológica
Na Figura 8 podemos analisar o uso de cada tipo de tecnologias pelo número de funcionalidades.
As empresas com mais funcionalidades são aquelas com maior valor no eixo dos X por sua vez as que
usam mais tecnologias código aberto são aquelas com mais valor no eixo dos Y.
Conseguimos ver que existe algum equilíbrio no uso de tecnologias de código fechado e código
aberto mesmo para os casos mais complexos (mais funcionalidades) existem empresas a usar muito
código aberto. De realçar que as empresas com mais funcionalidades apenas a Johnson Controls usa
somente tecnologias de código fechado.
Figura 8: Relação entre a complexidade (número de funcionalidades) e o tipo de tecnologias
De realçar que praticamente todas disponibilizam um interface web para o utilizador final. O uso
de restrito a tecnologias código fechado pode encarecer a solução coisa que não se pretende para este
projecto.
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 -.
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
35
Revisão Tecnológica
5.2.2.1
iEnergy – Eficiência Energética em Edifícios
Base de Dados
A base de dados já se encontrava implementada sobre uma BD Sql Server 2008 RC2, portanto não
foi objecto de estudo.
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);
36
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Revisão Tecnológica

Integração fácil com Frameworks JavaScript nomeadamente o JQuery;

Suporta motores de vista de terceiros NVelocity, Brail, NHaml entre outros;

Não existe ViewState e eventos PostBack;

Segue a natureza sem estado da Web;

Ideal para aplicações Web 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.
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
37
iEnergy – Eficiência Energética em Edifícios
Revisão Tecnológica
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
Panning
m
Múltipl
Diferentes
os eixos
tipos
gráficos
Mostrar
Possibilidad
de detalhes de e
pontos
Custo
de s
exportação
para Excel
Flot
X
X
X
X
X
-
0
Flotr
X
X
-
X
X
X
0
JqPlot
X
X
X
X
X
-
0
.Net Chart
-
-
X
X
X
X
0
Control
Tabela 3 - Comparação de ferramentas web de construção de gráficos
38
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
5.2.4.1
Revisão Tecnológica
Protótipos Construídos
Foram construídos dois protótipos com as tecnologias de gráficos, estes dois protótipos foram
feitos usando as tecnologias que mais se enquadravam no que se pretendia. Tecnologias gratuitas que
permitissem gerar gráficos ricos visualmente e em que o utilizador pudesse interagir facilmente (zoom,
detalhes de pontos do gráfico etc). Os protótipos foram construídos usando uma base de dados de
produção do - iEnergy - por forma a validar que estes componentes responderiam em tempo útil a uma
situação real.
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.
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
39
iEnergy – Eficiência Energética em Edifícios
Revisão Tecnológica
Agregados
Agregados
Agregados
Agregados
Agregados
horários
horários de
horários de
horários de
horários de
de 1 mês
3 mêses
6 mêses
9 mêses
1 Ano
(744 horas)
(2232 horas)
(4464 horas)
(6696 horas)
(8760 horas)
JqPlot
1s
2s
10s
24s
30s
.Net Chart
1s
2s
10s
20s
29s
Control
Tabela 4 - Tempo de renderização de gráficos
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.
40
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Especificação
6 Especificação
Este capítulo tem como objectivo apresentar a especificação da solução proposta. É efectuada uma
análise, primeiramente em geral e depois em detalhe, sobre os requisitos do sistema total, com todas as
características que os mesmos deverão ter no final do projecto. Os requisitos encontram-se agrupados
em subsecções, de acordo com as suas especificidades. Na subsecção dos requisitos funcionais são
apresentados os casos de uso do sistema, na subsecção de requisitos não funcionais são apresentados os
requisitos de qualidade, performance e segurança.
Como será dada mais importância à parte do sistema a desenvolver durante o estágio, será esta
parte que estará mais em foco. Para cada requisito em particular será atribuída uma prioridade em
relação à sua importância no desenvolvimento do sistema, dada pelo cliente como já foi explicado na
secção 3. Essa prioridade será “Must Have”, “Shoud Have” ou “Nice to Have”. Um requisito com
prioridade “Must Have” significa que no final do projecto terá de se encontrar completo e funcional. Se
um requisito tiver prioridade “Shoud Have” terá de existir, mas poderá ainda não estar totalmente
completo, e se a prioridade for “Nice to Have” significa que só será implementado se houver tempo,
sendo algo adicional que não é fundamental no sistema para esta fase, mas que lhe acrescenta valor.
Contudo, é necessário salientar que para alguns requisitos considerados com prioridade “Must Have”,
devido à sua complexidade, o seu desenvolvimento será gradual durante o desenvolvimento do
projecto (continuando mesmo após o estágio).
Este estágio prevê o desenvolvimento de uma aplicação web de raiz, a integrar na plataforma iEnergy - já existente, através de um web service. Este web service vai fazer uso de algumas
funcionalidades já existentes bem como incluir outras novas.
6.1 Visão Geral
Uma aplicação de gestão de energia para edifícios, permite reconhecer e identificar desperdícios a
partir dos dados recolhidos pelos sensores instalados nas várias divisões. Estes sensores permitem
medir os consumos de uma divisão, de um edifício inteiro ou até mesmo de um sistema de AVAC,
sendo que estes sistemas são a principal fonte de desperdícios nos edifícios, principalmente por falta de
zelo na sua utilização. Um sistema de gestão de energia permite ver estes consumos de forma isolada
ou em conjunto, sendo assim possível identificar onde estão as fontes de desperdício.
Os dados são recolhidos, tratados e armazenado no sistema de forma a posteriormente serem
apresentados ao utilizador na forma de relatórios, gráficos, indicadores ou mesmo alarmes.
Os dispositivos são organizados em grupos lógicos para serem facilmente reconhecidos e
manipuláveis pelo utilizador, estes grupos podem representar um edifício e os seus vários pisos e
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
41
iEnergy – Eficiência Energética em Edifícios
Especificação
divisões. O utilizador pode seleccionar esses edifícios e ver o consumo de um piso, ou de vários pisos
de forma a compará-los em termos de consumos e de custos. Estes dados podem ser posteriormente
exportados para Excel para posterior análise. Um dos problemas actuais deste tipo de software de
análise é a falta de liberdade que o utilizador tem para analisar os consumos, quer por falta
possibilidades de escolha dos períodos em análise e de agregação dos dados, quer pela falta de
organização lógica dos vários sensores.
Nesta aplicação todos os dados são apresentados através de uma aplicação web por via online, em
oposição a algumas das soluções já existentes, que em muitos dos casos são aplicações web usadas em
modo offline. Este sistema permite a consulta centralizada através da internet dos vários edifícios a
serem monitorizados.
O sistema deverá incluir uma forte componente financeira de forma a ser possível analisar os
consumos em termos de custos, sendo esta uma funcionalidade decisiva no sucesso da aplicação.
Também deverão existir alarmes para consumos fora de um certo padrão, já que é previsível que
existam muitos edifícios no sistema e não seria fácil percorrê-los a todos manualmente, procurando
desvios no padrão de consumo. Deste modo o gestor de energia pode configurar alarmes que serão
disparados quando ocorrerem consumos anormais, facilitando muito o seu trabalho. Por fim existirá
uma componente de actuação sobre os equipamentos instalados no edifício: por exemplo, é detectado
que os reclames luminosos de um determinado edifício se encontram acesos mesmo quando ainda é de
dia; nesse caso o gestor de energia pode criar um agendamento semanal para ligar ou desligar esses
equipamentos a horas fixas.
O sistema será estruturado em vários módulos, permitindo um estudo mais detalhado e rigoroso.
Deles fazem parte, num primeiro nível, a aplicação web, em seguida o web Service e o - iEnergy -,
e por fim o armazenamento (base de dados).
6.2 Características dos Utilizadores
Para este sistema foram identificados três actores, de acordo com o que foi dito na secção 2.2. O
acesso ao software é feito por login e password. Isto permite ter contas diferentes para cada utilizador e
perfis diferentes de utilizador. Cada perfil acede a determinadas funcionalidades do software.
Os diferentes perfis de utilizador são:

Cliente: Tem acesso à plataforma apenas para ver indicadores (não os pode alterar) e
extrair relatórios predefinidos (não os pode alterar) dos projectos a que está alocado. Este
utilizador apenas tem acesso aos grupos lógicos aos quais tem permissões para aceder.

Gestor de energia: Acesso total à plataforma não podendo no entanto gerir utilizadores
nem permissões nos grupos lógicos.
42
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios

Especificação
Administrador: Acesso total à plataforma.
Pode ser vista de seguida a hierarquia entre eles no seguinte diagrama (Figura 9):
uc Actors
Cliente
Gestor de energia
Administrador
Figura 9 - Hierarquia de Utilizadores
6.3 Análise de Requisitos
Nesta secção é descrita a fase de estudo e recolha de requisitos que coincide com o Pre-Game do
scrum que consistiu na aquisição dos requisitos funcionais e não funcionas para a plataforma.
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
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
43
iEnergy – Eficiência Energética em Edifícios
Especificação
reuniões de brainstorming foi feita uma prototipagem através de interfaces de utilizador de forma a
serem validados pelo cliente da aplicação. Durante a análise de requisitos, a prototipagem deu forma
concreta aos requisitos e assistiu à sua clarificação e determinação. Foram também elaboradas um
conjunto de questões para servirem como esclarecimento de dúvidas. Estas questões foram enviadas
para o cliente usado a ferramenta Google Docs e respondidas nessa mesma ferramenta (um exemplo na
Figura 10). Em muitas situações esta interacção através da ferramenta Google Docs não se mostrou
eficaz e tiveram mesmo de ser feitas reuniões para entender melhor certos requisitos.
Figura 10 - Exemplo de perguntas colocadas no Google Docs
Depois da primeira Release do software, e devido a algumas queixas de usabilidade da aplicação,
foram feitas algumas observações de comportamento com os utilizadores no seu ambiente natural de
trabalho, enquanto executavam tarefas específicas no software, o que permitiu detectar várias
melhorias a incorporar nas versões seguintes da aplicação.
Segundo a metodologia adoptada estes requisitos são elementos do product backlog e estão na
forma de user stories. Todos os requisitos presentes nesta secção são requisitos finais. No entanto,
muitos destes requisitos sofreram alterações de um sprint para o outro porque foram identificadas
melhorias principalmente a nível de interface.
6.4 Requisitos funcionais
Os requisitos foram aprovados e priorizados pelo cliente (o gestor de energia da ISA) em todas as
sprint’s do projecto, primeiro através do product backlog e posteriormente através do sprint backlog.
44
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Especificação
O desenvolvimento divide-se em várias partes e inclui a integração de todas elas, podendo ser
usados módulos já existentes, na sua totalidade, parcialmente ou mesmo como base para o
desenvolvimento de cada um. Por exemplo, para visualizar custos de energia de um edifício, é
necessário o cálculo dos custos tendo em conta o tarifário em vigor, pelo que é fundamental utilizar o
módulo de cálculo de tarifários, e logo de seguida o módulo de visualização de dados. Tentou-se fazer
uma divisão bem estruturada dos vários módulos com vista a uma leitura fácil de todas as
funcionalidades do sistema e permitir uma maior facilidade na implementação e integração das várias
partes. Essa estruturação pode ser observada no diagrama de casos de uso do sistema completo, na
Figura 11, no qual as funcionalidades estão estruturadas por pacotes devido à quantidade de casos de
uso existentes. Esses pacotes representam os módulos do sistema, fazendo todos eles parte da aplicação
web e da plataforma - iEnergy -. Estão representados também dois actores de sistema, o do módulo da
aplicação de cálculo de tarifários do módulo de verificação de actuações e de alertas. Encontram-se
representados dessa forma simplificada uma vez que podem ser vistos como “externos” ao sistema.
uc Primary Use Cases
Si stema de gestão de energi a
Visualização de dados(alertas, actuação,grupos, indicadores, tarifários)
Análise de dados
Gestão de tarifários
Cliente
Gestor de energia
Visualização de ralatórios
Simulação de tarifários
Gestão de grupos
Cálculo de tarifário
Verificação de actuações
Gestão de alertas
Verificação de alertas
Administrador
Sistema
Gestão de Indicadores
Cálculo da baseline
Gestão de v irtual tags
Gestão da baseline
Gestão de actuação
Figura 11 - Casos de uso do sistema separados por pacotes
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
45
iEnergy – Eficiência Energética em Edifícios
Especificação
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
46
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Especificação
constante é usada numa operação aritmética com uma tag, é chamado indicador. Sendo estes os
indicadores de estado, existem outros indicadores que medem a performace de determinado grupo
lógico de forma a sabermos se determinado grupo está ou não dentro de determinados valores de
eficiência energética.
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 Must Have
grupos lógicos.
CGL3
Deve ser possível criar uma hierarquia de grupos lógicos.
Must Have
CGL4
Só utilizadores adicionados ao grupo lógico podem ver a Must Have
informação associada a estes grupos não podem ver mais
nenhum grupo lógico que não seja seu. Os utilizadores
administradores e os gestores de energia podem ver todos os
grupos e toda a informação associada a eles.
CGL4
Cada grupo deve ter um tipo associado, cada um desses Shoud have
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
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
47
iEnergy – Eficiência Energética em Edifícios
Especificação
a um piso que, por sua vez, diz respeito a uma instalação que,
por sua vez, diz respeito a um projecto.
Cada um destes tipos de grupos tem um conjunto de
parâmetros associados. Estes devem ser dinamicamente criados
pelo utilizador podendo estar identificados de forma diferente da
especificada anteriormente.
Cada grupo pode ter associado vários tipos de horários, Must Have
CGL6
horário de funcionamento, manutenção etc. Cada um destes
horários tem uma hora de início e de fim e um dia da semana
associado.
Os grupos lógicos podem ter associada uma baseline do Must Have
CGL7
respectivo grupo, os dados dessa base line são:

Consumo de energia activa para cada um dos meses do
ano separado por tipos de( horas de ponta horas de
cheia, horas de vazio e horas de super vazio).Ao ano 0
corresponde o ano civil anterior ao ano de configuração
da instalação.

Consumo de energia do sistema AVAC.

Consumo de energia de cada um dos utensílios
existentes no grupo lógico (maquina de café etc)
Depois de configurada a baseline, ela fica guardada no
sistema. A baseline para o ano zero é fixa sendo que para os
anos posteriores podem ser introduzidas actualizações a
baseline, como novos dispositivos ou mudanças no no sistema
de AVAC. Com estas actualizações o sistema calcula a nova
baseline tendo em conta as alterações que existiram no edifício.
Deve ser possível inserir informações associadas aos grupos Must Have
CGL8
que serão posteriormente usados para calcular indicadores de
estado.

Área
total
sujeita
a
climatização
e/ou iluminação
permanente (m2)
48

Nº de funcionários permanentes

Nº de utensílios
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios

Especificação
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 Must Have
forma a efectuar uma operação lógica entre as tags desse grupo.
CGL10
Deve ser possível associar indicadores a grupos lógicos de Must Have
forma a efectuar uma operação lógica sobre as tags desse grupo
e outros detalhes do grupo.
Tabela 6 - Requisitos de grupos lógicos
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.
Requisito
CBE1
Descrição
Prioridade
Deve ser possível criar uma baseline associada a um grupo lógico Must have
(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).
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
Must have
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).
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
49
iEnergy – Eficiência Energética em Edifícios
Especificação
Em cada altura podem ser introduzidos actualizações a baseline,
CBE3
modificações no quadro de AVAC e também nos aparelhos. Estas
Must have
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 ).
CBE4
Apenas é possível apagar a última baseline introduzida no sistema.
Para apagar um conjunto de baselines o utilizadore deve começar por
Must have
apagar da última.
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.
Requisito
Descrição
Prioridade
IND1
Indicador de performance:
Must have
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.
50
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Especificação
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:
Must have
Indicador horário, com o valor do consumo para tags do tipo energia
activa e visíveis para o utilizador.
IND3
Medida Kw/h consumido com abstracção para CO2:
Must have
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.
IND4
Indicador de temperatura:
Must have
Indicador horário, com o último valor instantâneo disponível, para a
temperatura.
IND5
Indicador de humidade:
Must have
Indicador horário, com o último valor instantâneo disponível, para a
humidade.
IND6
Indicador diário de comparação com períodos homólogos:
Must have
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.
IND7
Indicador mensal de comparação com períodos homólogos:
Must have
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.
IND8
Indicador com % de poupança global relativa ao mesmo período do Must have
ano anterior:
A comparação é feita usando o consumo dentro do ano civil até à
data actual com o período homólogo do ano anterior.
Tabela 8 - Requisitos de KPIs
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
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
51
iEnergy – Eficiência Energética em Edifícios
Especificaçã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.
Requisito
Descrição
Prioridade
Deve ser possível criar, editar e apagar indicadores de estado. Must have
IND09
Estes indicadores devem estar associados aos grupos lógicos.
As operações possíveis na criação de um indicador de estado são a Must have
IND10
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.
Os indicadores de estado podem ser vistos da mesma maneira que Must have
IND11
as tags. Através da aplicação web na forma de gráficos e relatórios.
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.
Requisito
INP-001
Descrição
Prioridade
Os indicadores de poupança são indicadores predefinidos que Must have
são vistos nos relatórios gerados pela aplicação e têm como base de
cálculo a baseline.
INP-002
52
Sempre que uma baseline é actualizada os valores dos Must have
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Especificação
indicadores de poupança devem ser actualizados também.
Os
INP-003
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.
Requisito
MNS1
Descrição
Prioridade
Deverá ser possível ao gestor de energia enviar mensagens para Must Have
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,
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
53
iEnergy – Eficiência Energética em Edifícios
Especificação
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>].
Listagem de todas as mensagens enviadas pelo operador, com Nice
MNS2
filtro por agência.
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.
Requisito
Descrição
Prioridade
TV1
Deve ser possível criar editar apagar tags virtuais.
Must have
TV2
As operações suportadas sobre as tags são a multiplicação, divisão, Must have
soma e subtracção. As operações são sempre feitas sobre duas ou mais
tags.
TV3
O resultado desta operação deve poder ser visto da mesma forma que
Must have
são vistas as tags normais. Devem também aparecer na hierarquia de
grupos na aplicação web.
TV4
As tags virtuais devem também ser agregadas segundo as agregações Must have
especificadas para esta aplicação (Hora, dia, mês).
Tabela 12 - Requisitos de tags virtuais
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
54
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Especificação
energética. Esta secção encontra-se dividida em várias sub-secções já que existem muitos requisitos
associados a análise de dados.
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.
Requisito
COGV1
Descrição
Prioridade
O gestor de energia pode ver os grupos lógicos (edifícios, Must Have
agências, AVAC, etc) e respectivos parâmetros energéticos
monitorizados (energia, tensão, corrente, etc) numa vista em
árvore hierarquizada.
COGV2
O gestor de energia pode filtra os grupos lógicos e Nice to Have
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.
COGV3
O gestor de energia pode manipular livremente os Shoud Have
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.
COGV4
O gestor de energia pode seleccionar uma tag e escolher a Shoud Have
suar conversão para outra unidade (por exemplo ver o consumo
de energia em CO2).
Notas
O interface web deve apresentar uma árvore com a seguinte hierarquia base com este formato:
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
55
iEnergy – Eficiência Energética em Edifícios
Especificação
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.
Requisito
COD1
Descrição
Prioridade
O gestor de energia pode seleccionar vários dias para Must Have
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.
COD2
O gestor de energia deve ter uma opção no calendário para Nice to Have
seleccionar todos os dias da semana de um mês (excluindo assim
os fins de semana).
COD3
O gestor de energia pode escolher um intervalo de Must Have
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).
COD4
O gestor de energia deve poder optar pela escolha da data Must Have
através da funcionalidade CO1 ou CO2. Por defeito deve estar
activa a funcionalidade CO1.
COD5
O gestor de energia deve igualmente poder configurar o Must Have
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
56
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Especificação
e a hora fim 23:59).
O gestor de energia deve ter a possibilidade de configurar a Must Have
COD6
obtenção de dados agregados (hora, dia, Mês).
O gestor de energia deve poder minimizar a área de opções Must Have
COD7
para ter maior área de análise.
O gestor de energia deve poder ter a opção de criar gráficos Must Have
COD8
de regressão linear simples para os parâmetros seleccionados.
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.
Requisito
VDG1
Descrição
Prioridade
O gestor de energia pode gerar um gráfico quando tiver no Must Have
mínimo um parâmetro energético e um dia seleccionado.
VDG2
O gestor de energia pode gerar um gráfico com base nas Must Have
opções escolhidas. Os parâmetros energéticos seleccionados
devem estar sobrepostos no mesmo gráfico bem como os
diferentes dias seleccionados (ex. se for seleccionado o dia 1 de
Março e o dia 1 de Abril estes dois devem aparecer sobrepostos).
VDG3
Os eixos do gráfico devem estar identificados com as suas Must Have
unidades (o eixo do x representa sempre o tempo com excepção
para o gráfico de regressão linear, o eixo dos y representa a
unidade dos parâmetros seleccionadas).
VDG4
O gestor de energia deve ser informado do período sazonal Nice to Have
dos dados representados no gráfico (o gráfico pode ter informação
de vários períodos sazonais).
VDG5
O gestor de energia deve ter a indicação dos diferentes Must Have
períodos horários dentro do intervalo diário. Quando existe uma
sazonalidade diferente entre os dias seleccionados é necessário
mostrar os períodos horários de maneira alternativa (Cores
quando possível, pedaços e séries diferentes).
VDG6
O gráfico deve conter uma legenda elucidativa de todas as Must Have
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
57
iEnergy – Eficiência Energética em Edifícios
Especificação
séries de dados representados nele.
VDG7
O gestor de energia deve poder ver no gráfico informação do Must Have
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.
VDG8
O gestor de energia pode ver representado no gráfico caso Must to Have
active a opção, uma linha de média, mínimo e máximo.
VDG9
O gestor de energia pode ver representado no gráfico uma
Must Have
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.
VDG10
O gestor de energia pode seleccionar o tipo de gráfico (linhas, Nice to Have
barras, Stacked Bar).
VDG11
O gestor de energia deve poder exportada o gráfico e toda Must Have
informação contida nele, bem como a tabela geral para Excel.
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.
Requisito
ACE1
Descrição
Prioridade
O gestor de energia pode consultar uma representação Must have
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.
ACE2
O gestor de energia pode ver também uma tabela com o Must have
resumo da representação gráfica de ACE1, com informação da
data, valor de consumo/ custo, e consumos/custos totais.
ACE3
O gestor de energia deve também poder ver uma segunda Must have
tabela com os custos e consumos por tipo de hora (Cheia, Vazio,
58
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Especificação
etc) e o tarifário.
ACE4
O gestor de energia pode exportar estas tabelas para o Must have
formato Excel.
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.
Requisito
CA1
Descrição
Prioridade
O gestor de energia pode também consultar uma tabela com Must have
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.
CA2
O gestor de energia pode também consultar uma tabela com o
Must have
resumo de consumos em horas de ponta.
CA3
O gestor de energia pode exportar esta tabela para o formato Must have
Excel.
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.
Requisito
TG1
Descrição
Prioridade
O gestor de energia deve poder consultar os dados contidos no Must have
gráfico na forma de uma tabela. Esta tabela deve contar com os
seguintes campos (Data/Hora, Edifício, Grupo (ex. AVAC, Geral),
parâmetro, valor, unidades).
TG2
O gestor de energia pode exportar a tabela para o formato Excel.
Must have
Tabela 18 - Requisitos de dados gerais
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
59
iEnergy – Eficiência Energética em Edifícios
Especificação
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.
Requisito
REL1
Descrição
Prioridade
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
Must have
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.
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
Must have
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.
REL3
Relatório Semanal terá de apresentar os seguintes campos para a
semana seleccionada:

Gráfico, tabela de consumos e tabela de custos da energia activa

Gráfico, tabela de consumos e tabela de custos da energia
Must have
reactiva
60

Gráfico, tabela de consumos do Facto de Potência

Gráfico, tabela de consumos da Voltagem
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios

Especificação
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.

REL4
Gráfico e tabela da Potência tomada e contratada
Relatório Mensal terá de apresentar os seguintes campos para o mês
seleccionado:

Gráfico, tabela de consumos e tabela de custos da energia activa

Gráfico, tabela de consumos e tabela de custos da energia
Must have
reactiva

Gráfico, tabela de consumos do Facto de Potência

Gráfico, tabela de consumos da Voltagem

Tabela de alarmes para o Facto de Potência com valores
inferiores a 0,94.

Tabela com os indicadores do grupo

Tabelas de poupança de energia, custo e emissões com base na
baseline da agência.

REL5
Gráfico e tabela da Potência tomada e contratada
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.

Gráfico, tabela de consumos e tabela de custos da energia
Must have
reactiva

Gráfico, tabela de consumos do Facto de Potência

Gráfico, tabela de consumos da Voltagem

Tabela de alarmes para o Factor de Potência com valores
inferiores a 0,94.

Tabela com os indicadores do grupo

Tabelas de poupança de energia, custo e emissões com base na
baseline da agência.
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
61
iEnergy – Eficiência Energética em Edifícios
Especificação
Gráfico e tabela da Potência tomada e contratada
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
Must have
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.
REL7
REL8
Semelhante a REL6 mas para energia reactiva.
Must have
As secções de Factor de Potência e de Voltagem são semelhantes às
Must have
anteriores apenas não possuem tabela custos.
REL9
Na secção de alarmes são apresentados todos os alarm triggers que Must have
apontam para a tag de Factor de Potência em que o seu valor é inferior a
0,94.
REL10
62
Na secção de indicadores de poupança são apresentadas 3 tabelas:
Must have

Poupança de energia

Poupança de custos
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios

Especificação
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 Must have
contratada em cada mês (máximo valor da potência tomada nos 8 meses
anteriores) e a potência tomada em cada mês para cada tipo de intervalo
(obtida através da divisão dos valores da tag de Energia Activa em cada
tipo de hora).
Tabela 19 - Requisitos de Relatórios
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.
Requisito
ALM1
Descrição
Prioridade
Esta funcionalidade deve funcionar da mesma maneira que os Must have
validadores no iEnergy sendo estes plugins (dll’s) que são carregados
para o iEnergy.
ALM2
Deve ser possível ver todos os alarmes configurados no sistema, Must have
activar, desactivar, criar, editar e apagar alarmes. Os alarmes são
criados sobre tags, grupos ou unidades.
ALM3
Os tipos de alarmes que podem ser configurados no iEnergy são:
Must have

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).
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
63
iEnergy – Eficiência Energética em Edifícios
Especificação

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 Must have
lista configurada nos parâmetros do alerta com a descrição do alarme.
ALM5
Deve ser possível no iEnergy listar todos os alarmes disparadosMust
pelohave
sistema. Deve também ser possível marca-los como lidos.
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.
Requisito
MA1
Descrição
Prioridade
Deve ser possível agendar actuações para cada um dos dias da Must have
semana para uma determinada hora.
MA2
Deve ser possível ver a lista de actuações, registadas no sistema vem Must have
como gerir essas actuações (adicionar, editar e apagar).
MA3
O sistema deve reconhecer automaticamente quando deve enviar uma Must have
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.
Notas
As actuações não são instantâneas devido a limitações que existem actualmente no hardware e
software. Deve no entanto ser garantido um tempo máximo para que a actuação seja enviada para os
dispositivos.
Tabela 21 – Requisitos para a actuação
64
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Especificaçã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.
Requisito
CTAR1
Descrição
Prioridade
Deve ser possível criar tarifários industriais de energia no sistema,
estes tarifários são diferentes dos que existem actualmente no iEnergy, já
Must have
que tem em conta mais parâmetros, como a energia reactiva e as
potências (potência contratada e potência em horas de ponta). Os
tarifários actuais devem ser alterados de forma a suportar estes tarifários,
mantendo os tarifários já existentes. Pretende-se cobrir os tarifários
industriais sendo eles os tarifários:
CTAR2

MAT (Muito Alta Tensão)

AT (Alta Tensão);

MT (Média Tensão);

BTE (Baixa Tensão Especial)
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,
Must have
diário, mensal);

Parâmetro - Parâmetro a que se refere (energia activa,
energia reactiva, potência);

Tipos de hora - Tipos de horas em que o parâmetro deve ser
verificado;

Preço - Custo associado ao parâmetro.
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
65
iEnergy – Eficiência Energética em Edifícios
Especificação
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
Must have
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.
CTAR4
Deve ser possível associar custos fixos aos tarifários industriais que
seram aplicados ao custo no fim de cada mês.
CTAR5
Must have
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
Must have
As temporadas têm associadas duas datas a data de início e de fim.
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
Must have
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.
Notas
Devido a complexidade relacionada com o cálculo dos tarifários esta vai ser explicada na próxima
secção deste documento.
Tabela 22 – Requisitos para o cálculo de tarifários
66
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
6.4.7.1
Especificação
Componentes Tarifárias
A estrutura geral das opções tarifárias de MAT (Muito Alta Tensão), AT (Alta Tensão), MT
(Média Tensão) e BTE (Baixa Tensão Especial) são compostas pelas várias partes especificadas neste
capítulo.
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.
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
67
iEnergy – Eficiência Energética em Edifícios
Especificação
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.
68
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Especificação
Os preços da energia reactiva são discriminados em preços da energia reactiva indutiva (ou energia
reactiva fornecida) e preços da energia reactiva capacitiva (ou energia reactiva recebida), sendo
discriminada a sua fórmula de cálculo nas secções 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.
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
69
iEnergy – Eficiência Energética em Edifícios
Especificação
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.
70
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Especificação
Para obter estes valores de energia a partir dos valores de energia reactiva nos quatro quadrantes,
deverão ser criadas as tags virtuais que respeitem as seguintes equações:
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.
Requisito
STAR1
Descrição
Prioridade
Deve ser possível comparar os vários tarifários existentes no iEnergy Must have
aplicados aos consumos de energia em históricos relativos aos grupos
lógicos.
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:
STAR4

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
Os tipos de horas usados pela simulação são configurados na área de Must have
tarifários bem como o preço das potências e das energias capacitiva e
indutiva.
STAR5
O resultado da simulação pode ser positivo ou negativo sendo que um Must have
resultado positivo significa que se estivesse a usar aquele tarifário
pouparia em relação ao outro tarifário.
STAR6
Deve ser possível exportar esta informação para Excel.
Nice to Have
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
71
iEnergy – Eficiência Energética em Edifícios
Especificação
Notas
Apenas são feitas simulações em relação aos grupos que são as raízes das árvores de grupos
lógicos. A simulação deve ser feita sobre o quadro geral de cada edifício, neste cálculo não interessa
que exista a separação por quadro AVAC, Iluminação apenas interessa o consumo total do edifício
(grupo lógico).
Tabela 23 – Requisitos para simulação de tarifários
6.5 Protótipos de Interface
Nesta secção encontram-se alguns protótipos de interface com o utilizador construídos inicialmente
para validação dos requisitos apresentados nesta secção.
Com base nos requisitos funcionais apresentados neste capítulo, foram feitos vários protótipos de
interface que foram posteriormente mostrados aos clientes a fim de validar alguns dos requisitos e de
orientar a implementação.
A descrição exaustiva de todos os protótipos construídos seria demasiado extensa e de interesse
reduzido.
Por esse motivo, nesta secção tentou-se apresentar e explicar exemplos que melhor demonstrem a
generalidade do funcionamento e visual da aplicação, assim como os casos particulares mais
importante. Estes protótipos foram construídos numa fase inicial, alguns não reflectem a aparência
final na aplicação, serviram apenas para validar alguns requisitos. Ao longo do desenvolvimento foram
adaptados as necessidades, quer para utilização quer para apressar o desenvolvimento já que devido aos
atrasos iniciais não foi possível perder muito tempo a especificar exaustivamente estes protótipos de
interface.
Tabela de Mapeamento entre requisitos e ecrãs de protótipos de interface:
Módulo
Ecrã
Módulo de Análise de dados
Figura 17, 18,19, 20 e 21.
Módulo de Alertas
Figura 22, 23 e 24.
Módulo de Actuação
Figura 25 e 26.
Módulo de Tarifários
Figura 27, 28, 29 e 30
Módulo de Grupos Lógicos
Figura 31 e 32
Tabela 24 - Ligação de requisitos a protótipos
72
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Especificação
Figura 17 - Gráfico de linhas com representação dos períodos sazonais e períodos horários
Figura 18 - Opções de Gráfico e informação de análise
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
73
Especificação
iEnergy – Eficiência Energética em Edifícios
Figura 19 - Tabela de Conclusões
Figura 20 - Tabela Geral
74
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Especificação
Figura 21 - Análise de Custos
Figura 22 - Lista de Alertas
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
75
Especificação
iEnergy – Eficiência Energética em Edifícios
Figura 23 - Criação de alertas
Figura 24 - Lista de alertas disparados
76
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Especificação
Figura 25 - Criação de actuações
Figura 26 - Lista de actuações
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
77
Especificação
iEnergy – Eficiência Energética em Edifícios
Figura 27 - Simulação de tarifários
Figura 28 - Lista de tarifários
78
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Especificação
Figura 29 - Inserção de novo tarifário
Figura 30 - Inserção de parâmetros do tarifário
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
79
Especificação
iEnergy – Eficiência Energética em Edifícios
Figura 31- Lista de grupos
Figura 32 - Página de edição de grupos
80
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Especificação
6.6 Requisitos Não - Funcionais
Existem vários requisitos de qualidade que se explicitam de seguida.
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
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
81
iEnergy – Eficiência Energética em Edifícios
Especificação
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.
82
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Especificação
É necessário ter em conta também que será um sistema usado por várias gerações de pessoas, umas
mais novas e com conhecimentos mais alargados sobre a informática e outros com poucos
conhecimentos e menos habituados ao seu uso.
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.
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
83
iEnergy – Eficiência Energética em Edifícios
Especificação
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
84
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Especificação
documentação e legislação. Também do lado do cliente foi sentido durante algum tempo a falta de
alguém com conhecimento do negócio da energia. Um membro com este perfil foi mais tarde integrado
no projecto e foi um factor decisivo no sucesso desta especificação de requisitos. O estudo inicial da
concorrência foi muito importante para esta fase, já que permitiu ter uma ideia do que é que existia e o
que é que se pretendia exactamente fazer.
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
85
iEnergy – Eficiência Energética em Edifícios Arquitectura e Implementação da Plataforma
7 Arquitectura e Implementação da Plataforma
A plataforma - iEnergy - é constituída por diversos subsistemas que estão integrados e articulados
de maneira a satisfazer os requisitos funcionais e não funcionais do sistema. Nesta secção serão mais
focados os módulos que fizeram parte do projecto de estágio nomeadamente a aplicação web o web
service e também o core do - iEnergy - onde também foi desenvolvido trabalho, bem como a base de
dados. Nesta secção são focados os detalhes de estrutura, modelos de dados e arquitectura do código
desenvolvido, assim como as interfaces principais.
A aplicação web foi implementada de raiz e no web service foi criado um novo end point para
suportar esta plataforma web. Na base de dados apenas algumas coisas foram criadas de novo ou
melhoradas ampliando a sua funcionalidade, como é o caso dos tarifários.
Um dos módulos da aplicação web, a simulação e o cálculo dos tarifários, devido à sua
complexidade foi parcialmente implementado já que apenas suporta tarifários de energia eléctrica.
Nesta fase do projecto esses módulos permitem apenas simulação e cálculo de tarifários de
electricidade, e só numa fase posterior, já fora do âmbito do estágio, é que foi implementada toda a
componente de tarifários. No entanto, mesmo com o pouco tempo disponível para realizar a
implementação do sistema, foi possível apresentar uma solução completa e todos os casos de uso se
encontram implementados.
7.1 Integração com os Vários Sistemas
A Figura 34 mostra como o - iEnergy - e a aplicação web estão posicionados em relação a outros
componentes de hardware e software e que interagem com eles directamente ou indirectamente.
Figura 34 -Como é que o portal web e o iEnergy se enquadram na solução de medição
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
87
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.
7.2.1.3
Base de Dados
A base de dados assenta sobre o Microsoft SQL Server 2008 RC2.
88
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios Arquitectura e Implementação da Plataforma
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.
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
89
Arquitectura e Implementação da Plataforma
iEnergy – Eficiência Energética em Edifícios
Após esta análise sobre a estrutura da pasta da aplicação web serão analisados alguns tópicos
relativos ao código e decisões de desenho.
Todos estes módulos estão agrupados logicamente dentro de uma pasta virtual no IDE (Visual
Studio 2010). O agrupamento é simplesmente lógico não têm nenhum efeito em como o software é
implementado. Todo o código encontra-se documentado com RDoc, o qual permite gerar
documentação navegável num browser em HTML através do código, mais os comentários e descrições
existentes.
Figura 35 - Organização do código no Visual Studio.
Como se pode ver, o software é constituído por vários módulos independentes que facilitam a
integração e desenvolvimento de novas funcionalidades ou de novos sistemas. Nas secções seguintes
vão ser descritas as implementações feitas em cada um desses módulos do sistema.
7.3 Componentes
A solução tem uma arquitectura modelar que facilita o desenvolvimento. A Figura 36 mostra os
diferentes módulos da solução que foram criados ou usados durante o desenvolvimento com excepção
para o módulo de integração com o - iCenter - que foi apenas usado para enviar a mensagem de
actuação aos dispositivos.
90
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios Arquitectura e Implementação da Plataforma
Figura 36 - Módulos do iEnergy
Segue-se uma breve descrição de cada módulo e o que foi feito em cada um deles:

Web Service – Este módulo é responsável por gerir a interacção entre sistemas remotos e o iEnergy -. Neste módulo foi criado um novo end point que serviu para dar suporte ao portal
web.

BackOffice – Este módulo é responsável por ter um interface gráfico de gestão da plataforma iEnergy -. Neste módulo foram criadas novas áreas de maneira a ser possível responder aos
requisitos supra citados com por exemplo a criação de novos tarifários entre outras
funcionalidades.

Task Scheduler – Este módulo faz uso do windows task scheduler de forma a executar código
C# em horários específicos ou procedimentos na base de dados. O uso deste modulo para
execução de procedimentos na base de dados prende-se essencialmente com as restrições
paresentadas pela versão standard do Sql Server (instalada em alguns clientes) que não permite
a criação de Jobs.

Aplicação Web – Este módulo é responsável por mostrar todas análises realizadas pela
plataforma - iEnergy -. É uma aplicação cliente que serve de interface com o utilizador final.
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
91
Arquitectura e Implementação da Plataforma

iEnergy – Eficiência Energética em Edifícios
CORE / Business Logic – Este módulo é responsável por gerir toda a lógica de dados e de
negócio ligada a plataforma - iEnergy -.

iCenter Integration – Este módulo é responsável por gerir toda a interacção entre o - iCenter e o - iEnergy -. O - iCenter - é a plataforma que recolhe todos os dados dos dispositivos
remotos.
Nas secções seguintes cada um dos módulos do sistema de interesse para o estágio são descritos
mais detalhadamente, apenas nas componentes que a ele dizem respeito.
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.
92
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios Arquitectura e Implementação da Plataforma
supplier
Tabela que armazena todos os fornecedores de tarifários de energia.
virtual_tag_parameter
Tabela que guarda as formulas usadas no cálculo das tags virtuais.
indicator
Tabela que guarda os dados referentes ao cálculo de indicados de estados.
action
Tabela que guarda os dados referentes as actuações agendadas no sistema.
group
Tabela que guarda os dados referentes aos grupos.
group_details
Tabela que guarda os dados referentes aos detalhes dos grupos que são
usados no cálculo de indicadores de estado.
Tabela que armazena dados relativos aos tipos de grupos que estão
group_type
armazenados no sistema.
Tabela que armazena dados relativos aos horários de funcionamento do
group_schedule
grupo (segurança, limpeza etc).
Tabela que armazena dados relativos os baselines de cada ano referentes à
group_baseline
energia activa, reactiva e potência.
baseline
Tabela que armazena todas as baselines do sistema.
baseline_value
Tabela que armazenam todos os valores associados as baselines do
sistema.
baseline_appliance
Tabela que armazena todos os electrodomésticos associados a uma
baseline.
hierarchy
Tabela que armazena dados relativos a hierarquia existente entre os grupos
lógicos.
indicators
Tabela que armazena dados relativos aos indicadores configurados na
plataforma.
kpi_error_log
Tabela que armazena o registo de erros durante à execução dos
procedimentos de cálculo de KPI.
kpi_conf
Tabela que armazena as configurações usadas pelos procedimentos de
cálculo de KPI.
kpi_nessage
Tabela que armazena as mensagens enviadas pelo gestor de energia.
kpi_data
Tabela que armazena dados associados aos KPI’s.
kpi
Tabela que armazena os dados associados aos KPI existentes para os quais
será feito carregamento de dados.
Tabela 25 -Descrição sumária das entidades do diagrama da base de dados
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
93
Arquitectura e Implementação da Plataforma
7.3.1.1
iEnergy – Eficiência Energética em Edifícios
Esquema Relacional
A partir do diagrama de entidade relação da BD especificou-se o esquema relacional com as
tabelas contendo as respectivas chaves primárias (PKs – Primary Keys) e chaves estrangeiras (FKs –
Foreign Keys). A ISA segue uma série de convenções próprias relativamente ao esquema relacional,
por forma a normalizar a BD para que todos a possam perceber sem grande dificuldade. Estas
convenções foram aplicadas às tabelas criadas durante o estágio. Todas as tabelas do esquema
relacional da base de dados podem ser visualizadas no Anexo V.
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.
94
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios Arquitectura e Implementação da Plataforma
Inicio
Ler dados
das tag
Tag de Tarifário?
Não
Ler Tarifário
da Tag
Não
Sim
(Data de fim- data de
inicio)=Período de
calculo ?
Calcular custos do
parâmetro
Sim
O tarifário tem
parâmetros
configurados?
SIm
Ler os
Parâmetros
do tarifário
Ler período
de calculo
Não
Fim
Figura 37 - Fluxograma de cálculo de tarifários B2B
Início
Ler conjunto
sequencial
de
baselines
Fim
Não
Sim
Existe
próxima?
Sim
Baseline do
Ano 0?
Não
Não
Já calculada?
Não
Sim
Baseline mais
recente?
Sim
Calcular intervalo
de funcionamento
da baseline
Intervalo
superior a 1
mês?
Sim
Calcular Baseline
Figura 38 - Fluxo de cálculo da baseline
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
95
Arquitectura e Implementação da Plataforma
iEnergy – Eficiência Energética em Edifícios
Todos estes procedimentos correm como Jobs na base de dados com uma periocidade configurável
ou através do agendador de tarefas do Windows.
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.
96
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios Arquitectura e Implementação da Plataforma
Inicio
Não
Não
Ler alarmes
configurados
no sistema
Passou o período
de verificação?
Sim
Sim
Enviar Email
Não
O alarme esta dentro
dos parâmetros?
Lançar alarme e
enviar mail
Sim
Terminou o período de
avaliação do alarme?
Fim
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
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
97
Arquitectura e Implementação da Plataforma
iEnergy – Eficiência Energética em Edifícios
desenvolvimentos que foram efectuados no core da aplicação foi mantida esta estratégia, sendo criados
novos repositórios para suportar as funcionalidades criadas.
Estes repositórios foram posteriormente usados pelo web service para retornar os dados necessários
à aplicação web. Foram também usados no BackOffice do software para construir os interfaces
necessários aos CRUD das entidades.
Figura 40 -Diagrama de classes Core (apenas a parte criada durante o estágio)
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
98
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios Arquitectura e Implementação da Plataforma
o WCF com uma arquitectura SOA. O WCF é uma arquitectura orientada a serviços que permite o
suporte a computação distribuída onde os serviços têm consumidores remotos. Clientes podem
consumir múltiplos serviços e serviços podem ser consumidos por múltiplos clientes. Estes serviços
tem tipicamente um interface WSDL que qualquer cliente WCF pode consumir independentemente da
plataforma em que está hospedado.
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
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
99
Arquitectura e Implementação da Plataforma
iEnergy – Eficiência Energética em 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.
Consumidor
Fornecedor
XML
HTML,JSON
XML
Browser
iEnergy4Buildings
IIS
.NET Framework
Consumer API
Intranet
iEnergy2 Server
Services Provider
Figura 43 - Arquitectura Web Service
100
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios Arquitectura e Implementação da Plataforma
O web service disponibilizado pelo - iEnergy - permite que aplicações se conectem e interajam
pela rede. Construído no topo dos protocolos de internet existentes como o HTTP e o XML, estes
permitem a partilha de informação na rede: Internet, Intranet, ou Extranet.
Este Web Service e constituído por componentes de software que podem ser chamados
remotamente com Simple Object Access Protocol (SOAP). Este web service esta descrito em mais
pormenor na secção 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.
Web Application
Web Browser
HTML
Services
Services
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;
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
101
iEnergy – Eficiência Energética em Edifícios
Arquitectura e Implementação da Plataforma

Lógica de Negócio (Controller): É a camada intermédia na qual se faz a comunicação com o
web service e com o interface do sistema. Nesta camada é onde os dados são processados e
tratados, sendo também feita a comunicação com os vários módulos que compõem o sistema.
Esta camada é responsável por garantir um bom funcionamento, no geral;

Base de Dados (Model): Camada na qual é feito o armazenamento da informação. Essa
informação inclui as tags, informação associada e informação dos tarifários, entre outros.
uc Use Case Model
Interface com o utilizador(View )
Logica de negocio(contoller)
Base de dados (Model)
Figura 45 - Decomposição Horizontal
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.
102
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios Arquitectura e Implementação da Plataforma
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.
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
103
Arquitectura e Implementação da Plataforma
iEnergy – Eficiência Energética em Edifícios
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.
104
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios Arquitectura e Implementação da Plataforma
Figura 12 - Diagrama de classes do Model
Todo o código encontra-se documentado através do uso de NDoc, contendo as definições de todos
os métodos e classes.
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.
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
105
Arquitectura e Implementação da Plataforma
iEnergy – Eficiência Energética em Edifícios
Em relação às classes referentes aos módulos dos casos de uso da aplicação, contêm os métodos
referentes a cada caso de uso. Nestas classes cujo nome termina em Controller são disponibilizados
métodos para listas com paginação, criar, pesquisar editar e remover os objectos que essa classe gere.
A classe ExcelController permite exportar todo o tipo de dados para ficheiros Excel. A
AccountController disponibiliza métodos para realizar a autenticação com a camada model assim como
métodos para fazer a gestão da própria conta de utilizador.
Na Figura 47 pode-se analisar o diagrama de classes desta camada, contendo os nomes dos vários
métodos de cada classe (sem os parâmetros, para simplificar o diagrama).
Figura 47- Diagrama de classes do Controller
106
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios Arquitectura e Implementação da Plataforma
Todo o código encontra-se documentado através do uso de NDoc, contendo lá as definições de
todos os métodos e classes.
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
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
107
Arquitectura e Implementação da Plataforma
iEnergy – Eficiência Energética em Edifícios
parcials para listagem, entre outras. Com excepção para a pasta de layouts, ou seja: a pasta de layouts
contém o layout da aplicação web, existindo um master layout que é usado por todas as outras vistas.
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).
108
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios Arquitectura e Implementação da Plataforma
Figura 49 - Diagrama de classes dos helpers do view
Todo o código encontra-se documentado através do uso de NDoc, contendo lá as definições de
todos os métodos e classes.
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
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
109
Arquitectura e Implementação da Plataforma
iEnergy – Eficiência Energética em Edifícios
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
110
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios Arquitectura e Implementação da Plataforma
teste de carga à árvore criando os 400 grupos de forma a ser possível identificar possíveis
optimizações. Neste teste de carga foi possível ver que a árvore não suportaria o número de grupos que
estavam definidos.
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.
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
111
Arquitectura e Implementação da Plataforma
7.5
iEnergy – Eficiência Energética em Edifícios
Testes unitários
Durante o desenvolvimento foram elaborados testes unitários para validar as funcionalidades que
iam sendo construídas. Estes testes visaram apenas cada um dos módulos individualmente. Serviram
para ter um conjunto de testes de regressão com cobertura de código próxima dos 80%. Nem tudo foi
submetido a testes unitários, mas sim apenas os módulos em que se justificava, tais como, por
exemplo, o cálculo de tarifários assim como os novos repositórios implementados no core da aplicação
e os métodos do web service. Na aplicação web não foram realizados testes unitários já que a maior
parte da lógica estava do lado do web service e não me pareceu que se justificasse o esforço que seria
testar a mesma coisa duas vezes.
7.6 Opinião
Todos os requisitos que foram especificados na secção 6 foram implementados com sucesso,
apesar de haver espaço para a melhoria de alguns deles e para a introdução de outros. A maior
dificuldade na implementação prendeu-se com o facto da pouca experiência que se tinha com as
tecnologias de desenvolvimento usadas durante o projecto de estágio, tendo por isso sido necessário
algum tempo suplementar. Foram também sentidas dificuldades na implementação de alguns requisitos
por não terem uma especificação completa, pelo que se teve muitas vezes de esclarecer requisitos na
fase de implementação de forma a certificar-me que o que era implementado era o que o cliente
realmente pretendia.
112
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
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.
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
113
Verificação e Validação
iEnergy – Eficiência Energética em Edifícios
Tipos de teste
Cada um dos casos de teste efectuados ao software está associado a um ou mais requisitos de um
desses programas. Uma vez que o software possui requisitos funcionais e não funcionais, foram
igualmente especificados testes destes dois tipos para serem executados sobre todo o software
desenvolvido.
Métodos de teste
Geralmente são considerados três métodos diferentes para a realização de testes – os testes de caixa
preta, os de caixa branca e os de caixa cinza:
Testes de caixa preta – Testes efectuados sem conhecimento da implementação interna da
aplicação que é testada [23].
Testes de caixa branca – Testes realizados com conhecimento prévio do código fonte que
implementa o software que é testado [23].
Testes de caixa cinza – Testes que partilham características dos testes de caixa preta e de caixa
branca, uma vez que apenas é testado o comportamento exterior do programa (tal como nos testes de
caixa preta) mas em que existe conhecimento do seu código fonte (tal como nos testes de caixa
branca), o que permite escolher os casos de teste a fazer de uma forma mais informada [23].
Níveis de teste
Existem diversos níveis a que podem ser realizados casos de teste a software. No caso da aplicação
a desenvolver no âmbito do estágio “iEnergy - Eficiência energética em edifícios” considerei que faria
sentido submetê-las a testes unitários (já mencionados na secção de implementação), de componentes,
de regressão, de aceitação, de integração e de sistema (testes funcionais) e de carga, de estabilidade e
de segurança (testes não funcionais).
Os testes funcionais testam partes do código (geralmente funções ou métodos e classes, se o
software tiver sido implementado com recurso a programação orientada a objectos). Ainda dentro dos
testes funcionais justifica-se fazer testes de integração de sistema, uma vez que a aplicação
desenvolvida está integrada com um sistema complexo. Em termos de testes não funcionais, os testes
de carga procuraram, sobretudo, avaliar a escalabilidade do software desenvolvido.
8.3 Verificação
O software foi entregue ao cliente, pelo que este realizou uma verificação que consistiu numa
avaliação da solução implementada.
O resultado desta verificação foi que o software estava pronto para produção. Contudo foi retirada
a funcionalidade de actuação desta publicação já que não foi possível testá-la a fundo. Tratando-se de
uma funcionalidade que poderia trazer alguns problemas, foi decidido não a incluir na produção nesta
114
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
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.
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
115
iEnergy – Eficiência Energética em Edifícios
Conclusões e Perspectivas Futuras
9 Conclusão e Perspectivas Futuras
9.1 Planeamento Efectivamente Seguido
Como é habitual, o planeamento de um projecto de software não é tarefa fácil! E muitas vezes o
planeamento inicial não é conseguido, por diversos factores. Esta secção pretende justificar os atrasos
ocorridos quer no primeiro semestre, quer no segundo. O período de estágio decorreu sempre nas
instalações da ISA, com excepções pontuais tais como trabalho realizado esporadicamente fora da
empresa, e reuniões com o orientador do DEIS/ISEC.
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
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
117
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
118
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Conclusões e Perspectivas Futuras
aplicação desenvolvida (que já tinha sido iniciada no primeiro semestre), o que demorou cerca de cinco
semanas. Durante esse período de tempo foram definidas as linguagens de programação e tecnologias
que foram posteriormente utilizadas na fase de implementação. De seguida foram construídos alguns
protótipos com as tecnologias de gráficos e de relatórios.
A implementação demorou cerca de três meses e, por fim, a escrita do relatório foi feita ao longo
de todo o semestre, documentando o trabalho à medida que este foi realizado. Nesta fase não existiram
desvios para o planeamento que feito inicialmente.
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
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
119
Conclusões e Perspectivas Futuras
iEnergy – Eficiência Energética em Edifícios
relativamente às empresas de Tecnologias da Informação. Com esta experiência obtiveram-se diversos
ganhos tanto na área tecnológica como na pessoal. Para que o se tenha obtido a eficiência desejada,
contribuiu em grande parte a afinidade existente com as actividades realizadas e mesmo com o
software desenvolvido na empresa, dado que esta é uma área em que se tinha bastante interesse.
A preocupação da empresa em garantir a qualidade dos seus produtos e em garantir a colaboração e
comunicação entre todos os seus colaboradores foi algo sempre presente e observável. Isto
proporcionou que adquirisse muito rapidamente maior qualidade pessoal e profissional no
desenvolvimento prático das técnicas que já conhecia. Uma das características marcantes neste projecto
e que talvez seja o seu principal factor de sucesso, foi a multidisciplinaridade. Desde a fase de
concepção, diversos profissionais das áreas de energia, hardware, software e marketing estiveram
envolvidos. Estas múltiplas visões acerca do problema possibilitaram que a aprendizagem fosse guiada
com maior heterogeneidade, observando as várias dimensões envolvidas, garantindo o alinhamento
estratégico entre tecnologia, usabilidade, gestão de energia, parcerias comerciais e anseios do mercado
consumidor.
Este estágio iniciou o estudo e especificação de requisitos do mercado B2B na área de energia da
ISA. Este estudo e especificação ocuparam uma grande parte do tempo útil do estágio, havendo
inicialmente apenas o documento inicial elaborado pelo departamento de marketing da ISA. Pode-se
dizer, em suma, que durante o estágio se concluiu com sucesso a criação do sistema previsto, tendo-se
implementado o que era mais prioritário por forma a ter-se um sistema base completo, que poderá no
futuro ser complementado com novas funcionalidades.
As tecnologias que foram utilizadas revelaram-se adequadas à solução proposta, e permitem ainda
realizar um melhoramento significativo numa próxima fase, uma vez que disponibiliza um grande
leque de facilidades. Estas facilidades passam pela existência abundante de plugins, os quais devido à
sua enorme quantidade e complexidade não foram possíveis de estudar durante os nove meses de
estágio. No entanto, serão certamente uma mais-valia no melhoramento do sistema desenvolvido.
O modelo MVC adoptado na divisão da aplicação em camadas distintas com funcionalidades bem
definidas, foi crucial para se realizar um melhor desenvolvimento do sistema, onde a detecção e
correcção de erros foram mais facilmente realizados.
Desta forma, o trabalho desenvolvido durante o estágio cumpriu todos os objectivos a que se
propunha.
Por último, após todos os pontos enunciados, pode concluir-se que o projecto se está a revelar de
grande sucesso, na sua área.
120
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Conclusões e Perspectivas Futuras
9.3 Trabalho Futuro
Como já foi referido nas secções anteriores, esta plataforma é constituída por vários módulos por si
só de uma complexidade considerável. No futuro imediato pretende continuar-se o desenvolvimento da
plataforma - iEnergy - acrescentando-lhe novas funcionalidades: por um lado, evoluir o software e
incluir características tais associadas a tempo real; por outro lado, evoluir as funcionalidades já
implementadas (como é o caso da actuação), de forma a permitir não só a do tipo agendada mas
também a automática, em caso de ocorrências anormais, em estreita relação com os alarmes. Existe
ainda espaço para introdução de melhorias nas funcionalidades que foram construídas no âmbito deste
estágio. A curto prazo, deverão ser claramente identificadas e introduzidas no software.
Devido ao tempo reduzido do estágio não foi possível realizar testes de carga exaustivos. Por esse
motivo e como se pretende que o sistema responda eficazmente, tendo em simultâneo muitas
funcionalidades, será também necessário efectuar testes mais exaustivos e com maior carga do que
aquela a que o sistema já foi sujeito.
Num futuro próximo a plataforma irá evoluir para outros mercados como o mercado B2C,
chegando desta forma ao consumidor final. Oferecendo um leque alargando de funcionalidades
inovadoras, como a visualização de consumos em tempo real, melhorias à actuação entre muitas outras
coisas, permitirá ao consumidor final racionalizar a sua utilização de energia.
A longo prazo pretende-se evoluir a plataforma para produzir uma melhor análise dos consumos
energéticos, pretendendo-se introduzir técnicas de BI de forma a melhor tratar os dados recebidos,
identificando assim mais facilmente comportamentos desviantes.
9.4 Considerações Pessoais
Posso dizer que a realização deste estágio, com a duração de nove meses, foi uma experiência não
só muito gratificante como também de elevada importância, quer a nível pessoal quer a nível
profissional. Foi uma oportunidade única de conhecer por dentro o “mundo real” da engenharia
informática e poder conhecer de perto todo o processo de concepção e desenvolvimento de software.
Com este estágio tive a excelente oportunidade de trabalhar na equipa de energia da ISA em
Coimbra. Gostaria de destacar o bom ambiente de equipa e a camaradagem nela vivida, havendo apoio
e entreajuda entre os vários colaboradores, ambiente no qual fui bem recebido.
Tive ainda o privilégio de melhorar significativamente os meus conhecimentos na área de
concepção e desenvolvimento de sistemas de informação. A utilização da plataforma ASP.NET MVC e
a Entity Framework, que são bastante recentes e têm suscitado um interesse crescente por toda a
comunidade, foi também uma grande uma mais-valia.No entanto, a aprendizagem das tecnologias
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
121
Conclusões e Perspectivas Futuras
iEnergy – Eficiência Energética em Edifícios
utilizadas foi autodidacta, embora tenha tido sempre a disponibilidade de ajuda por parte dos
colaboradores da equipa de energia e o apoio indispensável do meu orientador na ISA.
As maiores dificuldades que senti foram principalmente devidas ao facto de ter de tomar várias
decisões com as quais fui confrontado pela primeira vez, nomeadamente a escolha das tecnologias a
usar, bem como o estudo, implementação e recolha de requisitos. O facto de o software ter como
objectivo ser entregue a cliente e ser operacionalizado, traduziu-se, também, num enorme sentido de
responsabilidade colocado sobre mim e num sentimento extra de dedicação e entrega da minha parte
para que tudo corresse como planeado.
Por tudo isto, posso afirmar sem sombra de dúvida que o trabalho realizado no contexto deste
estágio contribuiu de forma inequívoca para o meu crescimento, tanto a nível pessoal como a nível
profissional.
122
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
Glossário de Definições
iEnergy – Eficiência Energética em Edifícios
Glossário e definições
Infra-estrutura de medição avançada – Compreende todo o hardware e software de
comunicações e o software de sistema e de gestão de dados associados que criam uma rede entre os
contadores inteligentes e os sistemas de negócio de uma empresa geradora/fornecedora de energia que
permitem a recolha e distribuição de informação aos clientes e a outras partes tais como fornecedores a
retalho concorrentes, para além da empresa de utilidade pública em si.
Leitura automática de contadores – Sistema onde o uso (e em alguns casos a procura) agregado
de energia em – kilowatts por hora é obtido através de meios automáticos, tais como um veículo ou um
sistema portátil capaz de ser transportado na mão.
Utilização Racional de Energia (URE) - Acções conducentes à redução dos custos da energia
para o consumidor e para a economia, numa perspectiva técnico-económica de custo benefícios.
Baseline – Uma baseline é uma 'imagem' de uma versão anterior no caso da eficiência energética
de consumos passados. Ela funciona como um padrão oficial básico para outros estudos. Somente
mudanças autorizadas podem ser efetuadas na baseline. Depois de se estabelecer uma baseline inicial,
toda as mudanças feitas na baseline serão registadas como um elemento delta até a próxima baseline
ser definida.
Gestão de energia - De uma forma simples podemos dizer que a gestão de energia:
 é conhecer os consumos energéticos:
o porquê se consome a energia
o como se consome a energia
o onde se consome a energia
o quanto se consome de energia
 é contabilizar e seguir a evolução dos consumos de energia
 é dispor de dados para tomar decisões
 é agir para optimizar
 é controlar o resultado das acções e investimentos realizado
Recolha de dados
Contabilização
dos consumos energéticos
Tratamento
de informação
Tomada de medidas
correctivas
e preventivas
Elaboração
de relatórios
Glossário de Definições
iEnergy – Eficiência Energética em Edifícios
Figura 53 - Ciclo de Gestão de energia
Eficiência energética - Eficiência energética é um conceito generalizado para referir as medidas a
implementar (ou implementadas) bem como os resultados alcançados na redução do crescimento da
procura de energia ou, mais genericamente, na melhor utilização da energia. As medidas de eficiência
energética estão normalmente associadas a medidas políticas ou ao resultado de actos de gestão
energética.
Os instrumentos mais usuais para medir a forma como a energia é utilizada, quer ao nível micro
quer ao nível macroeconómico, são os indicadores energéticos. Existe, assim, um universo de
indicadores que permitem, no seu conjunto, estabelecer uma série de avaliações e comparações, quer
estáticas quer dinâmicas, sobre o estado da eficiência energética.
Gestão da procura de Energia - Acções de Gestão cujo objectivo é modificar a estrutura da
procura de energia com vista à redução de custos.
Conservação de Energia - Redução da quantidade de energia consumida para uma determinada
prestação energética.
Economias de Energia - Quantifica as reduções no consumo de energia, relativamente a um valor
de referência.
Eficiência Energética - Caracteriza a forma como a energia é usada na economia
Melhorias na Eficiência Energética Resultado de acções de Utilização Racional de Energia.
Indicadores Energéticos - Relações e variáveis usadas para medir a eficiência energética.
Web Methods- Motor de integração de aplicações, com capacidades de comunicação e
transformação de mensagens.
Windows - Família de sistemas operativos da Microsoft.
WEB - Aplicação da Internet baseada em páginas de hiper-texto, com conteúdos multimédia.
Torniquetes - Controlam a entrada de passageiros na embarcação permitindo ao sistema calcular
as cargas de cada percurso com base em informação estimada de passageiros e combustível.
Unidade GPS - Permite saber a cada instante a posição, velocidade e outros dados de interesse
relativos às diversas embarcações a monitorizar.
Caudalímetro - Permite a monitorização de consumos instantâneos. Em conjunto com o
datalogger permitirá o cálculo dos consumos entre horários. Será a fonte da informação de consumos
energéticos a utilizar na solução.
124
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Glossário de Definições
Monitorização de nível de combustível - Permite a monitorização dos níveis de combustível em
cada tanque da embarcação. Terá associada uma plataforma de gestão de alarmes que permite a
notificação instantânea das falhas de combustível.
TAGs RFID - para ancoradouros permitem detectar com exactidão as atracagens dos navios,
permitindo a separação clara dos tempos em carreira de outros tempos. Instalados nas oficinas ou
outros ancoradouros permite igualmente detectar com exactidão a posição da embarcação quando
parada. É um complemento ao DGPS facilitando a detecção da localização/estado do navio.
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
125
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]
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
127
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.
128
Pedro Saraiva – Relatório da disciplina de Estágio/Projecto Industrial 2010/2011
iEnergy – Eficiência Energética em Edifícios
Anexo I – Estado de Arte
Anexo I – Estado da Arte
Estudo de Estado de Arte
Out. 2010
3
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 Introdução
Neste documento é apresentado o estudo detalhado de alguns Softwares de gestões energéticas
existentes no mercado. Os principais competidores da plataforma iEnergy e os seus produtos
(funcionalidades e tecnologias usadas) estão descritos neste documento.
Sendo que os principais competidores presentes neste documento são: PulseEnergy, Enigin,
Plus-Energy, Advanced Telemetry, Energy Metering Technology Ltd, AgileWaves, Vision BMS,
Noveda, Synapsense, Schneider Electric, Johnson Controls. Não foi possível para nenhuma destas
empresas saber os custos para utilização das suas soluções.
PulseEnergy oferece tecnologia para melhorar a gestão de energia e assim aumentar a
produtividade nos edifícios. A solução da PulseEnergy combina Hardware com Software que
recolhe informações referente a variáveis enérgicas e permite que os utilizadores consultem esses
dados através de uma aplicação Web, os utilizadores podem consultar comparativos e custos de
energia através da internet.
Plus-Energy é uma empresa portuguesa de ESCO (Energy Services Company) especializada
investigação, desenvolvimento e implementação de soluções adaptadas as necessidades dos seus
clientes nas áreas da gestão de energia e gestão de edifícios. Os seus serviços envolvem actividades
de auditoria, implementação de medidas de racionalização de energia, desenho e escala de locais de
produção energeticamente mais eficientes (energia tradicionais e renováveis), manutenção de
sistemas de energia, leasing de equipamentos e financiamento de projectos.
Advanced Telemetry oferece soluções para ajudar os seus clientes a reduzir o seu consumo de
energia e aumentar as poupanças. A sua linha de produtos chamada EcoView permite aos
utilizadores que facilmente vejam, giram, e reduzam o seu consumo de energia através de uma
aplicação Web.
Energy Metering Technology Ltd oferece soluções para gestão de consumo de energia e água
através do uso de tecnologias emergentes de monotorização e comunicação. A sua solução é
composta por quatro produtos: DATACHICK que é um sistema de monotorização automática para
edifícios, DATABIRL para vários edifícios, DYNAMAT para monitorar e orientar os consumos de
energia e TURNKEY, uma solução final que inclui o Hardware, Software e outros serviços para
gerir todo o processo desde a consulta até a instalação e suporte.
AgileWaves é uma empresa sediada em Menlo Park, California que oferece um sistema de
monotorização e gestão de energia. A sua solução oferece um sistema de optimização de edifícios
que oferece ao gestor do edifício e aos donos dos mesmos dados em tempo real, métricas rigorosas
para aumentar a eficiência energética, reduzindo os custos e atender as exigências de controlo de
CO2.
Vision BMS é uma companhia formada em 2007 como vinda do Barco group. BMS fornece
serviços de execução de sistemas de fabrico para produção discreta, com foco no sector têxtil,
plástico e industria farmacêutica. Sob a marca BarcoVision, BMS oferece uma gama de sensores e
sistemas que visam a produtividade e melhoria da qualidade. Eles têm uma solução de energia que
segue o princípio de monitoramento e visionamento.
1
Estado da arte
Synapsenseoferece uma solução baseada em Wireless de sensores que oferece uma redução do
consumo de energia e da pegada de carbono em data centers e empresas.
Schneider Electric é uma especialista em gestão de energia com operações em mais de 100
países, Schneider Electric oferece soluções para diferentes segmentos do Mercado, incluem
posições em energia e infra-estruturas, processos industriais, automação de edifícios e data
centers/networks, é também com grande presença em aplicações residenciais.
Raritan oferece uma solução de gestão de potência e energia, Kernel based virtual machine
(KVM) e soluções de acesso.
Enigin oferece produtos para controlar, reduzir e eliminar as enormes contas de energia. Eles
têm uma solução para poupar energia em controlos de motores, controlos de luz, ar condicionado e
refrigeração. A sua solução oferece Software e Hardware para visualização de dados em tempo real
e para análise de informação. A informação em tempo real e disponibilizada por uma aplicação
desktop e as análises são fornecidas por uma aplicação Web.
Johnson Controls é um fornecedor de equipamentos, controlos e serviços para aquecimento,
ventilação, ar-condicionado, refrigeração e segurança em edifícios. Oferecem uma solução
“Metasys building management” que integra Hardware e Software com capacidade Wireless. Os
gestores dos edifícios são capazes de perceber e melhorar o consumo e custo da energia nos seus
edifícios.
2
Estado da arte
2 Funcionalidades
Nesta secção estão listadas as funcionalidades dos competidores e uma breve descrição dessas
mesmas funcionalidades.
As principais funcionalidades da competição são:







Dashboard View – Os utilizadores podem ver numa única página várias
análises/indicadores relevantes para a análise energética. Aqui alguns dos competidores
oferecem a possibilidade de configuração deste dashboard com outras análises que sejam
relevantes.
Real time análise – Esta funcionalidade permite que os utilizadores possam ver
exactamente para onde a energia esta ir, Segundo a Segundo.
o Consumo e custos de energia ao minuto.
Alertas – Se o utilizador exceder o consume ideal o mostrador muda de cor para avisar de
potencial desperdícios.
o Alarmes configuráveis – O utilizador pode configurar alertas para serem enviados
quando alguma coisa de invulgar acontecer.
o Os alertas podem ser enviados por SMS ou Correio electrónico.
Carbon Footprint – Os utilizadores podem seguir e reduzir a sua pegada de carbono através
da observação dos efeitos de decisões inteligentes e percebendo o seu impacto.
Gerações de relatórios – As análises podem ser mostradas de várias formas:
o Análises de tendência e histórico de comparativos.
o O histórico de consumo de energia pode ser comparado em através de dias,
semanas, meses ou até anos.
o Qualquer informação mostrada pode ser impressa para criar um relatório ou
descarregada para um spreadsheet para posterior análise.
o Detalhes de análises por piso, sala, dispositivo, circuito ou utilidade.
o Análise de gráficos pode ser configurada pelos utilizadores.
Análises de custos – Os utilizadores podem converter dados numa linguagem que todos
entendem - dinheiro.
o Os utilizadores podem reproduzir a conta de energia de acordo com uma estrutura
de tarifário.
o Os utilizadores podem aceder a previsões daquilo que poderão gastar na próxima
semana ou mês de forma a poderem fazer o seu orçamento de acordo ou tomar
medidas para reduzir o consumo.
o Os utilizadores podem aceder a contas passadas e comparar com as mais recentes.
o Os utilizadores podem analisar e simular a optimização do tarifário.
Os Amps, Voltagem & Factor Potência – Os utilizadores podem observar e entender o
consumo de energia de uma forma melhor. São a fases desequilibradas a ponto de expor o
sistema a falha do equipamento em massa? Está a tensão for a dos limites aceitáveis
adicionar 10% a mais a conta de energia? É o fraco factor potência que esta a diminuir a
capacidade e provocando multas desnecessárias de a empresa concessionária?
o Simulação do factor potência – O factor potência pode ser simulado para
correcção.
3
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Consumos em tempo
real
Relatórios (gráficos e
análises)
X
Gráficos
customizados
X
X
X
X
X
X
X
X
X
Alertas de aletas por
email
Envio de alertas por
SMS
X
Alertas no ecrã
X
X
Tabela 1 -Funcionalidades dos principais concorrentes
Alarmes
configuráveis
X
Vista de alertas com
detalhes
X
X
X
X
X
Download de análises
em vários formatos
X
X
X
X
X
X
X
X
X
X
X
X
Custos de energia
Previsão de custos de
energia
X
X
X
X
Análise de custos
para optimização
Opções de tarifários
X
X
X
X
X
X
X
X
X
X
X
Comparação de
vários locais
Simulação de factor
potência
X
X
X
X
X
Comparação de
várias divisões
X
X
X
X
Detalhes por divisão
X
X
Google Mpaps para
seleccionar local
Estado da arte
X
X
X
X
X
X
X
X
Dashboard View
A tabela seguinte mostra os competidores em análise e as funcionalidades que oferecem:
Pulse Energy
Enigin
Plus-Energy
Advanced
Telemetry
Energy
Metering
Technology
AgileWaves
Visionbms
Noveda
Synapsense
(Data
Centers)
Schneider
Electric
Johnson
Controls
Raritan
4
Pegada de carbono
Estado da arte
3 Tecnologias
Nesta secção é feito um breve resumo do estudo das tecnologias usadas pelos principais
competidores nos seus produtos. A tabela seguinte mostra a comparação entre cada um dos
competidores em termos de tecnologias.
Aplicação
móvel
NA
Aplicação
Web
A
Aplicação
desktop
NA
A
A
A
NA
NA
A
A
NA
NA
ASP.net/C#
NS
NS
NS
NS
NS
.NET
SqlServer
NA
NA
A
. NET
API for 3rd
party
NA
A
Flash…
A
API for 3rd
party
NA
MySQL/Or
acle/SqlSer
ver
NS
Synapsense
Schneider Electric
Raritan
NA
NA
NA
NA
NA
A
A
A
NA
Johnson Controls
A
A
A
Pulse Energy
Enigin
Plus-Energy
Advanced
Telemetry
Energy Metering
Technology
Visionbms
AgileWaves
Noveda
Tecnologias
DB
Flash,
Spring(J2EE)
PHP,.NET,
Flash,
JavaScript and
PERL
NS
PHP, Perl,
Flash
NS
(Windows)
J2EE,
Ajax/Flash/Fle
x
JAVA,JSP/J2E
E
NS
MySQL
NS
NS
NS
NS
Tabela 2 - Tecnologias dos principais concorrentes
Legenda:



A – Disponível
NA – Não disponível
NS – Não especificado
5
Estado da arte
4 Análise gráfica
Nesta secção são apresentadas uma série de análises gráficas que mostram a relação entre
funcionalidades e tipo de tecnologias usadas pelos competidores.
Na primeira imagem podemos ver que os competidores que têm menos funcionalidades; por
análise do gráfico podemos ver que a Enigin é a companhia com mais funcionalidades
implementadas e a Synapsense com menos.
Figura 1: Competidores por número de funcionalidades
A próxima imagem mostra que tipo de tecnologias são usadas pelos competidos nos seus
produtos: Fechadas ou abertas. Pela análise do gráfico podemos concluir que as fechadas são
usadas com mais frequência.
Figura 2: Tipo de tecnologias
Na última imagem podemos observar um gráfico que junta as duas análises anteriores: o tipo
de tecnologias usadas e o número de funcionalidades dos competidores. O eixo horizontal
6
Estado da arte
representa a complexidade dos produtos em número de funcionalidades o eixo vertical representa
as tipo tecnologias usadas: tecnologias abertas ou fechadas. Para cada competidor, quanto maior for
o valor no eixo vertical, mais fechadas são as tecnologias que usa. Como podemos ver, quatro
companhias usam apenas tecnologias fechadas e apenas uma usa só tecnologias abertas. Todos os
outros competidores usam uma mistura de tecnologias abertas e fechadas nas suas soluções.
Figura 3: Relação entre tecnologias e complexidade (número de funcionalidades)
7
Estado da arte
5 Software de gestão energética
Sim.
Versão
web?
345€ por licença.
Grátis.
Preço
Necessita de
ligação à
Internet?
Sim.
Não.
Não especificado.
Sistemas
operativos
Não.
Não.
Disponível
para o
público em
geral?
Sim.
Penso que não.
Ainda não.
Windows 98 ou
mais recente.
Sim.
Todos (à partida,
uma vez que é
web based).
Windows 2000 ou
mais recente.
Sim
Sim
Sim.
.
Não especificado.
Não necessariamente
(só algumas versões
necessitam).
.
O preço varia muito com a
versão da aplicação e com
outros parâmetros. Versão
client/server: desde $50,000
até $200,000. Versão
online: a partir de $3,000
por ano para organizações
mais pequenas. Versão
Desktop and Campus:
Desde $15,000 até $40,000.
Não especificado;
depende de alguns
Sim.
Todos (à partida,
uma vez que é
Sim.
Nesta secção são apresentadas mais algumas soluções de outras empresas já presentes no mercado.
Descrição
PowerMeter
Ferramenta de
monitorização dos gastos
de electricidade e gás
numa habitação.
Aplicação
Energy Lens
Metrix 4 Utility
Accounting
System
EnergyCAP
Ferramenta de
monitorização e de
Ferramenta de
monitorização dos gastos
de electricidade num
edifício.
Ferramenta de
monitorização dos gastos
de energia (electricidade,
gás natural, água, óleo
para aquecimento, gás
propano, gás LP, resíduos
sólidos, águas residuais)
num edifício.
Ferramenta de
monitorização e gestão do
consumo de energia (água
e gás, pelo menos) e de
processamento das contas
associadas.
Energy Expert
8
Notas
Encontra-se em versão beta
e neste momento apenas
pode ser testado pelos
empregados do Google e por
um grupo restrito de
clientes. Necessita que as
habitações onde seja
utilizado tenha um contador
inteligente para funcionar.
Precisa do Excel 97 ou mais
recente para funcionar.
Precisa do Excel 2003 ou
mais recente para funcionar.
Surveyor
NightWatchman
Power
Management
Hohm
MarketManager
Ferramenta que permite
gerir a energia consumida
por vários computadores
ligados em rede de forma
centralizada.
previsão dos gastos de
energia (mais
eficientemente
electricidade mas também
gás) e de picos de corrente
num edifício. Permite
também calcular a
poupança energética
realizada.
Ferramenta que permite
monitorar e simular os
gastos energéticos em
edifícios e prever o efeito
da aplicação de
determinadas medidas
energéticas nos mesmos.
Ferramenta de
monitorização dos gastos
de energia numa habitação
que fornece conselhos
personalizados sobre
poupança de energia.
Ferramenta que permite
gerir a energia consumida
por vários computadores
ligados em rede de forma
centralizada.
Ferramenta que permite
gerir a energia consumida
por vários computadores
ligados em rede de forma
centralizada.
Sim.
Sim.
Windows 2000 ou
mais recente e
Apple Mac OS X.
Windows Vista
(Business,
Enterprise,
Enterprise x64 e
Ultimate) e
Windows XP SP2
e mais recentes.
Windows Vista,
Vista x64,
Windows XP e
Windows 2000
Professional SP4
(ou mais recente).
Sim.
Sim.
Sim.
Windows Azure.
Windows.
web based).
Penso que não.
Não.
Penso que não.
Sim.
Não.
Penso
que não.
Não.
Penso
que não.
Sim.
Penso
que não
Não especificado, mas não
é grátis.
Não especificado, mas não
é grátis.
Não especificado.
Grátis.
$1095.
parâmetros.
9
Precisa do Windows Server
2008, 2008 (x64) ou
Windows Server 2003 SP2
para o servidor e do SQL
Server 2008, SQL Server
2005 SP2 & Express Edition
ou Microsoft SQL Server
2000 para a base de dados
Pode também ser adquirido
como parte da suite Systems
Lifecycle Management.
Ainda só há versão beta e
esta apenas se encontra
disponível para os
utilizadores dos Estados
Unidos da América.
Estado da arte
Ferramenta de cálulo de
poupança energética em
computadores (para um ou
vários).
Ferramenta de cálculo de
poupança energética em
computadores (para um ou
vários).
Widget que recolhe os
dados da poupança
energética acumulada
associada ao desligamento
dos computadores dos
utilizadores quando estes
não estão a ser utilizados.
Gadget de gestão
Ferramenta de gestão
energética em
computadores (apenas
para um).
Ferramenta que permite
controlar as opções de
gestão energética de forma
centralizada de vários
computadores usando
group policy objects.
(GPO).
Ferramenta de gestão
energética em
computadores (apenas
para um)
Ferramenta de
cálculo de poupança
energética em
computadores (para um ou
vários).
Ferramenta que
permite fazer a gestão
energética de vários
computadores.
Estado da arte
Edison
EZ GPO
EZ Wizard
Client energy
calculator
Power Save
Online energy
savings
calculator
Advanced Power
Save ROI
Calculator
Hewlett-Packard
Power To
Change
Energy Saver
10
Windows XP
(SP2) ou
Windows Vista.
Sim.
Não.
Não.
Grátis.
Grátis.
Grátis.
Penso
que não.
Não.
Penso que não.
Não.
Sim.
Sim.
Windows 2000 e
XP.
Não.
A partir de 5.29€ (para uma
licença e um ano de Power
Save Maintenance Package,
para Portugal, na categoria
educação).
Grátis.
Grátis.
Não.
Sim.
Grátis.
Sim.
Sim.
Sim.
Sim.
Sim.
Windows e Mac
OS X.
Sim.
Sim.
Sim.
Todos (à partida,
uma vez que é
web based).
Sim.
para funcionar.
Versão grátis e mais leve do
Surveyor.
Os administradores de rede
têm de correr Windows
Active Directory.
Só permite simular o
consumo em sistemas
Hewllett-Packard (e não
todos).
Widget que recolhe dados e
envia-os para um servidor
via Internet embora
necessite de interacção com
o utilizador.
Todos (à partida,
uma vez que é
web based).
Gadget para o Google
Grátis.
Grátis.
Não.
Não.
Sim.
Sim, pelo menos para
Sim.
Todos (à partida,
uma vez que é
web based).
Windows
2000 e XP.
Sim.
Windows, Linux e
Mac OS X.
Windows
Vista/XP, Linux e
Mac OS X
ver a quantidade de
energia poupada pela
comunidade de
utilizadores do
programa.
11
Desktop. Necessita do
Google Desktop 5 ou mais
recente para funcionar.
Tabela 3 – Resumo das características mais importantes das principais aplicações de gestão energética existentes no mercado
energética em
computadores (apenas
para um).
Estado da arte
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 Introdução
Neste documento são apresentados os casos de uso do software de gestão energética que se
pretende implementar. O software é composto por vários módulos que contem diferentes
funcionalidades dentro de si, com este documento pretende-se apresentar os principais casos de uso
do sistema.
1
Casos de Uso
2 Características dos Utilizadores
Para este sistema foram identificados três actores como se descreve de seguida, com base nos
requisitos de utilizador do sistema.
Os diferentes perfis de utilizador são:
 Cliente: Tem acesso à plataforma apenas para ver indicadores (não os pode alterar) e
extrair relatórios predefinidos (não os pode alterar) dos projectos a que está alocado.
 Gestor de energia: Acesso total à plataforma não podendo no entanto gerir
utilizadores nem permissões nos grupos lógicos.
 Administrador: Acesso total à plataforma.
Pode ser vista de seguida a hierarquia entre eles no seguinte diagrama:
uc Actors
Cliente
Gestor de energia
Administrador
Imagem 1 - Hierarquia de Utilizadores
2
Casos de Uso
3 Casos de Uso do Sistema
Nesta secção são detalhados todos os pacotes de casos de utilização do sistema, através dos
seus respectivos diagramas de casos de utilização. Alguns desses diagramas contêm casos de
utilização mais complexos - com a descrição Extension points - que representam funcionalidades
pertencentes a outros pacotes. Ou seja, são uma espécie de apontadores para outro caso de
utilização existente num outro pacote. Tanto o caso de utilização como o pacote onde se encontra
são especificados nesse mesmo caso de uso mais complexo.
Na imagem 2 estão representados todos os módulos do sistema bem como os utilizadores que
acedem a eles.
uc Primary Use Cases
Sistema de gestão de energia
Visualização de dados(alertas, actuação,grupos, indicadores, tarifários)
Análise de dados
Gestão de tarifários
Cliente
Gestor de energia
Visualização de ralatórios
Simulação de tarifários
Gestão de grupos
Cálculo de tarifário
Verificação de actuações
Gestão de alertas
Verificação de alertas
Administrador
Gestão de Indicadores
Cálculo da baseline
Gestão de v irtual tags
Gestão da baseline
Gestão de actuação
Imagem 2 - Casos de uso do sistema separados por pacotes
3
Sistema
Casos de Uso
uc Class Model
Visualisação de Dados
Escolher Agregação
de dados
Exportar Dados
«include»
«extend»
Cliente
Configurar
Parâmetros de
Aquisição
«include»
Visualizar Dados de
Histórico
«include»
«include»
Escolher Grupo
Lógico
«include»
«include»
Gestor de Energia
Escolher Unidade de
Medida
Comparar Dados de
Histórico
Escolher Tag
«include»
Administrador
Gerar Regressão
Linear
Imagem 3- Diagrama de casos de uso para visualização de dados
4
Casos de Uso
uc Cálculo da baseline
Baseline
Gerir Baseline
Gestor de energia
(from Actors)
Cálcular Baseline
«include»
Ver indicadores de
poupança
Sistema
Imagem 4 - Casos de uso de gestão de baseline
uc Gestão de grupos
Gestão de Grupos
Criar Sub Grupos
«extend»
Gerir Grupos
«extend»
Adicionar
Utilizadores a grupos
Gestor de energia
«extend»
(from Actors)
Gerir Indicadores
«extend»
Adicionar Tags a
Grupos
Adicionar detalhes
Gerir Virtual tags
Imagem 5- Casos de uso para gestão de grupos
5
Casos de Uso
uc Gestão de alertas
Gestão de alertas
Ver alertas
disparados
Env iar email com o
estado do alerta
Cliente
(from Actors)
«include»
Gerir alertas
Verificar alertas
Sistema
Gestor de energia
(from Actors)
Carregar alerta
Administrador
(from Actors)
Imagem 6 - Casos de uso para gestão de alertas
uc Cálculo de tarifário
Gestão de tarifários
Consultar tarifários
Cliente
(from Actors)
Cálcular simulação
de tarifários
Ver Simulação de
tarifários
«include»
Gestor de energia
(from Actors)
Criar nov as v ersões
«extend»
Cálcular tarifários
Gerir tarifários
Sistema
Imagem 7 - Casos de uso para gestão de tarifários
6
Casos de Uso
uc Gestão de actuação
Gestão de actuação
Gerir actuação
Gestor de energia
(from Actors)
Actuar sobre o
despositiv o
«include»
Verificar actuação
Sistema
Imagem 8 - Casos de uso para gestão de actuação
7
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
No decorrer do projecto foram identificados alguns riscos para o mesmo, para cada um
desses riscos foi identificada uma estratégia de contingência.
A tabela seguinte mostra os maiores riscos do projecto:
Risco
A carga a que o sistema vai ser sujeita.
Estratégia de contingência
Testes iniciais com uma base de dados de
produção de forma a perceber como pode ser
optimizado o sistema.
Esperar demasiado da plataforma pode
Deve existir uma apresentação da solução
levar a alguns mal entendidos entre o que a para que toda a gente saiba o que é a solução.
plataforma já é vs. Aquilo que é esperado
da plataforma
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
Estudo cuidado de todas as tecnologias que
para a implementação.
são usadas na implementação, através da internet
ou livros. Implementação de protótipos usando as
tecnologias em causa.
1
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
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.14
2.15
2.16
2.17
2.18
2.19
2.20
2.21
2.22
2.23
2.24
2.25
2.26
2.27
2.28
3
RESULTADO DE UMA OPERAÇÃO ................................................................................................... 2
INDICADOR ............................................................................................................................... 2
GRUPO .................................................................................................................................... 3
DETALHES DE GRUPO ................................................................................................................. 3
TIPO DE GRUPO......................................................................................................................... 3
COLUNAS DE UM TIPO DE GRUPO ................................................................................................. 3
VALORES DAS COLUNAS DE UM TIPO DE GRUPO .............................................................................. 4
TIPO DE HÓRARIO DE GRUPO ....................................................................................................... 4
HÓRARIO DE GRUPO .................................................................................................................. 4
TAG ........................................................................................................................................ 4
PARÂMETRO DA VIRTUAL TAG...................................................................................................... 5
TARIFA .................................................................................................................................... 5
PARÂMETRO DE TARIFÁRIO .......................................................................................................... 5
CUSTOS FIXOS........................................................................................................................... 5
INTERVALO ............................................................................................................................... 6
FACTOR DE MULTIPLICAÇÃO ........................................................................................................ 6
TEMPORADA ............................................................................................................................. 6
SIMULAÇÃO DE TARIFA................................................................................................................ 6
LINHA DE SIMULAÇÃO DE TARIFA .................................................................................................. 7
UNIDADE DE MEDIDA.................................................................................................................. 7
CONVERSÃO DE MEDIDA ............................................................................................................. 7
ALERTA.................................................................................................................................... 7
PARÂMETRO DO ALERTA.............................................................................................................. 8
ALERTA DISPARADO.................................................................................................................... 8
ACTUAÇÃO ............................................................................................................................... 8
BASELINE ................................................................................................................................. 9
VALORES DA BASELINE ................................................................................................................ 9
UTENSÍLIOS DA BASELINE ............................................................................................................. 9
MÉTODOS .............................................................................................................................. 10
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
ACESSO A DADOS ..................................................................................................................... 10
GRUPOS ................................................................................................................................ 11
UNIDADES DE MEDIDA .............................................................................................................. 14
TARIFAS ................................................................................................................................. 15
ALERTS .................................................................................................................................. 16
MESSAGES ............................................................................................................................. 18
BASELINE ............................................................................................................................... 19
RELATÓRIOS ........................................................................................................................... 19
ACTUAÇÃO ............................................................................................................................. 20
Especificação Web Service
1 Introdução
Este documento tem por objectivo apresentar a especificações dos métodos criados no novo
End Point do Web Service do iEnergy (end point de edifícios).
Web Service de Edíficios
1
Especificação Web Service
2 Estruturas de dados
Nesta secção são apresentadas todas as estruturas de dados e enumerações que são usadas no
end point de edifícios. Estas estruturas são específicas para um método ou para um conjunto de
métodos que as podem utilizar.
2.1 Resultado de uma operação
Todas as invocações de métodos retornam um código que indica o sucesso ou insucesso da
uma operação. Os valores possíveis estão codificados na seguinte enumeração:
public enum ResultCode : byte
{
Success = 1,
UnexpectedError = 2,
InvalidUser = 3,
InvalidParameter = 4,
NoData = 5,
UnAuthorized = 6,
ImpossibleConversion = 7
}
Os primeiros três valores são comuns a todas as operações, os restantes são específicos para
cada método e serão explicados em detalhe em cada caso.
A descrição desses valores é:
Valor
Descrição
Success
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; }
2
Web Service de Edíficios
Especificação Web Service
public byte TagMeasurementType{ get; set; }
public bool IsAccumulate{ get; set; }
}
2.3 Grupo
A classe Group é usada para representa um grupo e para fazer a sua serialização entre cliente e
a plataforma. A classe é definida por:
public class Group
{
public int Id { get; set; }
public string Name { get; set; }
public string Description { get; set; }
public int ParentId { get; set; }
public int IsBuilding { get; set; }
}
2.4 Detalhes de Grupo
A classe GroupDetails é usada para representa um detalhe de um grupo que pode ser usada em
indicadores de estado e para fazer a sua serialização entre cliente e a plataforma. A classe é
definida por:
public class GroupDetails
{
public int GroupId { get; set; }
public string Name { get; set; }
public decimal Value { get; set; }
}
2.5 Tipo de Grupo
A classe GroupType é usada para representa um tipo de grupo e para fazer a sua serialização
entre cliente e a plataforma. A classe é definida por:
public class GroupType
{
public int Id { get; set; }
public string Name { get; set; }
}
2.6 Colunas de um Tipo de Grupo
A classe GroupColumns é usada para representa os parâmetros de um tipo de grupo e para
fazer a sua serialização entre cliente e a plataforma. A classe é definida por:
public class GroupColumns
{
public int Id { get; set; }
public int GroupId { get; set; }
public string Name { get; set; }
public string Index { get; set; }
}
Web Service de Edíficios
3
Especificação Web Service
2.7 Valores das Colunas de um Tipo de Grupo
A classe GroupColumnsValues é usada para representa um valor de uma coluna de um tipo de
grupo e para fazer a sua serialização entre cliente e a plataforma. A classe é definida por:
public class GroupColumnsValues
{
public int Id { get; set; }
public string GroupId { get; set; }
public string ColumnId { get; set; }
public decimal Value { get; set; }
}
2.8 Tipo de Hórario de Grupo
A classe GroupScheduleType é usada para representa um tipo de hórario de um grupo e para
fazer a sua serialização entre cliente e a plataforma. A classe é definida por:
public class GroupColumns
{
public int Id { get; set; }
public int GroupId { get; set; }
public int ColumnId { get; set; }
public string Value { get; set; }
}
2.9 Hórario de Grupo
A classe GroupScheduleé usada para representar um horário de um grupo e para fazer a sua
serialização entre cliente e a plataforma. A classe é definida por:
public class GroupColumns
{
public int Id { get; set; }
public int GroupId { get; set; }
public int ColumnId { get; set; }
public string Value { get; set; }
}
2.10 Tag
A classe Tag é usada para representa uma Tag(variável medida) e para fazer a sua serialização
entre cliente e a plataforma. A classe é definida por:
public class Tag
{
public int Id { get; set; }
public string Name { get; set; }
public int UnitId { get; set; }
public int DeviceId { get; set; }
public int RemoteId { get; set; }
public int TagTypeId { get; set; }
public int LocalId { get; set; }
public int IsVirtual { get; set; }
}
4
Web Service de Edíficios
Especificação Web Service
2.11 Parâmetro da Virtual Tag
A classe Tag é usada para representa uma Tag(variável medida) e para fazer a sua serialização
entre cliente e a plataforma. A classe é definida por:
public class TagVirtualParameter
{
public int Id { get; set; }
public string TagId { get; set; }
public string VirtualParameterType { get; set; }
}
2.12 Tarifa
A classe Tariff é usada para representar uma tarifa e é serializada entre o cliente e a plataforma.
A classe tariff é definida por:
public class Tariff
{
public int Id { get; set; }
public int Supid { get; set; }
public string Name { get; set; }
public int AquisitionPeriods { get; set; }
public int SeasonSeries { get; set; }
public int Identification { get; set; }
public int UserId { get; set; }
public short Version { get; set; }
public bool IsPublic { get; set; }
public DateTime Start{ get; set; }
public DateTime End{ get; set; }
public List<Interval> Intervals { get; set; }
public List<FixedCosts> FixedCosts { get; set; }
public List<TariffParameter> Parameter{ get; set; }
}
2.13 Parâmetro de Tarifário
A classe TariffParameter é usada para representar um parâmetro do tarifário e é serializada
entre o cliente e a plataforma. A classe TariffParameter é definida por:
public class TariffParamter
{
public int Id { get; set; }
public int Type { get; set; }
public string Name { get; set; }
public int Period { get; set; }
public int Price { get; set; }
public List<int> Hours{ get; set; }
public List<MultiplicationFactor> Factor{ get; set; }
public List<Season> Seasons{ get; set; }
}
2.14 Custos Fixos
A classe FixedCosts é usada para representar um custo fixo associado ao tarifário e é
serializada entre o cliente e a plataforma. A classe FixedCosts é definida por:
public class FixedCosts
Web Service de Edíficios
5
Especificação Web Service
{
public
public
public
public
int Id { get; set; }
string Description { get; set; }
decimal ContractedPower { get; set; }
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;
public string Name {
public int StartDate
public int EndDate {
}
set; }
get; set; }
{ get; set; }
get; set; }
2.18 Simulação de tarifa
A classe TariffSimulation é usada para representar uma simulação e é serializada entre clientes
e a plataforma. A classe TariffSimulation é definida por:
public class TariffSimulation
{
public string Name { get; set; }
6
Web Service de Edíficios
Especificação Web Service
public List<TariffSimulationRow> Costs { get; set; }
public int Id { get; set; }
}
2.19 Linha de Simulação de tarifa
A classe TariffSimulationRow é usada para representar uma linha da simulação e é serializada
entre clientes e a plataforma. A classe TariffSimulation é definida por:
public class TariffSimulationRow
{
public decimal? RushHourCosts { get; set; }
public decimal? FloodHourCosts { get; set; }
public decimal? EmptyHourCosts { get; set; }
public decimal? SuperEmptyHouCostsr { get; set; }
public decimal? InductiveEnergyCosts { get; set; }
public decimal? CapacitiveEnergyCosts { get; set; }
public decimal? ContractedPowerCosts { get; set; }
public decimal? RushPowerCosts { get; set; }
}
2.20 Unidade de medida
A classe MeasurementUnit é usada para representa uma unidade de medida (kwh, € etc) e
para fazer a sua serialização entre cliente e a plataforma. A classe é definida por:
public class MeasurementUnit
{
public int Id { get; set; }
public string Name { get; set; }
public string SmallName { get; set; }
}
2.21 Conversão de medida
A classe MeasurementConversion é usada para representa uma conversão de uma unidade
de medida (kwh,€ etc) para outra (CO2,Car etc) e para fazer a sua serialização entre cliente e a
plataforma. A classe é definida por:
public class MeasurementConversion
{
public int Id { get; set; }
public Tuple<int,string,decimal> Source { get; set; }
public Tuple< int,string,decimal> Destination { get; set; }
}
2.22 Alerta
A classe Alert é usada para representa um alerta e para fazer a sua serialização entre cliente e a
plataforma. A classe é definida por:
public class Alert
{
public int Id { get; set; }
public Dictionary<string, string> Properties { get; set; }
public string Type { get; set; }
public bool HasEnable { get; set; }
Web Service de Edíficios
7
Especificação Web Service
public
public
public
public
string Name { get; set; }
int? EntityId { get; set; }
datetime StartDate { get; set; }
datetime EndDate { get; set; }
}
2.23 Parâmetro do alerta
A classe AlertParameterParameters é usada para representa um parâmetro de um alerta e para
fazer a sua serialização entre cliente e a plataforma. A classe é definida por:
public class AlertTriggerParameters
{
public int Id { get; set; }
public int AlertTriggerId { get; set; }
public string Name { get; set; }
public string ValueString { get; set; }
public decimal Value { get; set; }
}
2.24 Alerta disparado
A classe AlertTrigger é usada para representa um alerta que foi disputado e para fazer a sua
serialização entre cliente e a plataforma. A classe é definida por:
public class AlertTrigger
{
public int Id { get; set; }
public List< AlertTriggerParameters> Parameter { get; set; }
public string AlertName { get; set; }
public AlertType Type { get; set; }
public int AlertId { get; set; }
public bool HasChecked{ get; set; }
public int16 Priority { get; set; }
public bool HasSent { get; set; }
public datetime Date { get; set; }
}
Os tipos de alerta que existem são:
public enum AlertType: byte
{
Tag = (byte)0,
Unit = (byte)1,
Group = (byte)2,
System = (byte) 3
}
2.25 Actuação
A classe Action é usada para representa uma actuação e para fazer a sua serialização entre
cliente e a plataforma. A classe é definida por:
public class Action
{
public int Id { get; set; }
public int Weekday { get; set; }
public timespan Hour{ get; set; }
public bool Action { get; set; }
}
8
Web Service de Edíficios
Especificação Web Service
2.26 Baseline
A classe Baseline é usada para representa uma baseline e para fazer a sua serialização entre
cliente e a plataforma. A classe é definida por:
public class Baseline
{
public int Id { get; set; }
public datetime Date { get; set; }
public decimal AvacPower{ get; set; }
public timespan AvacStartTime { get; set; }
public timespan AvacEndTime { get; set; }
public List<BaselineValue> BaselineValues { get; set; }
public List<BaselineAppliance> BaselineAppliances{ get; set; }
}
2.27 Valores da Baseline
A classe BaselineValue é usada para representar um valor da baseline e para fazer a sua
serialização entre cliente e a plataforma. A classe é definida por:
public class BaselineValue
{
public int Id { get; set; }
public datetime Date { get; set; }
public decimal Rush { get; set; }
public decimal Full { get; set; }
public decimal Empty { get; set; }
public decimal SuperEmpty { get; set; }
}
2.28 Utensílios da baseline
A classe BaselineAppliance é usada para representar um utensílio e para fazer a sua
serialização entre cliente e a plataforma. A classe é definida por:
public class BaselineAppliance
{
public int Id { get; set; }
public string Name { get; set; }
public decimal Power{ get; set; }
public timespan StartTime { get; set; }
public timespan EndTime { get; set; }
}
Web Service de Edíficios
9
Especificação Web Service
3 Métodos
Nesta secção encontram-se todos os métodos que podem ser chamados no Web Service de
edifícios para retornar informação sobre as entidades armazenadas no sistema.
Nesta secção existe um método que é usado para listar algumas entidades no sistema segundo
alguns criterios:
ResultCode Search{Entidade} (string token, string? columnName, int? pagesize,
int? page, string searchText, string filter, out List<Entidade> entidade);
Descrição dos parâmetros:
Parâmetro
Fluxo
Token
In
ColumnName
In
Pagesize
In
Page
In
SearchText
In
Filter
In
Entidade
Out
Descrição
Token usado para verificar as credenciais do utilizador.
Nome da coluna para ordenação.
Número de resultados por página.
Página actual.
Texto que vai ser procurado.
Coluna da entidade que vai servir de filtro a pesquisa.
Lista com as entidades que preenchem o critério.
3.1 Acesso a dados
O método seguinte permite aceder a dados de consumos agregados para uma dada tag num
intervalo de tempo específico. Os valores são retornados numa unidade de medida específica:
ResultCode GetAggregatedConsumptions(string token, int tagId, DateTime
beginDate, DateTime endDate, byte measurementUnitId, AggType aggregation, out
List<Tuple<DateTime, decimal>> data);
Descrição dos parâmetros:
Parâmetro
Fluxo
Token
In
TagId
BeginDate
EndDate
MeasurementUnitId
In
In
In
In
Aggregation
In
Data
Out
Descrição
Token usado para verificar as credenciais do
utilizador.
Id da tag
Data de início
Data de fim
Unidade de medida em que os dados devem ser
retornados.
Tipo de agregação. (INSTANT, HOURLY,
DAILY, MONTHLY, YEARLY)
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
10
Não existem dados para os parâmetros especificados.
Web Service de Edíficios
Especificação Web Service
O método seguinte permite aceder a dados de consumos agregados (valores instantâneos) para
uma dada tag num intervalo de tempo específico. Os valores são retornados numa unidade de
medida específica:
ResultCode GetAggregatedInstants(string token, int tagId, DateTime beginDate,
DateTime endDate, byte measurementUnitId, Core.Structures.AggType aggregation,
Core.Structures.InstantType instant, out List<Tuple<DateTime, decimal>> data);
Descrição dos parâmetros:
Parâmetro
Fluxo
Token
In
TagId
In
BeginDate
In
EndDate
In
MeasurementUnitId
In
Aggregation
In
Instants
In
Data
Out
Descrição
Token usado para verificar as credenciais do utilizador.
Id da tag
Data de início
Data de fim
Unidade de medida em que os dados devem ser
retornados.
Tipo de agregação. (INSTANT, HOURLY, DAILY,
MONTHLY, YEARLY)
Operação estatística que deve ser aplicada aos dados.
(AVERAGE, MIN, MAX, STDEV)
Lista de tuples que contem os dados. Cada tuple
contém uma data e um decimal que representa o valor
em cada momento.
3.2 Grupos
Este método pesquisa por grupos com um nome ou descrição específicos:
ResultCode SearchGroup(string token, string text, out List<Group> groups);
Descrição de parâmetros:
Parâmetro
Fluxo
Token
In
Text
In
Groups
Out
Descrição
Token usado para verificar as credenciais do utilizador.
Texto a pesquisar.
Lista de grupos.
Método usado para retorna todos os grupos raiz:
ResultCode GetRootGroups (string token, out List<Group> groups);
Descrição de parâmetros:
Parâmetro
Fluxo
Token
In
Groups
Out
Descrição
Token usado para verificar as credenciais do utilizador.
Lista dos grupos raiz.
Este método verifica se um determinado grupo tem grupos filhos:
ResultCode HasChild (string token, int groupId, out bool hasChild);
Descrição de parâmetros:
Parâmetro
Fluxo
Token
In
GroupId
In
Web Service de Edíficios
Descrição
Token usado para verificar as credenciais do utilizador.
Group id.
11
Especificação Web Service
HasChild
Out
Returna verdadeiro ou falso.
Este método retorna as tag de um determinado grupo:
ResultCode GetTagsFromGroup (ing token, int groupId, out List<Tag> tags);
Descrição de parâmetros:
Parâmetro
Fluxo
Token
In
GroupId
In
Tags
Out
Descrição
Token usado para verificar as credenciais do utilizador.
Id do grupo.
Lista de tags.
Os códigos de retorno que podem ser retornados por este método são:
Código
de
resultado
Descrição
InvalidParameter
groupid é nulo ou vazio
groupid inválido
Método que retorna os indicadores de um determinado grupo:
ResultCode GetIndicatorsFromGroup (ing token, int groupId, out List<Tag>
tags);
Descrição de parâmetros:
Parâmetro
Fluxo
Token
In
GroupId
In
Indicators
Out
Descrição
Token usado para verificar as credenciais do utilizador.
Group id
Lista de indicadores do grupo.
Os códigos de retorno que podem ser retornados por este método são:
Código
de
resultado
Descrição
InvalidParameter
groupid é nulo ou vazio
groupid inválido
O método seguinte permite ao utilizador adicionar um novo grupo no sistema:
ResultCode AddGroup(string token, Group group, out int id);
Descrição dos parâmetros:
Parâmetro
Fluxo
Token
In
Group
In
Id
Out
Descrição
Token usado para verificar as credenciais do utilizador.
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.
O id do novo grupo criado.
O método seguinte permite adicionar tags a um determinado grupo:
ResultCode AddTagsToGroup(string token, int[] tags, int group);
Descrição dos parâmetros:
12
Web Service de Edíficios
Especificação Web Service
Parâmetro
Token
Tags
Fluxo
In
In
Group
In
Descrição
Token usado para verificar as credenciais do utilizador.
Um array com os ids das tags para serem adicionadas ao
grupo.
Id do grupo.
Este método permite editar informação de um determinado grupo:
ResultCode EditGroup(string token, Group g);
Descrição dos parâmetros:
Parâmetro
Fluxo
Token
In
Group
In
Descrição
Token usado para verificar as credenciais do utilizador.
Grupo a ser editado.
O método seguinte permite apagar um grupo:
ResultCode DeleteGroup(string token, int id);
Nota: Apenas grupos folha podem ser apagados.
Descrição dos parâmetros:
Parâmetro
Fluxo
Descrição
Token
In
Token usado para verificar as credenciais do utilizador.
Id
In
Id do grupo apagar.
O método seguinte permite linkar dois grupos um ao outro numa relação hierárquica.
ResultCode LinkGroups(string token, int parentId, int childId);
Descrição dos parâmetros:
Parâmetro
Fluxo
Token
In
ParentId
In
Childid
In
Descrição
Token usado para verificar as credenciais do utilizador.
Id do grupo pai.
Id do grupo filho.
O método seguinte permite que dois grupos sejam separados:
ResultCode UnLinkGroups(string token, int parentId, int childId);
Descrição dos parâmetros:
Parâmetro
Fluxo
Token
In
ParentId
In
Childid
In
Descrição
Token usado para verificar as credenciais do utilizador.
Id do grupo pai.
Id do grupo filho.
O método seguinte permite ao utilizador listar todos os grupos que tem acesso:
ResultCode GetGroups(string token, out List<Group> groups);
Descrição dos parâmetros:
Parâmetro
Fluxo
Token
In
Groups
out
Web Service de Edíficios
Descrição
Token usado para verificar as credenciais do utilizador.
Lista de grupos.
13
Especificação Web Service
O método seguinte permite ao utilizador obter todos os grupos filhos de um determinado grupo.
ResultCode GetDirectGroupChilds(string token, int groupId, out List<Group>
children);
Descrição dos parâmetros:
Parâmetro
Fluxo
Token
In
GroupId
In
Children
Out
Descrição
Token usado para verificar as credenciais do utilizador.
Id do grupo.
Lista de grupos filhos.
O método seguinte permite ao utilizador obter todos os grupos filhos de um determinado grupo.
ResultCode GetAllGroupChilds(string token, int groupId, out List<Group>
children);
Descrição dos parâmetros:
Parâmetro
Fluxo
Token
In
GroupId
In
Children
Out
Descrição
Token usado para verificar as credenciais do utilizador.
Id do grupo.
Lista de grupos filhos.
O método seguinte permite ao utilizador obter todas as tags dos grupos filhos de um
determinado grupo.
ResultCode GetAllTagsFromGroup(string token, int groupId, out List<Tag> tags);
Descrição dos parâmetros:
Parâmetro
Fluxo
Token
In
GroupId
In
Tags
Out
Descrição
Token usado para verificar as credenciais do utilizador.
Id do grupo.
Lista de tags dos grupos filhos.
O método seguinte permite que sejam listadas grupos por um certa condição:
ResultCode SearchGroups(string token, string? columnName, int? pagesize, int?
page, string searchText, string filter, out List<Group> entidade);
Explicação dos códigos retornados:
Código de resultado
Descrição
InvalidUser
Success
UnexpectedError
Token errado.
Token expirado.
Acesso não autorizado ao método.
Operação com sucesso.
Erro inesperado no acesso a base de dados.
3.3 Unidades de medida
O método seguinte permite ao utilizador obter uma lista de unidades de conversão:
ResultCode GetMeasurementConversions(string token, out
List<MeasurementConversions> conversions);
14
Web Service de Edíficios
Especificação Web Service
Uma conversão representa o factor pelo qual a unidade deve ser multiplicada para obter uma
outra unidade.
Descrição dos parâmetros:
Parâmetro
Fluxo
Descrição
Token
In
Token usado para verificar as credenciais do utilizador.
MeasurementUnits
Out
Lista de unidades de medida.
O método seguinte permite obter uma lista de tipos de medida (Gás, Água, Temperatura …):
ResultCode GetMeasurementTypes(string token, out List<Tuple<int, string>>
measurementTypes);
Descrição dos parâmetros
Parâmetro
Fluxo
Token
In
MeasurementTypes
Out
Descrição
Token usado para verificar as credenciais do utilizador.
Lista de tuples onde cada um deles contém o id e uma
string que representam o id e o nome do tipo,
respectivamente
O método seguinte permite que o utilizador possa obter as unidades de medida (Volt,
Kilowatt/h, CO2, …):
ResultCode GetMeasurementUnits(string token, out List<Tuple<int, string>>
measurementUnits);
Descrição dos parâmetros:
Parâmetro
Fluxo
Token
In
MeasurementUnits
Out
Descrição
Token usado para verificar as credenciais do utilizador.
Lista de tuples onde cada um deles contém o id e uma
string que representam o id e o nome do tipo,
respectivamente
3.4 Tarifas
O método seguinte permite obter o tarifário aplicado a uma determinada tag:
ResultCode GetDeviceTariff(string token,int tagId, out tariff Tariff);
Descrição dos parâmetros:
Parâmetro
Fluxo
Token
In
TagId
In
Tariff
Out
Descrição
Token usado para verificar as credenciais do utilizador.
Id da tag.
Tarifa aplicada a tag.
O método seguinte permite actualizar um tarifário de uma tag.
ResultCode UpdateDeviceTariff(string token,int tagId,int tarId out tariff
Tariff);
Descrição dos parâmetros:
Parâmetro
Fluxo
Token
In
TagId
In
Web Service de Edíficios
Descrição
Token usado para verificar as credenciais do utilizador.
Id da tag.
15
Especificação Web Service
TarId
Tariff
In
Out
Id do tarifário.
Tarifa aplicado a tag.
O método seguinte retorna a lista de tarifários aplicados num determinado local ou para todos
os locais:
ResultCode GetTariffs(string token,string zipcode, out List<tariff> tariffs);
Descrição dos parâmetros:
Parâmetro
Fluxo
Token
In
Zipcode
In
Tariff
Out
Descrição
Token usado para verificar as credenciais do utilizador.
Id do código postal onde se pretende consultar os
tarifários.
Lista de tarifários.
O método seguinte permite adicionar um novo tarifário a base de dados:
ResultCode AddTariffs(string token, tariff tariff);
Descrição dos parâmetros:
Parâmetro
Fluxo
Token
In
Tariff
In
Descrição
Token usado para verificar as credenciais do utilizador.
Tarifário a ser adicionado.
O método seguinte permite adicionar um novo versão do tarifário a base de dados:
ResultCode AddTariffVersion(string token,int lastTariffId tariff tariff);
Descrição dos parâmetros:
Parâmetro
Fluxo
Token
In
LastTariffId
In
Tariff
In
Descrição
Token usado para verificar as credenciais do utilizador.
Id do tarifário para o qual se pretende criar nova versão
do tarifário.
Tarifário a ser adicionado.
O método seguinte permite obter uma simulação de tarifário com todos os tarifários inseridos
no sistema.
ResultCode GetTariffSimulation(string token,int grupId, string? columnName, int?
pagesize, int? page, out List<TariffSimulation> simulation);
Descrição dos parâmetros:
Parâmetro
Fluxo
Token
In
GroupId
In
Simulation
Out
Descrição
Token usado para verificar as credenciais do utilizador.
Id do grupo que se pretende obter a simulação.
Lista de simulações com cada um dos tarifários.
3.5 Alerts
O método seguinte retorna uma lista de alertas configurados no sistema:
ResultCode GetAlerts(string token, string? columnName, int? pagesize, int? page,
out List<alert> alerts);
16
Web Service de Edíficios
Especificação Web Service
Descrição dos parâmetros:
Parâmetro
Fluxo
Token
In
Alerts
Out
Descrição
Token usado para verificar as credenciais do utilizador.
Lista de alertas configurados no sistema.
O método seguinte permite adicionar novos alertas ao sistema.
ResultCode AddAlert (string token, Alert alert);
Descrição dos parâmetros:
Parâmetro
Fluxo
Token
In
Alert
Out
Descrição
Token usado para verificar as credenciais do utilizador.
Novo alerta a ser adicionado.
O método seguinte permite ao utilizador apagar alertas definidos no sistema
ResultCode DeleteAlert (string token, int alertId)
Descrição dos parâmetros:
Parâmetro
Fluxo
Token
In
AlertId
In
Descrição
Token usado para verificar as credenciais do utilizador.
Id do alerta.
O método seguinte permite listar todos os alertas lançados pelo sistema.
ResultCode GetAlertTriggers (string token, string? columnName, int? pagesize,
int? page, out List<Tuple<int, string>> alertTriggers);
Descrição dos parâmetros:
Parâmetro
Fluxo
Token
In
Triggers
Out
Descrição
Token usado para verificar as credenciais do utilizador.
Lista de alertas lançados no sistema.
O método seguinte permite listar todos os alertas lançados pelo sistema, filtrados por grupo ou
por tipo.
ResultCode GetAlertTriggersByGroup (string token, int? groupId, int? groupId,
int? type, out List<Tuple<int, string>> measurementUnits);
Descrição dos parâmetros:
Parâmetro
Fluxo
Token
In
GroupId
In
Triggers
Out
Descrição
Token usado para verificar as credenciais do utilizador.
Id do grupo na qual se pretende listar os alertas.
Lista de alertas lançados no sistema.
O método seguinte permite que sejam listadas alertas disparados por um certa condição:
ResultCode SearchAlertTriggers(string token, string? columnName, int? pagesize,
int? page, string searchText, string filter, out List<AlertTriggers> entidade);
O método seguinte permite colocar um alerta como lido.
ResultCode SetAlertHasRead (string token, int alertId);
Web Service de Edíficios
17
Especificação Web Service
Descrição de parâmetros:
Parâmetro
Fluxo
Token
In
AlertId
In
Descrição
Token usado para verificar as credenciais do utilizador.
Id do alerta.
3.6 Messages
O método seguinte permite que sejam inseridas novas mensagens no sistema:
ResultCode AddMessage(string token, int groupId, string? columnName, int?
pagesize, int? page, Message message);
Descrição de parâmetros:
Parâmetro
Fluxo
Token
In
GroupId
In
Message
In
Descrição
Token usado para verificar as credenciais do utilizador.
Id do grupo a que pertence a mensagem
Mensagem a ser adicionada ao grupo.
O método seguinte permite apagar uma mensagem do sistema, esta mensagem é introduzida
para determinado grupo.
ResultCode DeleteMessage (string token,int messageId);
Descrição de parâmetros:
Parâmetro
Fluxo
Token
In
MessageId
Out
Descrição
O token de autenticação usado para verificar as
credenciais do utilizador.
Id da mensagem.
O método seguinte permite listar todas a mensagens no sistema.
ResultCode GetMessage (string token,out
Descrição de parâmetros:
Parâmetro
Fluxo
Token
In
Message
Out
Message message);
Descrição
O token de autenticação usado para verificar as
credenciais do utilizador.
Mensagens registadas no sistema.
O método seguinte permite listar todas as mensagens para um determinado grupo.
ResultCode GetMessageFromGroup string token, int groupId, out List<Message>
message);
Descrição de parâmetros:
Parâmetro
Fluxo
Token
In
GroupId
Message
In
Out
Descrição
O token de autenticação usado para verificar as
credenciais do utilizador.
Id d grupo.
Lista de mensagens.
O método seguinte permite que sejam listadas mensagens por um certa condição:
18
Web Service de Edíficios
Especificação Web Service
ResultCode SearchMessage(string token, string? columnName, int? pagesize, int?
page, string searchText, string filter, out List<Message> entidade);
3.7 Baseline
O método seguinte permite que sejam inseridas novas baselines no sistema.
ResultCode AddBaseline(string token, int groupId,baseline baseline);
Descrição de parâmetros:
Parâmetro
Fluxo
Token
In
GroupId
In
Baseline
In
Descrição
Token usado para verificar as credenciais do utilizador.
Id do grupo a que pertence a baseline
Baseline a ser adicionada ao grupo.
O método seguinte permite actualizar uma baseline:
ResultCode UpdateBaseline(string token, int lastId, baseline baseline);
Descrição de parâmetros:
Parâmetro
Fluxo
Token
In
LastId
In
Baseline
In
Descrição
Token usado para verificar as credenciais do utilizador.
Id da última baseline.
Nova baseline.
O método seguinte permite obter as baselines de um determinado grupo:
ResultCode GetBaselines(string token,groupId, out List<Baseline> baselines);
Descrição de parâmetros:
Parâmetro
Fluxo
Token
In
GroupId
In
Baselines
Out
Descrição
Token usado para verificar as credenciais do utilizador.
Id do grupo.
Lista de baselines do grupo.
O método seguinte permite apagar uma baseline do sistema, apenas é possível apagar a ultima
baseline introduzida para determinado grupo:
ResultCode DeleteBaseline(string token,int baselineId);
Descrição de parâmetros:
Parâmetro
Fluxo
Token
In
BaselineId
Out
Descrição
O token de autenticação usado para verificar as
credenciais do utilizador.
Id da baseline.
3.8 Relatórios
O método seguinte permite ao utilizador obter um relatório para um determinado grupo:
ResultCode GetReport(string token,int id,int type, out bytes[] report);
Descrição de parâmetros:
Web Service de Edíficios
19
Especificação Web Service
Parâmetro
Token
Fluxo
In
Id
Type
Report
In
In
Out
Descrição
O token de autenticação usado para verificar as
credenciais do utilizador.
Id do grupo para o qual se pretende obter o relatório.
Tipo de relatório (1 – Completo, 2 - Resumido).
Lista de bytes que representa o relatório.
3.9 Actuação
O método seguinte permite que sejam listadas todas as actuações do sistema:
ResultCode GetActions(string token, string? columnName, int? pagesize, int?
page, List<Action> actions);
Descrição de parâmetros:
Parâmetro
Fluxo
Token
In
Action
In
Descrição
Token usado para verificar as credenciais do utilizador.
Lista de actuações no sistema.
O método seguinte permite que sejam listadas as actuações de um grupo.
ResultCode GetGroupActions(string token, int groupId, string? columnName, int?
pagesize, int? page, List<Action> action);
Descrição de parâmetros:
Parâmetro
Fluxo
Token
In
GroupId
In
Action
In
Descrição
Token usado para verificar as credenciais do utilizador.
Id do grupo a que pertencem as actuações.
Lista de actuações no sistema.
O método seguinte permite que sejam inseridas novas actuações no sistema
ResultCode AddAction(string token,Action action);
Descrição de parâmetros:
Parâmetro
Fluxo
Token
In
Action
In
Descrição
Token usado para verificar as credenciais do utilizador.
Actuação a ser adicionada.
O método seguinte permite que sejam apagadas actuações do sistema:
ResultCode DeleteAction(string token, int actionId);
Descrição de parâmetros:
Parâmetro
Fluxo
Token
In
ActionId
In
Descrição
Token usado para verificar as credenciais do utilizador.
Id da actuação a ser adicionada.
O método seguinte permite que sejam listadas actuações por um certa condição:
ResultCode SearchAction(string token, string? columnName, int? pagesize, int?
page, string searchText, string filter, out List<Action> entidade);
20
Web Service de Edíficios
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
2.2
2.3
2.4
3
TABELAS DE ACTUAÇÃO ........................................................................................................................... 5
3.1
4
HIERARCHY................................................................................................................................................ 9
INDICADOR ................................................................................................................................................ 9
GROUP ..................................................................................................................................................... 9
GROUP_TYPE .......................................................................................................................................... 10
GROUP_COLUMNS ................................................................................................................................... 10
GROUP_COLUMNS_VALUES ....................................................................................................................... 10
GROUP_SCHEDULE ................................................................................................................................... 11
GROUP_DETAILS ...................................................................................................................................... 11
GROUP_TAG ........................................................................................................................................... 11
GROUP_USER .......................................................................................................................................... 12
TABELAS TARIFÁRIOS ............................................................................................................................. 14
6.1
6.2
6.3
6.4
6.5
6.6
6.7
7
BASELINE .................................................................................................................................................. 6
BASELINE_VALUES ...................................................................................................................................... 6
BASELINE_APPLIANCE ................................................................................................................................. 7
TABELAS GRUPOS..................................................................................................................................... 9
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
6
ACTION .................................................................................................................................................... 5
TABELAS BASELINE ................................................................................................................................... 6
4.1
4.2
4.3
5
ALERT....................................................................................................................................................... 2
ALERT_PARAMETER .................................................................................................................................... 2
ALERT_TRIGGER ......................................................................................................................................... 3
ALERT_TRIGGER_PARAMETER ...................................................................................................................... 3
TARIFF .................................................................................................................................................... 14
TARIFF_PARAMETER ................................................................................................................................. 14
MULTIPLICATION_FACTOR ......................................................................................................................... 15
SEASON .................................................................................................................................................. 15
SEASON_SERIES ....................................................................................................................................... 16
INTEVAL .................................................................................................................................................. 16
FIXED_COSTS........................................................................................................................................... 16
TABELAS KPI’S ........................................................................................................................................ 18
7.1
7.2
7.3
7.4
7.5
KPI ........................................................................................................................................................ 18
KPI_DATA ............................................................................................................................................. 18
KPI_MESSAGE ...................................................................................................................................... 19
KPI_CONF ............................................................................................................................................. 20
KPI_ERROR_LOG .................................................................................................................................. 20
Especificação da base de dados
1 Introdução
Neste documento são especificadas alterações feitas a base de dados no decorrer do
desenvolvimento do estágio bem como o modelo entidade relação, apenas da parte que faz parte do
estágio.
Especificação da base de dados
1
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
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

Chave primaria.
Data de fim do alerta.
Dependencies
Dependent Tables
unit, tag, dll
Dependent Procedures
2.2 Alert_Parameter
Entidade que representa um parâmetro do alerta que pode representar um valor que faz disparar
certo alerta.
Nome
Tipo
Def. Null Idx
Descrição
ap_id
int
ap_name
int
2
 Chave primaria.
Nome do parâmetro.
Especificação da base de dados
Especificação da base de dados
ap_value
decimal
Valor associado ao parâmetro.
ap_value_string
string
String associada ao parâmetro.
Dependencies
Dependent Tables
alert
Dependent Procedures
2.3 Alert_Trigger
Entidade que representa um parâmetro do alerta que foi disparado.
Nome
Tipo
Def. Null Idx
Descrição
 Chave primaria.
at_id
int
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
Dependent Procedures
2.4 Alert_Trigger_Parameter
Entidade que representa um parâmetro do alerta que fez disparar um determinado alerta.
Nome
Tipo
Def. Null Idx
Descrição
 Chave primaria.
atp_id
int
atp_name
datetime
Nome do parâmetro que fez
disparar o alerta.
atp_value
bit
Valor decimal que fez disparar o
alerta.
Especificação da base de dados
3
Especificação da base de dados
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
Dependent Procedures
alert
alr_id
alr_type
unt_id
g_id
tag_id
alr_enabled
alr_schedule
alr_last_exec
alert_trigger
at_id
at_date
at_checked
dll_id
alr_name
alr_data
alr_stop_date
at_priority
alr_id
at_email
alert_parameter
ap_id
ap_name
alert_trigger_parameter
ap_value
atp_id
alr_id
atp_name
ap_value_string
atp_value
atp_string_value
at_id
4
Especificação da base de dados
Especificação da base de dados
3 Tabelas de actuação
Secção com a descrição das tabelas referentes a funcionalidade de actuação.
3.1 Action
A tabela action irá conter as configurações das actuações agendadas no sistema. Tabela interna
de sistema.
Nome
Tipo
Def.
Null
Idx
Descrição
 Chave primaria.
act_id
int
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
Dependent Procedures
action
act_id
uni_id
tag_id
act_weekday
act_hour
act_action
act_next
Figura 1 – Diagrama ER relativo a actuação
Especificação da base de dados
5
Especificação da base de dados
4 Tabelas Baseline
Secção com a descrição das tabelas referentes a funcionalidade de baseline.
4.1 Baseline
A tabela Baseline irá conter as configurações das baselines armazenada na BD. Tabela interna
de sistema.
Nome
Tipo
Def.
Null
Idx
Descrição
 Chave primaria.
bl_id
int
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.
timestamp
Hora de início de funcionamento
do AVAC.
timestamp
Hora em que o AVAC é desligado.
bit
Diz se a baseline já foi ou não
calculada.
avac_start_time
avac_stop_time
bl_calculated
Dependencies
group
Dependent Tables
Dependent Procedures
4.2 Baseline_Values
A tabela baseline_values irá conter os valores para cada uma das baselines do sistema. Tabela
interna de sistema.
Nome
6
Tipo
Def.
Null
Idx
Descrição
Especificação da base de dados
Especificação da base de dados
 Chave primaria.
bv_id
int
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
Id da baseline.
int
Dependencies
baseline
Dependent Tables
Dependent Procedures
4.3 Baseline_Appliance
A tabela Baseline_Appliance irá conter os electrodomésticos configurados para cada baseline.
Nome
Tipo
Def.
Null
Idx
Descrição
 Chave primaria.
ap_id
int
ap_name
nvarchar(100)
Nome do electrodoméstico.
ap_power
decimal(15, 5)
Potência nominal.
ap_start
timespan
Hora de início de funcionamento.
ap_end
timespan
Hora de fim de funcionamento
dtt_index
int
Index no interface.
bl_id
int
Id da baseline a que esta associada
ao electrodomésticos.
Dependencies
baseline
Dependent Tables
Especificação da base de dados
7
Especificação da base de dados
Dependent Procedures
baseline
bl_id
g_id
baseline_value
bl_date
bv_id
bl_last_id
bv_date
bl_next_id
bv_ae_rush
bl_last_date
bv_ae_full
open_time
bv_ae_empty
close_time
bv_ae_superempty
avac_power
bl_id
avac_start_time
avac_stop_time
bl_calculated
baseline_appliance
ap_id
ap_name
ap_power
ap_start
ap_end
bl_id
dttt_index
Figura 2 - Diagrama ER relativo a baseline
8
Especificação da base de dados
Especificação da base de dados
5 Tabelas Grupos
Secção com as tabelas que constituem a funcionalidade de grupos.
5.1 Hierarchy
Tabela que armazena a relação hierarquizada dos grupos.
Nome
Tipo
h_parent
int
h_group
h_level
int
tinyint
h_references
tinyint
g_private
bit
Dependencies
Dependent Tables
Dependent Procedures
Def.
Null
Idx
Descrição
Chave estrangeira que referencia
(pai) group
Chave estrangeira que referencia
(filho) group
Distância entre pai e filho
Número de referência devido a
herança múltipla
Flag que indica se o grupo filho é
privado ou não.



group
5.2 Indicador
Entidade relacionar que armazena indicadores.
Nome
Tipo
Def. Null
ind_id
int
ind_operation
nchar(3)


ind_field
ind_name
nvarchar(50)
nvarchar(50)
ind_constant
decimal(15,5)
ind_isgroup
bit
Dependencies
Dependent Tables
Dependent Procedures
Idx

Descrição
Chave primaria
String que representa a operação
(sum, sub, avg …)
String que representa o nome do
group_details ou dos local_details
(dependendo da flag isgroup)
Nome do indicador.
Valor constante que pode ser usado
no indicador
Flag que indica que o indicador vai
usar para cálculo o group_details ou
local_details
group_indicator
5.3 Group
Entidade que armazena todas as instâncias de um grupo.
Especificação da base de dados
9
Especificação da base de dados
Nome
Tipo
g_id
g_name
g_description
int
nvarchar(20)
nvarchar(100)
g_deleted
bit
g_private
bit
Dependencies
Dependent Tables
Dependent Procedures
Def.
Null
Idx


Descrição
Chave primaria
Nome do grupo
Descrição do grupo
Flag que indica se o grupo esta a
pagado.
Flag que indica que o grupo é
privado (Pertence a um único
utilizador).
local
group_tag, group_user, hierarchy, user
5.4 Group_Type
Entidade que armazena todas as instâncias de um tipo de grupo.
Nome
Tipo
Def. Null Idx
Descrição
gt_id
gt_name

int
nvarchar(20)
Dependencies
Dependent Tables
Dependent Procedures
Chave primária.
Nome do tipo de grupo.
group
5.5 Group_Columns
Entidade que armazena todas as instâncias dos parâmetros de um tipo de grupo.
Nome
Tipo
Def. Null Idx
Descrição
gc_id
gc_name
int
nvarchar(20)
gt_id
dttt_index
int
int
Dependencies
Dependent Tables
Dependent Procedures

Chave primária.
Nome do parâmetro.
Chave estrangeira que referencia o
tipo de grupo.
Index do parâmetro no tipo de grupo.
group_type
5.6 Group_Columns_Values
Entidade que armazena todas as instâncias dos valores associados aos tipos de grupo.
Nome
Tipo
Def. Null Idx
Descrição
gtc_id
10
int

Chave primária.
Especificação da base de dados
Especificação da base de dados
gtc_value
nvarchar(20)
gt_id
int
g_id
int
Dependencies
Dependent Tables
Dependent Procedures
Valor do parâmetro.
Chave estrangeira que referencia o
tipo de grupo.
Chave estrangeira que referencia o
grupo.
Group, group_type
5.7 Group_Schedule
Entidade que armazena todas as instâncias de um hórario de um grupo.
Nome
Tipo
Def. Null Idx
Descrição
sh_id
start_hour
weekday
end_hour

int
time
int
time
Dependencies
Dependent Tables
Dependent Procedures
Chave primária.
Hora de início do turno.
Dia da semana
Hora de fim do turno
group
5.8 Group_Details
Entidade que armazena detalhes do grupo que são usados no cálculo de indicadores.
Nome
Tipo
Def. Null Idx
Descrição
g_id
gd_name
gd_value

int
nvarchar(20)
Decimal(15,3)
Dependencies
Dependent Tables
Dependent Procedures
Chave estrangeira que referencia um
grupo.
Nome do detalhe.
Valor do detalhe
group
5.9 Group_Tag
Entidade relacional que armazena todas as tags que pertencem a um certo grupo.
Nome
Tipo
Def. Null Idx
Descrição
g_id
int
tag_id
int
Especificação da base de dados


Chave estrangeira que referencia o
grupo.
Chave estrangeira que referencia o
tag
11
Especificação da base de dados
Dependencies
Dependent Tables
Dependent Procedures
tag, group
5.10 Group_Indicator
Entidade relacional que armazena todas os indicadores que pertencem a um certo grupo.
Nome
Tipo
Def. Null Idx
Descrição
g_id
int
tag_id
int
Ind_id
int
Dependencies
Dependent Tables
Dependent Procedures



Chave estrangeira que referencia o
grupo.
Chave estrangeira que referencia o
tag
Chave estrangeira que referencia o
indicador
tag, group, indicator
5.11 Group_User
Entidade relacional que armazena todos os utilizadores que tem acesso a um certo grupo.
Nome
Tipo
Def. Null Idx
Descrição
g_id
int
usr_id
int
Dependencies
Dependent Tables
Dependent Procedures
12


Chave estrangeira que referencia
o grupo.
Chave estrangeira que referencia
o utilizador
tag, user
Especificação da base de dados
Especificação da base de dados
group_columns_values
group_columns
gtc_id
gc_id
gtc_value
gc_name
gt_id
g_id
g_id
g_id
gt_id
gt_name
gt_id
gd_name
gc_id
dttt_index
group_type
group_types_values
group_details
gd_value
group_schedule_type
sh_id
sh_name
g_id
hierarchy
group
group_schedule
h_parent
g_id
h_group
g_name
sh_id
h_level
g_description
s_id
h_references
g_deleted
weekday
g_private
g_private
start_hour
gt_id
end_hour
group_tag
g_id
tag_id
indicator
ind_id
group_indicator
ind_operation
ind_id
ind_field
g_id
ind_name
tag_id
ind_constant
gi_id
group_user
g_id
usr_id
ind_isgroup
Figura 3 - Diagrama ER relativo aos grupos
Especificação da base de dados
13
Especificação da base de dados
6 Tabelas Tarifários
Secção corresponde as tabelas dos tarifários.
6.1 Tariff
Esta entidade armazena dados relativos aos tarifários.
Nome
Tipo
Def. Null
tar_id
tar_name
int
nvarchar(100)
sup_id
int
tar_deleted
bit
tar_version
smallint
tar_start
smalldatetime
tar_end
smalldatetime
sse_id
int
Idx


tar_tariff_identification int
usr_id
tar_ispublic
int
Bit
Dependencies
Dependent Tables
Dependent Procedures
Descrição
Chave primária.
Nome do tarifário
Chave estrangeira a referencia o
fornecedor.
Flag que indica se o tarifário esta
apagado ou não.
Número que indica a versão do
tarifário.
Data em que o tarifário começa a
estar activo
Data que indica quando a tarifária
deixa de estar activo.
Chave estrangeira que referencia a
tabela season_series
Número que identifica as diferentes
versões do mesmo tarifário
Chave estrangeira que identifica o
utilizador que criou o tarifário.
Flag que indica se a tarifa é publica.
supplier
interval, fixed_cost
6.2 Tariff_Parameter
A tabela tariff_parameter irá conter os parâmetros associados a um determinado tarifário.
Tabela interna de sistema.
Nome
Tipo
int
tp_type
smallint
14
nvarchar(100
)
Null
Idx

tp_id
tp_name
Def.
Descrição
Chave primária.
Tipo de parâmetro (energia activa,
potência, energia reactiva).
Nome do parâmetro.
Especificação da base de dados
Especificação da base de dados
tp_price
tp_period
smallmoney
Custo associado ao parâmetro.
smallint
De quanto em quanto tempo é
calculado o parâmetro (horário,
mensal, diário)
Dependencies
tariff
Dependent Tables
Dependent Procedures
6.3 Multiplication_Factor
A tabela multiplication_factor irá conter os factores de multiplicação associados a um
determinado parâmetro de um tarifário. Tabela interna de sistema.
Nome
Tipo
Def.
Null
Idx

Descrição
mf_id
int
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
Dependencies
Chave primária.
Ida do parâmetro do tarifário a que
o factor de multiplicação pertence.
tariff_parameter
Dependent Tables
Dependent Procedures
6.4 Season
Entidade que armazena o inicio e o fim que cada temporada.
Nome
Tipo
Def. Null Idx
Descrição
s_begindate
s_enddate
s_id
smalldatetime
smalldatetime
int
Especificação da base de dados

Data de início da temporada
Data de fim da temporada
Chave primária
15
Especificação da base de dados
s_deleted
bit
sse_id
int
s_season
tinyint
Dependencies
Dependent Tables
Dependent Procedures

Flag se a temporada foi apagada
Chave estrangeira para a
season_series
Indice da temporada. (e.x. 1, 2, …)
Onde 1=1st trimestre
2= 2nd trimestre
3=3rd trimestre
season_series
6.5 Season_Series
Entidade que armazena os tipos de temporadas que podem ser usadas nos tarifários.
Nome
Tipo
Def. Null Idx
Descrição

sse_id
int
sse_type
nvarchar(50)
sse_number_seasons tinyint
Dependencies
Dependent Tables
Dependent Procedures
Primary Key
Descrição do tipo de temporada.
Número de temporadas nesta serie.
tariff
6.6 Inteval
Entidade que armazena os intervalos de facturação de um tarifário.
Nome
Tipo
Def. Null Idx
Descrição
int_id
int_start
int_end
s_season
int_weekday
int_price
int
time(0)
time(0)
int
tinyint
smallmoney
tar_id
h_type
int
tinyint
Dependencies
Dependent Tables


Chave primária
Hora de início do intervalo.
Hora de fim de fim do intervalo
Índex da temporada nas séries
Dias da semana (bit mask)
Preço por unidade
Chave estrangeira que referencia a
tarifa.
Tipo de hora.
tariff
Dependent Procedures
6.7 Fixed_Costs
Entidade que armazena os custos fixos associados a um tarifário.
16
Especificação da base de dados
Especificação da base de dados
Nome
Tipo
fxc_id
fxc_description
fxc_price
int
nvarchar(50)
smallmoney
tar_id
int
Dependencies
Dependent Tables
Dependent Procedures
Def.
Null
Idx
Descrição
 Chave primária

Descrição do custo fixo
Valor do custo
Chave estrangeira que referencia a
tarifa
tariff
season
s_season
season_series
sse_id
s_begindate
sse_type
s_enddate
sse_number_seasons
s_id
sse_id
tariff
tar_id
tar_name
sup_id
interval
tar_intervals
int_id
tar_deleted
int_start
tar_version
int_end
tar_start
s_season
tar_end
tar_issingle_step
fixed_cost
int_weekday
tar_id
sse_id
fxc_id
tar_isstepbased
fxc_description
tar_tariff_identification
fxc_price
usr_id
tar_id
tar_ispublic
int_type
contracted_power
tariff_parameter
tp_id
tp_type
tar_id
tp_price
tp_period
tp_name
p_id
multiplication_factor
mf_id
mf_name
mf_min
mf_max
mf_factor
tp_id
tariff_parameter_season
tp_id
s_season
tps_id
Figura 4 - Diagrama ER relativo aos tarifários
Especificação da base de dados
17
Especificação da base de dados
7 Tabelas KPI’s
Nesta secção encontram-se todas as tabelas relacionadas com os KPI’s.
7.1 KPI
A tabela KPI irá conter informação sobre os KPIs existentes e para os quais serão feitos
carregamentos de dados.
Nome
Tipo
Def.
Null
Idx
Descrição

kpi_id
int
Chave primária.
kpi_name
nvarchar(100)
Nome do KPI.
kpi_description
nvarchar(4000)
Descrição do KPI.
kpi_type
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
Dependent Procedures
7.2 KPI_DATA
A tabela KPI_DATA irá conter todos os dados associados aos KPIs. O carregamento de dados
para esta tabela será feito através de Stored Procedures, que serão escalonados através de SQL
Server Job.
Nome
kpi_id
18
Tipo
int
Def. Null Idx

Descrição
Chave estrangeira que referência
o KPI.
Especificação da base de dados
Especificação da base de dados
kpid_value
decimal(15, 5)
kpid_current_value
decimal(15, 5)
Valor do KPI.

Valor current lido para calcular o
KPI (kpid_value).

O valor de referência lido para
calcular o KP (kpid_value). Este
é usado quando é definido um
objectivo.
kpid_reference_value
decimal(15, 5)
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
mensagem esta associada.
Dependencies
KPI
Dependent Tables
Dependent Procedures
7.3 KPI_MESSAGE
A tabela KPI_MESSAGE irá conter as mensagens registadas pelo gestor de energia para
notificação das agências relativamente a problemas encontrados.
Nome
Tipo
Def. Null
Idx

Descrição
kpim_id
int
kpim_date
datetime
Data de criação da mensagem.
kpim_severity
nchar(10)
kpim_title
nvarchar(100)
Gravidade da mensagem:
Grande, Média and pequena.
Título da menssagem.
kpim_body
nvarchar(4000)
Corpo da mensagem.
kpim_branch_code
nvarchar(50)
Código do grupo ao qual a
mensagem esta associada.
Especificação da base de dados
Primary Key.
19
Especificação da base de dados
kpim_branch_name
Nome do grupo ao qual a
mensagem esta associada.
nvarchar(50)
Dependencies
Dependent Tables
Dependent Procedures
7.4 KPI_CONF
A tabela KPI_CONF irá conter configurações que serão usadas pelos procedimentos durante a
execução. Tabela interna de sistema.
Nome
Tipo
Def.
Null
Idx
Descrição
Primary Key. Código da
configuração.

kpic_code
nvarchar(100)
kpic_value
nvarchar(100)
Valor da configuração.
kpic_description
nvarchar(4000)
Descrição da configuração do KPI.
Dependencies
Dependent Tables
Dependent Procedures
7.5 KPI_ERROR_LOG
A tabela KPI_ERROR_LOG irá registar os problemas encontrados durante a execução dos
Stored Procedures de forma a facilitar a identificação e correcção de problemas. Tabela interna de
sistema.
Nome
Tipo
Def. Null Idx

Descrição
Chave estraneira que referencia o
KPI.
kpi_id
int
kel_error_number
int

Número do erro.
kel_error_severity
int

Gravidade do erro.
kel_error_state
int

Estado do erro.
kel_error_line
int

Linha do erro.
20
Especificação da base de dados
Especificação da base de dados
kel_error_procedure
nvarchar(200)

Procedimento do erro.
kel_error_message
nvarchar(4000)

Mensagem do erro.
kel_date
datetime
Dependencies
Data de ocorrencia do erro.
KPI
Dependent Tables
Dependent Procedures
Figura 5 - Diagrama ER relativo aos KPI
Especificação da base de dados
21
iEnergy – Eficiência Energética em Edifícios
Anexo VI – Fase de Integração
Anexo VI – Requisitos Fase de Integração
iEnergy – Eficiência Energética em Edifícios
Anexo VI – Fase de Integração
Este anexo apresenta os requisitos detalhados para a fase de integração relativos ao projecto de
eficiência energética em embarcações.
Associar Mestres a Viagem (RFMV)
No módulo “Gestão -> Mestres e Viagens" deve ser possível associar mestres a viagens, bem
como consultar os já existentes no sistema.
Requisito
Descrição
Introdução
deve
ser
feita
através
da
importação de um ficheiro Excel.
RFA01
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.
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
RFA06
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.
Requisito
Descrição
Serviço deve processar ficheiros de bilhética.
RFBL01
RFBL02
RFBL03
Para cada viagem existente no ficheiro, o serviço deve verificar se essa viagem
já existe no sistema.
Caso uma viagem não exista no sistema, esta deve ser inserida. Os dados
Especificação de requisitos
1
Anexo VI – Fase de Integração
iEnergy – Eficiência Energética em Edifícios
necessários para inserir uma viagem são:
o Data
o Hora
o Terminal partida
o Carreira
o Embarcação
o Passageiros
o Tipo Viagem (Carreira)
o Estado da viagem (Válida)
Notas
O formato dos dados dos ficheiros de bilhética contém a seguinte informação:
<dia value="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.
Requisito
Descrição
Na página inicial, deve ser apresentada uma mensagem indicando o número de
RFAL01
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
RFAL06
RFAL07
2
As colunas da tabela de alarmes “Por processar” são:
o Data/Hora
o Embarcação
o Mensagem
o Estado
No módulo “Operações -> Gestão de Alarmes” deve ser possível pesquisar
alarmes.
A pesquisa deve permitir filtragem por:
o Data
Especificação de requisitos
iEnergy – Eficiência Energética em Edifícios
o
o
RFAL08
Anexo VI – Fase de Integração
Embarcação
Estado
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.
Requisito
Descrição
O serviço de recolha de dados tem de distinguir entre os diferentes tipos de
RFMA01
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
Especificação de requisitos
3
Anexo VI – Fase de Integração
iEnergy – Eficiência Energética em Edifícios
Os alarmes do navio, só são gerados, caso não exista nenhum alarme com o estado “Em Processamento” ou
“Por processar” para o navio em causa.
Os alarmes da viagem, só são gerados, caso não exista nenhum alarme com o estado “Em Processamento” ou
“Por processar”, para a viagem em causa.
Os alarmes da bilhética, são sempre gerados.
Mecanismo de validação de viagens – novas regras
Abaixo estão descritas as novas regras para validação de viagens.
Notas
No módulo de validação de viagens devem ser incluídos os seguintes parâmetros como sendo necessária
validação:
o Consumo/Viagem inferior a 20 e superior a 220
o Distância/Carreira superior a 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.
Requisito
REDG01
REDG02
REDG03
REDG04
REDG05
REDG06
4
Descrição
Deverá existir no portal duas páginas dedicadas a criação de relatórios sobre os
dados gerais das embarcações, uma para relatórios anuais, outra para relatórios
mensais.
Na página de relatórios mensais deverá ser possível seleccionar o ano e o mês
para o qual se pretende criar um novo relatório.
Na página de relatórios anuais deverá ser possível seleccionar o ano para o qual
se pretende criar um novo relatório.
O relatório para o mês ou ano escolhido e apresenta uma tabela com as
seguintes colunas:
 Nome da embarcação;
 Consumo Horário (L/h) (caudalímetro);
 Consumo Horário (L/h) (Registos);
 Consumo/Carreira (L) (caudalímetro);
 Consumo/Carreira (L) (Registos;
 Consumo Total (L) (caudalímetro);
 Consumo Total (L) (Registos);
 Custo/Km (Euro/km);
 Distância/Carreira;
 Eficiência da Oferta (pKm/L);
 Eficiência da Procura (pKm/L);
 Motores/Carreira (%);
 Passageiros/Carreira (nº);
 Peso transportado (Kg);
 Tempo/Viagem (min);
 Velocidade (nós);
 Carreiras realizadas
Deve ser possível pré-visualizar o relatório na página.
Deve ser possível exportar o relatório criado para um dos seguintes formatos:
DOC, XLS, PDF.
Especificação de requisitos
iEnergy – Eficiência Energética em Edifícios
Anexo VI – Fase de Integração
Notas
Todos os cálculos são baseados na tabela Indicators, alguns dos valores são médias outros são somas. De seguida é
apresentada a forma que cada um destes indicadores é calculado:

Consumo Horário (L/h) (caudalímetro) – Consumo médio horário de uma embarcação numa viagem do tipo
carreira;

Consumo Horário (L/h) (Registos) – Consumo médio horário de uma embarcação numa viagem do tipo carreira
através dos registos de consumos inseridos;

Consumo/Carreira (L) (caudalímetro) – Consumo médio de uma embarcação por viagem do tipo carreira;

Consumo/Carreira (L) (Registos) – Consumo médio de uma embarcação por viagem do tipo carreira através
dos registos de consumos inseridos;

Consumo Total (L) (caudalímetro) – Soma dos consumos de uma embarcação;

Consumo Total (L) (Registos) – Soma dos consumos de uma embarcação dos registos de consumos inseridos;

Custo/Km (Euro/km) – Custo médio da embarcação por Km percorrido;

Distância/Carreira – Distância media percorrida por viagem do tipo carreira;

Eficiência da Oferta (pKm/L) - Eficiência média da oferta por pKm/L;

Eficiência da Procura (pKm/L) – Eficiência média da procura por pKm/L;

Motores/Carreira (%) – Percentagem de utilização dos motores em viagens do tipo carreira (( Tempo viagem
tipo carreira - tempo viagem manobras)/( Tempo outras viagens – Tempo carreira - Tempo manutenção));

Passageiros/Carreira (nº) - Número médio de passageiros por viagem do tipo carreira;

Peso transportado (Kg) – Peso médio transportado por viagem do tipo carreira;

Tempo/Viagem (min) - Duração média de cada viagem do tipo carreira;

Velocidade (nós) - Velocidade média das viagens do tipo carreira;

Carreiras realizadas – Soma das viagens do tipo carreira realizadas.
Os dados que não e possível adquirir através do cauldalímetro são assinaladas com N/A (Não aplicável) os dados
que não e possível calcular por não existirem dados são assinaladas com S/D (Sem dados).
Relatório de uso de embarcação (RUE)
O sistema deverá permitir a criação de relatórios com os dados de uso de uma embarcação para
um determinado intervalo de datas.
Requisito
RUE01
RUE02
RUE03
RUE04
Descrição
Deverá existir no portal uma página dedicada a criação de relatórios sobre o uso
de uma embarcação.
Na página do relatório mensal deverá ser possível seleccionar uma data inicial e
final para criação do relatório.
Na página do relatório mensal deverá ser possível seleccionar a embarcação
para criar o relatório.
Deverá existir uma tabela para cada um dos meses do ano com os dados gerais
da embarcação. As linhas da tabela são:
 Nome da embarcação
 Consumo Horário (L/h) (caudalímetro);
 Consumo Horário (L/h) (Registos;
 Consumo/Carreira (L) (caudalímetro);
 Consumo/Carreira (L) (Registos);
 Consumo Total (L) (caudalímetro;
 Consumo Total (L) (Registos);
 Custo/Km (Euro/km);
 Distância/Carreira.
 Eficiência da Oferta (pKm/L);
 Eficiência da Procura (pKm/L);
 Motores/Carreira (%);
 Passageiros/Carreira (nº);
 Peso transportado (Kg);
 Tempo/Viagem (min);
 Velocidade (nós);
 Carreiras realizadas.
Especificação de requisitos
5
Anexo VI – Fase de Integração
RUE05
REDG06
REDG07
REDG08
REDG09
iEnergy – Eficiência Energética em Edifícios
Deverá existir uma tabela para cada um dos meses do ano com os tempos totais
em percentagem gastos em cada um dos tipos de viagens. As linhas da tabela são:
 Outras viagens;
 Aquecimento;
 Carreira;
 Manobras;
 Por Validar;
 Tempo ao cais;
 Tempo geral;
 Total registos.
Deverá existir uma tabela para cada um dos meses do ano com os consumos
totais gastos em cada um dos tipos de viagens. As linhas da tabela são:
 Outras viagens;
 Aquecimento;
 Cruzeiro;
 Manobras;
 Por Validar;
 Tempo ao cais;
 Tempo geral;
 Total registos.
Deverá existir uma tabela com dados para cada um dos mestres por área
geográfica em relação as carreiras realizadas, velocidade e peso. As colunas da
tabela são:
 Mestre – Nome dos mestres;
 Consumo
o Média;
o Desvio padrão.
 Velocidade
o Média;
o Desvio padrão.
 Peso
o Média;
o Desvio padrão.
 Consumo total;
 Passageiros totais;
 Distância total percorrida;
 Nº Carreiras.
Deve ser possível pré-visualizar o relatório na página.
Deve ser possível exportar o relatório criado para um dos seguintes formatos:
DOC, XLS, PDF.
Notas
Todos os cálculos são baseados na tabela Indicators, alguns dos valores são médias outros são somas. Este relatório
está dividido por várias tabelas. De seguida é apresentada a forma que cada um destes indicadores dessas tabelas é
calculado.
Os indicadores da tabela para cada um dos meses do ano com os dados gerais da embarcação são calculados da
seguinte forma:

Consumo Horário (L/h) (caudalímetro) – Consumo médio horário de uma embarcação numa viagem do tipo
carreira;

Consumo Horário (L/h) (Registos) – Consumo médio horário de uma embarcação numa viagem do tipo carreira
através dos registos de consumos inseridos;

Consumo/Carreira (L) (caudalímetro) – Consumo médio de uma embarcação por viagem do tipo carreira;

Consumo/Carreira (L) (Registos) – Consumo médio de uma embarcação por viagem do tipo carreira através
6
Especificação de requisitos
iEnergy – Eficiência Energética em Edifícios












Anexo VI – Fase de Integração
dos registos de consumos inseridos;
Consumo Total (L) (caudalímetro) – Soma dos consumos de uma embarcação;
Consumo Total (L) (Registos) – Soma dos consumos de uma embarcação através dos dados inseridos;
Custo/Km (Euro/km) – Custo médio da embarcação por Km percorrido;
Distância/Carreira – Distância média percorrida por viagem do tipo carreira.
Eficiência da Oferta (pKm/L) - Eficiência média da oferta por pKm/L;
Eficiência da Procura (pKm/L) – Eficiência média da procura por pKm/L;
Motores/Carreira (%) – Percentagem de utilização dos motores em viagens do tipo carreira;
Passageiros/Carreira (nº) - Número médio de passageiros por viagem do tipo carreira;
Peso transportado (Kg) – Peso médio transportado por viagem do tipo carreira;
Tempo/Viagem (min) - Duração média de cada viagem do tipo carreira;
Velocidade (nós) - Velocidade média das viagens do tipo carreira durante um intervalo de tempo;
Carreiras realizadas – Número das viagens do tipo carreiras realizadas.
Os indicadores para a tabela de tempos totais em percentagem gastos em cada um dos tipos de viagens, são
calculados da seguinte forma:

Outras viagens - Percentagem de tempo total gasto em viagens validas que não são cruzeiro, manobras, tempo
em cais ou aquecimento;

Aquecimento – Percentagem de tempo total gasto em viagens validas do tipo aquecimento;

Carreira - Percentagem de tempo total gasto em viagens validas do tipo Carreira;

Manobras - Percentagem de tempo total gasto em viagens validas do tipo manobras;

Por Validar - Percentagem de tempo total gasto em todas as viagens que ainda não estão validadas;

Tempo ao cais - Percentagem de tempo total gasto em cais que ainda não estão validadas, em cada um dos
meses do ano;

Tempo geral – Tempo total em horas gasto para cada uma das viagens acima descritas;

Total registos – Tempo total de funcionamento calculado a partir dos dados introduzidos.
Os indicadores da tabela de consumos totais gastos em cada um dos tipos de viagens, são calculados da seguinte
forma:

Outras viagens – Consumo em viagens validas que não sejam viagens de carreira, manobra, tempo em
cais ou aquecimento;

Aquecimento – Consumo em viagens validas do tipo aquecimento;

Cruzeiro - Consumo em viagens validas do tipo carreira;

Manobras - Consumo em viagens validas do tipo manobras;

Por Validar - Consumo médio em viagens que não estão validadas;

Tempo ao cais - Consumo médio em cais de viagens validadas;

Tempo geral - Consumo total gasto para cada mês do ano;
Os indicadores na tabela para cada um dos mestres por área geográfica em relação as carreiras realizadas, velocidade
e peso, são calculados da seguinte forma:

Consumo - Cálculo do consumo para cada um dos mestres
o Média – Valor médio de consumo do mestre em viagens do tipo carreira para o intervalo de tempo
especificado;
o Desvio padrão – Desvio padrão amostral de consumo de viagens do tipo carreira.

Velocidade - Cálculo da velocidade para um mestre
o Média – Velocidade média do mestre em viagens do tipo carreira;
o Desvio padrão – Desvio padrão amostral de velocidade de viagens do tipo carreira.

Peso - Cálculo do peso carregado por cada mestre nas viagens realizadas
o Média – Media de pesos de viagens do tipo carreira por cada mestre;
o Desvio padrão – Desvio padrão amostral do peso de viagens do tipo carreira.

Consumo total – Consumo total de combustível em viagens do tipo carreira por cada mestre;

Passageiros totais – Número total de passageiros em viagens do tipo carreira para cada um dos mestres;

Distância total percorrida – Distância total percorrida em viagens do tipo carreira por cada um dos mestres;

Nº Carreiras – Total de viagens do tipo carreira realizadas por cada um dos mestres.

Total registos – Consumo total calculado a partir dos dados introduzidos.
Os tempos são calculados a partir da hora de partida e chegados registados na tabela journey.
O intervalo de datas deve ser no máximo um ano.
Os dados que não e possível adquirir através do cauldalímetro são assinaladas com N/A (Não aplicável) os dados
que não e possível calcular por não existirem dados são assinaladas com S/D (Sem dados).
A fórmula usada para calcular o desvio padrão é a seguinte:
S
k
1

k
i 1
fi
 (( x
i 1
i
 x) 2  f i )
Especificação de requisitos
7
Anexo VI – Fase de Integração
iEnergy – Eficiência Energética em Edifícios
Relatório de carreiras por área geográfica (RCAG)
O sistema deverá permitir a criação de relatórios com dados relativos as carreiras realizadas
para cada área geográfica para um determinado intervalo de datas.
Requisito
RCAG01
RCAG02
RCAG03
RCAG04
RCAG5
RCAG6
RCAG7
Descrição
Deverá existir no portal uma página dedicada a criação de relatórios sobre o uso
de uma embarcação.
Na página do relatório deverá ser possível seleccionar uma data inicial e final
para criação do relatório.
Na página do relatório deverá ser possível seleccionar a área geográfica.
Deverá existir uma tabela com alguns dados da embarcação. As colunas da
tabela são:
 Número Carreiras;
 Consumo/Carreira
o Desvio Padrão
 Consumo/Carreira (Registos);
 Passageiros/Carreira
o Desvio Padrão
Deverá existir uma tabela com alguns dados das ligações para a área geográfica.
As colunas da tabela estão divididas fim-de-semana e feriados para cada uma dessas
divisões são calculados os indicadores:
 Passageiros/carreira;
 Desvio padrão.
Deve ser possível pré-visualizar o relatório na página.
Deve ser possível exportar o relatório criado para um dos seguintes formatos:
DOC, XLS, PDF.
Notas
Todos os cálculos são baseados na tabela Indicators, alguns dos valores são médias outros são somas. Este relatório
está dividido em duas tabelas. Estas tabelas são apresentadas de seguida.
Os indicadores na tabela com dados de embarcação, são calculados da seguinte forma:

Número Carreiras – Número total de carreiras para a área geográfica em análise;

Consumo/Carreira – Consumo médio por carreira (media de consumo por viagem do tipo carreira para a área
geográfica).
o Desvio Padrão – Desvio padrão amostral de consumo por carreira.

Consumo/Carreira (Registos) – Consumo por carreira baseado nos registos inseridos através do ficheiro de
consumos;

Passageiros/Carreira – Média de passageiros por carreira (média de passageiros em viagens do tipo carreira)
o Desvio Padrão – Desvio padrão amostral de passageiros por carreira.
Os indicadores na tabela com as medias e desvio padrão de passageiros, são calculados da seguinte forma:

Passageiros/carreira – Média de passageiros por carreira (média de passageiros em viagens do tipo carreira).

Desvio padrão – Diferença entre o valor máximo e mínimo de passageiros por carreira.
Os dados que não e possível adquirir através do cauldalímetro são assinaladas com N/A (Não aplicável) os dados
que não e possível calcular por não existirem dados são assinaladas com S/D (Sem dados).
A fórmula usada para calcular o desvio padrão é a seguinte:
S

k
i 1
8
k
1
fi
 (( x
i 1
i
 x) 2  f i )
Especificação de requisitos
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
2
ÍCONES DA APLICAÇÃO ......................................................................................................... 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
5
RELATÓRIOS .......................................................................................................................... 13
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
6
RESULTADOS ...................................................................................................................... 12
SECÇÃO DE ENERGIA ACTIVA ............................................................................................. 14
SECÇÃO DE ENERGIA REACTIVA ......................................................................................... 15
SECÇÃO DE FACTOR DE POTÊNCIA...................................................................................... 16
SECÇÃO DE ANÁLISE DE POTÊNCIA .................................................................................... 17
SECÇÃO DE INDICADORES DE ESTADO ................................................................................ 18
SECÇÃO DE INDICADORES DE POUPANÇA ........................................................................... 18
POUPANÇA DE ENERGIA ACTIVA ........................................................................................ 18
POUPANÇA DE DINHEIRO .................................................................................................... 18
POUPANÇA DE EMISSÕES .................................................................................................... 19
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
7.2
7.3
LISTAGEM ............................................................................................................................47
EDITAR ................................................................................................................................48
ADIÇÃO ...............................................................................................................................49
Manual de Utilizador
1 Introdução
O portal iEnergy4Buildings é um portal de eficiência energética que permite fazer análise de consumo, simulações
de tarifários e produzir relatórios que permitam analisar os gastos e proveitos associados ao comportamento
energético de edifícios. Existe ainda um back office que permite fazer administração de algumas entidades do sistema.
O portal divide-se em quatro secções distintas que são as seguintes:

Visualização – secção que permite fazer a análise e comparação de consumos com diferentes intervalos
de tempo;

Mensagens – secção que permite as mensagens que aparecem nos aplicativos disponíveis aos
utilizadores do sistema;

Simulação – secção que permite fazer simulações para identificar a melhor tarifa a ser aplicada a cada
edifício;

Relatórios – secção que permite gerar relatórios que possibilitam analisar o comportamento energético
de um edifício.

Tarifários – Permite fazer gestão dos tarifários existentes no sistema.

Grupos – Permite fazer a gestão dos grupos existentes no sistema.

Alertas – Permite gerir e ver os alertas disparados no sistema.
Neste documento são descritas as secções indicadas em detalhe para que o utilizador consiga tirar um melhor
proveito do sistema.
Manual de Utilizador
1
Manual de Utilizador
1.1 Ícones da aplicação
Ícone
Funcionalidade
Adicionar um registo.
Indicação que uma acção está a ser executada.
Representa um campo do tipo booleano marcado com o valor falso.
Representa um campo do tipo booleano marcado com o valor verdadeiro.
Acesso ao componente calendário.
Botões para expandir e encolher.
Apagar um registo.
Editar um registo.
Atribuir nova password.
Indicação do estado OK de uma Unidade, Dispositivo ou Tag.
Exportar dados para um ficheiro do tipo excel.
Executar pesquisa.
Exportar os dados para um ficheiro excel.
Indica que está a ser feito um pedido ao servidor.
2 Visualização
A secção de visualização é a secção que permite analisar os consumos de um ou mais edifícios/agências. Ao
aceder a esta secção é apresentada uma janela semelhante à seguinte:
2
Manual de Utilizador
Manual de Utilizador
Imagem 1 - Janela de Visualização
A secção de Visualização divide-se em 3 áreas:
Árvore das Agências e Edifícios
Campos de Filtragem do Gráfico
Visualização do Gráfico (e Tabelas de dados)
2.1 Árvore de Agências e Edifícios
A caixa de pesquisa:
Imagem 2 - Caixa de Pesquisa
permite filtrar, na árvore, a(s) agência(s) e edifício(s) pelo seu nome, reduzindo assim o tempo que o utilizador
demora a localizar uma agência em específico.
A Árvore apresenta vários níveis:
Manual de Utilizador
3
Manual de Utilizador
Imagem 3 – Árvore
- Nível Topo
: Estão localizadas as agências e edifícios;
- Nível Intermédio
- Nível Folha
: Estão localizados os grupos das agências e edifícios;
: 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):
4
Manual de Utilizador
Manual de Utilizador
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):
Manual de Utilizador
5
Manual de Utilizador
Imagem 10 - Intervalos de Tempo
Podem acrescentar-se
intervalos à listagem de intervalos de duas formas:
- Usando a opção
a Data de Início do intervalo será o dia mais antigo seleccionado no
calendário e a Data de Fim será o dia mais recente seleccionado no calendário;
- Usando a opção
a Data de Início será igual ao valor de Data Início e a Data
de Fim será igual ao valor de Data Fim.
O utilizador pode escolher entre 4 opções (operações) de amostragem dos dados no gráfico nos intervalos de
tempo definidos na listagem:

A opção
irá apresentar os dados no gráfico fazendo a média dos valores em cada intervalo de tempo
definido;

A opção
irá apresentar os dados no gráfico fazendo a soma dos valores em cada intervalo de tempo
definido;

A opção
irá apresentar os dados no gráfico fazendo a média sobre os valores de todos os intervalos
de tempo definidos;

A opção
irá apresentar os dados no gráfico fazendo a soma sobre os valores de todos os intervalos de
tempo definidos.
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);
6
Manual de Utilizador
Manual de Utilizador

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:
Manual de Utilizador
7
Manual de Utilizador
Imagem 13 - Tabela Geral
A tabela apresenta os dados detalhados por data (granularidade definida na filtragem), o edifício, o grupo, o
parâmetro (variável de medida), o valor (para cada ponto de dados no gráfico) e a unidade de medida da variável.
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.
8
Manual de Utilizador
Manual de Utilizador
Esta
secção
apresenta
ainda
a
informação
dos
consumos
divididos
por
tipos
de
hora:
Imagem 15 - Consumos por tipo de hora
A informação mostra o tipo de hora, a data, o edifício/agência, o grupo, o parâmetro (variável de medida) e o
valor correspondente ao consumo nesse período temporal.
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:
Manual de Utilizador
9
Manual de Utilizador
Imagem 18 - Secção de Mensagens
Ao aceder a esta secção o utilizador pode ver uma lista das mensagens existentes no sistema. Para facilitar a
pesquisa o utilizador pode filtrar as mensagens por agência/edifício, para isso basta seleccionar a agência/edifício
pretendida da lista do campo Agência e clicar no botão Pesquisar.
Para cada mensagem da listagem o utilizador pode apagar clicando em
ou pode editar clicando em
.
Quando o utilizador tenta apagar uma mensagem é apresentada uma janela, como a seguinte, para o utilizador
confirmar que quer apagar:
Imagem 19 - Confirmar que pretende apagar mensagem
Quando o utilizador clica em Editar ou em Nova Mensagem, aparece uma janela semelhante à seguinte:
10
Manual de Utilizador
Manual de Utilizador
Imagem 20 - Janela de editar e criar mensagem
Para criar uma mensagem é necessário o utilizador inserir a seguinte informação:

Agência – O utilizador deve seleccionar uma agência/edifício entre as que já existem no sistema;

Severidade – O nível de importância da mensagem. Existem no sistema três níveis: Alta, média e baixa;

Título – O título que é atribuído à mensagem;

Corpo – O conteúdo extenso da mensagem.
Ao clicar em Guardar é guardada a mensagem no sistema, ou se não foi preenchido nenhum campo obrigatório é
apresentada uma mensagem de aviso indicando qual o campo obrigatório em falta.
4 Simulação
A secção de simulação permite simular os custos dos consumos de uma agência/edifício em determinado período
de tempo para as várias tarifas configuradas no BackOffice. Ao aceder a esta secção é apresentada uma janela
semelhante à seguinte:
Manual de Utilizador
11
Manual de Utilizador
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:
12
Manual de Utilizador
Manual de Utilizador
Imagem 22 - Resultado de Simulação
As linhas da tabela de resultados da simulação apresentam os custos dos tarifários e respectivas versões,
combinados com os custos fixos associados a cada um dos tarifários.

A informação apresentada em cada linha distribui-se por:

Custos pelos Tipos de Hora;

Custo de Potência Contratada;

Custo de Potência em Horas de Ponta;

Custo de Energia Reactiva Indutiva;

Custo de Energia Reactiva Capacitiva;

Custo Fixo;

Custo Total: Soma dos valores das colunas prévias;

Poupança: Apresenta a diferença entre o custo do tarifário actual da agência e o custo simulado do tarifário
da linha. Um valor a verde significa que houve poupança e a vermelho significa que houve mais gasto.
Na legenda aparece referenciado o tarifário activo (*) e por (#) os tarifários que não podem ser usados por não
terem potência contratada suficiente para as necessidades da agência/edifício. Devem ser visualizadas estes tarifários
nas linhas da tabela de resultados.
Nota: Os tarifários devem estar previamente parametrizados no BackOffice, nomeadamente devem estar
parametrizados os tipos de hora, os custos de energia activa pelos tipos de hora, os custos de energia reactiva e
indutiva pelos tipos de hora, os custos da potência pelos tipos de hora, e os vários custos fixos associados ao tarifário.
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:
Manual de Utilizador
13
Manual de Utilizador
Imagem 23 - Janela de relatórios
Para gerar um relatório o utilizador tem de:
1.
Seleccionar uma agência ou edifício (no máximo só pode seleccionar um item) apresentado na árvore de
agências e edifícios - barra lateral esquerda;
2.
Seleccionar a data inicial (Data Início) e seguidamente um tipo de período (diário, semanal, mensal ou anual).
Consoante o tipo escolhido automaticamente é encontrado o dia final (Data Fim). É esse período temporal
que vai ser usado na geração do relatório;
3.
Seleccionar a tipo de relatório:

Completo – Toda a informação é exibida: Secção de Energia Activa, Secção de Factor de Potência,
Secção de Energia Reactiva, Secção de Análise de Potência, Secção de Indicadores de Estado, Secção de
Indicadores de Poupança;

Resumido – Secção de Energia Activa, Secção de Energia Reactiva, Secção de Indicadores de Estado,
Secção de Indicadores de Poupança.
4.
Clicar no botão Submeter.
O relatório gerado no formato PDF pode ser impresso
ou guardado
em disco.
5.1 Secção de Energia Activa
É apresentado o gráfico e tabela de dados da variável de medida de energia activa associada à agência/edifício
que foi seleccionada para a geração do relatório, para o período temporal escolhido.
14
Manual de Utilizador
Manual de Utilizador
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.
Manual de Utilizador
15
Manual de Utilizador
Imagem 25 - Energia Reactiva
Os valores apresentados na tabela por cada variável de medida de energia reactiva são:

Média;

Desvio Padrão;

Máximo;

Mínimo;

Total;

Frequência.
É também apresentada a tabela de custos (por tipos de hora) das variáveis de medida de energia reactiva. Os
dados correspondem a:

Tipo do intervalo;

Percentagem - de custo da energia, no tipo de intervalo, em relação ao total;

Custo Específico – valor do custo para o tipo de intervalo;

Total;

Média;

Máximo;

Mínimo.
Nota: É necessária a prévia configuração das variáveis de medida de energia reactiva no BackOffice (criação de
variáveis de medida secundárias com base em variáveis de medida primárias do tipo energia reactiva) assim como da
correcta configuração do tarifário (tipos de hora e respectivos custos) associado à agência seleccionada para a geração
do relatório.
5.3 Secção de Factor de Potência
É apresentado o gráfico e tabela de dados da variável de medida de factor de potência associada à
agência/edifício, que foi seleccionada para a geração do relatório, para o período temporal escolhido.
16
Manual de Utilizador
Manual de Utilizador
Imagem 26 - Factor de Potência
Os valores apresentados na tabela de dados incluem:

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
Os valores apresentados na tabela de dados incluem:


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:
Manual de Utilizador
17
Manual de Utilizador
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 à
agência/edifício, que foi seleccionada para a geração do relatório, para o período temporal escolhido.
Imagem 28 - Indicadores de Estado
A tabela apresenta uma listagem com o nome do indicador e o respectivo valor, para o período temporal
escolhido.
Nota: Para a apresentação da Secção de Indicadores de Estado estes indicadores devem ser previamente
configurados no BackOffice para cada agência/edifício seleccionada.
5.6 Secção de Indicadores de Poupança
É apresentada uma tabela de dados com os indicadores de poupança, e respectivos valores, associados à
agência/edifício, que foi seleccionada para a geração do relatório, para o período temporal escolhido.
5.7 Poupança de Energia Activa
É apresentado na tabela as diferenças entre os valores medidos e os valores expectáveis (valores da Baseline) para
cada mês e pelos vários tipos de hora existentes no sistema.
Imagem 29 - Poupança de Energia Activa
Nota: Para a apresentação dos Indicadores de Poupança de Energia Activa, no BackOffice, deve ser configurada
previamente a Baseline associada a cada agência/edifício. Esta configuração envolve caracterizar os consumos por mês
e por tipo de hora.
5.8 Poupança de Dinheiro
Os valores das poupanças de dinheiro resultam da multiplicação dos valores da tabela de poupança de consumos
de energia activa, pelo custo (por tipo de hora) parametrizado para o tarifário do mês em análise.
18
Manual de Utilizador
Manual de Utilizador
Imagem 30 - Poupança de Dinheiro
Nota: Para a apresentação dos Indicadores de Poupança de Dinheiro, no BackOffice, deve ser configurada
previamente a Baseline associada a cada agência/edifício além de ter-se de configurar correctamente os custos pelos
tipos de hora do tarifário associado à agência para a qual se está a gerar o relatório.
5.9 Poupança de Emissões
A tabela de dados de Poupança de Emissões resulta da multiplicação dos valores da tabela de poupança de
consumos de energia activa, pelo factor de conversão configurado no BackOffice.
Imagem 31 - Poupança de Emissões
Nota: Para a apresentação dos Indicadores de Poupança de Emissões, no BackOffice, deve ser configurada
previamente a Baseline associada a cada agência/edifício além de ter de se configurar correctamente o factor de
conversão de energia por CO2, no BackOffice.
6 Operações de Back Office
6.1 Alertas
No painel Alertas Disparados, o utilizador pode consultar os alertas disparados por unidade, tipo de alerta, nome,
data e hora.
Imagem 32 - Painel de Alertas
Manual de Utilizador
19
Manual de Utilizador
O painel oferece a possibilidade de filtrar os dados através de vários campos relativos ao Alerta: Tipo de Alerta,
Novo, Alerta, Prioridade, Data, Unidade, Grupo e Tag.
Imagem 33 - Alertas filtrados por Prioridade Miníma
Neste painel, além do utilizador conseguir ver os detalhes dos alertas disparados, pode também verificar a data,
se foi ou não enviado 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.
20
Manual de Utilizador
Manual de Utilizador
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.
Manual de Utilizador
21
Manual de Utilizador
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.
22
Manual de Utilizador
Manual de Utilizador
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.
Manual de Utilizador
23
Manual de Utilizador
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
24
Manual de Utilizador
Manual de Utilizador
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.
Manual de Utilizador
25
Manual de Utilizador
Imagem 43 - Criar Indicador
Neste painel o utilizador pode definir a seguinte informação:

Nome – Nome que quer dar ao Indicador;

Pesquisa de tags – Permite pesquisar as tags que podem ser associadas ao Indicador. Estas tags são todas as
tags que estejam no grupo ou nos seus sub-grupos;

Fórmula – Local onde se constrói a fórmula que define os valores da virtual tag e que contém as opções:
o
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
26
Manual de Utilizador
Manual de Utilizador
activa a opção principal o grupo passa a ser considerado como grupo principal e tem obrigatoriamente que ter um
sub-grupo geral.
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.
Manual de Utilizador
27
Manual de Utilizador
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;


28
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
Manual de Utilizador
Manual de Utilizador
Imagem 48 - Adição de Baseline do Ano 0
No final o utilizador ao clicar em Ok é guardada a Baseline no sistema, se carregar em Cancel é descartada a
informação que foi introduzida no formulário da Baseline.
Ao guardar a Baseline ao utilizador é apresentada a Baseline na listagem de Baselines do Grupo, como
demonstrado na imagem seguinte.
Imagem 49 - Listagem de Baselines
Actualizar Baseline
Depois de criada a Baseline do Ano 0 só pode ser actualizada essa Baseline com dados para os meses do Ano 1
(automaticamente definido como o ano posterior ao Ano 0). Clicando no botão
do registo da Baseline do ano 0
é-lhe apresentada a janela de actualização.
Manual de Utilizador
29
Manual de Utilizador
Imagem 50 - Actualização de Baseline
Nesta janela o utilizador pode escolher o mês da actualização, no campo Data. Automaticamente é restringido o
mês começando no mês de início do ano ou o mês posterior ao último mês de actualização da Baseline do Ano 1.
O utilizador pode preencher de seguida os campos com as alterações de consumos que aconteceram desde o
mês do ano 0 para o mês do ano 1, nomeadamente:


AVAC – Sistema Avac associado ao grupo:
o
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).
30
Manual de Utilizador
Manual de Utilizador
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
Manual de Utilizador
31
Manual de Utilizador
podem deixar de pertencer a uma hierarquia. Assim, se o Grupo não possuir nenhuma outra ligação, a separação não
pode ser efectuada.
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.
32
Manual de Utilizador
Manual de Utilizador
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
Manual de Utilizador
33
Manual de Utilizador
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
34
Manual de Utilizador
Manual de Utilizador
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.
Manual de Utilizador
35
Manual de Utilizador
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.
36
Manual de Utilizador
Manual de Utilizador
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
Neste painel o utilizador pode definir a seguinte informação:

Nome – nome da tarifa;

Período de facturação – período de facturação associado com a tarifa;

Data de início da tarifa – Data em que a tarifa começa;

Tipo de Temporada – Associação da tarifa as estações da secção de estações;

Publico – Se a tarifa tem visibilidade publica ao não;

Tipo – Tipo de tarifa (escalões ou intervalos);
Depois de adicionar a informação o utilizador será redireccionado para o painel mostrado na Imagem 63.
Manual de Utilizador
37
Manual de Utilizador
Imagem 63 - Detalhe de Tarifa
Nota que o sistema indica que não foram encontrados períodos nem escalões nem parâmetros nem factores de
multiplicação, para adicionar qualquer uma destas entidades o utilizador pode clicar no Adicionar Período, Adicionar
Passo ou Adicionar Custos Fixos, Adicionar Parâmetro respectivamente.
Quando o utilizador clica no botão de adicionar período o painel da Imagem 64 é mostrado ao utilizador.
Imagem 64 - Adição de Período
Como é visível no painel de adição de intervalos o utilizador terá de preencher a seguinte informação:

Inicio – Hora de início do intervalo.

Fim – Hora de fim do intervalo.

Temporada – Um inteiro que indica a estação em que o intervalo é aplicado. As estações são definidas em
separado. Por agora, a estação 0 é o verão e a estação 1 é o inverno.
38
Manual de Utilizador
Manual de Utilizador

Tipo de hora – Tipo de hora a que o intervalo pertence.

Preço – Valor numérico que indica o preço.

Dias da semana – Dias da semana em que o intervalo é aplicado.
Depois de preenchida a informação requerida o utilizador pode clicar em guardar e guardar o intervalo na base
de dados. Esta acção vai então redireccionar o utilizador para os detalhes da tarifa Imagem 65.
Imagem 65 - Listagem de Períodos por Tipo de Hora
Note de que depois de inserir a informação dos intervalos a mensagem de aviso anterior desaparece.
Para adicionar um custo fixo o processo é semelhante. O utilizador clica no botão Adicionar custo fixo o que lhe
vai mostrar o painel na Imagem
66.
Imagem 66 - Adição de Custo Fixo
Como é visível no painel de adição de custos fixos o utilizador terá de preencher a seguinte informação:

Descrição – Descrição do custo fixo;

Preço – Valor numérico que indica o preço;

Potência contractada – Potência que esta associada ao custo fixo;
Depois de preenchida a informação requerida o utilizador pode clicar em guardar e guardar o custo fixo na base
de dados. Esta acção vai então redireccionar o utilizador para os detalhes da tarifa Imagem 67.
Imagem 67 - Listagem de Custo Fixo
Para adicionar um parâmetro ao tarifário o processo é semelhante. O utilizador clica no botão Adicionar
parâmetro o que lhe vai mostrar o painel na Imagem 68.
Manual de Utilizador
39
Manual de Utilizador
Imagem 68 - Adição de Parâmetro
Como é visível no painel de adição de parâmetros o utilizador terá de preencher a seguinte informação:

Nome – Nome do parâmetro tarifário;

Período de cálculo – De quanto em quanto tempo o parâmetro deve ser calculado;

Parâmetro – Parâmetro que vai ser associado ao tarifário;

Tipos de horas – Tipos de hora em que o parâmetro vai ser avaliado;

Preço – Preço associado ao parâmetro;
Depois de preenchida a informação requerida o utilizador pode clicar em guardar e guardar o parâmetro na base
de dados. Esta acção vai então redireccionar o utilizador para os detalhes da tarifa Imagem 69.
Imagem 69 - Listagem de Parâmetros
Nos parâmetros do tarifário para além das opções de edição, apagar existe ainda uma opção associada ao
parâmetro de energia reactiva indutiva, que permite adicionar novos factores de multiplicação. O utilizador clica no
botão de adição de factor de multiplicação (
) sendo mostrado a formulário de factores de multiplicação como
mostra a Imagem 70.
40
Manual de Utilizador
Manual de Utilizador
Imagem 70 - Factor de Multiplicação
Como é visível no painel de adição de factores de multiplicação o utilizador terá de preencher a seguinte
informação:

Descrição – Descrição do factor de multiplicação;

Máximo – Valor máximo do factor;

Mínimo – Valor mínimo do factor;

Factor de multiplicação – Factor de multiplicação atribuído.
Depois de preenchida a informação requerida o utilizador pode clicar em guardar e o factor de multiplicação é
adicionado na base de dados. Esta acção vai então redireccionar o utilizador para os detalhes da tarifa Imagem 711.
Imagem 71 - Listagem de Factor de Multiplicação
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.
Manual de Utilizador
41
Manual de Utilizador
Imagem 72 - Adição de Tarifa de Tipo Escalão
Depois de adicionada a tarifa de escalão é mostrado um painel em tudo parecido com o painel de tarifas por
intervalos como mostra a Imagem 73.
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.
42
Manual de Utilizador
Manual de Utilizador
Imagem 74 - Adicionar Escalão
Adicionar novo escalão requer que o utilizador preencha o campo de mínimo, máximo com uma identificação
numérica e indicar o custo do novo escalão. Depois de preencher os dois campos o utilizador pode pressionar guardar
o que vai guardar a informação na base de dados e redirecciona para o painel de detalhes de tarifa da Imagem 75.
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.
Manual de Utilizador
43
Manual de Utilizador
Imagem 76 - Edição de Tarifa
Neste ponto acabamos a adição de informação sobre uma tarifa específica do fornecedor, mais tarifas podem ser
adicionas seguindo os passos anteriores.
Outra informação importante que pode ser adicionada ao fornecedor é o código postal onde estes oferecem os
seus serviços. No painel de detalhes de fornecedor na imagem 66 existe uma secção que permite o utilizador
adicionar, remover e procurar por códigos postais que foram associados aos fornecedores. Para adicionar um código
postal o utilizado precisa simplesmente de especificar o número do código postal e clicar no botão de adicionar.
Note que o código postal tem dois números separados por traço, o primeiro número contém sempre 4 dígitos e
o segundo contém sempre 3 dígitos (ex. 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
44
Manual de Utilizador
Manual de Utilizador
Se o utilizador desejar apagar um código postal específico ou todos os códigos postais apenas tem de preencher
a caixa de texto de apagar e pressionar o botão de apagar. Outra opção para apagar um código postal específico é
usar o botão de apagar na lista de códigos postais.
6.5 Estações
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.
Manual de Utilizador
45
Manual de Utilizador
Imagem 80 - Detalhe de Estação
No painel de detalhes, o utilizador pode ver todas as temporadas associados a uma estação específica.
Na secção esquerda o utilizador tem três botões que dão acesso a acções diferentes:
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.
46
Manual de Utilizador
Manual de Utilizador
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
Manual de Utilizador
47
Manual de Utilizador
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
48
Manual de Utilizador
Manual de Utilizador
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
Manual de Utilizador
49