SPESSS - SPecial Event Support by Satellite System Final Review ...

SPESSS (SPecial Event Support by Satellite System)

GJU Contract Number : GJU/05/2423/CTR/SPESSS

SPESSS Final Review Report(Version 1.0 23/07/2007) 1/98

SPESSS - SPecial Event Support by Satellite System

Final Review Report

“SPESSS” SPecial Event Support by Satellite System

GALILEO Joint Undertaking AREA 3: Innovation by Small and Medium Enterprises

Project GJU/05/2423/CTR/SPESSS

Deliverable D11 Version 1.0 Final VERSION – July 23, 2007

Document: SPESSS_FR_Report




Programme Name: …………………….GALILEO Joint Undertaking: GJU/05/2423/CTR/SPESSS AREA 3: Innovation by Small and Medium Enterprises

Project Number: ................................. GJU/05/2423/CTR/SPESSS

Project Title: ....................................... SPESSS

Partners: ............................................Coordinator: NEXT - Ingegneria dei Sistemi S.p.A. (IT). Principal Contractors: Rigel Mobile Service Provider S.A. (ES)

Document Number: ........................... D11

Work-Package: ................................... WP1000

Deliverable Type: ................................ REPORT

Contractual Date of Delivery: ........... MONTH 12

Actual Date of Delivery: .................... MONTH 14

Title of Document:.............................. FINAL REVIEW REPORT

Responsible:........................................ NEXT

Author(s): ........................................... NEXT

Approval of this report: .................... GSA

Summary of this report: ....................The report covers all the technical work performed by the consortium, provides an analysis of objectives, results and conclusions, and the final plan for using and disseminating the knowledge, including a summary of all these aspects

History:................................................ Version 1.0 23/07/07

Keyword List: ....................................project, architecture, plan, components, software, system

Classification:.....................................DELIVERABLE

Availability: ......................................... INTERNAL




DOCUMENT STATUS SHEET

Version Date Description of evolution Modifications

1.0 09/03/2007 Final Version None

DISTRIBUTION LIST

Company Name Role e-mail

GSA Eric Guyader GSA Project Manager [email protected]

GSA Aydin Ciliv GSA Project Controller aydin.ciliv@ ext.ec.europa.eu

NEXT S.p.A. Luigi Mazzucchelli SPESSS Coordinator [email protected]

NEXT S.p.A. Antonio Casoria SPESSS Project TM [email protected]

RIGEL S.A. Luis Alcántara RIGEL Project Manager [email protected]

ESYS plc Ian Jory GJU Assistant Evaluator [email protected]




Table of Contents1 EXECUTIVE SUMMARY .............................................................................................................. 12

2 INTRODUCTION ............................................................................................................................ 14 2.1 DOCUMENT STRUCTURE....................................................................................................... 14

3 PROJECT OVERVIEW.................................................................................................................. 15 3.1 PROJECT PRESENTATION ...................................................................................................... 15 3.2 OBJECTIVES OF THE PROJECT ............................................................................................... 16 3.3 ENDORSEMENT..................................................................................................................... 17 3.4 PROJECT SCHEDULING.......................................................................................................... 18

3.4.1 The project GANTT.............................................................................................................. 20 3.5 WORK BREAKDOWN STRUCTURE ......................................................................................... 21 3.6 LIST OF DELIVERABLES........................................................................................................ 22

3.6.1 Project management plan .................................................................................................... 22 3.6.2 Requirements analysis ......................................................................................................... 22 3.6.3 Preliminary system design ................................................................................................... 22 3.6.4 Detailed system design......................................................................................................... 23 3.6.5 Technology transfer plan ..................................................................................................... 23 3.6.6 Dissemination plan .............................................................................................................. 23 3.6.7 Results analysis and recommendations ............................................................................... 23 3.6.8 Software prototype............................................................................................................... 23 3.6.9 Analysis phase review report ............................................................................................... 23 3.6.10 Mid term report.................................................................................................................. 23 3.6.11 Final review report ............................................................................................................ 23 3.6.12 State of the art.................................................................................................................... 23

3.7 THE INNOVATIVE APPROACH................................................................................................ 24 4 TURIN 2006 WINTER OLYMPIC GAMES DEMONSTRATION............................................ 25

4.1 THE DEMONSTRATION SCENARIO......................................................................................... 25 4.2 DEMONSTRATION OVERVIEW............................................................................................... 25 4.3 TURIN DEMONSTRATION OPERATION ................................................................................... 27

4.3.1 Pre-operation activities ....................................................................................................... 27 4.3.2 The demonstration operation............................................................................................... 28

4.4 DEMONSTRATION FEEDBACKS AND RESULTS ...................................................................... 30 4.4.1 Users feedbacks ................................................................................................................... 30 4.4.2 Demonstration results.......................................................................................................... 31

5 ANALYSIS PHASE.......................................................................................................................... 33 5.1 STATE OF THE ART ANALYSIS............................................................................................... 33

5.1.1 Technology........................................................................................................................... 33 5.1.1.1 Wireless communication technologies.......................................................................................................... 33 5.1.1.2 Positioning technologies ............................................................................................................................... 33

5.1.1.2.1 Enabling devices and hardware ...................................................................................................... 34 5.1.2 GNSS Applications............................................................................................................... 35

5.1.2.1 Research and development projects.............................................................................................................. 35 5.1.2.1.1 RIMSAT......................................................................................................................................... 36




5.1.2.1.2 Special Event Transportation Service Planning & Operations Strategies for Transit..................... 38 5.1.2.1.3 Xenios ............................................................................................................................................ 39 5.1.2.1.4 Other projects and systems............................................................................................................. 39 5.1.2.1.5 Partnerships and programs in the field ........................................................................................... 40 5.1.2.1.6 Commercial systems and GNSS products ...................................................................................... 40

5.2 USER REQUIREMENTS ANALYSIS.......................................................................................... 40 5.2.1 Mobility management .......................................................................................................... 41

5.2.1.1 Requirements ................................................................................................................................................ 41 5.2.2 Emergency management ...................................................................................................... 42

5.2.2.1 Requirements ................................................................................................................................................ 42 5.3 APPLICATION REQUIREMENT................................................................................................ 43

5.3.1 List of requirements ............................................................................................................. 43 5.4 SYSTEM REQUIREMENTS ANALYSIS .................................................................................... 45 5.5 SYSTEM REQUIREMENTS COMPLIANCE OF REQUIREMENTS................................................ 47

5.5.1 User Requirements............................................................................................................... 47 5.5.2 Application Requirements.................................................................................................... 47 5.5.3 System Requirements ........................................................................................................... 50

6 IMPLEMENTATION PHASE........................................................................................................ 52 6.1 THE DESIGN & IMPLEMENTATION PROCESS ........................................................................ 52 6.2 SYSTEM ARCHITECTURE DESIGN TASK................................................................................ 52 6.3 SYSTEM LOGICAL ARCHITECTURE ....................................................................................... 55 6.4 SYSTEM DIAGRAMS.............................................................................................................. 56

6.4.1 Fleet Monitoring .................................................................................................................. 56 6.4.1.1 Flow Diagrams.............................................................................................................................................. 56

6.4.1.1.1 User Terminal................................................................................................................................. 56 6.4.1.1.2 SECC.............................................................................................................................................. 57 6.4.1.1.3 Artificial Intelligence ..................................................................................................................... 57

6.4.1.2 Activity Diagrams......................................................................................................................................... 57 6.4.1.3 Sequence Diagrams ...................................................................................................................................... 57

6.4.2 Emergency management ...................................................................................................... 57 6.4.2.1 Flow Diagrams.............................................................................................................................................. 57

6.4.2.1.1 User Terminal................................................................................................................................. 57 6.4.2.2 SECC ............................................................................................................................................................ 58 6.4.2.3 Activity Diagrams......................................................................................................................................... 58 6.4.2.4 Sequence Diagrams ...................................................................................................................................... 58

6.5 SPESSS SYSTEM DECOMPOSITION....................................................................................... 59 6.5.1 Service & Emergency Control Centre ................................................................................. 59

6.5.1.1 CORBA components .................................................................................................................................... 60 6.5.1.1.1 Director .......................................................................................................................................... 60 6.5.1.1.2 Event Manager ............................................................................................................................... 60

6.5.1.2 RMI Environment......................................................................................................................................... 60 6.5.1.2.1 VSCC ............................................................................................................................................. 61 6.5.1.2.2 Terminal Server.............................................................................................................................. 61 6.5.1.2.3 Messaging component.................................................................................................................... 61 6.5.1.2.4 DB Manager ................................................................................................................................... 61 6.5.1.2.5 DB Service Handler ....................................................................................................................... 62 6.5.1.2.6 GoogleMap..................................................................................................................................... 62 6.5.1.2.7 Tracking component....................................................................................................................... 62

6.5.2 The SPESSS data structure .................................................................................................. 62 6.5.2.1 The database schema .................................................................................................................................... 62

6.5.2.1.1 Configuration tables ....................................................................................................................... 64 6.5.2.1.2 Event tables .................................................................................................................................... 64 6.5.2.1.3 Service tables ................................................................................................................................. 64

6.5.2.2 Checkpoint data structure ............................................................................................................................. 64




6.6 THE SPESSS ARTIFICIAL INTELLIGENCE SYSTEM .............................................................. 65 6.6.1 AiLoader .............................................................................................................................. 67 6.6.2 AiModules ............................................................................................................................ 67 6.6.3 DatabaseManager ............................................................................................................... 67

6.6.3.1 Data base design ........................................................................................................................................... 67 6.6.3.2 Tables description......................................................................................................................................... 68

6.6.4 WebService........................................................................................................................... 69 6.6.5 Clips..................................................................................................................................... 69 6.6.6 Algorithm ............................................................................................................................. 70

6.7 THE SPESSS MOBILE USER TERMINAL............................................................................... 71 6.7.1 HMI...................................................................................................................................... 72 6.7.2 Mapping............................................................................................................................... 72 6.7.3 Navigation............................................................................................................................ 72 6.7.4 Services ................................................................................................................................ 72

6.8 THE SPESSS INTRA-SYSTEM COMMUNICATION MECHANISM.............................................. 73 6.8.1 Introduction ......................................................................................................................... 73 6.8.2 General message format ...................................................................................................... 74 6.8.3 General XSD schema file ..................................................................................................... 75 6.8.4 Schema diagram .................................................................................................................. 75 6.8.5 General XML example ......................................................................................................... 75 6.8.6 The Implemented Messages ................................................................................................. 76

6.8.6.1 List of commands ......................................................................................................................................... 76 7 DISSEMINATION ACTIVITIES................................................................................................... 78

7.1 OBJECTIVES OF THE DISSEMINATION PLAN ......................................................................... 78 7.2 MATERIALS .......................................................................................................................... 78 7.3 DISSEMINATION ACTIVITIES................................................................................................. 78 7.4 THE OFFICIAL WEB SITE........................................................................................................ 81 7.5 DISSEMINATION.................................................................................................................... 83 7.6 EXPLOITATION ..................................................................................................................... 83 7.7 MARKETING PLAN ................................................................................................................ 84

7.7.1 Market research................................................................................................................... 85 7.7.2 Product ................................................................................................................................ 86

7.7.2.1 Product definition and attributes................................................................................................................... 86 7.7.2.2 Product launch: key factors .......................................................................................................................... 87

7.7.3 Corporate image for dissemination ..................................................................................... 88 7.7.4 Marketing at events and fairs .............................................................................................. 88

7.7.4.1 Before the events .......................................................................................................................................... 88 7.7.4.2 During the events.......................................................................................................................................... 88 7.7.4.3 After the events............................................................................................................................................. 89

7.7.5 Customer management and continuous marketing.............................................................. 89 8 ANALYSIS OF MAJOR RESULTS............................................................................................... 91

8.1 MAIN FEATURES IMPLEMENTED........................................................................................... 91 8.2 INNOVATIVE SERVICES OFFERED.......................................................................................... 91 8.3 COMPARISON BETWEEN RESULTS AND EXPECTATIONS ....................................................... 91

8.3.1 Filling an innovation gap: intelligence ............................................................................... 92 8.3.2 Ensuring flexibility for future improvements ....................................................................... 92 8.3.3 Building on ready-made developments................................................................................ 93

9 RECOMMENDATIONS FOR EVOLUTION OF SPESSS ......................................................... 95




9.1 STRATEGY APPROACH.......................................................................................................... 95 9.1.1 Management interface ......................................................................................................... 95 9.1.2 Registry and monitoring ...................................................................................................... 95 9.1.3 Robustness ........................................................................................................................... 96

9.2 IMPLEMENTATION OF OPTIONAL REQUIREMENTS ................................................................ 96 9.3 ENHANCEMENTS TO THE X-INFO SUB-SYSTEM .................................................................... 96 9.4 ENHANCEMENTS TO THE AI SUB-SYSTEM............................................................................ 97




Documents AD.1 GALILEO Research and Development Activities 2nd Call (2423) ”Innovation by Small and Medium

Enterprises Statement of Work” GJU/04/2423-SOW/AK/DL/mg

AD.2 GALILEO JOINT UNDERTAKING ”General Condition of Tender for Galileo Joint Undertaking Contracts” GJU/03/039/issue2a/OM/nv

AD.3 GALILEO JOINT UNDERTAKING “Special Condition of Tender” GJU/04/2423-SCOT/NV

Reference Documents RD.1 SPESSS Technical Tender

RD.2 The EGNOS Mission Requirements Document

RD.3 The GALILEO Mission Requirements Document

D01 Project Management Plan

D02 Requirement Analysis

D03 Preliminary System Design

D04 Detailed System Design

D05 Technology Transfer Plan

D06 Dissemination Plan

D07 Results Analysis & Recommendations

D08 Software Design

D12 State of the Art

Company Acronym NEXT Next Ingegneria dei Sistemi S.p.A.

RIGEL Rigel Mobile Service Provider, S.A.




List of Figures Figure 1: Project GANTT........................................................................................................................................................20 Figure 2: Work Breakdown Structure .....................................................................................................................................21 Figure 3: The Service &Emergency Control Centre at Turin..................................................................................................28 Figure 4: Turin raster map and the two path............................................................................................................................29 Figure 5: Examples of daily bus schedule ...............................................................................................................................30 Figure 6: The Mobile User Terminal installed on a GTT bus ready to start............................................................................30 Figure 7: Flow of the activities bringing to the Detailed System Architecture Design ...........................................................53 Figure 8: Logical view of the SPESSS system and the data flow exchanged among different actors ....................................54 Figure 9: The SPESSS Logical Model Architecture ...............................................................................................................56 Figure 10: SECC Detailed Logical View ................................................................................................................................59 Figure 11: SPESSS X-InfoDatabase Schema ..........................................................................................................................64 Figure 12: AI Module Architecture .........................................................................................................................................66 Figure 13: AI Data base structure............................................................................................................................................68 Figure 14: SPESSS User Terminal Logical Architecture ........................................................................................................71 Figure 15: Communication Protocol .......................................................................................................................................74 Figure 16: General XML File ..................................................................................................................................................75 Figure 17: XML Schema Diagram ..........................................................................................................................................75 Figure 18: SPESSS project web site welcome page ................................................................................................................81




List of Tables Table 1: Most relevant project dates........................................................................................................................................19 Table 2: List of deliverables ....................................................................................................................................................22 Table 3: List of application requirements ................................................................................................................................45 Table 4: List of system requirements.......................................................................................................................................46 Table 5: Compliance of User Requirements............................................................................................................................47 Table 6: Compliance of Application Requirements.................................................................................................................50 Table 7: Compliance of System Requirements........................................................................................................................51 Table 8: System design & implementation steps .....................................................................................................................52 Table 9: List of commands ......................................................................................................................................................77 Table 10: Dissemination activities...........................................................................................................................................80 Table 11: SPESSS sitemap ......................................................................................................................................................82 Table 12: SWOT analysis........................................................................................................................................................86




Acronyms

ACR Acronym

AD Applicable Document

CO Contract Officer

DD Deliverable Document

DOM Document Object Model

EGNOS European Geo-stationary Navigation Overlay Service

GJU Galileo Joint Undertaking

GNSS Global Navigation Satellite System

GPS Global Positioning System

GUI Guided User Interface

HMI Human Machine Interface

KOM Kick Off Meeting

LBS Location Based Services

MMI Man Machine Interface

MUT Mobile User Terminal

PDA Personal Digital Assistant

PIM Personal Info Mobility

PM Project Manager

SoA State of the Art

SiS Signal in Space

SECC Security & Emergency Control Centre

TOROC TORino Organizing Committee

UMTS Universal Mobile Telecommunication System

UT User Terminal

WS Web Service

WP Work Package

XBL Extensible Bindings Language

XUL XML User Interface Language




1 EXECUTIVE SUMMARY

A Special Event, in the context of this project, means an event in which a well defined wide area becomes for one or some days the focal point for a very important performance (e.g. sport, exhibitions, meetings, concerts and so on) during which thousands of people are concentrated and move around.

The concentration of such a mass of people may have a huge impact in dense populated area such as big cities or rural areas both in term of mobility of residents and visitors.

In big cities or in dense populated areas the concentration of thousands people for few days means to stress all the infrastructures (mobility, security, emergency, etc.). Moreover the management of the visitors requires ad-hoc solutions that, in some cases, goes against the direct needs and interests of the residents, who perceive the visitors as invaders more than hosts.

In rural areas the lack of infrastructure to support such huge mass of people, also in relation to the residents, provokes chaos and feelings of resistance against the so-lived invasion of their normal quite life.

The areas were the impact are more visible are:

• Vehicle and personal mobility;

• Emergency services;

• Security;

In particular security is nowadays one of the first worries for Organisation Committees of special Events, which could become a possible target of terrorist activities due to the media coverage and the concentration in a well defined area of thousands of people; the situation forced the Organisation Committees to increase the number of people involved in the security activities and consequently making their coordination and management more complex.

Also the interaction with the existing systems installed at the different corps and organizations devoted to the management of the everyday mobility, security and emergency is one of the key points that can enhance the quality of the services provided and decrease the impact of the event on the hosting community.

The aforementioned complexity in the management of Special Events could be reduced by :

