From  user  requirements  to  a  system architecture  for  managing  robots  in risky interventions Jeremi Gancet*, Carlos Pinzón◊, Wim Mees◊, Michel Ilzkovitz* * Space Application Services N.V., Zaventem, Belgium

◊ Royal Military Academy, Brussels, Belgium

 Abstract: As worldwide geopolitical stability becomes more and more questionable, as industrialization requires the manipulation and containment of potentially dangerous materials, as ecological stakes (and especially global warming) unpredictably threaten human life, crisis management is a rising concern of every industrialized country. The objective of the View-Finder research project is to extend existing crisis management structures with operational robotics appliances that come in support of the existing crisis management actors, such as civilian protection services or fire fighting services, during their intervention. View-Finder appliances gather and process real-time information on the field and make this information available to various entities in the crisis management chain of command. A view-Finder appliance typically consist of a few robots (2-3) endowed with a number of sensors. Some of these sensors are chemical sensors that cover a spectrum of chemical substances identification and others are imaging sensors, the data of which can be used to construct 2D and 3D models of the environment. These robots are connected to a base station that provides users with a number of services:

• Human Machine Interface (HMI) for robot monitoring & control,

• Robot sensor data processing,

• Mission authoring, planning & scheduling, execution supervision and data recording,

• Interfaces to the Crisis Management Information System (CMIS)

The CMIS is the local access point to the national crisis coordination center, enabling real-time coordination of the View-Finder appliance with higher level crisis coordination decisions. The CMIS also gathers relevant GIS data, supporting in this way local decision making in the region involved in the crisis. In this paper we introduce the stakes and issues of crisis management using the View-Finder system; we describe the user requirements used to design the system, and subsequently depict a preliminary design with a focus on the CMIS and base station interrelations in View-Finder.

Keywords: crisis management, multi-robot system, monitoring and control station

1 Introduction The View-Finder project focuses on the combination of robots for in-situ data gathering on a fire/crisis ground together with the most appropriate risk and crisis management strategies in order to ensure the optimal exchange of information between the local forces deployed at the crisis ground in the one hand and the centralised higher land crisis management and information sources on the other.

To reach these goals, the View-Finder project has to define and develop open, flexible and generic information tools which will allow the field actors, when the crisis arises, to take the right decisions, in an effective and efficient way.

The purpose of his paper is to show how the requirements, gathered from the users, lead to the View-Finder crisis management information system architecture. It furthermore provides an overview of this architecture.

Through the analysis of the essential wishes and needs expressed by the users, this paper introduces in section 2, the user requirements and their impact on the definition of the View-Finder architecture; following, in section 3, by a brief overview of related work on crisis management systems as well as on robot monitoring and control. Finally, in section 4, the choices are made for the system architecture. The fourth section also explains the two essential elements of this defined architecture: the Crisis Management Information System and the Base station.

2 User requirements The User Requirements Document (URD) analyses the expectations and the needs of the end users. The authorities of the security services, the fire-fighters, and the civil protection of several countries were contacted and requested to participate in a survey.

This survey took the form of a questionnaire whose main goal was to get together experts from the View-Finder participant countries in order to obtain a representative description of their Civil Protection and Fire-Fighting Services, including the legal and/or normative obligations of the organizational administrative and operational Intervention Chains. Moreover the URD intends to highlight the basic objectives, expectations and requirements of the National Authorities in charge of the Civil Protection and Fire-Fighting Services.

The organisations, consulted when producing the URD, can be classified as follows:

local level: authorities intervening when the threat or the emergency situation is limited to the local area; these emergency situations can be controlled using local means and reinforcements, such as those provided by the municipal fire fighters and the police.

regional level: authorities playing a role in the crisis management, intended to provide an aid in emergency situations or being able to provide relevant information to be used at the time of a crisis, when the threat or emergency situation concerns more than one local authority can cope with. In this category we find the fire-fighting brigades, the police and the regional civil protection.

national level: authorities or organisations playing an executive role in the crisis prevention. Typically: ministries of the interior and defence, civil protection services, national crisis management units, national intervention units, units specialised in prevention of CBRN-E incidents.

2.1 Relevant requirements for crisis management and GIS data In this section we will present the most important items, extracted from the user requirement document (URD) as well as from the system requirements document (SRD), which lead to the definition of the system architecture presented in this paper.

UR 1: The terminology of the crisis management-technical tools has to be standardized.

