Ioannis N Athanasiadis

How to start an environmental software project

de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Environmental software projects are intensive research collaboration projects, where research challenges go beyond a single discipline. Collaboration projects are typically characterised by heterogeneous actors with collective responsibilities and accountabilities, organised in geographically dispersed teams [START_REF] Brocke | Managing collaborative research projects: A synthesis of project management literature and directives for future research[END_REF]. Those aspects imply challenges for conventional project management approaches, and involve uncertainties about working and collaboration methods. A clear big picture of the project, where heterogeneous actors identify their roles and communicate effectively is the key for successfully managing collaborative projects. To this end, it is essential that actors involved develop early in the project a common language to share their ideas, and shape a common vision.

Voinov and Shugart suggested that we need more creativity in integrated modelling, instead of mechanistically plugging modules together [START_REF] Voinov | Integronsters', integral and integrated modeling[END_REF]. However, there has been little reported ever since, on how environmental software projects are set up in order to foster creativity. On the contrary, most interdisciplinary environmental modelling and software projects today are still organized in complex disciplinary hierarchies.

While this paper does not address the problem in its entirety, it introduces and evaluates a modus operandi for starting with an environmental software projects. It presents a single day workshop format that intends to lay the grounds for interdisciplinary teams to start communicating and collaborating effectively in integrated environmental software teams. The Inception Workshop is a participatory method to be applied at the start up stage of a project to explore the solution space or for early requirements analysis. The intention is to start a project with an event that allows for creativity, to charge heterogeneous actors involved, to start communicating effectively about their disciplinary interests, and work together beyond disciplinary barriers to identify and solve common problems.

The rest of this paper is structured as follows. Section 2 debriefs common attitudes in interdisciplinary projects and introduces the Inception Workshop objectives and participant roles. Section 3 presents implementation guidelines and Section 4 details an experimental setup, involving the two workshop installations, along with lessons learned in practice. Section 5 presents the workshop evaluation results, and conclusions are drawn in Section 6.

2

Materials and Methods

Domain understanding and common attitudes in environmental software

Domain understanding is generally acknowledged as a prerequisite for successful projects that involves information technology innovations, however it is often neglected. Software developers seem not to appreciate domain modelling, nor to recognize its importance in effective requirements engineering and risk management [START_REF] Offen | Domain understanding is the key to successful system development[END_REF]. A common attitude observed in several occasions in environmental software projects is that information engineers overestimate the capabilities of their solutions, while underplay the complexity of environmental systems. At the same time, environmental experts tend to underestimate the burden of technological solution deployment and system integration, they typically pass on the shoulders of the IT team. Both sides seem to spin a vicious cycle that creates great expectations on software solutions and drives projects to failure.

In environmental software projects we observe the same, recurring motif: Environmental modelling problems are convoluted for the IT experts, and information technology innovations are arcane for environmental scientists. The result is the illusion of the magic wand for environmental modelling: Information technology experts believe that they have one, while environmental experts expect that is going to work! Model integration and integrated modelling in environmental software projects is a challenging task for several reasons. [START_REF] Janssen | Managing the hydra in integration: Developing an integrated assessment tool for agricultural systems[END_REF] viewed integration in interdisciplinary modelling projects as a multi-headed Hydra snake, due to the many different types of integration that have to be achieved in parallel, and to the important role of communication [START_REF] Janssen | Managing the hydra in integration: Developing an integrated assessment tool for agricultural systems[END_REF].

For an environmental scientist it is costly to be involved in an interdisciplinary project, as it entails extra effort, for which there is not always appropriate academic credit, and the development of new skills. Rhoten [START_REF] Rhoten | Interdisciplinary research: Trend or transition[END_REF] notes that interdisciplinary research requires sharing existing information through "collegial" interactions, confirming that interdisciplinary science needs effective and active communication across disciplines.

Environmental software projects are also challenging for software experts. Software curricula cover a handful of application areas, and most textbooks have examples from the most common ones, let it be retail, finance, or entertainment. In this respect, IT experts are less prepared for science applications, and even less for interdisciplinary ones. With practicing the profession, software engineers become more experienced with certain application areas, and switching to a new one can be a very stressful experience. Bjørner estimates that "to establish a reasonably trustworthy and believable theory of a domain may take years, possibly 10-15!" [START_REF] Bjørner | Domain engineering[END_REF].

Environmental software projects are by definition interdisciplinary, and interdisciplinary science is founded on communication. This comes together with current practice in requirements engineering, as requirements gathering and agreement process has shifted from a documentation to a communication effort [START_REF] Zhang | Towards Lightweight Requirements Documentation[END_REF]. Traditional methods for requirement analysis as via detailed specification documents, questionnaires or interviews are not suited for environmental software projects. More agile approaches are better suited, as those using less formal means for team building, engaging with stakeholders, gathering requirements, and possibly involve rapid prototyping in small increments to verify them continuously with the end-users.

2.2

The Inception Workshop approach: purpose and objectives

Effective communication requires heterogeneous teams to speak the same language. In most environmental software projects this means that they need to invent it. To facilitate this goal, the Inception Workshop is proposed, an event that is expected to be the first meet-up of experts within an integrated project. At project starting phase, communication between team members is difficult. Each discipline has its own value systems, models of work, communication patterns, terminology and jargon. They look like knowledge islands with not much in common. Domain understanding is the bridge that will make these worlds collaborate effectively. Focusing early on building domain knowledge is essential for the success of an environmental software project, as it will help scientists to get out of their disciplinary safe house and foster collaboration. Interdisciplinary science can be achieved only by understanding better each other's scientific niche, while tackling together well-defined problems. This goes beyond superficial coexistence that is founded on short-lived meetups. Consilience is the key to interdisciplinary projects, as scientists not only need to interact with each other, but also have to engage in seeing the big picture.

In the case of environmental software projects, the more environmental scientists are exposed to innovative IT technologies, the easier it becomes to build confidence with IT processes and tools, and to engage actively in technical integration tasks. Similarly, there are benefits for IT scientists involved, as a dialogue with environmental scientists allows to identify early critical system aspects. In an environmental software project, IT experts need to get out of their cubicles and the tools they are locked-in with, and start working on interdisciplinary integration from the start of the project.

The Inception Workshop aims to establish communication bridges across heterogeneous team members in an environmental software project. It is intended for early project stages, for problem clarification and early requirements analysis. The goal of the workshop is to identify initial user stories, which will be further considered in the project. The main tool is to give the floor to scientists, members of a heterogeneous team to present their own expertise in an informal, open fashion. Team members interact intensively for a day, collaborate, and make their first achievements together.

When setting up the Inception Workshop format, it was assumed that time allotted is restricted. As integrated projects typically involve geographically distributed teams, we assume that there is available only one full day (or two half ones) which seems already too much for facetime in many collaboration environments. However, more time may be allotted, if conditions allow. Spontaneous, informal communications (that resemble standup meetings of agile programming) were intentionally preferred as opposed to structured formats preferred in academic fora.

In terms of preparation, team members are invited to come with no prepackaged content as presentation slideshows, or marketing pamphlets. All discussions are intentionally unpremeditated, unrehearsed. The invitation only sets the overall workshop goal in the form of a question, that does not impose any particular solution. It can be phrased as "How to improve the domain-specific system X (with technology offering Y)?". During the workshop, there is no speaker agenda, only a general structure for the discussion (see Table 1 below), with a single goal which is to identify one or more interesting user stories.

The general flow of the workshop is as follows. First, domain (environmental) experts get the floor to present their current (or intended) activity in a storytelling fashion, and altogether try to identify hotspots which are interesting or challenging, (or weak and tedious), and improvements seem needed. This identifies a first list of open problems that call for interdisciplinary intervention. Then, the team reflects on technologies and solutions that could potentially address some of the open problems. This is a spontaneous reaction in the form of sharing anecdotes or experience from previous projects from other fields. The final step is that the team tries to match hotspots with tools available to put together solutions and formulate them as user stories. Last but not least, priorities and risks are estimated for each user story.

2.3

Participants and Roles

There are three types of participants involved. Team members may have the role of environmental expert, IT expert and a facilitator. As interdisciplinary projects involve big teams, it remains a challenge to select the right people to invite. Readers may be refer to literature for stakeholder identification [START_REF] Glinz | Guest Editors' Introduction: Stakeholders in Requirements Engineering[END_REF][START_REF] Sharp | Stakeholder identification in the requirements engineering process[END_REF].