• Special Event security context: Security and Emergency staff are usually composed by people dislocated over a wide area, walking or driving a vehicle around or standing by a place, sometime alone and often without the opportunity to know what is going on in other areas and sometimes having no idea about relative positions of the colleagues. The Security during Special Events, like those above mentioned, need an efficient way to distribute data and information among Organisation Committee’s Key Person (K-P e.g.: Responsible and Staff of Planning and Organisation, Security, Medical Assistance, Fire Department, Logistic, Technical Assistance) usually moving from one place to another and sometimes requested in several places at the same times.

• Minimum reaction time: In case of an emergency event, the security reaction time of the people involved in the Security and Emergency management represents the main issue, as they must offer the first response to the emergency. For this reason they have to understand as much as possible about what




is going on, getting quick, proper and reliable information, to understand whether it is more efficient to go in a direction rather another, or to take the appropriate actions instead of adopting standard procedures that may not apply to the case, represents an important element in the efficiency of the security and emergency situation.

• Safety of personnel: For the security responsible it is fundamental to always have a reliable data position of its staff (and vice versa), being not only a way to easy the organisation and the management of its work, but also to make it more efficient and safer. for the Security and Emergency staff. In fact they move around in the event’s area and the knowledge of their own and colleagues’ position it is not only the way to make the work easier but overall safer, as they know that in case of emergency, in any place and at any level, they can have the right information in the shortest gap of time to plan their actions and get the eventual help.

Reliable localisation of mobile resources (people and vehicle) and real time distribution of selected and personalised data and information is the one of the most important aspect for the management of security and emergencies. EGNOS, and in the near future GALILEO, represents the enabling technology for the implementation of innovative application related to the “Security and Emergency management” where information and data, regarding the positions of mobile entity, have to be highly reliable.

In fact these markets are among the most important ones for GNSS applications and where EGNOS and GALILEO could successfully show their benefits and the increased quality of service offered.

The SPESSS (SPecial Events Support by Satellite System) project develops innovative applications and services based on EGNOS service in the Special Events Management domain, with special focus on the Security, Safety and Emergency Management, in order to contribute to the assessment of the benefits provided by this technology. In this sense EGNOS technology is exploited, together with latest software technologies such as the “Intelligent Agents”, and latest generation of user Terminal, such as PDAs and tabletPC.

In fact satellite position based applications, location based information services and communication infrastructures integrated in mobile distributed systems have had a great influence on the development of new applications in various fields. One of them is certainly represented by the management and the optimization of Security matters during Special Events involving hundred people that have to be coordinated in real time taking into account their movement through the environment in which they are dislocated .

The proposed system relies on an advanced infrastructure called X-Info, specifically focused on Personal Info-Mobility, whose main components are a Service Control Centres and the User Terminals (UTs), supported by an Artificial Intelligence module. The infrastructure supports new applications that enhance the efficiency of the security, safety and emergency management, and optimise the reaction time of the staff to recover emergency situations. Through a demonstration activity held in Turin during the 2006 Winter Olympic Games, SPESSS brings the EGNOS technology to the attention and in the hands of the agencies involved in the management of the Security, Safety and Emergency for the Special Events, giving them the opportunity to exploit, conveniently and efficiently, this technology.




2 Introduction The SPESSS project has been conceived to exploit the capabilities offered by EGNOS, in the short term, and Galileo, in the next future, to provide new services to Organization of big events both in term of enhanced security and traffic management capabilities.

The project started by identifying the user needs and service requirements, whilst at the same time implementing a working system to perform a demonstration session during the 2006 Winter Olympic Games held in Turin.

Once the results of the demonstration activities were assessed, a new iteration of requirements analysis was held in order to fix them and to identify the final definition of the functionalities required.

The implementation of the prototype for the Winter Olympic Games provided the consortium of a tested baseline to be used to build all the functionalities emerged by the requirements analysis.

A sound State of the Art were performed in order to have all the appropriate information of the significant trends in the specific market, plus a clear picture of the latest available technologies to implement the propose system.

Having all the elements, the definition of the Architecture of the final system was performed, which positively concluded the definition process. The consortium then began the implementation and test phase.

The final prototype has been demonstrated at GSA representative during the Final review meeting.

This report describes the overall activities conducted within the SPESSS project, reporting for each specific task the objectives, the involved partners and the results and major outputs.

2.1 Document structure Chapter 3 provides an overview of the project;

Chapter 4 presents a summary of the demonstration activities held in Turin;

Chapter 5 is a summary of the requirements analysis phase;

Chapter 6 contains a summary of the implementation phase;

Chapter 7 describes the dissemination activities performed by the consortium;

Chapter0describes the technology transfer plan;

Chapter 8 contains the analysis of major results achieved by the project;

Chapter 9 proposes the recommendations for evolution of SPESSS system.




3 Project Overview

3.1 Project presentation The scope of SPESSS (SPecial Events Support by Satellite System) project is to develop innovative applications and services based on EGNOS service in the Special Events Management domain, with special focus on the Security, Safety and Emergency Management, in order to contribute to the assessment of the benefits provided by this technology. In this sense EGNOS technology is exploited, together with latest software technologies such as the “Intelligent Agents”, and latest generation of user Terminal, such as PDAs and tabletPC.

In fact satellite position based applications, location based information services and communication infrastructures integrated in mobile distributed systems have had a great influence on the development of new applications in various fields. One of them is certainly represented by the management and the optimization of Security matters during Special Events involving hundred people that have to be coordinated in real time taking into account their movement through the environment in which they are dislocated .

Special Events, in the context of this project, means an event in which a well defined open sky wide area becomes for one or some days the focal point of a very important performance (e.g. sport, exhibitions, meetings, concerts and so on) during whom thousands of people are concentrated and move.

In particular security is nowadays one of the first worries for Organisation Committees of special Events, which could become a possible target of terrorist activities due to the media coverage and the concentration in a well defined area of thousands of people; the situation forced the Organisation Committees to increase the number of people involved in the security activities and consequently making their coordination and management more complex.

Reliable localisation of mobile resources (people and vehicle) and real time distribution of selected and personalised data and information is the one of the most important aspect for the management of security and emergencies. These markets are ones of the most important for GNSS applications and EGNOS and GALILEO could successfully show their benefits and the increased quality of service offered.

The aforementioned complexity in the management of Special Events could be definitely reduced by :

• Special Event security context: Security and Emergency staff are usually composed by people dislocated over a wide area, walking or driving a vehicle around or standing by a place, sometime alone and often without the opportunity to know what is going on in other areas and sometimes having no idea about relative positions of the colleagues. The Security during Special Events, like those above mentioned, need an efficient way to distribute data and information among Organisation Committee’s Key Person (K-P e.g.: Responsible and Staff of Planning and Organisation, Security, Medical Assistance, Fire Department, Logistic, Technical Assistance) usually moving from one place to another and sometimes requested in several places at the same times.

• Minimum reaction time: In case of an emergency event, the security reaction time of the people involved in the Security and Emergency management represents the main issue, as they must offer the first response to the emergency. For this reason they have to understand as much as possible about what is going on, getting quick, proper and reliable information, to understand whether it is more efficient to go in a direction rather another, or to take the appropriate actions instead of adopting standard procedures that may not apply to the case, represents an important element in the efficiency of the security and emergency situation.




• Safety of personnel: For the security responsible it is fundamental to always have a reliable data position of its staff (and vice versa), being not only a way to easy the organisation and the management of its work, but also to make it more efficient and safer. for the Security and Emergency staff. In fact they move around in the event’s area and the knowledge of their own and colleagues’ position it is not only the way to make the work easier but overall safer, as they know that in case of emergency, in any place and at any level, they can have the right information in the shortest gap of time to plan their actions and get the eventual help.

EGNOS, and in the near future GALILEO, represents the enabling technology for the implementation of innovative application related to the “Security and Emergency management” where information and data, regarding the positions of mobile entity, have to be highly reliable.

The proposed system relies on an advanced infrastructure called X-Info, specifically focused on Personal Info-Mobility, whose main components are a Service Control Centres and the User Terminals (UTs), supported by an Artificial Intelligence module. The infrastructure supports new applications that enhance the efficiency of the security, safety and emergency management, and optimise the reaction time of the staff to recover emergency situations. Through a demonstration activity held in Turin during the 2006 Winter Olympic Games, SPESSS brings the EGNOS technology to the attention and in the hands of the agencies involved in the management of the Security, Safety and Emergency for the Special Events, giving them the opportunity to exploit, conveniently and efficiently, this technology.

3.2 Objectives of the project The main objective of the project is the design of a clustered reconfigurable mobile architecture, that allows scalability and a dynamic mode of operation to achieve robustness, interconnection fault-tolerance and service continuity, and the development of a system capable of providing innovative “Personal Info Mobility” applications based on EGNOS Satellite Positioning technology.

The proposed solution allows, in push (unsolicited by the User but coherent with its profile location and emergency) and pull (upon request) mode, the distribution of geo-referenced, multimedia, personalized and heterogeneous information, that reach the Security and Emergency staff on their Mobile User Terminals (PDAs, TablePC), taking into account their actual reliable location and their specific “role”. (Security, Emergency, Technical Assistance, etc.).

In this sense SPESSS aims to provide selected and integrated geo-referenced information to the people involved in the Security and Emergency management in both push and pull modes. The provision of geo referenced information based on the above mentioned concepts, methodologies and technologies, was performed exploiting the latest evolution of X-Info, the infrastructure based on a distributed component architecture and robust middleware technology in an open component view, which has been developed during an EC 5th Framework Programme’s project (i.e. “INStANT Olympic”), and through the use of latest generation of mobile user terminals (PDAs).

The main technical objectives of the project are:

• Design/simulate and integrate, at a conceptual as well as an operative level, the components that are necessary to build a mobile user terminal, that consists of the integration of the following services:

o GNSS navigation and positioning, based on EGNOS receivers;

o cellular communications, with particular emphasis on new 2.5/3rd generation equipments;

o smart and capable interfaces that are tuned to reach high level of usability in the domain of personal security applications.




• Develop a Security Control Centralized Infrastructure (SCCI) capable of the service functionalities and thus equipped with a:

o Suitable Control Center to enable mobile internet connection

o Application server equipped with Data exchange management capabilities (SMS, Vector data in XML packets, Raster image processing) to serve a dynamic push model management for emergencies control (Events to mobile equipments) and management of mobile equipments under critical alerting constraints. The synchronization between central/local databases containing information on mobile position and sensible data (such as equipments, water level, intervention state, resources, machine conditions) and the management of (optimal) route planning of vehicles within service areas.

• Assessment of EGNOS signal in the area of Turin;

• X-Info InfoMobility Platform extension and integration with other systems and external data providers;

• Assessment of differentiators and benefits of EGNOS exploitation in such domain;

• Specific assessment of MUT technologies.

Event-based, exchangeable use of UMTS and WLAN wireless communication systems and Satellite links forces the use of heterogeneous bandwidths in a dynamic fashion, with the requirement of superior QoS facilities and reconfigurable modes of operation specific to the Emergency Services domains. Clustered mobile computations, in which local control centers and local data exchanges are handled by WLAN/UMTS means, allow scalability and dynamic modes of operation to achieve robustness and interconnection fault-tolerance.

The SPESSS approach also targeted overcoming major issues typical of mobile systems such as function replication, limited portable resources, bandwidth constraints for data exchange, packet management, recovery of transactions and data synchronization.

The advantages of the technologies involved in SPESSS are basically the following:

• EGNOS: a more reliable positioning system that allows the development of functionalities that couldn’t be fully implemented with other technologies, especially when the applications have to support Security and Emergencies management activities;

• X-Info: this software infrastructure (extension of INStANT) is an InfoMobility platform used as baseline of SPESSS. It has been designed for Emergency and Info Mobility Systems and it has been updated and improved to match the Project’s objectives;

• UT: Mobile User Terminals integrating GNSS, UMTS are able to implement innovative functionalities: Cooperative, Context aware etc.

• Artificial Intelligence: the proposed system uses all the information gather from the User Terminal to provide hints and advises to the managers of the event or to a specific User Terminal on how to behave in response of the specific situation that can have impact on the planned

3.3 Endorsement The project, whose demonstration activity was carried out in Turin, was endorsed by the Torino 2006 Organizing Committee (TOROC) .

This entity is highly representative from the “user” point of view, giving external support to the project in the definition of the user needs.




3.4 Project scheduling The SPESSS project is divided into three phases:

• Analysis Phase: (4 months)

• Implementation Phase: (10 months)

• Technology Transfer Phase: from month 11 to month 12 (2 months)

The first two phases, Analysis and Implementation, has been iteratively performed during the first ten months of the project. The first iteration was focused on determining the special needs and requests resulting from the meetings with the TOROC representatives and implementing them. These actions allowed the Consortium to perform the demonstration activity in Turin during the 2006 Winter Olympic Games from the 10th to the 24th of February. Due to the reduced time all the activities were concentrated on the personalization of the basic infrastructure for the specific event.

The second iteration focused on the definition of the user and system requirements, creating the basis on which to develop the architectural design of the final system. The implementation phase has all the elements to proceed to build the prototype that fully implemented the results of the definition activities.

The consortium ends the implementation and test phase in line with original project deadline.

In the Table 1 the most significant dates for the project are reported:




Item Date Contract signed by NEXT 24/01/2006

Contract signed by EC 26/01/2006

Demonstration at the et 2006 Winter Olympic Games 10/02/2006 – 24/02/2006

Kick-off meetings 03/03/2006

Official project web site on-line 18/04/2006

CCN01 received from Coordinator 25/09/2006

Official appointment of the external reviewer 15/06/2006

MTR meeting 10/11/2006

Official acceptance of MTR deliverables 29/11/2006



Final review meeting 30/04/2007

Table 1: Most relevant project dates




3.4.1 The project GANTT

Figure 1: Project GANTT




3.5 Work breakdown structure The summary Work Breakdown Structure is shown in Figure 2 below

Figure 2: Work Breakdown Structure




3.6 List of Deliverables # WP/

Task

Reference Title Leader Contributor

Due date (project month)

Milestone Classification

01 1000 D01/12 Project Management Plan NEXT 2 INTERNAL

02 2000 D02/12 Requirements Analysis NEXT 4 PR INTERNAL

03 2000 D03/12 Preliminary System Design NEXT 4 PR INTERNAL

04 3000 D04/12 Detailed System Design NEXT 10 MTR INTERNAL

05 4000 D05/12 Technology Transfer Plan RIGEL 12 FR INTERNAL

06 4000 D06/12 Dissemination Plan NEXT 12 FR INTERNAL

07 4000 D07/12 Results Analysis and Recommendations RIGEL 12 FR INTERNAL

08 3000 D08/12 Software Prototypes NEXT 10 MTR INTERNAL

09 1000 D09/12 Analysis Phase Review Report NEXT 12 FR INTERNAL

10 1000 D10/12 Mid Term Review Report NEXT 6 MTR INTERNAL

11 1000 D11/12 Final Review Report NEXT 12 FR INTERNAL

12 2000 D12/12 State of the Art RIGEL 4 PR INTERNAL

Table 2: List of deliverables

3.6.1 Project management plan The document details Managerial processes to be used to achieve project objectives within the scope, time and budget of the contract SPESSS. Specific definitions of technical processes are also given, together with the summary of milestones, deliverables, work-packages and responsibilities for the partners.

3.6.2 Requirements analysis This document enumerates and describe the requirements of the SPESSS system from the point of view of the user needs and the consequent function requirements.

3.6.3 Preliminary system design The document is targeted to describe the design and develop activities performed by the consortium to prepare the preliminary system used at the 2006 Winter Olympic Games and been the reference for the final system.




3.6.4 Detailed system design The document is targeted to design, develop and test the necessary “core” components to be used in the construction of the System; these include server-side, client-side, applicative and also all the components implementing other important characteristics of the system, like: authentication, external data services, GIS and mapping, Artificial Intelligence and others.

3.6.5 Technology transfer plan The document sets up the guidelines of activities to be undertaken in order to ensure that the work carried out during the project is best exploited. The key objectives are to make the results of the project being known to the relevant third parties and enable mechanisms for industrial exploitation in the market.

3.6.6 Dissemination plan The document is targeted to describe the dissemination activities of the project.

3.6.7 Results analysis and recommendations The document offers a general report of the analysis of results of the project. Special attention is given to the presentation of the results of real tests carried out over the software system developed in the SPESSS project. Also conclusions and comparisons are described

3.6.8 Software prototype The document is targeted to detail the process followed by the consortium in the development activity, highlighting the major achievements and innovative approaches.

3.6.9 Analysis phase review report The report provides a synthesis of the different results of the analysis phase obtained by the consortium in the different areas of work.

3.6.10 Mid term report The report provides a synthesis of the different results of the mid term review obtained by the consortium in the different areas of work.

3.6.11 Final review report The report provides an overview of all the activities performed by the consortium and a synthesis of the different results and outputs obtained by the consortium in the project.

3.6.12 State of the art The document summarizes the results of the analysis carried out to identify and assess the main technological options available in the market with potential impact in the SPESSS project. It consists of two major parts: a compilation and evaluation of the relevant enabling technologies (wireless communications, positioning




technologies, supporting devices) and a study of current products or projects within the industry that addresses the subject of people and team management applying satellite positioning technologies.

3.7 The innovative approach SPESSS supports the K-P (Key-Persons) involved, at any level, in the core of the Special Events, with particular emphasis to the Security and Emergency management activities. To do so, a specific Security Control Centre and latest Mobile User Terminals, such as the PDAs, TabletPC are used and equipped with the innovative applications, that are developed in this project timeframe.

SPESSS aims at giving to each K-P a unique access point to the information related to the Security. This is possible through the use of PDAs, a hand held Mobile User Terminal (MUT) no bigger that a normal guide book, equipped with an EGNOS match-box sized receiver. By means of the X-Info InfoMobility Platform appropriate geo referenced data and information could be retrieved, selected and provided to the right K-Ps.

The Security Control Centre is the focal point of the system; the innovative applications developed in the project allows the SCC’s operator to have a complete and clear image concerning the reliable position of every K-P, its name, its responsibility level, its role, its status (idle, busy, not available, not reachable) and eventual related warning event (e.g. not reachable for a defined time interval) .