In order to facilitate the communication between different actors, involved in managing the crisis, the VF crisis management information system must define a common terminology to be used throughout the crisis management operations. It is well-advised to use existing, where applicable, crisis management standards to make the system compliant with other international projects and, if necessary, propose new standards or complete the existent ones. This is part of the work that has to be taking into account in developing the CMIS.

UR 2: Realistic scenarios involve specific dangerous tasks that should first be entrusted to robots, under the direct control of the COC together with humans intervening in the field.

Contacts with organisations such as the civil protection, the fire brigades and companies working in sensitive sectors, will permit the elaboration of realistic scenarios for using the robots. To make these conceptual scenarios useful, they should be integrated in the overall crisis management information approach. Scenarios and walkthroughs should be available to the users of the CMIS in the COC in order to serve them as a guide in the resolution of the crisis.

UR 3: View-Finder should develop efficient crisis management tools related to the local, regional and national urgency and intervention plans including the foreseen operational services.

When managing crisis situations, an emergency plan is applied; this plan delimits and assigns the responsibilities for each  service  involved.  A  “specific  mono-disciplinary  plan”  is  created  for  each service. There are, in general, five different services: emergency, medical, sanitary and psychosocial, police, logistical and information.

The COC is staffed with representatives of each of these services together with a representative of the organisation that is affected by the crisis. The information system should, therefore, have the possibility to provide each of these persons with the information necessary to evaluate the current situation and to make the most appropriate decisions.

A generic crisis management and planning system, based on information gathered from similar situations in the past, on information about dangerous, products and on the relevant standards accessible in an interactive format, should be proposed to the users of the different services.

UR 4: Data (geographical data, CBRN-E data, and local management data) is needed at the level of the COC and the CRMC; and this before, during and after the crisis.

Cartographic maps of roads and buildings (outside perimeters and interior layout), traffic networks, water reservoirs, network fire hydrants and hazardous materials storage location are all suitable to give pertinent information about the crisis zone. The CMIS should provide access to these maps. The information system should be able to import cartographic information from heterogeneous sources (public map services, tools available from national authorities or maps stored in different formats media such as CD-ROMs or DVDs). The diversity in sources and nature of these maps will require specific transformations that must be provided by the information system.

UR 5: The Control Operational Centre (COC) and the Crisis and Risk Management Centre (CRMC) are required to maintain a close two-way cooperation and coordination to ensure effective action in response to the emergency. The COC must ensure that the CRMC is kept up to date by regular reports and the CRMC will advise on the progress of actions requested by the COC.

The site of the emergency is subdivided into zones if that is appropriate for the type of emergency that occurred and the specific situation on this site. When necessary, zones are classified as red (exclusion perimeter), orange (insulation perimeter) and yellow (dissuasion perimeter). The COC, and thus the VF crisis management tools, is located in the orange zone (typically only accessible to people who reside or work in this zone).

Moreover, all operational personnel and therefore people in the CRMC must be able to communicate with each other. These communication tools, with user interfaces adapted to the requirements specific to VF-type operations, should be provided by View-Finder crisis management system.

2.2 Relevant requirements for robots management We present here the most relevant user requirements, collected in the early phases of the View-Finder project, which apply to the end-to-end robot operation and management (i.e. in particular the remote monitoring and the control of the robots from the base station).

UR 1: The Base Station shall enable the individual control of the robots; from locomotion to perception tasks and manipulation (shall some robots have manipulation means). The control means shall be reactive enough to perform the instruction with an acceptable latency.

It is likely that, in the frame of the baseline View-Finder scenario, robots shall be directly and individually controlled by users, as the terrain can be very uneven, as tasks can be complex or sensitive, and as contingencies are likely to appear in such a crisis environment.

UR 2: The Base Station should offer a number of individual robot behaviour options, such as “stop and wait in stand by”, or “come back to the Base Station”, and also a number of group policy options for  setting  the  “behaviour”  of  a  set  /  subset  of  robots,  such  as  “explore  an  area”,  or  “observe simultaneously a target from different points of view”.

End-users consider it interesting to have a large scope of control modalities for the robots, ranging from individual direct control (see req. 1) through individual, more elaborated behaviours, up to very high level group policies targeting a number of robots as a whole. The possibility to exploit these different levels of control will be thoroughly considered from the point of view of the base station.

UR 3: The Base Station shall provide the tools to support mission design and to apply (or re-use) such templates in particular operational contexts.

