5.2 Exemplo DDDAS
5.2.1 Simulação para previsão de inundações
Como complemento da configuração inicial, descreve-se agora a criação de um workflow de suporte à simulação da evolução de possíveis cenários de inundação numa dada loca- lidade, com base em dados recolhidos em tempo quase-real (online data).
Para isso é utilizado um padrão estrutural pipeline combinado com o comportamento produtor/consumidor, em que a primeira tarefa consiste na obtenção de dados de pre- cipitação referentes a uma localidade particular. A segunda etapa do pipeline consiste numa aplicação de simulação que permite gerar cenários de possíveis inundações, face aos valores recolhidos no terreno (e recebidos no contexto da primeira etapa do pipeline). No exemplo criado a protecção civil pretende simular cenários de perigo de inundação na localidade de Chioggia (localidade de Veneza), tal como ilustrado na Figura5.20.
Na primeira etapa, os dados meteorológicos são obtidos através de um web service que contém um método que recebe por argumento o nome da localidade e devolve os dados. O web service foi criado por nós para testes com geração de valores aleatórios. O valor máximo varia por localidade, por exemplo, para a localidade Chioggia a precipitação varia entre 0 e 99mm. A tarefa ”simulator” por sua vez, recebe os valores da precipitação
Figura 5.20: Exemplo UFAM (exemplo pipeline)
e, acedendo ao histórico da localidade, a simulação avalia a probabilidade de ocorrer inundações nesse contexto. Caso essa probabilidade seja significativa, gera avisos de situação de perigo, para essa localidade.
Figura 5.21: Exemplo UFAM (exemplo output da execução do pipeline)
Neste exemplo, a tarefa ”simulator” avalia o valor da precipitação e retorna um output com possíveis cenários, por exemplo, caso esse valor seja entre 0 e 33 não existe perigo, caso seja entre 33 e 66 a zona está em risco, e entre 66 e 99 perigo é eminente. A Fi- gura5.21ilustra um exemplo de execução. Por exemplo, a partir de uma determinada altura verifica-se que a localidade está em risco de ocorrer uma inundação. Neste caso, os serviços de protecção civil/autoridade local, podem ter necessidade que a simulação
seja mais precisa, porque uma única fonte de dados pode não ser suficiente para obter ce- nários o mais precisos e realistas possíveis. O chover muito não implica necessariamente casos de perigo. Assim é necessário que a informação geográfica da zona também seja considerada. Por exemplo, se existem barragens próximas da zona crítica, ou cursos de água em vias de transbordar os seus limites.
Figura 5.22: Exemplo UFAM (pipeline com nova fonte)
Adicionalmente, a protecção civil pretende que a informação gerada pelo simulador seja gravada numa base de dados, por forma a garantir a persistência dos dados para fins de histórico. Para o nosso exemplo essa tarefa guarda os dados num ficheiro.
Tal como mostra a Figura5.22, o acesso a uma nova fonte de dados é realizada pela tarefa incluída na segunda etapa do pipeline, representando informação geográfica ob- tida num sistema GIS. No nosso exemplo, essa informação foi criada por nós, simulando possíveis condicionamentos para as diferentes localidades. Foi atribuído um peso a con- dições existentes no terreno, em termos da sua implicação num possível agravamento de uma situação de inundação. Por exemplo, a existência de rios com um elevado cau- dal, na zona afectada, aumenta significativamente a probabilidade de ocorrência de uma inundação, ou o seu agravamento, caso já exista inundação na zona em análise, pelo que tem um grande peso na formula subjacente à simulação. Outros factores podem ser tidos em consideração, aqui por exemplo a situação é mais grave numa planície do que numa zona montanhosa.
Na terceira etapa do pipeline encontra-se a aplicação de simulação (Figura5.22), que verifica a densidade da precipitação bem como os condicionamentos na zona que possam agravar a situação, devolvendo cenários possíveis. No nosso exemplo, são considerados os seguintes condicionamentos: ”terreno acidentado” com peso médio, ”zona monta- nhosa” com peso baixo dado que está em análise o perigo de inundação. Os resultados
Figura 5.23: Exemplo UFAM (pipeline com novo consumidor e comando de reconfigura- ção)
obtidos são claramente diferentes visto que, apesar de ser uma zona com terreno aciden- tado, a informação de que é uma zona montanhosa ajuda a não existirem cenários de grande perigo de inundação. Esta nova formula de teste devolve valores entre 0 e 80 (não existe perigo), entre 80 e 130 (zona em risco) e entre 130 e 180 (perigo eminente):
Valor simulação: valor precipitação + média de pesos dos condicionamentos (são dados pesos numéricos, escala de 0 a 50)
No nosso exemplo ”terreno acidentado” tem um peso de 25 e a ”zona montanhosa” 10, logo a média é de 17,5. Os resultados como previsto são menos drásticos (lista5.3) apesar das precipitações serem elevadas (ver Figura5.22).
Listing 5.3: Valores gravados no ficheiro 1 Info Simulador: A localidade Chioggia nao corre perigo!
2 Info Simulador: A localidade Chioggia e uma zona em risco! 3 Info Simulador: A localidade Chioggia nao corre perigo! 4 Info Simulador: A localidade Chioggia nao corre perigo! 5 Info Simulador: A localidade Chioggia e uma zona em risco! 6 Info Simulador: A localidade Chioggia nao corre perigo! 7 Info Simulador: A localidade Chioggia e uma zona em risco! 8 Info Simulador: A localidade Chioggia e uma zona em risco! 9 Info Simulador: A localidade Chioggia e uma zona em risco! 10 Info Simulador: A localidade Chioggia nao corre perigo! 11 Info Simulador: A localidade Chioggia e uma zona em risco! 12 Info Simulador: A localidade Chioggia e uma zona em risco! 13 Info Simulador: A localidade Chioggia nao corre perigo! 14 Info Simulador: A localidade Chioggia e uma zona em risco!
Na última etapa do pipeline é guardada a informação gerada pela aplicação de simu- lação num repositório para análise posterior.
No contexto deste exemplo, uma das reconfigurações dinâmica possíveis é a adição de uma ou mais tarefas representando a visualização, em tempo real, dos dados produ- zidos pela simulação. Esta visualização é útil considerando que peritos no domínio de nacionalidades e em localizações diferentes, podem contribuir com os seus conhecimen- tos na avaliação de perigo da situação corrente. Assim, é feita uma reconfiguração tal que, as suas últimas etapas ”simulation” e ”Data storage” passam a fazer parte de uma estrela, nas posições de núcleo e satélite, respectivamente (Figura5.23). Assim é possível adicionar dinamicamente novos satélites, representando consolas para peritos diferen- tes. Os mesmos dados, em vez de serem enviados apenas para a tarefa ”Data storage”, são enviadas para todos os satélites da estrela.
Figura 5.24: Exemplo UFAM (Output consola universidade)
Tal como no exemplo anterior, o administrador encarregue de gerir a execução deste workflow, executa o comando de adicionar uma tarefa para visualização dos dados numa consola. O workflow fica com a estruturação apresentada na Figura 5.23. Como se pode verificar a tarefa ”simulation” é produtora para duas tarefas no contexto do padrão em estrela.