Having to deal with Security management, data exchange between the SCC and the User Terminals, by mean of UMTS channel, is secured by the use of the proper Cryptography Technologies.

The main innovations of the project are therefore:

• Design of an integrated user terminal, based on integration of readily available COTS components capable of GNSS, mobile communications, visualization, mobile internet applications;

• Development of a modular architecture, based on extensible components, that can be reused for different applications and allow usage of new terminals as they become cheaper and more powerful;

• Extensive Demonstrations of the EGNOS Signal;

• The concept of the data-driven or push models, an approach capable of providing a service with (near) real time response to emergency events, distributed over (mobile) communication infrastructures, dynamic and reusable;

• An expert module that implements the artificial intelligence and capable to provide hints and advises on how to manage situations that have impacts on the overall operations.




4 Turin 2006 Winter Olympic Games Demonstration

4.1 The demonstration scenario In Turin during the 2006 Winter Olympic Games there were lanes on the main street that were completely devoted to the movement of busses and cars that were specifically appointed for the movement of Key Persons. Those changes of the everyday mobility had a big impact on the everyday use of the roads while at the same time causing blocking of such vehicles when there was congestion of those lanes. For example an incident in Turin involving a bomb threat in a tunnel, caused the busses on the Olympic routes to be blocked until the alarm situation ended.

A new approach of the mobility management in urban environment is proposed and possible thanks to the convergence between GNSS and wireless communication technologies, used as baseline technologies for distributed IT infrastructure.

Moreover the quality of time and positional data provided by EGNOS in the short term and Galileo in the future, allow their use for analysis of the status of the traffic condition.

The underlying concept is to use the moving vehicle not only as the destination of the message and data but also as an active source of reliable real-time data that, analyzed at a centralized level, offer an continuous stream of updated information.

In a non urban environment flexibility and adaptability are the key characteristics for systems devoted to the management of the mobility of Key Persons: the areas in which the events take place are often far from the main location and in particular situation are distributed between spots very far from one another, in this sense the distance is a crucial element to be taken into account.

Moreover agenda changes constantly, being adapted to the changing environment conditions, forcing to a continuous update of the scheduled journeys. The personal needs of the different Key Person, that in some situation can diverge significantly can have a deep impact on the scheduling activities where a prioritization of needs is essential. In standard approach this can lead to delay and retard in serving the different Key Person. The combination of communication and precise navigation data can support the implementation of truly dynamic functions to manage the movement of the Key Persons between the different spots at the event accordingly to the specific requests and needs.

4.2 Demonstration overview The demonstration activities performed during the Turin Winter Olympic Games dealt with applications related to the management special events with special emphasis on the management of security aspects and emergency situations of the transport in an urban environment of Key-Person through the use of the precise satellite position signal provided by EGNOS in conjunction with the X-Info infrastructure.

In fact during the Olympic games in Turin, many so-called Olympic lines had been designed to allow the K-P to move in a safe and fast way among the different Key-Points in Turin. Buses were fully devoted to these Olympic lines, as well as streets and lines that were closed to the normal traffic. The K-P are people directly involved in the Special Events and, for their role and importance, need special attention.




The improvement of capabilities to guarantee more security in the day to day operations and to react to sudden emergency events has been reached thanks to the constant and precise monitoring of the position of buses, with the constant control of the followed path both in geographical and time terms.

It is worth mentioning that the project had the full endorsement of the TOROC, Turin Olympic 2006 Organizing Committee and had been conducted with the close relationship with GTT, Gruppo Torinese Trasporti.

The contribution offered by GTT spanned from physical support, having provided the location for the Service and Emergency Control Centre and the buses where to install the client side of the application, to the support in defining a subset of user requirements that the consortium implemented.

In fact, after many meetings between NEXT and GTT during the latter months of 2005, the companies agreed on a list of new requirements and constraints the application had to meet in order to perform the foreseen activities in Turin:

1. A full implementation of the Server side infrastructure had to be installed at one of the GTT premise in Turin

2. Five buses on two distinct Olympic lines were provided with a PDA on which the application client side was installed.

3. The client side had to be updated in order to work in a “hands –free” behaviour

4. The monitoring activities were performed on a daily basis for the selected buses distributed between two different Olympic lines

Moreover a list of functionalities that characterize the application had been agreed, as well. In particular on the Service and Emergency Control Centre the functionalities implemented include:

• Real-time visualization of each single vehicle

• Visualization of the geo-referenced information received from the Client

• Visualization of the Client status

• Visualization of the Olympic path to be monitored

• Visualization of the start point, end point and stop points for each Olympic path

• Management of the Route Planning for the two Olympic path

• Sending of the path assigned to each Client

• Sending of the schedule to each Client

• Real-time checking for each bus of the respect of both the path and the schedule assigned

• Real-time warnings and alarms visualization in response of variation of both path and schedule

• Real time visualization of alarm received from each Client

• Off line position request of a Client

On the Client side, the new functionalities have been:

• Visualization of the actual position on a map

• Visualization of the path assigned

• Visualization of the start point, end point and stop points

• Sending of the position every one minutes (the frequency can be changed at configuration level)




• Sending of service messages to the SECC

• Visualization of the alerts and alarms received from the SECC

• Sending of geo-referenced information to the SECC

• Sending of defined alarms

• Sending of defined help requests

4.3 Turin demonstration operation The demonstration activities began in Turin on the 16th of February 2006 and lasted until the 24th of February 2006.

4.3.1 Pre-operation activities During the first two days at the GTT premises, located in via Daniele Manin, the Service and Emergency Control Centre was deployed and the five User Terminals were configured.

The SECC was composed of two servers linked in a LAN on which the following components had been installed:

Server NEXUS:

• System & Service database

• System infrastructure

• System operator console

Server AD4DEMO_WS2

• Service infrastructure

• Service operator console

• High quality raster and vector maps interfaces




Figure 3: The Service &Emergency Control Centre at Turin

The Client side of the application had been installed on Qtek PDA 9090 linked through bluetooth to the GPS/EGNOS receiver EMTAC S3 BTGPS.

4.3.2 The demonstration operation The demonstration started on Monday, the 20th of February, and consisted of monitoring the day to day activities of five buses dedicated to two distinct Olympic lines: MC4 and MC8.

The MC4 line linked the two meeting points at MVUNIVERSITY and MMCLINGOTTO, with the two intermediate stops at TORINO ESPOSIZIONI and MEDIA HTL, lines yellow and green.

The MC8 line linked the two meeting points at MV VEROLENGO MORTARA and MMCLINGOTTO, lines light blue and light green.




Figure 4: Turin raster map and the two path

Everyday the schedule of the four buses to be monitored was inserted into the system, and the Mobile User Terminal installed in the selected buses




Figure 5: Examples of daily bus schedule

Once each bus exited the depot, the operator at the SECC assigned the corresponding path and timetable to each bus.

The Monitoring and Control management is based on the following overall internal Client states:

IDLE: The bus is connected to the system but no path is assigned to it; no controls are activated both on the Server and Client side; the bus sends its position on the configured frequency

SCHEDULE: The bus receives the path and the scheduling, but has not reached the starting point; the control over the timetable is activated on the Server Side;

START: The bus is in starting area; the control on the path is activated on the Client side;

RUNNING: The bus is on the assigned journey;

STOP: The bus is in the stopping area; if the bus has completed the schedule the application turns to the state IDLE, on the contrary it turns to the state START.

Figure 6: The Mobile User Terminal installed on a GTT bus ready to start

4.4 Demonstration feedbacks and results

4.4.1 Users feedbacks The demonstration during the Olympic Winter Games had two different category of users, who sometimes had divergent needs:

• The GTT company

• The buss drivers

In fact some of the functional requirements expressed by GTT took into account the possible negative reaction that the proposed system could have generated from the drivers. Moreover the limited installation timeframe did not permit to organize meetings or/and training courses to the end-user to formally present the system and its functionalities.




This situation forces the consortium to not propose a final questionnaire to the drivers to collect their feedbacks and comments.

Nevertheless during the days in Turin the consortium members had the opportunity to discuss informally with may buss drives who showed interests in the systems.

The majority expressed a feeling of an increasing personal safety directly linked to the fact that there were people that constantly knew where they were. The tracing and tracking function were perceived more as a means to guarantee their personal security than as a means to control their work.

Another aspects considered very important was the possibility to receive and send information from the supervisor: in fact the drivers were equipped with cellular phone but the information exchange was limited due to technological constraints.

Form the GTT point of view the demonstration was very useful since it had the chance to see at work the EGNOS system. At the moment the diffusion of EGNOS among the real user community is very limited and the information on it are vague and confused.

The possibility to see live the differences between the GPS alone and the GPS + EGNOS enforced the interest in the european GNNS system.

4.4.2 Demonstration results The demonstration offers the chance to the consortium to have an early feedback on the project assumptions and implementation guidelines.

EGNOS service

The Turin area suffered of a not linear coverage of the EGNOS service. The particular position of Turin and the structure of the road inside it create a not friendly environment.

In this sense the demonstration allow the consortium the comparison of the quality of the functionalities implemented with and without EGNOS.

Even to an not expert user, the presence of EGNOS is perceived as fundamental to use services in which accuracy and quality of service is the key element.

User terminal

The devices used during the demonstration activities were mass market product which, used in stressing condition, showed limitations and constrains for their utilization in production.

They showed two main issues:

1. The duration of the battery is very limited

2. The internal protection against current jolt caused sudden crash of the application as the device was linked to the busses current supply.

The emerged limitation forced the consortium to make a new assessment on the available portable devices in the market.

HMI

The demonstration and the interaction with the end user proved that the main idea that lead to the adoption of configurable interface depending on the situation could be one of the winning point of the proposed system.




In fact the usability of the entire system is enhanced thanks of the proposed approach and also the acceptance of the system by the end user, even not very skilled, increased since the interface are very simple and implemented for an easy access to main functionalities that in each specific circumstance may need.

Service &Emergency Control Centre

The innovative idea behind the project was to merge an infrastructure offering info-mobility service with the capabilities offered by Artificial Intelligence system.

The limited time did not allow the consortium to prepare a suitable AI system.

The X-Info infrastructure, on the other hand, did not suffer any particular problems or downtime, even if the hardware infrastructure was limited.

Furthermore the possibility to publish the fleet management data on the Internet, through the Google map based interface, was a very useful enhancement that allow the visibility of the published data in different place without any software need.




5 Analysis Phase

5.1 State of the art analysis The State of Art analysis, built on market research and a primary assessment of technologies, is intended as a reference document for further definition and analysis tasks within the SPESSS project.

The analysis, design and development activities carried out in the project are built on the recommendations of the SoA document and evolved to reach results that are novel in the industry and have a competitive advantage towards similar systems.

The SoA analysis is divided into two major analysis streams:

• Technological

• Competitive application

5.1.1 Technology This part of the analysis is dedicated to the compilation and assessment of the technological options available in the market. The technical fields covered are those that are considered as enabling tools for the implementation of the SPESSS project, i.e. communication, positioning and hardware technologies.

5.1.1.1 Wireless communication technologies The most relevant wireless communication technologies are identified and presented. These means of communication are not only key to enable the GNSS applications: they also have a great impact in our society. In few years their market has increased its scope. Its main engine is the cellular phone field, but satellite communications obviously play a big role and we cannot forget other wireless technologies intended for shorter geographical spans.

The SoA analysis includes the description and assessment of different wireless communications technologies classified according to their scope or reach:

• Wide-area networks (digital mobile communications), including GSM and other 2G systems, GPRS, 3G, etc.

• Metropolitan area networks, including radio trucking, TETRA, WiMax, HiperMAN, MBWA, LMDS, etc.

• Local area networks, including the IEEE 802.11x WLAN technologies, HiperLAN and DECT.

• Short-range (personal area) networks, including Bluetooth, UWB, ZigBee, HiperPAN, HomeRF, IrDA, WUSB, etc.

• Satellite communications, considering GEO, MEO and LEO systems.

5.1.1.2 Positioning technologies In this area, different technological options for estimating the geographical location of devices are studied.

There are very different engineering approaches to the problem of calculating positions. The technologies in this section are classified according to those approaches.




• Satellite-based systems, including GPS, GLONASS and others, along with forerunners and derivations from them. Obviously, Galileo/EGNOS was the preferred option, so no further assessment was carried out.

• Cellular positioning systems, considering several mechanisms: Cell Identity (CI), CI plus Time Advance (CI+TA), Observed Time Difference (OTD) and Enhanced OTD, Time of Arrival (TOA), Time Difference of Arrival (TDOA) and Angle of Arrival (AOA).

• Wireless network positioning systems, such as Hitachi Air Location, Skyhook Wireless, Ekahau Positioning Engine, WhereNET or PlaceLab.

• Hybrid positioning systems. Some of them include Assisted GPS, SISNET / EDAS (EGNOS, Data Access System).

• Other positioning systems that can not be classified under the categories above.

5.1.1.2.1 Enabling devices and hardware This work area is targeted to the study of the technological options available for building the terminal “sub-system” of the SPESSS project. To do that, it is necessary to establish a minimum set of capabilities for that unit. The overall requirements identified are:

A) A wide-Area data communications interface

B) A GNSS receiver, specifically based on EGNOS technology

C) A programmable platform or operating system

The first two aspects are sufficiently covered in the analysis described in previous sections. The third one, related to the programming capabilities of the terminal sub-system, are specifically addressed in this area.

We need a programming platform where to install and run the software responsible for handling the client part of the system. Therefore, we need an open programmable platform or Operating System.

The choice of the programming support and/or operating system in the mobile user terminal is an extremely important matter, since the O.S. will be responsible for managing the hardware and software in the most efficient way, and this will influence many aspects of our applications: graphical interface, memory management, communications…

Nowadays we can find an assortment of Operating Systems for mobile devices. The following list shows the most compelling platforms and O.S. that have been designed to operate in different mobile devices and were studied in the SoA analysis:

• J2ME (Java 2 Mobile Edition), considering the two types of configuration: Connected Limited Device Configuration (CLDC) and Connected Device Configuration (CDC), as well as the MIDP 1.0 and 2.0 profiles and the optional packages.

• Symbian OS, considering the different interfaces available for different devices: Series 60, Series 80, Series 90 and UIQ, and the versions that have been released until now.

• Windows Mobile and its evolution.

• Linux

• Palm OS

In order to analyse and propose commercial options for implementation of the terminal unit, the sub-system is in turn divided into three functional components: communication, processing and positioning.




The functional division above can also be a physical division: that is, the terminal sub-system can be comprised of several hardware devices, each carrying out a particular function. The different devices (possibly two or three) would be connected mechanically or wirelessly to build a full terminal sub-system in the SPESSS project.

There are also some readily-available products in the market that could become the terminal sub-system part of the SPESSS platform in a single hardware device. They were also studied in the SoA analysis.

In summary, the study covered different categories of devices:

• Communication components. These terminals are only used for communication purposes without a specific processing of information.

• Processing components. Under this category we have the devices that have processing capability and allow the installation of software programs, but they neither integrate a communications module nor a positioning module.

• Positioning components. The GNSS positioning capabilities can be added to the terminal sub-system by means of a separate satellite receiver that communicates to the processing unit locally.

• Combined processing and communication components. They are basically mobile telephones and Personal Digital Assistants (PDA).

• Combined processing and positioning components. There are PDAs in the market that come really fitted with an embedded GPS receiver or similar, without communication capabilities.

• Full sub-system terminal devices. There are quite few devices in the market that integrate the three essential components of our required terminal sub-system: communications, processing and satellite positioning. We can classify them into mobile phones and PDAs (although the difference becomes more and more subtle as the industry evolves).

5.1.2 GNSS Applications The second part of the SoA analysis covers the State of the Art of relevant products, projects and initiatives present in the market that are concerned with the exploitation of satellite positioning for event management and personal info-mobility. The main objective of this task is to avoid detailed work in areas already covered and to help the partners build on past and present initiatives.

Due to the characteristics of our project, we focused on GNSS applications for the civil protection sector: coordination of different specialized teams to prevent disasters, to provide safety and security for people, management of emergency situations and disasters. In addition, we offer a general view of current market situation and show some commercial products in all kind of areas.

The study and presentation of results is made according to the following classification:

5.1.2.1 Research and development projects The sub-sections under this area describe relevant R&D projects and activities related to GNSS applications. Some of these projects are in progress or will be developed in the near future and others have been finished some years ago. All of them can be considered as great information sources and their results can contribute to increase the quality of the SPESSS development.

The projects addressed in the document include:

• REMSAT (Real-time Emergency Management via Satellite)

• GEMINI (Global Emergency Management Information Network Initiative)




• GAMMA (GNSS for Airport Movements Monitoring and Alerting)

• PARAMOUNT, which is a LBS prototype for hikers that aims to increase the emergency respond efficiency in the mountainous environment

• GIGA (Galileo Integrated Georeference Applications in the energy market)

• Some projects under the Galileo programme: INSTANT, SCORE (Service of Coordinated Operational Emergency and Rescue using EGNOS), POP-ART (Precise Operation Positioning for Alpine Rescue Teams), VASER (Visual Awareness System for Emergency Response), ADVANTIS, GIROADS, GADEROS (Galileo Demonstrator for Railway Operation Systems), NAUPLIOS and POLARIS.

In particular some projects deserve a particular attention due to the close relationship with the SPESSS project.

5.1.2.1.1 RIMSAT 5.1.2.1.1.1 Project overview

RIMSAT stands for Remote Intelligent Management Support and Training.

RIMSAT (Remote Intelligent Management Support and Training) was a European Commission funded project designed to:

• Provide an innovative, ‘intelligent’, knowledge based solution aimed at improving the quality of critical decisions

• Enhance the competencies and responsiveness of individuals and organisations involved in highly complex, safety critical incidents - irrespective of their location.

The RIMSAT project was focused on helping organisations to use efficiently the knowledge collected by their people and making the most of it in order to help making suitable decisions. By integrating leading edge and innovative knowledge engineering techniques to support knowledge management, RIMSAT intended to provide a novel way of using the acquired knowledge to improve organisational procedures.

The project has its own web-site with information about it: http://www.rimsat.com

5.1.2.1.1.2 Project objectives

RIMSAT objectives were:

