Development case studies
Authors are invited to submit a solution to a selection of the AgentLink case studies based on existing agent oriented methodologies. These solutions need not show a relevant scientific contribution, but instead how a methodology can solve a problem. With this format, we hope to attract the attention of young practitioners who, with a reduced effort, will gain access to the workshop and contribute to the community with another AOSE example.

Submissions will be evaluated taking into account coherence, quality, and feasibility. Accepted submissions will be considered for the post-proceedings in an appropriate form, possibly by combining submissions into a single jointly authored paper. Depending on the quality, a journal extension may be considered. Authors will be required to attend the workshop.

Agentlink's case studies are the following:
  • CASE01: handling insurance claims. The process of handling insurance claims is heavily bureaucratic, with most of the information processing done by humans, resulting in long times for settlement. Many European insurance companies use heterogeneous information systems, with different means of storing and using data, hence data must be exchanged manually between companies when dealing with claims. The challenge consists in developing an agent based system to automate the process of information exchange between a different insurance company when handling cross-European motor vehicle accident insurance claims.
  • CASE02: modelling human variability in military environments. The objective is to offer a simulation environment for studying how people alter their decision making and interactions with other military personnel when influenced by various moderating factors, such as heat, tiredness, consumption of stimulants like caffeine, as well as battlefield experience and cultural factors.
  • CASE03: crisis management. This outlines a use case in which poisonous material has been accidentally released into a city. Early observation of the problems at hand and communication between crisis management experts and people “on the ground” are both crucial, as is alerting the public of the danger, and providing emergency services such as medical support to people affected.
  • CASE04: steel production optimisation. The system uses a distributed planning and scheduling algorithm to calculate daily target schedules for the operations necessary to produce steel of different quality levels, according to given customer orders. It also monitors the execution of the schedules and responds to unpredicted changes in customer orders and to operational faults, by dynamically adapting the schedules.
  • CASE05: management and optimisation of a corrugated-box manufacturing plant. It is an agent based solution that explores different strategies for reducing stock levels without compromising delivery times, as well as evaluating consequences of changes in its customer base.
  • CASE06: intelligent scheduler for cargo fleets. This helps human schedulers to plan and re-plan which cargoes are to be assigned to which vessels in their fleet.
  • CASE07: real time evaluation of supply chain assets. This requires methods for responsively constructing production schedules across many different products and plants. Such schedules must be responsive to a large number of dynamic constraints and thus be modifiable on the fly. Related to this is the problem of finding optimal product routing policies from Air Liquide America’s plants to its customer sites. Again, these policies must be responsive to variations in customer demand and the changing constraints placed on production plants.
  • CASE08: intelligent distributed control of shipboard Chilled Water System (CWS) for vessels. To design a highly distributed shipboard automation system, the following four fundamental requirements are considered: reduced maintaining, flexible distributed control, commercial-off-the-shelf, and reliable and survivable operations.
  • CASE09: dynamic transport optimisation. The main benefits brought by agent technology over traditional Transport Management Systems (TMS) are the abilities to adapt transport plans and schedules in response to unforeseen events, and to reduce overall transport costs by improving the coordination between regional dispatchers and the utilisation of trucks.
Required content of the submission

The maximum number of pages of this kind of submission is 8. Each submission must have an annex of free format and undetermined length (in addition to the 8 page limit) to include the more complete specification (but should not exceed 2MB). The title of the paper must be Case study XX with methodology YY, where XX is the number of the case study and YY the name of the methodology.

The submission should introduce the solution, the decisions made, and  how the solution satisfies three evaluating parameters: coherence of  the specification (if it makes sense and answers the initial problem), quality features of the system (is there an effort to look for efficiency, for instance?), and feasibility (if it can be implemented).

To facilitate the work of authors, we have prepared some latex templates illustrating what we expect.

Development support
This year, we aim to update the current state-of-the-art in relation to support tools for AOSE aiding a user of methodologies in concrete development stages (analysis/requirements, design, implementation, testing, maintenance, management). This could be in form of framework instantiation tool, a specification editor, or an agent platform, to give just a few examples. AOSE 2008 therefore solicits papers describing such implemented AOSE support tools. 

Submissions will be evaluated taking into accout robustness of the tool, actual developments in which it was applied, people using it, and why this tool is relevant in the selected development stage/stages.

Accepted submissions will be considered for the post-proceedings in an appropriate form, possibly by combining submissions into a single jointly authored paper. Depending on the quality, a journal extension for individual submissions may be considered. Authors will be required to attend the workshop and present their work in a demo session.

Required content of the submission

Each submission must contain the name of the tool, a brief description,  the name of the relevant development stage, the concrete relevance of   the tool to the specified stage (functionality provided by the tool in the stage; benefits obtained by the developer; future improvements considered by the author), and instructions to obtain the tool.

In addition, the text should address the evaluation criteria given  above (robustness, developments using the tool, current users, and  relevance). The title of the paper must be Support for XX stage with  YY, where XX is the name of the stage or stages and YY the name of the  tool. If the tool helps in different stages, we recommend using in the  title the following short names for each stage: RG (requirements  gathering), AN (analysis), DE (design), IM (implementation), TS  (testing), and MN (Maintenance).

To facilitate the work of authors, we have prepared some latex templates illustrating what we expect.