Nesta sec¸c˜ao ´e descrita a implementa¸c˜ao do sistema de alarmes. Visto que a arquitetura da gateway j´a prevˆe a existˆencia deste sistema de alarmes, a implementa¸c˜ao do sistema seguiu os requisitos da plataforma j´a existente.
Assim, e considerando que a gateway foi desenvolvida baseada em threads, o sistema de alarmes foi desenvolvido numa thread distinta, permitindo a sua f´acil integra¸c˜ao na gateway existente. A thread criada permite que o sistema de alarmes funcione em paralelo em rela¸c˜ao ao resto do sistema, ou seja, permite que o sistema desempenhe todas as suas fun¸c˜oes previstas. A thread criada para a gest˜ao do sistema de alarmes est´a associada a v´arias fun¸c˜oes, correspondendo cada fun¸c˜ao a um tipo de alarme diferente. As fun¸c˜oes desenvolvidas seguem a estrutura ilustrada no fluxograma da Figura 4.5. O primeiro passo consiste na leitura e valida¸c˜ao de dados presentes em mem´oria. Caso os dados sejam v´alidos, estes s˜ao guardados e analisados pelo algoritmo de decis˜ao, que permite inferir se estamos perante uma situa¸c˜ao alarmista. Caso n˜ao estejamos num cen´ario alarmista, ou anteriormente se tenha detetado que os dados n˜ao s˜ao v´alidos, realiza-se uma nova leitura de dados. No entanto, caso estejamos perante uma situa¸c˜ao alarmista, procede-se `a classifica¸c˜ao do tipo de alarme e do seu n´ıvel de prioridade. Em situa¸c˜oes de prioridade alta, al´em do aviso atrav´es da p´agina web, ´e tamb´em enviado um email e SMS.
Apesar de uma estrutura comum, as fun¸c˜oes que detetam cada uma das situa¸c˜oes alar- mistas distinguem-se pelo algoritmo de decis˜ao, em que este ´e distinto em cada uma dessas fun¸c˜oes. Assim, as subsec¸c˜oes que se seguem abordam cada uma dessas situa¸c˜oes.
Figura 4.5: Fluxograma do algoritmo dos alarmes
4.3.1 Alarmes associados aos dispositivos
Nesta sec¸c˜ao ´e descrita a implementa¸c˜ao detalhada dos alarmes associados aos dispositivos, nomeadamente, bateria baixa, problemas de hardware e coleiras perdidas.
Baterias
O alarme relacionado com as baterias indica se a carga da bateria das coleiras ou dos far´ois ´e baixa, comparando com valores pr´e-definidos. De acordo com os valores limiares escolhidos, os alarmes podem ser classificados com prioridade baixa, m´edia ou alta.
No algoritmo 1 pode-se observar o pseudoc´odigo que serve de base `a implementa¸c˜ao da fun¸c˜ao de dete¸c˜ao de bateria baixa nas coleiras. Apenas se apresenta para o caso das coleiras, pois a dete¸c˜ao nos far´ois segue a mesma estrutura. O c´odigo ´e percorrido ao fim de um deter- minado tempo (tBateria), em que cada vez que ´e executado ´e incrementado um contador, m,
que sinaliza o n´umero de valores que se v˜ao guardando. Cada ´ındice do ciclo for ´e utilizado como parˆametro para efetuar a leitura dos identificadores, ID, e respetivos dados presentes na mem´oria partilhada. De forma a que se validem os identificadores, verifica-se se estes est˜ao contidos num determinado intervalo, sendo limitado pelo n´umero m´aximo de coleiras definido (N ). Caso contr´ario ´e descartado o identificado (ID) procedendo-se incrementa¸c˜ao no ciclo inicial e consequente valida¸c˜ao do pr´oximo identificador. Se os IDs forem v´alidos, guardam-se os valores de bateria (B[ID,m[ID]] ) e realiza-se a incrementa¸c˜ao do contador (m[ID]). Se o n´umero de valores contabilizados for igual a M, procede-se `a analise das condi¸c˜oes que permi- tem gerar estes alarmes. Observou-se que existem erros associados `as baterias, que originam varia¸c˜oes nos valores destas. Para prevenir uma alta ocorrˆencia dessas varia¸c˜oes, realizou-se uma valida¸c˜ao dos valores guardados da bateria (∆B[ID,]), verificando se a diferen¸ca entre estes ´e menor que o valor do erro (Ebat ). Caso esta condi¸c˜ao n˜ao se verifique, os valores s˜ao descartados e procede-se `a an´alise de um novo identificador, caso contr´ario, executa-se a verifica¸c˜ao de uma segunda condi¸c˜ao, realizando-se uma nova an´alise de forma a garantir que o valor mais recente (B[ID,M]) ´e menor que o primeiro valor recolhido (B[ID,1]). Ap´os serem validadas estas condi¸c˜oes, determina-se atrav´es da compara¸c˜ao com valores limiares (Tabela 4.1) se vai ser gerado o alarme e qual a prioridade associada, e tamb´em o respetivo m´etodo de notifica¸c˜ao.
Algoritmo 1: Fun¸c˜ao dete¸c˜ao de bateria baixa
1: m ← 0
2: 3: top:
4: if tdecorrido == tBateria then
5: loop: 6: for i = 1 : N do 7: ID ← get(ID(i)) 8: if ID > 1 and ID < N then 9: B[ID,m[ID]] 10: m[ID]++ 11: else 12: goto loop 13: if m[ID] == M then
14: if ∆B[ID,] > Ebat then
15: goto loop
16: else
17: if B[ID,M] > B[ID,1] then
18: goto loop
19: else
20: if B[ID,M] 6 Blim1 then
21: Alarme ← timestamp, ID, bateria, alto, B[ID,M]
22: else if B[ID,M] > Blim1 and B[ID,M] 6 Blim2 then
23: Alarme ← timestamp, ID, bateria, m´edio, B[ID,M]
24: else if B[ID,M] > Blim2 and B[ID,M] 6 Blim3 then
25: Alarme ← timestamp, ID, bateria, baixo, B[ID,M]
Valores Limiares Prioridade Notifica¸c˜oes Blim2< B[ID,M] 6 Blim3 Baixa P´agina Web
Blim1< B[ID,M] 6 Blim2 M´edia P´agina Web
B[ID,M] 6 Blim1 Alta P´agina Web,
SMS e email Tabela 4.1: Valores Limares Bateria
Problemas de Hardware
O alarmes associados aos problemas de hardware dos dispositivos, mais concretamente nas coleiras, permitem identificar um deficiente funcionamento dos sensores da coleira, nome- adamente, do aceler´ometro. Uma vez que estes problemas afetam uma das principais partes do sistema, foi definido que, caso o alerta seja lan¸cado, ´e gerado com n´ıvel de prioridade alto. No algoritmo 2 pode-se observar o pseudoc´odigo para gerar este alarme. O esquema de funcionamento inicial ´e semelhante ao alarme anterior, ou seja, a fun¸c˜ao ´e percorrida ap´os um determinado tempo (tProblema). A valida¸c˜ao tamb´em ´e comum com o anterior, mas neste
caso guardam-se os valores das acelera¸c˜oes dinˆamicas dos eixos x, y e z (Ad X[ID,m[ID]], Ad Y[ID,m[ID]] e Ad Z[ID,m[ID]], respetivamente) e realiza-se a incrementa¸c˜ao do contador (m[ID]). Como no caso do alarme das baterias, quando o valor do contador (m) for igual a M, procede-se `a analise das condi¸c˜oes que permitem gerar estes alarmes. Verifica-se se a varia¸c˜ao dos valores guardados das acelera¸c˜oes (∆Ad X[ID,] , ∆Ad Y[ID,] e ∆Ad Z[ID,]) ´e igual a zero, caso se verifique esta condi¸c˜ao, este alarme ´e gerado.
Algoritmo 2: Fun¸c˜ao dete¸c˜ao de Problemas de Hardware
1: m ← 0
2: 3: top:
4: if tdecorrido == tProblema then
5: loop: 6: for i = 1 : N do 7: ID ← get(ID(i)) 8: if ID > 1 and ID < N then 9: Ad X[ID,m[ID]] 10: Ad Y[ID,m[ID]] 11: Ad Z[ID,m[ID]] 12: m[ID]++ 13: else 14: goto loop 15: if m[ID] == M then
16: if ∆Ad X[ID,] == 0 and ∆Ad Y[ID,] == 0 and ∆Ad Z[ID,] == 0 then
17: Alarme ← timestamp, ID, problemas hardware, alto
18: else
19: goto loop
Coleiras Perdidas
O alarme associado a coleiras perdidas, tal como o alarme de problemas de hardware, est´a sempre associado a um n´ıvel de prioridade alto, e, consequentemente, todas as notifica¸c˜oes s˜ao enviadas via SMS, email e atrav´es da p´agina web.
No algoritmo 3 pode ser observado o pseudoc´odigo e as condi¸c˜oes utilizadas para que este alarme seja gerado. Como mencionado na Sec¸c˜ao 4.2.1, al´em de ser necess´ario saber o identi- ficador das coleiras, ´e tamb´em essencial analisar um conjunto de parˆametros, nomeadamente:
• m´odulo da acelera¸c˜ao dinˆamica (AD MOD[ID,m[ID]] );
• ˆangulos pitch (Pitch[ID,m[ID]] ) , roll (Roll[ID,m[ID]] ) e heading (Heading[ID,m[ID]] ); • estado (Tabela 2.1) que as coleiras apresentam (Estado[ID,m[ID]] ) .
Este algoritmo recolhe os dados referentes aos parˆametros acima mencionados ao fim de um intervalo de tempo (tPerdida) e de cada vez que a fun¸c˜ao ´e lida e os identificadores (ID)
validados, s˜ao guardados os valores dos parˆametros e ´e incrementado o contador (m[ID]). Quando o contador for igual a M, ´e realizada uma an´alise `as condi¸c˜oes necess´arias para a gera¸c˜ao destes alarmes. Dada a natureza ruidosa dos valores obtidos pelo aceler´ometro, mesmo quando este se encontra em repouso, definiu-se um conjunto de valores limiares que garante que, se os valores do m´odulo da acelera¸c˜ao e dos ˆangulos de uma coleira estiverem dentro de uma gama de valores, ent˜ao o alarme pode ser gerado. As condi¸c˜oes necess´arias para gerar os alarmes s˜ao:
• a varia¸c˜ao dos valores dos ˆangulos tem de ser menor ou igual que o valor do erro (EAng)
devido a varia¸c˜oes na leitura dos valores;
• a varia¸c˜ao dos valores do m´odulo da acelera¸c˜ao dinˆamica de uma coleira tem de ser menor que o valor do erro (EAcel) devido a varia¸c˜oes na leitura dos valores;
• a diferen¸ca entre os valores do m´odulo da acelera¸c˜ao dinˆamica de uma coleira em rela¸c˜ao ao resto das coleiras pertencentes ao rebanho tem de ser maior que o valor limiar (EAcelFlock);
• o estado da coleira tem de ser o Standing, que corresponde ao animal estar parado; • o estado da coleira tem de ser diferente do estado do resto das coleiras pertencentes ao
rebanho.
4.3.2 Alarmes associados aos animais
Estes alarmes s˜ao gerados quando se verifica a existˆencia de situa¸c˜oes problem´aticas re- lacionadas com os animais, tais como um elevado n´umero de infra¸c˜oes, a identifica¸c˜ao de situa¸c˜oes de pˆanico ou um poss´ıvel desaparecimento de um animal.
Algoritmo 3: Fun¸c˜ao dete¸c˜ao de Coleiras Perdidas
1: m ← 0
2: 3: top:
4: if tdecorrido == tPerdida then
5: loop: 6: for i = 1 : N do 7: ID ← get(ID(i)) 8: if ID > 1 and ID < N then 9: Pitch[ID,m[ID]] 10: Roll[ID,m[ID]] 11: Heading[ID,m[ID]] 12: Estado[ID,m[ID]] 13: AD MOD[ID,m[ID]] 14: m[ID]++ 15: else 16: goto loop 17: if m[ID] == M then
18: if ∆Pitch[ID,] 6 Eang and ∆Roll[ID,] 6 Eang and ∆Heading[ID,] 6
Eang and ∆AD MOD[ID,] 6 Eacel and Ad MOD[ID,] − Ad MOD[ID+1,] >
EacelFLock and ∆Estado[ID,] == S and Estado[ID,] 6= Estado[ID+1,] then
19: Alarme ← timestamp, ID, coleira perdida, alto
20: else
21: goto loop
22: goto top.
Infra¸c˜oes
No algoritmo 4 est´a ilustrado o pseudoc´odigo da fun¸c˜ao que permite gerar os alarmes de elevado n´umero de est´ımulos eletrost´aticos. Tal como nos alarmes anteriores o algoritmo ´e percorrido ap´os um determinado tempo (tChoque), onde ´e realizada a leitura e valida¸c˜ao dos
identificadores, ap´os a qual, caso sejam v´alidos, guardam-se os valores do contador de choques (Ch[ID,m[ID]] ), sendo tamb´em incrementado o contador (m[ID]). Ap´os a obten¸c˜ao de v´arios valores (m[ID] == M) procede-se `a an´alise das condi¸c˜oes essenciais para gerar estes alarmes. Se o ´ultimo valor obtido do contador de choques (Ch[ID,M] ) for menor que o primeiro valor desse contador (Ch[ID,1 ) ent˜ao os respetivos dados s˜ao eliminados, iniciando-se a an´alise de um novo ID, pois o valor mais recente tem de ser maior que o mais antigo. Caso se verifique que o primeiro valor ´e menor que o ´ultimo, realiza-se o c´alculo da diferen¸ca entre o ´ultimo valor e o primeiro (Num Ch[ID] = CH[ID,M]-CH[ID,1]) para contabilizar o n´umero de est´ımulos aplicados ao animal. Por fim, realiza-se a compara¸c˜ao do n´umero de choques (Num Ch[ID] ) com os valores limiares (CHlim1 e CHlim2). Na Tabela 4.2 podem ser encontradas as condi¸c˜oes
que permitem gerar os diferentes tipos de alarmes, bem como a prioridade e os respetivos m´etodos de notifica¸c˜ao.
O caso de elevado n´umero de est´ımulos sonoros tem uma implementa¸c˜ao idˆentica ao men- cionado acima, com uma ´unica diferen¸ca: os alarmes gerados s˜ao sempre de baixa prioridade (quando estes forem superiores a um determinado valor Solim3).
Tipo de Infra¸c˜oes Valores Limiares Prioridade Notifica¸c˜oes
Sonora > Solim3 Baixa P´agina Web
Choque CHlim2 6 Num Ch[ID] < CHlim1 M´edia P´agina Web
Choque Num Ch[ID] > CHlim1 Alta P´agina Web,
SMS e email Tabela 4.2: Valores Limares Alarme de Infra¸c˜oes
Algoritmo 4: Fun¸c˜ao dete¸c˜ao de Elevado N´umero de Est´ımulos Eletrost´aticos
1: m ← 0
2: 3: top:
4: if tdecorrido == tChoque then
5: loop: 6: for i = 1 : N do 7: ID ← get(ID(i)) 8: if ID > 1 and ID < N then 9: Ch[ID,m[ID]] 10: m[ID]++ 11: else 12: goto loop 13: if m[ID] == M then
14: if CH[ID,M] < CH[ID,1] then
15: goto loop
16: else
17: Num Ch[ID] = CH[ID,M]-CH[ID,1]
18: if Num Ch[ID] > CHlim1 then
19: Alarme ← timestamp, ID, Choque, alto, Num Ch[ID]
20: else if Num Ch[ID] > CHlim2 and Num Ch[ID] < CHlim1 then
21: Alarme ← timestamp, ID, Choque, m´edio, Num Ch[ID]
22: else
23: goto loop
24: goto top.
Pˆanico
O alarme de pˆanico ocorre quando o m´odulo da acelera¸c˜ao dinˆamica durante um per´ıodo de tempo ´e superior a um determinado valor. E poss´ıvel distinguir situa¸c˜´ oes de corrida normal e de pˆanico atrav´es da an´alise do tempo em que o animal/rebanho permanece a correr. Portanto, o valor do intervalo de tempo para gerar o alarme n˜ao pode ser muito baixo devido `a possibilidade de ser confundido com uma simples corrida.
Como foi explicado na Sec¸c˜ao 4.2.2, existem dois tipos de alarmes de pˆanico: o pˆanico individual e o pˆanico coletivo. No algoritmo 5 ´e apresentado o pseudoc´odigo para gerar alarmes de pˆanico individual e coletivo. Ap´os intervalos de tempo (tPanico), validam-se os
valores dos identificadores dos animais (IDs). Caso sejam v´alidos, calculam-se e guardam-se os valores do m´odulo da acelera¸c˜ao dinˆamica (AD mod[ID,m[ID]] ). Ap´os serem guardados
v´arios valores da acelera¸c˜ao dinˆamica, ou seja, quando o contador (m[ID]) ´e igual a um determinado valor M, ´e calculada a m´edia da acelera¸c˜ao dinˆamica (AD Med[ID]), que se for superior a um determinado valor limiar (ADlim1), permite que seja gerado o alarme de pˆanico
individual. Indicou-se que os alarmes de pˆanico s˜ao de baixa prioridade, devido `a dificuldade na distin¸c˜ao entre simples corridas e situa¸c˜oes de pˆanico. O utilizador ´e informado atrav´es da p´agina web, sobre o timestamp, o identificador do animal (ID ), o tipo de alarme, prioridade e a acelera¸c˜ao m´edia.
Quando se verifica a presen¸ca do pˆanico individual, ´e ent˜ao necess´ario analisar o resto do rebanho. Para cada animal, caso se encontre em pˆanico, a Flag Panico[ID] ´e igualada a 1, caso n˜ao seja detetado pˆanico, ent˜ao a Flag Not Panico[ID] ´e que ´e igualada a 1. Ap´os serem analisados todos os animais, percorrem-se de novo os identificadores dos animais, por forma a contabilizar o n´umero de animais em estado de pˆanico (Cont Panic), e o n´umero de animais
Algoritmo 5: Fun¸c˜ao dete¸c˜ao de Pˆanico Individual e de Rebanho
1: m ← 0
2: Flag Panico ← 0
3: Flag Not Panico ← 0
4: 5: top:
6: if tdecorrido == tPanico then
7: loop: 8: for i = 1 : N do 9: ID ← get(ID(i)) 10: if ID > 1 and ID < N then 11: AD mod[ID,m[ID]] 12: m[ID]++ 13: else 14: goto loop 15: if m[ID] == M then
16: AD Med[ID] = (AD mod[ID,1] + ... + AD mod[ID,M])/M
17: if AD Med[ID] > ADlim1 then
18: Alarme ← timestamp, ID, pˆanico individual, baixo, AD Med[ID]
19: Flag Panico[ID] = 1
20: else
21: Flag Not Panico[ID] = 1
22: Reb:
23: for ID = 1 : N do
24: if Flag Panico[ID] == 1 then
25: Cont Panic++
26: if Flag Not Panico[ID] == 1 then
27: Cont Not Panic++
28: Perc Num Panic = Cont Panic/(Cont Panic + Cont Not Panic)X100
29: if Perc Num Panic > ADlim2 then
30: Alarme ← timestamp, rebanho, pˆanico rebanho, baixo, Perc Num Panic
que n˜ao se encontram em estado de pˆanico (Cont Not Panic). Terminadas as contagens ´e calculada a percentagem de animais que se encontra em pˆanico (Perc Num Panic), sendo de seguida comparada com um novo valor limiar (ADlim2) e caso seja superior a este valor, ent˜ao
´e gerado o alarme de pˆanico para o rebanho. Este alarme, como o de pˆanico individual e pelo mesmo motivo, ´e de baixa prioridade e informa o utilizador atrav´es da p´agina web, sobre o timestamp, rebanho, o tipo de alarme, prioridade e a percentagem de animais em pˆanico.
4.3.3 Alarmes associados aos animais e/ou dispositivos
Estes alarmes s˜ao gerados quando se verifica a ausˆencia dos animais e/ou dispositivos, podendo ser devido a fatores como bateria baixa ou ausˆencia de animais na ´area controlada. Este tipo de alarmes possui trˆes n´ıveis de prioridades que variam com o tempo, tendo em conta a ´ultima vez que foi detetado. Este alarme evolui desde a prioridade baixa at´e `
a prioridade alta. No pseudoc´odigo ilustrado no Algoritmo 6 para os alarmes de ausˆencia de animais, apenas ´e apresentado este algoritmo visto que o de dete¸c˜ao de dispositivos tem uma implementa¸c˜ao semelhante, apenas mudando os identificadores utilizados. O esquema de funcionamento inicial ´e semelhante aos alarmes anteriores, ou seja, a fun¸c˜ao ´e executada ao fim de um per´ıodo de tempo (tAusencia). A valida¸c˜ao ´e comum com os alarmes mencionados
previamente, neste caso os valores a guardar s˜ao os tempos em segundos dos identificadores dos animais quando guardados na gateway (T G[ID] ). Este timestamp ´e comparado com o tempo em segundos do sistema (time raw ). Para comparar os dois timestamps, o valor do tempo quando guardado na gateway (T G[ID] ), mais um valor limiar (Tlim1, Tlim2 ou Tlim3)
tem de ser inferior ao tempo do sistema (time raw ). Na Tabela 4.3 pode-se observar para cada valor limiar qual a prioridade dos alarmes de ausˆencia e respetivos m´etodos de notifica¸c˜ao. Estes alarmes notificam o utilizador da data e hora do alarme, o identificador do animal, prioridade, data e hora da ´ultima dete¸c˜ao (T G[ID]).
Valores Limiares Prioridade Notifica¸c˜oes
Tlim1 Baixa P´agina Web
Tlim2 M´edia P´agina Web
Tlim3 Alta
P´agina Web, SMS e email Tabela 4.3: Valores Limares Ausˆencia
Algoritmo 6: Fun¸c˜ao dete¸c˜ao de ausˆencia de animais
1: time raw ← time(NULL)
2: 3: top:
4: if tdecorrido == tAusencia then
5: loop: 6: for i = 1 : N do 7: ID ← get(ID(i)) 8: if ID > 1 and ID < N then 9: T G[ID] 10: else 11: goto loop
12: if T G[ID] + Tlim1 6 time raw then
13: Alarme ← timestamp, ID, ausˆencia, baixo, T G[ID]
14: else if T G[ID] + Tlim26 time raw then
15: Alarme ← timestamp, ID, ausˆencia, m´edia, T G[ID]
16: else if T G[ID] + Tlim36 time raw then
17: Alarme ← timestamp, ID, ausˆencia, alta, T G[ID]
18: else
19: goto loop
Cap´ıtulo 5
An´alise de Resultados
Neste cap´ıtulo apresenta-se uma an´alise dos resultados dos testes efetuados para valida¸c˜ao do sistema de alarmes. Analisou-se o tempo de resposta das fun¸c˜oes no PC e na Raspberry, particularmente o tempo de processamento e an´alise de dados, tempo de dete¸c˜ao e envio de alarmes e o tempo cumulativo. S˜ao tamb´em analisados testes `a percentagem de CPU e mem´oria utilizados pela gateway com e sem alarmes. Analisa-se tamb´em a escalabilidade do sistema de alarmes, ao analisar o comportamento do mesmo na monitoriza¸c˜ao de rebanhos de diferentes dimens˜oes. Por ´ultimo, ´e demonstrada a gera¸c˜ao de um alarme de ausˆencia.