The facilitator is responsible for running the workshop according to the general schedule and to keep discussions focused. Experts tend to get excited with their work and thus dive fast into details, or divert the discussion to irrelevant topics. The facilitator is the one to give pace to the discussion, ensure that everyone gets the opportunity to contribute with their ideas and encourage participants to stand up. She should not be the one that needs to deliver the final outcome of the workshop, in the sense that the stress should not be on her shoulders. Her role is rather to stimulate critical thinking in a Socratic way, than that of the interrogator, and she is not expected publicly interview the experts in a panel discussion. She is not required to have a very deep understanding of the domains or the technologies presented, rather than appreciating the various disciplines involved, interdisciplinarity and the process of integrated modelling. She should be very experienced in discussion facilitation.

Environmental experts participate in order to represent their disciplines, and present obstacles in their everyday work practice, which they want to solve with environmental software. When invited they are asked to bring to the workshop documents, tools, photographs or other artifacts from their practice they thing they would like to show, and share with the rest team. While this sound odd, in practice it was proved a nice way to start the discussion. In the start of the workshop most participants feel a bit odd, so "What have you brought?" is a nice line to start with, though certainly this may not be working with all disciplines or cases.

IT experts come to the workshop to better understand the problem at hand, and do their first step in requirements elicitation, together with the rest of the team. The composition of the IT team is not restricted to analysts or designers, and certainly developers are welcomed. Our assumption is that IT scientists not directly involved may contribute. IT team members have a lot to gain in terms of domain understanding, and from engaging with disciplinary scientists. They are expected to show creativity and forward thinking and try to exemplify their technologies to the rest team. This is a crucial step for building confidence among the team members. Note that IT experts from different backgrounds may be less open to change, as new technologies may be disruptive to their routine.

The participation model is founded on open, democratic principles. While each organization involved in an environmental software project has its own structure and hierarchy, for this workshop participants are asked to contribute freely, directly, and simply. The facilitator needs to clarify from the beginning that the workshop is exploratory without formalities, and encourage participants to contribute. The facilitator is to protect the group from insisting participants that may slow down the discussion. At the same time, he makes clear that everyone has the right to speak, and he needs to accommodate time for all, while decisions are taken by the majority.

Implementation

Preparation and agenda

The workshop is intended to run for one or two days in a room with a round table. The equipment needed is a white-board or a flip-chart, pens, post-it notes and stuff brought by the participants. Part of the preparation is to provide food and beverages for coffee and lunch breaks. Table 1 presents a typical agenda. The workshop starts with a welcome from the facilitator and a short introduction round of the participants. The facilitator presents the workshop agenda and main question, and may give a couple of examples of user stories, if asked by the participants.

Part I: Storytelling

The first session focuses on domain understanding. The goal is to follow the current or future processes and increase the understanding of team members. Team share their knowledge across environmental domains involved in a storytelling fashion: They communicate their knowledge by sharing experiences and anecdotes. In a collaborative team environment, experts stand up to share their views of the system, while rest team members may intervene with clarifying questions. If needed, environmental experts may start drawing on flip charts to illustrate their claims. In other cases, they might show the stuff brought, that could be equipment, documents, or other exhibits of their practice. Each contributes with a partial view of the integrated system to be developed, undoubtedly biased by her own disciplinary background and intentions.

While the flip chart starts to fill up, and artifacts are on the table, participants are instructed to use post-it notes and identify "hotspots" that need intervention. These could be processes or activities that are popular, crucial or bottlenecks that are shared by team members. Discussions should not run into solutions at this stage, and participants are encouraged to flag hotspots, but reserve solution ideas for later. The facilitator needs to keep the storyline progressing, and prevent the team from diving into details.

Part II: Technology Roadshow

The second session, called technology roadshow, focus is on familiarizing the team with IT opportunities and identify possible solutions. This is achieved by working with examples and learning by analogy. This supports two objectives: First objective is to increase team awareness of IT tool capabilities, as potential options to adopt for certain problems. This will build interest in the beginning, and hopefully confidence at a later stage to (new) technologies for environmental software. Second objective is to identify via brainstorming possible solutions for the "hotspots" flagged in the previous session. Team members take turns and 'put guns on the table', i.e they exemplify how technical solutions might be used for tackling the problems presented before. Existing or new solutions are presented informally, in the form of examples. Solutions do not need necessarily be related to the problem at hand, but may come from other disciplines as well.

Simplifications are encouraged so that team members with different backgrounds get a grasp of how a solution works and which are the potential benefits. Participants are encouraged to ask questions, and the facilitator is responsible for moderating jargon language and reminding technical experts to use simple examples from applications known to the rest team members.

Part III: Synthesis of User Stories and Risks

The final session aim is to produce a synthesis of the two previous sessions. In a collaborative team environment, participants are challenged to interpret together the identified hotspots and the tools presented in order to form initial user stories. Agile requirements methodology considers user stories as very high-level definition of requirements, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it [START_REF] Cobb | Making Sense of Agile Project Management[END_REF]. In our case, initial user stories aim to produce high-level requirements of an environmental software system, often called epic in agile methodology.

The first part of this session is to identify user stories. Any workshop participant is free to summarize a solution of the equation hotspot + tool = user story. While a story is presented others may contribute to clarify or extend it. User stories at this stage are given short names and listed on the flipchart, so that participants may refer to them later on.

The second part of this session is to go through the user story list and set priorities in terms of effectiveness, risk and cost. While these are rough estimates, it is also interesting from a team building point of view, as it reveals the different priorities and perception of difficulty from heterogeneous team members.

Application

The Inception Workshop method presented above has been applied in two projects that the author has been involved in, and are shortly described below.

Workshop #1