The base station will offer the tools to elaborate and store mission templates which will mainly consist in defining the applicable scope for particular missions, such as the type of environment to expect, the type  of  robot  service  required  (locomotion,  perception…), etc. The exploitation and adaptation of DMAP data will provide a sound baseline for elaborating such mission templates. A mission template is supposed to be applied further on in the operational context where it is instantiated according to available resources (robots and their sensors, human beings, etc.), time constraints, and available geographical information.

UR 4: The Base Station shall allow the visualization / monitoring of all the robots of the system as a whole. Nevertheless the Base Station shall also allow the visualization of the detailed status of any single robot on request.

It is essential to provide View-Finder system users with as much awareness of the situation as possible: thus the HMI for monitoring and controlling the robot shall be flexible enough to cope with different types of visualization (depending on ongoing robot activities), while anyway always preserving overall operations awareness.

UR 5: The Base Station shall allow the selection and visualization, possibly through various modalities, of robots processed sensor data material. In addition the Base Station shall able to manage rough video and audio data received from the robots in such a way that these rough data can be directly provided to clients on request.

The base station will allow the visualization of the different sensors data, either as rough information (if needed), or, more probably, as processed and merged information into exploitable cognitive models (such as 2D and 3D multi-modal models of the environments). Rough audio and video data availability to users is not always critical: in fact such rough information can be counter-productive, as they may inconveniently overload cognitive abilities of the users. However they can become essential in particular tasks where increased telepresence feeling helps in properly controlling the robots and in properly and timely making decision.

UR 6: It may be good to have the possibility, for each client, to enable the video recording of the client’s display(s), either as a training support feature, or for post-mission analysis purpose plus some synchronization capabilities with the other recorded mission data.

This requirement deals with the recording of missions. In order to improve the overall handling of the View-Finder robots on the field (depending on the operational context), debriefing of each performed mission by the users is an essential step. For this purpose, in support to debriefing, the base station will feature an extensive mission data recording system that will allow post-mission replay of the mission, displaying / providing all the detail of actions performed by users, synchronously with sensor data acquired by the robots along the mission timeline.

3 Related work (state of the art) 3.1 Crisis management Several ongoing crisis management research projects were studied in order to define the View-Finder crisis management information system architecture. Three of these projects were financed by the European Commission within the Sixth Framework Programme (FP6), in agreement with its strategic objective of “Improving Risk Management”. 

The projects, ORCHESTRA, WIN and OASIS each focus on a part of the disaster risk cycle yet together cover the whole cycle. They use the same common architecture principles and provide input towards the drafting as well as the piloting of the European directives implementing rules in the risk management domain [ORCHWINOASIS-05].

The architecture and the standards defined in those projects were taken into account in order to define the View-Finder project in such a way that it is as open as possible. The Risk Management Glossary defined in WIN will be used as the basic reference for the terminology used in View-Finder. The open architecture as well as the services specified by OASIS will be taken into account in View-Finder to define the exchange formats within the crisis management system as well as with external crisis management systems.

3.2 Robot monitoring and control A well-known environment for multi-robot mission specification and execution monitoring is the Arkin's MissionLab suite ([ARKIN-92], [MACKENZIE-97]), that has been used and improved for more than 10 years. It allows to design complex robot control structures and to execute them as robot behaviours. In addition it supports plan reparation through case-based reasoning [MOSHKINA-06]. MissionLab ability to support mission design and execution monitoring could be in line with View-Finder needs. It is inspired from military-style plans and approach, and hence could make sense regarding integration to emergency and rescue services procedures. However, the provided behaviour-based robot control framework is not compatible with our project needs: indeed the robotic platforms in View-Finder come with their own existing navigation capabilities, software architecture, and the MissionLab architecture cannot just be implemented on the View-Finder robots.

The FAMOUS framework [FONTAINE-96] has been developed and exploited for almost 10 years for remote monitoring and control of robots and spacecrafts. It is structured as a multi-purpose M&C solution, featuring mission recording mechanisms, multi-operator interfaces and simulation interfaces that meet space industry quality requirements standards. However this framework is not especially designed to cope with multiple systems M&C, hence lacks scalability to cope with a multi-robot system. In addition existing implementation is now somehow outdated, and performances could be an issue. Nonetheless much of the subjacent philosophy still makes sense in Guardians.