• To develop an innovative, "learning" knowledge-based decision support system aimed at organisations involved in highly complex, safety and/or mission critical activities and events, irrespective of their location

• To elicit both tacit and explicit knowledge, information and data from a variety of formal and informal sources to provide a best practice, dynamic advice and guidance system available at any fixed or mobile location that has access to any terminal with wired or wireless communication capability

• To ensure that the system will continually "learn" from previous experiences, enabling the advice & guidance it determines to represent the best practice available at that specific moment in time

• To prove the concept of the system through real-world trials in a highly complex, safety-critical environment

• To use the system as the basis for collaborative distance learning/training through customisable event/incident simulation




• Enabling existing skills to be improved and new skills to be acquired without the need to remove personnel from their centre of operations for extended periods of time

5.1.2.1.1.3 Project results

The project started on October 2001 and was meant to finish on March 2004. The official web-site only contains information about its first year, but some information about the conclusion of it can be gathered out of the comments in:

http://istresults.cordis.europa.eu/index.cfm/section/news/tpl/article/BrowsingType/Features/ID/70780/highlights/RIMSAT

The RIMSAT system was to be validated in a safety-critical environment where the sharing of knowledge is not only vital but is considered the norm. For that matter, the RIMSAT project involved a number of Public Safety Services (PSS), principally fire services in the UK. The lead PSS was West Midlands Fire Service.

By the conclusion of the project in March 2004, the RIMSAT partners had developed a knowledge system that incorporates both case-based and model-based reasoning. However, the fire service partners in the project felt that the model-based reasoning aspect of the prototype slowed down the system, making its predictive abilities less suitable for use on the fire-ground.

Nonetheless, the project method entered into service. RIMSAT’s capabilities have been welcomed as a useful addition to the training environment. The West Midlands Fire Service in the UK, one of the project partners, has integrated the RIMSAT method of collecting post-incident experience into the work of the service.

5.1.2.1.1.4 Assessment against SPESSS

Decision makers at the scene of an emergency incident are faced with a range of challenges in bringing the situation to a safe and timely conclusion. The RIMSAT project was initiated with the aim of addressing two key issues:

• Personnel are required to make decisions where the type incident may be outside of their range of experience simply because they have not dealt with such a situation before, or because the type of incident occurs infrequently – rail crash, petrol tanker crashing into Spaghetti junction, Mont Blanc tunnel fire etc. No mechanisms exist to capture the ‘experience’ and the learning outcomes when a similar incident has been dealt by another person, possibly in another country and make that knowledge available at the scene of an emergency to others.

• Incident commandeers are required to assimilate information from a number of different sources and then develop a plan which identifies a sequence of events which are prioritised. In developing the plan it is possible that key points may be missed or incorrectly prioritised.

The RIMSAT project researched on the feasibility of providing a means of assisting incident commanders in the future by providing support information that will enable them to make the best decision for the situation that they are dealing with. In addition to its use within incident command, RIMSAT aims to support

• The delivery of training as a web based distance-learning facility that will support the training of personnel within their normal place of work.

• Pre-planning for incidents and the development of systems of work and procedures. The ability to test a range of ‘what if’ scenarios will enable the outcomes for a particular course of action related to a specific incident, to be predicted.




In short, RIMSAT was conceived and developed (and so it was finally demonstrated) as a useful tool to help people making decisions in complex, critical situations. An important driver is the fact that knowledge and expertise can grow and help future decisions. But it is not a system for coordination and information of the people that are actually coping with the critical situation.

In other words, RIMSAT fits very well in the procedures of SPESSS to assist people when teaching the system how to behave. Or, otherwise, SPESSS could be a very useful tool to assist the RIMSAT platform into putting in practice its decisions and conclusions. That is, the two projects could benefit of their integration. They are quite complementary systems.

5.1.2.1.2 Special Event Transportation Service Planning & Operations Strategies for Transit

5.1.2.1.2.1 Project objectives

The goal of this project was to meet the expressed needs of Florida transit agencies for the development of a guide for special event transportation services that could benefit transit agencies and the organizations with whom they must coordinate for the provision of services. Unlike regular transit service planning, service for special events presents a challenge for service providers in that they are non-recurring events without a predictable transit demand, transit agencies must work cooperatively with other stakeholders, and supplemental service is provided in addition to normal transit services. Special events services are one of the biggest attractors of non-regular riders, presenting a unique opportunity to market the transit agency’s services to the community.

Unfortunately, service for special events is often subject to ad hoc planning and designed based on tradition rather than with a systematic approach to meet the transit agency’s goals. Often, the inherent benefits of providing special events services are never realized by the transit agency, and costs are not minimized.

Special events range from very large events such as the Olympics to very small events such as a local community parade; this report includes information and best practices that will be useful in the provision of any type of special event service. This service guide includes strategies for coordination within and among relevant agencies, key considerations before undertaking special event transportation services, and a framework to enable service providers to proactively plan and successfully deliver these services.

The delivery of transportation services during special events often requires the cooperation of agencies that do not usually work together. However, cooperative planning during periods of increased travel demand offers a unique opportunity to pursue innovative operational practices and apply technologies to improve the performance of the overall transportation system through more effective utilization of available roadway and service capacity.

Given the existing and growing potential for special events in various urban areas of Florida and the growing need for transit agencies to attract new riders, it is vital that transit agencies utilize an operations reference resource to ensure effective planning and efficient service delivery.

5.1.2.1.2.2 Project overview

This project was carried out by the Center for Urban Transportation Research (CUTR) of the University of South Florida. It started in January 2004 and finished in the beginning of 2006.

As a result of the project, an overview of transportation planning and management for special events was presented. The current practices of Florida public transit systems involved in supporting special events in their communities were documented. An overview of the Federal Transit Administration's (FTA) charter regulations was provided, including an outline of the procedures for compliance. Also, a summary of recent pertinent FTA cases and rulings related to charter service provision and special events was provided. Best practices in planning




guidelines and strategies were presented for use by transit agencies to improve their involvement in community planned special events.

More information can be obtained through the website http://www.nctr.usf.edu/projects/Year5/576-09.html


This project was a pure research initiative, without a development component and certainly without a focus on IT solutions. It is interesting to raise awareness of this project in relation to SPESSS because it is addressed at similar problems in the same field and provides some useful information regarding policies for management of people (specifically transport) within the context of special events.

Therefore, this project is definitely not a competitor of SPESSS. It is not even a complementary product or platform, since there is no IT solution behind it. But this project can supply important information to potential customers of the SPESSS solution, providing guidelines for design and configuration of policy rules that can be programmed into the expert system of SPESSS.

5.1.2.1.3 Xenios 5.1.2.1.3.1 Project overview

Transport firms that daily pickup or deliver commodities encounter a plethora of problems relating to their Vehicle Routing and Scheduling (VRS) activities. To make decisions about Routing and Scheduling during special events is even more complicated process. During the Athens Olympic Games 2004 in Athens, the Vehicle Routing and Scheduling problem was very keen. Actually, the commodities transportation had to be done within strictly defined time-periods and under many security and traffic restrictions.

"Xenios" is a specific Decision Support System (DSS) that was developed to assist the daily VRS activities of Greek transport firms during special events. This system incorporated essential functions of GIS, database systems and model management techniques to support overall routing, scheduling and decision-making processes for VRS problems encountered during the Athens 2004 Olympic Games (ATHENS 2004).


From a very limited point-of-view (only general information could be gathered), it can be concluded that this project introduces techniques for automation of the process of managing moving people in special events. However, the focus of the decision mechanisms is on the routing and geographical distribution of units rather than on the assignment of tasks according to emergencies. Therefore, the two projects (Xenios and SPESSS) could be considered more as complementary platforms than as competitors.

5.1.2.1.4 Other projects and systems 5.1.2.1.4.1 STADSS

Strategic Transportation Analysis Decision Support System (STADSS) is an integrated system consisting of: transportation networks and other geographic databases; GIS, transportation analysis, and graphics display software; and host computers and peripheral hardware. It was designed to provide the Military Traffic Management Command, Washington, D.C. (MTMC) with improved transportation analysis capabilities for surface transportation systems in the continental U.S.

Not much information could be retrieved about this system to analyse it against SPESSS.




5.1.2.1.5 Partnerships and programs in the field This section addresses some associations and groups of companies that work in the field of GNSS applications. The main aim of this kind of organization is to develop and research GNSS applications and their use in our society. These consortia imply the collaboration between a great variety of companies and academics. Some key relevant consortia in Europe nowadays, presented in the SoA document, are:

• Pinpoint Faraday

• The Agile project

• The INAVSAT & EURELY association

5.1.2.1.6 Commercial systems and GNSS products This part is divided in turn into two areas:

The first one is a description of theme areas where GNSS can be useful and it also gives examples of commercial products in each theme. The areas addressed are:

• LBS (Location Based Services), further classified into information and navigation, emergency assistance, tracking services and network related services.

• Road applications

• Aviation

• Maritime

• Rail

• Oil and gas

The second part is an example of a real GNSS development deployed in the city of Los Angeles (USA), called ESCN (Emergency Satellite Communications Network).

The system has been deployed in the city of Los Angeles, in the USA. The Los Angeles County Office of Emergency Management and Network Innovation Associates Inc. installed a LinkStar satellite private network from ViaSat Inc. The ESCN system is designed to coordinate and manage L.A. County fire, law enforcement, health and safety agencies. The system also helps creating an information flow in a common central data base that is used and updated by the members of emergency services. Connection in real time between all safety agencies is an essential feature of ESCN.

5.2 User requirements analysis Organizations which manage the mobility during special events in general have to cover two different main scenarios: the first is the everyday mobility of the Key Person between different locations, the second is the management of alarms or critical situations in which all the routine guidelines must be reviewed to be adapted for the new situation, while at the same time in all the areas not directly involved the mobility must be as least effected as possible. One aspect that must be taken into account is that the former scenario is compulsory for the overall success of the event while the latter is subject to media coverage that, in many cases, focuses the attentions on the management operations only.




5.2.1 Mobility management One of the first problems that organization of special event has to meet is the management of the mobility of all the persons that are involved at different level in the event. The first step is to define and design special lines targeted to support the mobility between the main spots of the event of the person involved. Nevertheless not all the actors are serviced by these general purpose lines, but for particular actors ad-hoc mobility services are designed. The profiling of the person involved in the event manages the services offered.

Having this structure defined, one fundamental service is the monitoring of the movement of all the vehicles (busses, cars) available and the position of the Key-Persons. This service provides the basic information to the mobility management organization necessary to understand how the current situation is and to provide the directions to respond to changes to the normal behaviour.

5.2.1.1 Requirements In the following section the list of requirements agreed with representatives of the “User community” are introduced.

USR_M001 HMI

Description:

The HMI for the devices to be used by the Key Person and the one for the Buses Tracing/Tracking must be different. The different masks must be adapted in respect to the end user and the actual situation.

USR_M002 HMI UT Key Person

Description:

It must display a map with the current position of the user. All functionalities implemented must be invoked by a simple click on a button.

USR_M003 HMI UT Bus

Description:

It must display a map with the current position of the user. All functionalities implemented must be invoked automatically without man interference. The messages must disappear automatically.

The last requirement stems from the following:

1. The drivers must be concentrated on the driving, which is the first and must important duty;

2. The training period must be the shortest possible

USR_M004 HMI UT Bus 2

Description:

The messages received must be available on a specific interface.

USR_M005 Bus position

Description:

The position of a bus must be calculated in real time and sent to the Service Control Centre at a time interval set by the Service Control Centre.

USR_M006 Bus position 2

Description:




The Service Control Centre can request at any time the position of a particular bus.

USR_M007 HMI Tracing/tracking

Description:

It must display a map with the current position of the user. All functionalities implemented must be invoked automatically without man interference. The messages must disappear automatically.

USR_M008 Control over the path

Description:

Each bus must monitored during its journey both in time and in space. In case of delays or route mismatching the Service Control Centre must send alarms of different severity relevant to the scale of the problem.

USR_M009 Message Management

Description:

All relevant messages sent and received from and by the User Terminal must generate an acknowledgement message to inform the sender of its correct reception.

USR_M010 Key Person position

Description:

The position of a key person must be calculated in real time and sent to the Service Control Centre only if it is necessary to provide a required function or if explicitly requested by the Service Control Centre or sent by the Key Person.

USR_M011 Key Person message

Description:

A Key Person must be able to send to the Service Control Centre textual messages, audio and multimedia files.

USR_M012 Key Person request

Description:

A key person must be able to send a request to the Service Control Centre to receive at least the nearest bus stop or/and directions on how to get to it.

USR_M013 Key Person request 2

Description:

A Key Person must be able to send a request to the Service Control Centre to be collected by a bus.

5.2.2 Emergency management The management of emergency situation is very challenging for organization of special event: the situation can be either general, the emergency is not strictly related to the event but it has impact on the event, or particular, the emergency is strictly connected to the event or to a particular moment of the event. In both case the organization must be able to respond in a flexible way, assuring the correct management of the situation being able at the same time to maintain the same level of services in the area not effected by the emergency situation.

5.2.2.1 Requirements




In the following section the list of requirements agreed with representatives of the “User community” are introduced.

USR_E001 HMI

Description:

The User must be able to send an S.O.S. by only pushing a button that is well displayed and highly visible in the main windows.

USR_E002 HMI 2

Description:

The request must always be confirmed by the User clicking a confirmation button which must appears on the current window after the request.

USR_E003 HMI 3

Description:

The User must have the possibility to request a specific operator (Fire brigades, ambulance, car assistance, etc.) .

USR_E004 Acknowledge

Description:

The User must receive an acknowledgement as the Service Control Centre manages the request.

USR_E005 Acknowledge 2

Description:

In case the User Terminal does not receive the acknowledgement after a defined interval, the request must be re-sent automatically.

5.3 Application requirement

5.3.1 List of requirements The requirements have been categorised into three types or levels, namely: ‘Must’, ‘Should’ and ‘Nice to have’, in order to help the definition of what is developed in the real prototype for this project:

• Must: This type is considered an essential feature of the system and must be implemented.

• Should: This requirement is not considered an essential feature. However, it would be beneficial and should be implemented if the time permits it.

• Nice to have: This is a particular type that offers a special feature or increases the power of the system but is not essential and the project can be finished successfully without it.

The requirements in this section have been categorised according to the classes defined above and are illustrated in the table “list of requirements”. This table is divided in two groups: “Pull mode” and “Push mode” requirements:

• Pull mode (reactive): These requirements correspond to functionalities in the system where the AI module (which falls within the working area of Rigel) does not generate automatic responses but,




instead, it reacts to requests from the info-mobility platform (within the working area of Next). For example, a k-p requests the status of a nearby k-p.

• Push mode (proactive): These requirements correspond to functionalities in the system where the AI module generates automatic orders or messages to the info-mobility module. That is, the AI module makes decisions without a triggering request. For example: When the AI module detects an unexpected behaviour of a k-p and it notifies the X-info system automatically.

Code Name Class Pull mode

REQ001 Message centre MUST

REQ002 Connections control MUST

REQ003 User register & identification MUST

REQ004 Location of k-p MUST

REQ005 Roles for each k-p MUST

REQ006 GUI for manager (Administrative panel) SHOULD

REQ007 Interface for the command centre MUST

REQ008 Data base for user and available units MUST

REQ009 Configuration data files SHOULD

REQ010 Information services for k-p MUST

REQ011 Knowledge of grounds and maps (GPS) MUST

REQ012 Alerts level classified by user role MUST

Push mode

REQ013 AI module MUST

REQ014 AI profiles NICE TO HAVE

REQ015 proximity alert MUST

REQ016 AI control level SHOULD

REQ017 Balance of unit MUST

REQ018 Path for patrols SHOULD

REQ019 Alert by k-p status MUST




Code Name Class REQ020 Knowledge of k-p status MUST

REQ021 Event launcher(ALERTS) MUST

REQ022 End and beginning of service NICE TO HAVE

REQ023 Short path SHOULD

REQ024 Alternative path NICE TO HAVE

REQ025 Resolution of ground cell SHOULD

REQ026 Timetables management SHOULD

REQ027 Perimeter for emergencies SHOULD

REQ028 Last position MUST

REQ029 Out of range MUST

REQ030 No response MUST

REQ031 Conventional log MUST

REQ032 Graphical log and basic animation. NICE TO HAVE

REQ033 Programmed alert NICE TO HAVE

Table 3: List of application requirements

5.4 System Requirements Analysis This list addresses different general aspects of the system such as hardware, services, network and software modules. The requirements in the list are classified into three different levels: must, should and nice to have. This list is complementary to the user and application requirements. Within this project the consortium delivers a prototype which acts as working system that addresses all mandatory requirements, therefore being able to demonstrate the advantages and innovations of the project.

On the other hand the requirement analysis undertaken in the project covers all the desirable requirements (not only the system requirements but also the user and application requirements, described in a separate document) that a real operative system must address in order to be able to respond to and offer a quality of service in line with the market expectations.

Code Name Type Level

REQ001 PDA devices Hardware MUST




Code Name Type Level

REQ002 Mobile service provider (2G/3G) Services MUST

REQ003 Terminal connection control Software SHOULD

REQ004 EGNOS signal Services MUST

REQ005 EGNOS receiver Hardware MUST

REQ006 Wireless access points Network NICE TO HAVE

REQ007 Alternative wireless interface in device Hardware NICE TO HAVE

REQ008 Message centre Software MUST

REQ009 Identification control Software MUST

REQ010 Administrative modules Software SHOULD

REQ011 Common data base manager Software SHOULD

REQ012 Local data base Software MUST

REQ013 Monitor for emergencies Software MUST

REQ014 Alert manager Software MUST

REQ015 AI module Software MUST

REQ016 AI service configuration panel Software SHOULD

REQ017 Log system Software MUST

REQ018 Backup system Software SHOULD

REQ019 High availability Software. & network SHOULD

REQ020 Software maintenance Software SHOULD

REQ021 Remote control of global system Software & network SHOULD

REQ022 Statistics and results Software SHOULD

REQ023 Map provider Service & software MUST

Table 4: List of system requirements




5.5 System Requirements Compliance of Requirements This section presents a comprehensive report of compliance of the system developed against the stated requirements. These are divided intro three categories: user, application and system requirements. Not all requirements are met by the system, but at least those classified as mandatory (with level “Must”).

