4. TYPOLOGIE POSSIBLE DE STATION SATELLITE
4.6 T ECHNOLOGIE DES CANALISATIONS DE LIAISON
De acordo com Changheng-2011, Hernandez-2011, Barbas-2012, a geolocalização dos sensores é fundametal para o refinamento do processo de análise de dados. Neste sentido, um sensor corresponde à uma abstração de qualquer dispositivo capaz de fornecer informações sobre determinado contexto.
53 3.4. REQUISITOS PARA UMA ARQUITETURA DE SOFTWARE PARA CIDADES INTELIGENTES A partir destas informações geográficas dos sensores é possível realizar ações específicas para cada ambienteJAUREGUI-ORTIZ et al.(2012). Esta característica pode ser notada nas abordagens IMSSHAO(2011), USNHERNáNDEZ-MUñOZ et al. (2011) e S3OiA VEGA-
BARBAS et al.(2012). No caso da abordagem IMS, a geolocalização dos sensores é importante
para a investigação do comportamento dos cidadãos; na USN, a localização é considerada um requisito diferenciador; por fim, em S3OiA a localização é utilizada para unificar as ações realizadas sobre um determinado conjunto de sensores.
3.4.8
Composição de Dados Urbanos
Em uma visão sistêmica, ambientes urbanos são essencialmente um conjunto de domínios complexos (como transporte, água, energia elétrica, saneamento básico, etc.) disponibilizados para suprir as necessidades de seus cidadãos. AS’s que se dispõe a dar suporte à esses sistemas devem considerá-los como complementares na busca de um gerenciamento urbano efetivo, ao invés de tratá-los de forma isolada.
Pelo fato de que CI pode ser considerada um sistema de sistemas, a composição dos dados oriundos destes ambientes urbanos deve ser considerada um requisito fundamental.
Estes dados de cada ambiente urbano deve ser disponibilizado de forma que possam ser reutilizados e agrupados para criar uma visão holística e contextualizada da cidade na qual a AS foi implementadaANTHOPOULOS; FITSILIS(2010);NAM; PARDO(2011);PLANIT(2012).
Para atender essa composição de dados urbanos as AS’s Nam’2011NAM; PARDO
(2011), CPAFMOSTASHARI et al.(2011), IMSSHAO(2011), Anthopoulos’2010ANTHO-
POULOS; FITSILIS(2010), Fazio’2012FAZIO et al.(2012) e Living PlanITPLANIT(2012)
implementam explicitamente algum módulo que visa atender este requisito fundamental.
3.4.9
Histórico de dados
No contexto de CI, todos os componentes que compõem cada domínio de uma cidade estão constantemente sendo modificados, seja por eventos humanos, naturais ou tecnológicos. Dessa forma, todo dado captado tem potencial para se tornar uma informação relevante, desde que seja agregado a outros dados.
Estes dados históricos podem ser empregados na predição de eventos futuros, princi- palmente quando houver um grande período sem dados em tempo real. Por exemplo, a partir de informações meterológicas dos anos anteriores é possível prever os meses que poderão ter tempestades. Com informação nessa granularidade é possível adotar providências preventivas para evitar catóstrofres.
Logo, torna-se substancial que as AS’s contemplem mecanismos eficientes de arma- zenamento e consulta desses dados. Como é citado em MB2BLACKSTOCK et al. (2010), SmartSantanderSANCHEZ et al.(2011), EcoCity/ISMP-UCLEE; BAIK; CHOONHWA LEE
54 CAPÍTULO 3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWARE PARA CIDADES INTELIGENTES
(2011) e Living PlanITPLANIT(2012), estas informações historicamente armazenadas potenci- alizarão os resultados obtidos a partir de um algoritmo de contexto e mineração de dados.
3.4.10
Disponibilidade
Para permitir a captação de dados em tempo real e o fornecimento de informações contextualizadas, a AS deve ser altamente disponível, em qualquer dia e horário.
Na literatura existem diversas iniciativas que propõem mecanismos para garantir a dis- ponibilidade da AS. Dentra elas, a mais discutida e utilizada é relacionada à Cloud Computing. Desta forma, caso a infraestrutura de cloud computing seja utilizada, mecanismos de controle de fluxo, colisão e redundância devem ser inerentes à solução.
Nas AS’s SmartSantanderSANCHEZ et al.(2011), USNHERNáNDEZ-MUñOZ et al.
(2011) e Nam’2011 NAM; PARDO (2011), estas situações são tratadas utilizando diversos mecanismos de modularidade em relação a cloud.
3.4.11
Sensoriamento e Processamento Distribuído
Para que sejam propostas soluções para o aumento da eficácia em serviços urbanos é necessário que se façam aferições das características qualitativas ou quantitativas que permeiam esses serviços, bem como do resultado que produzem. É através de sensoriamento que se obtêm a visão computacional do ambiente urbano; quanto maior o número de sensores e mais disperso eles estiverem, maior será o escopo abrangido pela AS.
A heterogeneidade dos sensores utilizados influencia na riqueza de detalhes e na quan- tidade de dados que podem ser extraídos de cada cenário monitorado, sendo possível obter resultados mais precisos. Por exemplo, reports de trânsito em determinada via podem ser melhor analisados se complementados com imagens obtidas através de câmeras instaladas nas redondezas.
Em situações que exigem que medidas preventivas ou corretivas sejam tomadas instanta- neamente exige-se processamento em tempo real, com tempo de resposta rápido o suficiente para fornecer embasamento para ações que devem ser executadas assim que determinada situação é identificada. Considerando quantidades massivas de dados coletados, o suporte à esse tipo de contexto sugere a necessidade de processamento distribuído, explorando a capacidade da infraestrutura existente.
Uma cidade capaz de monitorar todo o ambiente a sua volta, captar dados e gerar informações e conhecimento, permite execução de seus serviços de forma otimizada e um gerenciamento urbano eficiente.
As AS’s que visam atender esse requisito são USNHERNáNDEZ-MUñOZ et al.(2011), SOFIAFILIPPONI et al.(2010), Andreini’2011ANDREINI et al.(2011) e EcoCity/ ISMP-UC
55 3.5. SUMÁRIO DOS REQUISITOS PARA CIDADES INTELIGENTES
3.4.12
Flexibilidade/Extensibilidade
Este requisito corresponde à capacidade da AS adaptar-se à mudanças e extensões. Além da inserção de novos serviços, a AS deve ser capaz de adaptar-se à novos requisitos inerentes ao contexto de implementação. Por exemplo, a AS deve ser independente de padrões específicos de hardware.
Apesar da evidente relevância deste requisito, apenas três AS’s exploram este requisito: Klein’2008KLEIN; KAEFER(2008), MB2BLACKSTOCK et al.(2010) e EcoCity/ISMP-UC
LEE; BAIK; CHOONHWA LEE(2011).
3.5
Sumário dos Requisitos para Cidades Inteligentes
A Tabela 3.4 ilustra um resumo dos requisitos que foram implementados nas AS’s abordadas nesse Capítulo. Nesta tabela, a coluna # representa a quantidade de abordagens encontradas que visam atender ao determinado requisito.
Ao analisar essas informações, pode-se perceber que nenhuma dessas AS’s implementam minimamente todos os requisitos levantados.
Isto deve-se ao fato de que as AS’s geralmente são projetadas para propósitos específicos e cada uma propõe uma solução focada especificamente no problema que pretende resolver.
Além disso, percebe-se que os requisitos de Interoperabilidade de Objetos e Moni- toramento em Tempo Real são os mais abordados pelas AS’s. Esta observação confirma a importância em monitorar constantemente todos os aspectos que envolvem a cidade, processar e disponibilizar os dados coletados rapidamente, a fim de fornecer uma visão de estado do ambiente urbano mais precisa e atualizada para dar suporte às tomadas de decisão em tempo real.
A AS descrita emPLANIT(2012) atende o maior número de requisitos considerados essenciais no contexto desse trabalho. A abordagem de estruturação da AS, cujas camadas apresentam os mesmos princípios de abstração encontrados em sistemas operacionais, garante as mesmas vantagens aos mesmos atribuídas - como abstração e gerenciamento de dispositivos físicos - que aliada à conectividade expande a abrangência de atuação dentro do ambiente urbano, criando um ambiente pervasivo favorável a uma gestão urbana efetiva.
3.6
Discussão do Capítulo
Neste Capítulo foram apresentadas 20 abordagens, em diferentes estágios de validação, oriundas de dois tipos de revisão: Revisão Sistemática e ad hoc. A partir da revisão exploratória foram encontrados trabalhos com investimentos da iniciativa privada e que já se encontram em estágio de prototipação.
Ao término desse Capítulo, pode-se perceber que não há a necessidade da criação de um novo padrão arquitetural ou adaptação de um padrão já existente para o contexto de CI e IoT.
56 CAPÍTULO 3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWARE PARA CIDADES INTELIGENTES
Tabela 3.4: Mapeamento requisitos-arquiteturas
Requisito Abordagens #
Interoperabilidade de objetos SOFIA, USN, EcoCity/ISMP-UC, Living PlanIT, Zygia-
ris’2012, Wu’2011 e S3OiA
7 Monitoramento em tempo
real
Al-Hader’2009, SOFIA, SmartSantander, USN, Asimako- poulou’2011, Attwood’2011 e Living PlanIT
7
Sustentabilidade Klein’2008, EcoCity/ISMP-UC, SmartSantander, Masdar
City e Zygiaris’2012
5
Aspectos sociais Klein’2008, IMS e Asimakopoulou’2011 3
Ubiquidade/Mobilidade SmartSantander, USN, MB2 e Zygiaris’2012 4
Privacidade e Segurança dos dados
SmartSantander, Living PlanIT e Fazio’2012 3
Geolocalização dos Sensores IMS, USN e S3OiA 3
Composição de Dados Urba- nos
Nam’2011, CPAF, IMS, Anthopoulos’2010, Fazio’2012 e Living PlanIT
6
Histórico de dados MB2, SmartSantander, EcoCity/ISMP-UC e Living Pla-
nIT
4
Disponibilidade SmartSantander, USN e Nam’2011 3
Sensoriamento e Processa- mento Distribuído
USN, SOFIA, Andreini’2011 e EcoCity/ISMP-UC 4
Flexibilidade/Extensibilidade Klein’2008, MB2 e EcoCity/ISMP-UC 2
Ainda em relação aos padrões arquiteturais, nota-se que o modelo de arquiteturas em camadas é o mais utilizado, pois permitem o escalonamento de uma AS. Outro padrão bastante empregado pelas AS’s foi o publisher-subscriber, devido, principalmente, as vantagens em utilizá-lo para modelar o ambiente real.
Além disso, pode-se perceber que algumas AS’s foram propostas para finalidades es- pecíficas, como gerenciamento de catastrófes. Apesar disso, essas AS’s possuem mecanismos interessantes de tratamento de eventos em tempo real que devem ser considerados no desenvolvi- mento de qualquer AS para CI.
Apesar dos objetivos comuns destas abordagens, uma coisa é fato: ainda não há um consenso amplamente aceito na literatura sobre quais os requisitos que uma AS deve atender para ser considerada efetiva, independente da forma como foi implementada. A partir das abordagens estudadas, pode-se estabelecer um conjunto de requisitos essenciais ao analisar os principais objetivos das abordagens previamente descritas. Esses requisitos constituem a base para qualquer AS para CI, pois abrangem os princípios definidos para uma CI.
Ao analisar esse conjunto de requisitos, nota-se que nenhuma AS atendeu todos os requisitos. Geralmente, as AS’s são propostas com propósitos específicos e ignoram alguns requisitos essenciais.
Dessa forma, ao propor uma nova AS para CI é de suma importância que ela atenda a maior quantidade desses requisitos, para que uma cidade possa ser de fato considerada inteli- gente. Esses requisitos servirão como pilares para a elaboração da AS para CI que combine as tecnologias de IoT que será descrita nos próximos Capítulos.
57 3.7. CONSIDERAÇÕES FINAIS DO CAPÍTULO
3.7
Considerações Finais do Capítulo
Este Capítulo apresentou algumas abordagens arquiteturais encontradas na litetura. Para tal, dois métodos de revisão da literatura foram utilizados: Revisão Sistemática e ad-hoc.
A Seção 3.1 apresentou a metodologia utilizada durante o processo de revisão sistemática. Posteriormente, os resultados foram apresentados em ordem cronológica.
Por sua vez, a Seção 3.2 apresentou a revisão ad-hoc e os respectivos resultados, ressal- tando, principalmente, o estágio de validação das abordagens encontradas.
Na Seção 3.3 foi realizado uma consolidação das características mais relevantes de cada abordagem. Por fim, a Seção 3.4 apresentou um conjunto de requisitos, extraídos a partir da análise das abordagens, que uma AS para CI deve atender.
Estes requisitos foram utilizados para guiar o desenvolvimento da proposta deste trabalho. Logo, o próximo Capítulo apresenta esta proposta, utilizando um método de descrição arquitetural amplamente discutido na literaturaKRUCHTEN(1995).
59 59 59
4
Uma Arquitetura de Software para Cidades
Inteligentes baseada na Internet das Coisas
Os verdadeiros analfabetos são os que aprenderam a ler e não lêem. —MARIO QUINTANA, 2006 (Caderno H)
Baseado nas demandas de uma AS para Cidade Inteligente (CI) que possibilite a inte- gração de tecnologias IoT e no conjunto de requisitos que foi definido no Capítulo anterior, este Capítulo visa propor uma AS para CI que permita a combinação com tecnologias IoT. O foco da solução proposta consiste em atender um sub-conjunto destes requisitos, bem como prover mecanismos, do ponto de vista de infraestrutura, para que novos requisitos possam ser futuramente incluídos, de acordo com o contexto de cada cidade.
Dessa forma, a Seção 4.1 apresenta este sub-conjunto de requisitos que serão abordados nesta proposta. Já para descrever a proposta detalhadamente é utilizado um método de descrição de AS’s baseado em visões, conhecido como “4+1”, na Seção 4.2.
Em seguida, cada visão abordará aspectos específicos da AS. A Seção 4.3 apresentará a Visão Lógica, a partir de um ponto de vista funcional, relacionando os principais módulos e as operações realizadas com mais frequência. Por sua vez, a Seção 4.4 apresentará a Visão de Execução, com o mapeamento dos componentes lógicos em processos e threads. A Seção 4.5 apresentará a Visão de Implementação, seguido da Seção 4.6 explicitando a Visão Física. Além das visões deste método, duas outras visões definidas pelo SEICLEMENTS(2003) foram utili- zadas para facilitar a compreensão pelos stakeholders: Visão Componente Conector (Seção 4.7) e Visão de Dependências (Seção 4.8).
Por fim, a Seção 4.9 apresentará alguns dos principais cenários de utilização desta AS, do ponto de vista de orgãos governamentais e não-governamentais, cidadãos e desenvolvedores. Finalmente, a Seção 4.10 consolida as principais características da AS proposta discutidas
60CAPÍTULO 4. UMA ARQUITETURA DE SOFTWARE PARA CIDADES INTELIGENTES BASEADA NA INTERNET DAS COISAS
neste Capítulo e a Seção 4.11 finaliza o Capítulo.
4.1
Requisitos abordados
A partir da descrição dos requisitos realizada no Capítulo anterior, um sub-conjunto de requisitos foi selecionado para ser abordado nesta proposta de AS. A Tabela 4.1 exibe todos os requisitos e indica quais destes foram abordados nesta proposta, ordenados pela quantidade de abordagens encontradas que visam atender o determinado requisito, conforme ilustrado na coluna #.
Tabela 4.1: Requisitos abordados
Requisito Abordado #
Interoperabilidade de objetos Sim 7
Monitoramento em tempo real Sim 7
Composição de Dados urbanos Sim 6
Sustentabilidade Não 5
Histórico de dados Sim 4
Ubiquidade/Mobilidade Sim 4
Sensoriamento e Processamento Distribuído Sim 4
Geolocalização dos Sensores Sim 3
Privacidade e Segurança dos dados Não 3
Aspectos sociais Não 3
Disponibilidade Não 3
Flexibilidade/Extensibilidade Sim 2
Ao analisar a Tabela 4.1, percebe-se que do total de 12, apenas 4 não foram incluídos nesta proposta e 8 foram incluídos. Para realizar essa priorização, dois fatores foram ponderados: i) a importância/relevância do requisito, inferida a partir da quantidade de abordagens na literatura que visam satisfazer esse requisito, conforme pode ser observado na coluna “#”; e ii) este conjunto de requisitos foi incluído nesta proposta são os requisitos mínimos que toda AS de software para CI deve atender.
Os demais requisitos que, mesmo considerados importantes/relevantes, não foram abor- dados nesta proposta, dificilmente podem ser abordados nesta proposta no estágio atual. A saber:
Sustentabilidade: A proposta atual não possui nenhuma parceria com instituições governamentais. Logo, nas 5 abordagens na qual esta requisito foi encontrado, todas possuíam uma parceria com as prefeituras locais, que criavam campanhas para incentivar o consumo consciente dos cidadãos.
Privacidade e Segurança dos dados: De fato, esta necessidade foi identificada no começo desta pesquisa, porém um outro trabalho de mestrado está sendo desenvolvido com este escopo. Este trabalho de privacidade será acoplado à esta proposta assim que finalizado. Para isso, as definições de interfaces e padrões de mensagens estão sendo definidas em conjunto. O escopo deste trabalho de privacidade é criar um
61 4.2. METODOLOGIA “4+1” mecanismo em que, a partir das interações anteriores, os cidadãos possam “negociar” o quão seus dados estarão disponíveis para um determinado provedor de serviço urbano.
Aspectos sociais: Da mesma forma que o requisito de Sustenabilidade, para que a AS atenda ao requisito de Aspectos Sociais é necessário o estabelecimento de parcerias com as instituições governamentais para de fato incluir os cidadãos como parte do sistema de uma CI.
Disponibilidade: O requisito de Disponibilidade está relacionado à infraestrutura na qual esta proposta estará sendo executada.
4.2
Metodologia “4+1”
A Arquitetura de Software (AS) tem desempenhado um papel fundamental no desenvol- vimento de sistemas de software. Ela oferece um maior entendimento da aplicação por dividi-la em um conjunto de componentes que interagem entre si para realizar parte de uma ou várias funcionalidades do sistemaGARLAN; SHAW(1994).
Porém, diversos autores relatam a falta de eficiência em documentar essas AS’s para que sejam legíveis para os mais variados stakeholdersGARLAN; SHAW(1994);CLEMENTS
(2003). Visando atender essa ineficiência, em Kruchten:1995:VMA:624610.625529 é proposto um método de descrição de AS’s baseado em visões chamado “4+1”. Para facilitar a compreensão pelos stakeholders, duas outras visões definidas pelo SEICLEMENTS(2003) foram utilizadas: Visão Componente Conector e Visão de Dependências. A integração dessas visões é ilustrada na Figura ??.
file = images/promodelo.pd f , width = 10cm
Figura 4.1: Integração das visões do modelo “4+1” com as visões definidas pelo SEI
Este uso de múltiplas visões permite abordar separadamente as preocupações de vários stakeholders da AS: usuários finais, desenvolvedores, engenheiros de sistemas, gerentes de projetos, entre outros; e permite avaliar separadamente os requisitos funcionais e não funcionais. Estas visões abordam aspectos de relevância arquiteturais sob diferentes perspectivas:
A visão lógica aborda os elementos significativos do projeto para a AS adotada e a relação entre eles. Entre os principais elementos estão os módulos, os componentes, os pacotes e as classes principais de aplicação;
A visão de execução relata os aspectos de concorrência e sincronização do sistema, mapeando os elementos da visão lógica de processos, threads e tarefas de execução;
62CAPÍTULO 4. UMA ARQUITETURA DE SOFTWARE PARA CIDADES INTELIGENTES BASEADA NA INTERNET DAS COISAS
A visão de implementação centra-se em aspectos relacionados com a organização do código-fonte do sistema, padrões de AS utilizada e as orientações e as normas para o desenvolvimento do sistema;
A visão física demonstra as configurações de hardware e o mapeamento dos elemen- tos de software para os elementos de hardware no ambiente do sistema;
A visão componente conector se refere ao comportamento dos componentes em tempo de execução e seus conectores, que são responsáveis pela comunicação entre estes;
A visão dependências ilustra as dependências existentes entre os módulos da AS ;
Os cenários mostram um subconjunto dos casos de uso significativo da AS.
No contexto de CI, diferentes stakeholders são envolvidos no processo de criação de uma solução eficiente, por exemplo, prefeito, secretarias públicas, desenvolvedores e cidadãos. Logo, o método “4+1” foi escolhido e duas visões foram adicionadas para descrever esta proposta arquitetural justamente para contribuir no entendimento por estes diferentes stakeholders.
4.3
Visão Lógica
Esta Seção demonstra a organização da AS a partir de um ponto de vista funcional. Os principais elementos, como módulos e componentes principais são especificados. A interface entre estes elementos também é especificada. A Figura 4.2 ilustra a arquitetura do ponto de vista lógico.
As subseções seguintes explicitarão cada módulo, ressaltando sua responsabilidade e os requisitos funcionais atendidos.
4.3.1
Módulo de Acesso e Comunicação (MAC)
O Módulo de Acesso e Comunicação (MAC) representa o ponto de entrada para as aplicações e serviços externos. O MAC provê os mecanismos necessários para o acesso e a comunicação com a AS, a partir da interface REST (Representational state transfer).
De acordo com MB2-2010 e Hernandez-2011, utilizar uma interface padronizada, como REST, é uma das técnicas empregadas para tornar a AS compatível com as tecnologias mó- veis, como totens, smartphones e tablets. Esta decisão arquitetural permite que a AS torna-se compatível com o requisito de ubiquidade/mobilidade.
Além disso, de acordo com MB2-2010 e Filipponi-2010, a principal estratégia para que uma AS contemple a interoperabilidade de objetos é permitir a comunicação com dispositivos e sistemas através de diferentes protocolos de troca de mensagens. Para tal, o MAC contém
63 4.3. VISÃO LÓGICA
Registro de recursos Configuração de recursos
Driver BD1 BD1 BD2 BD3 DHT-BD Driver BD2 ...
Interface: Banco de Dados
Módulo de Acesso e Comunicação (MAC) Módulo de Gerenciamento de Recursos (MGR) Módulo de Gerenciamento e Distribuição de Dados (MGDD) Módulo de Persistência de Dados (MPD) DHT - Canal de dados P P ... C C ... Canal 2 P P ... C C ... .... Canal 3 P P ... C C ... Canal 1 Driver BD3 REST
Interface: Protocolos de troca de mensagens
Figura 4.2: Visão lógica da Arquitetura de Software (AS) proposta
uma interface padronizada que permite a inserção de novos adaptadores que implementam os diferentes protocolos de troca de mensagem sob demanda.
O funcionamento do MAC consiste em receber cada requisição dos diferentes recursos e encaminhá-las para os demais módulos. Para isso, o MAC oferece todos os operações para interagir com a AS, por exemplo, operações responsáveis pelo Registro de Recursos, como será detalhado na seção a seguir. De acordo com a operação do método, este delega ação para o respectivo módulo.