The AITOLOS project aimed to identify smart ICT solutions to be incorporated into the everyday work of national forest protection services [1,[START_REF] Athanasiadis | Identifying Smart Solutions for Fighting Illegal Logging and Timber Trade[END_REF]. The project team consisted of forest service officers with several years of field work in forest protection, but from different functions, and software experts with varying expertise (business analysts, telecommunications, GIS, image processing, remote sensing, semantic web). In this team environment forest service officers were not proficient users of IT, and software experts had no prior experience in forestry applications. In order to identify potential solutions, a bidirectional knowledge shift between team members was needed, so that they develop a common language and achieve consensus.

The AITOLOS inception workshop took place in Thessaloniki, Greece, on January 25, 2013, with the participation of 12 environmental experts from the forest services of Kilkis and Goumenissa, in Greece, and 7 software experts from the Information Technologies Institute (CERTH), and the Surveying and Geomatics Department of TEI of Central Macedonia. The project was in the initial problem identification phase, and the main goal of the workshop was to answer the question: "How smart ICT solutions may be applied in forest service practice to combat illegal logging and timber trade?". After a single day of intensive discussions, the team concluded with seven user stories, spanning the whole lifecycle of logging and timber trade. The workshop findings are detailed in separate reports [START_REF] Anastasiadou | Complementary software solutions for efficient timber logging and trade management[END_REF][START_REF] Athanasiadis | Identifying Smart Solutions for Fighting Illegal Logging and Timber Trade[END_REF].

Workshop #2

The ALPINE project aimed to develop an intelligent, low-power sensor network architecture for environmental management. One of the two pilots is concerned with wildlife management, and specifically was concerned with how sensor networks can be used to improve the current situation with large carnivore monitoring and protection in the study area. Though the case study was different from the previous workshop, again the situation was similar: IT experts from industry and academia had very poor understanding of large carnivore protection domain, and wildlife scientists were not up to date with recent advances in IT. While the project was not in a very early stage, communication between the two sides was very slow and ineffective. Based on the first workshop experience, we decided to organize an event with the same structure, and monitor if it will help improving communications among the interdisciplinary team, and achieve some progress with the test case.

The ALPINE/Wildlife Inception Workshop was held in Xanthi, Greece, on February 13, 2014. We invited two wildlife scientists, working with different species and six IT experts. The the main goal of the workshop was to answer the question: "How intelligent sensor network technology and applications can be used for bear and wolf monitoring and management?". After a single day of intensive discussions, the team concluded with four user stories, three related to bear and one related to wolf management. One of those epics has been actually implemented in the project [START_REF] Athanasiadis | Towards a semantic framework for wildlife modeling[END_REF].

Evaluation

Methodology

In order to evaluate the effectiveness of the proposed method, in both experimental workshops we conducted a survey. The survey was done in two stages, with pre-and post-workshop questionnaires. Both questionnaires included the same set of questions, in which the respondents were asked to evaluate their familiarity with environmental domain concepts and procedures, and IT tools and technologies. Half of the questions were related to the application domain and the rest related to technology. All participants were asked to respond to all questions independently of their expertise. The level of familiarity was measured using a five-point Likert scale. A portion of the two questionnaires is presented in Table 2. The post-workshop evaluation form included questions to evaluate workshop performance and organization, adapted from [START_REF] Wgbh | Enhancing Education: A Producer's Guide[END_REF]. Workshop participants gave their oral consent to process their answers, given that no personal information are disclosed. In the first workshop, 14 out of 19 participants returned the questionnaire forms. In the second workshop, all seven participants returned the questionnaire forms.

Ethics statement

Voluntary feedback evaluation forms are commonly distributed in workshops. Participants of the two pilot workshops evaluation were exposed to no risk; there were no vulnerable populations involved; and no sensitive data were collected. For these reasons, no approval from an ethics committee/IRB was asked. Participants were informed briefly before the start of the workshop about the goals of this research and were given the option to fill in the pre-workshop questionnaire that was included in their folder.

The same happened with post-workshop questionnaires. The questionnaire forms included information about the researcher who conducted the study. The questionnaire forms included a written outline of the research purpose and contained a statement that completion and return of the questionnaire indicates consent to participate in the study. Written consent was not obtained as there was no risk for the participants; to ensure anonymity of the responses; and the involved procedures would not normally require written consent outside the purposes of this study. Completed questionnaire forms were returned in a box, while the researcher was not present. No private information has been disclosed. No penalty or consequences was implied by not filling in the questionnaire. No benefits or long term engagement was associated with participating to this study. Written responses were digitized, and original forms destroyed. Participants had the option to mention their name, a common practice for workshop feedback forms to build engagement and trust with a team. However, responses were treated anonymously. Anonymized responses of the questions relevant for reproducing the results presented in this manuscript have been archived on Zenodo [START_REF] Athanasiadis | Anonymized survey responses from two Inception Workshops[END_REF].

5.3

Results

Answers to pre-and post-workshop questions suggest that most participants felt more familiar with the domain concepts and related technologies after the workshop end. This can be considered as a sign of effective communication towards the development of a common language in a heterogeneous team.

We performed the Wilcoxon matched-pairs signed-rank test, a nonparametric method to compare before-after (or matched) questionnaires. The test was conducted to each participant matched responses before and after the workshop, to determine whether there was a statistical difference in their reported familiarity with the domains and technologies involved. The results are reported in Table 3, and indicate that in the vast majority of the participants, in both workshops, there was a statistically significant difference in their responses. For Workshop #1, the Wilcoxon analysis yielded with p < 0.05 for 10 out of 14 participants. The difference in average response was not due to chance for the majority of both domain and IT experts. For Workshop #2, the Wilcoxon tests reveals that shift in respondents' familiarity is statistically significant for five out of seven participants with p < 0.05.

Lessons learned

Both workshops concluded with valuable outcomes for each project, and participants in principle were satisfied with the workshop goals, structure, and process. However, the two workshops were executed in different ways.

In the first one, discussion went deep in operational detailed, which crunched the time available for risk estimation. However, this allowed us to identify many high-level user stories, and satisfied the project need for identification of alternative solutions. At the same time, the large number of participants made discussions last longer, and some of the domain experts had no opportunity to participate actively, rather they participated as observers. This was considered as a significant organizational drawback as it is commonly acknowledged that engaging with experts is hard to achieve, and their time shouldn't be wasted. Thus, in the second Inception Workshop, the same process was repeated with less number of participants. However, due to an emergency we missed one of the two domain experts, to our disappointment.

In the second workshop we experienced a better balance of time allocation between 'storytelling' and 'technology roadshow' sessions. The four user stories we concluded with were more detailed, tailored to the needs of the participants. In this respect, the workshop was less exploratory. Risk analysis and prioritization was done in more detail, also taking under account the limitations of the project. The take-home message from this installation was to host the workshop in the vicinity of the customer headquarters, if possible.

In both cases, the user stories were epic, in the sense that they can be broken down to smaller, more targeted stories [START_REF] Cobb | Making Sense of Agile Project Management[END_REF]. However, this was rather expected as the goal of these workshops was not to identify specific features to be implemented, rather it was to identify solutions to be subsequently specified in detail.

Conclusions

Domain knowledge is essential for heterogeneous teams that are challenged with integrated projects, as limited or no familiarity with a domain increases the risks for project failure. Domain knowledge is even more critical with increasing agility of the software development process. As interdisciplinary teams move from bureaucratic, plan-based processes to more iterative and less structured methods, requirements elicitation is transformed from an understanding and documentation activity to a learning and communication one. This paper argues that at the beginning of environmental software projects, more effective communication is required. While agile methods are well suited for ill-defined needs and ever-changing requirements, they assume effective communication among heterogeneous teams. This is certainly not the case in environmental software. As a remedy to this problem we presented the Inception Workshop to establish effective communication between team members, early in the project. With the Inception Workshop, a team of heterogeneous actors is challenged to collaborate for identifying user stories and associated risks for an interdisciplinary environmental software project. The method has been applied twice, and lessons were reported about the number of the participants, time allocation, specificity of the user stories. In both installations participant found the process stimulating and helped them to engage with each other.

Participants of both inception workshops were satisfied; and this is attributed to the fact that all had gains from the process. Some familiarized themselves with new domains, others with certain technologies. All participants learned new things, and had their say in the project start. A set of user stories to further develop in the project is a tangible result for everyone satisfaction. The workshops were also helpful in building team spirit due to the participatory sessions, where interactions brought participants closer. Questionnaire analysis of the two pilot workshops suggests statistical significance of the participant responses after the workshop. Though, participant enthusiasm and long-standing engagement to their project success is the stronger evidence of success.

Table 1 :

 1 Inception Workshop typical agenda

	Duration Topic	Lead participant
	30'	Welcome -The workshop process	Facilitator
		and introductions
	90'	'Storytelling'	Domain experts
		(Domain understanding session)
	30'	Short Break
	90'	'Technology roadshow'	IT experts
		(Explore technology opportunities)
	60'	Long Break
	60'	Synthesis	All
		(Define first user stories)
	30'	Short Break
	60'	Synthesis (cont.)	All
		(Set priorities and identify risks)

Table 2 :

 2 Questionnaires for the two workshops. The question was How familiar are you with...

	Workshop #1	Workshop #2
	1 Forest value	1 Value of ecosystems
	2 Forest office organization	2 Wildlife in Greece
	3 Forest management plans	3 Large carnivore movement patterns
	4 Forest products	4 Human-wildlife coexistance conflicts
	5 Legal logging processes	5 Wolf damages on livestock
	6 Forest product market	6 Human effect on wildlife habitat
	7 Taxes on loggers permits	7 Spotting wildlife
	8 Legal timber trade cycle	8 Trap and drug a bear
	9 Illegal timber trade cycle	9 Bear identification collars
	10 Cross-border illegal logging 10 GIS and maps
	11 GPS applications	11 Ecosystem population models
	12 GIS and maps	12 GPS applications
	13 Remote sensing	13 Delay tolerant networks
	14 Digital signatures	14 Knowledge modelling
	15 RFID tags	15 RFID tags
	16 Office applications	16 Barcode, QR code
	17 Barcode, QR codes	17 Software development
	18 Software development	18 Sensor networks
	19 e-governance	19 Low power sensors
	20 Social networks

Table 3 :

 3 Questionnaire statistics (Wilcoxon p-value) from the two workshops. The perception of each participant is evaluated with respect to her confidence to domain concepts and technology topics. Participants are identified with a letter and a number. The letter encodes the discipline of the participant -D for domain scientists and S for software experts.

		Workshop #1		Workshop #2
	ID	p value	p < 0.05 ID p value p < 0.05
	D1	0.002	*	D1	1.000
	D2	0.009	*	S1	0.070
	D3	0.009	*	S2	0.001	*
	D4	0.025	*	S3	0.001	*
	D5	1.000		S4	0.033	*
	D6	0.033	*	S5	0.000	*
	D7	0.057		S6	0.009	*
	S1	0.554
	S2	0.000	*
	S3	0.001	*
	S4	0.018	*
	S5	0.001	*
	S6	0.530
	S7	0.020	*

Acknowledgments

Author was partially supported by the Greek Secretariat of Research and Technology Collaboration (ALPINE grant 11SYN-6-411), and the IPA cross-border programme (AITOLOS grant IPA/2010/DN022619/CN314 294) which is co-funded by the EU and by national funds of the participating countries. The funders had no role in study design, data collection and analysis, decision to publish, or preparation of the manuscript. The author would like to thank the participants of both workshops for their encouraging comments.


Frank Fuchs-Kittowski
email: frank.fuchs-kittowski@fokus.fraunhofer.de

Michael Jendreck
email: michael.jendreck@fokus.fraunhofer.de

Ulrich Meissen
email: ulrich.meissen@fokus.fraunhofer.de

Michel Rösler

Eridy Lukau
email: eridy.lukau@fokus.fraunhofer.de

Stefan Pfennigschmidt
email: stefan.pfennigschmidt@fokus.fraunhofer.de

Markus Hardt
email: markus.hardt@fokus.fraunhofer.de

Frank Fuchs-Kittowski1
email: frank.fuchs-kittowski@htw-berlin.de

ENSURE -Integration of Volunteers in Disaster Management

Keywords: ENSURE, volunteers, crowd tasking, disaster management

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

In recent years, more and more citizens are willing to actively help during crises and disasters [START_REF] Ohder | Hilfebedarf, Hilfeerwartung und Hilfebereitschaft bei einem Stromausfall. Ergebnisse einer Bürgerbefragung in Berlin[END_REF], such as during the flood in 2013 in Saxony-Anhalt [START_REF] Geißler | Hilfeverhalten in Katastrophen und die Folgen für das Katastrophenmanagement -am Beispiel des Hochwassers 2013 in Magdeburg[END_REF]. The engagement of so-called "unbound volunteers" can be a valuable contribution while coping with a disaster [START_REF] Reuter | Social Media for Supporting Emergent Groups in Crisis Management[END_REF]. Nevertheless, this kind of support can be problematic if it is not coordinated by emergency personnel. The lack of efficient coordination can result in the support being ineffective, with overcrowded or understaffed operation sites. This can lead to frustration among the volunteers [START_REF] Kircher | Ungebundene Helfer im Katastrophenschutz[END_REF] and can hinder the actions of the emergency personnel or may even result in unintentional damages [START_REF] Schorr | Die Rolle der ungebundenen HelferInnen bei der Bewältigung von Schadensereignissen[END_REF]. Modern (i.e., interactive, collaborative, and mobile) technologies can help to effectively involve spontaneous unbound volunteers in disaster management in case of an emergency [START_REF] Mauthner | Informationstechnologien für das Freiwilligenmanagement in Katastrophenschutz und Krisenmanagement[END_REF]. Web 2.0 has created concepts of participation, such as crowdsourcing [START_REF] Howe | The rise of crowdsourcing[END_REF], which facilitate the engagement of volunteers and which have successfully been used in crisis management [START_REF] Kaufhold | Vernetzte Selbsthilfe in Sozialen Medien am Beispiel des Hochwassers 2013[END_REF], [START_REF] Schimak | Crowdsourcing in Crisis and Disaster Management -Challenges and Considerations[END_REF]. In addition, the widespread use of mobile devices among the population offers a high potential to change the means of communicating with citizens in the event of a disaster, and to simplify the participation of the citizens as active volunteers [START_REF] Reuter | Ad Hoc Participation in Situation Assessment -Supporting Mobile Collaboration in Emergencies[END_REF]. With the help of mobile applications, crisis management can provide current on-site information via mobile devices in real time as well as organize and coordinate the activities of the volunteers at specific locations.

This paper presents the ENSURE system, designed to effectively integrate volunteers for an improved approach to crisis management. The system enables the registration, coordination, and notification of volunteers. The paper is structured as follows: Section 2 provides a brief introduction into crowdsourcing and crowdtasking in the context of disaster management and the conceptual architecture of crowdtasking systems is presented. In Section 3, the ENSURE system is considered from a user's perspective by discussing the functions it provides. Details on the technical system architecture are presented in Section 4. A brief overview about implementation and evaluation of the system is provided in Section 5. Related work is discussed in Section 6. A summary of the paper is given in Section 7.

2

Mobile crowd sourcing and tasking in disaster management

Existing approaches and concepts

There is a variety of approaches to mobile IT systems for the integration of volunteers into crisis management. The majority of these systems are primarily designed for users to collect or assess information on their mobile devices, e.g., CrisisTrackers, Ushahidi, GeoChat, Mobile4D, Cross, Diadem, CrowdHelp, RE-ACTA. This type of involvement, in which simple, digital tasks are performed on-site by volunteers, can be described as "Mobile Crowdsourcing" [START_REF] Fuchs-Kittowski | Architecture of Mobile Crowdsourcing Systems[END_REF] (or "Mobile Crowdsensing", if data are captured using the built-in sensors of the mobile devices). A sub-form of mobile crowdsourcing is "Mobile Crowdtasking", in which volunteers undertake special physical tasks (such as filling sandbags, providing first aid to injured people, protecting cultural assets, securing dangerous places, etc.) and report on them if appropriate. Two forms of mobile crowdtasking can be distinguished based on the task distribution scheme [START_REF] Fuchs-Kittowski | Architecture of Mobile Crowdsourcing Systems[END_REF], with one approach being independent, autonomous task selection and the other coordinated task assignment. In the first case, the volunteers choose their own tasks from a pool of globally available tasks. In the second case, qualified volunteers are efficiently given appropriate tasks with the aim of fulfilling the objectives of the application as best as possible. In a narrower sense of the term, only the subcategory in which the volunteers are not addressed as a group, but rather assigned individual tasks, is referred to as crowdtasking [START_REF] Neubauer | Crowdtasking -A New Concept for Volunteer Management in Disaster Relief[END_REF].

The potential of crowdtasking systems remains largely untapped with only a few examples of such systems currently in use to assign real, physical tasks to volunteers (e.g., filling sandbags). Scientific approaches and projects for such integration of unbound volunteers are Hands2Help [START_REF] Hofmann | Hands2Help -Ein App-basiertes Konzept zur Koordination freiwilliger Helfer[END_REF], AHA [START_REF] Detjen | Nutzeranforderungen eines Systems zur automatischen Helferbereitstellung[END_REF], and KOKOS [START_REF] Kokos | Project-Website[END_REF]. In addition to these scientific approaches, there are already some projects based on practical experience, such as ZUKS [START_REF] Zuks E | ZUKS -Zivile Unterstützung im Katastrophenschutz -Konzept im Juni[END_REF], and Team Österreich [START_REF] Neubauer | Crowdtasking -A New Concept for Volunteer Management in Disaster Relief[END_REF], aimed at the coordinated involvement of volunteers. Other helpful systems such as Mobile Retter, instantHelp, FirstAED, or Pulsepoint (which notifies a registered user of an accident in the area according to the user's skills) are also aimed at involving and coordinating volunteers, but they are mainly used for ad hoc lifesaving, i.e., they are specifically designed for first aid, and not common tasks in crisis management.

All the approaches to mobile crowdtasking mentioned so far have the following points in common: they provide methods and tools to recruit a greater number of volunteers, mobilize and activate them when needed, and coordinate their activities. To achieve this, a specific control system is required in order to distribute the tasks to suitable volunteers. A mobile app is also necessary for the volunteer to receive the tasks, coordinate with others, get involved, and capture and send data or reports to the control system. Additionally, the data captured and the reports sent (e.g. about task fulfilment) by the volunteers have to be analysed and evaluated by the control centre to gain a better awareness of the situation and to support campaign and crisis management.

Conceptual architecture for mobile crowdtasking systems

Based on these application examples as well as proposals for a general architecture for crowdsourcing applications [START_REF] Fuchs-Kittowski | Architecture of Mobile Crowdsourcing Systems[END_REF], volunteer management systems [START_REF] Neubauer | Crowdtasking -A New Concept for Volunteer Management in Disaster Relief[END_REF], and a general process of crowdtasking [START_REF] Auferbauer | Moving towards crowd tasking for disaster mitigation[END_REF][START_REF] Middelhoff | Crowdsourcing and Crowdtasking in Crisis Management: Lessons Learned From a Field Experiment Simulating a Flooding in City of the Hague[END_REF][START_REF] Auferbauer | Crowdtasking: Field Study on a Crowdsourcing Solution for practitioners in Crisis Management[END_REF], we identify the following components of a general architecture for crowdtasking systems (see Figure 1).

Fig. 1. Conceptual architecture of crowdtasking systems

Typical roles within this architecture are "campaign manager", "crisis manager" (both within the control centre), and "volunteer (citizen)".

• Campaign manager (control centre): initiates and monitors the crowdtasking campaign, including the definition of the campaign as well as recruitment, control, and coordination of well-suited volunteers. • Volunteer (citizen): contributes to the crowdtasking campaign by (voluntarily) accepting and fulfilling tasks using his/her own mobile device. Often volunteers are members of the general public ("unbound volunteers"), but they can also be in a formal relation to the organizer ("formal voluntary engagement", see [START_REF] Neubauer | Crowdtasking -A New Concept for Volunteer Management in Disaster Relief[END_REF]). • Crisis manager (control centre): accesses and processes the data captured or reports sent by the volunteers for better situational awareness and crisis management.

The conceptual architecture is divided into three independent runtime systems:

• Backend system (server) with two main components: 1) Campaign Management provides subcomponents for Crowd or Volunteer Management (campaign planning, volunteer management, recruiting and maintenance of volunteers), and Crowd Task Management (task planning, selection of volunteers, distribution of tasks to volunteers). 2) Data Management contains components for data processing (preprocessing, storage, processing, and provisioning), data analysis (i.e. hazard detection, risk assessment), and notification/warning. • Mobile App (mobile client) for the volunteers with the components for Registration (motivation of volunteers, creation and maintenance of a volunteer profile), Mobile Notification (push notification, pull information), and Mobile Sensing (task control, data capturing, and data transfer). • Web App (web client) for the control centre providing dashboard features for Campaign Monitoring (campaign coordination, monitoring of task fulfilment), and Crisis Monitoring (situational awareness, decision support).