5.5.1 User Requirements Code Name Level Implemented

USR_M001 HMI Must YES

USR_M002 HMI UT Key Person Must YES

USR_M003 HMI UT Bus Must YES

USR_M004 HMI UT Bus2 Must YES

USR_M005 Bus position Must YES

USR_M006 Bus position 2 Must YES

USR_M007 HMI Tracing/tracking Must YES

USR_M008 Control over the path Must YES

USR_M009 Message Management Must YES

USR_M010 Key Person position Must YES

USR_M011 Key Person message Must YES

USR_M012 Key Person request Must YES

USR_M013 Key Person request 2 Must YES

USR_E001 HMI Must YES

USR_E002 HMI 2 Must YES

USR_E003 HMI 3 Must YES

USR_E004 Acknowledge Must YES

USR_E005 Acknowledge 2 Must YES

Table 5: Compliance of User Requirements

5.5.2 Application Requirements




The table below shows which application requirements are implemented in the prototype developed within the SPESSS project. For those requirements that are implemented, the table indicates the associated software module that addresses the corresponding feature. Also, where possible, the associated class in the module is also identified.

Note that some requirements are implemented by means of software modules in both sub-systems of SPESSS: the X-Info and AI sub-system.

Code Name Level Implemented Module Class REQ001 Message centre Must YES Plugin.EventViewer EventViewer

REQ002 Connections control Must YES MessagingComponent Messaging

REQ003 User register & identification

Must YES plugin.UserTree UserTree

REQ004 Location of K-P Must YES At X-Info: plugin.GoogleMap,plugin.Mappi

ng,GoogleMapWebInterface

At AI: com.rigel.spesss.framework.core

At X-Info: GoogleMapPlugIn,

Navigator, GoogleMap

At AI: KpPosition

REQ005 Roles for each K-P Must YES com.rigel.spesss Roles

REQ006 GUI for manager (Administrative panel)

Should YES At X-Info: Director, RMIDirector

At AI: com.rigel.webService

At X-Info: DirectorMain,

RMIDirectorMain

At AI: -

REQ007 Interface for the command centre

Must YES At X-Info: VSCC At X-Info: VSCCMain

REQ008 Data base for user and available units

Must YES At X-Info: DBManager

At AI: com.rigel.spesss.dataBase

At X-Info: IDBManager

At AI: -

REQ009 Configuration data files

Should YES At X-Info: config

At AI: com.rigel.spesss.dataContext

At X-Info: Configuration

At AI: ConfigParameter

REQ010 Information services for K-P

Must YES services.* TrackingManager, EmergencyManager, CheckpointManager

REQ011 Knowledge of grounds and maps

(GPS)

Must YES com.rigel.spesss Map

REQ012 Alerts level classified Must YES com.rigel.spesss.services -




Code Name Level Implemented Module Class by user role

REQ013 AI module Must YES com.rigel.spesss.aiModules AiCore

REQ014 AI profiles Nice to have

YES com.rigel.spesss.dataContext ConfigParameter

REQ015 proximity alert Must YES com.rigel.spesss.services ProximityAlertService

REQ016 AI control level Should YES com.rigel.spesss.dataContext ConfigParameter

REQ017 Balance of unit Must YES com.rigel.spesss.services BalanceOfUnitService

REQ018 Path for patrols Should YES com.rigel.spesss.services PathForPatrolService

REQ019 Alert by K-P status Must YES com.rigel.spesss.services UnavailableUnitService

REQ020 Knowledge of K-P status

Must YES com.rigel.spesss.framework.core KpStatus

REQ021 Event launcher(ALERTS)

Must YES com.rigel.spesss.services ClipsService

REQ022 End and beginning of service

Nice to have

NO - -

REQ023 Short path Should NO - -

REQ024 Alternative path Nice to have

NO - -

REQ025 Resolution of ground cell

Should YES com.rigel.spesss Map

REQ026 Timetables management

Should NO - -

REQ027 Perimeter for emergencies

Should YES com.rigel.spesss -

REQ028 Last position Must YES com.rigel.spesss.framework.core KpPosition

REQ029 Out of range Must YES com.rigel.spesss.services OutOfRangeService

REQ030 No response Must YES com.rigel.spesss.services NoResponseService

REQ031 Conventional log Must YES com.rigel.spesss Log

REQ032 Graphical log and Nice to NO - -




Code Name Level Implemented Module Class basic animation. have

REQ033 Programmed alert Nice to have

NO com.rigel.spesss.services programedAlertService

Table 6: Compliance of Application Requirements

5.5.3 System Requirements The table below shows which systems requirements are implemented in the prototype developed within the SPESSS project.

Code Name Level Implemented

REQ001 PDA devices Must YES

REQ002 Mobile service provider (2G/3G) Must YES

REQ003 Terminal connection control Should YES

REQ004 EGNOS signal Must YES

REQ005 EGNOS receiver Must YES

REQ006 Wireless access points Nice to have PARTIALLY

REQ007 Alternative wireless interface in device Nice to have NO

REQ008 Message centre Must YES

REQ009 Identification control Must YES

REQ010 Administrative modules Should YES

REQ011 Common data base manager Should YES

REQ012 Local data base Must YES

REQ013 Monitor for emergencies Must YES

REQ014 Alert manager Must YES

REQ015 AI module Must YES

REQ016 AI service configuration panel Should YES

REQ017 Log system Must YES




Code Name Level Implemented

REQ018 Backup system Should NO

REQ019 High availability Should YES

REQ020 Software maintenance Should NO

REQ021 Remote control of global system Should YES

REQ022 Statistics and results Should NO

REQ023 Map provider Must YES

Table 7: Compliance of System Requirements




6 Implementation Phase

6.1 The Design & Implementation Process Hereafter a list of the various steps in their logic flow in order to complete the implementation phase.

State of the Art Analysis

Requirements Analysis

Functional Analysis

Preliminary System Design

System Requirements Analysis

Overall Architecture Definition

Detailed System Components Design

Architectural Elements Implementation

System Integration

Table 8: System design & implementation steps

Starting from the Preliminary System Architecture Design stemming from the work done for the demonstration campaign, the implementation phase has been focused on the definition and development of a detailed design of SPESSS System architecture. The detailed design has been obtained through the analysis of the inputs obtained during the first stage of the project, together with the system requirements that constraint the whole system architecture.

In parallel the development of the new components foreseen was carried out in parallel, in order to have an early validation of the design of the architecture and to be able to begin the component tests.

The implementation of the system continued with the refinement and customization of the existing components in order to provide the expected services.

The last phase is characterized by the integration of the new components in the existing framework and a first round of integrity tests.

The conclusion of the phase coincides with the integration tests and the delivery of the working system.

6.2 System Architecture Design task Taking into account the aforementioned logical path followed, the Detailed System Design was obtained from the baseline traced by the Preliminary System Architecture Design, addressing the following points:

• Adaptation and detailing of sub-systems to cover results from system requirements definition;

• Integration of the new capabilities and interfaces of the X-Info infrastructure;

• Design of new components to cover all the user and functional requirements;

The following figure offers an overview of the described process.




Figure 7: Flow of the activities bringing to the Detailed System Architecture Design

The different sub-systems constituting the final SPESSS system architecture are:

• Mobile User Terminal

• Service & Emergency Control Centre

• Artificial Intelligent System

• External Service Providers




Figure 8: Logical view of the SPESSS system and the data flow exchanged among different actors

For the scope of this document the logical and physical architecture description is provided for following macro-components:

• Service and Emergency Control Centre, SECC;

• Mobile User Terminal, MUT;

• Artificial Intelligence sub-system, AI;

Regarding the External service provider the proposed interface towards their systems is described.




6.3 System Logical architecture This section provides an overview of the logical architecture1 of the SPESSS system identifying the main components that compose the system. The key features of this logic are:

• A logical module is defined as a software entity able to provide some set of services.

• The services provided by the module are defined in the specification of the module itself in terms of the interfaces (collection of operations) it offers.

• The inter-relationship between modules is defined in terms of data flowing between them as well as in terms of interconnections among interfaces provided and interfaces required by different modules.

• All possible interactions and the exchanged data flow between the logical modules become services and/or events in the definition of the interfaces dedicated to the logical module.

The logical modules of the SPESSS system can be classified in different sub-systems:

Service & Emergency Control Centre, is the part of the system responsible for providing control of the behaviour of the Mobile User Terminal such as radar tracks, flight plans, predictions and safety alerts. This macro component is based on an extended implementation of the X-Info Server platform, on which specific new components have been designed.

Mobile User Terminal, is the part of the system responsible for interaction with the system End User and the collection of precise geo-referenced data. This macro component is based on an extended implementation of the X-Info Client platform, on which specific new components have been designed.

Intelligent Artificial sub-system, is the part of the system responsible for interference possible scenarios and provide advice and alarms to the system End User based on the collection of precise geo-referenced data.

External Service Providers, is the part of the system responsible for providing external data (i.e. weather information and/or traffic data for the region of interest) necessary to enhance the quality of the services offers by the system.

As stated in the previous sections, not all the subsystems or their full implementation are the objective of development by the SPESSS project prototype.

1 By logical architecture (the logical view of the SPESSS system) we mean the identification of the logical modules that

comprise the SPESSS system and their inter-relationships.




Figure 9: The SPESSS Logical Model Architecture

6.4 System Diagrams Te behaviour of the SPESSS prototype system is described through the use of standard UML diagrams. In fact, since the first phase of the project (see RD02), the consortium adopted UML diagrams as describing and designing tools. For the main scenarios identified in the analysis phase, Fleet Monitoring and Emergency Management, a complete set of diagrams (Flow , Activity and Sequence) were provided to describe the behaviour of the system and of all the sub-systems.

6.4.1 Fleet Monitoring The service is devoted to the control of the vehicle fleet directly managed or/and in use of organizations to guarantee the mobility of Key Persons and other people involved in the event.

6.4.1.1 Flow Diagrams The flow diagrams are provided for each of the main subsystems which the SPESSS prototype is composed. The proposed diagrams aimed to explain the internal behaviour of each subsystem with respect to the scenarios described in the DD02 document through the specific Use Case. The full description and the diagrams are in the project document DD04.

6.4.1.1.1 User Terminal The first component described is the User Terminal. Three different diagrams were proposed in order to explain its internal behaviour in relation to the possible situations that it must handle.

Standard behaviour: the first diagram depicts the internal flow data and checks of the User Terminal subsystem that guarantees the provision of the expected functionalities.




Received alarm behaviour: the second diagram depicts the internal flow data and checks that it allows the User Terminal to respond to the receipt of an alarm.

Received request position behaviour: the third diagram depicts the internal flow data and checks that it allows the User Terminal to respond to a request of a new position.

6.4.1.1.2 SECC The second component described is the SECC. Only one diagram is proposed in order to explain its internal behaviour in relation to the possible situations that it must handle.

Received UT event behaviour: the diagram depicts the internal flow data and checks of the SECC subsystem that guarantee the provision of the expected functionalities as a new event is received from a UT.

6.4.1.1.3 Artificial Intelligence The diagram depicts the internal flow data and checks of the Artificial Intelligence subsystem that guarantee the provision of the expected functionalities as a new event is received from a SECC.

6.4.1.2 Activity Diagrams The proposed diagram shows the interaction between the three subsystems during typical behaviour of the SPESSS system and how the relevant data and controls are managed in each subsystem.

6.4.1.3 Sequence Diagrams The sequence diagrams aim to describe the SPESSS system behaviour on a temporal level. In fact the focus is on the temporal data exchange between the different subsystem and functionalities execution within the SPESSS system. The proposed diagrams are on the two most important situations faced by the system

Tracking

The first diagram depicts the sequence of the execution of the basic functionalities implemented in the case of vehicle tracking under normal behaviour.

Tacking alarm

The first diagram depicts the sequence of the execution of the basic functionalities implemented in the case of vehicle tracking during exceptional behaviour.

6.4.2 Emergency management The service is devoted to the emergency management of an expected situation. The SPESSS system aims to manage two different possible situations: the former is based on a manual request for support by a Key Person or a vehicle driver, the latter is based on the elaboration of received information by the Artificial Intelligent sub-system.

6.4.2.1 Flow Diagrams The flow diagrams are provided for each of the main subsystems of which the SPESSS prototype is composed. The proposed diagrams aim to explain the internal behaviour of each subsystem with respect to the scenarios described in the RD02 document through the specific Use Case.

6.4.2.1.1 User Terminal The first component described is the User Terminal. One diagram is proposed for each of the possible scenarios in order to explain its internal behaviour in relation to the possible situation that it must handle.




Received alarm behaviour

The diagram depicts the internal flow data and checks that it allows the User Terminal to respond to the receipt of an alarm.

Manual alarm behaviour

The diagram depicts the internal flow data and checks that it allows the User Terminal to send a request for support to the SECC.

6.4.2.2 SECC The second component described is the SECC. Only one diagram is proposed in order to explain its internal behaviour in relation to the possible situation that it must handle.

Received AI alarm behaviour

The diagram depicts the internal flow data and checks of the SECC subsystem that guarantee the provision of the expected functionalities as an alarm is received from the AI sub-system.

Received UT alarm behaviour

The diagram depicts the internal flow data and checks of the SECC subsystem that guarantee the provision of the expected functionalities as a new request for support is received from a UT.

6.4.2.3 Activity Diagrams The proposed diagrams show the interaction between the three subsystems during typical behaviour of the SPESSS system and how the relevant data and controls are managed in each subsystem. The proposed diagrams are on the two most important situations faced by the system.

AI generated alarm

The first diagram depicts the interaction between the three main sub-systems in the case of the AI sub-system generates an alarm in the SPESSS system.

UT generated alarm

The request of support or help from a UT must be accessible in two different ways: the former must be easy and intuitive and request generic support, the latter must allow the requester to chose a specific emergency operator.

• Panic alarm

The first diagram depicts the interaction the interaction between the three main sub-systems in case of request for generic help from a UT.

• Specific operator alarm

The second diagram depicts the interaction between the three main sub-systems in case of request for help from a UT for a specific operator.

6.4.2.4 Sequence Diagrams The sequence diagram aims to describe the SPESSS system behaviour on a temporal level. In fact the focus is on the temporal data exchange between the different subsystem and functionalities execution within the SPESSS system. The proposed diagrams are on the two most important situations faced by the system.

AI generated alarm

UT generated alarm




6.5 SPESSS System decomposition This section provides a detailed description of the logical modules that form the SPESSS system. Services provided and required by the each module are depicted as well as data flows between them.

6.5.1 Service & Emergency Control Centre The SERVICE & EMERGENCY CONTROL CENTER (SECC) is the core for the emergency management. It contains components for the communication with the OBUs and for the storage of the received data.

Figure 10: SECC Detailed Logical View

As described in the previous sections, the X-Info components are developed in two different environments, RMI and CORBA. In the next sections the architecture and behaviour of the different components in their respective environments is described.




6.5.1.1 CORBA components 6.5.1.1.1 Director

The Director has been designed and implemented (C++) with the objective of monitoring all the other components of the system, visualizing their status and managing a session log for every activated component. It also provides robustness for the entire infrastructure; during the system start-up it manages the initialization of all the necessary components, it resets “not-responding” components and after a parametric number of attempts reloads them on other machines (when the problem is not a software issue) by executing proper Operating System commands on the remote machines, while respecting different components loading priorities: the loaded components are also registered in an appropriate data structure.

The monitoring mechanism is implemented by the utilization of IDL Interfaces belonging to communication channels between Director and every monitored component. The monitoring process is based on dummy methods called ‘check’. Every component implements this function which simply return the ‘True’ Boolean value.

The ‘check’ functions are called from the director to every component, respecting a parametric time interval, so that, if the component responds with an acknowledgement it is determined to be “alive”, otherwise the Director reloads it, if necessary on another remote machine.

Special feedback operations for the components can be requested by the Service Control Centre by mean of rich IDL Interfaces.

Finally, the Director, like all other components, logs its activities on the Database, by the use of a connection class that communicates with the Event Manager.

All the operations and the duties described for this component are managed on the basis of predefined and preloaded policies. The policies contain the rules that the system must obey regarding the component start-up and shutdown plus the monitoring activities on the behaviour of each single component. In addition the implemented policies give the rules that specify the dynamic reconfiguration process of the system in case of failure (i.e. a component that crashed on a remote server is reloaded on another remote server).

The policies are loaded from a specific configuration file at the start-up of the Director

6.5.1.1.2 Event Manager The Event Manager component provides Database managing capabilities to the CORBA environment and communicates with the system by means of the IDL Interfaces provided by CORBA environment.

The task of the Event Manager is the logging of data on the database:

• Message log;

• Positions log;

• System operations log;

The Event Manager component receives from other components of the CORBA environment access requests to read or write on the Database and elaborates them by parsing the corresponding event variables. Subsequently, in case of a write request it directly executes the request, otherwise, in case of a read request, it generates the appropriate query and executes it. The results of the query are collected, structured and sent back to the Service Control Centre, which forwards them to the relevant component. At the end of every operation, the Event Manager updates the system log on the Database.

6.5.1.2 RMI Environment




6.5.1.2.1 VSCC The VSCC implements the user interface with the service side of the system. The architecture is composed of a static framework and a dynamic Plug-In structure; this structure is composed of the ad-hoc sub-components (such as the ContentInfoMonitor) connected to the corresponding implemented service. The framework is static in the sense that offers a common application layer for the execution of each implemented Plug-In; the plug-in structure is dynamic because it can be changed during the application runtime without the modification of the static code.

The Core component is the kernel of the framework and manages the different Plug-Ins and sub-components contained in the VSCC.

6.5.1.2.2 Terminal Server The Terminal Server component acts as a gateway between the client part and the server part of the system: in fact it is the only server component that can accept connections from a client.

The terminal servers main tasks are:

• to listen for a client’s connection, to register and authenticate a client to the system, to serve any subsequent client request (by forwarding to the MessagingComponent) and to forward any system message to the client itself

• Logging of events:

o every incoming event from a client is dispatched to the Messaging Component and then logged to the DB through the DBManager;

o every incoming event from the server side is dispatched to the target client and then logged to the DB through the DBManager.