MOCU [POWELL-06] is another control station that is currently used for military purposes: it supports monitoring and control activities for multiple robots, and can handle a number of modules related to environment modelization, data gathering and processing. It enables edition of monitoring and control interfaces through XML configuration files. However the chosen approach is to control a single robot at a time, so a single user cannot operate multiple robots through this scheme.

4 System architecture 4.1 Big picture of the View-Finder system architecture The architecture of the View-Finder system is composed of two high level conceptual entities communicating with each other: the appliances (robots) performing their mission inside the crisis area and the combination of the base station (BS) and the Crisis Management Information System (CMIS), that we call Control Operation Center (COC).

The base station is in charge of managing the robots and their sensors. The CMIS takes the information produced by the robots and the sensors they carry, and relayed through the BS, and provide an interface to this information for the crisis managers.

The following picture depicts the relationship between these modules:

Figure 1: VF big picture architecture

4.2 The Crisis management Information System (CMIS) The View-Finder project, along with its appliances (robots), develops a crisis management system to support the actors involved in the crisis.

The crisis management information system (CMIS) developed in the context of View-Finder, must cover the whole Crisis Life Cycle (CLC) and therefore combines the following two components:

the Disaster Management Action Plan (DMAP), the Crisis Management System (CMS)

4.2.1 The CMIS concept The DMAP The DMAP is a conceptual crisis management tool which shall be capable to provide specific answers at any stage of the crisis, for any kind of emergency situations, from large-scale national and cross-border crises, regional disasters down to local-scale incidents. In all cases, collaboration between different organisations and units is envisaged which may include entities from the Governmental Crisis Coordination Centre down to local civil protection authorities.

From a practical point of view, the DMAP will propose to the Protection Services walkthroughs and scenarios which will guide them throughout the crisis management process; moreover the DMAP will provide to the end users three types of information:

1. standards and terminology: to facilitate the communication in heterogeneous contexts; 2. crisis events walkthroughs: provide the end users with access to the recommended methods

to manage this particular crisis based on pre-recorded crisis events; 3. mission templates: based on the material gathered from users, this tool gives a set of pre-

compiled templates to facilitate the characterisation and follow-up of a crisis.

The DMAP features are available all along the utilisation of the CMS and can be invoked in particular situations. For instance, to get the habitual procedure to manage certain dangerous products, to know the list of authorities involved in such a crisis, or even, to look-up the chemical characteristics of a

product present in the crisis zone. The information sources are the standards, templates and databases, present in the system.

Schematic view of the construction of DMAP:

Figure 2: Construction of the DMAP

The Crisis Management System (CMS) The CMS consist of a set of software tools that will allow the people involved at different levels in managing the crisis, to communicate with each other, get a view of the crisis location in real time and receive information on key points in the crisis area.

4.2.2 Architecture of the CMIS The CMIS consist essentially of a first component that is installed at the centralised permanent coordination centre and, after the initial deployment, of a second component that is installed in the vicinity of the disaster inside the crisis area coordination centre [MEES-07].

Figure 3: Crisis being managed in the View-Finder project

These CMIS offers the following services in the form of web based tools

DMAP Services

o Standards

o Mission templates & Walkthroughs

CMS Services

o GIS Services

o Search services

o Communication services

A layered architecture of the CMIS is depicted in the following figure

Figure 4: Layered architecture of the CMIS

4.2.2.1  DMAP Services 

This module covers the essential functionalities of the generic DMAP tool. It is composed of two parts: the “Mission templates and Walkthroughs” module and the “Standards” module.

Mission templates and Walkthroughs This module will offer the mission templates intended to be saved and potentially exploited in multiple operational contexts. These mission templates are standardised guides that will orient the users in the management of a crisis by proposing pre-recorded situations of similar emergencies with the solutions provided to this particular case. This module offers also Walkthroughs

Standards In this module users will find the industrial standard of chemical products  received  from  the  robot’s sensors, methods to manage dangerous products, and even recommendations concerning their manipulation.

4.2.2.2  The CMS Services 

The CMS integrates three services:

Geographic information system (GIS)

Search

Communications

CMS

GIS Search Comm

Figure 5: CMS packages diagram

GIS Services Thematic maps will be provided in a specific Geographic Information System (GIS). The sources of these maps are heterogeneous (other GIS, data stored in common media support, databases); Modules for the processing of these data are foreseen (GIS Servers, WMS, WFS) as well as a module which will allow transforming the retrieved data in a seamless way.

