Agentes Inteligentes e
Sistemas Multi-agente
FIPA
IST- 2003/2004
Ana Paiva
1
Sumário
FIPA = Federação InterPlanetária Anónima???





A estrutura da FIPA
Alguns Parceiros da FIPA
Especificações
- FIPA-ACL
Plataformas FIPA (amanhã):
- FIPA-OS
Cooperação entre agentes:
- Contract-NET (breve)
A. Paiva
João Leonardo Carmo - IAA - LEIC - IST - 2002/03
FIPA???




FIPA é o acrónimo de Foundation for Intelligent Physical
Agents
Criada em 1996 e localizada em Genebra, na Suíça, é uma
associação sem fins lucrativos
Tem como objectivo a promoção de standards de software
(especificações) e de tecnologias que facilitem comunidades de
agentes heterogéneos e sistemas baseados em agentes a
interactuar entre si
Para atingir estes objectivos, a FIPA cria, divulga e gere
especificações por forma maximizar a interoperabilidade entre
estes sistemas heterogéneos de agentes
A. Paiva
João Leonardo Carmo - IAA - LEIC - IST - 2002/03
FIPA???



Na produção dos ditos standards, a FIPA recorre também à
comunidade dos seus membros (empresas associadas),
realizando periodicamente sessões de reuniões com os mesmos
(4 vezes por ano)
Juntos, tentam desenvolver formas para que agentes criados em
plataformas de empresas e comunidades diferentes consigam
comunicar e inter-operar entre si
A juntar a este grupo estão outras organizações de standards
como a Object Management Group (OMG)
A. Paiva
A estrutura da FIPA

A FIPA está organizada e estruturada em dois
grupos:
- Grupo Administrativo
- Grupo Técnico
 O Grupo Administrativo da FIPA é responsável
por toda a gestão e bom funcionamento da
empresa
 Por sua vez, o Grupo Técnico é responsável
pelo desenvolvimento das especificações da
FIPA
A. Paiva
A estrutura da FIPA
Grupo Administrativo
A. Paiva
Grupo Técnico
A estrutura da FIPA

Do Grupo Técnico destacam-se três entidades:
- os Comités Técnicos, que produzem trabalho técnico e
escrevem as especificações da FIPA
- os Grupos de Trabalho, que se encarregam de outros
aspectos no trabalho da FIPA, como coordenar
actividades de implementação ou centrarem-se mais
sobre uma determinada aplicação
- as duas entidades anteriores juntas formam o Conselho
de Arquitectura
- finalmente, os Grupos de Interesses Especiais, que
desempenham um papel preponderante ao auxiliarem a
FIPA com trabalho que é do interesse desta, como
estarem atentos a novas tecnologias que poderão evoluir
para standards (Agentcities - rede aberta de vários
serviços de agentes, faculdades, etc.)
A. Paiva
Alguns parceiros da








ADETTI - Lisboa / Portugal
Boeing – Delaware / Estados
Unidos
BOSCH - Hildesheim / Alemanha
British Telecommunications Londres / Reino Unido
France Telecom - Paris / França
Fujitsu - Tóquio / Japão
Hewlett-Packard - Estados Unidos
IBM - Armonk / Estados Unidos








A. Paiva
FIPA
Intel – Hilsboro / Estados
Unidos
Mitsubishi Electric - Kanagawa
/ Japão
Motorola - Schaumburg /
Estados Unidos
NASA - Greenbelt / Estados
Unidos
Siemens - Munique / Alemanha
Sun Microsystems – Palo Alto /
Estados Unidos
Toshiba - Tóquio / Japão
Unisys - Tóquio / Japão
Especificações

Tipos de Especificações
 Identificadores de Especificações
 Ciclo de vida de uma Especificação
 Estrutura de uma Especificação
- FIPA-ACL
A. Paiva
Especificações

Existem dois tipos de especificações:
- especificação de componentes
- especificação de perfis


Uma especificação de componentes descreve uma
especificação lógica para uma tecnologia ou para um grupo
intrínseco de tecnologias
Por sua vez, uma especificação de perfis descreve como um
conjunto de especificações de componentes pode ser usado
para definir colectivamente uma entidade mais avançada
A. Paiva
Identificadores de Especificações