ENSURE system concept

In this section, the concept of the ENSURE system is presented. The most important functions of the system are discussed from the users' perspective. The aim of the system is to support disaster relief forces in recruitment, administration, activation, and coordination of volunteers in urban spaces in case of disasters. From the user perspective, the ENSURE system distributes help requests or alerts in the event of a hazard or emergency (Figure 2, 3, and4). These requests or alerts are delivered to the volunteers via a mobile app (Figure 5). Volunteers agree to receive requests through a subscriptionbased system. Therefore, the system provides certain functionalities such as

• Registration of volunteers,
• Profiling of volunteers,

• Notification of volunteers (see Figure 2, 3, and 4),

• Activation of volunteers (see Figure 5) by means of a mobile app for the volunteers (see Figure 5) and a coordination system (control centre) for the disaster relief forces (see Figure 2, 3, and 4).

Volunteer registration

Volunteers must first register via the mobile app in order to receive alerts. When the app is run for the first time, the user is presented with a project guide to encourage him/her to "join in". If the user decides to take part, this is technically equivalent to registering and is taken as implicit consent to create a user profile.

Volunteer profiles

One of the basic principles of data protection is data minimization. The ENSURE system implements this as much as possible. Only the following information is stored (anonymously) in the base profile of a user:

• Current location: It is necessary to know the approximate current location of the volunteer in order to send regional alerts. With regard to data protection and informational self-determination, a volunteer must actively agree, after registration, to receive regional alerts and accept that their location is therefore always recorded by the system. • Fitness level and social skills: In order to effectively activate volunteers in the event of a hazard or emergency, it should be possible to filter volunteers based on some properties. Information (subjective assessments) regarding physical fitness and social skills are stored in the base profile of the volunteer. This information is based on answers supplied by the volunteer to questions posed during the app setup.

