Document title:

AgentCities Work Plan

Document number:


Document source:

FIPA AgentCities WG

Document status:


Date of this status:


Change history:


Initial draft


Updates to include responses to detailed comments from Jonathan Dale


Updates based on confirmations of supporters and detailed comments from Stefan Poslad


FAB comments (see end)


                                Steve Willmott                                  Bernard Burg

                        <>              <>


Problem Statement:

FIPA has produced three sets of standards for agent interoperation (FIPA 97, FIPA 98 and FIPA 2000 standards) that have the potential to provide a very valuable basis for future agent research and commercial exploitation. The standards have also been tested by many FIPA members and in large scale collaborative projects such as the EU FACTS project. Despite this success, several issues related to the deployment of FIPA technology are still lacking:

·         Although FIPA infrastructures such as FIPA-OS, JADE, ZEUS and others are increasingly being made public and open source, they have limited exposure to the public at large

·         There are few publicly available deployed FIPA agents or agent based services outside collaborative projects – exceptions include the Agentis meeting scheduler which should soon be available on the FIPA web site

·         A lack of published ontologies and service descriptions for use in a FIPA context

·         No open network of platforms to connect to and provide an easy test of interoperability. Those on-line platforms that do exist (such as Comtec’s platform, JADE DF, FIPA-NET) are not federated or naturally interoperable at least at the transport layer.

·         There is little publicly visible deployment of FIPA technology by which outside observers can gauge the utility of FIPA specifications


These difficulties arguably: stifle development of innovative FIPA based applications, hamper basic interoperability testing (which can only be carried out in the context of whichwcollaborative projects between FIPA member organisations) and make it hard to evaluate FIPA technologies for providing innovative agent based services in an open world environment such as the Internet.


The authors would like to make it clear that they realize that is not one of FIPA’s stated aims to address these points directly but up to individual member organizations. The problem statement is simply intended to highlight what may be potential barriers to FIPA’s long term success.


Please note that this document covers only the administrative aspects of work in the TC and is not intended to give details on the precise services that might be deployed in the test bed (this is a topic for a parallel discussion).


Objective: The objective of this work plan is to encourage and support the development of a continually available, publicly accessible network of deployed FIPA agent services. The network should serve as an experimental test bed for interoperability testing and application development. Although most of the technical work would be carried out by test bed contributors themselves, the following activities within FIPA would be a valuable support to the effort:

·         Regular meetings to provide a focal point for test bed activity

·         Producing informative guidelines on issues such as problem modelling, ontology design, service description, usage of FIPA specifications

·         Discussing modelling issues for services of interest to a large subset of test bed contributors (agreeing on ontologies and service functionality to support for example)

·         Specifying a set of functions to be implemented by all agents in the test bed that provide information such as uptime, state, requests served etc. for debugging and statistical purposes[1]

·         Publicizing the effort and encouraging participation


Technology: No new standards are required (the effort is essentially to implement/apply existing standards). New work items may well be generated however:

1.       When specifying test bed details (debugging functions, services, ontologies) and writing informative guideline documents

2.       By feedback from applying FIPA technology in the test bed


Feedback generated by point 2 will be channelled through the Interoperability SIG. Any major technology issues raised by points 1 and 2 are expected to be dealt with in other work plans (configuration management, agent communication, management etc.) or to generate new, separate, work plans.


Specifications Generated:  This work plan is not intended to produce FIPA specifications, rather to support the building of the test bed resource. It should also generate informative documents relating to the test bed that are also of use in the wider context of applying FIPA specifications in general. The work plan would generate the following documents:

·         Charter for Participation[2]: a short document to clarify issues of property rights, etiquette etc. in the test bed, this would also include specifications for technical and operational details (FIPA specification versions to be supported, encodings, transports, availability of services etc.)

·         Guidelines: informative documents produced by test bed contributors describing things such as service modelling, use of ontologies, content languages, FIPA ACL etc.[3]

·         Service Specifications: for services which are of general interest to a significant subgroup of test bed contributors, the TC may specify ontologies, content languages and service functionality. This would support the development of applications relying on a core set of identical services being deployed on a number of platforms

·         Test Bed Management Function Specifications[4]: for functions which are decided upon to help debugging and management of the test bed as a whole (wherever these functions are not supported by existing FIPA standards)


The scope of these documents is limited to the application of FIPA in the test bed and they should be classified as FIPA output documents (see [f-out-00003]) and not FIPA specifications.


Plan for Work: If created, the TC would use the following modes of work:

·         Regular meetings at FIPA meetings to:

o        Discuss administrative and technical issues

o        Present reports from contributors on services deployed, progress and issues

o        Sub-committees may be formed around applications of particular interest