Cada especificação da FIPA é representada por um identificador
de especificação.
Existem cinco tipos de identificadores, um por estágio no ciclo de
vida da especificação.
A. Paiva
Ciclo de vida de
uma Especificação


As especificações da FIPA são publicadas de acordo
com a sua posição no ciclo de vida de uma
especificação.
Pretende-se com o ciclo de vida monitorizar e registar
o progresso de uma dada especificação desde a sua
concepção até ao fim do seu papel, seja este o de
standard ou de especificação obsoleta.
A. Paiva
Ciclo de vida de
uma Especificação
Desaprovada
Preliminar

Experimental
Standard
Obsoleta
Preliminar: um “esboço” de uma especificação ainda em construção (Ex: PC00035 => lêse “especificação de componente preliminar nº 00035”)
A. Paiva
Ciclo de vida de
uma Especificação
Desaprovada
Preliminar

Experimental
Standard
Obsoleta
Experimental: uma especificação preliminar que foi aprovada para o nível experimental, pois é estável
por um período de pelo menos dois anos e está agora pronta para ser proposta como standard. (Ex:
XC00035)
A. Paiva
Ciclo de vida de
uma Especificação
Desaprovada
Preliminar


Experimental
Standard
Obsoleta
Standard: uma especificação experimental que foi implementada com
sucesso em várias plataformas de agentes de acordo com as normas da
FIPA, evolui para o estatuto de Standard, e é formalmente publicada pela
FIPA
(Ex: SC00035)
Depois de chegar a standard, a especificação só pode sair deste estado
se deixar de ser necessária, altura em que é colocada no estado de
Desaprovada
A. Paiva
Ciclo de vida de
uma Especificação
Desaprovada
Preliminar



Experimental
Standard
Obsoleta
Desaprovada: uma especificação standard que foi identificada como sendo
potencialmente desnecessária para os standards da FIPA (Ex: DC00035)
Possivelmente devido à evolução tecnológica ou mesmo à evolução de outros
standards ou especificações da FIPA
Se ao fim de 6 meses de permanência neste estado, a especificação continuar a
ser considerada como potencialmente desnecessária, então avançará para o
estado de Obsoleta, caso contrário retornará ao estatuto de Standard
A. Paiva
Ciclo de vida de
uma Especificação
Desaprovada
Preliminar

Experimental
Standard
Obsoleta
Obsoleta: uma especificação Desaprovada que foi identificada e
comprovada como sendo desnecessária para os standards da FIPA
(Ex: OC00035)
A. Paiva
Estrutura de
uma Especificação
Aplicações baseadas em
Agentes
Sistema de Comunicações
do Agente
Sistema de Gestão do
Agente
Sistema de Transporte de
Mensagens do Agente
Arquitectura
Abstracta
A. Paiva
Estrutura de
uma Especificação



Arquitectura Abstracta: é a responsável por todas as entidades
abstractas necessárias para o desenvolvimento de sistemas
baseados em agentes. Faz a distinção entre as entidades que
são facilmente representadas de uma forma abstracta (como por
exemplo o FIPA ACL) dos elementos que não são genéricos a
todos os sistemas de agentes (como a mobilidade do agente ou
o sistema de gestão do mesmo)
Na prática, a Arquitectura Abstracta da FIPA é a parcela comum
a todas as plataformas de agentes que a implementam e que
são compatíveis com as suas especificações, como é o caso do
FIPA-OS, JADE e ZEUS
Sistema de Transporte de Mensagens do Agente: é o
responsável pela entrega e pela representação de mensagens
no seio de ambientes e redes heterogéneas com diferentes
protocolos de transporte
A. Paiva
Estrutura de
uma Especificação
Agente A
Plataforma de
Agentes
Message Transport Service
(MTS)
Mensagem ACL sobre MTS
Message Transport Protocol
(MTP)
Message Transport Service
(MTS)
Agente B
Plataforma de
Agentes
A. Paiva
Estrutura de
uma Especificação

Sistema de Gestão do Agente: providencia a
framework dentro da qual os agentes FIPA existem e
operam. Estabelece o modelo lógico de referência
para a criação, registo, localização, comunicação,
migração e eliminação de agentes
A. Paiva
Estrutura de
uma Especificação
Aplicação de
Agentes
Aplicação
Plataforma de Agentes
Agente
Sistema de
Gestão de
Agentes
(White Pages)
Message Transport Service
(MTS)
Message Transport Service
(MTS)
Plataforma de Agentes
A. Paiva
Directory
Facilitator
(DF)
(Yellow Pages)
Estrutura de
uma Especificação