In addition to the base profile, the system allows volunteers to add so-called "profile extensions". These profile extensions can provide information such as third-party verified qualifications (e.g., first aid), driving license class, technical expertise, etc.

Alerts

The help requests (or alerts) sent by the system to the volunteers are created by the app control centre by means of a web-based control system. Filtering and alerting of volunteers is a multistep process and proceeds as follows:

• Alert type: It must first be established whether to send a regional alert or a topicbased alert. • Filtering: Volunteers are chosen based on the location and time of the emergency, the number of volunteers needed, and any special skills that may be required. • Alert details: Additional information such as specific tasks, estimated duration of the emergency operation, instructions, etc., can be added to the alert. Volunteers can be alerted in one of two ways:

• The control system can trigger a regional alert to all volunteers in a given area (Figure 2, right and Figure 3). With this type of alert, volunteers receive a request if they are in the immediate vicinity of the emergency based on their current location. • Alternatively, volunteers can receive topic-based alerts by subscribing to a certain topic, e.g., "Flooding 2013 -Dresden" (Figure 2, left and Figure 4). The location of the volunteer does not play a role in this type of alert, and so does not need to be known. The volunteer can freely select which type of alerts to receive in the mobile app.

Fig. 3. Alerting of volunteers: coordination system (regional alert)

In addition to regional and topic-based alerts, alerts can be further classified as early warning alerts and ad hoc alerts:

• Early warning alerts: If the warning period is sufficiently long, the potential volunteers can be requested to confirm their willingness to participate in advance. This procedure can be used for both regional and topic-based alerts and is particularly beneficial for improving planning. A questionnaire can also be sent to the volunteers in order to collect information about special skills that may be required during the emergency operation. The results of the questionnaire are stored as profile extensions in the system and can be used as filtering criteria. • Ad hoc alerts: These alerts do not have a warning period or a planning phase. The idea is that volunteers in the immediate vicinity of an emergency (e.g., a medical emergency) arrive as soon as possible and provide first aid. In order to not lose time creating the alert, only the location and the emergency operation code must be given.

If the emergency is assigned an address, this is set automatically as the target location. Extra details can be entered in a free-text field in the creation form for the alert. As the control system is web-based, all fields of the alert form can be filled with URL parameters. Specialized procedures can pass pre-existing information to the control system via a URL link. Other functions that are available on the control system include:

• Sending updates to all users,

• Sending additional information about an emergency operation to all users taking part in that operation, • A detailed view of ongoing emergency operations (including volunteer feedback).

Volunteer activation

For activation (Figure 5), the selected volunteers receive a message via push notification on their smartphones. The users are shown all the information about the emergency operation in the app and can decide whether to accept or reject the request. They can also respond to a questionnaire regarding special skills for the emergency operation if one was sent with the alert. In this section, the architecture of the ENSURE system is presented (see Figure 6).

Components

The components of this system can be divided in seven logical parts (subsystems).

• Accepting and managing events (1). The Incident Content Management Endpoint is responsible for managing incoming events (alerts or requests from the control system). It accepts event messages (raw events) via different external interfaces and saves them in the Incident Content Storage. New or updated events are forwarded to the Incident Content Producer/Dispatcher and thus to the distribution system. • Distribution system (2). The Incident Content Producer/Dispatcher has two main tasks: it prepares the raw data of the incoming events and is responsible for the distribution system. ─ The processing is performed according to how the information will be further distributed. The system stores the data required for sending the notifications in the Demand/Incident Storage and informs the Incident Notification Generator about the new or updated event. It also generates the data required by the end users for the textual and graphical processing on their devices. These data are made available for retrieval via the Incident Content Cache. ─ The Incident Content Cache serves as a buffer for content to be delivered (e.g., events such as alerts or inquiries, additional information). The Demand/Incident Storage maps subscriptions from system users and event messages in a high-performance runtime model that facilitates efficient matching between both types of information.

Fig. 6. ENSURE -System architecture (mobile app, web app, backend)

• Content retrieval (3). The Content Endpoint provides the interface through which content may be queried. This includes queries of processed events and relevant additional information. The data are taken from the Incident Content Cache. The Content Endpoint is designed for maximum scalability and employs dynamic load distribution.

• Management of personal and device information (4). The Profile Endpoint presents the interface through which the user can query, add, or modify profile information. Similar to the Content Endpoint, the Profile Endpoint uses a dynamic load distribution in order to enable, among other things, multiple profile updates within a short period of time. The Profile Endpoint retrieves answers to queries from the Profile Info Cache, which holds frequently requested data as well as current profile information in a high-performance key-value cache. The Profile/Location Manager is responsible for managing all profile-related data in the system. User inquiries are forwarded to the manager if they cannot be answered directly from the Profile Info Cache. All data are persistently stored in the Location/Profile/Feedback Storage.

Changes to subscriptions are also send to the Demand/Incident Storage and forwarded to the Incident Notification Generator to check if a notification is required. • Notification service (6). The Incident Notification Generator is responsible for matching subscriptions (current position) and events. ─ The service has access to the Demand/Incident Storage, a special runtime database in which the subscription and event data have already been combined. The main task is to retrieve the mailing addresses of the relevant volunteers for each of the event messages and send these data to the Incident Notification Dispatcher.