Search services A multi-criterion search tool will be available in order to give quick access to the data available in the system; these data could include information in many formats, for instance images retrieved from the GIS, text retrieved from legal documents or semi-structured information (xml), raw data in provenance of other databases and services.

Communication services This module stores and makes available the gathered data to decision makers at different levels and provides to the system users, the authentication methods and tools which will allow them to keep informed about the crisis events and to keep in contact

4.2.3 User interface of the CMIS The user interfaces of the CMIS should show, simultaneously, technical information about chemical products or locations being observed, as well as the path followed by the robots and points where relevant information can be found (for instance sensor data acquisition time). The system should also offer to the user the possibility to indicate a point in a map as a place with available data or as a reference to be used in the crisis management. A preliminary design of the foreseen CMIS user interface is depicted hereafter (figure 6):

Figure 6: Foreseen CMIS user interface

4.3 The Base Station (BS) The base station (see figure 7 hereafter) is one of the two components of the VF Control Operation Center (aka. COC), the second one being the CMIS. Together with the robot platforms and their sensors, they constitute the View-Finder system.

We identified the following software components, as being part of the base station:

1. Base Station Core (BSC)

2. Mission Template Editor (MTE)

3. Mission Planner, Scheduler and Execution Monitoring (MPSEM)

4. Mission Data Recorder & Dispatcher (MDRD)

5. HMI Clients

6. Sensor Data Processing (SDP)

In addition, the base station provides interfaces with the CMIS and interfaces with the robots and their sensors, as depicted on the figure 7 hereafter.

Figure 7: Base station functional architecture w.r.t. the overall View-Finder system

The figure 8 hereafter focuses on the base station components and highlights the data flows between these different components.

Figure 8: Base Station components detail and associated data flows

We provide in the following some details about the different components introduced above.

4.3.1 (1) Base Station Core (BSC) This component is quite central in the system: it provides management means for the overall system, including users administration, system elements health status and testing, software maintenance (updating software components...), etc. It also has two different HMI servers: one related to Heavy HMI service (as a gateway for data from and to the connected Heavy HMI), and the other one related

to Lightweight HMI service (as a web server, for access through the internet). The BSC accepts connections with clients HMI, either remotely (lightweight client through internet) or on-site (heavy, full-featured client). These servers allow using the different base station components features (MTE, MPSEM, MDRD...), in addition to enabling monitoring and control interfaces for robots and human crew members operations. Accordingly the BSC gathers the following components:

Heavy HMI server: in charge of the heavy HMI clients connections and services providing. Lightweight HMI server: in charge of the light HMI clients connections and services providing.

Clients’ profiles manager: manages user profiles, clearance levels, individual user preferences, etc.

System administration tools: set of tools to administrate the overall base station software.

4.3.2 (2) Mission Template Editor (MTE) The MTE provides the tools to edit mission templates that can be used afterward in operational contexts. The possibility to design before-hand such mission templates allows to think in advance, without the pressure of the operations, about recurrent, classical situations and scenarios of operations. Typically we can imagine a mission template related to the intervention in the aftermath of an earthquake: the typical mission will be mostly outdoor, with very cluttered environment to navigate. The tasks consist of sweeping the disaster zone in order to search for signs of life, to investigate over (and when possible within) the piles of rubbles. In such a template, an area shall be delimited. Although maps of the area are likely not to be directly exploitable, they can help in identifying places which are the most likely to have human presence / victims. A mission template typically consists of:

The selection / definition of a particular type of environment (outdoor / indoor / mix, structured / unstructured, temperature characteristics, expected soil characteristics, expected atmosphere characteristics, known presence of humans or not, expected visibility / constraints on sensors, etc.)

Preferred team (robot platforms) composition for the mission

Mission steps / main guidelines (kind of sub-missions within the mission, with associated partial order, according to well known procedures for this kind of mission context). Multiple possible schemes will be identified here.

Selection of possible tasks that may have to be performed in such a mission, and pre-calibration of these tasks according to available (general) knowledge related to this kind of mission context: expected size of area to cover if approximation is possible, stringent time constraints or not, special care needed for detection or not, communication relay needed or not, trustable map likely to be available or not (if not, SLAM needed...), etc.

Once edited, mission templates are saved in a mission template database which management is under responsibility of the base station coordinator. Mission template can also be simply uploaded from an external source (such as the DMAP), and available mission templates can be shared (saved to an external data support) as well.