Sistema de Comunicações do Agente: a comunicação entre
agentes FIPA é baseada num modelo que assenta basicamente
na grande qualidade semântica das mensagens, ou seja, toda a
comunicação encontra-se pré-definida e enriquecida
semânticamente para que seja bem entendida por todos os
agentes
A base da comunicação entre agentes FIPA é conseguida
atrabés do uso de actos comunicativos ou performativas, como
request, inform ou refuse, independentes do conteúdo global da
mensagem em si
A. Paiva
FIPA-ACL



A mensagem que é fornecida ao agente juntamente
com o acto comunicativo está “embrulhada” num
envelope bem especificado, envelope esse
denominado de Envelope de Linguagem de
Comunicação de Agentes, ou Envelope ACL (Agent
Communication Language)
Uma ACL providencia mecanismos para adicionar
contexto ao conteúdo das mensagens e ao acto
comunicativo, tais como identificar o emissor e o
receptor, a ontologia, a linguagem e o protocolo de
interacção da mensagem, entre outros
Graças a uma ACL, agentes de sistemas
heterogéneos conseguem comunicar entre si, uma
vez que a definição da ACL é uma definição abstracta
e bastante genérica (definida na Arquitectura
Abstracta)
A. Paiva
FIPA-ACL



Cada agente interpreta a mensagem consoante os
seus meios internos, mas a comunicação e
transmissão de dados, graças à FIPA-ACL, está
standardizada, sendo genérica a todos os agentes
FIPA
O conteúdo concreto da mensagem é expresso numa
linguagem de conteúdo, tal como a linguagem
semântica FIPA (SL), KIF (Knowledge Interchange
Format) ou RDF (Resource Description Framework),
por exemplo
A FIPA-ACL foi baseada originalmente no ARCOL
com uma série de revisões do KQML
A. Paiva
FIPA-ACL
Actos Comunicativos
A. Paiva
FIPA-ACL
Actos Comunicativos e protocolos
Assertives: inform, refuse, failure, etc…
 Directives: request, query-reg, etc…
 Commissives (compromissos): agree
 Expressives (expressões de interesse): subscribe

•
•
São tipos básicos de conversação (actos
comunicativos)
Protocolo: mensagens ocorrem em padrões,
denominados conversas ou diálogos (ex: fipa-request,
fipa-cfp)
A. Paiva
FIPA-ACL
Comunicação entre dois agentes
(inform
:sender tio-ze
:receiver luis
:content "(not (tempo alentejo chuva))"
:language sl
:ontology meteorologia
:in-reply-to query-1234)
(request
:sender luis
:receiver tio-ze
:content
(inform-if
:sender tio-ze
:receiver luis
:content "(tempo alentejo chuva)"
:language sl
:ontology meteorologia)
:language sl
:reply-with query-1234)
A. Paiva
FIPA-ACL: Comunicação entre dois agentes
A. Paiva
FIPA-ACL
O Envelope ACL
A. Paiva
FIPA-ACL
O Envelope ACL



Ontologia: define os termos, as relações entre os termos e as
operações sobre esses termos num dado contexto (domínio) (Ex:
meteorologia)
Conteúdo: representa o conteúdo da mensagem (o exemplo do
Tio Zé!)
Linguagem: representa a linguagem utilizada no conteúdo da
mensagem, que define as condições, regras e operações
genéricas para que se possa inferir algo do conteúdo da
mensagem (Ex: SL, RDF, KIF, …)
A. Paiva
Plataformas
FIPA
A. Paiva
FIPA-OS




A plataforma FIPA-OS foi a primeira implementação Open Source da FIPA
OS significa... Adivinharam! Open-Source!
Iniciada em Agosto de 1999
Tipos de agentes básicos suportados:
- Reactivo: reage a mensagens ACL provenientes de outros agentes no
ambiente
- Proactivo: o agente consegue decidir quando deve iniciar a interacção
com outros agentes (só para objectivos simples, como registar-se num
servidor de registo!)
- Social: reactivo e proactivo
- Autónomo: cada agente possui várias threads de controlo
A. Paiva
FIPA-OS
A. Paiva
FIPA-OS