Each TerminalServer is able to manage a set of clients at the same time; the task is made possible by maintaining a vector of connected clients identified by unique ID.

6.5.1.2.3 Messaging component The messaging component only performs two tasks in the system, but it’s role is the most important for the infrastructure. The main task is to provide the system with the event routing facilities it needs. Every event in the infrastructure reaches the MessagingComponent, which checks the type and its destination (via the unique ID of the destination component which is a basic information of the event itself), and forwards it to the destination component. The second task is to keep updated the list of associations between the component IDs and the remote references of every distributed servers components that are correctly registered to the system; In case of client components the association is between the client component ID and the reference of the server component that acts as a “gateway” between the client component and the infrastructure. With this list, the event routing facility is easily and quickly exploited.

The messaging component is the event routing core of the system since each event traversing the system is bound to pass through the messaging component to be redirected towards the correct destination. The messaging component is predisposed to live in both of the two different middleware environments (CORBA and RMI).

The MessagingBasic unit is the kernel of the messaging component and implements all of its interface methods. The event routing process makes use of the ConnectionHash to dispatch events to the correct destination; the event dispatching is made possible by the ConnectionHash that associates ID and references, thus enabling the forwarding of an event to the software reference corresponding to the ID of the destination component.

6.5.1.2.4 DB Manager




The DBManager component manages the interactions between the database and the components deployed in the RMI environment. The component supports free query execution as well as predefined queries.

The DBManager also supports query capabilities towards the database for complex java objects that need to implement the SQLData interface that is needed by the native database java engine. For every event a specific Event Handler is created at runtime.

The ‘DBConnectionData’ sub-component reads the parameters needed for database connection from the configuration file “db.ini” and stores them.

6.5.1.2.5 DB Service Handler The DBServiceHandler is a database resident component and it is comprised of a set of Java procedures that allow the sending of events from the Database; this task is fulfilled by the utilization of a remote handling component which obtains a Messaging component reference and sends the event to the target system component.

6.5.1.2.6 GoogleMap The GoogleMap component publishes over the web the fleet management data coming from the X-Info infrastructure over a Google-based map. It can be viewed as a ‘distributed component’ because in order to implement the above functionality it must make use of the following distributed components:

A VSCC Plug-In that allow publishing on the web the positions received from the clients

A PHP-based component that allows saving to an appropriate XML data structure the published position

An optional XML file for map enrichment purposes

A JavaScript component needed to interact with the Google map service

The Google Map Service itself

The actual Google Map component architecture allows the utilization of an asynchronous web interface for the visualization of raster maps; it should be noted that such an interface is effectively independent and separated from the rest of the system.

6.5.1.2.7 Tracking component The TrackingComponent manages the tracking service in terms of verifying the actual position of each client to be monitored and verifying their status. The TrackingComponent implements the Tracking service logic and is coordinated by the VSCC component. It is comprised of:

Furthermore the Tracking component implements the routing capability in the SPESSS system.

The Router is the main implementing component, it implements the routing functionality through the Dijkstra algorithm that executes its computation over the graph data structure.

The route guidance component is not present in the SPESSS system.

The calculated path is sent to the interested client through the messaging component.

6.5.2 The SPESSS data structure 6.5.2.1 The database schema

The database is characterized by three different categories of tables:

1. The tables which store configuration data of the X-Info platform;




2. The tables which store the system and service events;

3. The tables which store service related data.




Figure 11: SPESSS X-InfoDatabase Schema

In the following paragraphs a detailed description of the individual tables is provided.

6.5.2.1.1 Configuration tables Three tables are used to configure the environment of the X-Info platform:

IT_COMPONETTYPE stores the type of the User Terminal that are used in the system;

IT_COMPONET stores all the components (server and client) that are recognized by the system;

XUL_TABLE stores the User Terminal HMI that are used in the system.

6.5.2.1.2 Event tables Three tables are used to store the service and systems events:

IT_EVENT stores the service and systems events;

IT_EVENT_E stores the events generated to signal system errors;

IT_EVENT_HISTORY stores historical event data.

6.5.2.1.3 Service tables Six tables are used to provide the advanced tracing/tracking service:

APR_FREQUENCY stores the interval time to be used by the UT to configure the frequency of sending the position;

ROUTE_TABLE stores the paths that the busses must follow;

CHECK_POINT stores the precise points to be used to check the busses behaviour;

ITER_CKP stores the association between every path and the check point;

PERCORSO stores the forward and backward paths that define the entire bus route;

6.5.2.2 Checkpoint data structure The checkpoint data structure is represent in XML file format, a sample of which is provided below: <?xml version = '1.0' encoding = 'UTF-8'?>

<path id="1" tratta="A" description="MC8">

<checkpoint order="1" type="5" minLon="7.659764703816166" minLat="45.030250742919485" maxLon="7.660911296183834" maxLat="45.03118125708051"/>




</path>

Each checkpoint is a component of a path that contains two or more checkpoints. Each path is composed by the following attributes:




• Id: the unique identifier of the path.

• Tratta: the type of path, it could be forward (A) or backward ( R ).

• Description: a verbose description of the path.

• List of checkpoints: The required checkpoints are the start and the stop depot (eventually they could be the same one).

Each checkpoint is comprised of:

• Order number: the index of the checkpoint in the ordered list

• Type: it could be start (5), intermediate (3) or stop (4)

• The bounds: composed by

• MinLon: the minimal longitude

• MinLat: the minimal latitude

• MaxLon: the maximal longitude

• MaxLat: the maximal latitude

6.6 The SPESSS Artificial Intelligence System From a high level point of view, the AI sub-system could be considered as an auxiliary service connected to the X-Info platform. That is, the X-Info platform could work on its own without exchanging any information with the AI part, but then it would only offer conventional information services to the final users and fleet management capabilities. The reason for integration between them is to have an expert system or “brain” that knows how to behave depending on the circumstances of the environment.

For the whole SPESSS system to work properly, the X-Info infrastructure needs to inform the AI sub-system about all events that are taking place in the area under control. This means basically to send the K-P geographical positions in real-time, so that the AI module can know where each K-P is at all times, as well as send messages to inform about emergency situations or alerts being raised. The X-Info infrastructure just keeps on operating and relies on the AI module to make any decisions about the course of action to take. If necessary, the AI module would ask the X-Info module to send messages to specific K-P’s, which X-Info would relay accordingly.

The AI sub-system has at its core an expert module that actually implements the artificial intelligence in SPESSS. This element is based on a rule-based engine developed using the Clips language. It is generally referred to in this document as Clips module, Clips service, Clips core, etc.

In a simplified way, we could say that all the modules of the AI sub-system are built around the Clips core as auxiliary tools that process the real-world information (e.g. positioning co-ordinates) as well as system information (e.g. data bases, files, communication, etc.) in order to present a simplified version of the environment to the Clips core. The Clips component only understands simple facts in a structured format and generates simple logical outputs that the software modules around must process and act upon.

It is important to understand that the Clips module and therefore the AI sub-system do not implement automated learning. The intelligence of the system must be configured by expert humans who decide how the SPESSS system shall react under different situations. One of the advantages of using this rule-based artificial intelligence is that humans can add, remove and change policies at will and without modification in the software: all that they have to do is configure the rules (simple or complex, as they wish) through a GUI. The rules can be complex and




take account of a large number of conditions, past and present, and the expert system handles all that, checking its accumulated knowledge.

The Artificial intelligent part consists of a set of software modules, each one with a specific function. The AI module is developed in Java language with J2EE 1.5 specification, and is capable of running within an application server with a real JMS implementation. The following diagram offers a general view of the AI infrastructure.

Figure 12: AI Module Architecture

The above diagram represents the AI system split up into components and shows the dependencies among these components.

All the packages exposed above are explained below using Class diagrams, where each class is represented by a box with the name of the class written inside it.

A compartment below the class name shows the class's attributes (i.e., its properties). Each attribute is shown with its name and type.

The class's operations appear in another compartment. Each operation is shown with its name, and with its parameters and return type.

Attributes and operations have their visibility marked as follows:

"+" for public

"−" for private

A description of each class and their relationships is provided. However, not all of the attributes and operations are described for simplicity: they are not of relevance in this document.




6.6.1 AiLoader This module is the entry point of the AI infrastructure. When the application server is starting, the AiLoder starts to load the user and password from local configuration files to connect with the local data base. The tasks of AiLoader are described in the following points:

• Load data base options: First of all it loads information about data base connection.

• Get profiles: This module loads the current profile from the local data base.

• Configure services: Load all configuration options of each service related with the current profile. We can have one or more profiles stored in DB but only one can be run at a time.

• Launch AiModules: Prepare and launch the AiModules with the current profile.

• Refresh data: The module is responsible for reloading all configuration settings if the webService sends a signal if any settings have been changed and the user wants to refresh the data. The user and password data is persistent all the time unless it is reloaded.

6.6.2 AiModules This module is the core of the Ai sub-system. It is aware of all modules and coordinates them and receives information about each one. Its functions are the following:

• Scheduler services: This module launches each service and controls its execution time. The scheduler can start and stop a service if it is required by the administrator.

• Clips control: The basic function of the system is to send an alarm to a K-P when an event happens. AiModules prepares rules and listens to events from the Clips module.

• Event Launcher: When the core of AI system receives an event from a service, it is analysed and the responses are send to X-info using the SPESSS framework.

• Data container: All data basic structures stored in temporal memory are managed by AiModules. Some of these are: Maps, List of current K-P units in the system, types of emergencies and lists of services.

6.6.3 DatabaseManager This module manages the connection with the local data base. DataBaseManager is used by WebService to update configuration settings such as rules, emergencies, roles, Ai profiles and so on. The access method of this module is by means of a JDBC driver implemented in Java language.

6.6.3.1 Data base design The database platform used in the AI system can be a standard SQL one, such as MySql server. DataBaseManager uses stored procedures. The use of these procedures increases the efficiency of a data base access. The following diagram shows the local data base design of the AI system.




Figure 13: AI Data base structure

6.6.3.2 Tables description • Users: This table holds the administrator users of the Ai system. The system authenticates an user and

create a web session by means of this table so that administrator users can have access to the web services.

• Aiprofiles: The system can have one or more sets of configuration settings. A set of configuration settings is considered as a profile in the Ai system. This table holds the names of profiles and references to the Config table.

• Services: This represents the services in the system. It has a special field that indicates if a service is active or inactive at this time. Each service has a reference to Aiprofile table.

• Config: This could be considered one of the most relevant tables because the behaviour of each service depends of the field values stored in it.

• Rules: All rules for the Clips module are stored in this table. When the system starts, all these rules are loaded by the Clips module to create the expert system.

• Roles, emergencies and messages: These three tables have all the necessary data to configure the expert system.




6.6.4 WebService The WebService module provides a web interface to configure all aspects of the AI system. The main functions of this module are described in the following points:

• Status control: This module allows administrator users to know the actual situation of each part of AI system in each time. It shows generated alerts and related logs.

• Administrator: An administrator can change all the configuration parameter of a service easily.

• Adding user: The system allows the administrator user to add new administrator users with different profiles.

6.6.5 Clips The Clips module is really the part of the system where the key artificial intelligence lies. It is an implementation of a rule-based expert system using the Clips language (hence the name). To understand the way it works, we have to introduce two main concepts: facts and rules:

• The facts are all the information about the environment that the expert system collects. In the SPESSS implementation, this information includes the places or areas where the K-P’s have been, the messages they have received, the roles that have been defined for them, etc.

• The rules define how the system must react to new circumstances that take place. They are a translation into a formal language of the expertise of the people (administrators) who configure the system.

Both the facts and rules evolve in time: The facts or knowledge grows as new events are taking place in the environment. Also, new rules are added or some old rules are removed as the expert people who configure the system decide to carry out new policies for management of the situations. The facts and rules are kept stored in separate text files.

The rules normally define a reaction of the system (e.g. generating an output) if a specific set of conditions are met. The conditions are expressed generally as logical values or states of the facts. For example: If a person is in area A and has not received message B, then send him/her message B.

In SPESSS, we define a common structure for the rules so that they can be built by the administrator users through a web-based GUI. In short, each rule has these parameters:

• The event that launches the rule. The user can define the type of event (positioning, emergency, internal) and the value that triggers the rule (which can only take a list of values, depending on the type).

• The conditions to be met. The user can select a number of logical conditions, based on the knowledge held by the expert system, that need to be met for the rule to be applied. The conditions may include circumstances such as the messages received by the associated K-P, the areas where the K-P has been, the role of the K-P, etc.

• The consequence or output to be generated in case all conditions are met. The output is normally configured as a given type of message and an identifier for the best message to be sent, together with a destination for the message. The destination could be a K-P (the same that triggered the rule, e.g. by changing his position), all K-P’s of a given role or all K-P’s in a given area. But the output could also be an internal message to another software module to ask it to carry out some special action.

From a software design point of view, this module generates events which are listened to by the AiModule. It is the core of the basic AI service and it is the unique service that can not be deactivated. This module allows:




• Communication with Clips libraries: To communicate and use the native Clips language C library.

• Abstraction : Clips module can prepare the expert system based on Clips language with few single JAVA methods.

6.6.6 Algorithm This module provides a set of algorithms to calculate positions and areas on the map. Some algorithms that are developed are:

• Position: This algorithm indicates if a K-P is in a correct position at a particular moment.

• Area: It works out whether a K-P is in a specific part of the map such as within a predefined area.

• Nearest unit: It provides the reference to a K-P that is the nearest to a given point in the map.

• Balance of units: This algorithms indicates a possible distribution of K-P units on the map.




6.7 The SPESSS Mobile User Terminal In the following chapter the personalization of the MUT basic architecture to meet the requirements of the SPESSS project is described. In this case the description of the updated or ad-hoc developed component is provided.

Figure 14: SPESSS User Terminal Logical Architecture




6.7.1 HMI The HMI logical block represents the application graphical interface. The graphical interface of the SPESSS MUT is not a static one but is provided dynamically from the Server. The GUI is generated during the runtime application from a XULParser engine.

The XULParser component reads XUL (XML User interface description Language) file that describes the user interface aspect, parses from the file the binding between the interactive graphical interface components (widget) and the application function defined in the ‘Action’ package.

With this approach it is possible to change the GUI during the application runtime and bind it to different function (for example the server could send to the client a new XUL file and a new action package to the client, and in this way both the user interface and the defined functionalities could be changed). This approach allows to have always a very simple interface displayed, but the interface can be updated in case of need.

6.7.2 Mapping The mapping block is comprised of a set of specialized components: the MapManager, the MapReader and the Rendering component for the visualization of vector maps.

The MapManager is the vector map manager: containing the graphical components needed for the HMI integration and the vector map visualization; it has references to the MapReader and the Rendering components.

The MapReader component is dedicated to loading the map data and to make it available to the MapManager and the Rendering components.

The Rendering component completes the Mapping logical block. It allows the display of the raw data read from the MapReader. The displayable map is passed to the MapManager for visualization.

6.7.3 Navigation The navigation logical block contains the EGNOS class hierarchy.

The EgnosInterface formalizes the access to the position receiver interface. Every EGNOS class represents a different way to obtain a position data structure:

• EgnosBT: is the class that interacts with the satellite receiver’s serial port through a native C++ DLL.

• EgnosCremeAdvanced: is the class that interacts with the satellite receiver’s serial port through the Creme java libraries.

• HISEgnos: is the class that simulates the positioning mechanism by reading the positions logged on a history file.

There are also classes specialized for simulation and testing purposes that use different kinds of log files to simulate the position receiving process.

6.7.4 Services The services logic block is a container for the services realized for a particular implementation. The services HMI package contains the HMI components needed for the different services. Each service is implemented as a Plug-In inserted in the services container. The service Plug-Ins specific for SPESSS are:

• EmergencyManager: The Emergency service manager allows the system to manage the emergencies in the receiving and sending process. The component enables the sending of an emergency message to




the SCC and a wait the acknowledgement for an established timeout period. If the timeout expires, the emergency message is resent until an acknowledgement is received.

• CheckpointManager: The tracking service manager loads and maintains the checkpoint data structure when the tracking service is active. It verifies if the current client position is obtained from the expected checkpoint (the next to be visited). In this case it sends to the server the checkpoint and the position data of the client. This communication with the SCC handles the tracking monitor process.

6.8 The SPESSS intra-system communication mechanism

This section describes the design of the communication mechanism established between the two major parts of the SPESSS platform: the X-Info and the AI sub-systems. These parts of the complete system can be located not only in different physical computers but also at very distant premises with different computing frameworks and infrastructures.

The design of the communication framework is intended to ensure flexibility, so that some aspects of it (such as the complete list of types of messages or specific reactions to new messages) can be added or modified in the future. The current version of the design includes all the types of messages that have been considered necessary in order to fulfil the requirements of the SPESSS project.

6.8.1 Introduction The main purpose of this section is to describe the method used to implement the communication between the X-Info and the AI sub-systems. The following figure offers a general view of the structure.




Figure 15: Communication Protocol

The chosen communication mechanism must address three main constraints of the project:

1. Allow the consortium companies the implementation of the components under their responsibility independently from the other work;

2. Allow the systems comprised in the SPESSS infrastructure to work independently;

3. Optimize the data exchange.

The communication method chosen is an asynchronous model based on standard JMS implementation. The main feature of this method is the abstraction it offers from underlying networking considerations. This ensures reliable and easy integration between both systems, even if they are hosted at separate computers and with different supporting infrastructures.

As we can see in the Figure 15, the JMS queues (input & output queues) receive and send events or information between the X-Info and AI systems, while they guarantee the decoupling of them.

6.8.2 General message format The first step for creating a protocol is to define the general message format. The message is encapsulated in an XML file. Each XML field has relevant information about the message command. The JMS provider supplies




XML files that must be parsed by the XML layer. This layer extracts information and invokes methods for each framework.

6.8.3 General XSD schema file

Figure 16: General XML File

6.8.4 Schema diagram

Figure 17: XML Schema Diagram

6.8.5 General XML example This is an extremely simple example to illustrate a SPESSS XML message. This example has no real meaning in the system – instead, reference words have been included in square brackets as place holders to show where the actual values would be placed.




Derived from the XSD schema, it is provided an XML file general example. <?xml version="1.0" encoding="UTF-8"?> <spesss-message xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="XXX.xsd" >