In addition, this component has a store in which the notification statuses of the individual devices/users are held. ─ The Incident Notification Generator also informs other system components of which devices are expected to send queries in the near future before triggering the notification delivery. This makes it possible to prepare the system so that requested information is more readily available. ─ The Incident Notification Dispatcher is responsible for sending the notifications over different channels. It receives the event messages generated by the Incident Notification Generator along with the corresponding mailing addresses and sends the notifications. • User feedback (5). The Feedback Endpoint allows all user feedback (task accepted/rejected, feedback after completion of a task, as well as feedback regarding the basic profiling) to be received and forwarded to the Feedback Storage. Furthermore, the content management system can access all feedback information via this endpoint and prepare it for the dispatchers or use it as filter parameters (profile extensions) for the volunteer search. • System monitoring [START_REF] Howe | The rise of crowdsourcing[END_REF]. The System Watchdog is an instance of a checking system that checks to see if all active components are working properly within a given timeframe.

─ The so-called Heartbeat is a complex object that is regularly sent by each active component to the System Watchdog. This object contains, among other things, information on the current status, errors, processed objects, as well as environment variables (such as required memory). With these data, the System Watchdog can react in the case of faulty behaviour and take control using the Command Interface. ─ The System Logger receives log entries from all active components, prepares this information, and stores it in the System Logs Storage. Furthermore, it offers a request interface for retrieving log entries from both internal and external components, e.g., for support.

Performance, scalability, and data security

The system architecture was designed to ensure scalability, load balancing, performance, and availability. In order to realise the performance and scalability of the system, the following design decisions were consistently applied within the architecture and later in the implementation:

• Key-value caches are used to quickly respond to queries. These are designed for the purpose of load distribution using multiple distributable instances. The number of instances can be dynamically adjusted depending on the expected or actual load. Additionally, key-value storage instances provide advantages over relational storage instances in terms of scalability. • All data are persistently stored in databases. This means that all cache instances have persistent data storage. If an (unexpected) restart occurs, the information in the caches can be restored. • Communication between the individual components in the system backend is asynchronous.

Implementation and evaluation

The ENSURE system has been developed in an iterative process. In each iteration, new functionality is added to the system and evaluated. For the evaluation of the system, several alerting exercises as well as two large-scale field tests directed by the disaster relief forces in Berlin (Berlin fire brigade and red cross) are carried out. The results of evaluations are used for improvement of the existing system, which will be evaluated in the next iteration.

The implementation of the system is based on the following technologies:

• The mobile client, used by the volunteers, was implemented as a native mobile app for the mobile platforms iOS and Android. • The control system, used by the control centre, was implemented as a single-page web application using the client-side JavaScript framework AngularJS. • The backend, providing the functionality for the two clients and ensuring satisfaction of non-functional requirements like performance, robustness, and scalability, was implemented using server-side JavaScript technology included in the MEAN stack (MongoDB, Express.js, AngularJS, and Node.js) as well as Redis as a key value store.

A comprehensive evaluation of the system was performed as a large-scale exercise directed by the disaster relief forces in Berlin. In total, 24 volunteers and 120 aid workers took part in this exercise. Volunteers had to fulfil 14 different tasks before the arrival of the aid forces as well as simultaneously with the work of the disaster relief forces.

The evaluation criteria concentrated on the three established requirements on software applications in disaster management [START_REF] Mauthner | Informationstechnologien für das Freiwilligenmanagement in Katastrophenschutz und Krisenmanagement[END_REF]: efficiency & security, clarity & usability, reliability & availability. The evaluation results were, without exception, positive in all three evaluation areas. In particular, the app was found to be very usable (SUS score: 90 points), highly stable, and had short response time as well a good success rate when storing a personal profile. First aid tasks were especially well performed (observation) and the volunteers followed instructions very accurately (clearing vehicle access routes, etc.) (See [START_REF] Jendreck | ENSURE -Increasing resilience by integration of volunteers in disaster management[END_REF] for details.)

Currently, another large-scale field-test of ENSURE is taking place in Berlin under the name "Support the Berlin fire brigade". The ENSURE app is available in app stores (iOS and Android) for the field test so that anyone can participate as a volunteer in the exercise.

Related work

Overall, the ENSURE approach described above has a number of similarities with existing concepts and systems (see Section 2.1), but it also shows significant differences. The aim of the ZUKS project (Zivile Unterstützung im Katastrophenschutz) is to acquire helpers and to organise and deploy them. Similar to the ENSURE project, notification, organisation, and coordination is carried out using a control system. Activating previously registered helpers and sending task details is done analogously to a smartphone app. However, there is a considerable divergence in the integration of both systems. ENSURE provides the technical platform to the emergency and rescue services for free use; in contrast, the ZUKS project integrates the separate organisations into the existing system, and then the system manages the helpers. Furthermore, ENSURE is defined by anonymous registration and the continued organisation and coordination of helpers on the ground (including food and accommodation).

Similar to ENSURE, the Hands2Help project offers an app-based coordination and notification system that is designed to support emergency and rescue services in coordinating volunteers. Control centres can define a request for help by filling out a form. Volunteers can offer help and indicate their abilities through the app. If the system detects a match between an offer and a request, the relevant users are automatically contacted. This continues until the appropriate number of suitable volunteers is found. In contrast to ENSURE, no control system is provided for manual notification of volunteers by a control centre since the matching between offers and requests as well as the notification is automatically taken care of by system algorithms. The fact that every user can publish a request for help also differentiates both projects. In addition, Hands2Help requires compulsory data on the availability of the users with regard to time and location. ENSURE, in addition to notifying volunteers based on their location, offers topic-based notifications that do not require the location data of the volunteers.

The AHA project (Automatisiertes Helferangebot bei Großschadensereignissen) and the KOKOS project (Kooperation mit freiwilligen Helfern in komplexen Schadenslagen) both run parallel to the basic idea of ENSURE and also have the goal of involving the population in dealing with damage. However, there are differences in the concrete implementation of this objective. The KOKOS project focusses on integrating the public into crisis management. In addition to the volunteers themselves, the AHA project especially considers the technical equipment of the volunteers to be a useful resource, and it requests and registers availability.

In the Team Österreich project, volunteers can be registered with the Red Cross Austria as helpers and can be notified via various channels (SMS, email, etc.) in case of an emergency. Suitable volunteers are identified for a task, taking into account their place of residence as well as distance to the task location, so that enough volunteers with the right skill set are automatically notified. ENSURE relies on a content management system, which allows control centres to notify a certain number of volunteers and if necessary, request more help. The ENSURE app also offers users the possibility to report a delay in arriving at the task site so that the "non-appearance" of helpers can be taken into account by the control centre and included in the planning and coordination.

Conclusions

Disaster management is currently changing. On the one hand, citizens are very willing to actively help during crises and catastrophes and support the local emergency services. On the other hand, citizens are also increasingly seen as major players and a key resource in disaster relief. Nevertheless, the integration of volunteers into disaster management is still in its infancy. There are a variety of approaches to implementing mobile IT systems for integrating citizens into crisis management. However, the potential of crowdtasking systems remains largely untapped with only a few examples of such systems in existence and a low level of interest and consideration in the research community.

This paper presents the ENSURE system. The goal of ENSURE is to effectively integrate volunteers for an improved approach to disaster management. The system enables the registration, coordination, and alerting of spontaneous volunteers. The functionality and architecture of the system are described in detail. ENSURE provides a concrete example that mobile crowdtasking applications can contribute to the effective involvement of volunteers in disaster relief.

A general, conceptual architecture for mobile crowdtasking systems was also proposed in this paper. The characterisation of mobile crowdtasking systems helped to understand the individual components and their attributes as well as the existing relationships and interdependency among the components, as determined by the system as a whole. The generic system architecture allows specific applications to be designed, classified, and evaluated, e.g., the ENSURE system.

The system architecture of ENSURE is not only an example of the use of the conceptual architecture. It is also an example of a system architecture that ensures scalability, load balancing, performance, and availability. It demonstrates the feasibility of developing robust crowdtasking applications. Identifying variables and features that affect the scalability and performance of a system is helpful when planning its design or making improvements to it once it is in operation.

The great potential, but also the associated difficulties, are only slowly coming to light. Questions regarding the validation and quality of the services provided by the volunteers as well as the handling of data protection issues arising from the use of personal data are currently being discussed. In addition, volunteer motivation and incentive systems for volunteer participation are important issues. In the end, evaluations of emergency operations must show how much the operations could be improved by the participation of the volunteers.

The systems that are known so far for the successful integration of the population into disaster relief show the starting points for the necessary change: citizens should not only be seen as recipients, but as an important resource in disaster management. Even though there may already be some examples of citizen integration in crisis management, these are always isolated and individual cases. So far, there is no unified, integrated concept covering all phases of disaster management, in which the different parties -professional forces, volunteer forces, and citizens -are well coordinated.