Qualquer plataforma FIPA contém:
- Directory Facilitator (DF): Tipo de agentes que fornecem o serviço de
“páginas amerelas” a outros agentes (localização de serviços e serviços de
registo)
- Agent Management System (AMS): gere o ciclo de vida de um agente na
plataforma, enquanto providencia serviços de “páginas brancas” a outros
agentes (localização de agentes, nomes e serviços de controlo de acessos)
- Message Transport Service (MTS):
-
MTP (Message Transport Protocol) numa determinada plataforma (varios
protocolos)
- ACC (Agent Communication Channel) para comunicar entre plataformas
A. Paiva
FIPA-OS
Componentes
específicos do
FIPA-OS
A. Paiva
FIPA-OS




•
Agent Shell: para além dos componentes mandatórios presentes no Modelo de Referência da FIPA, a distribuição da FIPA-OS inclui
um template vazio de um agente denominado Agent Shell.
Através deste template podemos produzir os nossos agentes para inter-operarem na FIPA-OS
Agent Management Service (AMS): É um agente que faz o papel de Serviço e é usado para controlar os ciclos de vida dos outros
agentes.
O agente registado informa o AMS sobre alterações significativas no seu ciclo de vida e deixa o AMS controlar esse mesmo ciclo.
No caso de um agente rebelde que não se deixe controlar pelo AMS, este invoca directamente operações do agente pela sua API
A. Paiva
FIPA-OS



Task Manager: Cada tarefa de cada agente é uma tarefa distinta (ambiente multi-tarefa)
As mensagens são redireccionadas automaticamente para o estado correcto
É possível interagir dentro da mesma tarefa
A. Paiva
FIPA-OS




Parse Factory: sempre que um agente recebe uma mensagem, o Parse Factory descobre em que linguagem a mensagem vem
escrita e carrega dinamicamente o parser respectivo para que a conversão se faça sem sobressaltos
A vantagem mais notória é a transparência com que se pode encarar as mensagens, dando total atenção à componente semântica
destas
Uma vez que o parsing é feito automaticamente, para o agente é como se estivesse a comunicar na mesma linguagem! Não há
necessidade de codificação sintática!
Só o conteúdo semântico interessa ao agente
A. Paiva
FIPA-OS


Conversation Manager: Trata de todo o tráfego de conversas (não trata mensagens individuais)
Simplifica a implementação das conversas, senão teriamos de associar sempre a identificação das conversas à mensagem antes do agente
enviar a mesma
A. Paiva
FIPA-OS


Comunicações: Remote Method Invocation (RMI) usado em comunicação no interior da mesma plataforma (intra-plataforma)
IIOP com Voyager e SunIDL para comunicação para plataformas diferentes! (inter-plataforma)
A. Paiva
FIPA-OS:
Exemplo
Agência A
Plataforma
móvel
A. Paiva
Agência B
Cooperação entre agentes:
Contract-NET



É um protocolo do FIPA-ACL para a cooperação entre os agentes para resolver
problemas por comunicação directa.
É modelado sobre os mecanismos que governam a troca de mercadorias e
serviços.
Prevê uma solução para o chamado problema da conexão: encontrar um agente
apropriado para realizar uma determinada tarefa.
A. Paiva
Cooperação entre agentes:
Contract-NET - exemplo



Um agente que tem uma tarefa a ser feita é o chamado gerente
Agentes que podem resolver essa tarefa são os chamados contrantantes.
Do ponto de vista do gerente, o processo é o seguinte:
-
A. Paiva
Anuncia uma tarefa que precisa de ser executada
Recebe e avalia as “ofertas” dos potenciais contratantes
Decide a favor de um contratante conveniente e envia-lhe o contrato
Recebe e sintetiza os resultados
Cooperação entre agentes:
Contract-NET - exemplo

Do ponto de vista do contratante, o processo é o seguinte:

Recebe o anúncio de uma tarefa
Avalia sua própria capacidade de a resolver
Responde negando ou fazendo uma “oferta”
Executa a tarefa se sua “oferta” é aceite
Envia os resultados ao gerente
O papel dos agentes não é previamente especificado. Qualquer um pode ser gerente ou
contratante.
A. Paiva
FIPA

Referências:
- http://www.fipa.org
- http://fipa-os.sourceforge.net
- http://www.agentcities.org
- http://www.nortelnetworks.com/
A. Paiva