2 3 : name : r o b o t 4 5 : I n i t i a l B e l i e f s : 6 p o s s i b l e _ r u b b l e ( 1 , 1 ) 7 p o s s i b l e _ r u b b l e ( 3 , 3 ) 8 p o s s i b l e _ r u b b l e ( 5 , 5 ) 9 10 : I n i t i a l G o a l s : 11 h o l d i n g ( r u b b l e ) [ a c h i e v e ] 12 13 : P l a n s : 14 + ! h o l d i n g ( r u b b l e ) [ a c h i e v e ] : 15 {B p o s s i b l e _ r u b b l e ( X , Y ) , ~B n o _ r u b b l e ( X , Y) } ← move_to ( X , Y ) ; 16 + a t ( X , Y) : {~B r u b b l e ( X , Y) } ← + n o _ r u b b l e ( X , Y ) ; 17 + r u b b l e ( X , Y ) : {B a t ( X , Y) } ← l i f t _ r u b b l e ; 18 + h o l d i n g ( r u b b l e ) : {⊤} ← p r i n t ( d o n e ) ;
Fonte: Dennis e Fisher (2016)
Neste trabalho a linguagem de programação de agentes Gwendolen será utilizada. A escolha foi feita por ser o Gwendolen uma linguagem específica para agentes racionais (DENNIS
et al., 2012) e ser possível fazer sua verificação formal através do MCAPL (Model Checking
Agent Programming Languages) (DENNIS, 2017).
3.5 VERIFICAÇÃO FORMAL DE AGENTES
A verificação é uma maneira de averiguar se um sistema atende a suas especificações e requisitos. Ela pode ser realizada através de métodos como testes, simulação e verificação formal (DENNIS; FISHER, 2016). Dill (1998) propôs um espectro variando da simulação à verificação formal completa que pode ser visto na Figura 21.
Figura 21 – Espectro de técnicas de verificação
Fonte: Adaptado de Dill (1998)
Ao simular um sistema o número de cenários possíveis pode ser infinito e, ao selecionar um subconjunto finito para simulação, há sempre incerteza sobre a corretude do sistema. Essa
Quadro 5 – Comparativo entre simulação e verificação formal
Desafio Simulação Verificação Formal
Exaustão (capacidade de observar todos os cenários de entrada possíveis)
Não é capaz de simular todos os es- tados possíveis.
Concentra-se em encontrar cenários que possam falhar;
Explora todos os estados possíveis.
Foco no comportamento cor- reto do sistema.
Controlabilidade (capacidade de ativar um ponto específico dentro do sistema)
É provável que configurações isola- das que causem erros sejam perdi- das;
Todas as configurações são consideradas.
Observabilidade (capacidade de observar os efeitos de um ponto específico dentro do sistema)
Propaga erros sendo difícil encon- trar o que o causou;
É capaz de indicar onde o erro ocorreu.
Fonte: Adaptado de Sanghavi (2010)
incerteza vêm pelos cenários não simulados que podem conter erros ou situações indesejadas. A verificação formal pode aumentar a confiança de programadores e usuários nas novas tecnologias que incluem os veículos autônomos (DENNIS; FISHER, 2016).
A verificação formal utiliza demonstrações lógicas para verificar se o sistema atende a suas especificações. As técnicas aplicadas para verificação formal variam da prova formal reali- zada manualmente até a exploração exaustiva e automatizada de estados na execução do sistema (DENNIS; FISHER, 2016). Sanghavi (2010) afirma que a verificação formal pode superar os três grandes desafios da simulação, descritos no Quadro 5:
Para verificar as propriedades e requerimentos do sistema os mesmos são descritos através de uma especificação formal onde todos os cenários são considerados. Erros podem ser detectados antes que o sistema seja implantado devido ao rigor matemático das provas lógicas (BAIER; KATOEN; LARSEN, 2008). O esquema da verificação de um sistema é apresentado na Figura 22.
Figura 22 – Esquema da verificação de um sistema
A especificação do sistema determina as propriedades que devem ser verificadas e, se o sistema atende a todas as suas especificações e nenhum erro é encontrado, pode-se dizer que está correto.
A NASA (do inglês, National Aeronautics and Space Administration), juntamente com FAA (do inglês, Federal Aviation Authority) concluiram, em uma publicação sobre métodos formais do qual a verificação formal faz parte, que "os métodos formais devem fazer parte da educação de todos os cientistas da computação e engenheiros de software"(BAIER; KATOEN; LARSEN, 2008). Isso porque tais técnicas asseguram o funcionamento dos sistemas evitando o seu comprometimento devido a falhas. A verificação formal poderia ter corrigido algumas conversões erradas nas variáveis do software do foguete Ariane 5 que fizeram com que ele ex- plodisse menos de quarenta segundos após o lançamento em 4 de Junho de 1996, (CLARKE; GRUMBERG; PELED, 1999).
Uma das categorias da verificação formal é a verificação baseada em modelos. Nela o sistema é modelado matematicamente de forma precisa antes da verificação sendo possível encontrar inconsistências ainda nesta etapa. Algoritmos exploram sistematicamente todos os es- tados do modelo permitindo sua verificação de forma exaustiva. Essa é a base do model checking (BAIER; KATOEN; LARSEN, 2008).
Na Figura 23 é possível visualizar o esquema de funcionamento do model checking. Os requerimentos do sistema são formalizados enquanto o sistema está sendo modelado. As saídas desses dois processos são examinadas com o model checking. Se todas as propriedades modeladas foram satisfeitas o sistema está correto. Caso contrário, um simulador auxilia na localização do erro ao simular as propriedades violadas.
Figura 23 – Visão esquemática do model checking
Com a verificação por meio do model checking não é possível ter uma garantia absoluta de que o sistema está correto pois ele verifica o modelo do sistema, ou seja, os resultados estão corretos se o modelo também estiver. Porém esta é uma técnica considerada eficaz para encontrar erros e inconsistências e "pode proporcionar um aumento significativo no nível de confiança de um projeto de sistema" (BAIER; KATOEN; LARSEN, 2008).
Uma das ferramentas para realizar o model checking é o JPF (Java PathFinder) que tem como objetivo verificar e depurar programas Java. A ideia de desenvolver a ferramenta veio após um rover que operava em Marte em 1997 apresentar vários erros que poderiam ter sido encontrados através de uma verificação adequada. A missão foi considerada um sucesso, mas os erros causavam reinício repetido do software (HAVELUND; PRESSBURGER, 2000). "O nome JAVA PathFinder é um jogo de palavras: encontra os caminhos de um programa JAVA que leva a erros"(HAVELUND; PRESSBURGER, 2000).
O JPF implementa sua própria maquina virtual que explora todos os caminhos possíveis dentro de um programa e funciona um nível acima da máquina virtual padrão do Java. Se um erro é encontrado um relatório mostra todas as etapas que o causaram (DENNIS et al., 2008).
3.6 MODEL CHECKING AGENT PROGRAMMING LANGUAGES
O MCAPL (Model Checking Agent Programming Languages) é um conjunto de ferra- mentas para realizar a verificação formal de sistemas baseados em agentes. O AIL (Agent In-
frastructure Layer) e o AJPF (Agent JPF) fazem parte desse framework (DENNIS, 2017). Essas ferramentas são descritas detalhadamente no trabalho de Fernandes (2017).
3.6.1 Agent Infrastructure Layer
O AIL (Agent Infrastructure Layer) é uma pacote proposto por Dennis et al. (2008) composto por uma coleção de classes Java que fazem a representação de um sistema desen- volvido em uma das linguagens de programação de agentes (como: AgentSpeak, 3APL, Jadex, Metatem e Gwendolen) permitindo a verificação formal dos mesmos. Justificando a criação os autores afirmam que programas baseados em agentes são utilizados cada vez mais em áreas complexas e críticas onde a verificação formal é necessária. É preciso analisar o que o agente faz, porque agiu daquela forma, quais eram suas crenças e intenções naquele momento. "Em vez de fornecer uma abordagem para uma linguagem de programação específica, descrevemos uma nova arquitetura (...)"(DENNIS et al., 2008).
3.6.2 Agent JPF
O AJPF (Agent JPF) é uma extensão do JPF que incorpora as classes AIL para verifica- ção formal de sistemas desenvolvidos em uma das linguagens de programação de agentes (como: AgentSpeak, 3APL, Jadex, Metatem e Gwendolen) através do Model Checking (DENNIS et al., 2008).
Na Figura 24 é possível ver que o AIL funciona como uma camada intermediária que não se destina a uma linguagem de agentes específica, por sua vez o AJPF faz a verificação como uma extensão do JPF.
Figura 24 – Abordagens para Model Checking de linguagens de programação de agentes
Fonte: Adaptado de Dennis et al. (2008)
A linguagem utilizada para especificação de propriedade é baseada na Lógica Temporal Linear (LTL) e especializada em programas de agentes racionais (DENNIS; FISHER, 2016). Ela é um dos diferentes tipos de lógica temporal existentes que permite especificar propriedades de tempo em fórmulas proposicionais considerando que "em cada momento, existe um único momento sucessor" (BAIER; KATOEN; LARSEN, 2008). Os seguintes operadores formam a LTL:
∙ Da lógica clássica: negação (¬) e conjunção (∧);
∙ Operadores temporais: próximo (next, ○), até que (until, ∪), agora ou em algum momento no futuro (eventually, ♢) e sempre verdadeiro (always,).
Figura 25 – Operadores da lógica temporal linear
Fonte: Adaptado de Baier, Katoen e Larsen (2008)
Dennis e Fisher (2016) exemplificam propriedades de um agente em uma autoestrada utilizando a sintaxe do AJPF baseada na LTL. Os operadores 𝐵, 𝐺 e 𝐼𝐷 representam crença, objetivo e a intenção de tomar uma ação respectivamente:
1. Agora ou em algum momento no futuro car1 acredita que at_speed_limit. ♢𝐵𝑐𝑎𝑟1𝑎𝑡_𝑠𝑝𝑒𝑒𝑑_𝑙𝑖𝑚𝑖𝑡
2. Agora ou em algum momento no futuro car1 possui o objetivo at_speed_limit. ♢𝐺𝑐𝑎𝑟1𝑎𝑡_𝑠𝑝𝑒𝑒𝑑_𝑙𝑖𝑚𝑖𝑡
3. Agora ou em algum momento no futuro car1 acredita started e eventualmente car1 acredita at_speed_limit.
♢𝐵𝑐𝑎𝑟1𝑠𝑡𝑎𝑟𝑡𝑒𝑑 ∧ ♢𝐵𝑐𝑎𝑟1𝑎𝑡_𝑠𝑝𝑒𝑒𝑑_𝑙𝑖𝑚𝑖𝑡 4. Agora ou em algum momento no futuro car1 pretende accelerate.
♢𝐼𝐷𝑐𝑎𝑟1𝑎𝑐𝑐𝑒𝑙𝑒𝑟𝑎𝑡𝑒
3.7 CONSIDERAÇÕES FINAIS
O presente trabalho trata-se da implementação de um agente racional condutor de um veículo autônomo. O agente implementado segue o modelo BDI pois trata-se de um agente de raciocínio prático, capaz de deliberar e decidir como os objetivos propostos serão alcançados.
Além disso o agente racional é capaz de buscar o melhor resultado para alcançar os objeti- vos considerando seu histórico de percepções e podendo melhorar seu desempenho conforme o tempo.
O raciocício do agente é verificado formalmente por meio do Model checking, mais es- pecificamente utilizando o framework MCAPL. Para isso o agente é programado pela linguagem Gwendolen, um arquivo é criado com as especificações formais a serem provadas baseadas na lógica temporal linear e, ao executar o arquivo para verificação, o framework gera um modelo do sistema baseado nas classes do AIL e verifica o modelo criado.
4 DESENVOLVIMENTO
O trabalho apresentado pode ser divido em duas partes. A primeira é o desenvolvimento do ambiente de simulação que consiste na implementação do ambiente em que o agente irá perceber e agir e a construção de um simulador para representar o sistema.
A segunda parte consiste na verificação formal de um agente racional condutor de um veículo autônomo. Nessa etapa consta a implementação do agente condutor em Gwendolen e a verificação formal com MCAPL. A Figura 26 mostra as ferramentas utilizadas em cada uma das etapas de desenvolvimento.
Figura 26 – Ferramentas utilizadas no trabalho
Fonte: Autoria própria
A seguir, as Seções deste Capítulo irão apresentar em mais detalhes o processo de cria- ção de cada uma das partes. Informações sobre o ambiente e simulador são dadas na Seção 4.1. O agente construído em Gwendolen e a verificação formal do mesmo são os assuntos da Seção 4.2.
4.1 AMBIENTE DE SIMULAÇÃO
O sistema é composto por um conjunto de doze arquivos:
1. 𝑎𝑢𝑡𝑜𝑛𝑜𝑚𝑜𝑢𝑠_𝑐𝑎𝑟.𝑎𝑖𝑙: arquivo que une o caminho do ambiente e agente para exe- cução do sistema;
2. 𝑎𝑢𝑡𝑜𝑛𝑜𝑚𝑜𝑢𝑠_𝑐𝑎𝑟.𝑔𝑤𝑒𝑛: arquivo que contém a implementação do agente, deta- lhada na Seção 4.2;
3. 𝐶𝑜𝑜𝑟𝑑𝑖𝑛𝑎𝑡𝑒.𝑗𝑎𝑣𝑎: classe que representa uma coordenada. Cada elemento do cená- rio possui uma coordenada (𝑥, 𝑦) referente ao canto superior esquerdo do mesmo. A partir desse ponto o elemento se estende de acordo com sua largura e compri-
mento. Um exemplo de aplicação é o veículo conduzido pelo agente. Para desviar de obstáculos é preciso considerar a parte de trás do veículo, que corresponde a sua coordenada, e a frente do veículo, que corresponde a sua coordenada mais seu comprimento e largura;
4. 𝑃 𝑒𝑑𝑒𝑠𝑡𝑟𝑖𝑎𝑛.𝑗𝑎𝑣𝑎: classe que representa o pedestre programado para atravessar a faixa de pedestre. Ele possui atributos referentes ao seu estado caso esteja atraves- sando a rua para cima ou para baixo e caso esteja esperando para atravessar em um desses sentidos. A classe também possui dois métodos denominados 𝑎𝑑𝑑𝑇 𝑖𝑚𝑒() e 𝑐ℎ𝑒𝑐𝑘𝑆𝑡𝑎𝑡𝑒() que serão detalhados na Seção 4.1;
5. 𝐶𝑎𝑟.𝑗𝑎𝑣𝑎: classe que representa o veículo a ser conduzido pelo agente. Possui atri- butos referentes a sua velocidade, velocidade máxima na qual pode trafegar, sua aceleração e alcance dos sensores;
6. 𝑂𝑏𝑠𝑡𝑎𝑐𝑙𝑒.𝑗𝑎𝑣𝑎: classe que representa um obstáculo. Possui quatro variáveis utili- zadas para identificação do seu estado a medida que são captados pelos sensores:
∙ 𝑓 𝑜𝑢𝑛𝑑: verdadeira quando o obstáculo está dentro do alcance do wide sensor do veículo;
∙ 𝑎𝑛𝑎𝑙𝑖𝑧𝑒𝑑: verdadeira quando as informações do obstáculo foram enviadas para o agente;
∙ 𝑠𝑖𝑛𝑎𝑙𝑖𝑧𝑒𝑑: verdadeira quando o obstáculo está dentro do alcance do ultrasonic
sensordo veículo;
∙ 𝑜𝑣𝑒𝑟𝑃 𝑎𝑠𝑡: verdadeira quando o obstáculo foi ultrapassado. 7. 𝐶𝑟𝑜𝑠𝑠𝑤𝑎𝑙𝑘.𝑗𝑎𝑣𝑎: classe que representa a faixa de pedestre;
8. 𝑇 𝑟𝑎𝑓 𝑓 𝑖𝑐𝐿𝑖𝑔ℎ𝑡.𝑗𝑎𝑣𝑎: classe que representa o semáforo. Possui atributos referentes ao seu estado: red, green e yellow. Possui dois métodos chamados 𝑎𝑑𝑑𝑇 𝑖𝑚𝑒() e 𝑐ℎ𝑒𝑐𝑘𝑆𝑡𝑎𝑡𝑒() que serão detalhadas na Seção 4.1;
9. 𝑅𝑜𝑎𝑑.𝑗𝑎𝑣𝑎: classe que representa a pista onde o veículo trafega;
10. 𝐶𝑙𝑖𝑒𝑛𝑡.𝑗𝑎𝑣𝑎: classe para o envio de mensagens do ambiente para o simulador; 11. 𝑆𝑖𝑚𝑢𝑙𝑎𝑡𝑜𝑟.𝑗𝑎𝑣𝑎: classe que implementa a simulação do sistema. As informações
são enviadas do ambiente para o simulador onde a parte gráfica é desenhada. O simulador também permite configurar a quantidade de obstáculos do ambiente e iniciar a simulação do sistema. Detalhes sobre o simulador serão dados na Seção 4.1.1;
12. 𝐴𝑢𝑡𝑜𝑛𝑜𝑚𝑜𝑢𝑠𝐶𝑎𝑟𝐸𝑛𝑣.𝑗𝑎𝑣𝑎: classe do ambiente do sistema. Constrói o cenário para a condução do veículo e possui funções chamadas pelo agente para agir no ambiente. Detalhes sobre a implementação do ambiente serão dados na Seção 4.1.2. A Figura 27 apresenta o Diagrama de Classes do sistema. Os elementos do ambiente (𝑃 𝑒𝑑𝑒𝑠𝑡𝑟𝑖𝑎𝑛, 𝐶𝑎𝑟, 𝑂𝑏𝑠𝑡𝑎𝑐𝑙𝑒, 𝐶𝑟𝑜𝑠𝑠𝑤𝑎𝑙𝑘 e 𝑇 𝑟𝑎𝑓 𝑓 𝑖𝑐𝐿𝑖𝑔ℎ𝑡) são tipos de coordenada (𝐶𝑜𝑜𝑟𝑑𝑖𝑛𝑎𝑡𝑒) pois possuem uma posição na matriz do ambiente, uma largura e comprimento. A faixa de pe-
destre (𝐶𝑟𝑜𝑠𝑠𝑤𝑎𝑙𝑘) e o semáforo (𝑇 𝑟𝑎𝑓 𝑓 𝑖𝑐𝐿𝑖𝑔ℎ𝑡) também são tipos de obstáculos, pois são elementos detectados pelos sensores onde as variáveis 𝑓 𝑜𝑢𝑛𝑑, 𝑎𝑛𝑎𝑙𝑖𝑧𝑒𝑑, 𝑠𝑖𝑛𝑎𝑙𝑖𝑧𝑒𝑑 e 𝑜𝑣𝑒𝑟𝑃 𝑎𝑠𝑡 são utilizadas. O pedestre (𝑃 𝑒𝑑𝑒𝑠𝑡𝑟𝑖𝑎𝑛) não é um tipo de obstáculo porque, de acordo com a implementação, ele só é considerado quando a faixa de pedestres é detectada. A classe (𝐶𝑎𝑟) refere-se ao veículo dirigido pelo agente.
O simulador contém um veículo, um pedestre, uma faixa de pedestres, um semáforo e um conjunto de obstáculos que serão desenhados na simulação. O ambiente possui uma instância do simulador iniciada junto ao ambiente, um semáforo, uma faixa de pedestres, um pedestre, uma pista onde o veículo irá trafegar, um veículo e um conjunto de obstáculos. A Classe 𝐶𝑙𝑖𝑒𝑛𝑡 possui métodos estáticos que podem ser utilizados pelo ambiente sem uma instância dela.
Figura 27 – Diagrama de Classes do SAE: tráfego urbano
Cada elemento do ambiente possui seu tamanho proporcional a realidade. Essas infor- mações e detalhes da implementação serão dadas na seção 4.1.1 e 4.1.2 referentes ao simulador e ambiente, respectivamente.
4.1.1 Simulador
O simulador mostra de forma visual as ações do agente e outros elementos do cenário. Para isso ele recebe mensagens do ambiente com as informações a serem desenhadas na tela e a Figura 28 mostra o Diagrama de Sequência dessa comunicação. Foi utilizada principalmente a classe 𝑗𝑎𝑣𝑎.𝑎𝑤𝑡.𝐺𝑟𝑎𝑝ℎ𝑖𝑐𝑠 para desenhar os elementos e a simulação funciona em um sistema semelhante a jogos de corrida infinita, onde a câmera fica fixa no veículo e a pista, bem como os elementos contidos nela, se movimentam.
Figura 28 – Diagrama de Sequência: Comunicação Ambiente-Simulador
Fonte: Fernandes (2017)
O Código 4 mostra o funcionamento da função principal do simulador. É possível notar que antes de iniciar a execução do while cria-se uma instância de server configurada na porta 9999 habilitando o simulador a receber mensagens do ambiente. Iniciada a execução do while, o sistema permanece nesse loop até que o simulador seja encerrado.
Na linha 11, o server aguarda mensagens do ambiente e, ao recebe-las, executa o mé- todo readReceivedMessage(), responsável por tratá-las, passando-a como parâmetro. A variável
nextUpdate, iniciada com o valor 0 na linha 2, é utilizada para atualizar a visualização do simu- lador (Figura 29 a). Na linha 19 ela é atualizada pelo retorno de System.currentTimeMillis(), que retorna o tempo atual em milissegundos, adicionado da variável fps, variável global configurada no início da classe. Isso é feito toda vez que o desenho é atualizado.
Código 4 – Loop principal do simulador