4.3.3 (3) The Mission Planning, Scheduling and Execution Monitoring (MPSEM) The MPSEM gathers several features related to mission plan execution in an operational context. It first provides the means to instantiate a mission template in the current operational context. For that purpose it supports the base station coordinator in performing the instantiation, such as:

identifying actually available resources,

matching the selected template information with available GIS data of the region (extent of the main operational area, buildings, regions where human life is supposed to be, potentially dangerous / hot spots, forbidden zones, unknown zones, etc.),

selecting high level tasks in the frame of the pre-identified mission (and "sub-missions") steps, according to latest available knowledge about the operations to be performed,

setting a timeframe for the different steps of the operations (time constraints). Then, with such an instantiated mission, the MPSEM may generate a detailed task plan, and accordingly may schedule the activities according to available robots and sensors, and taking into account identified time constraints. The result is a consistent task plan ready for execution by robots and base station human team. It is important to mention that the MPSEM will usually simultaneously manage multiple robots, hence coordination of activities is an important point to consider, probably to be tackled at the scheduling level: indeed this is about ensuring that resources are properly allocated, without conflict. However contingencies necessarily occur during execution: one shall not rely on pre-established plan. Instead one should be prepared to revise (or "repair") task schedule or task plan, according to the impact of the contingencies. Among features to be considered in addition in the MPSEM, we may consider the possibility to have efficient path planning and perception planning (which are somehow dependant) services in support to task plan elaboration and scheduling. Moreover multiple robot path planning may have to be addressed too, accordingly.

4.3.4 (4) The Mission Data Recorder and Dispatcher (MDRD) The Mission Data Recorder and Dispatcher (MDRD) is twofold: its main role is to listen to and save all information transiting from the base station, to the base station, and in a certain extent, within the base station: controls flows (requests towards both human crew members and robots, execution status, system related controls flows...) and data flows (sensors data TM, housekeeping TM, raw video and sound data, etc.). In addition, considering the need to have all transiting data dumped through the MRDR, it makes sense to use it as a node that gathers data from and dispatches data to all components of the base station (and also from and to components outside the base station, through adequate interfaces). Alternatively the MDRD can "replay" (some of the) recorded data as if it was current data transiting in the system: this could be used to debrief recorded mission through the same monitoring devices (HMI) as used during actual operations (but obviously without the ability to interact).

4.3.5 (5) The HMI Clients HMI clients are the interfaces to the system users: they connect to the HMI server (described hereafter) in order to offer access to the base station, whatever the needs of the users. When an user connects, providing login and password, his profile is restored with rights / accreditation depending on his role. All HMI clients feature visualization services, but additionally, depending on the clearance (role) of user, certain HMI clients can be endowed with various interaction means such as: screen touching, simple mouse using, joysticks, microphone and speakers, voice recognition, etc. Relevance of these technologies will be carefully studied according to the roles requirements, ergonomics issues, and efficiency in monitoring and controlling the system. Data visualization / display, personalization of the content is to be featured. This deals with selection of information to display, respective localization and size in the display, and maybe automatic information changing (or notification) according to events occurring. This shall never be an unwilled constraint for the user (nobody wants jumping trombones anymore...). The possibility to automatically personalize the display according to the use of users is also a topic that will be investigated: for instance learning sequences of actions performed by the user, and offer shortcuts to perform them in a more efficient way. HMI Clients may be either "lightweight" interfaces, providing mainly passive monitoring features, or "heavy" interfaces, featuring various interaction modalities in addition to monitoring. Lightweight interfaces are likely to be remotely exploitable with a web browser through an internet connection, while heavy ones are likely to require the installation of specific software, and would be probably wire-connected in the vicinity of the base station hardware, for communication efficiency (and security) issues.

The following roles have been identified:

Base station coordinator: (using heavy HMI client). In charge of the robot operators and science data specialists coordination during a mission. He is the point of contact from and toward the CMIS. He is also the Base Station administrator, and responsible for managing the users role and users registration.

Robot operator: (using heavy HMI client). In charge of controlling one robot activities. Sensor data specialist: (using light / heavy HMI client). In charge of supporting decision

making through monitoring of science data (and especially chemicals assessment). First observers circle (using light HMI client): Users having access to all available

monitoring data (observation purpose, and communication purpose in a certain extent). Typically: mayor / local crisis manager, rescue services coordinators such as firemen, etc.

Second observers circle (using light HMI client): Users having access to limited / filtered monitoring data (observation purpose only). Typically: press & information media.