·         Report to Interoperability SIG at each FIPA meeting

·         Ad-hoc interim meetings: since much of the technical work is being carried out by test bed contributors it is expected that interim meetings between subsets of contributors would occur to solve interoperability / interconnection issues

·         Reflector discussion: the reflector should be used actively to disseminate news of services deployed, problems encountered and issues to discuss (reflector name[5]).


Significant areas of technical work which would require new FIPA specifications would be dealt with either under an existing work plan (configuration management, management, agent communication, gateways etc.) or generate a new work plan. It is not this TC’s function to produce new FIPA specifications.


Milestones: The milestones for this activity are shown in shown in Table 1 and classified into internal (documents and output to/by FIPA) and external (achieved by the test bed contributors). The work plan is set to run for 12 months, milestones to be completed by the end of the relevant FIPA meeting. The definition of “connected” for a platform used here is:

·         Must be able to exchange messages with other platforms in the network (this may entail defining conformance points / base-line encoding, protocols, ontologies, etc for interoperability and defining an interoperability test-suite)

·         Must be publicly accessible and available continuously

·         Must be hosting two or more FIPA agent based services




FIPA Internal milestones

External (Test bed) milestones


Jul 00

·          V0.0 PC



Oct 00

·          V1.0 PC

·          V1.0 TMF

·          List of core services which are considered for deployment on several test bed participants platforms (V0.0 SS)

·          5+ connected platforms


Jan 01

·          V1.1 PC

·          V2.0 TMF

·          V1.0 SS – preliminary specifications of key services

·          Significant cross platform applications being tested

·          Established basic service set supported by most platforms


Apr 01

·          V2.0 SS

·          10+ connected platforms


Jul 01

·          Joint demonstration of all test bed contributors, showing one or more applications using deployed services (V2.0 SS)

·          Complete Guideline document for the implementation of a rich set of FIPA Agent based services

·          Use demonstration applications to encourage organic growth of the network


Table 1: TC milestones: PC = Participation Charter, TMF = Test bed Management

 Functions, SS = specifications of services of interest to a significant

 number of test bed contributors


The primary external goal of the work plan is to get a test bed of deployed services running that has sufficient critical mass to make significant contribution to the continued evolution of FIPA specifications. The test bed should demonstrate the value of FIPA, enable developers to implement and test innovative agent based applications and generate feedback to FIPA. Finally the start-up costs (in terms implementations and documentation) for new organisations adding services to the network should be minimised by the body of work generated during the lifetime of the work plan.


Future Work: Continuing beyond the 12 month work plan, the test bed should hopefully develop into a permanent resource for FIPA members and non-members, providing:


·         A rich environment for FIPA agent services and applications

·         A benchmark environment for compliance testing

·         A publicity device for FIPA specifications

·         Potential link ups to deployed commercial FIPA agent applications

·         Finally, if the test bed establishes itself it should form an ideal environment for FIPA application competitions (a first round could potentially take place in 2001/10).


A potential danger for FIPA is that the test bed become “legacy system” and does not keep up with the newest FIPA specifications. This could be avoided to some extent by making decisions at the TC level to adopt new standards as soon as feasible after they are released. There should be a commitment to support experimental and standard level standards.



·         [FIPA00006] FIPA Ontology Service Specification

·         [FIPA00007] FIPA Content Languages Specification

·         [FIPA00023] FIPA Agent Management Specification

·         [FIPA00067] FIPA Agent Message Transport Service Specification

·         [FIPAacl] FIPA Agent Communication Language Specification


There may also be impacts on other work plans in the form of input to their specifications.



John Shepherdson, BT

Hiroki Suguri, Comtec (potential contributor)

Fabio Bellifemine, CSELT (potential contributor)

Jonathan Dale, Fujitsu Laboratories of America (potential contributor)

Makoto Okada, Fujitsu Laboratories

Stefan Poslad, Imperial College (potential contributor)

Steve Willmott, EPFL (potential contributor)

Bernard Burg, Motorola (potential contributor)

Phil Buckle, Nortel Networks (potential contributor)

Tianning Zhang, PopNet Agentscape AG (potential contributor)


FAB Comments:

This work plan is approved and has been assigned to the AgentCities Working Group.

[1]Agent management services may suffice for this but there may be value in adding some functions to improve control.

[2] This is basically so that we can make tighter assumptions in the test bed that the whole latitude the FIPA specifications give if that facilitates the task of interconnecting the platforms.

[3] Not sure how much this overlaps with any plans for a developer’s guide – who is currently in charge of the developers guide?

[4] I’m not sure exactly what will be needed here but simple ping functions and checks on uptime etc. could be very useful.

[5] Note that this does not exist at this time.