Instituto de Pesquisas Tecnológicas do Estado de São Paulo
Vitor Monteiro Puente
Especificação de modelo de interoperabilidade de negócios nagestão de eficiência energética utilizando harmonização de
modelos de referência
São Paulo2018
Vitor Monteiro Puente
Especificação de modelo de interoperabilidade de negócios na gestão de eficiênciaenergética utilizando harmonização de modelos de referência
Dissertação de Mestrado apresentada aoInstituto de Pesquisas Tecnológicas doEstado de São Paulo - IPT, como partedos requisitos para a obtenção do títulode Mestre em Engenharia da Computação:Engenharia de Software
Data da aprovação ____/____/______
____________________________________Prof. Dr. Mario Yoshikazu Miyake (Orienta-dor)Instituto de Pesquisas Tecnológicas doEstado de São Paulo
Membros da Banca Examinadora:
Prof. Dr. Mario Yoshikazu Miyake (Orientador)Instituto de Pesquisas Tecnológicas do Estado de São Paulo
Prof. Dr. Jorge Luis Risco BecerraUSP - Universidade de São Paulo
Prof. Dr. Nelson TanomaruAtech – Negócios em Tecnologia S/A
Vitor Monteiro Puente
Especificação de modelo de interoperabilidade de negócios na gestãode eficiência energética utilizando harmonização de modelos de
referência
Dissertação de Mestrado apresentada aoInstituto de Pesquisas Tecnológicas doEstado de São Paulo - IPT, como partedos requisitos para a obtenção do títulode Mestre em Engenharia da Computação:Engenharia de Software
Área de Concentração: Engenharia de Soft-ware
Orientador: Prof. Dr. Mario Yoshikazu Miyake
São PauloJaneiro/2018
AGRADECIMENTOS
A Aline por todo o amor, suporte e compreensão em todos os momentos. Sem isso,
este trabalho seria impossível.
A minha família por sempre me motivar a estudar cada vez mais e pela estrutura
que me deram, permitindo-me cumprir todos esses anseios.
Ao Prof. Dr. Mário Yoshikazu Miyake pela orientação sempre presente e pelo de-
safio posto frente a mim. Sua determinação sempre me ajudou a ir em frente, seus
conselhos e seus ensinamentos estão presentes neste trabalho.
Ao Prof. Dr. Jorge Luis Risco Becerra pela contribuição que deu a este trabalho
com suas análises e suas observações.
Ao Prof. Dr. Nelson Tanomaru pela ajuda e atenção que dedicou a este trabalho.
Ao Roberto Henrique Marchiori por apoiar meu trabalho e pelas discussões sobre
modelos, teorias, processos e tudo mais.
A Juan Felipe Naranjo, Prof. Ms. Ana Rossi e ao Lucas Torreão por toda a ajuda,
por todos os conselhos e por sempre trazer um olhar diferente para esta pesquisa.
A todos amigos que me apoiara e me motivaram.
Ao meus amigos de trabalho, especialmente Clément Rouquie e Rodrigo Colossi,
que sempre me apoiaram na dedicação a este trabalho.
RESUMO
O aumento de demanda por energia tem crescido e o aumento da oferta não temacompanhado no mesmo ritmo. Enquanto as fontes de energia não renováveis estãocada vez mais questionadas, as soluções que buscam usar fontes renováveis aindaestão em desenvolvimento. Apesar do investimento na geração de energia, o desen-volvimento de soluções na gestão de eficiência energética proverão maior benefíciono curto prazo. O Grupo de Arquitetura e Fábrica de Software (GARFSoft), perten-cente ao Laboratório de Tecnologia e Software (LTS) no Departamento de Computa-ção e Sistemas Digitais (PCS) da Escola Politécnica da Universidade de São Paulo(USP), está desenvolvendo um sistema de gestão de eficiência energética. Esse sis-tema possui serviços de software estruturados em dois níveis, gerencial e operacional.Atualmente, a evolução deste software está limitada devido aos impactos que mudan-ças nos serviços operacionais causam nos serviços gerenciais. Este trabalho propõea especificação de um modelo de interoperabilidade de negócios na gestão de efici-ência energética, o qual irá apoiar a evolução dos sistemas de gestão de eficiênciaenergética desenvolvidos no GARFSoft. Esse modelo será a base para especificaçãode um middleware para o tratamento da interoperabilidade de negócios. Dessa forma,procura-se permitir que as aplicações em nível gerencial não sofram impactos devidoa mudanças no nível operacional.
Palavras-chave: internet das coisas, redes elétricas inteligentes. interoperabilidade,middleware.
ABSTRACT
Especificação de modelo de interoperabilidade de negócios na gestão de efici-ência energética utilizando harmonização de modelos de referênciaDemand for energy consumption has increased in the last years and energy genera-tion does not offer a short time solutions. Meanwhile, renewable resources are still incharge due the fact that there is still some development to be done in order to achieveits full potential. Despite all the investment in energy generation, solutions focused onenergy efficiency has shown better results for the shor time. At Grupo de Arquitetura eFábrica de Software (GARFSoft), located at Laboratório de Tecnologia e Software (LTS)at Departamento de Computação e Sistemas Digitais (PCS) at Escola Politécnica daUniversidade de São Paulo (USP), is developing a software focused on energy effici-ency services. These services are cathegorized in two levels, strategic and operational.Nowadays, evolve this software is hard due to impacts that changes on operationallevel causes on strategic level. This thesis has the goal of specify a business intero-perability model on management of energy efficiency, that will support the evolution ofthe energy efficiency system developed at GARFSOft. This model will act as a basisfor the specification of a middleware for the treatment of business interoperability. Withthis model, changes on services at operation level would not impact strategic levels.
Keywords: internet of things, smart grid, interoperability, middleware.
LISTA DE ILUSTRAÇÕES
Figura 1 – Alternativas para o atendimento da crescente demanda de energiaidentificadas pela Empresa de Pesquisas Energéticas . . . . . . . . 22
Figura 2 – Problemas de design e perguntas do conhecimento referentes a esteprojeto de pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figura 3 – Processo de pesquisa utilizado nesta pesquisa . . . . . . . . . . . . 28Figura 4 – Visões sobre IoT por Atzori et al. (2010) . . . . . . . . . . . . . . . . 32Figura 5 – Modelo de referência para internet das coisas . . . . . . . . . . . . . 41Figura 6 – Modelo de domínio definido no ARM . . . . . . . . . . . . . . . . . . 42Figura 7 – Modelo de informação definido no ARM . . . . . . . . . . . . . . . . 43Figura 8 – Modelo de funcional definido no ARM . . . . . . . . . . . . . . . . . 44Figura 9 – Modelo conceitual do SGAM . . . . . . . . . . . . . . . . . . . . . . 48Figura 10 – A planície do SGAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Figura 11 – O modelo de interoperabilidade do GWAC, suas categorias e enti-
dade transversais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Figura 12 – O modelo de interoperabilidade do GWAC e sua relação com o SGAM 57Figura 13 – Modelo do framework do SGAM . . . . . . . . . . . . . . . . . . . . 58Figura 14 – Modelo conceitual desta pesquisa segundo o Design Science . . . . 60Figura 15 – Modelo da proposta de trabalho a ser desenvolvido neste trabalho . 62Figura 16 – Processo de harmonização para elaboração do modelo domiddleware 65Figura 17 – Análise das relações entre as visões arquiteturais do RM-ODP e as
partes dos modelos de referência . . . . . . . . . . . . . . . . . . . . 67Figura 18 – Resultado da homogeneização dos modelos do grupo de domínio . 71Figura 19 – Resultado da homogeneização dos modelos do grupo de funcional . 72Figura 20 – Resultado da homogeneização dos modelos do grupo de informação 73Figura 21 – Resultado da harmonização dos modelos do grupo de domínio . . . 76Figura 22 – Resultado da harmonização dos modelos do grupo funcional . . . . 77Figura 23 – Resultado da harmonização dos modelos do grupo de informação . 79Figura 24 – Classificação dos métodos de pesquisa . . . . . . . . . . . . . . . . 81Figura 25 – Processo de design do tratamento para elaboração da arquitetura do
middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Figura 26 – Visão empresa do sistema de gestão de eficiência energética . . . . 85Figura 27 – Visão informação do sistema de gestão de eficiência energética . . 86Figura 28 – Visão computação do sistema de gestão de eficiência energética . . 87Figura 29 – Visão empresa baseada no modelo de interoperabilidade de negócios 88Figura 30 – Comunidade provedor de gestão de eficiência energética baseada
no modelo de interoperabilidade de negócios . . . . . . . . . . . . . 89Figura 31 – Especificação informação baseada no modelo de interoperabilidade
de negócios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Figura 32 – Schema de ações baseada no modelo de interoperabilidade de ne-
gócios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Figura 33 – Visão geral do schema de informação baseada no modelo de intero-
perabilidade de negócios . . . . . . . . . . . . . . . . . . . . . . . . 92Figura 34 – Schema de informação do módulo operacional baseada no modelo
de interoperabilidade de negócios . . . . . . . . . . . . . . . . . . . 93Figura 35 – Schema de informação do módulo gerenciamento baseada no mo-
delo de interoperabilidade de negócios . . . . . . . . . . . . . . . . . 94
Figura 36 – visão geral da visão computação do middleware . . . . . . . . . . . 95Figura 37 – Resultado da comparação na homogeneização dosmodelos do grupo
de dominio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108Figura 38 – Resultado da comparação na homogeneização dosmodelos do grupo
funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Figura 39 – Resultado da comparação na homogeneização dosmodelos do grupo
de informacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
LISTA DE TABELAS
Tabela 1 – Matriz de critérios de homogeneização . . . . . . . . . . . . . . . . 69
LISTA DE ABREVIATURAS E SIGLAS
IEC International Electrotechnical CommissionCEN European Committee for StandardizationCENELEC European Committee for Eletrotecnichal StandardizationETSI European Telecommunication Standard InstituteNIST National Institute of Standards and TechnologyIEEE Institute of Electrical and Electronics Engineers
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.1 Considerações iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . 211.2 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231.3 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241.4 Abrangência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251.5 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261.6 Organização do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . 29
2 INTERNET DAS COISAS E O CONTEXTO DA GESTÃO DE EFICI-ÊNCIA ENERGÉTICA . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.1 Internet das coisas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.1.1 Áreas de aplicação de IoT . . . . . . . . . . . . . . . . . . . . . . . . 362.1.2 Redes elétricas inteligentes . . . . . . . . . . . . . . . . . . . . . . . 372.2 Middleware no contexto de IoT . . . . . . . . . . . . . . . . . . . . . 382.3 Modelo Arquitetural de Referência (ARM) para Internet das Coisas . 402.3.1 Modelo de referência para IoT . . . . . . . . . . . . . . . . . . . . . . 402.3.1.1 Modelo de domínio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.3.1.2 Modelo de informação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.3.1.3 Modelo funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.3.1.4 Modelo de comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . 442.3.1.5 Modelo de confiança, segurança e privacidade . . . . . . . . . . . . . . . . . 442.4 Modelo arquitetural para redes elétricas inteligentes . . . . . . . . . . 462.4.0.1 Modelo conceitual do SGAM . . . . . . . . . . . . . . . . . . . . . . . . . . 472.4.0.2 Framework do SGAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3 UMMODELODE INTEROPERABILIDADEDENEGÓCIOSNAGES-TÃO DA EFICIÊNCIA ENERGÉTICA . . . . . . . . . . . . . . . . . . 59
3.1 Modelo conceitual deste trabalho . . . . . . . . . . . . . . . . . . . . 593.2 Modelo conceitual da solução proposta . . . . . . . . . . . . . . . . . 613.3 Especificação de um modelo para interoperabilidade de negócios na
gestão de eficiência energética . . . . . . . . . . . . . . . . . . . . . 633.3.1 O uso do ARM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.3.2 O uso do SGAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.3.3 O uso de Razzaque et al. (2016) . . . . . . . . . . . . . . . . . . . . 643.3.4 O uso de Andrén et al. (2017) . . . . . . . . . . . . . . . . . . . . . . 643.4 O processo de especificação do modelo de interoperabilidade de ne-
gócio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653.4.1 Análise dos modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . 663.4.2 Harmonização dos modelos de referência . . . . . . . . . . . . . . . 683.4.2.1 Homogeneização de modelos de referência . . . . . . . . . . . . . . . . . . 683.4.2.2 Comparação de modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . 743.4.2.3 Integração de modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753.4.3 Revisão dos resultados . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4 VALIDAÇÃO DO TRABALHO . . . . . . . . . . . . . . . . . . . . . . 814.1 Método de validação . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.1.1 Mecanismo de experimento de caso único . . . . . . . . . . . . . . . 824.2 O processo para especificação das visões arquiteturais . . . . . . . . 824.3 Aplicação do experimento . . . . . . . . . . . . . . . . . . . . . . . . 844.3.1 O contexto do experimento . . . . . . . . . . . . . . . . . . . . . . . . 844.3.2 As visões arquiteturais de um middleware para interoperabilidade de
negócio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5 CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . 975.1 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975.2 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
ANEXO A – COMPARAÇÃO DOS ELEMENTOS DOS MODELOS DEREFERÊNCIA . . . . . . . . . . . . . . . . . . . . . . . . . 107
21
1 INTRODUÇÃO
Neste capítulo serão apresentadas as considerações iniciais sobre a pesquisa, as-
sim como os objetivos e os trabalhos relacionados que a justificam. Também serão
apresentados a abrangência e a metodologia de pesquisa.
1.1 Considerações iniciais
A preocupação com a gestão de energia é tratada no Brasil pelo Ministério de Mi-
nas e Energia. O relatório apresentado por Tolmasquim et al. (2016) demonstra uma
preocupação com o crescimento da demanda energética no Brasil e aponta dois prin-
cipais caminhos a serem desenvolvidos: o gerenciamento pelo lado da demanda e a
expansão da oferta.
A expansão da oferta constitui em investimentos em grandes usinas geradoras de
energia que, apesar de trazerem aumento da disponibilidade de energia, possuem
capacidade limitada. Eichinger et al. (2012) destacam três motivos pelos quais o inves-
timento em usinas geradoras de energia, cuja fonte é não renovável, não é viável: 1
- economicamente não é viável, pois os recursos são finitos; 2 - os prejuízos ao meio
ambiente são altos e; 3 - os riscos são considerados altos, principalmente em casos
de fontes nucleares. E, no que diz repeito a geradores de energia baseado em fontes
renováveis, há a necessidade de desenvolvimento tecnológico. Além disso, as constru-
ções dessas usinas levam tempo devido a questões ambientais e de engenharia. Os
autores destacam ainda que, nesses casos, é necessário um planejamento a longo
prazo.
Para o curto prazo, o investimento deve estar concentrado em projetos que promo-
vam a eficiência energética. No Brasil, tanto a iniciativa de expansão da oferta quanto
a iniciativa de gestão da demanda são consideradas. Na Figura 1, é possível observar
essas duas categorias.
A Figura 1 representa as categorias das iniciativas para o tratamento do aumento
de demanda no Brasil. Este trabalho está situado na categoria de ”Gerenciamento
pelo lado da demanda”, mais especificamente na categoria de ”Eficiência energética
autônoma”.
A eficiência energética é a capacidade de gerir, de maneira mais adequada às ne-
22
Figura 1 – Alternativas para o atendimento da crescente demanda de energia identifi-cadas pela Empresa de Pesquisas Energéticas
Fonte: (TOLMASQUIM et al., 2016)
cessidades de um contexto, a energia gerada por diversas fontes (EICHINGER et al.,
2012). Essa definição é especialmente verdade quando colocada sob o contexto das
redes elétricas inteligentes, pois, nesse contexto, a aplicação de tecnologias de infor-
mação e comunicação (ICT - Information and Communication Technologies) sob a rede
de energia atua diretamente na eficiência energética (ZHENG et al., 2012).
No Grupo de Arquitetura e Fábrica de Software (GARFSoft), pertencente ao Labo-
ratório de Tecnologia e Software (LTS) no Departamento de Computação e Sistemas
Digitais (PCS) da Escola Politécnica da Universidade de São Paulo (USP), em parceria
com uma empresa de mercado, há o desenvolvimento de uma solução inovadora para
gestão da eficiência energética voltada para consumidores de energia proprietários
de pequenos estabelecimentos, como agências bancárias e mercados. Essa solução
consiste de dois sistemas, um sistema de gestão de eficiência energética em nível
gerencial e um sistema de gestão de eficiência energética em nível operacional.
No trabalho desenvolvido no GARFSoft, foi encontrado um problema na interope-
rabilidade entre o sistema de gestão de eficiência energética em nível gerencial e o
sistema de gestão de eficiência energética em nível operacional relacionado a ma-
neira como o negócio de gestão da eficiência energética está construído. O sistema
de gestão de eficiência energética em nível gerencial tem de interoperar com diver-
23
sos sistemas de gestão de eficiência energética em nível operacional, presentes nos
estabelecimentos e com diferentes características devido ao ambiente IoT específico.
Neste trabalho, será apresentado uma proposta para tratar o problema encontrado
na interoperabilidade entre o sistema de gestão de eficiência energética em nível ge-
rencial e os sistemas de gestão de eficiência energética em nível operacional. O sis-
tema de gestão de eficiência energética em nível operacional consistem de sistemas
de automação, sistemas IoT, dentre outros, e estão presentes nos diversos locais re-
presentantes dos clientes da empresa provedora de serviço de gestão de eficiência
energética.
1.2 Objetivo
Esta pesquisa tem por objetivo especificar um modelo de interoperabilidade de ne-
gócios na gestão da eficiência energética. Esse modelo terá o foco no tratamento da
interoperabilidade de negócios, procurando abstrair as complexidades dos serviços
de negócio do sistema de gestão de eficiência em nível operacional para o sistema de
gestão da eficiência energética em nível gerencial.
Esse modelo será utilizado para a especificação de visões arquiteturais da des-
crição arquitetural de um middleware, o qual irá atuar na interoperabilidade entre o
sistema de gestão de eficiência energética em nível gerencial e o sistema de gestão
de eficiência energética em nível operacional.
Os modelos especificado por este trabalho está baseado nos modelos de referên-
cia Modelo Arquitetural de Referência para IoT (ARM - Architecture Reference Model
for IoT) (CARREZ et al., 2013), o Framework do Modelo Arquitetural para Sistemas In-
teligentes de Energia (SGAM Framework - Smart Grid Architecture Model Framework)
(CEN-CENELEC-ETSI, 2012b), o modelo funcional de Razzaque et al. (2016) e o mo-
delo de informação de Andrén et al. (2017). Esses modelos definem os elementos ne-
cessários para a especificação do modelo de interoperabilidade de negócios na gestão
de eficiência energética, porém serão harmonizados para diminuir a complexidade e
aumentar a aderência ao contexto social.
Com isso, esta pesquisa visa permitir que o sistema gerencial de gestão de efi-
ciência energética tenha um modelo para apoiar na atividade de interoperar com os
diferentes sistemas de gestão de eficiência energética em nível operacional existentes
24
no contexto social.
1.3 Justificativa
Atzori et al. (2010) definem duas tecnologias como habilitadoras do desenvolvi-
mento de sistemas baseados em IoT, as tecnologias de identificação e os middleware.
Hoje, consumidores encontram dificuldade na gestão da eficiência energética devido
a complexidade na interoperabilidade entre os diversos sistemas (SANTO et al., 2015).
Os diferentes atores e dispositivos existentes fazem com que seja necessário um mid-
dleware específico para servir de base para construção de soluções para o sistema
energético.
Santo et al. (2015) ainda destacam que faz-se necessário o desenvolvimento de
modelos de informação interoperáveis para a gestão da eficiência energética. Esses
modelos são a base para programas de controle e redução do consumo, além de per-
mitir a comunicação bidirecional entre consumidores e outros atores do sistema de
energia.
No domínio de redes elétricas inteligentes, Okuno et al. (2015) desenvolveram um
middleware para gestão de comunicação entre os operadores da rede de distribuição e
agregadores, os quais representavam um grupo de consumidores. Okuno et al. (2015)
encapsularam dois protocolos utilizados nessa comunicação, o IEC 61850 (IEC, 2016)
e o OpenADR 2.0(ALLIANCE, 2017), dentro do Extensible Messaging and Presence
Protocol (XMPP)(SAINT-ANDRE, 2017). Um fator relevante é que os autores usaram
o SGAM para modelagem do contexto do problema, pois este uso também é objetivo
deste trabalho.
Também Shamszaman et al. (2014) propõem um middleware para gestão de ener-
gia baseado em duas camadas funcionais, uma camada de sistemas e uma camada
gateway. Outros autores que construíram um middleware para gestão de eficiência
energética foram Ożadowicz e Grela (2016), esses autores propõem um middleware
para sistema de gestão de energia para gestão da demanda pelo cliente baseado em
sistemas de controle e automação orientados a eventos e orientados a tempo.
Porém, é necessário destacar que os trabalhos apresentados em Okuno et al.
(2015), Shamszaman et al. (2014) e Ożadowicz e Grela (2016) não tiveram como base
nenhum modelo arquitetural de referência, dificultando a aplicabilidade desses traba-
25
lhos fora do contexto social específico em que foram concebidos.
Bellagente et al. (2015) propõem um sistema de gestão de energia contendo um
middleware em sua estrutura. Os autores fazem ainda uma relação do sistema pro-
posto com o modelo funcional do ARM. Porém, é importante ressaltar que estabelecer
uma relação com um modelo do ARM não torna o sistema aderente ao modelo arqui-
tetural de referência, uma vez que não são utilizados elementos do ARM.
Por fim, outros trabalhos relacionados ao desenvolvimento de middleware para IoT
podem ser encontrados nos trabalhos de Silva et al. (2014) e Parlanti et al. (2010).
Porém, novamente, esses trabalhos são implementações específicas e não seguem
um modelo arquitetural de referência. Além disso, esses trabalhos não endereçam as
questões específicas de redes elétricas inteligentes.
Na análise deste trabalho de pesquisa, os trabalhos correlatos apresentados serão
beneficiados pelos modelos de interoperabilidade definidos aqui.
1.4 Abrangência
Neste trabalho de pesquisa, os modelos de referência serão a base da especifica-
ção do modelo de interoperabilidade de negócios na gestão de eficiência energética.
Porém, esses modelos são bastante abrangentes, cobrindo não somente a gestão da
eficiência energética mas também outros escopos. Devido a este fato, o contexto social
deste trabalho, constituído do trabalho de gestão de eficiência energética doGARFSoft,
será utilizado como ferramenta para limitar o escopo de trabalho.
Em (IEC, 2017) é definido ummapa de aplicações segundo o Framework do SGAM.
Nesse mapa é possível identificar o trabalho a ser desenvolvido aqui no domínio de
consumidores e nas zonas de estação e campo. Outros domínios, como os distribuido-
res de energia e os responsáveis pela transmissão, não serão tratados neste trabalho,
bem como os processos e sistemas relacionados a estes atores.
O modelo especificado neste trabalho de pesquisa tem seu foco na interoperabi-
lidade de negócios. Outros níveis de interoperabilidade serão tratado parcialmente,
como a interoperabilidade de informação, ou não serão tratados, como os demais ní-
veis de interoperabilidade. Os níveis de interoperabilidade são apresentados na revisão
bibliográfica.
Outro ponto importante de abrangência deste trabalho, diz respeito às visões arqui-
26
teturais especificadas para validar o modelo. Serão especificadas as visões arquitetu-
rais relacionadas ao modelo especificado por este trabalho, pois tem a finalidade de
evidenciar o uso do modelo. Outras visões arquiteturais não relacionadas diretamente
ao modelo serão tratadas em um trabalho futuro. Aqui, quando é dito que a visão está
relacionada ao modelo, significa que os elementos do modelo são utilizados na espe-
cificação da arquitetura.
1.5 Metodologia
Este trabalho aplicará o design science como método de pesquisa como definido
em (WIERINGA, 2014). O design science consiste do projeto e investigação da aplica-
ção de um artefato sob um contexto.
No design science, tem-se o contexto social como ponto de partida da pesquisa.
Uma pesquisa está fundamentada em um problema no contexto social, um problema
real. A partir deste problema do contexto social, tem-se o problema do contexto do
conhecimento, o problema científico. No problema científico encontra-se a pesquisa.
Durante toda a pesquisa, um conjunto de questões do conhecimento e problemas
de projeto foram elaborados. Essas questões de conhecimento e os problemas de
projeto estão descritos na Figura 2.
As questões de conhecimento adicionam conhecimento científico à base de conhe-
cimento, enquanto os problemas de projeto visam tratar problemas encontrados no
contexto social.
Para a construção e validação do artefato, o design science define um ciclo de
design, o qual é composto por três fases: investigação do problema, design do artefato
e validação do artefato. O processo, os atores e as atividades, os quais representam
o ciclo de design desta pesquisa, estão ilustrados na Figura 3. Também na Figura 3, é
possível verificar a correspondência com o ciclo de design.
Na listagem abaixo, estão descritas as atividades do método de pesquisa. Há uma
atividade inicial de revisão da literatura, a aplicação de ciclo de design e uma atividade
final de consolidação dos trabalhos e escrita da dissertação, ambas não constam na
Figura 3, pois não fazem parte do ciclo de design science, mas sim de etapas comple-
mentares da pesquisa.
27
Figura 2 – Problemas de design e perguntas do conhecimento referentes a este projetode pesquisa
Fonte: Elaborado pelo autor
a) Revisão da literatura do contexto de pesquisa
Levantamento da literatura sobre interoperabilidade de sistemas, internet das coi-
sas, middleware, processos de construção de arquitetura de software, dentre ou-
tros conceitos correlatos com esta dissertação.
b) Identificação dos interesses dos consumidores e provedores de serviços de ges-
tão de eficiência energética e da relação desses interesses
Identificação das necessidades dos consumidores-produtores para gestão da efi-
ciência de energia, das políticas ligadas a gestão de eficiência energética, objeti-
vos e escopo da gestão de eficiência energética para esses atores. Serão realiza-
das análises do contexto onde esses atores estão inseridos para detalhamento
de suas reais necessidades.
c) Levantamento das causas do problema de interoperabilidade no contexto dos
28
Figura 3 – Processo de pesquisa utilizado nesta pesquisa
Fonte: Elaborado pelo autor
stakeholders
Nesta atividade, serão analisados a interoperabilidade entre os sistemas de ges-
tão de eficiência energética existente no contexto social desta pesquisa.
d) Especificação do modelo de interoperabilidade de negócio na gestão de eficiên-
cia energética
Especificação do modelo de interoperabilidade de negócios na gestão de efici-
ência energética deste trabalho de pesquisa. Nesta atividade, será realizada a
harmonização dos modelos utilizados na pesquisa para elaboração do modelo.
e) Especificação de visões arquiteturais da descrição arquitetural de ummiddleware
para sistemas de gestão de eficiência energética em IoT
Nesta atividade, serão especificadas as visões arquiteturais relacionadas ao mo-
delos de interoperabilidade de negócios para a validação da aplicabilidade do
modelo. Serão especificadas um conjunto de visões arquiteturais do Modelo de
Referência para Sistemas Abertos e Distribuídos (do inglês - Reference Model -
Open Distributed Systems) (ISO/IEC, 2009).
f) Consolidação do trabalho e escrita da dissertação
29
Consolidação dos resultados finais do trabalho e escrita da dissertação.
1.6 Organização do trabalho
No capítulo 2 é apresentado o conhecimento científico que forma a base deste tra-
balho. Dentro do conhecimento científico desta pesquisa serão apresentados a arqui-
teturas para a IoT e o contexto da eficiência energética. Também serão discutidos os
diferentes tipos de middleware no contexto de IoT, o modelo arquitetural de referência
para IoT e a aplicabilidade de IoT na gestão de energia. No capítulo 3 será apresen-
tado o modelo de interoperabilidade de negócios para gestão de eficiência energética.
Será apresentado o modelo conceitual desta pesquisa segundo o Design Science, o
modelo da solução proposta. No capítulo 4, será apresentado a especificação de vi-
sões arquiteturais baseadas no modelo de interoperabilidade de negócios para gestão
de eficiência energética. Por fim, no capítulo 5, serão apresentados os resultados e as
conclusões.
31
2 INTERNET DAS COISAS E O CONTEXTO DA GESTÃO DE EFICIÊNCIA ENER-
GÉTICA
Neste capítulo serão apresentados os conceitos base desta pesquisa, bem como os
estudos relacionados. Primeiramente, será apresentado a definição de IoT. Após isso,
será apresentado o ARM, suas características e aplicações. Por fim, será apresentado
o estado dos trabalhos em gestão de energia relacionado a IoT, dando um foco especial
na gestão da eficiência energética.
2.1 Internet das coisas
O termo IoT foi apresentado pela primeira vez por Ashton (2009) numa apresenta-
ção sobre RFID na P&G em 1999. Ashton (2009) destaca o fato de que, até aquele
momento, a internet ainda era dependente de humanos, principalmente com relação
a entrada de dados, e poucos objetos, como sensores, atuadores e computadores, fa-
zem a entrada de dados de forma autônoma. Ashton (2009) salienta que a internet
das coisas só irá alcançar o seu completo potencial quando as coisas agirem de forma
independente e os humanos não forem mais o único eixo para o desenvolvimento da
internet.
Em 2005, um relatório da União Internacional de Telecomunicações (ITU - Interna-
tional Telecommunication Union) definiu a internet das coisas como ”a presença de
qualquer dispositivo conectados à internet em qualquer lugar e a qualquer hora”(ITU,
2005). Porém essa definição ainda é muito genérica.
Com o desenvolvimento da internet das coisas, uma definição mais precisa fez-se
necessário. Atzori et al. (2010) apresentou a Internet das Coisas como a presença
de maneira pervasiva de dispositivos e coisas nas atividades de nosso cotidiano com
o objetivo de cumprir um propósito. Os autores fazem uma distinção de internet das
coisas segundo três visões. Essa distinção vem do fato de a própria palavra Internet
das Coisas possuir duas palavras fortes e difíceis de definir precisamente - Internet e
Coisas - e que juntas trazem um novo significado, formam uma nova palavra. As três
visões são descritas como:
a) Visão orientada a internet
Visão sobre a internet das coisas pela qual prevalece a composição dos proto-
32
colos e a evolução da web para a internet das coisas, também é chamada por
alguns autores de Web das coisas - do inglêsWeb of Things.
b) visão orientada a coisas
Parte da internet das coisas focada no desenvolvimento de novos dispositivos,
controladores, atuadores, sensores, entre outros. É onde ocorre o desenvolvi-
mento da camada físicas da internet das coisas.
c) Visão orientada a semântica
A união das visões orientadas a internet e orientada a coisas faz com que se
crie uma outra visão, chamada visão semântica. Esta visão disponibiliza para os
usuários maneiras de desenvolver soluções e utilizar a internet das coisas. Esta
visão compreende plataformas de análise de dados,middleware, arcabouços tec-
nológicos, arquiteturas, entre outros elementos.
Essas três visões estão representadas da Figura 4.
Figura 4 – Visões sobre IoT por Atzori et al. (2010)
Fonte: (ATZORI et al., 2010)
Versmesan e Friess (2015) destacam que muitos tratam IoT como uma nova inter-
net, outros como uma evolução da internet e definem IoT como uma infra estrutura de
rede dinâmica global com capacidade de auto configuração baseada em protocolos
de comunicação padronizados e interoperáveis na qual coisas físicas e virtuais tem
33
identidades, atributos físicos e personalidade virtual, usam de interfaces inteligentes,
e estão integradas na rede global de informação.
IEEE-SA (2015) define que IoT refere-se a qualquer sistema interconectando pes-
soas, objetos físicos, e plataformas de tecnologia da informação, assim como qualquer
tecnologia para melhor construir, operar e gerenciar o mundo físico através de coleta
de dados de modo pervasivo, rede inteligente, análise preditiva e otimização.
Porém, essas definições são ainda bastante abrangentes. E o relatório ressalta
que a definição de IoT deve ser aplicada a um contexto, como energia, transporte,
etc. Dessa forma, recebe um nome mais adequado, como redes elétricas inteligentes,
do inglês smart energy, transportes inteligentes, do inglês smart transportation, casas
inteligentes, do inglês smart home e acaba adotando características mais detalhadas
e precisas.
Razzaque et al. (2016) trazem uma visão sobre IoT mais precisa para a óptica de
um middleware. Os autores destacam as características da IoT e suas implicações
sobre a construção de um middleware, apresentando estas características sob duas
perspectivas. Essas perspectivas são denominadas características de infraestrutura de
IoT e características de aplicação de IoT. Os detalhes da perspectiva de infraestrutura
estão descritas a seguir:
a) Dispositivos heterogêneos
Os dispositivos dentro do contexto de IoT possuem uma variedade tanto de hard-
ware quanto de funcionalidade. Além disso, dispositivos com similaridades fun-
cionais possuem fornecedores diferentes e, algumas vezes, adotam padrões es-
pecíficos desses fornecedores.
b) Recursos limitados
Os dispositivos possuemdiversas restrições de capacidades, comomemória, pro-
cessamento e armazenamento. Também é uma preocupação constante das so-
luções de IoT a capacidade energética dos dispositivos.
c) Interação espontânea
As soluções de IoT possuem um alto grau de pervasividade e buscam pela inte-
ração com seus usuários em seus diferentes domínios. Essa pervasividade faz
34
com que seja difícil prever quando os eventos irão ocorrer, as interações dos
usuários com os sistemas IoT são espontâneas.
d) Rede de alta escala e grande número de eventos
O Gartner publicou um relatório com a previsão de existirem aproximadamente
vinte e seis bilhões de dispositivos em soluções IoT até o ano de 2020 (RIVERA;
MEULEN, 2013). Essa grande quantidade de dispositivos irá gerar uma grande
quantidade de eventos e exigirá redes com um alto grau de escalabilidade.
e) Redes oportunistas e ausência de infraestrutura
Diversos dispositivos de IoT possuem conectividade sem fio e tem a caracterís-
tica de mobilidade. Isso faz com que redes espontâneas possam ser criadas de
acordo com o contexto de cada solução.
f) Aplicação contextual
Como dito nas características anteriores, a grande quantidade de dados e a
grande quantidade de eventos irão proporcionar a capacidade das soluções de
IoT se adaptarem ao contexto em que estão inseridas.
g) Inteligência
A rede de sensores e atuadores, em conjunto com aplicações e middleware irão
permitir que objetos atuem de modo autônomo dentro da rede. Essa inteligência
será uma característica que permitirá as aplicações a adaptação necessária aos
usuários.
h) Localização
A característica de localização das soluções IoT diz repeito ao modo como os
objetos irão se comportar de acordo com a posição geográfica, além da posição
relativa a outros objetos.
i) Distribuída
A distribuição é uma característica inerente das soluções de IoT. Essas aplica-
ções, dispositivos e até mesmo os usuários estarão distribuídos geograficamente
de maneira global e local.
35
As características de aplicações de IoT diz respeito a características das aplicações
que estarão em contato com os usuários. Essas características estão descritas abaixo:
a) Aplicações diversas
As áreas de aplicações das soluções de IoT são as mais diversas, pois os sen-
sores, atuadores e as aplicações construídas estão aplicadas nos mais diversos
domínios.
b) Tempo real
As soluções de IoT estarão atuando no borda, em contato com os usuários. Isso
faz com que diversos casos de uso de tempo real sejam característicos dessas
soluções.
c) Tudo como serviço (XaaS - Everything-as-a-service)
A característica de tudo como serviço das soluções IoT diz respeito ao modo
como todas as aplicações e dispositivos serão expostos como serviço e, pos-
sivelmente, estarão abertos para consumo de outros usuários. Nessa caracte-
rística, as restrições de segurança e privacidade são aplicadas em cada caso,
obviamente.
d) Aumento da capilaridade do escopo de segurança
Com a implantação de soluções IoT, o número de alvos de ataques irá crescer,
pois os diferentes dispositivos da rede poderão ser alvos de ataques.
e) Privacidade
A coleta de dados dos usuários através de sensores irá gerar um conjunto de
informações que são pessoais e não podem entrar em domínio público. A preo-
cupação com quais dados poderão ser coletados, processados e armazenados
será uma característica de todas as soluções de IoT.
Por fim, neste trabalho, caracteriza-se por soluções de IoT como a aplicação de
ICT, como sensores, atuadores, middleware específicos, dispositivos com restrições
de capacidades e pervasivos, entre outras tecnologias, na construção de sistemas
que visam cooperar de modo autônomo para atender a uma necessidade dos usuários
dentro de uma área de aplicação.
36
2.1.1 Áreas de aplicação de IoT
Pela natureza heterogênea característica de sistemas IoT, há diversas áreas onde
hoje esses sistemas são aplicados e novas áreas são desenvolvidas continuamente
com o avanço tecnológico.
Li et al. (2015) destacam que soluções IoT estão presentes nas mais diversas áreas
de nosso dia-a-dia. Esses autores citam, principalmente, o setor industrial, o social, a
saúde, a infraestrutura e a segurança. Porém também ressaltam a importância da IoT
para a cadeia de suprimentos, a logística, o turismo e a área de serviços à população.
Vermesan e Friess (2016) vão mais a fundo e apresentam uma categorização de
cada aplicação de IoT. Essas definições são apresentadas a seguir e, ao final, a área
de redes elétricas inteligentes é apresentada em detalhes.
a) Tecnologia vestíveis
As tecnologias vestíveis são a implementação de IoT nos artefatos presentes nas
rotinas das pessoas. São sensores, monitores e pequenos dispositivos implanta-
dos dentro dos equipamentos cotidianos. Esses equipamentos são carregados
com as pessoas nos seus dia-a-dia. Fazem parte desta categoria artefatos como,
relógios inteligentes, pulseiras inteligentes, roupas inteligentes, entre outros.
b) Saúde inteligente
As soluções IoT tem sido aplicadas na área da saúde através da implantação de
sensores, atuadores, monitores ou dispositivos de coleta de dados nos aparelhos
domésticos ou em aparelhos específicos. Essas soluções tem a finalidade de,
principalmente, prover dados de modo mais assertivo para os profissionais da
saúde e prevenir situações de emergência.
Essas soluções possibilitam a população um atendimento mais detalhado por
parte dos profissionais da saúde. Importante ressaltar que nessa área, questões
ligadas a privacidade ainda são bastante discutidas.
c) Casas e prédios inteligentes
A aplicação de IoT em casas e prédios tem sido fomentada pela necessidade
de gerenciar de modo mais eficiente os recursos desses estabelecimentos, pro-
porcionar maior qualidade de vida para as pessoas que frequentam esses locais
37
e permitir uma gestão mais eficiente do ciclo de manutenção desses estabeleci-
mentos.
Além disso, questões de segurança são aprimoradas através dos diversos senso-
res e atuadores presentes nas soluções de IoT. Os autores destacam como um
dos principais desafios deste campo de aplicação, a construção de arquiteturas
e plataformas de desenvolvimento de soluções para IoT.
Aqui, vale ressaltar, os autores fazem uma relação com a gestão de energia den-
tro dos estabelecimentos e as redes elétricas inteligentes.
d) Transportes inteligentes
Essa área de aplicação consiste na implantação de soluções de IoT na mobili-
dade das pessoas em seus dia-a-dia. Desde a aplicação de dispositivos inteli-
gentes para controle de sinais de trânsito até a automóveis autônomos, soluções
IoT tem sido implantadas com a finalidade de permitir maior mobilidade as pes-
soas de modo mais seguro e conveniente.
e) IoT industrial
A aplicação de IoT na indústria permite a otimização do processo de produção
através da implantação de sensores, atuadores e dispositivos em suas diversas
etapas. Além disso, através da análise dos dados coletados dos objetos produzi-
dos e do processo como um todo, é possível encontrar pontos de melhoria. Um
dos maiores desafios apresentado pelos autores é a integração dessas tecnolo-
gias, devido ao fato de as diferentes indústrias terem diferentes contextos.
f) Cidades inteligentes
Os autores definem cidades inteligentes como as cidades que monitoram e inte-
gram sua infraestrutura, planejam de modo otimizado a utilização de seus recur-
sos, previnem ações de manutenção, cuidam de aspectos da segurança pública
e aumentam os serviços a população, através de soluções IoT.
2.1.2 Redes elétricas inteligentes
As redes elétricas inteligentes consistem na aplicação de soluções IoT por toda
a cadeia de rede de energia, desde a geração até o consumidor final, melhorando a
38
capacidade de automação, controle, monitoração, prevenção a falhas e adaptação por
parte desses sistemas de energia (VERMESAN; FRIESS, 2016).
Santo et al. (2015) também trazem uma definição similar para as redes elétricas
inteligentes. Os autores tratam das redes como a implantação de tecnologias de infor-
mação e comunicação na geração, na transmissão, na distribuição e no consumo de
energia. Além disso, ressaltam quer as redes elétricas inteligentes trazem benefícios
como melhoria da eficiência da rede, facilidade de operação, acomodação a fontes
renováveis, entre outros.
Também são destacadas as barreiras que hoje desafiam o desenvolvimento de re-
des elétricas inteligentes, como o alto custo, a falta de engajamento dos atores envol-
vidos, questões envolvendo segurança e privacidade e o desenvolvimento tecnológico.
Dentro das redes elétricas inteligentes, há ainda o conceito de micro redes.
As micro redes de energia são um sistemas de energia integrados contendo gera-
ção distribuída, armazenamento distribuído e sistemas de operação atuando com uma
unidade autônoma, conectada ou não, do grande sistema de energia. Quando a ener-
gia demandada não pode ser suprida pela micro rede, a energia extra necessária é
buscada na rede principal, também chamada de rede central (MAHIEUX; OUDALOV,
2016).
As micro redes trazem uma série de vantagens, como confiabilidade na entrega de
energia, eficiência por ter perdas menores devido a maior proximidade, sustentabili-
dade por permitir a penetração das energias renováveis, escalabilidade e redução dos
investimentos por parte de governos. (GREGORATTI; MATAMOROS, 2015).
Quando a micro rede de energia atua de modo autônomo e auto suficiente, esta
rede é dita em estado de ilhamento. O ilhamento consiste no caso de uma micro rede
perder conexão com a rede principal devido a algum incidente ou interrupção. Ter uma
micro rede ilhada faz com que os elementos dessa micro rede tenham de gerar a sua
própria energia, através da geração distribuída para o abastecimento local.
2.2 Middleware no contexto de IoT
O conceito demiddleware é anterior ao conceito de IoT. A construção demiddleware
como forma de acelerar e facilitar o desenvolvimento de aplicações já é estudado há
vários anos.
39
Para Emmerich (2000), um middleware visa prover aos engenheiros de aplicação
com primitivas de alto nível para simplificar a construção de sistemas distribuídos. Em-
merich (2000) também definiu os requisitos relacionados a ummiddleware como, requi-
sitos de comunicação de rede, requisitos de coordenação, requisitos de confiabilidade,
requisitos de escalabilidade e requisitos relacionados a heterogeneidade. Esses requi-
sitos endereçam pontos nos quais as aplicações não devem dedicar esforços, pois são
transversais e sua implementação tornaria o desenvolvimento muito custoso.
Os requisitos de comunicação de rede estão ligados a capacidade de uma aplica-
ção enviar mensagens para outras aplicações, sem se preocupar com a distribuição
dessas aplicações. A aplicação não deve ser responsável pela implementação dos pro-
tocolos de rede, pois estes podem variar de acordo com a arquitetura de rede em que
a aplicação se encontra. Os requisitos de coordenação permitem a abstração do sin-
cronismo entre troca de mensagens, podendo esta troca ser síncrona ou assíncrona,
além de gerenciar mecanismos de ativação e desativação de componentes. Os re-
quisitos de confiabilidade tratam da garantia de entrega das mensagens através de
mecanismos de comunicação, tempo máximo, transações e replicação de mensagens.
Os requisitos de escalabilidade tratam da capacidade de atender ao crescimento do
uso da aplicação. A aplicação não terá a capacidade de escalar através da adição de
novas instâncias se tiver de lidar com as complexidades da rede. Por fim, o requisito de
heterogeneidade endereça a característica natural dos sistemas distribuídos, que é a
existência de diferentes plataformas de hardware, diferentes sistemas operacionais e
até mesmo diferenças de linguagens. Todas essas complexidades devem ser tratadas
pelo middleware.
Al-Jaroodi et al. (2003) destacam ainda que além de reduzir a complexidade da
infraestrutura, ummiddleware também deve ser responsável também por facilitar o de-
senvolvimento de aplicações e reduzir a manutenibilidade da aplicação. Al-Jaroodi et
al. (2003) também apontam que a existência de um middleware traz algumas desvan-
tagens relacionadas ao uso desse middleware pelas aplicações. Dentre as principais
desvantagens, destacou a oneração da performance e um aumento do tempo de res-
posta da aplicação como um todo.
Ambos os trabalhos de Emmerich (2000) e Al-Jaroodi et al. (2003) definem o mid-
dleware fora do contexto de IoT. Issarny et al. (2007) apresenta os desafios de um
middleware dentro do contexto de IoT, destacando a necessidade de um middleware
40
atender aos requisitos de mobilidade, contextualização, adaptação, restrição de ener-
gia, privacidade e confiabilidade. Essa visão traz o middleware para o contexto mais
específico da IoT.
Bandyopadhyay et al. (2011) ainda vão além e definem os componentes funcionais
de um middleware para IoT. Os autores destacam um estudo das características de
um middleware no contexto de IoT e extraem dessa análise os componentes funcio-
nais. Os componentes funcionais são denominados componente de interoperabilidade,
componente de detecção de contexto, componente de gerenciamento e descobrimento
de dispositivos, componente de privacidade e segurança e componente de gestão de
dados.
Tanto Issarny et al. (2007) quanto Bandyopadhyay et al. (2011) trazem omiddleware
para o contexto de IoT. Porém, Razzaque et al. (2016) apresentaram um estudo mais
detalhado sobre os requisitos e as características nas quais omiddleware está inserido.
No contexto deste trabalho, middleware é o elemento da arquitetura computacio-
nal responsável por abstrair a complexidade de uma camada. Este middleware tem
como objetivo prover primitivas para que os atores utilizem de suas capacidades sem
o conhecimento dos detalhes das camadas inferiores.
2.3 Modelo Arquitetural de Referência (ARM) para Internet das Coisas
Com o objetivo de buscar a interoperabilidade entre as diversas iniciativas em torno
da internet das coisas e definir uma base comum para pesquisa, o projeto Internet of
Things - Architecture (IoT-A) foi criado como parte do programa de pesquisa chamado
Seventh Framework Programme for Research and Technological Development (FP7)
(FP7, 2016). O IoT-A definiu, como resultado de seu trabalho, um Modelo Arquitetural
de Referência para Internet das Coisas (ARM - Architecture Reference Model for Inter-
net of Things) composto pelo modelo de referência para IoT, a arquitetura de referência
para IoT e guias de implementação.
2.3.1 Modelo de referência para IoT
O modelo de referência estabelece os conceitos fundamentais para a internet da
coisas.O objetivo desse modelo de referência é estabelecer um entendimento comum
41
e uma linguagem comum para sistemas e arquiteturas baseadas em IoT.
O modelo de referência para IoT é um conjunto de modelos que servem de base
para a construção de arquiteturas para soluções no contexto da IoT. Esses modelos
dão suporte a construção das visões arquiteturais e perspectivas presentes no ARM.
A figura 5 apresenta os submodelos constituintes do modelo de referência para IoT.
Figura 5 – Modelo de referência para internet das coisas
Fonte: (CARREZ et al., 2013)
O submodelo base é o Modelo de Domínio, o qual descreve todos os conceitos
relevantes de uma solução de IoT. Este submodelo atua como base para todos os
outros submodelos. Enquanto modelos como o de Comunicação e do de Segurança,
Privacidade e Confiabilidade podem ser mais ou menos relevantes dado um contexto,
o modelo de domínio é mandatório para quaisquer soluções e cenários envolvendo
sistemas baseados no ARM.
2.3.1.1 Modelo de domínio
A base do modelo de referência para IoT é o submodelo de domínio, o qual define
os principais conceitos relacionados a arquitetura e a sistemas de IoT, tais como, dis-
positivos, entidades virtuais, entre outros. Nele também são definidos os elementos de
um sistema IoT ou de uma arquitetura IoT, suas propriedade e seus relacionamentos.
O modelo de domínio é apresentado na Figura 6.
42
Figura 6 – Modelo de domínio definido no ARM
Fonte: (CARREZ et al., 2013)
2.3.1.2 Modelo de informação
O submodelo de informação do modelo de referência está baseado no modelo de
domínio e representa a estrutura (elementos e suas relações) da informação de um
sistema IoT em um nível conceitual, agnóstico de qualquer tecnologia. O submodelo de
informação usa o termo informação segundo como definido por Rowley (2007) o qual
define dados como como valores puros, sem relevância se vistos sozinhos e define
informação como dados adicionados de contexto e razão de ser.
O submodelo de informação é um meta-modelo que fornece a estrutura para a
informação sendo manipulada dentro de um sistema IoT e está ilustrado na Figura 7.
43
Figura 7 – Modelo de informação definido no ARM
Fonte: (CARREZ et al., 2013)
2.3.1.3 Modelo funcional
O submodelo funcional é um arcabouço abstrato para o entendimento dos principais
grupos funcionais e suas interações. Este arcabouço define a semântica comum das
funcionalidade de um sistema IoT e será utilizado como base para construção da visão
funcional do IoT-A.
O submodelo de funcional identifica grupos funcionais baseados no submodelo de
domínio e no submodelo de informação. Este modelo descreve como gerenciar os
elementos do modelo de domínio, tais como entidades virtuais e serviços, e como
gerenciar as informações presentes em sistemas de IoT baseada nos elementos do
submodelo de informação.
Dois grupos funcionais especiais presentes no submodelo funcional são o grupo
funcional de comunicação e o grupo funcional de segurança. Devido à importância
destes dois grupos funcionais, foi feito um destaque destes dois grupos para submo-
delos específicos.
44
Figura 8 – Modelo de funcional definido no ARM
Fonte: (CARREZ et al., 2013)
2.3.1.4 Modelo de comunicação
O submodelo de Comunicação é usado como guia para o grupo funcional de co-
municação e define os principais paradigmas de comunicação para a conectividade
dos elementos. O submodelo de comunicação é baseado no modelo ISO/OSI (ZIM-
MERMANN, 1980) e o estende e aprimora para o contexto de restrição de recursos
característico de sistemas IoT. Também são tratados os mecanismo de canais de co-
municação, como gateways, redes restritivas, redes oportunistas.
2.3.1.5 Modelo de confiança, segurança e privacidade
Diversos dados são trafegados em sistemas IoT, os usuários tem de ter confiança
na integridade e confidencialidade dessas informações. Um submodelo de confiança
em nível de aplicação que prove integridade e confidencialidade de informações é
fornecido pelo ARM e composto pelos seguintes aspectos:
a) Domínios de Modelos de Confiança - como há um vasto e diverso conjunto de
aplicações, a modelagem dos domínios para tratamento da confiança faz-se ne-
45
cessário;
b) Mecanismo de avaliação - mecanismo que permitam testar a confiabilidade do
sistema;
c) Políticas comportamentais - através do uso de políticas, um sistema ou sensor
pode decidir não trocar informações com outro que possui políticas de confiabili-
dade menos restritivas;
d) Âncora de confiança - é o modelo e confiança em si, aplicado à rede ou ao um
gateway;
e) Federação de confiabilidade - consiste nas regras de confiabilidade entre siste-
mas com diferentes modelos de confiabilidade;
f) Suporte aMachine-to-Machine - Prove o suporte a mecanismos de confiabilidade
na comunicação entre dispositivos.
O submodelo de segurança no ARM é composto de três camada: Segurança de
Serviços, Segurança de Comunicação e Segurança de Aplicação. A segurança no ní-
vel de comunicação define perfis para agrupar características comuns entre diversos
tipos de comunicação, não é definido nenhum perfil específico, somente que o uso de
perfis deve ser feito para que a segurança de comunicação seja tratada. Também a
rede é dividida em rede com restrição de recursos e rede sem restrição de recursos.
Entre essas duas redes, um gateway é o responsável por incrementar e implementar
mecanismos de segurança.
A privacidade é necessária devido ao fato de que dados pessoais dos usuários
irão trafegar pelas soluções IoT. O ARM define que o submodelo de privacidade deve
garantir as seguintes propriedades:
a) Deve ser possível escolher, ou não, compartilhar informações com outras entida-
des;
b) Deve ser possível controlar todos os mecanismos ligados a privacidade;
c) Deve ser possível ter o controle sobre o propósito do uso das informações;
d) Deve ser possível saber quando a informação foi utilizada e por quem;
46
e) Durante uma interação entre um usuário e um sistema IoT, somente a informação
estritamente necessária deve ser trocada entre ambos;
f) Não deve ser possível inferir informações sobre entidades;
g) Informações utilizadas para um determinado propósito não devem ser utilizadas
para outro propósito.
Para suportar as características descritas acima, o submodelo de privacidade é
composto por dois componentes funcionais: o componente de autenticação e o com-
ponente de confiabilidade e reputação.
2.4 Modelo arquitetural para redes elétricas inteligentes
Devido as mudanças ocorridas nos sistemas de energia ao longo dos últimos anos,
uma série de características tem alterado a maneira como os sistema de energia ope-
ram. Dentre essas características, destacam-se a descentralização da geração de
energia, a participação mais ativa por parte dos consumidores, a inserção de novos
atores e a inclusão de tecnologias de informação e comunicação.
A geração de energia de modo distribuído tem alterado o modelo de mercado, per-
mitindo que pequenos produtores comercializem energia (PARAG; SOVACOOL, 2016)
e que regiões inteiras se desassociem da rede central de energia, fenômeno este co-
nhecido como ”ilhamento”(MAHIEUX; OUDALOV, 2016). A participação mais ativa do
consumidor permite que, através de tecnologias de informação e comunicação, os con-
sumidores alterem seu modo de consumo e até alterem os provedores de energia
(GREGORATTI; MATAMOROS, 2015). Os novos atores tem permitido empresas pres-
tadoras de serviços ofertem novos produtos e serviços para os clientes (BLUMSACK;
FERNANDEZ, 2012). Por fim, a introdução de novas tecnologias de informação e co-
municação tem possibilitado novas capacidades por diferentes atores do sistema de
energia, como gestão de energia, mecanismos de controle de demanda, mecanismos
de resposta ativa a demandas, entre outros (TUBALLA; ABUNDO, 2016).
O Modelo Arquitetural para Redes Inteligentes de Energia (SGAM - Smart Grid
Architectural Model) (CEN-CENELEC-ETSI, 2012b) é o resultado de um grupo de tra-
balho para o Mandato M/490 (CEN-CENELEC-ETSI, 2017), o qual estabelece um mo-
delo voltado para as redes elétricas inteligentes com o foco no atendimento das novas
47
características dos sistemas de energia. Dessa forma, o modelo visa dar suporte ao
desenvolvimento de novas tecnologias e padrões e atender as necessidades de evo-
luções, interoperabilidade e gestão do sistema de energia.
O SGAM foi elaborado e desenvolvido pelo Comitê Europeu de Padronização (CEN
- European Committee for Standardization) (CEN, 2017), pelo Comitê Europeu para Pa-
dronização Eletrotécnica (CENELEC - European Committee for Eletrotecnichal Stan-
dardization) (CENELEC, 2017) e pelo Instituto de Padronização Europeu para Tele-
comunicações (ETSI - European Telecommunication Standard Institute) (ETSI, 2017).
O CEN é um órgão de padronização europeu com 34 países associados e produz
padrões nos mais diversos setores, como químico, segurança, energia, saúde, entre
outros. O CENELEC é o órgão europeu responsável pela padronização no campo da
engenharia eletrotécnica e tem o foco na padronização do mercado de energia como
forma de acelerar a inovação. O ETSI é um órgão de padronização europeu para teleco-
municações focado em tecnologia de telefonia móvel, fixa e tecnologia de informação
e comunicação.
O SGAM pode ser utilizado como um modelo para facilitar a contextualização e
posicionamento de projetos de pesquisa e projetos de padronização ligados a redes
elétricas inteligentes, permitir a análise de novos casos de uso e novos domínios, per-
mitir uma avaliação das necessidades de evoluções dos sistemas de energia.
O SGAM é composto de dois principais elementos, o modelo conceitual e o fra-
mework de interoperabilidade.
2.4.0.1 Modelo conceitual do SGAM
Omodelo conceitual definido pelo SGAM define sete principais domínios, o fluxo de
informação e integrações entre esses domínios. Esse modelo conceitual está baseado
no modelo do Instituto Nacional de Padrões e Tecnologia (NIST - National Institute
of Standards and Technology) (NIST, 2017). O Modelo conceitual é apresentado na
Figura 9. Vale ressaltar que, o modelo conceitual do SGAM adiciona um domínio ao
modelo conceitual do NIST, o domínio de Recursos de Energia Distribuídos (DER -
Distributed Energy Resources).
48
Figura 9 – Modelo conceitual do SGAM
Fonte: (CEN-CENELEC-ETSI, 2012b)
2.4.0.2 Framework do SGAM
O framework do SGAM define um conjunto de elementos que visam estabelecer
um modelo para permitir a representação da gestão da informação, a análise de dife-
rentes casos de uso dentro do sistema de energia e dar suporte a construção de novos
sistemas, garantindo a interoperabilidade entre esses sistemas. Vale ressaltar também
que, este modelo foi construído com o foco na neutralidade tecnológica, separando os
conceitos nele definidos das reais implementações. Esses elementos são: um conjunto
de cinco domínios, representando os atores dentro do fluxo de energia de uma rede
de energia; um conjunto de seis zonas, responsáveis pela representação da hierarquia
dos sistemas de gestão de energia; e, por fim, um conjunto de cinco camadas, o qual
estabelece os diferentes níveis de interoperabilidade que devem ser tratados pelos
diferentes domínios e zonas.
Os cinco domínios do SGAM definem os diferentes domínios existentes na cadeia
de conversão de energia, desde a sua geração até o consumo pelo usuário final. Es-
ses domínios são o de geração, o de transmissão, o de distribuição, o de geração
49
distribuída e o de consumo. Os cinco domínios são listados a seguir:
a) Domínio de geração
O domínio de geração de energia representa a geração de energia em grandes
quantidade e é composto pelas grandes usinas geradoras de energia, como usi-
nas termoelétricas, usinas nucleares, usinas hidroelétricas, entre outras. Usual-
mente, essas usinas estão ligadas ao domínio de transmissão.
b) Domínio de transmissão
O domínio de transmissão representa a infraestrutura e as organizações respon-
sáveis pelo transporte de energia para grandes distâncias.
c) Domínio de distribuição
O domínio de distribuição representa a infraestrutura e os organizações respon-
sáveis pelo transporte de energia para pequenas regiões. Geralmente, esse do-
mínio está conectado ao domínio de transmissão e garante a entrega de energia
para os consumidores.
d) Domínios de geração distribuída de energia
O domínio de geração distribuída de energia representa os pequenas usinas ge-
radores de energia, geralmente conectados ao domínios de distribuição. Esses
geradores incluem placas solares, pequenas turbinas eólicas, entre outros.
e) Domínio de consumo
O domínio de consumo representa os consumidores finais, os quais também po-
dem gerar energia através de painéis solares ou qualquer outra forma. Esse do-
mínio é composto por residências, pequenos estabelecimentos e indústrias.
As seis zonas do SGAM representam os diferentes níveis hierárquicos relacionado
a gestão de informação dentro do sistema de energia. As zonas definidas pelo SGAM
são a zona de processo, a zona de campo, a zona de estação, a zona de operação, a
zona corporativa e a zona de mercado.
Essas divisão leva em consideração os princípios da agregação e da separação
funcional. A agregação diz respeito a composição da informação e da composição
espacial das diferentes zonas. A separação funcional estabelece funções específicas
50
para as zonas de acordo com a afinidade e das necessidades dos usuários. As seis
zonas são listadas a seguir:
a) Zona de processo
A zona de processo inclui todos os elementos responsáveis pela conversão de
energia para o consumo direto. Todos os sensores, atuadores, transformadores,
etc, que fazem com que a energia possa ser consumida pelo usuário final.
b) Zona de campo
A zona de campo inclui todos os elementos responsáveis pelo controle, moni-
toramento e proteção da zona de processo do sistema de energia. Isso inclui
sistemas de gestão de eficiência energética, os quais são o foco desse trabalho.
c) Zona de estação
A zona de estação consiste na agregação dos sistemas de campo. Essa zona
inclui sistemas de supervisão local, sistemas de agregação de informação, sis-
temas de supervisão e aquisição de dados (SCADA - Supervisory Control and
Data Acquisition).
d) Zona de operação
A zona de operação consiste nos sistemas de operação e controle de cada domí-
nio. Esses sistemas incluem os sistemas de operação de transmissão, sistemas
de gerenciamento do distribuição, sistemas de gestão de geradores, entre outros.
e) Zona corporativa
A zona corporativa inclui os processos, serviços e infraestrutura das corporações.
Isso inclui os elementos de gestão de ativos, logística, relação com cliente, entre
outros.
f) Zona de mercado
A zona de mercado representa as operações de mercado possíveis transações
de compra e venda de energia nos diferentes domínios, desde a geração até o
mercado descentralizado de energia.
51
Como forma de representar os diversos sistemas de uma rede inteligente de ener-
gia segundo o modelo conceitual, a planície do SGAM foi elaborada e está ilustrada
na Figura 10.
Figura 10 – A planície do SGAM
Fonte: (CEN-CENELEC-ETSI, 2012b)
Na Figura 10 é possível ver os cinco domínios e suas suas relações com as zonas.
Através dessa planície, o SGAM estabelece as bases para a construção de sistemas
interoperáveis no contexto de redes elétricas inteligentes, como mencionado no início
desta seção.
A interoperabilidade é a capacidade de dois ou mais sistemas, de um mesmo for-
necedor ou de fornecedores diferentes, trocarem informações de modo que ambos
possam usar e processar essa informação (IEC, 2016). Para estabelecer como a inte-
roperabilidade é abordada na planície do SGAM, o modelo de interoperabilidade para
redes elétricas inteligentes do Conselho de Arquitetura GridWise (GWAC - GridWise
Architecture Council) (GRIDWISE, 2008) foi utilizado. O GWAC é um órgão formado
pelo departamento de energia dos Estados Unidos e diversas indústrias do setor de
energia com a finalidade de estabelecer os conceitos e os modelos necessários para
ter-se a interoperabilidade entre os diversos domínios no setor de energia.
Esse modelo é composto por três macro categorias, denominadas organização,
informação e técnica, e oito sub categorias. Essas oito sub categorias são:
a) Conectividade básica
52
A categoria de conectividade básica do modelo de interoperabilidade do GWAC
estabelece os mecanismos físicos e lógicos para a conexão entre os sistemas.
Ela garante um canal de comunicação confiável para a entrega dos pacotes de
dados entre dois sistemas, implementa os mecanismos de transmissão e recep-
ção desses pacotes, codificação de caracteres e correção de erros na entrega
dos pacotes.
Essa categoria tem relação direta com as camadas física e de enlace do mo-
delo Aberto de Interconexão de Sistemas (OSI - Open System Interconnection)
(ZIMMERMANN, 1980). Alguns padrões comuns dessa categoria são o padrão
ethernet, wifi, ponto-a-ponto, entre outros.
b) Interoperabilidade de rede
A categoria de interoperabilidade de rede do modelo de interoperabilidade do
GWAC é responsável pela comunicação entre dois sistemas através de quais-
quer redes, com garantia de entrega e gerenciamento dos erros de toda a men-
sagem e não somente do pacote. Essa categoria é responsável pela tradução
dos endereços lógicos para os endereços físicos, envio de mensagens através
de redes heterogêneas e correção de erros na entrega de mensagens.
Essa categoria corresponde às camadas de rede, transporte, sessão e, algumas
vezes, aplicação do modelo OSI. Alguns padrões de categoria são o protocolo de
transferência de arquivos (FTP - File Transfer Protocol) (POSTEL; REYNOLDS,
1985), protocolo de controle de transporte (TCP - Transport Control Protocol)
(POSTEL, 1981b), protocolo de resolução de endereço (ARP - Address Reso-
lution Protocol) (PLUMMER, 1982), protocolo de internet (IP - Internet Protocol)
(POSTEL, 1981a), entre outros.
c) Interoperabilidade sintática
A categoria de interoperabilidade sintática do modelo de interoperabilidade do
GWAC é responsável pelo entendimento da estrutura dos dados na troca de
mensagens entre dois sistemas. Nessa categoria, são definidas as estruturas
dos dados que serão trocados nas mensagens, sem preocupação com o signifi-
cado dos dados e os mecanismos padrões de trocas de mensagens, como por
exemplo, requisição / resposta ou publicação / subscrição.
53
Essa categoria corresponde à camada de apresentação do modelo OSI. Alguns
dos padrões comuns a esta categoria são a linguagem demarcação de hipertexto
(HTML - Hypertext Markup Language) (BERNERS-LEEA; CONNOLLY, 1995), lin-
guagem de marcação extensível (XML - eXtensible Markup Language) (BRAY et
al., 2008), protocolo simples de acesso a objetos (SOAP - Simple Access Object
Protocol) (GUDGIN et al., 2007), entre outros.
d) Entendimento semântico
A categoria de entendimento semântico domodelo de interoperabilidade doGWAC
está focada no entendimento do conteúdo das mensagens trocadas entre dois
sistemas. Essa categoria permite o entendimento do significado das entidades
da mensagem, permitindo o discernimento entre elementos ambíguos. Vale res-
saltar que, geralmente, essa categoria de interoperabilidade está relacionada a
um contexto específico.
Essa categoria é, geralmente, expressa através domodelo de objetos, em termos
de classes, propriedades, comportamentos e relacionamentos. É possível tam-
bém estabelecer restrições e mecanismos de asserções ou inferências. Exem-
plos desses modelos são o modelo de informação comum para energia (CIM -
Common Information Model for power) (IEC, 2005), o modelo baseado no padrão
IEC 61850 (IEC, 2016) para automação de subestação, entre outros.
e) Contexto de negócio
A categoria de contexto de negócio do modelo de interoperabilidade do GWAC
traz o contexto de negócio para omodelo de informação. Essa categoria é respon-
sável por restringir o modelo de informação com o entendimento, características
e restrições do processo de negócio sendo modelado. Nessa categoria, o mo-
delo de informação deixa de ser genérico e passa a ganhar sentido dentro de
um contexto específico, é a ponte entre os processos de negócio e o modelo de
informação.
Um exemplo é a linguagem de ontologia para web (OWL - Web Ontology Lan-
guage) (BAO et al., 2012), na qual uma linguagem estende o modelo de informa-
ção para a web.
f) Procedimentos de negócio
54
A categoria de procedimentos de negócio do modelo de interoperabilidade do
GWAC consiste nas interfaces dos processos e procedimentos de negócio entre
duas organizações. Para se obter a interoperabilidade de informação, é neces-
sário que duas organizações tenham processos e procedimentos compatíveis.
As interfaces dos processos de negócio são definidas pela categoria de objetivos
de negócios.
g) Objetivos de negócio
A categoria de objetivos de negócio do modelo de interoperabilidade do GWAC
consiste na garantia de que os níveis estratégico e tático de duas organizações
são compatíveis, permitindo assim, a interoperabilidade de modo efetivo. Essa
categoria engloba a interoperabilidade entre diversos processos e procedimentos
de negócio executados através de várias interfaces e contratos.
h) Políticas regulatórias e econômicas
A categoria de políticas regulatórias e econômicas do modelo de interoperabili-
dade do GWAC garante que diferente ambientes não sejam uma barreira para
a interoperabilidade entre diferentes organizações. Organizações de diferentes
cidades, estados ou mesmo países podem, e provavelmente irão, precisar de po-
líticas e regulamentações específicas para a execução dos objetivos de negócio.
A relação entre asmacro categorias e as categorias domodeloGWACestá ilustrada
na Figura 11.
Como é possível notar, na Figura 11, são definidos dez entidades transversais às
categorias de interoperabilidades. Essas entidades transversais podem ser aplicadas
em mais de uma categoria, mas não necessariamente em todas. A definição exata de
quais entidades transversais estão relacionadas com quais categorias não é apresen-
tada pelo GWAC e é classificada para uma análise posterior. As entidades transversais
são apresentadas em detalhe abaixo:
a) Compartilhamento de Significado de conteúdo
Para obter-se a interoperabilidade entre duas entidades, uma série de conceitos
e definições comuns devem ser compartilhadas. Essa entidade transversal cuida
55
Figura 11 – O modelo de interoperabilidade do GWAC, suas categorias e entidadetransversais
Fonte: (CEN-CENELEC-ETSI, 2012b)
para que um entendimento comum entre diferentes comunidades seja estabele-
cido.
b) Identificação de recursos
A interoperabilidade requer que os diferente elementos sejam identificáveis en-
tre os diferentes sistemas. Para tal, a entidade transversal de identificação de
recursos define um mecanismo de três etapas para a definição de identificado-
res. Deve-se ser acordar sobre o formato do identificador, deve-se ser possível
atribuir um identificador para um recurso e deve ser possível comunicar o novo
identificador para os outros elementos.
c) Sequenciamento e sincronia de tempo
O fluxo de informação trocada entre os diversos sistemas tem de manter os re-
quisitos de qualidade de serviços e sequenciamento. Para tal, todos os sistemas
devem manter uma sincronia com relação ao tempo, inclusive no formato.
d) Segurança e privacidade
As diferentes categorias de interoperabilidade devem tratar questões de segu-
rança e privacidade. Tanto na definição de políticas quanto na definição do mo-
delo de conectividade, a segurança e a privacidade devem ser tratados.
56
e) Log e auditoria
Como forma de manter o histórico da troca de informações, mecanismos de log
e auditoria devem ser implementados pelas diferentes categorias de interopera-
bilidade.
f) Gerenciamento de estado e transações
O gerenciamento do estado e gerenciamento do contexto transacional entre dois
sistemas deve ser implementado como forma de manter a consistência entre os
sistemas. Além disso, mecanismos de gestão de falhas de transações devem ser
implementados pelas diferentes categorias de interoperabilidade.
g) Preservação do sistema
Acima da integridade de um componente, a integridade do sistema como um
todo deve ser garantida. Essa entidade transversal tem o foco na garantia de
que diferentes mecanismos de resiliência serão implementados.
h) Qualidade de serviço
Os diversos serviços e as diversas transações possuem requisitos de perfor-
mance e confiabilidade, para isso, a definição dos requisitos de qualidade de
serviços nas mais diferentes categorias faz-se necessária.
i) Descobrimento e configuração
Em um contexto composto de um conjunto vasto de sistemas como o contexto
de sistemas de energia, diversos sistemas são conectados e desativados com
o tempo. Para facilitar a retirada e entrada de sistemas, mecanismos de confi-
guração e descobrimento devem ser estabelecidos nas diversas categorias de
interoperabilidade.
j) Escalabilidade e evolução de sistemas
A escalabilidade e a evolução de sistemas são entidades transversais que devem
ser tratadas na diversas categorias de interoperabilidades. O ambiente dinâmico
dos sistemas de energia faz com que novos atores apareçam e negócios exis-
tentes experimentem um aumento de carga de tempos em tempos pelas mais
diversas características.
57
O framework do SGAM utiliza o modelo de interoperabilidade do GWAC estabe-
lecendo cinco camadas de interoperabilidade. Essas camadas são chamadas de ca-
mada de negócio, camada funcional, camada de informação, camada de comunicação
e camada de componentes. A camada de negócio está relacionada com a categorias
de políticas regulatórias e econômicas e a categoria de objetivos de negócio. A camada
funcional está relacionada com a categoria de procedimentos de negócio. A camada
de informação está relacionada com a categoria de objetivos de negócio e entendi-
mento semântico. A camada de comunicação está relacionada com a categoria de
interoperabilidade sintática e com a categoria de interoperabilidade de rede. Por fim,
a camada de componentes está relacionada com a categoria de básica conectividade.
Essa relação está ilustrada na Figura 12.
Figura 12 – O modelo de interoperabilidade do GWAC e sua relação com o SGAM
Fonte: (CEN-CENELEC-ETSI, 2012b)
O SGAM, por fim, aplica as camadas de interoperabilidade na planície, definindo
assim, ummodelo para especificação da interoperabilidade entre sistemas no contexto
de redes elétricas inteligentes. Esse modelo é apresentado na Figura 13.
58
Figura 13 – Modelo do framework do SGAM
Fonte: (CEN-CENELEC-ETSI, 2012b)
59
3 UMMODELO DE INTEROPERABILIDADE DE NEGÓCIOS NA GESTÃO DA EFI-
CIÊNCIA ENERGÉTICA
Neste capítulo será apresentado o modelo conceitual desta pesquisa contendo os
principais elementos da pesquisa e suas relações. Também será apresentado o mo-
delo da solução proposta. Por fim, será apresentado o processo de harmonização de
modelos que foi utilizado para especificar o artefato desta pesquisa.
3.1 Modelo conceitual deste trabalho
Nesta seção, será apresentado o modelo conceitual desta pesquisa segundo o De-
sign Science (DS) (WIERINGA, 2014). O objetivo do modelo conceitual da pesquisa é
identificar os principais elementos da pesquisa e suas relações. A representação des-
ses elementos no modelo conceitual está centrada no artefato, resultado da pesquisa.
Inicialmente, será apresentada uma breve explicação sobre o DS e, após isso, será
apresentado e explicado o modelo conceitual e seus elementos.
O DS tem como objetivo o estudo e a aplicação de um artefato em um contexto e
é composto de três principais elementos, o contexto social, a base de conhecimento e
o próprio artefato em si. O artefato pode ser qualquer produto de pesquisa que, uma
vez aplicado no contexto social da pesquisa, altera esse contexto social produzindo
um efeito. Exemplos de artefatos são software, práticas, técnicas, processos, dentre
outros.
O contexto social contém os elementos do ambiente nos quais a pesquisa está fun-
damentada, sendo esses elementos os atores, sistemas, práticas, times, dentre outros.
No contexto social também encontram-se o problema de pesquisa e os interesses dos
stakeholders.
A interação entre o artefato e o problema de pesquisa no contexto social é chamada
de tratamento. Vale ressaltar que o resultado de um tratamento pode ser a solução
definitiva do problema, a solução parcial do problema, ou até mesmo ocasionar novos
problemas.
No DS tem-se dois tipos principais de atividades, o projeto do artefato e a investiga-
ção. As atividades de projeto visam construir o artefato da pesquisa e o tratamento. As
atividades de investigação visam procurar por referências na ciência para suporte às
atividades de projeto. Dessa forma, uma vez que o pesquisador identificou o problema
60
de pesquisa, é executada a atividade de investigação para elaborar a primeira versão
do artefato. Uma vez o artefato elaborado, aplica-se o tratamento e analisa-se os resul-
tados. Dado o resultado, novas atividades de investigação e projeto são executadas a
fim de evoluir o artefato.
A base de conhecimento contém todos os estudos e referências bibliográficas resul-
tados da atividade de investigação. Na base de conhecimento o pesquisador procura
por métodos, práticas, arquiteturas, dentre outros elementos que possam auxiliar na
elaboração do artefato.
Na Figura 14 está ilustrado o modelo conceitual desta pesquisa.
Figura 14 – Modelo conceitual desta pesquisa segundo o Design Science
Fonte: Elaborado pelo autor
O contexto social desta pesquisa é composto pelos provedores de gestão de eficiên-
cia energética e pelos consumidores-produtores inteligentes de energia. Os consumidores-
produtores inteligentes de energia consistem de pequenos estabelecimentos comerci-
ais ou prédios que utilizam de tecnologia IoT para a gestão da eficiência energética
predial. Os provedores de gestão de eficiência energética são empresas que ofere-
cem serviços de gestão de eficiência energética aos consumidores.
Há dois sistemas no contexto social deste trabalho. Um sistema oferece serviços
de gestão de eficiência energética em nível gerencial, como serviços de análise de
desempenho energético, simulação de economia de energia e aplicação de plano de
eficiência energética, dentre outros. E outro sistema o qual oferece serviços de gestão
de eficiência energética em nível operacional, como histórico de consumo, caracteri-
zação da infraestrutura, funcionamento da infraestrutura e aplicação de políticas de
61
consumo, dentre outros.
O problema de pesquisa consiste na interoperabilidade entre esses dois níveis de
serviços. A empresa provedora do sistema de gestão de eficiência energética tem di-
ficuldades para interoperar seu negócio devido aos diversos sistemas de gestão de
eficiência energética em nível operacional. Para o tratamento deste problema será es-
pecificado um modelo de middleware para interoperabilidade de negócio para gestão
de eficiência energética. Este modelo de middleware consiste no artefato deste traba-
lho de pesquisa.
A base de conhecimento desta pesquisa consiste nos modelos de referência utili-
zados como base para o modelo de middleware. É utilizado o ARM como modelo de
conteúdo para IoT, o SGAM como modelo de conteúdo para interoperabilidade no con-
texto de redes elétricas inteligentes, o modelo de informação de Andrén et al. (2017)
como modelo de conteúdo de informação de middleware e o modelo de conteúdo fun-
cional de Razzaque et al. (2016).
Por fim, para validação do artefato, visões arquiteturais serão especificadas em
base ao modelo proposto.
3.2 Modelo conceitual da solução proposta
Nesta seção, será apresentado o modelo conceitual da solução proposta neste pro-
jeto de pesquisa. Neste modelo estão os elementos que compõem a solução proposta
na pesquisa e as relações entre esses elementos. Esse modelo tem por objetivo ilus-
trar como o artefato será elaborado e como cada elementos da pesquisa contribuiu
para a especificação do artefato.
A Figura 15 ilustra o modelo da solução proposta nesta pesquisa. Neste modelo,
estarão ilustrados os modelos de referência que compõem a base da solução, o pro-
cesso de harmonização, os requisitos da contexto social da pesquisa, o processo de
validação do artefato, bem como a relação entre todos esses elementos. Importante
ressaltar que, o elemento ”Modelo de referência de interoperabilidade de negócio na
gestão de eficiência energética”consiste do artefato desta pesquisa e é a represen-
tação neste modelo do elemento ”Modelo de middleware para interoperabilidade de
negócios”presenta na Figura 14
Na Figura 15, é possível verificar quatro tipos de elementos, identificados pelas
62
Figura 15 – Modelo da proposta de trabalho a ser desenvolvido neste trabalho
Fonte: Elaborado pelo autor
cores. Há dois processos, um para a elaboração do modelo de middleware e outro
para elaboração da arquitetura do middleware. Há cinco elementos do contexto do
conhecimento, o modelo funcional de middleware, o modelo de referência do ARM, o
modelo de interoperabilidade do SGAM, o modelo de informação do middleware e a
arquitetura de referência do ARM. Há dois artefatos propostos, omodelo domiddleware
e a arquitetura domiddleware. Por fim, há dois elementos do contexto social, o sistema
de gestão de energia e os requisitos provindos do sistema de gestão de energia.
É importante ressaltar que os requisitos do contexto social tem dois papéis na elabo-
ração do modelo demiddleware. Esses requisitos tem como fonte o sistema de gestão
de eficiência energética desenvolvido no GARFSoft.
Na fase de especificação do modelo de middleware, a qual está ilustrada pelo ele-
mento ”Processo de especificação de modelo de referência”da Figura 15, os requisitos
atuam como critério para seleção dos elementos da harmonização. Esses critérios res-
tringem o escopo de trabalho a ser harmonizado. Sem esses critérios, a atividade de
harmonização levaria muito tempo e sairia fora do escopo desta pesquisa, pois os
modelos de referência são genéricos e contém informações além do escopo deste
trabalho de pesquisa.
Na fase da validação domodelo através da especificação da arquitetura, a qual está
ilustrada pelo elemento ”Processo de especificação de arquitetura em IoT”da Figura 15,
os requisitos atuam como fonte de informação para a especificação da arquitetura do
middleware. Com base a esses requisitos e ao modelo demiddleware, a arquitetura do
63
middleware será especificada estruturada nas visões do RM-ODP (PUTNAM, 2000).
3.3 Especificação de um modelo para interoperabilidade de negócios na gestão de
eficiência energética
Nesta seção, será descrito como os modelos de referência são utilizados na espe-
cificação do modelo para interoperabilidade de negócios na gestão de eficiência ener-
gética. Esse modelo contém uma especificação das funcionalidades que o compõem,
os atores e quais informações são trocadas entre os elementos do modelo.
Os modelos de referência utilizados serão o ARM, o SGAM, o modelo de informa-
ção de Andrén et al. (2017) e o modelo funcional de Razzaque et al. (2016). Para a
especificação do modelo para interoperabilidade de negócios na gestão de eficiência
energética, será executada a harmonização desses modelos de referência com a fina-
lidade de diminuir a complexidade de se trabalhar com múltiplos modelos e aumentar
a coesão da relação entre os diferentes elementos dos diferentes modelos (PARDO et
al., 2010).
3.3.1 O uso do ARM
O ARM define uma arquitetura de referência composta de visões arquiteturais, mo-
delos de referência e guias de implementação. O ARM define em seu modelo de re-
ferência, os elementos necessários para especificação de sistemas no contexto de
IoT. O modelo de referência do ARM é composto de cinco sub-modelos, sendo eles o
sub-modelo de domínio, o sub-modelo de informação, o sub-modelo funcional, o sub-
modelo de comunicação e o sub-modelo de privacidade, confiabilidade e segurança.
Para este trabalho de pesquisa e com a finalidade de obter a interoperabilidade em
nível de negócio, os sub-modelos de domínio, de informação e funcional serão utili-
zados. O sub-modelo de domínio visa identificar os atores do contexto e como esses
atores estão relacionados com os diferentes elementos dos outros modelos. O sub-
modelo de informação visa especificar as informações trocadas nas mensagens entre
os diferentes sistemas. O sub-modelos funcional visa especificar quais funcionalidades
os sistemas devem implementar no contexto de IoT.
Esses sub-modelos trazem o conteúdo de IoT presente no contexto social para o
64
modelo para interoperabilidade de negócios na gestão de eficiência energética.
3.3.2 O uso do SGAM
O SGAM define um modelo de interoperabilidade para redes elétricas inteligentes
definido em cindo camadas. Essas camadas são a camada de negócio, a camada
funcional, a camada de informação, a camada de comunicação e a camada de com-
ponentes.
Para este trabalho de pesquisa, serão utilizadas as camadas de negócio, funcio-
nal e de informação. A camada de negócio visa definir os atores do contexto social, o
propósito desses atores e a relação entre esses atores. A camada funcional visa es-
pecificar os funções que identificam e relacionam cada ator do modelo de negócio. A
camada de informação visa especificar as informações trocadas nas funcionalidades.
Essas camadas contribuem com o conteúdo sobre redes elétricas inteligentes para
o modelo para interoperabilidade de negócios na gestão de eficiência energética.
3.3.3 O uso de Razzaque et al. (2016)
O modelo funcional definido por Razzaque et al. (2016) define um conjunto de fun-
cionalidades características de middleware para IoT. Como este trabalho de pesquisa
visa especificar ummodelo para interoperabilidade de negócios na gestão de eficiência
energética, as funcionalidades de middleware irão contribuir para definição de como o
modelo poderá abstrair a complexidade do negócio.
3.3.4 O uso de Andrén et al. (2017)
O modelo de informação definido por Andrén et al. (2017) visa especificar as in-
formações, e propriedades dessas informações, trocadas entre os diferentes atores e
sistemas das redes elétricas inteligentes. Através desse modelo, um conjunto de obje-
tos de informação são especificados e serão utilizados como base para o modelo para
interoperabilidade de negócios na gestão de eficiência energética.
As informações correspondem ao conjunto de dados e seus significados no con-
texto de pesquisa (ROWLEY, 2007).
65
3.4 O processo de especificação do modelo de interoperabilidade de negócio
Nesta seção, será apresentado o processo de especificação do modelo de intero-
perabilidade de negócio executado nesta pesquisa. Este processo foi todo executado
por um ator, o pesquisador, teve como artefatos de entrada os modelos de referência
e com artefato de saída o modelo harmonizado. Será apresentado uma visão geral do
processo e, após isso, o detalhe de cada atividade.
O processo de especificação do modelo de interoperabilidade de negócio aplicado
neste trabalho está composto de três atividades. Essas atividades estão ilustradas na
Figura 16.
Figura 16 – Processo de harmonização para elaboração do modelo do middleware
Fonte: Elaborado pelo autor
As atividades ilustradas na Figura 16 consistem na harmonização dos modelos de
referência (PARDO et al., 2010). A descrição de cada atividade para a harmonização
dos modelos está listada a seguir:
a) Análise da relação dos modelos com a gestão de eficiência energética em IoT
66
Nesta atividade, a relação entre os modelos é entendida e estabelecida. Dessa
forma, a técnica para a harmonização dos modelos é definida.
b) Harmonização dos modelos
Nesta atividade, a harmonização dos modelos é executada. A harmonização dos
modelos é realizada em três passos. Primeiro, os elementos dos modelos são ho-
mogeneizados utilizando como base um modelo abstrato comum, neste caso, o
RM-ODP. Após a homogeneização, é executada a comparação entre os elemen-
tos do modelo a fim de se identificar os elementos comuns. Por fim, é realizada
a integração dos elementos para obter o elemento harmonizado.
c) Revisão e documentação do modelo
Após concluída a harmonização, a documentação do modelo existente é execu-
tada.
3.4.1 Análise dos modelos
Nesta seção, será apresentado como foi realizada a atividade análise dos modelos
de referência utilizados na pesquisa. Também será descrito quais partes dos modelos
de referência foram utilizadas para a harmonização.
Mais uma vez, é importante ressaltar que o contexto social estabelecido pelo projeto
no GARFSoft estabeleceu restrições para a atividade de harmonização. Dessa forma,
foram harmonizados somente as partes dos modelos que possuíam relação com o
contexto social, o que neste caso é a gestão de eficiência energética. Essa limitação
foi essencial, pois sem ela ter-se-ia muitos elementos a serem harmonizados que não
trariam valor ao trabalho.
Dessa forma, sempre que os modelos foram analisados neste trabalho, foi sob a
óptica da gestão de eficiência energética, sendo desconsiderados elementos que não
tangessem a esse contexto.
Com base às visões arquiteturais do RM-ODP, as quais foram utilizadas para es-
pecificar a arquitetura do middleware deste trabalho de pesquisa, foi analisado quais
partes dos modelos de referência teriam relação com essas visões. Essa relação está
ilustrada na Figura 17.
67
Figura 17 – Análise das relações entre as visões arquiteturais do RM-ODP e as partesdos modelos de referência
Fonte: Elaborado pelo autor
Como está ilustrado na Figura 17, as partes os modelos de referência utilizados
foram categorizadas pelo pesquisador em três grupos de acordo com o propósito de
cada parte.
O grupo de domínio contém os modelos que descrevem os atores, os propósitos
desses atores, os sistemas e outros elementos os quais compõem o contexto da pes-
quisa. Neste grupo de modelos estão o sub-modelos de domínio do ARM e a camada
de negócios do SGAM.
O grupo funcional contém os modelos que descrevem as funcionalidades dos sis-
temas e com as quais os atores interagem para interoperar. Neste grupo estão o sub-
modelo funcional do ARM, a camada de interoperabilidade funcional do SGAM e o
modelo funcional definido por Razzaque et al. (2016).
O grupo de informação contém os modelos que descrevem as informações e o
significado das informações trocadas entre os sistemas com a finalidade de interoperar.
Neste grupo estão o sub-modelos de informação e o modelo de informação definido
por Andrén et al. (2017).
Por fim, a harmonização foi executada para cada grupo de modelos descrito.
68
3.4.2 Harmonização dos modelos de referência
Nesta seção, será apresentado como foi executado a harmonização dos modelos
de referência. Essa execução foi dividade em três etapas distintas, a homogeneização,
a comparação e a integração. É importante ressaltar que, a harmonização dos mode-
los de referência neste trabalho busca especificar um modelo com menor número de
elementos e com uma maior cobertura sob o escopo da gestão da eficiência energé-
tica.
3.4.2.1 Homogeneização de modelos de referência
Nesta etapa, os modelos de referência são abstraídos para um modelo mais abs-
trato com a finalidade de colocar os diferentes elementos dos diferentes modelos sob
a mesma taxonomia (PARDO et al., 2012). Para isso, uma matriz de critérios foi elabo-
rada como forma de guiar o trabalho de abstração dos elementos dos modelos utiliza-
dos para o modelo de referência RM-ODP. Essa matriz está representada na Tabela
1.
Seguindo a matriz de critérios para homogeneização, o resultado obtido foram os
modelos homogeneizados. A Figura 18 ilustra o resultado da homogeneização dos mo-
delos pertencentes ao grupo de domínio. Para descrever os elementos neste processo
de harmonização, foi utilizado a notação UML4ODP (LININGTON et al., 2011).
Os elementos do grupo de domínio foram homogeneizados para os elementos da
visão empresa. A partir do SGAM, foi selecionado um conjunto de atores relacionados
ao contexto social desta pesquisa. Esses atores estão relacionados ao grupo de atores
Serviços de Energia e Usuários da Rede Elétrica. O ARM definiu atores no sub modelo
de domínio e esses atores também foram homogeneizados. Essa atividade resultou
na homogeneização de 15 elementos ao todo, duas comunidades e 13 papéis.
A Figura 19 ilustra o resultado da homogeneização dos modelos pertencentes ao
grupo funcional.
A homogeneização dos elementos do grupo funcional utilizou omodelo funcional de
Razzaque et al. (2016), do modelo funcional definido no ARM (CARREZ et al., 2013) e
o conjunto de funcionalidades SGAM (CEN-CENELEC-ETSI, 2012a). Cada elementos
desses modelos funcionais foram classificados como objetos ações, o qual determina
69
Tabela 1 – Matriz de critérios de homogeneização
Visão empresaNúmero do critério Elemento do mo-
delo de referênciaFator de decisão Elemento do RM-
ODP1 Domínios (SGAM) Elementos que re-
presentam gruposde entidades comum objetivo em co-mum
Comunidades
2 Usuários(ARM),atores (SGAM)
Elementos re-presentantes deatores, usuários,clientes ou quais-quer entidadesas quais atuemdiretamente comos sistemas
Atores
3 Propósitos dos ato-res (SGAM), usuá-rios (ARM)
Descrição dos ob-jetivos e do propó-sito dos atores
Objetivos
Visão informação4 Informação (ARM),
informação (AN-DRÉN et al., 2017)
Elementos que re-presentam a infor-mação presente nosistema
Objeto de informa-ção
5 Funcionalidades(ARM), Funciona-lidades (SGAM),Funcionalidades(RAZZAQUE et al.,2016)
Elementos que re-presentam funcio-nalidades ou açõesque manipulem asinformações
Tipos de ação dainformação
6 Grupo funcional(ARM), Grupofuncional (SGAM)
Agrupamento defuncionalidades e /ou informações
InvariantSchema
Fonte: Elaborado pelo autor
as ações que um sistema aplica sob a informação. Essa atividade resultou na homo-
geneização 43 elementos, sendo 9 grupos funcionais e 34 funcionalidades. Os grupos
funcionais foram homogeneizados para objetos pacote e as funcionalidades para ob-
jetos ação.
A Figura 20 ilustra o resultado da homogeneização dosmodelos pertencentes grupo
de informação.
A homogeneização da visão informação utilizou o modelo de informação de An-
70
drén et al. (2017) e o modelo de informação ARM (CARREZ et al., 2013). O SGAM
(CEN-CENELEC-ETSI, 2012b) não foi considerado pois, apesar de conter um camada
específica para o tratamento da interoperabilidade de informação, não define nenhum
modelo. O SGAM faz a recomendação de utilização dos modelos de informação exis-
tentes para o contexto social do trabalho. Além disso, o modelo de Andrén et al. (2017)
está baseado no SGAM. Essa atividade resultou na homogeneização de 35 elemen-
tos, sendo os 35 elementos informações. Esses elementos foram homogeneizados
para objetos informação.
71
Figura18
–Resultado
dahomogeneizaçãodosmodelos
dogrupode
domínio
Fonte:Elaborado
peloautor
72
Figura19
–Resultado
dahomogeneizaçãodosmodelos
dogrupode
funcional
Fonte:Elaborado
peloautor
73
Figura20
–Resultado
dahomogeneizaçãodosmodelos
dogrupode
informação
Fonte:Elaborado
peloautor
74
3.4.2.2 Comparação de modelos
Nesta etapa, os modelos homogeneizados são comparados a fim de se identificar
quais elementos possuem similaridade semântica ou, até mesmo, possuem o mesmo
significado em dois modelos distintos (PARDO et al., 2012). Ao final desta etapa, as
intersecções entre os modelos e as relações entre elementos de distintos modelos
estarão identificadas. Os modelos comparados estão no Anexo A.
A propriedade dos elementos considerada para a comparação foi o propósito. Dessa
forma, elementos que possuem o mesmo propósito foram comparados a fim de identi-
ficar se esses elementos poderiam ser considerados o mesmo objeto.
Nos modelos do grupo de domínio foram identificados 2 comunidades, a comu-
nidade de ”Serviços de energia”e a comunidade de ”Usuários da rede elétrica”. Na
comunidade de ”Serviços de energia”foi identificado 7 papéis e definido um objetivo.
Na comunidade de de ”Usuários da rede elétrica”foram identificados 6 papéis e um
objetivo. Não foram identificados elementos que definissem os processos dessas co-
munidades e nem políticas.
Na execução da comparação dos elementos homogeneizados não foram encon-
trados elementos com o mesmo propósito. Dessa forma, a técnica a ser utilizada na
atividade de integração será a técnica de ”União”.
Nos modelos grupo funcional foram identificados 43 elementos. Desses 43 elemen-
tos, 9 eram grupos funcionais e 34 eram funcionalidades. A comparação das funcio-
nalidades identificou 4 conjuntos de funcionalidades com propósitos similares entre os
elementos do modelo funcional do ARM e os elementos do modelo funcional de Raz-
zaque et al. (2016). O modelo funcional do SGAM não tem elementos com propósitos
similares. Para a integração desses modelos a técnica a ser utilizada será a técnica
de ”Complemento”, tendo como modelo base o ARM pois o ARM é o modelo mais
abrangente.
Nos modelos do grupo de informação foram identificados 35 elementos, sendo to-
dos os 35 elementos objetos informação. A comparação desses elementos identificou
4 conjuntos de objetos informação com propósito similares entre os elementos do mo-
delo de informação do ARM e o modelos de informação de Andrén et al. (2017). Dessa
forma, a integração desses elementos utilizará da técnica de ”Complemento”, tendo
como base o modelo de informação de Andrén et al. (2017) pois, neste caso, é o mo-
75
delo mais abrangente.
3.4.2.3 Integração de modelos
Nesta etapa, os modelos são integrados com base às comparações realizadas. O
objetivo é eliminar os elementos desnecessários e mesclar os diferentes modelos a fim
de se obter um modelo único (PARDO et al., 2012). A atividade integração consiste na
análise das comparações executadas e aplicação das técnicas de união, intersecção
e / ou complemento. De acordo com a análise da relação de cada modelo, uma das
técnicas é aplicada.
Para a integração dos modelos de referência deste trabalho de pesquisa, foram
aplicadas as técnicas de ”União”e ”Complemento”.
Para a integração dos elementos dos modelos do grupo de domínio, a técnica de
”União”foi utilizada. Devido ao fato de não haver similaridades entre os elementos dos
modelos de referência, a união permitiu que o modelo harmonizado resultasse em um
modelo mais completo. Essa técnica acabou de fazer não ter diferenças no resultado
da homogeneização, pois os elementos homogeneizados não sofreram alterações nas
etapas de comparação e integração.
Para a integração dos elementos dos modelos do grupo funcional e do grupo de
informação, a técnica utilizada foi o ”Complemento”. Devido ao fato de haver elementos
com propósitos similares, a transformação de dois ou mais elementos similares em um
permite uma maior simplicidade sem afetar a completude do modelo.
Por fim, o modelos harmonizado foi obtido. O modelo harmonizado está represen-
tado em 3 figuras. A Figura 21 ilustra o resultado da harmonização dos elementos do
grupo de domínio. A Figura 22 ilustra o resultado da harmonização dos elementos do
grupo funcional. Por fim, a Figura 23 ilustra o resultado da harmonização dos elemen-
tos do grupo de informação.
76
Figura21
–Resultado
daharmonização
dosmodelos
dogrupode
domínio
Fonte:Elaborado
peloautor
77
Figura22
–Resultado
daharmonização
dosmodelos
dogrupofuncional
Fonte:Elaborado
peloautor
78
3.4.3 Revisão dos resultados
A última atividade deste processo de especificação domodelo de interoperabilidade
de negócios na gestão da eficiência energética foi a revisão dos modelos. Nesta ativi-
dade, não foram encontrados inconsistência e o pesquisador definiu o modelo pronto
para ser utilizado na especificação de visões arquiteturais.
79
Figura 23 – Resultado da harmonização dos modelos do grupo de informação
Fonte: Elaborado pelo autor
81
4 VALIDAÇÃO DO TRABALHO
Nesta seção, será apresentado o método de validação utilizado e o processo que
foi seguido para aplicação do método de validação. A validação irá demonstrar como o
modelo de interoperabilidade de negócio na gestão da eficiência energética foi utilizado
na especificação de visões arquiteturais.
4.1 Método de validação
O Design Science (DS) é o design (projeto / desenho) e investigação de um ar-
tefato em um contexto (WIERINGA, 2014). É uma abordagem para a resolução de
problemas a qual busca criar produtos inovadores através de processos de análise,
design e implementação (UYSAL, 2016).
A fase de validação visa justificar que um tratamento contribui para os objetivos dos
atores envolvidos. Ela é feita através da elaboração de um protótipo do artefato e da
aplicação deste protótipo no contexto de pesquisa (WIERINGA, 2014).
Wieringa (2014) ainda classifica os quatro métodos de pesquisa segundo o local
de sua execução e a natureza do que é estudado. Essa classificação está ilustrada na
Figura 24.
Figura 24 – Classificação dos métodos de pesquisa
Fonte: (WIERINGA, 2014)
Devido ao fato de esta pesquisa estar localizada no GARFSoft e estudar o caso
82
individual da gestão de eficiência energética para a empresa provedora de serviços
relacionado ao laboratório, o método de pesquisa utilizado será o mecanismo de expe-
rimento único.
4.1.1 Mecanismo de experimento de caso único
O método de pesquisa mecanismo de experimento de caso único tem por objetivo
descrever e explicar o efeito da aplicação de um artefato sob um objeto de estudo. Na
aplicação do mecanismo de experimento de caso único, o pesquisador tem acesso ao
objeto de estudo e conhece sua arquitetura (WIERINGA, 2014). A interoperabilidade
entre os sistemas de gestão de eficiência energética de nível gerencial e o sistema
de gestão de eficiência energética de nível operacional consiste no objeto de estudo
desta pesquisa.
Nesta pesquisa, a validação da arquitetura do modelo de interoperabilidade de ne-
gócios foi realizada através da especificação de modelos das visões arquiteturais de
um middleware para o tratamento da interoperabilidade de negócio. Essa especifica-
ção será realizada tendo como base o modelo de referência de interoperabilidade de
negócio na gestão de eficiência energética e as visões do RM-ODP (ISO/IEC, 2009).
4.2 O processo para especificação das visões arquiteturais
Nesta seção, será apresentado o processo para execução da fase de validação da
pesquisa. Esse processo visou a especificação de modelos das visões arquiteturais do
RM-ODP baseadas no modelo de interoperabilidade de negócios na gestão de eficiên-
cia energética. Essas visões arquiteturais representarão parte da especificação de um
middleware.
A Figura 25 ilustra as atividade para a elaboração das visões arquiteturais do mid-
dleware.
As atividades a serem executadas para elaboração domodelos baseado nas visões
arquiteturais estão listadas a seguir:
a) Análise do contexto do experimento e da gestão da eficiência energética
Nesta atividade, os requisitos provenientes do trabalho de gestão de eficiência
energética desenvolvido no GARFSoft são analisado. Os elementos do trabalho
83
Figura 25 – Processo de design do tratamento para elaboração da arquitetura do mid-dleware
Fonte: Elaborado pelo autor
desenvolvido noGARFSoft irão auxiliar a análise domodelo de interoperabilidade
de negócios validando o modelo e complementando-o quando necessário.
b) Modelagem dos atores, suas responsabilidades e suas relações
Nesta atividade, a visão de contexto é elaborada contendo todos os atores e
demonstrando como estes atores atuam dentro do contexto.
c) Modelagem das funcionalidades da gestão de eficiência energética
Nesta atividade, a visão funcional será elaborada descrevendo as funcionalida-
des contidas no modelo de referência e executadas pelos provedores de serviço
e pelos consumidores.
d) Modelagem dos elementos de informação da gestão de eficiência energética
Nesta atividade, a visão de informação será elaborada contendo o modelo de
informação domiddleware e descrevendo como a informação será ofertada pelos
dispositivos e consumida pelo sistema de gestão de energia.
e) Modelagem de elementos da visão computação
84
Nesta atividade, uma visão geral dos objetos computação é especificada para
demonstrar como ficaria o desacoplamento do sistema de gestão de eficiência
energética em nível gerencial e do sistema de gestão de eficiência energética em
nível operacional.
Por fim, ao final desta fase, ter-se-á os modelos das visões arquiteturais relaciona-
das ao modelo de interoperabilidade de negócios na gestão de eficiência energética.
Esses modelos serão as evidência da aplicabilidade do modelo.
4.3 Aplicação do experimento
Nesta seção, será descrito como o experimento foi executado. Primeiro, será apre-
sentado o contexto do experimento, no qual estará descrito o relacionamento do pro-
jeto desenvolvido no GARFSoft com esta pesquisa. Após isso, serão apresentadas
as visões arquiteturais especificadas com o uso do modelo de interoperabilidade de
negócios. Por fim, a análise do artefato será apresentada.
O objetivo do experimento consiste na verificação da aplicabilidade do modelo de
interoperabilidade de negócios na gestão da eficiência energética para a especificação
de visões arquiteturais.
Para simplificar a escrita, sempre que estiver escrito ”modelo de interoperabilidade
de negócios”nesta seção significa o artefato especificado neste trabalho de pesquisa,
o qual é o modelo de middleware para a interoperabilidade de negócios para gestão
da eficiência energética.
4.3.1 O contexto do experimento
Nesta seção, será apresentado o contexto do experimento. O contexto do experi-
mento realizado está baseado no projeto para implementação de um sistema de gestão
de eficiência energética noGARFSoft. Esse sistema tem por objetivo melhorar o uso da
energia em prédios através do uso de inteligência na análise de padrões de consumo
e uso de dispositivos IoT.
Busca-se por meio desse sistema, analisar as propriedades do local, como por-
tas, janelas, tamanho de cômodos, dentre outras, associada a outras variáveis para o
entendimento do consumo energético do prédio como um todo. Após essa análise, a
85
definição e aplicação de políticas de melhoria do consumo energético é aplicada, vi-
sando o aumento da eficiência. Todo o processo é acompanhado através da sistemas
de monitoração.
Na Figura 26, está ilustrado a visão empresa do sistema de gestão de eficiência
energética.
Figura 26 – Visão empresa do sistema de gestão de eficiência energética
Fonte: Adaptado pelo autor
Na Figura 26, é possível notar a especificação dos processos envolvidos na gestão
da eficiência energética divididos em 2 grupos, gerencia e operacional. É importante
ressaltar que o middleware está posicionado entre os pacotes ”Gerencial”e ”Operacio-
nal”. Na Figura 26, o middleware não está representado pois não encontra-se desen-
volvido.
A Figura 27 ilustra a visão informação do sistema de gestão de eficiência energética.
Na Figura 27, é possível notar a relação entre as informações analisadas. Essas in-
formações estão sub divididas em três grupos, variáveis de serviços do local, variáveis
86
Figura 27 – Visão informação do sistema de gestão de eficiência energética
Fonte: Adaptado pelo autor
de clima, variáveis de ambiente.
A Figura 28 ilustra a visão computação do sistema de gestão de eficiência energé-
tica.
Na Figura 28, é possível notar os módulos do sistema de gestão de eficiência ener-
gética. Aqui fica evidente o acoplamento entre o sistema de gestão de eficiência ener-
gética na camada gerencial e o sistema de gestão de eficiência energética na camada
operacional.
Esse acoplamento dificulta os negócios da empresa provedora de energia, uma vez
que seu sistema na camada gerencial tem de interoperar com mais de um sistema na
camada operacional.
Para atuar no tratamento do problema de interoperabilidade de negócios apresen-
tado, um middleware será especificado e implementado. A especificação desse mid-
dleware está baseada no modelos de interoperabilidade de negócios definido neste
trabalho.
4.3.2 As visões arquiteturais de um middleware para interoperabilidade de negócio
Nesta seção, serão apresentadas as visões arquiteturais especificadas a partir do
modelos de interoperabilidade de negócios na gestão da eficiência energética.
87
Figura 28 – Visão computação do sistema de gestão de eficiência energética
Fonte: Adaptado pelo autor
A especificação das visões arquiteturais de ummiddleware tem por objetivo validar
o uso do modelo de interoperabilidade de negócio na gestão de eficiência energética.
Pata tal, essa atividade de especificação teve como foco as visões arquiteturais rela-
cionadas aos modelos obtidos. Dado o fato de o foco deste trabalho ser a interopera-
bilidade de negócio, as visões arquiteturais especificadas foram a visão empresa e a
visão de informação.
Na Figura 29, está ilustrada a especificação empresa.
Na Figura 29, estão ilustrados os elementos da visão empresa, a comunidade do
provedor de gestão de eficiência energética, a comunidade da agência bancária, o
sistema gerencial de gestão de eficiência energética, o middleware de gestão de efici-
ência energética e o sistema de gestão de eficiência energética em nível operacional.
Na especificação empresa é possível notar alguns elementos do modelo especificado
neste trabalho, pois ambas as comunidades estão previstas no modelo. A comunidade
provedor de gestão de eficiência energética está especificada na comunidade ”Servi-
ços de Energia”. Já a comunidade agência bancária está especificada como ”Usuários
da rede elétrica”. Os sistemas não estavam previstos no modelo e foram modelados
88
Figura 29 – Visão empresa baseada no modelo de interoperabilidade de negócios
Fonte: Elaborado pelo autor
dado o contexto social.
A Figura 30 ilustra a especificação da comunidade provedor de gestão de eficiência
energética.
Nesta especificação também é possível notar alguns elementos do modelo. A co-
munidade em si está prevista no modelo e, também, o objetivo da comunidade. Os
papéis também foram utilizados segundo o modelo. Novamente, os sistemas não esta-
vam presentes no modelo e foram especificados segundo o contexto social do trabalho.
Também é importante notar que, o objeto processo da especificação da comunidade
não estava presente no modelo. Isso deve-se ao fato de nenhum modelo de referên-
cia especificar os processos de negócio desses atores. O objeto processo ilustrado na
Figura 26 são os processos do contexto social.
Dado a especificação empresa e a especificação da comunidade provedor de ges-
tão de eficiência energética, foi especificado a visão informação para o middleware. O
89
Figura 30 – Comunidade provedor de gestão de eficiência energética baseada no mo-delo de interoperabilidade de negócios
Fonte: Elaborado pelo autor
sistema gerencial de gestão de eficiência energética não foi especificado pois não é
foco deste trabalho de pesquisa e já está descrito no contexto do experimento.
Na Figura 31 está ilustrada a especificação informação do middleware de gestão
de eficiência energética.
A especificação informação é composta por dois principais elementos o schema de
informações e o schema de ações. A Figura 32 ilustra o schema de ações.
Na Figura 32 cada objeto ação representa uma funcionalidade domiddleware. Dado
o contexto social, as funcionalidades ”coletorDadosServiçosEdifício”, ”coletorDadosAm-
bienteEdifício”, ”coletorDadosConsumoEdifício”e ”coletorDadosClima”foram adiciona-
das à especificação do middleware e não estavam previstas no modelo. As outras
funcionalidades já estavam previstas no modelo de interoperabilidade.
A Figura 33 ilustra uma visão geral do schema de informação do middleware.
Na Figura 33 está especificado o middleware como objeto informação aplicação e
seu relacionamentos com os grupos funcionais descritos pelos pacotes. Essa visão ge-
ral visa simplificar a leitura do modelo pois, sem ela, o modelo ficaria extenso demais.
Serão detalhados dois grupos funcionais, o grupo das funções de gerenciamento e o
grupo das funções de gestão operacional de eficiência energética. A escolha desses
dois grupo foi feita com base à quantidade de funções pertencentes a estes grupos.
90
Figura 31 – Especificação informação baseada no modelo de interoperabilidade de ne-gócios
Fonte: Elaborado pelo autor
Como estes dois grupos são os maiores grupos funcionais da especificação, já é pos-
sível cobrir os casos necessários para avaliar o modelo. Além disso, os grupos funcio-
nais de funções de serviços IoT e funções de entidades virtuais são grupos de suporte
aos outros grupos funcionais, tendo influência indireta sobre a interoperabilidade de
negócios.
Na Figura 34, está ilustrado o detalhamento da especificação informação para as
funções de gestão operacional de eficiência energética.
Como é possível notar na Figura 34, o único elemento que não foi possível espe-
cificar a partir do modelo de interoperabilidade de negócios foi o elemento ”Sítio”. Os
demais elementos já estavam previstos no modelo.
A Figura 35 ilustra o detalhamento da especificação informação para as funções de
gerenciamento.
Neste detalhamento também é possível notar que o único elemento não previsto
no modelo de interoperabilidade de negócio foi o elemento ”Sítio”.
Também foi especificado um visão geral da visão computação do middleware com
a finalidade de ilustrar como ficaria os objetos computação após a introdução do mid-
91
Figura 32 – Schema de ações baseada no modelo de interoperabilidade de negócios
Fonte: Elaborado pelo autor
dleware e compará-la com a visão computação descrita no contexto do experimento.
A Figura 36 ilustra a visão computação do middleware.
Como é possível notar na Figura 36, o sistema gerencial de gestão de eficiência
energética não mais interopera diretamente com o sistema de gestão de eficiência
energética em nível operacional.
Por fim, o experimento foi concluído com base nas visões especificadas.
92
Figura 33 – Visão geral do schema de informação baseada no modelo de interopera-bilidade de negócios
Fonte: Elaborado pelo autor
93
Figura 34 – Schema de informação do módulo operacional baseada no modelo de in-teroperabilidade de negócios
Fonte: Elaborado pelo autor
94
Figura 35 – Schema de informação do módulo gerenciamento baseada no modelo deinteroperabilidade de negócios
Fonte: Elaborado pelo autor
95
Figura 36 – visão geral da visão computação do middleware
Fonte: Elaborado pelo autor
97
5 CONSIDERAÇÕES FINAIS
Nesta seção, serão apresentadas as conclusões deste trabalho de pesquisa. Tam-
bém serão descritos alguns trabalhos futuros.
5.1 Conclusões
Este trabalho especificou um modelo de interoperabilidade de negócios na gestão
de eficiência energética.
Através do experimento conduzido foi possível validar o uso do modelo de inte-
roperabilidade de negócios. Considerando comunidades, papéis, objetivos, pacotes,
informações e ações, foram especificados no total 89 objetos no total. Durante o expe-
rimento, foram adicionados 9 objetos, sendo 1 objeto processo, 3 objetos sistemas, 1
objeto informação e 4 objetos ação. Dessa forma, conclui-se que o modelo permitiu a
especificação de um middleware para a interoperabilidade de negócios na gestão de
eficiência energética.
Porém, é importante destacar que os modelos de referência não especificavam
nenhum sistema. Na especificação da arquitetura, os sistemas de gestão de eficiên-
cia energética em nível gerencial, o middleware e o sistema de gestão de eficiência
energética em nível operacional estão presentes. Também os processos de negócio
possuem papel importante na definição do modelo de interoperabilidade e não havia
especificação de processos nos modelos de referência.
As ausência de especificação de sistemas e processos não impossibilitou a espe-
cificação das visões do middleware, porém serão consideradas nos trabalhos futuros.
Durante este trabalho de pesquisa, as questões relacionadas às questões do co-
nhecimento e problemas de design foram analisadas e respondidas. Algumas ques-
tões foram reelaboradas com a evolução da pesquisa. A listagem abaixo apresenta as
questões e as respostas:
• Questão: Como possibilitar a interoperabilidade de negócios para gestão de ener-
gia em ambientes de sistemas inteligentes de energia?
Esta questão foi amotivação inicial deste trabalho. O tratamento foi diagnosticado
através da implementação de um middleware.
98
• Questão: Quais os serviços dos consumidores de energia utilizados para realizar
a gestão de energia?
Os modelos de referência especificaram grande parte dos serviços necessários
para gestão da eficiência energética e foram modelados no artefato. Vale ressal-
tar que, alguns serviços foram especificados a partir do contexto social.
• Questão: Quais os atores atuantes na gestão de energia baseado em sistemas
de energia inteligentes?
No modelo conceitual do SGAM (CEN-CENELEC-ETSI, 2012b) os atores do sis-
tema de energia são apresentados, são eles Responsável pelo balanceamento
da rede elétrica, Responsável pelo gestão do consumo, Responsável pela ges-
tão da produção, Responsável pela gestão do comércio. Vale ressaltar que, há
outros atores especificados no SGAM que estão fora do contexto deste trabalho.
• Questão: Qual modelo de referência para especificação de arquiteturas de mid-
dleware de sistemas de energia inteligentes? E como esse modelo impacta os
sistemas de gestão de energia?
Essa questão visou estabelecer um ponto de referência para o desenvolvimento
deste trabalhos. Neste ponto, foram estudados os modelos de referência de An-
drén et al. (2017), de Razzaque et al. (2016), o ARM e o SGAM.
• Questão: Qual modelo arquitetural de referência para IoT?
Nesta questão, através dos estudos realizados foi definido que o ARM será o
modelo arquitetural de referência utilizado.
• Questão: Quais arquiteturas atuais paramiddleware de gestão da eficiência ener-
gética em sistemas de energia?
Foram estudados alguns trabalhos nos quais sistemas de gestão de energia fo-
ram implementados. Esses trabalhos contribuíram para o entendimento geral da
gestão de energia. Os principais trabalhos foram Bellagente et al. (2015), Shams-
zaman et al. (2014) e Okuno et al. (2015).
• Questão: Qual modelo de referência garantiria a interoperabilidade em nível de
negócio para a gestão da eficiência energética?
99
Mais uma vez, os elementos utilizados foram os modelos de referência de An-
drén et al. (2017), de Razzaque et al. (2016), o ARM e o SGAM. Como não foi
encontrado nenhum modelo único para a interoperabilidade de negócios, a har-
monização de modelo de referência foi utilizada.
• Questão: O modelo especificado permitiu o tratamento da interoperabilidade de
negócios na gestão da eficiência energética?
As conclusões deste trabalho de pesquisa são de que, sim, o modelo de intero-
perabilidade de negócios na gestão de eficiência energética permitiu a especi-
ficação de visões arquiteturais de um middleware focado no tratamento dessa
interoperabilidade.
5.2 Trabalhos futuros
Por fim, o trabalho realizado por esta pesquisa permitiu identificar alguns pontos de
evolução e trabalhos futuros. Esses trabalhos estão destacados nesta seção.
Primeiramente, com o objetivo de enriquecer o modelo de interoperabilidade de
negócios na gestão de eficiência energética, é necessário identificar um modelo de
referência de processos de negócio. Esse modelo de referência entra como modelo a
ser harmonizado e facilitará que outras empresas provedoras de serviços de gestão
de eficiência energética adotem o modelo especificado.
Outro ponto a ser trabalhado no futuro, diz respeito a especificação de outras vi-
sões, como a engenharia e a tecnologia. Isso traria maior abrangência ao modelo de
negócios.
É importante também evoluir o trabalho no sentido da implementação do que foi
especificado. A implementação do middleware e sua implantação no contexto social
trarão novos elementos a serem analisados.
Por fim, um aspecto importante e de grande notoriedade no mundo acadêmico diz
respeito à segurança. Evoluir o modelo de referência considerando as questões de
segurança e o contexto de IoT será um grande trabalho a ser desenvolvido.
101
REFERÊNCIAS
AL-JAROODI, J. et al. Distributed systems middleware architecture from a softwareengineering perspective. In: IEEE. Information Reuse and Integration, 2003. IRI2003. IEEE International Conference on. [S.l.], 2003. p. 572–579.
ALLIANCE, O. OpenADR 2.0 profile specification, A profile. 2017. Disponível em:<http://www.openadr.org/>.
ANDRÉN, F. P. et al. Engineering smart grids: Applying model-driven developmentfrom use case design to deployment. Energies, Multidisciplinary Digital PublishingInstitute, v. 10, n. 3, p. 374, 2017.
ASHTON, K. That ’Internet of Things’ thing. 2009. Disponível em: <http://www.rfidjournal.com/articles/view/4986>.
ATZORI, L. et al. The internet of things: A survey. Computer Network, v. 54, n. 15, p.2787–2805, June 2010.
BANDYOPADHYAY, S. et al. Role of middleware for internet of things: A study.International Journal of Computer Science and Engineering Survey, v. 2, n. 3, p.94–105, 2011.
BAO, J. et al. OWL 2 Web Ontology Language. [S.l.], 2012. Disponível em:<https://www.w3.org/TR/2012/REC-owl2-quick-reference-20121211/>.
BELLAGENTE, P. et al. Adopting iot framework for energy management of smartbuilding: A real test case. In: IEEE. Research and Technologies for Society andIndustry Leveraging a better tomorrow (RTSI), 2015 IEEE 1st International Forumon. [S.l.], 2015. p. 138–143.
BERNERS-LEEA, T.; CONNOLLY, D. Hypertext Markup Language - 2.0. [S.l.], 1995.Disponível em: <https://tools.ietf.org/html/rfc1866>.
BLUMSACK, S.; FERNANDEZ, A. Ready or not, here comes the smart grid! Energy,v. 37, n. 1, p. 61–68, 2012.
BRAY, T. et al. Extensible Markup Language (XML) 1.0. [S.l.], 2008. Disponível em:<https://www.w3.org/TR/REC-xml/>.
CARREZ, F. et al. Final architectural reference model for the iot v3. 0, internetof things-architecture iot-a ec project. Internet of Things - Architecture ProjectConsortium, Internet of Things - Architecture, D1.5, p. 482, July 2013. Disponível em:<http://www.iot-a.eu/public/public-documents/d1.5/view>.
CEN. European Committee for Standardization. 2017. Disponível em: <https://www.cen.eu/Pages/default.aspx>.
102
CEN-CENELEC-ETSI. Smart Grid Reference Architecture - Group First set ofstandards. [S.l.], 2012.
. Smart Grid Reference Architecture - Smart Grid Architecture ModelFramework. [S.l.], 2012.
. Mandate M/490. 2017. Disponível em: <http://ec.europa.eu/growth/tools-databases/mandates/index.cfm?fuseaction=search.detail&id=475>.
CENELEC. European Committee for Eletrotecnichal Standardization. 2017.Disponível em: <https://www.cenelec.eu/>.
EICHINGER, F. et al. Data analysis challenges in the future energy domain.Computational Intelligent Data Analysis for Sustainable Development, p.181–242, 2012.
EMMERICH, W. Software engineering and middleware: a roadmap. In: ACM.Proceedings of the Conference on the Future of Software Engineering. [S.l.],2000. p. 117–129.
ETSI. European Telecommunication Standard Institute. 2017. Disponível em:<http://www.etsi.org/>.
FP7. Seventh Framework Programme for Research and TechnologicalDevelopment. 2016. Disponível em: <https://ec.europa.eu/research/fp7/>.
GREGORATTI, D.; MATAMOROS, J. Distributed energy trading: The multiple-microgrid case. IEEE Transactions on Industrial Electronics, v. 62, n. 4, p.2551–2559, April 2015.
GRIDWISE, A. C. Gridwise interoperability context-setting framework. Smart GridsInteroperability, p. 1 – 52, 2008.
GUDGIN, M. et al. SOAP Version 1.2. [S.l.], 2007. Disponível em: <https://www.w3.org/TR/soap12/>.
IEC. Energy management system application program interface (EMS-API). [S.l.],2005. Disponível em: <https://webstore.iec.ch/publication/6208>.
. IEC 61850 - Communication networks and systems for power utilityautomation. [S.l.], 2016. Disponível em: <https://webstore.iec.ch/publication/6028>.
. Smart grid standards map. 2017. Disponível em: <http://smartgridstandardsmap.com/>.
IEEE-SA. Internet of things ecosystem study. [S.l.], 2015.
103
ISO/IEC. ISO/IEC 10746-1, 2, 3, 4| ITU-T Recommendation X. 901. 2009.
ISSARNY, V. et al. A perspective on the future of middleware-based softwareengineering. In: IEEE COMPUTER SOCIETY. 2007 Future of Software Engineering.[S.l.], 2007. p. 244–258.
ITU. Itu internet reports 2005: The internet of things. Geneva: InternationalTelecommunication Union (ITU), ITU, 2005.
LI, S. et al. The internet of things: a survey. Information Systems Frontiers, v. 17,n. 2, p. 243–259, April 2015.
LININGTON, P. F. et al. Building enterprise systems with ODP: an introduction toopen distributed processing. [S.l.]: CRC Press, 2011.
MAHIEUX, C.; OUDALOV, A. Microgrids enter the mainstream. Renewable EnergyFocus, v. 17, n. 2, p. 70–72, April 2016.
NIST. National Institute of Standards and Technology. 2017. Disponível em:<https://www.nist.gov/>.
OKUNO, Y. et al. Xmpp-based energy management system architecture forcommunications systems. In: IEEE. Telecommunications Energy Conference(INTELEC), 2015 IEEE International. [S.l.], 2015. p. 1–6.
OŻADOWICZ, A.; GRELA, J. An event-driven building energy management systemenabling active demand side management. In: IEEE. Event-based Control,Communication, and Signal Processing (EBCCSP), 2016 Second InternationalConference on. [S.l.], 2016. p. 1–8.
PARAG, Y.; SOVACOOL, B. K. Electricity market design for the prosumer era. NatureEnergy, v. 1, n. 16032, 2016.
PARDO, C. et al. A process for driving the harmonization of models. In: ACM.Proceedings of the 11th International Conference on Product Focused Software.[S.l.], 2010. p. 51–54.
. An ontology for the harmonization of multiple standards and models. ComputerStandards and Interfaces, v. 34, n. 1, p. 48–59, 2012.
PARLANTI, D. et al. A scalable grid and service-oriented middleware for distributedheterogeneous data and system integration in context-awareness-oriented domains.In: SPRINGER. The Internet of Things. [S.l.], 2010. p. 109–118.
PLUMMER, D. C. An Ethernet Address Resolution Protocol. [S.l.], 1982. Disponívelem: <https://www.ietf.org/rfc/rfc826.txt>.
104
POSTEL, J. Internet protocol (IP). [S.l.], 1981. Disponível em: <https://tools.ietf.org/html/rfc791>.
. Transport control protocol (TCP). [S.l.], 1981. Disponível em: <https://tools.ietf.org/html/rfc793>.
POSTEL, J.; REYNOLDS, J. File transfer protocol (FTP). [S.l.], 1985. Disponível em:<https://tools.ietf.org/html/rfc959>.
PUTNAM, J. R. Architecting with RM-ODP. [S.l.]: Prentice-Hall, Englewood Cliffs.isbn 0-13-019116-7, 2000.
RAZZAQUE, M. A. et al. Middleware for internet of things: A survey. IEEE Internet ofThings Journal, v. 3, n. 1, p. 70–95, February 2016.
RIVERA, J.; MEULEN, R. van der. Gartner says the internet of things installed base willgrow to 26 billion units by 2020. Stamford, conn., December, v. 12, 2013. Disponívelem: <http://www.gartner.com/newsroom/id/2636073>.
ROWLEY, J. The wisdom hierarchy: representations of the dikw hierarchy.Journal of information science, v. 33, n. 2, p. 163–180, 2007. Disponível em:<http://journals.sagepub.com/doi/abs/10.1177/0165551506070706>.
SAINT-ANDRE, P. Extensible messaging and presence protocol (XMPP): Core.2017. Disponível em: <https://xmpp.org/>.
SANTO, K. G. D. et al. A review on smart grids and experiences in brazil. Renewableand Sustainable Energy Reviews, Elsevier BV, v. 52, p. 1072–1082, Dec 2015. ISSN1364-0321. Disponível em: <http://dx.doi.org/10.1016/j.rser.2015.07.182>.
SHAMSZAMAN, Z. U. et al. Woo based user centric energy management systemin the internet of things. In: IEEE. The International Conference on InformationNetworking 2014 (ICOIN2014). [S.l.], 2014. p. 475–480.
SILVA, J. R. et al. Prisma: A publish-subscribe and resource-oriented middleware forwireless sensor networks. In: Proceedings of the Tenth Advanced InternationalConference on Telecommunications, Paris, France. [S.l.: s.n.], 2014. v. 2024, p.87–97.
TOLMASQUIM, M. T. et al. Nota técnica 13/15 - Demanda de energia 2050. [S.l.],2016.
TUBALLA, M. L.; ABUNDO, M. L. A review of the development of smart gridtechnologies. Renewable and Sustainable Energy Reviews, v. 59, p. 710–725,2016.
105
UYSAL, M. P. Towards a software engineering research framework: Extending designscience research. International Research Journal of Engineering and Technology(IRJET), v. 03, n. 02, p. 22–26, Fevereiro 2016.
VERMESAN, O.; FRIESS, P. Digitising the Industry-Internet of Things Connectingthe Physical, Digital and Virtual Worlds. River Publishers, 2016. 364 p. Disponívelem: <http://www.internet-of-things-research.eu/pdf/Digitising_the_Industry_IoT_IERC_2016_Cluster_eBook_978-87-93379-82-4_P_Web.pdf>.
VERSMESAN, O.; FRIESS, P. (Ed.). Building the Hyperconnected Society: IoTResearch and Innovation Value Chains, Ecosystems and Markets. [S.l.]: RiverPublishers, 2015. 331 p.
WIERINGA, R. J. Design Science Methodology for Infomation Systems andSoftware Engineering. 1. ed. [S.l.]: Springer, 2014. 332 p.
ZHENG, L. et al. Research of architecture and application of internet of things for smartgrid. In: IEEE. Computer Science & Service System (CSSS), 2012 InternationalConference on. [S.l.], 2012. p. 938–941.
ZIMMERMANN, H. Osi reference model–the iso model of architecture for opensystems interconnection. IEEE Transactions on communications, v. 28, n. 4, p.425–432, 1980.
107
ANEXO A – COMPARAÇÃO DOS ELEMENTOS DOS MODELOS DE
REFERÊNCIA
Nesta seção estão os modelos intermediários especificados pelo autor. Estes mo-
delos representam o resultado da atividade de comparação da harmonização.
Na Figura 37 está ilustrado a comparação enter os elementos do grupo de domínio
dos modelos de referência. Como os elementos não possuem prefixos, nõa foi cons-
tado nenhuma similaridade entre esses elementos.
108
Figura37
–Resultado
dacomparaçãona
homogeneizaçãodosmodelos
dogrupode
dominio
Fonte:Elaborado
peloautor
109
Na Figura 38 está ilustrado a comparação enter os elementos do grupo funcional
dos modelos de referência. É possível notar os prefixos em comuns entre alguns ele-
mentos denotando a similaridade entre esses elementos. Elementos que não possuem
prefixos são os elementos sem similaridade com quaisquer outros elementos.
110
Figura38
–Resultado
dacomparaçãona
homogeneizaçãodosmodelos
dogrupofuncional
Fonte:Elaborado
peloautor
111
Na Figura 39 está ilustrado a comparação enter os elementos do grupo de informa-
ção dos modelos de referência. É possível notar os prefixos em comuns entre alguns
elementos denotando a similaridade entre esses elementos. Elementos que não pos-
suem prefixos são os elementos sem similaridade com quaisquer outros elementos.
112
Figura39
–Resultado
dacomparaçãona
homogeneizaçãodosmodelos
dogrupode
informacao
Fonte:Elaborado
peloautor
Top Related