4.3.6 (6) The Sensor Data Processing (SDP) This component gathers the functions to process the incoming sensor data from the robots in order both to support the localization of the robots (SLAM supported by exteroceptive sensors) and to perform multi-modal map building of the environments (2D / 3D obstacle maps, chemical map, etc.) that would be too much CPU-consuming for onboard performance. Resulting data are both sent back to the robot (when the communication bandwidth makes it possible), and provided to the system users (in support to robots operations) and to the CIM for further use with the crisis management authorities.

This component is just briefly introduced here, as the SDP and, in a greater extent, sensor data processing in View-Finder, is the main topics of a standalone RISE’08 paper.

4.4 Common issues and differences between the CMIS and the BS There are common issues and practical differences between some concepts of the BS and the CMIS

The mission templates proposed by the DMAP are different from the mission templates in the Base Station (BS): the mission templates in the BS refer to the tasks that the robots have to accomplish; for instance covering a zone, taking into account specific constraints, analyse a set of chemical products or acquire the information needed for a building reconstruction.

Nevertheless, regardless their conceptual difference, and for reasons of compatibility and effectiveness, both databases can be implemented using the same standards and exchange formats.

A distinction must be made between the Operators of the BS and the Users of the CMIS. The operators of the BS are experts in robot control and in interpreting the raw data gathered from the sensors (a semi-automatic classification of the sensor data can be made using the information contained in the base station mission template database). The CMIS users are experts in crisis management; this people are responsible for the crisis in the local coordination center and in the permanent coordination center, experts of different disciplines, as well as other actors as the civil protection and fire brigade. The Operator of the BD must be trained to use the interfaces proposed by the Base Station, whilst the Users of the CMIS do not need any special training; the CMIS interfaces will be ready to use for a standard user.

5 Conclusion This paper relates the View-Finder experience in the design of a robots management architecture, relying on user requirements expressed by crisis management organizations, including emergency services, firemen services, and both local and global crisis handling services.

One of the essential outputs of the VF project is the creation of a CMIS giving the possibility to the services involved in the crisis management to communicate and have an instant picture of the situation. The generic disaster management tools (DMAP), which consists in the implementation of well known disaster management methods, is intended to improve the effectiveness in the management of current and future crisis.

The base station is the in-situ operational node for the deployment and handling of View-Finder robots during a crisis, and for the acquisition and processing of robots’ acquired data.  It features operational mission planning and execution supervision tools, allows data recording and replaying for post-mission debriefing, and provides a full range of HMI modalities that fit different user roles in the base station: for robot operations, for data analysis and for operational decision making, in the scope of robots operations.

The VF system as a whole gathers the hardware and software tools to handle robots operations, to acquire relevant data and convey these data to the actors of the crisis management, and to communicate between these actors. As a result, significant improvement in crisis handling efficiency is expected.

6 Acknowledgement View-Finder is an EU funded project, referenced as: FP6 IST 045541. We would like to thanks all View-Finder project’s partners.

7 References  [ARKIN-92] R. C. Arkin. Cooperation without communication: Multiagent schema based robot navigation. Journal of Robotics Systems, vol. 9(3):pp 351-364, 1992.

[FONTAINE-96] B. Fontaine, L. Steinicke, and G. Visentin. A reusable and exible control station for preparing and executing robotics missions in space. In Proceeding of the SpaceOps conference, Germany, 1996. DLR.

[MACKENZIE-97] D. MacKenzie, R. Arkin, and J. Cameron. Multiagent mission specication and execution. In Autonomous Robots, number 1, pages pp 29-52, 1997.

[MEES-07] W. Mees. Information management for localized disaster relief operations. ISMCR 2007 21-23 June 2007 - Warsaw, POLAND.

[MOSHKINA-06] L. Moshkina, Y. Endo, and R. C. Arkin. Usability evaluation of an automated mission repair mechanism for mobile robot mission specification. In Proceeding of the 1st ACM SIGCHI/SIGART conference on Human-robot interaction, 2006.

[ORCHWINOASIS-05] ORCHESTRA Executive Board. Towards an open disaster risk management service architecture for INSPIRE and GMES. Internet Link http://www.eu-orchestra.org/docs/20050223_White%20Paper_v9.pdf

[POWELL-06] D. Powell, G. Gilbreath, and M. Bruch. Multi-robot operator control unit. In Proceedings of the SPIE, volume vol. 6230, page pp. 62301N, 2006.