Restrições são regras que caracterizam um estilo arquitetural e devem ser satisfeitas antes, durante e depois da execução de uma arquitetura concreta. A Tabela 10 apresenta as restrições do estilo IoT proposto. Essas restrições foram elaboradas com base na observação de sistemas de IoT gerais (SANTOS et al., 2019) (CROES, 2015) e na norma ISO/IEC 30141 (ISO/IEC, 2018). Se uma determinada restrição for violada, a arquitetura concreta não implementará o estilo IoT corretamente.
As restrições foram classificadas em três categorias:
(i) Comportamento, que indica o comportamento básico de um sistema de IoT; (ii) Comunicação, que indica como os componentes devem ou não se comunicar; e (iii) Cardinalidade de conectores, que indica quantidade de bindings de conectores.
Tabela 10: Restrições do estilo IoT
Categoria ID Restrição
Comportamento
C1 Deve existir pelo menos uma atividade de cada tipo: Monitoring, Analysis, Planning e Execution.
C2 A execução das atividades que implementam atividades abstratas deve seguir a seguinte ordem: Monitoring, Analysis, Planning e Execution.
C3 A atividade Monitoring deve ser implementada por uma atividade que esteja associada a um componente do tipo Sensor.
Comunicação
C4 Componentes Controller devem ser embutidos no Device.
C5 Componentes Sensor devem ser conectados a componentes Device ou Controller. C6 Componentes Actuator devem ser conectados a componentes Device ou Controller. C7 Componentes dos tipos Sensor e Actuator não se comunicam diretamente.
Cardinalidade de Conectores
C8 Conectores do tipo SensorData devem possuir apenas uma origem e um destino. C9 Conectores do tipo ActuatorCommand devem possuir apenas uma origem e um
destino.
C10 Conectores do tipo DeviceData devem possuir apenas uma origem e um destino.
Além das restrições listadas na Tabela 10, as cardinalidades dos componentes e portas do estilo IoT também impõem restrições. Em relação à cardinalidade de componentes, um sistema IoT deve ter pelo menos um Sensor para recuperar informações do ambiente e pelo menos um Device para ler os dados de sensores e enviar comandos para os atuadores. Controllers podem estar presentes ou não, isto é, se existir pelo menos um sensor e/ou atuador dentro de um dispositivo, este dispositivo irá conter um Controller. Devido ao grande volume de dados existente nos sistemas de IoT, deve haver pelo menos um DataStore no sistema. Dependendo do domínio da aplicação, Actuators e Gateways podem estar presentes ou não nos sistemas de IoT.
Por exemplo, no caso do sistema de sensor corporal, detalhado na Seção 5.2, que monitora alguns parâmetros de saúde do usuário através de uma pulseira e se comunica com um smartphone para exibir os dados monitorados, Actuators e Gateways não são necessários. No sistema Smart Place, detalhado na Seção 5.1, que controla automaticamente a temperatura em prédios inteligentes, existe a necessidade de uma intervenção no ambiente desempenhada pelo atuador, além de existir um Gateway que se comunica com o Device.
As restrições de comportamento baseiam-se no modelo MAPE-K (KEPHART; CHESS, 2003), um dos modelos mais utilizados para realizar sistemas autônomos (KÜHN; HELLBRÜCK; FISCHER, 2018), que também tem sido adaptado para ambientes de IoT
(GURGEN et al., 2013) (NGUYEN et al., 2015). O modelo MAPE-K descreve quatro fases (monitoring, analysis, planning e execution) em um loop, além de uma base de conhecimento (knowledge), conforme ilustrado na Figura 33.
Figura 33: Loop Mape-K (BELHAJ; BELAÏD; MUKHTAR, 2017)
No estilo IoT, estas quatro fases são representadas por atividades abstratas. A atividade Monitoring representa o comportamento dos sensores na coleta dos dados de contexto. Com base nestes dados, a atividade Analysis realiza todo o raciocínio necessário para verificar se há necessidade de realizar alguma ação. Em caso positivo, a atividade Planning planejará a ação, que será executada pela atividade Execution.
As restrições indicam a necessidade de todas as atividades abstratas serem referenciadas na arquitetura concreta, explicitam a ordem de execução das atividades, além de restringir os tipos de atividades que podem implementar a atividade abstrata Monitoring. As atividades Analysis, Planning e Execution podem ser implementadas por qualquer atividade definida no BDD comportamental da arquitetura concreta baseada do estilo IoT, enquanto a atividade Monitoring só pode ser implementada por atividades associadas a componentes do tipo SensorCP. Vale salientar que uma atividade da arquitetura concreta pode implementar mais de uma atividade abstrata e que uma atividade abstrata pode ser associada a mais de um componente da arquitetura concreta.
Sobre restrições de comunicação, em sistemas de IoT Sensors normalmente não se comunicam diretamente com Actuators, mas através de Devices. Devices podem se comunicar diretamente uns com os outros ou usar um Gateway como mediador.
Por exemplo, no caso do sistema de sensor corporal, a pulseira e o smartphone são dispositivos que se comunicam diretamente. Por outro lado, em cenários que conectam uma
grande quantidade de dispositivos heterogêneos, onde a interoperabilidade é um requisito importante, como, por exemplo, em uma casa inteligente, os dispositivos podem ser conectados a um gateway, que funcionará como um ponto central para toda a comunicação dentro de uma certa proximidade (CROES, 2015). Este é o caso do sistema Smart Home, detalhado na Seção 5.3.
As restrições de cardinalidade dos conectores determinam que devem existir canais de comunicação individuais para cada Sensor, Actuator e Device no sistema. Esta decisão tem o objetivo de favorecer a escalabilidade dos sistemas de IoT, evitando gargalos causados por canais compartilhados.
4.2
Estilo IoT e a Norma ISO/IEC 30141
A Figura 34 associa entidades do modelo conceitual definido na norma ISO/IEC 30141 (ISO/IEC, 2018) a elementos do estilo IoT. As entidades Sensor, Actuator, Data Store e IoT Gateway correspondem, respectivamente, aos componentes Sensor, Actuator, DataStore, Gateway. A entidade Service corresponde às portas de entrada e saída de serviços.
Figura 34: Relações entre as entidades do modelo conceitual definido na norma ISO/IEC 30141 e os elementos do estilo IoT
Vale salientar que a entidade IoT Device não corresponde ao componente Device do estilo IoT, uma vez que IoT Device representa uma generalização de Sensor e Actuator no modelo conceitual (Figura 15), enquanto no estilo IoT tanto Device, quanto Sensor e Actuator são componentes independentes, de forma que sensores e atuadores podem ser conectados ou embutidos em um dispositivo. Isso não fere o modelo conceitual, apenas incrementa o nível de detalhamento.
O termo IoT envolve dois elementos chaves: Internet e Coisas. Na norma ISO/IEC 30141 esses elementos são representados, respectivamente, pelas entidades Network e PhysicalEntity. No estilo IoT, a Internet é representada pelos componentes Gateway, que consiste em um meio de conectar dispositivos a uma rede de longa distância, e pelo componente Device, que pode possuir uma conexão direta com a internet. As coisas são representadas pelos componentes Device, Sensor e Actuator.
Os elementos do estilo IoT relacionam-se com quatro das cinco visões da arquitetura de referência proposta pela norma ISO/IEC 30141. Basicamente, os elementos do estilo IoT desempenham papéis que correspondem aos elementos que compõem as camadas Sensing & Controlling e Application Service das visões funcional, de sistema, de comunicação e de informação da arquitetura de referência. A visão de uso não possui relação com os elementos do estilo IoT, uma vez que esta visão representa apenas os papéis e atividades desempenhadas pelos usuários do sistema e, portanto, está fora do escopo do estilo proposto.
A Figura 35 apresenta a visão funcional, destacando duas camadas: (i) Sensing & Controlling Domain e (ii) Application Service Domain. A camada Sensing & Controlling Domain possui elementos responsáveis pela (i) coleta dos dados providos por sensores (função dos componentes Device e Controller do estilo IoT), (ii) análise dos dados e decisões sobre atuação (função que pode ser realizada pelos componentes Device, Controller ou Gateway do estilo IoT e pode envolver o componente DataStore) e (iii) envio de comandos de atuação (função dos componentes Device e Controller do estilo IoT). A camada Application Service Domain representa a coleção de funções que implementam a lógica da aplicação e que realizam funcionalidades de negócio específicas para os provedores de serviços. Estas funcionalidades estão associadas às portas de entrada e saída de serviços do estilo IoT e podem envolver os componentes Gateway, Device e DataStoreCP.
Figura 35: Visão funcional da arquitetura de referência definida na norma ISO/IEC 30141 e as camadas relacionadas ao estilo IoT (Adaptado de ISO/IEC (2018))
A Figura 36 apresenta a visão de sistema, destacando duas camadas: (i) Sensing & Controlling Domain e (ii) Application Service Domain. A camada Sensing & Controlling Domain inclui os elementos (i) Sensor, responsável por recuperar informações do ambiente, assim como o componente Sensor do estilo IoT, (ii) Actuator, responsável por atuar no ambiente, assim como o componente Actuator do estilo IoT e (iii) IoT Gateway, responsável por funções como conversão de protocolo, mapeamento de endereços, processamento de dados, fusão de informações, certificação e gerenciamento de equipamentos, assim como o componente Gateway do estilo IoT. A camada Application Service Domain inclui um componente Business Service System, responsável por funções comerciais, e um componente Basic Service System, que fornece serviços de dados como acesso a dados, processamento de dados, fusão de dados, armazenamento de dados, etc. Ambos os sistemas atuam provendo e consumindo serviços, logo, estão associados às portas de entrada e saída de serviços do estilo IoT e podem envolver o componente DataStore na função de armazenamento de dados.
A visão de comunicação destaca as principais redes de comunicação envolvidas nos sistemas de IoT e as entidades com as quais elas se conectam. Dessa forma, esta visão se relaciona com o estilo IoT apenas indicando qual o tipo de rede utilizada pelas entidades representadas no estilo IoT. A Figura 37 apresenta a visão de comunicação, destacando duas camadas: (i) Sensing & Controlling e (ii) Application Service. A camada Sensing & Controlling utiliza duas redes de comunicação: (i) Rede de Proximidade, para conectar Sensores e Atuatores
ao Gateway e (ii) Rede de Acesso, para conectar Gateways. A camada Application Service utiliza a Rede de Serviços, que conecta aplicações e serviços.
Figura 36: Visão de sistema da arquitetura de referência definida na norma ISO/IEC 30141 e as camadas relacionadas ao estilo IoT (Adaptado de ISO/IEC (2018))
Figura 37: Visão de comunicação da arquitetura de referência definida na norma ISO/IEC 30141 e as camadas relacionadas ao estilo IoT (Adaptado de ISO/IEC (2018))
A Figura 38 apresenta a visão de informação, destacando duas camadas: (i) Sensing & Controlling e (ii) Application Service. A camada Sensing & Controlling representa os dados produzidos pelos Sensors, Actuators e IoT Gateways, que correspondem aos dados enviados e recebidos pelas portas dos componentes Sensor, Actuator e Gateway do estilo IoT. A camada Application Service representa dados de serviços, que correspondem aos dados enviados e recebidos pelas portas de serviços do estilo IoT.
Figura 38: Visão de informação da arquitetura de referência definida na norma ISO/IEC 30141 e as camadas relacionadas ao estilo IoT (Adaptado de ISO/IEC (2018))
É natural que os elementos do estilo IoT não abordem todos os elementos tratados pela arquitetura de referência, uma vez que arquiteturas de referência são mais detalhistas em termos de componentes, enquanto estilos arquiteturais são mais abstratos. Por outro lado, estilos arquiteturais possuem não só um conjunto de componentes e conectores pré-definidos, como também um conjunto de restrições sobre as possíveis interações entre os elementos. Dessa forma, podemos concluir que arquiteturas de referência e estilos arquiteturais possuem diferentes finalidade e são complementares.
No cenário da IoT, a possibilidade de utilizar um estilo e uma arquitetura de referência para IoT oferece ao arquiteto um conjunto de decisões arquiteturais pré-definidas e validadas que podem ser aplicadas a diferentes domínios. Isso pode se refletir na redução da complexidade que envolve a modelagem arquitetural de sistemas de IoT, além de melhorar a consistência e a clareza das especificações arquiteturais pelo fato de estar seguindo soluções padronizadas.
4.3
Estilo IoT em SysADL
A Figura 39 mostra um IBD SysADL representando um exemplo genérico de uma arquitetura que segue o estilo IoT proposto. O componente DeviceCP pode receber dados de componentes SensorCP. O componente ControllerCP também pode receber dados a partir de componentes SensorCP internos ao DeviceCP. O componente ControllerCP pode enviar comandos para os componentes ActuatorCP internos e o DeviceCP pode enviar comandos para
os componentes ActuatorCP externos. O componente DeviceCP pode enviar e receber dados de componentes GatewayCP. Vale salientar que este é apenas um exemplo para ilustrar uma possível configuração de componentes e conectores seguindo o estilo IoT.
A seguir detalhamos as visões estrutural (Seção 4.3.1) e comportamental (Seção 4.3.2) do estilo IoT em SysADL, além de demonstrar como utilizar o estilo IoT na ferramenta SysADL Studio (Seção 4.3.3).
Figura 39: IBD SysADL com exemplo genérico de arquitetura baseada no estilo IoT