<message-features date=”xx:xx:xx” hour=”xx:xx:xx” id=”xxx”/>

<command>[command code]</command>

<ack>[true | false]</ack>

<param1></param1>

<param2></param2>

....

</spesss-message>

Field description:

Message features: It represents aspects of the current message such as time or date.

Protocol command: This part represents the kind of message and its content. For example, the command code indicates whether this is a positioning event or an emergency event. See descriptions below in this document.

Ack: status is ‘True’ if this message is an acknowledgement to a previous message. It’s status is ‘False’ if it is a normal message.

Parameters : The relevant information of each message.

6.8.6 The Implemented Messages This section presents the complete list of types of messages implemented in the communication framework, along with a description of what they are used for. The sub-section below just collects all the types in a single list for clarity. Then, they are described one by one in the next sub-sections.

6.8.6.1 List of commands The table below presents the list of types of messages that are implemented in the communication framework. Each type is identified by a “command code” (see place holder in example message above). For each type, the table shows which part of the platform is the origin of the message, according to the client-server model: server refers to the AI sub-system and client to the X-Info platform.

There is one particular type of message that can be sent by both sides of the communication infrastructure: the acknowledgement (ACK) messages, which are responses to messages of any other type. They are identified in the XML file by setting the <ack> field to “true” (see place holder in example message above) and they keep the command code of the request message that they confirmed as processed.

When the messages are received at one of the sides of the communication, first of all they are parsed to extract the values of the parameters. The first parameter that is looked at is the command code, which informs about the type of procedure that should be followed. This way, the core software module at each side (e.g. AiModules in the AI sub-system) knows how to act in relation to the message.

Following the table, there is a description of each of the types of messages.

Command code Name Type Sender




Command code Name Type Sender

0 Connect. Request/Response. client

1 Disconnect. Request both

2 Send basic object Request/Response client

3 Add role Request/Response client

4 Add K-P unit Request/Response client

5 Add kind of message. Request/Response client

6 Create an incident in the system. Request/Response client

7 Update K-P position. Request/Response client

8 Update K-P Status. Request/Response client

9 Remove a K-P. Request/Response client

10 AI alarm message. Automatic response server

11 AI alarm with destination. Automatic response server

12 Alarm for NEXT platform. Automatic response server

13 Send object area Request/Response client

14 ACK. Response both

Table 9: List of commands




7 Dissemination Activities

7.1 Objectives of the Dissemination Plan Depending on the phase of the project, Analysis, Implementation and Technology Transfer , three main activities, or dissemination steps, can be identified:

1. “Spread the word”. The SPESSS Project has to be presented to as many potential stakeholders as possible. Presentations should be shaped differently according to each type of potential stakeholder, in order to effectively explain:

o what SPESSS is about (objective, timing, target countries…)

o what SPESSS is aimed at

o which of the project partners can provide appropriate expertise

2. Eliciting interest and commitment. Strictly related to the previous goal, “commitment” means effective collaboration of stakeholders in developing next steps of SPESSS. Different levels of collaboration are possible, ranging from general feedback to “data-gathering” in support of research, or even to “joint design, implementation and test” of potential applications.

3. Measuring and disseminating results of pilot tests.

These goals must be considered as non exclusive, as they can be achieved sequentially or sometimes in parallel, as indicated in the following paragraph as steps of the process.

The dissemination activities carried out by the consortium wants to obtain three main different goals:

1. Enlarge within the potential end-user the knowledge of EGNOS and its added values;

2. Introduces to the targeted SPESSS project audience the innovative concepts that are beyond the proposed system;

3. Built on the developed system, a commercial system ready to be used.

7.2 Materials The consortium prepares different materials to be used in the dissemination activities:

• An abstract of the project, approved by GJU to use for the Leaflet prepared within the Progeny project for the Galileo Workshop for SMEs in Brussels (2006) and used as baseline for all the dissemination materials

• A presentation of the project, approved by GJU, which has been used as baseline for the presentation of possible prospects and partners

• A poster of the NEXT R&D department highlighting the projects managed by the department

• A leaflet of the NEXT R&D department highlighting the projects managed by the department

7.3 Dissemination activities




Tools:

The Consortium have prepared and updates the SPESSS website as new outputs or news are available.

Articles:

“Un Sistema Sicuro per la Gestione di Eventi su Larga Scala basato su EGNOS: il Progetto SPESSS” published on GEOMEDIA magazine.

Meetings:

April 2006 Rome: The results of the demonstration activities held in Turin during the 2006 Winter Olympic Games were presented to Telespazio R&D responsible to analyze possible re-utilization of concepts demonstrated.

May-June 2006 Rome: The objectives of the project and the SPESSS proposed architectures has been presented to representatives of the Rome Fire Brigades department.

Result: NEXT implements a system to support the emergency management of the Rome Fire Brigades based on the X-Info platform.

July 2006 Rome: The objectives of the project and the SPESSS proposed architectures has been presented to representatives of R&D department of SELEX (Finmeccanica Group) to analyze possible re-utilization of concepts implemented.

January 2007 Rome: The acquired results and overall architecture design has been presented to SOGEI in order to study the possibility to consolidate and extend the functionalities offered by the system.

March 2007 Rome: The project SPESSS is presented to the head of the Civil Protection for the Provincia di Roma area.

Major Events:

Several events have been attended by the project team.

Events after the conclusion of the project are also been identified as opportunities for disseminating information regarding SPESSS.

A table to summarize the activities performed during the project time frame by the consortium:




Table 10: Dissemination activities

Planned/actual

Dates Type Type of audience Countries

addressed

Partner responsible /involved

Conference Research

April 2006 Galileo Workshop for SMEs Research & Industry

NEXT/RIGEL

Publications

March 2006 Press Article

“Un Sistema Sicuro per la Gestione di Eventi su Larga Scala basato su EGNOS: il Progetto SPESSS”

Research & Industry

ITALY NEXT

February 2007 Project web-site ALL WORD NEXT

Meetings

April 2006 Industry (Telespazio)

ITALY NEXT

May-June 2006 Organization (Fire Brigades)

ITALY NEXT

July 2006 Industry (SELEX) ITALY NEXT

January 2007 Industry (SOGEI) ITALY NEXT

March 2007 Institutional (Provincia di Roma)

ITALY NEXT




7.4 The official web site The website is an important medium because it works both as an internal communication channel among partners and as an external medium, addressed to the wider public.

The website has been regularly updated with main project achievements, demonstration events and international press reviews. Users have detailed information concerning the project, its technical issues and its potential applications.

A strong “link policy” should be established in order to increase traffic towards the website. Important links concerning GJU/GSA are provided for visitors interested in more information about satellite technologies and functioning of Galileo.

The partners area is reserved for partners who can gain access by username and password. A strong security system is employed to protect private data, this area provides a repository for all project documents and information related to meetings, MOMs next steps, etc.

Figure 18: SPESSS project web site welcome page




The site is divided into three levels, comprised of sub pages deriving from the home page (which is the highest level), as illustrated in the table below.

HOME WHAT IS SPESSS NEWS

PARTNER AREA

LEVEL 1

• Project

• Consortium

• WorkPlan

• Links:

o http://ec.europa.eu/dgs/energy_transport/galileo/index_en.htm

o www.galileoju.com

o www.esa.int

• Activities

• Demonstration Events

• Dissemination Events

• Results

• Communications

• Deliverables

• Meetings

LEVEL 2

• Consortium:

o contributions

o partner site

o contact us

• www.galileoju.com

• Deliverables:

o PDF

• Meetings:

o Minutes of Meeting

o Presentations

Table 11: SPESSS sitemap




The technology transfer plan

A series of tasks need to be undertaken as part of the technology transfer work of the SPESSS project. The technology transfer actually started right from the beginning of the project, even if we call it a final phase, given the specific circumstances under which the project took place.

This chapter highlights the main tasks planned and performed, also outlining the ones planned for the future.

7.5 Dissemination The core part of the technology transfer activities consists of making the results of the project publicly available and raising visibility of them. In other words, disseminating the results and the relevant achievements across the industry, with special focus on the fields of interest: special events management, security and emergency coordination, Galileo deployment and applications, etc.

Extensive work was carried out within the project to design a suitable dissemination plan and to define the activities that would be done and the technology transfer products (documents, reports, brochures) that would be produced and disseminated.

7.6 Exploitation The exploitation phase really starts with the consolidation of the results of the project, after finishing all technical developments. In SPESSS, the associated activities are out of scope of the contract with the GSA (formerly the GJU). They are launched after the acceptance of works by the GSA, following the Final Review Meeting.

The exploitation of results involves a series of tasks:

D) Conceptualisation of project works and the SPESSS system. The objective of this task is to produce simple yet precise descriptions of the technical innovations achieved and the software components developed. This is necessary as an enabling step for defining subsequent technical and marketing strategies.

This task is done in cooperation by all the partners and also solely by each participating company, focusing on their particular expectations.

The estimated duration of this task is less than 1 month.

E) Commercial and technical agreements of utilization. The partners define in detail what work done during the project becomes new know-how and what is the ownership over the results.

This task is carried out in cooperation by the partners and with the support of legal advisors.

The estimated duration is less than 1 month.

F) Technological observatories. The partners set up their own procedures for continuous monitoring of the State-of-the-Art and report directly to project leaders and decision makers.

This task is carried out independently by each partner, although fluent communication is advisable to exploit synergies.

The task is launched right after finishing the SPESSS project. Its duration is unlimited.

G) Software management. The partners set up their own procedures for managing the evolution of the software components developed, keeping track of bugs and suggestions and the versions released.




This task is carried out independently by each partner, although fluent communication is to be kept to exploit synergies and to ensure consistency of the combined platforms.


H) Knowledge management. The partners set up their own procedures for managing the know-how acquired during the project. The scientific contents and expertise are to be kept alive and updated, in line with the inputs from the technological observatory and the suggestions from the marketing teams.

This task is carried out independently by each partner, although fluent communication should be kept to exploit synergies.


I) Marketing activities. The partners launch marketing processes targeted towards disseminating further the benefits of the project and towards setting the path for commercial exploitation. This activity is described in section 7.7 .

This task is carried out independently by each partner, although fluent communication should be kept to exploit synergies.

The task is launched right after finishing the SPESSS project. Its total length is not estimated at this stage, but will be planned at the beginning of the work.

This series of tasks needs to be coordinated together with the preparation of the Business Plan.

J) Business plan. This is the key piece of work to be undertaken within the exploitation framework. The objective is to design a strategy for commercial exploitation of the results, which can take the form of product releases, service offerings, licensing to third parties, etc. The decisions will be made taking into account the results of the market analysis (see item I), carried out at the beginning of the marketing plan, along with cost considerations, sales expectations, product and company positioning in the market, etc.

This task is carried out independently by each partner, although fluent communication is to be kept to exploit synergies. Support is sought from business advisors

The task is undertaken in coordination with the marketing process. The estimated duration is between 1 and 3 months.

K) Business support documents. The partners produce template documents to be used for agreements with external parties (confidentiality, distribution, service provision, etc.).

This task is carried out independently by each partner, although fluent communication should be kept to exploit synergies. Support is be sought from legal advisors

The task is launched after completion of the initial business plan. The estimated duration is less that 1 month.

7.7 Marketing plan The companies involved in the SPESSS project intend to exploit commercially the results of the project. The efforts invested in the execution must be turned into positive results, whether as direct commercial sales or as an improvement in industry placement.

Therefore, it is considered that a full marketing process should be carried out in order to exploit the potential of the results and to help transfer the technology out of the consortium.




This section of the document provides an outline of the steps foreseen by the partners within their marketing activities concerning the SPESSS project. It is important to emphasize that the marketing process must be carried out in coordination with the preparation of the business plan.

The following divisions and subdivisions within this section are listed according to their sequence in time, to show an ordered story of the steps to be made. There may be several iterations of a step or loops to earlier steps in the list after analysis of results or changes in the environment. Actual duration of each step cannot be foreseen at this stage.

7.7.1 Market research Market research is the process of systematic gathering, recording and analyzing of data about customers, competitors and the market. Market researches help us to create a Business Plan, to launch a new product or service, to fine tune existing products and services, to expand into new markets etc. It can be used to determine which portion of the potential customers will purchase the product/service and it can be established what market characteristics a target market has. With market research, companies can learn more about current and potential customers requirements and needs.

The purpose of the market research is to help the partners of the SPESSS consortium make better business decisions about the development and marketing of new products derived from the work done in the project. Market research represents the voice of the consumer to the companies.

A list of questions that can be answered through market research is as follows:

• What is happening in the market?

• What are the trends?

• Who are the competitors?

• How do consumers talk about the products in the market?

• Which needs are important?

• Are the needs being met by current products?

We have to carry out the analysis in two directions:

• Internal analysis, looking at the elements within the company

• External analysis, looking at the elements outside the company

This analysis will focus on two scopes or domains:

a. Macro-environment (socioeconomic, technological, political and demographic factors)

b. Micro-environment: The sector where the product will be located is quite important. We have to study the chosen sector and we have to analyze the forecast and the potential growth of the sector. In doing that we have to consider several questions:

• Is the market mature or immature?

• Is the sector concentrated or dispersed?

• Do we have factors that may influence on the current market structure?

• What are the trends?




• What is the state of the market? We have to analyze the current situation of the market, the growth average and the buying behaviours of the potentials customers.

• Clients. The market research has to determine and define our potentials clients:

o Location

o Sector, activity

o Turnover, numbers of employees

o Buying potential

• Suppliers. We have to obtain information about their prices, methods of payment, deliveries time, etc. It is important to obtain several quotes from different suppliers.

• Competitors. We have to know the type of competitors within the potential market and also their strengths and weaknesses.

o Number of competitors

o Localization

o Features of their products or services

o Length of time in the market?

o Prices

o Quality

o Distribution efficiency

o Market share

o Sales strategies

Finally, we have to elaborate a SWOT analysis, which is a strategic planning tool used to evaluate the Strengths, Weaknesses, Opportunities, and Threats. The key aspects identified under these categories are collected in a table, as the one shown in Table 12.

Opportunities:

-

-

Weaknesses:

-

-

Threats:

-

-

Strengths:

-

-

Table 12: SWOT analysis

7.7.2 Product 7.7.2.1 Product definition and attributes

To launch an actual commercial product as a result of the work done in SPESSS, we have to define our product in two different ways: conceptual and technical. The definition is actually the result of a product design process,




even if there is already a software prototype designed and implemented: the product and the prototype are not necessarily the same thing.

The definition of the project should include these attributes:

• Core: Technical aspects that make our product capable of performing the service.

• Quality: Valuation of the elements that comprise the core of our product based on standards of quality in order to stand out from competitors offerings.

• Price: It is important to know the prices of our competitors products/services. Our own price is to be set in accordance with the Business Plan.

• Packaging: The element that protects the solution and makes a first impression with customers. It includes the web site, using CD´s, boxes, manual, etc., if applicable.

• Design, shape and size: in case there are physical items included in our product (e.g. mobile terminals specifically designed), the physical aspects are those that convey the peculiar characteristics of the product and ensure that both the product and companies are easily recognised by customers.

• Brand: Names and graphic expressions that easily presents the identification of our products.

• Service: Group of valued-added services of our product that allow us to stand out from competitors.

• Product Image: Global opinion that it creates in the customer mind according to the information received (direct or indirect) about the product itself.

• Company Image: Global opinion of other products and other cases that may help in the launching process of a new product/service.

7.7.2.2 Product launch: key factors The following issues must be carefully analysed and decisions made before launch:

A) Product

Do we launch our product in certain geographic areas, abroad, etc?

Our product responds to the market necessities according to the market research?

Do we have to modify the aspects of the initial product?

Does our product have the appropriate quality?

B) Price conditions

The price assigned for the launch of our product is acceptable for the final customer and the distribution channel?

Is the final client happy with the economic conditions to use the product?

Do we have to give an incentive to our agents / channels and potential clients?

C) Distribution channel

Do we achieve successful results with the initial distribution channel or do we have to change?

Do we have to extend our product to another distribution channel?

D) Sales organization




Do we have to create a sales department to launch our product or do we have to just reorganize our current facilities?

Who are the best salesmen to assign?

Do we have to hire a task force for the launching process?

Do we have to give an incentive to our team?

E) Communication campaign

Is the potential demand responding as we expected?

Did we choose the correct communications means? Do we have to use other means?

How many promotion campaigns have to be carried out?

Do we have to use direct marketing?

7.7.3 Corporate image for dissemination The commercialisation of our product or products will need to be backed by supporting marketing materials.

In general, these materials will not necessarily be the same as the materials produced for SPESSS dissemination and hence they would need to be specially produced. In short, the correspondent activities to carry out during this marketing phase include:

• Design and production of brochures (informative and commercials, technical sheets, etc)

• Continuous maintenance of the websites (those of Next, Rigel, the SPESSS project and any potential new sites) with the new contents related to the product

• Preparation of demonstrations in different formats: turbo demo, flash, power point, etc…

• Production and release of white papers, dossiers and all kind of marketing collateral information

7.7.4 Marketing at events and fairs Part of the marketing activities described in the plan is to raise visibility of the product through participation in events. Such occasions are also useful to establish new commercial leads and prospects.

7.7.4.1 Before the events The decision of whether or not to participate in a fair or similar event must be aligned with the marketing strategy already planned.

Targets: We have to decide which fairs are the most appropriate to promote our product.

Budget: We have to assess the costs involved in the participation (space, type of stand, human resources, training, presentation, publicity means, invitations, client database, etc.) and accommodate them within our budget, according to the means we are going to use.

Data Base: Our own marketing data-base will have to be updated with the addition of new clients to boost the commercial activity.

Communication: We have to elaborate press releases in different formats and styles with different content.

7.7.4.2 During the events




There are many kinds of events, ranging in scope (regional, national, international), their length, the parallelism of congress, etc. The actual activities that can and should be carried out during the event depend heavily on the characteristics of the event. This is a list of some actions that should be addressed where possible:

• Contact current clients and strengthen customer loyalty

• Recover former clients

• Extend the data base of potential clients

• Research the market and competitors

• Establish cooperation agreements with middlemen and other means

• Create or consolidate the new brand or company image

