Algoritmo Básico do GM

Conforme já apresentado na seção 5.4, o GM possui como responsabilidades principais: a tradução da missão em um plano de missão, realizado pela atividade de planejamento; a realização do replanejamento quando a carga de bateria não for suficiente para completar todas as fases da missão; e a escolha do próximo evento que irá guiar o veículo em direção aos objetivos da missão. Tal escolha de eventos está baseada na sequência de referência, nos modos de operação e na política de atribuição de prioridades, conforme discutidos na seção 5.4.4, onde em condições normais de operação o plano de missão original é seguido, mas em estados de falhas impõem-se a realização de um plano pré-estabelecido de recuperação do veículo (modos de operação) ou então um novo plano de missão é gerado (replanejamento). Sempre que o GM decidir pela realização de uma ação, o respectivo evento controlável e seu parâmetro de configuração é então selecionado, de acordo com a política de prioridades implementada. Contudo, caso seja necessário que o veículo termine uma ação ou operação em curso, indicado por um evento não-controlável, o GM opta então por não escolher nenhum evento controlável. De maneira resumida, a tabela 6.2 apresenta o algoritmo básico de execução do SCM, e constitui-se de uma implementação do fluxograma genérico proposto para o SCM mostrado na seção 5.4. O algoritmo é explicado na continuação.

Inicialmente o SCM inicializa variáveis internas, filas e processos de comunicação do ROS (linhas 2 e 3). Comprova-se se o plano de missão, gerado a partir do arquivo de missão, contém uma sequência de referência de eventos realizável pela planta (linhas 4 a 6). Enquanto a missão não chegar ao final, o programa permanece em um laço de repetição que dura até o final da missão (linha 7). De modo a garantir a integridade dos modelos abstratos do CSML e manter os mesmos sincronizados com a planta, os eventos não-controláveis são gerados a partir de uma fila de sinais recebidos pelo nível SO (linha 9). Essa fila mantém a ordem dos eventos conforme são recebidos pelo nível SO. Uma vez recebido o evento não-controlável, os modelos das plantas do nível SP e os supervisores modulares (SM) são atualizados (linhas 10 e 11). Na sequência o plano de missão (linha 12) e o modo de operação (linha 13) são atualizados, e também é realizada a comprovação da necessidade de replanejamento se, por exemplo, um evento não-contro-

Tabela 6.2: Algoritmo básico do SCM 1 Main 2 Init_variables() 3 Init_ROS_components() 4 Read_mission_file() 5 Generate_mission_plan() 6 Check_mission_plan()

7 while (mission is not at end && ROS_ok)

8 while (SO_level_hasResponses) 9 event_uncontrollable = SO_level.getResponse() 10 SP_level.DoEvent(event_uncontrollable) 11 SM_level.DoEvent(event_uncontrollable) 12 updateMissionPlan(event_uncontrollable) 13 updateMode(SP_level, SM_level) 14 Check_Do_Replanning(event_uncontrollable, battery_level) 15 event_controllable = planner_getEvent()

16 if event_controllable is not null

17 SP_level.DoEvent(event_controllable) 18 SM_level.DoEvent(event_controllable) 19 updateMissionPlan(event_controllable) 20 updateMode(SP_level, SM_level) 21 cmd=SO_level.Generate_command(event_controllable) 22 Send_Data2IHM()

lável de erro não previsto na sequência de referência de eventos do plano de missão ocorrer (linha 14). Quando não mais houver eventos não-controláveis, o GM comprova a necessidade de execução de algum evento controlável, analisando o plano de missão (linha 15). Caso exista tal evento controlável (linha 16), o nível SP e SM são atualizados (linhas 17 e 18), o plano de missão e o modo de operação também são atualizados (linhas 19 e 20) e o nível SO traduz e envia o comando equivalente, com respectivos parâmetros, para os níveis inferiores da arquitetura (linha 21). As tabelas de prioridades dos eventos são atualizadas na seguintes situações: cada vez que um novo evento não- controlável é gerado pelo sistema; quando um evento controlável é selecionado pelo GM; ou quando ocorre o replanejamento da missão. Finalmente, são enviados para a IHM (linha 22) as informações referentes ao estado da missão, estado dos modelos, eventos habilitados / desabilitados, posição e orientação atuais do veículo.

Para o SCM implementado e simulações realizadas para este trabalho (capítulo 7), em média, um ciclo do algoritmo do SCM (linhas

7 a 22) dura cerca de 100 a 200 ms, levando em consideração que o ROS suspende o processo sempre que o tempo de execução do ciclo for inferior ao tempo estipulado para execução do processo, programado mediante uma diretiva da biblioteca de funções do ROS (10 Hz ou 100 ms). O valor de 100 a 200 ms é obtido a partir dos registros (logs) do sistema, contudo, como o ROS e o Ubuntu usados para implementar o SCM não suportam processamento tempo-real, tal valor é somente uma média, não havendo garantias destes tempos de execução. Visando aumentar o tempo de desenvolvimento do SCM sem ocupar-se diretamente com aspectos de comunicação, troca de mensagens, detecção de obstáculos, visualização de dados, cálculos de transformações de coordenadas, optou-se pelo ROS. Contudo, como o número de operações do SCM é fixo, com exceção do planejamento e replanejamento, é razoável assumir que o SCM pode ser implementado em um sistema tempo-real.

A posição e orientação atuais do veículo, enviados pelo Matlab/Simulink, os dados enviados pela IHM e pelos demais processos em C/C++ em execução no ROS são recebidos mediante callback síncrono, ou seja, sempre que um dado chega, a execução do laço principal do programa é interrompido e a função corresponde ao tratamento do dado é executada. Semáforos de exclusão mútua (mutexes na biblioteca C/C++) são usados para evitar que dois processos (threads) manipulem a mesma variável simultaneamente, ou ainda, tentem acessar uma área de memória sendo modificada por outra parte do programa. Ainda que o ROS e bibliotecas da linguagem C/C++ forneçam tais mecanismos é necessário a programação dos mesmos no desenvolvimento do sistema. Contudo, a arquitetura para SCM proposta no capítulo 5 independe do sistema operacional e do tipo de comunicação empregados.