Description of the workplan

The workplan is based on a migration strategy, covering the development stages from a single agent application to a fully fledged multi-agent system. The migration strategy comprises three stages for the development of the agent-based system and one pre-stage for the installation of the virtual enterprise:

Stage 0 - implementation of the virtual enterprise

In stage 0 as a pre-stage before the full participation of the three SMEs as ONE service provider for hardening and tempering processes and as ONE service user of logistic services within the enterprise gateway can start, the virtual enterprise will be implemented by the three SMEs. The legal aspects of their close co-operation are clarified and agreed by all parties so that the technical work of the implementation of the virtual enterprise can immediately start after approval of the proposal. Within stage 0 the technical infrastructure for the virtual enterprise will be set-up, interfaces to existing software systems will be implemented and a knowledge based system for the allocation of jointly used resources with optimised batch production will be specified.

Stage 1 - service user (SU) agents

The focus of the first stage is the introduction of intelligent agent technology on the side of the users of the enterprise gateway, requiring services from the service providers. Via the logistics gate and the products & services gate the users are connected to fixed pools of service providers, bound by contractual frameworks. An assistant agent acts on behalf of the users to choose the best service provider for a required task from the pools. The agent bases its decisions on criteria given by the user.
In the consortium service users are represented by a retailer and a virtual enterprise comprising 3 SMEs.

Stage 2 - gateway agents

In the second stage an extension to the gateway is developed, providing a link to e-platforms. An agent representative for each service user connects to the platform to achieve required tasks. These tasks may range from simple monitoring (e.g. announcing new service providers to the user) to searching for best providers and in the end to automated negotiations between service users and service providers. Agents may be mobile, actually moving to remote platforms, or they may simply connect to remote platforms for task execution. Thus stage 2 comprises several migration steps by itself.
To guarantee the interoperability of our system as much as possible we will base our solution on existing/ emerging agent standards, especially on the field of agent communication.

Stage 3 - service provider (SP) agents

In the third stage we introduce agents on the side of service providers, connected to service users via the logistics and the products & services gate. This allows direct interactions between SU agents and SP agents, actually giving rise to a multiagent system. Benefits of automated user-provider interactions could e.g. be dynamic price formation.
Service providers are represented in the consortium by a logistics service provider and a virtual enterprise comprising 3 SMEs (simultaneously using logistics services and providing production services (tempering)).



The above migration strategy is broken down into seven work-packages:

· WP1: Requirements Engineering
· WP2: Interface Specification
· WP3: Agent System Specification
· WP4: Implementation of 1st Prototype
· WP5: Validation of 1st Prototype
· WP6: Implementation of 2nd Prototype
· WP7: Dissemination and Exploitation

WP1 guarantees the industrial grounding of the project. The endusers (service users and service providers) define their expectations of the system, i.e. they describe what the system is supposed to do on a most abstract level. The user requirements are the basis for the specification of software requirements. As a prerequisite for the installation of the Virtual Enterprise the technical and IT requirements to set-up the Virtual Enterprise of the three SMEs have to be identified.

In WP2 interfaces are specified, allowing agents to interact with users, the enterprise gateway and e-platforms. Moreover the interface connecting the enterprise gateway with e-platforms is specified. Besides, the IT infrastructure for the Virtual Enterprise has to be connected to software systems which already exist at the three SMEs. Also, the co-ordination of a resource allocation across company borders is a prerequisite to efficiently use joint resources and to act as ONE production service provider against the Enterprise Gateway. This includes the specification of a concept for a knowledge based batch production to merge tempering orders from different customers with different products.

WP3 identifies agents, their relations and internal structures. The workpackage provides an infrastructure necessary for agent interactions on the various levels of agent communication and models the agent interactions according to WP1 use-cases.

WP4 installs the Virtual Enterprise and implements a prototype solution for stage 1 and 2 of the system migration path.

WP5 validates the 1st prototype developed in WP4.

WP6 implements a prototype solution for stage 3 of the system migration path, integrating the 1st prototype and including tests and evaluation.

In WP7 the dissemination and exploitation of scientific and technological results are described.

The logical interaction and interrelation between workpackages is depicted in fig. 4. The user and software requirements elaborated in WP 1 provide input for the system specification in WP 2 and WP 3. Moreover the evaluation phases of WP 6 and WP 5 are based on the user requirements. The interfaces specified in WP 2 are implemented in WP 4 and WP 6. The agent system architecture developed in WP 3 takes into account the results of WP 2 (as far as interfaces to agents are concerned). The implementation of WP 3 is achieved in WP 4 and WP 6. WP 5 validates the results of WP 4 and feeds them back to the implementation phase. Finally WP 6 implements specification results of WP 2 and WP 3, integrates the 1st prototype of WP 4 and bases the 2nd prototype evaluation on the user requirements of WP 1.
Note: the workpackage dealing with dissemination (WP 7) is not mentioned in the flow diagram. WP 7 receives input from WP 1 - WP 6, so the links to WP 7 would just add a bit of confusion to the flow diagram.