A criação de uma descrição mais refinada para os dispositivos foi realizada para soluci- onar o problema de particularidades dos ambientes onde o Smart Place iria ser instalado, como quantidade de aparelhos de ar condicionados, modelo e modo em que o sistema iria atuar com tomada de decisões especificas. Essa descrição acabou se estendendo e en-
43 globando também a lógica de decisões do sistema, que relaciona, por exemplo, em que situação o aparelho de ar condicionado deve ser ligado ou desligado, o período de consulta dos sensores e os fluxos de execuções paralelos ou sequenciais.
Nas subseções a seguir será explicado em nível de software como ocorre a relação entre os Agentes Master e Slave, apresentando a arquitetura do sistema que executa na Raspberry Pi e que, por meio dessa configuração de entrada, cria uma política de atuação específica para cada ambiente.
4.3.1 Arquitetura
Os Agentes Master e Slave são importantes em situações em que somente um dis- positivo não consegue mapear os recursos de todo o ambiente em que foi instalado. No entanto, esse cenário não é comum e só foi realizado em uma única sala na implantação do Smart Place em salas da UFRN. Devido a isso, a configuração dos dispositivos é aplicada somente ao Raspberry, que recebe por padrão o papel de Agente Master.
A arquitetura que suporta a criação de uma política própria para cada dispositivo é apresentada na Figura 15 de forma simplificada. O Diagrama UML de Classes apresentado representa o sistema desenvolvido em Python (versão 3.7).
Figura 15: Arquitetura de software no dispositivo
O sistema executa a classe Main, que por sua vez, instancia um objeto da classe Set- tingsSetup, que é a classe responsável por ler e interpretar a descrição da configuração do dispositivo. Após essa primeira etapa, a classe Main instancia um objeto da classe Coodi- nator, passando a configuração como parâmetro. Logo, nesse momento, é feito um link de
44 métodos especificados na configuração com métodos definidos na classe MethodsMapping; nesse link cada método é associado a uma Task. Ainda no construtor de Coodinator, é defi- nida a política de controle modelada por Policy e são construídos os sensores, atuadores e recursos que também são descritos no arquivo de configuração. Após as operações realiza- das na instanciação do Coodinator, a classe Main executa o método start em Coodinator, que por consequência inicia o serviço do Smart Place.
Iniciar o serviço representa executar a política do agente, no qual é dado start em cada Flow da lista flows de Policy, e cada um dos fluxos é executado de forma concorrente em diferentes threads. Esse processo é ilustrado no Algoritmo 1.
Algoritmo 1: PolicyStartFlows
1 início
2 para cada (flow em policy.flows) faça 3 Thread(runFlow()).start()
4 fim 5 fim
Cada um dos fluxos pode ser descrito para ser executados de forma contínua (durante a vida útil do serviço) ou uma única vez. Isso é importante para, por exemplo, executar um fluxo contínuo de leitura dos sensores ou para se comunicar com um sistema externo, ou um fluxo executado apenas uma vez para configurar o dispositivo. No Algoritmo 2 é apresentado esse trecho de execução da política, que é acionado logo após a execução do Algoritmo 1. Nesse processo, cada Action da lista actions é executada por meio do método run e caso a variável continuos_loop seja verdadeira, as listas de ações são repetidas até a interrupção do serviço do Smart Place.
Algoritmo 2: RunFlow
1 início 2 repita
3 para cada (action em flow.actions) faça
4 action.run()
5 fim
6 até (continuos_loop); 7 fim
Quando as ações são iniciadas, é percorrida uma lista de Action, cada uma possuindo uma lista de conditions, tasks e final_tasks, que são instâncias de Task. É então realizada uma verificação das conditions e, caso o retorno seja verdadeiro, as tasks são executadas. As final_tasks são sempre executadas ao final, independente do resultado das conditions.
45 Esse processo é apresentado no Algoritmo 3.
Algoritmo 3: RunAction
1 início
2 result = True . Resultado das condições
3 para cada (disj_conditions em conditions) faça 4 result = True
5 para cada (condition em disj_conditions) faça 6 result = condition.run() and result
7 if (result) then
8 break
9 fim 10 fim
11 .Verifica o resultado das condições para executar as tasks
12 if (result) then
13 para cada (task em self.tasks) faça
14 task.run()
15 fim 16 end
17 . Executa as final_tasks
18 para cada (task em final_tasks) faça 19 task.run()
20 fim 21 fim
4.3.2 Metodologia de descrição da configuração
A configuração do dispositivo se dá pela descrição dos seus recursos, sensores, atuado- res e de sua política, que representa as ações realizadas sobre esses recursos por meio dos sensores e atuadores e outros métodos que sejam configurados. Isso é realizado criando- se um arquivo de configuração no formato YAML, que foi adotado pela simplicidade da sintaxe, em comparação com outros formatos, como JSON ou XML.
Nesse arquivo são inseridas palavras chave especificas, chamadas de tokens. Ao ser iniciado o serviço do Smart Place na Raspberry Pi, esse arquivo é passado como argumento e interpretado usando a biblioteca PyYAML. A descrição ditará o comportamento do sistema. Cada sala onde o dispositivo é instalado possui seu próprio arquivo de descrição. Ao menos os identificadores dos sensores, atuadores e recursos, bem como a descrição do local serão diferentes de um lugar para outro. Na Tabela 3 é apresentada uma listagem dos principais tokens utilizados no arquivo de configuração.
46 Tabela 3: Mapeamento dos tokens de configuração
Token Descrição
local Descrição do local de instalação fiware Configurações do FIWARE agents Listagens dos Agentes
role Papel do Agente em master ou slave resources Lista de Recursos que serão controlados sensors Lista de Sensores
actuators Lista de Atuadores policy Definição da Política
args Variáveis globais para uso na descrição
flows Lista de fluxos concorrentes que serão executados loop_option Opção para determinar se fluxo será contínuo actions Lista de Ações executadas no fluxo
conditions Condições para tarefas sejam executadas nas ações tasks Tarefas executadas dentro da ação
final_tasks Tarefas executadas ao final da ação, independente das condições descrição de atuadores e sensores de um dispositivo. O token actuators indica uma lista de atuadores e cada item da lista possui um identificador (id), tipo do componente (type) e meio de conexão do atuador com a Raspberry (interface), que na figura se trata de uma porta GPIO. Já os sensores possuem o atributo model de diferencial em relação aos atuadores, pois existem vários modelos para o mesmo tipo de sensor, como é o caso de DHT11 e DHT22, ambos sensores de temperatura. É importante destacar que o atributo type é determinante na implementação da classe específica tanto para sensores como para atuadores.
(a) Atuadores (b) Sensores
Figura 16: Descrição de atuadores e sensores dos agentes
Configuradas essas estruturas, a política irá moldar o comportamento do dispositivo. Os fluxos concorrentes e as ações internas são organizadas de forma hierárquica, seguindo
47 o Diagrama de Classes apresentado na Figura 15. O ponto mais complexo dessa descrição são as ações, como mostrado na Figura 17.
Figura 17: Ações de um fluxo para Ligar e desligar um ar condicionado
As ações de um fluxo específico são listadas para serem executadas em ordem. No exemplo é mostrada a ação de ligar e desligar um aparelho de ar condicionado. As tare- fas (tasks) envolvidas na ação de ligar são CHANGE_STATE e SYNC_REQUEST e é passado um conjunto de argumentos para cada tarefa. No entanto, para que as tarefas sejam executadas são verificadas as condições (conditions). Para ligar o ar condicionado é feita uma conjunção se existe movimento detectado pelo sensor (vm), se o estado do aparelho é OFF (vs) e se existe reserva para o intervalo de 15 minutos (ir). Caso a pri- meira conjunção não seja verdadeira, é realizada uma segunda conjunção das condições da câmera ter detectado pessoas (hpd), o estado do aparelho ser OFF (vs) e do dia (nd) e horários serem normais (nt). Uma representação lógica da verificação das condições de ligar o aparelho seria:
(vm^ vs ^ ir) _ (hpd ^ vs ^ nd ^ nt)