Fig. 2 .

 2 Fig. 2. Alerting of volunteers: coordination system (left: topic-based alert, right: regional alert)

Fig. 4 .

 4 Fig. 4. Alerting of volunteers: coordination system (topic-based alert)

Fig. 5 .

 5 Fig. 5. Volunteer activation via the mobile app


Nikos Katsifarakis
email: nikolakk@auth.gr

Kostas Karatzas

A new feature selection methodology for environmental modelling support: the case of Thessaloniki Air Quality

Keywords: Air quality, Feature selection, Self-Organizing Maps

Environmental systems status is described via a (usually big) set of parameters. Therefore, relevant models employ a large feature space, thus making feature selection a necessity towards better modelling results. Many methods have been used in order to reduce the number of features, while safeguarding environmental model performance and resulting to low computational time. In this study, a new feature selection methodology is presented, making use of the Self Organizing Maps (SOM) method. SOM visualization values are used as a similarity measure between the parameter that is to be forecasted, and parameters of the feature space. The method leads to the smallest set of parameters that surpass a similarity threshold. Results obtained, for the case of Thessaloniki air quality forecasting, are comparable to what feature selection methods offer.

Introduction

Environmental systems are complex, in terms of the parameters required to describe their status and spatiotemporal behavior. It is therefore expected that relevant models are complex as well, involving a large number of features. In the case of urban air quality systems [START_REF] Gulia | Urban air quality management-A review[END_REF] such parameters can be pollutant levels, meteorological conditions and any other feature that describes the impact that the atmospheric environment poses on human life [START_REF] Chen | A systematic review of the relation between long-term exposure to ambient air pollution and chronic diseases[END_REF]. Such features are commonly used as inputs to various datadriven environmental models [START_REF] Araghinejad | Data-Driven Modeling: Using MATLAB® in Water Resources and Environmental Engineering[END_REF], while some of them contain very little or no valuable information for the purposes of the model they are fed into. Therefore, it is necessary to select the most appropriate ones and thus reduce their number, using feature prioritization and selection methods [START_REF] Mesin | A Feature Selection Method for Air Quality Forecasting[END_REF]. In this paper, two well-established feature selection methods are used as a reference, while a new feature selection method based on Self Organizing Maps (SOM) is introduced. Methods are compared in terms of forecasting performance for a number of Computational Intelligence (CI) oriented models, for the case of air quality forecasting in Thessaloniki, Greece.

The case study

The application domain of this study is urban air quality in the area of Thessaloniki. It is the second largest city of Greece, characterized by high urbanization and a heavily used traffic network. Its wider area covers approximately 93 km 2 and has a population density of around 16000 inhabitants per km 2 . Thessaloniki is located in the inner part of the Thermaikos gulf and has Hortiatis mountain and the Seich Sou forest to its north and north -east respectively, while the industrial zone is situated on its western part [START_REF] Voukantsis | Intercomparison of air quality data using principal component analysis, and forecasting of PM10 and PM2.5 concentrations using artificial neural networks, in Thessaloniki and Helsinki[END_REF]. Regarding its air quality, it is characterized by very high levels of PM10 [START_REF] Moussiopoulos | Air quality status in Greater Thessaloniki Area and the emission reductions needed for attaining the EU air quality legislation[END_REF].

Available data include daily averages of air pollutant concentration levels (PM10, CO, NO2 and O3 in μg/m 3 ), as monitored at seven stations located in different areas of the city, for the years 2000 to 2013 (a total of 17 features). In order to better evaluate the new proposed feature selection method, features with many missing values were omitted, this being the reason that the used dataset contains no meteorological parameters. A map of the city is presented in Figure 1, where the seven stations (Agia Sofia, Aristotle University, Kalamaria, Kordelio, Panorama, Sindos and Neochorouda) are marked.

The proposed methodology

With the aim of the study being the presentation and evaluation of a new feature selection methodology, two feature selection methods were rendered to be appropriate as reference methods, implemented in the WEKA computational environment [START_REF] Hall | The WEKA Data Mining Software: An Update[END_REF]: (i) the Correlation -based feature selection (CfsSubsetEval) [START_REF] Hall | Correlation-based feature subset selection for machine learning[END_REF], and (ii) the ReliefFAt-tributeEval [START_REF] Kira | A Practical Approach to Feature Selection[END_REF] The CfsSubsetEval method was chosen, as (a) it can be used in regression problems (i.e. the problem category where arithmetic values of feature(s) are forecasted), (b) it focuses on maximizing the forecasting ability of a model (our goal in this study), and (c) it employs features that demonstrate high predictive ability (i.e. lead to better forecasting statistics) and low intercorrelation [START_REF] Yue | Correlation-Based Feature Selection and Regression[END_REF]. The ReliefFAt-tributeEval method was chosen as it takes into account feature interrelationships by assigning a grade of relevance to each feature and then selecting those that are graded over a user given threshold [START_REF] Arauzo-Azofra | Self-Organized Formation of Topologically Correct Feature Maps[END_REF].

The new feature selection method proposed makes use of the SOM method. SOMs are based on neural networks composed of a two-dimensional array of (initially) randomly weighted neurons [12]. All data points are passed through the neural network and are matched with a winning neuron, causing the network topology to adjust and eventually form clusters of similar attributes, while weights are updated to better fit into the process. The unified distance matrix (U-matrix) commonly used for SOM visualization, represents the Euclidean distance between neighboring neurons which is actually an expression of the relationship ("similarity") between neighboring neurons [START_REF] Ultsch | Kohonen's Self Organizing Feature Maps for Exploratory Data Analysis[END_REF].

Here, the SOM Toolbox for Matlab [14] was used, as it offers a stable and commonly used implementation of the method. A typical example of the SOM representation, generated with the Matlab toolbox for the data used in this study is presented in Figure 2 that contains a SOM for each parameter, as well as the U -matrix. Each SOM visualizes the areas where the corresponding variables have high or low values (blue colors here correspond to low values and red to high), and the U -matrix indicates the distance between neighboring tiles (neurons). Thus, similarities between maps are indications of interrelationships between the corresponding parameters. For example, the maps of Ozone in the area of Agia Sofia (O3_ag.sof) and Ozone in the area of the Aristotle University of Thessaloniki (O3_auth) present with high values in their upper parts and low values in the lower parts, thus they look topologically similar. This indicates that there is strong relationship between these two features.

For each of the 17 parameters -features, the SOM method generates a topographic map presenting the weight values for the neurons in each of the SOM nodes. These values are stored in an M*N matrix, where M is the number on nodes that the aforementioned maps contain, and N is the number of the features. In this way, the values at each column represent the relevant weight ("importance") of each feature for the nodes within the SOM.

After one of the features is set as the parameter of interest (forecasting goal), the method aims at identifying the features that maximize the forecasting ability of the mode(s) to be used. For this purpose, we make use of the values of the M*N matrix W of the SOM weights. As the method is based on the weights of the existing features, we introduce a number of N random additional "features", so that the weight matrix doubles its columns becoming an M * 2N matrix. This is done in order to enlarge the population of candidate features to be selected by introducing features that are not related whatsoever with the problem under investigation, thus acting as indicators of "noise" and therefore be used as a selection threshold criterion as explained next.The weights matrix is then normalized, so that its values become (real) numbers between 0 and 1. In the next step, each feature column N is compared with that of the -parameter of interest, element by element, to determine how many values are either very similar, or complementary (i.e. have a sum close to 1), according to Eq 1. An arbitrary parameter α is introduced, to quantitatively express the relationship between values being compared, α being a positive real number close to zero.

|Tar(j) -Feati(j)| ≤ α or | Tar(j) + Feati(j) -1| ≤ α

(1)