• Communicate advances in products or services

• Present novelties or improvements

• Establish the commercial bases in short and large term

• Carry out commercial operations

• Carry out special promotions that allow us to test our product or service

• Extend the current markets to other areas or abroad

• Gather feedback from all actions for subsequent analysis

7.7.4.3 After the events After the events where the partners will participate, each company will have to analyze all the information collected. This should be done in a timeframe of about a week after conclusion of the fair.

The subsequent activities can be divided into three fields:

Marketing: Once all the information is analyzed, we have to elaborate new strategies and carry out a final balance of the fair. Then new marketing materials may need to be produced. The original marketing plan and, possibly, even the Business Plan may need to be reviewed with respect to publicity, promotions, products, data base, targets and sale forecast, market, competitors, etc.

Communication: New information will be released after the fair, normally through contacts and the press. It may be necessary to review and edit previous articles, press releases, possible agreements and cooperation etc.

Commercial: A reasonable tracking of the potential leads contacted during the event must be undertaken. The aim is to keep contacts active and to deepen relations with potential customers. An updated and well maintained data-base is very important for this task.

7.7.5 Customer management and continuous marketing Once the basic foundations for establishing commercial agreements and gaining contracts have been laid, the activities should turn their focus into the commercial work.

The marketing activities will not end up at this point, but they get farther in our marketing plan for SPESSS and we can just define approximate guidelines.

We foresee that we will carry out relational marketing activities addressed at our future customers, with some key tasks:




Data-base: Contents maintenance, organization, analysis.

Programs design and deployment: Once we have identified our potential clients (even if not customers yet), we can assess their needs and we can develop a strategy to gain their loyalty.

Feedback: After analyzing all the information, we have to stay in contact with clients and follow up each particular case to establish a long term relation with them.

We will also study the possibility of carrying out direct marketing activities as reinforcement. Direct marketing is a strategic tool with interesting benefits: It can be used as a means to improve the relationships with clients or as a means of gathering information to gain new customers and markets.




8 Analysis of major results

8.1 Main features implemented The final software system developed during the SPESSS project implements the functional requirements identified for the general tool for support of special events. In short, these features are:

• A monitoring system that knows the position of the Key-People (KP’s) distributed in the area. This logistic tool is implemented through the X-Info platform.

• A communication tool that allows sending and receiving messages from and to the KP’s over a wireless network (2.5/3G in our case) using a suitable user interface. Again, this is implemented through the X-Info platform.

• An expert system that can be taught how to organise the people in the field. The administrator must be able to set up the rules that define the behaviour, as well as set up a logical map that represents the relevant geographical areas and points of interest. This is implemented through the AI module.

• A control system that is informed about whatever happens in the area under consideration. The system should register all relevant knowledge (history) about facts that take place and use that knowledge to react, according to the decision rules that were set up, hence controlling the KP’s.

8.2 Innovative services offered The AI sub-system introduced in the SPESSS project provides a new set of advanced functions or services:

• A user defined response to a mobility event: The system is capable of generating alerts according to the KP’s positions in the map.

• A user defined response to an emergency event: The system allows setting up the response and the destination KP’s when an incident shows up in the system.

• A user defined response to a time event: The user can program alerts for each group or an individual unit. These messages can be sent everyday, at a specific time and so on.

• A user defined response to proximity alert event: The system is capable of generating alerts when two or more units with the same role are at specified cells near one another. These alerts can be configured so that no messages are sent when a high concentration of units is required (that is, the proximity is normal).

• A user defined response to an out of range event: The system detects an invalid position of a k-p unit. If it is detected an alert message is sent to the selected KP.

• A user defined response to an unavailable event: The AI module checks the status of each available unit on the map. Alert messages are sent to other units if unavailable status after a user specified time (minutes).

8.3 Comparison between results and expectations




In this sub-section we provide a brief report about the achievements of the SPESSS project, compared to the initial expectations:

8.3.1 Filling an innovation gap: intelligence This aspect of the system developed has been widely commented throughout this document. The software prototype delivered incorporates an expert system with a rule-based decision engine. The engine has two major functions:

• It knows both the present and past facts that take place: movements of the KP’s, incidents that arise, messages sent to the terminals, etc.

• It accepts the introduction of decision rules that instruct it how to behave when new events take place. Following those rules, the system can react appropriately to the circumstances.

It is true that there are plenty of expert systems implemented and deployed in the industry. It is also true that there are plenty of logistics applications in the market that monitor the position of moving units and allow communication with them. But there are few or no commercial applications or publicly announced R&D projects that addresses both functions together.

With SPESSS, we have moved a step forward in the field of GNSS applications by introducing automated intelligent response in the control systems. For now, this intelligence is not self-learned but manually configured by administrators. The fact that the intelligence (in the shape of rules of behaviour) is introduced manually does not imply that the system works manually: the important feature is that the system can work automatically once configured and handle very complex situations with a high load of simultaneous events. If a team of people was in charge of taking the decisions looking at a chart of policies, the errors could be high due to the complexity (the history of events of each and all KP’s must be considered for the decisions) and the response time could be extremely long. Using a software-based expert system, the decisions are error-free and are taken in fractions of seconds. Also, the capacity can be scaled flexibly to cope with the desired amount of simultaneous events.

An alternative to manually-configured policies would be a self-learning expert system, where the AI module would be initially trained manually by humans during a learning period, then left to evolve on its own. Initial training would basically imply a process of leaving the module to operate and telling it whether its decisions are correct or wrong. Subsequent adjustment of the policies would be done by the module itself, upon observation of the results of the decisions made. A self-learning expert module could have been a challenging option for implementation in the SPESSS project. However, given the specific field of application of the system (i.e. control of the key people that are responsible for security and assistance in the context of special events), this option does not seem advisable. The potential risks involved by such an approach are not acceptable for the purpose of managing security and emergencies in critical open events. Therefore, the manual configuration option, that delivers deterministic, totally foreseen decisions, was selected against the self-learning option, that would deliver statistical output decisions.

8.3.2 Ensuring flexibility for future improvements The partners of the SPESSS consortium are aware that this is a development project oriented towards delivering a prototype demonstrator. The key driver is to implement a proof-of-concept that would help identifying industrial benefits and commercial opportunities.

Therefore, it is important that the prototype developed is flexible enough to ensure simple and cost-efficient evolution towards an upgraded version of the system that is suitable to be exploited as a commercial product. The flexibility has been achieved in the SPESSS project thanks to a series of factors:




• Adherence to standards: The technologies used for building the prototype are all standard. This concerns to the communications field (GPRS/UMTS, IP, XML, etc.), positioning (Galileo/EGNOS) and software (Java, standard APIs, JMS, CLIPS, etc.) The use standard technology provides flexibility because future evolution or developments are not constrained to a specific commercial provider. Instead, the partners of the consortium are free to change the selection of providers for hardware (terminals, radio equipment, satellite receivers, etc.), software platforms, tools, etc., as long as the comply to international standards. Choosing proprietary technologies may have endangered future evolution of the system.

• Modularity: The architecture of the prototype follows a hierarchical approach where the full system is actually made up of two major sub-systems, completely separated and independent but interconnected. Then, each sub-system is divided in turn into a series of structural modules (see the “Detailed System Design”, ref. D04). Further on, the structural modules are built with functional Java classes that implement different operations. As a consequence, the system can evolve flexibly by changing or substituting specific modules, without affecting the remaining ones.

• Scalability: The design of the system is not based on capacity requirements. The system has not been developed to cope with a certain amount of load (number of KP’s, time between events, message size, etc.) but rather as a general functioning tool. The architecture and the technologies used were selected precisely to make sure that the system could be adapted to work in different scenarios. Normally, enlarging the capacity of an actual deployment would imply adding hardware and resources. The resulting implementation may not be the most efficient. However, we have the flexibility to grow or to adapt to fewer resources.

8.3.3 Building on ready-made developments The partners have tackled their development tasks by making the most of their existing platforms and know-how. To be more specific:

• The X-Info platform is info-mobility platform, which thanks the capability to establish data communications to and from the mobile user terminals (MUT) equipped with GNS receivers that are EGNOS ready, which were used to exchange complex messages between the terminals and a control server and also among the terminals.

• The X-Info platform was equipped with mapping capabilities for representing the UT in vectoral as well as raster maps. Suitable diagrams of parts of the maps could also be sent to the MUT’s as required. This capability is also used now in the SPESSS system to build rich messages that are sent to the KP’s. For example, when the AI module decides to send a message to a specific KP or a set of them (e.g. all policemen) including a pair of geographical coordinates, the X-Info platform can represent on the map the position of the destination KP plus a mark at the position specified by the AI module.

Next have experience in using the JMS Java API to interconnect separate functional modules. This was actually a major mechanism used in their original info-mobility platform. The technology was suggested as a desired option for SPESSS and, to reduce risks, the actual JMS queue manager of SPESSS was deployed and configured by Next at their premises in Rome.

Rigel had an original implementation of an expert system that implements artificial intelligence using a rule-based decision engine. This implementation was an integral part of separate product called Movípolis, designed to offer automated tourist guidance through mobile terminals in urban areas (such as historical city centers). The core of the system was based on an adaptation of the jCLIPS engine to be run within a communication infrastructure, where the events were directly associated to data messages received from remote computing nodes.




In Movípolis, as well as in SPESSS, the mobile user terminals do not exchange messages directly with the expert system. Instead, there are intermediate nodes (“gateways” in Movípolis, the SCC in SPESSS) that monitor the events that take place (people movements, content message requests, etc.) and inform the expert system accordingly. In Movípolis, these information messages are exchanged using a proprietary protocol designed by Rigel. The protocol runs through TCP connections over IP and the data is sent using a proprietary format of messages. Therefore, Rigel had to adapt the modules that transform the messages into logical statements understood by CLIPS, from a proprietary implementation to a standard mechanism based on XML messages and JMS interface.

The Movípolis platform by Rigel includes a web-based GUI that is used by administrators (normally tourist guides and experts) to set up guiding rules and content messages. In SPESSS, there is no need to set up the contents, because they are controlled by the info-mobility sub-system. But the underlying modules of the configuration GUI are very useful for implementation of the SPESSS administration interface.

However, the administration interface of SPESSS is significantly more complex than that of Movípolis. In the latter, there are only two types of rules: based on position events and based on time. In SPESSS, there is a wider variety of rules with quite different triggers (see section 8.2 ). The web interface, built using Java servlets, was developed for SPESSS almost from scratch, just making use of the very core functional modules when possible.

The facts that are registered and controlled by the SPESSS expert system are slightly different from those controlled in Movípolis, but they are quite similar in essence. In SPESSS, we must take care of the users’ positions in time (in terms of location areas visited), their roles, the messages exchanged. In Movípolis, the facts that are recorded include the users’ positions in time (in terms of detection hot-spots), the messages sent, the messages requested.




9 Recommendations for evolution of SPESSS

9.1 Strategy approach The technical objectives set for the SPESSS project have been achieved. The results of the project are satisfactory to the partners of the consortium. Therefore, the partners do not set up recommendations oriented towards correcting the results or fixing errors. Any recommendations of further tasks to be tackled following the SPESSS project are hence aimed at enhancing its features or improving its industrial approach.

Since both partners of the consortium are private companies, their interest is to gain a commercial advantage by appropriate exploitation of the results of the project. This exploitation can be manifold (see “Technology Transfer Plan”). One potential line of business is obviously to license the software platform as a commercial product. However, the current state of the system is not suitable for that purpose, even if the technical objectives were met.

Some recommendations can be made in order to help positioning the system as a commercial product:

9.1.1 Management interface This is perhaps the most relevant aspect that our prototype lacks from an industrial point of view. Our system is a full functional software platform that implements the necessary technical requirements but is not practical, in an operational way.

For example, the current development consists of an assembly of separate modules (mainly the X-Info platform and the AI sub-system), each of them having its own managing interface. A potential third-party administrator would have to log on to each of the GUIs to set up configurations and to monitor the behavior of the system. This person would need to be trained to use both interfaces and it would be mandatory to keep overall consistency between configurations. A future commercial product would have a single managing interface, ideally web-based, that will offer a centralized control board to administrators. Using such interface the administrators would be able to configure the operation of the system without possibility of inconsistencies and without duplication of work or inputs.

The procedures for managing the system through the interface should be made more structured and simpler. This applies to the provisioning of new users and Key-People, setting up logical geographical areas within the actual GIS maps, configuring decision rules in a graphical manner, etc.

9.1.2 Registry and monitoring The fields and subjects of application of our system are quite sensitive, since they would involve the management of critical operations carried out by key people: coping with emergencies, organizing movements of people, raising alarms, coordinating patrols, etc. Therefore, it is not only important but also necessary to make sure that every operation handled by the system is registered suitably. In other words, there must be a mechanism for auditing the operation of the system. This involves not only logging automatically all events and messages that are sent and received and keeping them securely, but also presenting auditing tools that can help administrators to track the history of events of each particular incident, with all relevant details: people involved, time stamps of events, time delays, reactions, errors, specific messages, etc.

The monitoring features of the system should also be extended to offering graphical tools to the administrators. The integration of the processes of the sub-systems with a detailed GIS, covering the geographical area of interest, would allow the administrators to have a visual overview of the current status of the operations. We




currently have the possibility to display graphically the position of KP’s, but it could be extended to display graphically the distribution of incidents, the assignment of tasks and directions to KP’s, the configuration and state of logical areas in the map, etc.

9.1.3 Robustness As it was stated above in this document, the current SPESSS system was designed and developed with no specific capacity requirements or system constraints. The development was focused on checking technical feasibility and ensuring technical innovation.

Therefore, we came up with a suite of software modules that integrate together to yield the required functionality. But this software platform is not a packaged product that can be deployed at a potential customer’s premises and satisfy fully its specific requirements.

A recommendation for evolution of the project is to package all system components into a simpler software platform and to design and develop an installation tool. The tool would help deploying the system at the required infrastructure, according to the context (redundant hardware, data connections, database availability, underlying technologies, etc.) and allowing structural configuration of the system.

The capacity and reliability features of the resulting installed system would depend heavily on the supporting infrastructure, but we would have a robust software product and installation tool that would help make the most of the modules developed.

9.2 Implementation of optional requirements The “Requirements Analysis” phase, fully documented in the official deliverable document D02, presents a list of functional requirements to be implemented in the SPESSS project classified into three levels of priority: Must, Should and Nice-to-have.

The actual development carried out during the project has satisfied all compulsory requirements (those labeled as “Must”) and some of the optional requirements (those labeled as “Should” and “Nice-to-have”).

Within the optional requirements considered, there are some functional features that have not been implemented in the framework of the SPESSS project but could help improve the commercial prospects of the system, even if they are not necessary to verify the technical advantages. Therefore, one of the basic lines of evolution that the partners of the consortium would address is selecting those optional features that would be useful from the commercial point of view. The corresponding requirements would be planned in a development roadmap, along with a plan of delivery of subsequent versions of the system.

The selection and planning of next features will be carried out in accordance to the market analysis results, as described in the previous chapter.

9.3 Enhancements to the X-Info sub-system Many enhancements can be introduced in the SPESSS prototypes to develop it. The most relevant are listed:

• Integration with other systems: the full implementation of the SPESSS system can be achieved with the integration of the proposed system with external systems that can provide all the relevant information that the SPESSS application may need to support the correct decision or that can take advantage from the information provided by the SPESSS system. Such external system can be: Emergency system, traffic data system, city mobility systems, weather information system




• Security: security mechanisms both in terms of data protection and intrinsic system characteristics. In the current implementation, the data transferred over the radio access interface is protected thanks to the security mechanisms already implemented within the GPRS/UMTS protocols. However, no encryption or strong authentication procedures have been implemented over the fixed-line communication interfaces of the system. A future version of SPESSS would benefit from the addition of security and authentication algorithms in all data communication channels.

9.4 Enhancements to the AI sub-system The AI module of the SPESSS project could be enhanced in several ways. Here we introduce some examples:

• Adding parameters to the context. The current implementation of the expert system supported by CLIPS registers and handles historical information mainly about the logical areas visited by the KP’s and the messages sent to or received from them. This was identified during the design phase of the project as being enough to achieve the goals of the artificial intelligence. However, once we start discussing real-world deployments with potential customers we will probably face the problem of having more parameters being considered to take decisions. In that case, it would be necessary to enlarge the number and types of parameters registered by the expert system, so that the administrator can implement more powerful decision rules that take into account new circumstances about the KP’s and the environment.

• Adding pre-processing services. The current implementation already has some “pre-processing” services included in the AI module. These services perform calculations before relaying events to the actual rule-based expert core. One example is the preparation of proximity alerts: There is no message being sent from the X-Info platform informing about the proximity of two KP’s. Instead, a processing service that is continuously running in the sub-system checks all changes of position of KP’s and, when two of them with the same role get close, a new internal event is generated and relayed to the CLIPS core. Similar services can easily be added to the current implementation in order to enhance the functional capabilities offered by the AI sub-system.

• Adding post-processing services. In a similar way as stated above, the AI sub-system can be enhanced by adding software modules that carry out operations and calculations based on the outputs of the expert core. In other words, these components behave as alternative destinations of the decisions made by the expert core. An example is the component used to organize a uniform distribution of KP’s in a given area when the CLIPS core decides that a balance of units must be carried out (such a function is currently implemented as a module that can be invoked after the processing of a proximity alert event). The rule-based core works according to logical areas not coordinates. It is the post-processing components that are in charge of understanding the orders placed by the core and making numerical calculations. After this second step of processing, the appropriate messages are generated and sent to the X-Info sub-system for its subsequent relay to the destination KP’s.

• Integrating configuration messages in the interface between X-Info and the AI. In the current implementation, the two separate sub-systems of the SPESSS platform work independently and exchange messages that are essential to the operation of each side: mainly related to the events taking place in the area under control (movements of KP’s), incidents and messages relayed to and from KP’s. That is, they are all operational messages. This implies that each sub-system must be configured and managed separately. It would be better to introduce administration messages in the protocol between the two sub-systems in order to enable synchronization of administration activities at both sides.




End of Document

SPESSS - SPecial Event Support by Satellite System Final Review ...

Documents

Transcript of SPESSS - SPecial Event Support by Satellite System Final Review ...