AKTive.Response

This document describes the AKTive Response challenge area:
this builds on the general notion of e-Response, which is about the creation and use of a virtual organisation for the purpose of responding to highly dynamic
events - such as emergencies.

In the aftermath of the Kobe earthquake in 1995, problems with the in situ IT systems led to the creation of the Robocup-Rescue project.
The long-term goals of the project are to address the following:

Ensuring reliability and robustness through the use of distributed systems;

Ensuring a smooth transition from state of readiness to full response mode.

The Kobe earthquake simultator was developed to encourage and stimulate work towards these objectives.
The simulator models building collapse, road blockages, fire spread and traffic flow across a single district of Kobe.
There are a number of autonomous agents: civilians, fire-crews, ambulance-crews and police are mobile, while fire and police stations, hospitals and refuges are static.
Agents have the ability to 'see' their local environment and act according to their natures (fire-crews fight fires, police clear blocked roads, etc).

Agents of each of the services (fire, police, ambulance) can communicate with each other and with their service 'control center' agent.
The control center agents can communicate with each other to organise a coordinated response.
The overall aim is to reduce the amount of (human, material) damage to the district.
Different plans, control and coordination strategies can be applied to assess their relative worth in this environment.

At this level, we have already used an I-X panel to act as a (manually-operated) control center agent for one of the services. Edinburgh is also intending to apply its coordination technology, and compare it against the approaches of others.

To show how our technologies might be used in a more 'realistic' setting, we propose also introducing a layer of semantic descriptions and services on top of the simulator.

This would allow us, for example, to describe the agents more richly by describing their differing capabilities (eg. fire-crews with specialist chemical fire apparatus) and also their dynamic properties (current status, fuel levels, etc, as well as current position and activity).
By modifying mobile agents to maintain and report their properties, and enrich their 'seeing' capabilities (eg. reporting that what they can see appears to be a chemical fire), we can do this without having to modify the simulator itself.
We would also introduce semantic descriptions of known static agents, so that, for example, a certain hospital has a specialist burns units, but is currently working at maximum capacity.

To do this we would need to produce an ontology (a very rough version can be found here) along with an infrastructure for using this (OWL descriptions + RSS feeds for updates? 3Store?).
In addition semantic web services could be used to eg. request information/expertise outside the current 'response organisation', such as weather forecasts, information about particular buildings, etc.
(Another very rough ontology, this time of services, can be seen here; some initial sample services can be found here.)
Semantic brokering could be used to find candidate services for meeting particular needs.
Where such information is not to be found in existing services, more general use of the 'normal' web could be used to try to locate the information within text of web-pages, etc.

Interaction with this semantic layer (and with the Kobe agents) would be done (still manually) using an I-X panel (which would essentially give a control 'interface' onto the response).
The user of the panel would be able to call upon a library of standard operating procedures (such as the one developed during CoAKTinG), to initiate and delegate specialised responses to developing situations (which might mean overriding a mobile agent's current intentions).
Automated planning might also be invoked at this level.

Although it would be difficult to evaluate this semantic layer in the context of the Kobe simulation (since it is essentially introducing and then tackling a different problem), the intention is that it should serve as a nice integrated demonstrator of AKT tools, and one that should require relatively little effort to put together using existing tools.