Here Tar(j) is the j-th element of the target -parameter column and Feati(j) is the j-th element of the column of the i-th feature. Thus, the initial M*2N matrix is transformed to a new one, S, with each column representing the same feature as the initial matrix, but with each element being equal to either one (when the original map's corresponding element is very similar or very complementary to the one of the targetparameter), or to zero otherwise. With this new matrix, the feature that has the highest sum of values ("ones") is selected as the first feature of the current selection CL, and then the rest of the features are ranked accordingly. Then, a new ranking takes place, in which the remaining features are ranked again on the basis of Eq. 1, according to the amount of elements equal to "ones" they present, for element locations that the current selection demonstrates "zeros". Αgain, the feature that ranks first is selected, thus replacing the "zeros" of the current selection at the places where the newly selected feature had "ones". In this way, features are "completing" each other in order to be part of the population of the selected features, in an effort to maximize the amount of ones with the least possible features. This procedure also makes sure that there will be no redundancy, as simi-lar features will have "ones" in similar places, therefore if one of them is selected, the rest will rank poorly in the next ranking round. The overall algorithm is presented in Table 1. This process terminates once the maximum amount of ones is reached, or when one of the random "features" is selected, as this will indicate that the rest of the features offer little to no useful information for the parameter of interest. In this way, a set of features that describes the biggest part or the SOM concerning the parameter of interest is determined.

Results and discussion

The parameter chosen to be forecasted as a test for the proposed methodology, was Ozone from the Panorama station (a typical inhabited urban area). The algorithms used for developing the forecasting models were Linear Regression (LR) [START_REF] Rencher | Chapter 10, Multivariate regression -Section 10.1, Introduction[END_REF] and Multilayer Perceptron (MLP) Artificial Neural Networks [START_REF] Rumelhart | Learning Internal Representations by Error Propagation[END_REF], since they are very commonly used in regression problems and have led to high AQ forecasting accuracy for the same geographic area [START_REF] Voukantsis | Intercomparison of air quality data using principal component analysis, and forecasting of PM10 and PM2.5 concentrations using artificial neural networks, in Thessaloniki and Helsinki[END_REF]. Computations were again performed in WEKA [START_REF] Hall | The WEKA Data Mining Software: An Update[END_REF]. Both LR and MLP were used for the cases of (a) the complete set of features, (b) the sets of features suggested by the CfsSubsetEval and ReliefFAttributeEval methods, and (c) the features resulting from the suggested methodology, for each value from 0.005 to 0.5, with a step of 0.005, for the parameter α. It should be noted that model development and training was made via the 10-fold cross validation method [START_REF] Kohavi | A study of cross-validation and bootstrap for accuracy estimation and model selection[END_REF].

The comparison of the CI models' performance with the set of features presented in each case, as well as these of the CfsSubsetEval and ReliefFAtttributeEval methods are presented in Figures 3, 4 and5. Results indicate that even a slight change in α can lead in different sets of features being selected. In more detail, for low values of α, (from 0.005 to 0.11), all the feature sets resulting from the new proposed method lead to better LR performance in comparison to the feature sets from both the reference methods (with 0.8382 being the highest value for correlation coefficient, 1.7% higher than the CfsSubsetEval method and 7.85% higher than ReliefFAtttributeEval method), while regarding MLP, they all outperform the ReliefFAtttributeEval method, and most outperform the CfsSub-setEval method as well (with 0.8332 being the highest value for correlation coefficient, 3.92% higher than the CfsSubsetEval method and 6.75% higher than ReliefFAt-ttributeEval method). Values of 0.115 to 0.17 for α lead to the feature set with the poorest performance of all the sets offered by the new proposed method. Values of α between 0.175 and 0.295 lead to different sets that perform close to the set offered by the CfsSubsetEval method with LR and somewhere between the two reference methods with MLP. Finally, for α varying between 0.3 and 0.5, the feature set offered by the new proposed method does not change, and performs close to the set offered by the CfsSubsetEval method with LR and worse than the two reference methods with MLP, however, with only two features, as opposed to the four of the CfsSubsetEval method and the five of the ReliefFAtttributeEval method.

The most popular features among all the offered feature sets are Ozone from the Kordelio station, which is also selected by the CfsSubsetEval method, and Ozone from the Neochorouda station, which is selected by both the reference methods as well. This selection seems very plausible, as it makes sense for the same pollutant from the other stations to be more correlated to our target -parameter than other atmospheric quality parameters.

Overall, the CI model's performance is comparable to this of the sets presented by the CfsSubsetEval and the ReliefFAtttributeEval methods for each α. Table 2 presents the mean value and standard deviation of the CI models' performance for every α between 0.005 and 0.3 (as after 0.3 the results remain the same). Table 2 indicates that even a poor choice of α will outperform the ReliefFAt-ttributeEval method, and perform close to the CfsSubsetEval method. The low standard deviation of the results, despite the number of different set of features offered, shows that the concept of complementarity of features with the aim of maximum similarity with the target -parameter will always lead to acceptable results for the case under investigation. It is also apparent that there are values of α that lead to sets of features which outperform both the ReliefFAtttributeEval and the CfsSubsetEval methods, as well some that lead to good performance with less features. For reasons of further investigation, the same tests were also run for a different pollutant and monitoring station, namely NO2 for the Sindos station. The mean value and standard deviation of both models' performance is presented in Table 3. It should be mentioned that in this case results did not change for any α greater than 0.27. Again low values for α lead to feature sets with better performance, at times superior to the two reference methods, with the maximum correlation coefficient for the LR model reaching 0.74 (for a=0.11) while for the MLP model it was 0.67 (again for a=0.11). Reference methods on the other hand led to the feature sets that correspond to the modelling results presented in Table 4, demonstrating better performance in comparison to the mean performance indicators of Table 3. Table 3. Mean value and standard deviation of the CI models' performance for NO2 for the Sindos Station, with the sets of features from the suggested methodology, for every α between 0.005 and 0.27.

Mean

Conclusions

In the present paper a new methodology for feature selection in data-driven air quality forecasting problems is presented and compared with two existing and commonly used feature selection methods, namely CfsSubsetEval and ReliefFAttributeEval. The new method is based on SOMs thus making use of additional information concerning feature interrelationship and cross-influence. Two air quality forecasting models were used for testing the performance of the feature selection methods, one being a standard multivariate Linear Regression model and the other being an Artificial Neural Network of the Multi-Layer Perceptron type. Model results show that the new feature selection method is comparable to the reference ones, while being also able to outperform them producing results up to +7.85% for the correlation coefficient, provided that computational experiments take place in order to determine the values for the selection parameter a (alpha). As such, this approach seems promising, and is offered for further investigation, involving testing additional cases while also improving the estimation of the alpha parameter.

Fig. 1 .

 1 Fig. 1. Map of Thessaloniki, marking the seven air quality monitoring stations used in the current study.

Fig. 2 .

 2 Fig. 2. A typical SOM representation of the case under study.

Table 1 .

 1 The new feature selection algorithm based on SOM Algorithm SOM_Feature_Selection ! N: the initial number of features ! M: the number of data rows (time stamps) in the data matrix ! Tar: the target parameter to be forecasted Get W; ! this is the SOM weights matrix CL := []; ! initialize current selection W := [W, rand(size(W))]; ! introduce N new random features NW := Normalized(W); ! normalize the SOM weights matrix S := zeros(size(NW)); S(|Tar(j) -Feati(j)| ≤ α or |Tar(j) + Feati(j) -1| ≤ α) := 1; S2 := AddAllValuesPerLine(S) -ones(M,1); maxsim := (M -Sum(S2 == 0)) / M; R := Rank(features(feature != Tar)) ; !Ranks according to Sum(S(:,i)), i = 1, …, 2N CL := [CL, R(1)]; begin R := Rank(features(feature != Tar, feature not in CL)) ; !Ranks according to !Sum(S(:,i)), i Є[1, 2N] and S(:,CL(i)) == 0 CL := [CL, R(1)]; until Rank(1) > N or Sum(CL(CL == 0)) == 0 if CL(end) > N then CL := CL(1:end-1); end if end

Fig. 3 .

 3 Fig. 3. Number of features of each feature set proposed by the SOM -based methodology, compared with these of the CfsSubsetEval and ReliefFAtttributeEval methods.

Fig. 4 .

 4 Fig. 4. Correlation coefficient of Linear Regression with each feature set proposed by the SOM -based methodology, compared with these of the CfsSubsetEval and ReliefFAtttributeEval methods.

Fig. 5 .

 5 Fig. 5. Correlation coefficient of Multilayer Perceptron with each feature set proposed by the SOM -based methodology, compared with these of the CfsSubsetEval and ReliefFAt-ttributeEval methods.

Table 2 .

 2 Mean value and standard deviation of the CI models' performance for Ozone for the Panorama Station, with the sets of features from the suggested methodology, for α varyingbetween 0.005 and 0.3.

		Mean	Standard Deviation
	Linear Regression	0.8202	0.0156
	MLP	0.7848	0.0262

Table 4 .

 4 Performance of the CI models with the feature sets offered by the two reference feature selection methods, for NO2 and for the Sindos station.

			Standard Deviation
	Linear Regression	0.7049	0.0173
	MLP	0.6261	0.0258
		CfsSubsetEval	ReliefFAttributeEval
	Linear Regression	0.7317	0.6931
	MLP	0.6564	0.6286