Prova de conceito

A prova de conceito modelada com a DSL intermediária foi extraída de um importante domínio de aplicação de RSASF: monitoramento da saúde de estruturas civis (Structural Health Monitoring - SHM) [CHINTALAPUDI, 2006].

5.1.1.1. Structural Health Monitoring

O objetivo das aplicações de monitoramento da saúde estrutural (SHM) é detectar e localizar danos em estruturas civis, como prédios, pontes, dentre outras. Todas as estruturas reagem a vibrações, forçadas ou causadas pelo ambiente (naturais). Vibrações naturais podem ser geradas por terremotos, ventos, veículos em movimento, ondas, entre outros, enquanto vibrações forçadas são geradas por shakers e outros dispositivos. Há várias propostas de

89

algoritmos para realizar detecção e localização de danos em estruturas. A prova de conceito do presente trabalho foi baseada em [CHINTALAPUDI, 2006], onde são apresentados dois algoritmos para SHM. O primeiro trata da localização e o segundo da detecção de danos. Nesta prova de conceito, apenas o algoritmo de detecção de danos é analisado, cujo objetivo é detectar a presença de danos em um edifício usando (i) acelerômetros capazes de detectar variações no comportamento da estrutura, e (ii) um computador externo ao processo de detecção dados; e determinar a existência de danos estruturais. Para a execução com sucesso, desse algoritmo, são necessários no mínimo trinta nós sensores, a serem dispostos em cada andar do edifício monitorado, para obter dados com a precisão necessária para detectar qualquer anormalidade. O algoritmo de detecção funciona da seguinte forma: inicialmente, os sensores coletam a assinatura inicial da estrutura monitorada e enviam essa informação para o nó coletor (sink) conectado a um computador. Essa leitura inicial consiste na assinatura de uma estrutura "saudável" (não danificada) e é usada para fins de comparação com as medições posteriores dos sensores. Em uma segunda fase, o sink calcula um conjunto de funções (como detalhado em [CHINTALAPUDI, 2006]) e armazena os resultados para cada assinatura da estrutura, centralizando as funções que necessitam de um maior processamento em um computador e não em cada nó sensor. A assinatura de uma estrutura é obtida após ter sido efetuada a coleta dos sinais de aceleração pelos sensores e representa a resposta vibracional da estrutura a estímulos recebidos. Após a coleta, é aplicada uma Transformada Rápida de Fourier (FFT) no sinal de aceleração coletado. A seguir, usa-se um método para extração dos valores de frequência dos picos do espectro de frequência gerado pela FFT. Esses valores de frequências dos picos são as frequências respectivas aos modos de vibração da estrutura. Os valores de frequências obtidas em cada sensor, considerando a taxa de amostragem utilizada, referem-se aos primeiros picos do espectro de frequência retornado pela FFT, e vão compor a chamada assinatura da estrutura.

90

Vários tipos de hardware de sensores fornecem as funcionalidades necessárias para uma aplicação de SHM. Nesta prova de conceito é desenvolvida uma aplicação para rodar em nós sensores Sun Spot ([Sun SPOT, 2012]), com a seguinte configuração: nós Sun SPOT modelo MPR 2400, que operam com rádio IEEE 802.15.4, associados a placas de sensoriamento com acelerômetro de 3 eixos. O hardware do nó sink (ou estação base) é desconectado das placas de sensoriamento e conectado a um computador pessoal através de um cabo USB, usando uma porta USB padrão. O computador pessoal receberá os dados coletados pelos nós sensores e aplicará o algoritmo de detecção de danos.

5.1.1.2. Modelagem da aplicação SHM

A modelagem de aplicações para RSASF com a DSL intermediária segue os mesmos passos que são utilizados por LWiSSy e que foram detalhados na Seção 4.4. No entanto, neste caso, a atividade “Modelar sistema com LWiSSy” será efetuada com o auxílio do metamodelo da DSL intermediária ao invés do metamodelo de LWiSSy, o que ocasionará a produção de modelos PIM da DSL intermediária. Além disso, as regras de transformação M2M utilizadas são aquelas definidas em [RODRIGUES, 2011]. Os demais passos do ciclo de desenvolvimento são executados da mesma forma para ambas as DSLs. Esta característica já permite-nos visualizar que a adoção deste ciclo de desenvolvimento de sistemas para RSASF possibilita o reuso de diversos artefatos, o que pode facilitar o desenvolvimento e a manutenção destes sistemas.

De acordo com o processo utilizado, a primeira atividade tem com o objetivo a produção do modelo CIM. Como já mencionado anteriormente, a modelagem deste modelo não faz parte do escopo deste trabalho. Logo após, o especialista de domínio inicia a modelagem da aplicação utilizando a DSL intermediária e o modelo CIM. Em paralelo a esta atividade, o especialista de redes analisa o CIM e escolhe qual plataforma de RSASF melhor se adapta aos requisitos da

91

aplicação-alvo. Como já detalhado na Seção anterior, a plataforma Sun SPOT é utilizada.

A modelagem da aplicação SHM pode ser visualizada na Figura 5-1. Nela observa-se que duas a aplicação é composta por duas regiões (downtier e uptier) e três tipos de nós: floor1, o qual é composto por acelerômetros; SinkNode, o qual possui uma porta USB e Shaker, composto por um atuador.

A primeira região, downtier, é dividida em um grupo de nós (Damage_detection_1), o qual, por sua vez, apresenta um único fluxo comportamental definido em Collects_building_data.

92

O fluxo comportamental Collects_building_data pode ser visto como uma máquina de estados, onde os estados são representados pelas unidades funcionais (FunctionalUnit, RadioConfigUnit, LedsUnit, TimerUnit, AggregationUnit e DataDeliveryUnit) e as transições podem ser vistas como os UnitLinks, os quais efetuam as conexões entre as unidades funcionais. Dessa

forma, este fluxo comportamental pode ser descrito da seguinte maneira: os nós do grupo são ligados (startSensing); os rádios pertencentes a estes nós são configurados (configRadioSensing); os LEDs vermelhos dos nós são acesos (redLight); os acelerômetros dos nós são calibrados (calibrate); a aplicação fica em stand by durante 22 segundos (timer22s); os atuadores são disparados (actuator); mais uma vez a aplicação entra no modo stand by por 20 segundos; os LEDs amarelos dos nós são acesos (yellowLightOn); os nós coletam dados dos acelerômetros (getSamples); a agregação dos dados coletados pelos nós é efetuada (getAverage); os LEDs amarelos dos nós são desligados (yellowLightOff); os dados coletados e agregados são enviados ao nó sink (sendData) e, por fim, a aplicação permanece no modo stand by por 24 horas antes que o processo comece novamente.

Enquanto isso, o fluxo comportamental (getData) modelado para o grupo de nós (sinkNode) da segunda região (uptier) funciona como segue: o nó sink é ligado (startSink); o seu rádio é configurado (configRadio); o nó fica esperando que dados sejam enviados para ele (receiveData) e, quando isso ocorre, ele os envia para um computador (storeData) por meio de uma porta USB.

Feito isto, os especialistas devem efetuar as atividades posteriores a modelagem da aplicação, as quais podem ser vistas na Figura 4-6.