D2.3 Conceptual Design of the C2-SENSE Architecture

D2.3 Conceptual Design of the C2-SENSE Architecture

Due Date: December 26, 2014

Actual Submission Date: December 24, 2014

Lead Beneficiary in charge of the Deliverable: SRDC

Revision: V2.0

Grant Agreement: 607729

Project Acronym: C2-SENSE

Project Title: Interoperability Profiles for Command/Control Systems and

Sensor Systems in Emergency Management

Funding Scheme: SEC-2013.5.3-1

Project Start Date:

Duration:

April 01, 2014

36 months

Project co-funded by the European Commission within the Seventh Framework Programme (2007-2013)

Dissemination Level

PU Public X

PP Restricted to other programme participants (including the Commission Services)

RE Restricted to a group specified by the consortium (including the Commission Services)

CO Confidential, only for members of the consortium (including the Commission Services)

D2.3 Conceptual Design of the C2-SENSE Architecture – /176

Document History:

Version Date Changes From Review

V0.1 04.08.2014 Initial Document Mert Gençtürk (SRDC) All

V0.2 17.09.2014 SRDC Input for Architectural Design Mert Gençtürk (SRDC) All

V0.3 29.09.2014 AIT Input for Architectural Design Refiz Duro (AIT) All

V0.4 06.10.2014

LUTECH Input for Architectural

Design

Alberto Pasotti

(LUTECH)

All

V0.5 06.10.2014

SAGEM Input for Architectural

Design

Romuald Perinelle

(SAGEM)

All

V0.6 08.10.2014 Inputs are consolidated Mert Gençtürk (SRDC) All

V0.7 13.10.2014 Reviewed by SRDC Mert Gençtürk (SRDC) Mert Gençtürk (SRDC)

V0.8 26.10.2014 PIAP Input Jan Piwinski (PIAP) All

V0.9 27.10.2014 Updates are applied Mert Gençtürk (SRDC) All

V0.10 25.09.2014 SRDC Input for Use Case Design Mert Gençtürk (SRDC) All

V0.11 21.10.2014 AIT Input for Use Case Design Refiz Duro (AIT) All

V0.12 21.10.2014 LUTECH Input for Use Case Design

Matteo Redaelli,

Roberto Maglieri

(LUTECH)

All

V0.13 26.10.2014 PIAP Input for Use Case Design Jan Piwinski (PIAP) All

V0.14 29.10.2014 SAGEM Input for Use Case Design

Romuald Perinelle

(SAGEM)

All


V0.16 21.11.2014 Consortium review Mert Gençtürk (SRDC)

Mert Gençtürk, Gökçe

Banu Laleci Ertürkmen

(SRDC), Refiz Duro,

Gerald Schimak (AIT),

Romuald Perinelle

(SAGEM)

V0.17 27.11.2014 PIAP Input is updated Jan Piwinski (PIAP) All

V1.0 28.11.2014 Final version, ready for submission Mert Gençtürk (SRDC) Gökçe Banu Laleci

Ertürkmen (SRDC)

V1.1 02.12.2014 SRDC Input for Class Design Mert Gençtürk (SRDC) All


V1.2 08.12.2014 SAGEM Input for Class Design Romuald Perinelle

(SAGEM) All

V1.3 10.12.2014 LUTECH Input for Class Design Alberto Pasotti

(LUTECH) All

V1.4 10.12.2014 AIT Input for Class Design Refiz Duro (AIT) All

V1.5 12.12.2014 PIAP Input for Class Design Jan Piwinski (PIAP) All


V1.7 22.12.2014 LUTECH Input is updated Alberto Pasotti, Matteo

Redaelli (LUTECH) All

V1.8 23.12.2014 Consortium review Mert Gençtürk (SRDC)

Mert Gençtürk, Gökçe

Banu Laleci Ertürkmen

(SRDC), Refiz Duro

(AIT), Romuald Perinelle

(SAGEM)

V2.0 24.12.2014 Final version, ready for submission Mert Gençtürk (SRDC) Gökçe Banu Laleci

Ertürkmen (SRDC)

Contributors:

Responsible Author Mert Gençtürk Email [email protected]

Beneficiary SRDC Phone +90 312 210 1763

mailto:[email protected]


Quality Control

Role Name Date

Security Scrutiny Committee Review

Comments

Recommended Distribution

Date


EXECUTIVE SUMMARY

In the course of the conceptual design task of the C2-SENSE project, Rational Unified Process (RUP)

will be applied. The RUP is a Software Engineering Process. It provides a disciplined approach to

assigning tasks and responsibilities within a development organization. Its goal is to ensure the

production of high-quality software that meets the needs of its end-users, within a predictable

schedule and budget. RUP enhances team productivity by providing every team member with easy

access to a knowledge base with guidelines, templates and tool mentors.

The Rational Unified Process is composed of Business Modelling Workflow, Requirements

Workflow, Analysis & Design Workflow, Implementation Workflow, Test Workflow, Project

Management Workflow, Configuration and Change Management Workflow and Environment

Workflow.

In Task 2.3 “Gathering User and Technical Requirements of C2-SENSE Architecture” and Task 7.1

“Requirements of C2-SENSE Pilot Application”, speaking in terms of RUP terms, Business

Modelling Workflow and Requirements Workflow have already been performed. In the conceptual

design task of the C2-SENSE Project, the Analysis & Design Workflow is applied. As Environment

Workflow of RUP also suggests, the Analysis & Design Workflow is adapted and tailored according to

the needs of the C2-SENSE Project. The following steps are performed throughout the conceptual

design task of the project: Use-Case Analysis, Architectural Design, Use-Case Design, and Class

Design.

These four steps are processed step by step. The output of first step which is Use-Case Analysis phase

is an input for this document and is presented as an annex of this deliverable. In this step, for each use

model, analysis classes are identified and their responsibilities are defined.

In the first version of “D2.3 Conceptual Design of the C2-SENSE Architecture”, Architectural Design

and Use-Case Design are processed respectively. In Architectural Design phase, identified analysis

classes are categorized as design classes or subsystems. In Use-Case Design phase, use case

realizations are refined in terms of interactions so that for each use case, one or more sequence

diagrams are created to illustrate the interactions between design objects.

In the second version of “D2.3 Conceptual Design of the C2-SENSE Architecture”, Class Design is

processed. In this last step, additional classes are added, some classes are eliminated, and operation

visibility, scope, attributes, dependencies, associations and generalizations are defined by taking into

account the implementation and deployment environment.


TABLE OF CONTENTS

Executive Summary ................................................................................................................................ 5 Table of contents ..................................................................................................................................... 6 Table of FIGURES ............................................................................................................................... 10 1 INTRODUCTION ........................................................................................................................ 15

1.1 Purpose .................................................................................................................................. 15 1.2 Scope ..................................................................................................................................... 15

1.2.1 Introduction to C2-SENSE ............................................................................................ 15 1.2.2 Scope of this Deliverable .............................................................................................. 18

1.3 Definitions, Abbreviations and Acronyms ............................................................................ 19 2 REFERENCES ............................................................................................................................. 21 3 DECOMPOSITION DESCRIPTION .......................................................................................... 21

3.1 Emergency Ontology Creator Tool ....................................................................................... 23 3.1.1 Content Model Importer Subsystem ............................................................................. 24 3.1.2 Ontology Resource Editor Subsystem .......................................................................... 25 3.1.3 Ontology Editor Subsystem .......................................................................................... 25

3.2 Mapping Generator Tool ....................................................................................................... 26 3.2.1 Mapping Generator Subsystem ..................................................................................... 28 3.2.2 Converter Engine Subsystem ........................................................................................ 29

3.3 Profile Monitoring Tool ........................................................................................................ 30 3.3.1 Profile Monitoring Subsystem ...................................................................................... 31

3.4 Profile Definition and Specialization Tool ........................................................................... 32 3.4.1 Profile Definition Subsystem ........................................................................................ 34 3.4.2 Profile Specialization Subsystem .................................................................................. 35

3.5 Security and Privacy Tool ..................................................................................................... 36 3.5.1 Authorization Manager Subsystem ............................................................................... 37 3.5.2 Encryption Manager Subsystem ................................................................................... 38 3.5.3 Authentication Mechanism Subsystem ......................................................................... 39

3.6 Conformance and Interoperability Testing Mechanism ........................................................ 39 3.6.1 Test Execution Monitoring Subsystem ......................................................................... 41 3.6.2 Test Execution Subsystem ............................................................................................ 42 3.6.3 Test Scenario Creator Subsystem ................................................................................. 43

3.7 Enterprise Service Bus .......................................................................................................... 44 3.7.1 Rule Subsystem ............................................................................................................. 45 3.7.2 Service Subsystem ........................................................................................................ 45 3.7.3 Network Monitoring Tool Subsystem ........................................................................... 45

3.8 Message Communication Platform ....................................................................................... 46 3.8.1 User And Role Creator Subsystem ............................................................................... 47 3.8.2 User From Topic Deleter Subsystem ............................................................................ 48 3.8.3 Topic Unsubscriber Subsystem ..................................................................................... 48 3.8.4 Communication Handler Subsystem ............................................................................. 48

3.9 Data Integrators ..................................................................................................................... 48 3.9.1 Message System Subsystem .......................................................................................... 50 3.9.2 Message Sender Subsystem .......................................................................................... 50

3.10 Profile Execution Engine ...................................................................................................... 51 3.10.1 Emergency Profiler Subsystem ..................................................................................... 52 3.10.2 Process Subsystem ........................................................................................................ 52

3.11 Web Service Creator Tool..................................................................................................... 53 3.11.1 Web Service Subsystem ................................................................................................ 53 3.11.2 Web Service Creator Subsystem ................................................................................... 55

3.12 Emergency Maps Tool .......................................................................................................... 56 3.12.1 Emergency Maps Importer Subsystem ......................................................................... 58 3.12.2 Knowledge Layer Subsystem ........................................................................................ 59


3.12.3 MashUp Tool Subsystem .............................................................................................. 59 3.12.4 Emergency Situation User Actions Subsystem ............................................................. 59

3.13 GIS Server ............................................................................................................................. 59 3.13.1 GIS Server Subsystem .................................................................................................. 61 3.13.2 Semantic Information Subsystem ................................................................................. 62 3.13.3 Geo Servers Subsystem ................................................................................................. 62 3.13.4 Maps Server Subsystem ................................................................................................ 62

3.14 Sensor Protocol Adapter Tool ............................................................................................... 63 3.14.1 Sensor Management Tool Subsystem ........................................................................... 64 3.14.2 PlugNplay Subsystem ................................................................................................... 65 3.14.3 AnySen Tool Subsystem ............................................................................................... 65

3.15 Collaboration Environment ................................................................................................... 65 3.16 C2-SENSE Gateway ............................................................................................................. 66

3.16.1 Physical Interface Connector Subsystem ...................................................................... 67 3.16.2 Enterprise Service Bus Subsystem ................................................................................ 67

4 DETAILED DESCRIPTION ....................................................................................................... 68 4.1 Detailed Interaction Diagrams .............................................................................................. 68

4.1.1 Emergency Ontology Creator Tool Interaction Diagrams ............................................ 68 4.1.1.1 Use Case: UC-EOCT-1 Import a Local Content Model ......................................................................... 68 4.1.1.2 Use Case: UC-EOCT-2 Search Ontology Resource ............................................................................... 68 4.1.1.3 Use Case: UC-EOCT-3 Browse/View Ontology Resource .................................................................... 69 4.1.1.4 Use Case: UC-EOCT-4 Export C2-SENSE Harmonized Ontology ....................................................... 69

4.1.2 Mapping Generator Tool Interaction Diagrams ............................................................ 70 4.1.2.1 Use Case: UC-MGT-1 Map Local Domain Ontology to C2-SENSE Harmonized Ontology ................ 70 4.1.2.2 Use Case: UC-MGT-2 Convert Local Content Model to Another ......................................................... 70

4.1.3 Profile Monitoring Tool Interaction Diagrams ............................................................. 71 4.1.3.1 Use Case: UC-PMT-1 Trace the Execution of a Specific Profile ........................................................... 71 4.1.3.2 Use Case: UC-PMT-2 Display Completed Tasks .................................................................................. 72 4.1.3.3 Use Case: UC-PMT-3 Display Currently Running Tasks ...................................................................... 72 4.1.3.4 Use Case: UC-PMT-4 Display Bottlenecks ........................................................................................... 72 4.1.3.5 Use Case: UC-PMT-5 Display Incomplete Tasks .................................................................................. 72 4.1.3.6 Use Case: UC-PMT-6 Display Pending Tasks ....................................................................................... 72

4.1.4 Profile Definition and Specialization Tool Interaction Diagrams ................................. 73 4.1.4.1 Use Case: UC-PDST-1 Define Actors of a Profile................................................................................. 73 4.1.4.2 Use Case: UC-PDST-2 Define Messages of a Profile ............................................................................ 73 4.1.4.3 Use Case: UC-PDST-3 Define Transactions of a Profile ....................................................................... 73 4.1.4.4 Use Case: UC-PDST-4 Specialize Generic Profile to a Specific Case ................................................... 74

4.1.5 Security and Privacy Tool Interaction Diagrams .......................................................... 74 4.1.5.1 Use Case: UC-SPT-1 Authorization ...................................................................................................... 74 4.1.5.2 Use Case: UC-SPT-2 Integrity ............................................................................................................... 75 4.1.5.3 Use Case: UC-SPT-3 Usage of Certificates ........................................................................................... 76 4.1.5.4 Use Case: UC-SPT-4 Authentication ..................................................................................................... 76

4.1.6 Conformance and Interoperability Testing Mechanism Interaction Diagrams ............. 77 4.1.6.1 Use Case: UC-CITM-1 Provide Web Based Graphical Environment .................................................... 77 4.1.6.2 Use Case: UC-CITM-2 Provide Emergency Test Scenario ................................................................... 77 4.1.6.3 Use Case: UC-CITM-3 Simulate Missing Roles in the Scenario ........................................................... 78 4.1.6.4 Use Case: UC-CITM-4 Execute Test Scenario ...................................................................................... 78 4.1.6.5 Use Case: UC-CITM-5 Display Detailed Log Information ................................................................... 78 4.1.6.6 Use Case: UC-CITM-6 Display Error Location ..................................................................................... 78 4.1.6.7 Use Case: UC-CITM-7 Automate Whole Testing Process .................................................................... 78 4.1.6.8 Use Case: UC-CITM-8 Capture Messages Exchanged Between Parties ............................................... 79 4.1.6.9 Use Case: UC-CITM-9 Verify Emergency Messages and Document Semantically .............................. 79 4.1.6.10 Use Case: UC-CITM-10 Validate Emergency Messages and Documents Syntactically ....................... 79

4.1.7 Enterprise Service Bus Interaction Diagrams ............................................................... 79 4.1.7.1 Use Case: UC-ESB-1 Add New Rule .................................................................................................... 79 4.1.7.2 Use Case: UC-ESB-2 Modify ESB Rule ............................................................................................... 79 4.1.7.3 Use Case: UC-ESB-3 Delete ESB Rules ............................................................................................... 80 4.1.7.4 Use Case: UC-ESB-4 Monitor Network Traffic & UC-ESB-5 View System Logs ............................... 80 4.1.7.5 Use Case: UC-ESB-6 Register New Service on ESB ............................................................................ 81 4.1.7.6 Use Case: UC-ESB-7 View Registered Service ..................................................................................... 81 4.1.7.7 Use Case: UC-ESB-8 Delete Registered Service ................................................................................... 81 4.1.7.8 Use Case: UC-ESB-9 Send Message ..................................................................................................... 82


4.1.7.9 Use Case: UC-ESB-10 Receive Message .............................................................................................. 82 4.1.8 Message Communication Platform Interaction Diagrams ............................................ 83

4.1.8.1 Use Cases: UC-MCP-1 Add User to Topic & UC-MCP-2 Create Role & UC-MCP-3 Assign Role ..... 83 4.1.8.2 Use Case: UC-MCP-4 Deleting User from Topic .................................................................................. 83 4.1.8.3 Use Case: UC-MCP-5 Un-subscription from Topic ............................................................................... 84 4.1.8.4 Use Case: UC-MCP-6 Send Message .................................................................................................... 84 4.1.8.5 Use Case: UC-MCP-7 Receive Message ............................................................................................... 84

4.1.9 Data Integrators Interaction Diagrams .......................................................................... 85 4.1.9.1 Use Case: UC-DI-1 Receiving Events & UC-DI-2 Validating Format & UC-DI-3 Converting Data

Format 85 4.1.9.2 Use Case: UC-DI-4 Forwarding Formatted Data to the ESB ................................................................. 85

4.1.10 Profile Execution Engine Interaction Diagrams ........................................................... 86 4.1.10.1 Use Case: UC-PEE-1 Import Emergency Profile ................................................................................... 86 4.1.10.2 Use Case: UC-PEE-2 Delete Emergency Profile ................................................................................... 86 4.1.10.3 Use Case: UC-PEE-3 Start Process ........................................................................................................ 87

4.1.11 Web Service Creator Tool Interaction Diagrams .......................................................... 88 4.1.11.1 Use Case: UC-WSCT-1 Create a Service for a Given Legacy System .................................................. 88 4.1.11.2 Use Case: UC-WSCT-2 Install the WSC Tool ....................................................................................... 88 4.1.11.3 Use Case: UC-WSCT-3 Start the WSC Tool ......................................................................................... 89 4.1.11.4 Use Case: UC-WSCT-4 Log into the Tool ............................................................................................ 89 4.1.11.5 Use Case: UC-WSCT-5 Upgrade the Interface of a Legacy System ...................................................... 90 4.1.11.6 Use Case: UC-WSCT-6 Upgrade the Profiles........................................................................................ 91

4.1.12 Emergency Maps Creator Tool Interaction Diagrams .................................................. 91 4.1.12.1 Use Case: UC-EM-1 Provide a Common Operational Picture of the Crisis Situation ........................... 91 4.1.12.2 Use Case: UC-EM-2 Support Decision Making Process ....................................................................... 91 4.1.12.3 Use Case: UC-EM-3 Display Emergency Area to User ......................................................................... 92 4.1.12.4 Use Case: UC-EM-4 Show Maps and Situation Information ................................................................. 93 4.1.12.5 Use Case: UC-EM-5 Track the Emergency Situation User Actions ...................................................... 93 4.1.12.6 Use Case: UC-EM-6 Analyze the Emergency Situation User Actions .................................................. 94

4.1.13 GIS Server Interaction Diagrams .................................................................................. 95 4.1.13.1 Use Case: UC-GS-1 Share and Edit Geospatial Data ............................................................................. 95 4.1.13.2 Use Case: UC-GS-2 Extract Spatial Information from Semantic Information Interoperability Layer ... 96 4.1.13.3 Use Case: UC-GS-3 Deliver Geo-Referenced Information from Different Sources .............................. 97 4.1.13.4 Use Case: UC-GS-4 Provide Background Maps for the Geo-Referenced Presentation of Relevant Data

97 4.1.14 Sensor Protocol Adapter Tool Interaction Diagrams .................................................... 98

4.1.14.1 Use Case: UC-SP-1 Sensor Management for Many Sensors ................................................................. 98 4.1.14.2 Use Case: UC-SP-2 Plug and Measure .................................................................................................. 99 4.1.14.3 Use Case: UC-SP-3 Gather Real-Time Data .......................................................................................... 99 4.1.14.4 Use Case: UC-SP-4 User Management of Sensors and Input .............................................................. 100

4.1.15 Collaboration Tool Interaction Diagrams ................................................................... 101 4.1.15.1 Use Case: UC-CE-1 Combination of Maps with Content Information from Different (Information)

Sources 101 4.1.15.2 Use Case: UC-CE-2 Visualize Crisis Situation .................................................................................... 101 4.1.15.3 Use Case: UC-CE-3 Provide Information for Decision Making Process ............................................. 101 4.1.15.4 Use Case: UC-CE-4 Provide Map Data and Content Information for Emergency Maps Tool ............ 101 4.1.15.5 Use Case: UC-CE-5 Gather User Input to Track the Changes of Crisis Situation ............................... 101

4.1.16 C2-SENSE Gateway Interaction Diagrams ................................................................ 101 4.1.16.1 Use Case: UC-C2SG-1 Connect Data from External System/Data Source & UC-C2SG-2 Send Data in

Unified Form to Enterprise Service Bus .................................................................................................................. 101 4.2 Design Class Diagrams ....................................................................................................... 102

4.2.1 Emergency Ontology Creator Tool Class Diagrams ................................................... 102 4.2.2 Mapping Generator Tool Class Diagrams................................................................... 106 4.2.3 Profile Monitoring Tool Design Classes ..................................................................... 108 4.2.4 Profile Definition and Specialization Tool Design Classes ........................................ 109 4.2.5 Security and Privacy Tool Design Classes.................................................................. 112 4.2.6 Conformance and Interoperability Testing Mechanism Design Classes .................... 115 4.2.7 Enterprise Service Bus Design Classes ....................................................................... 118 4.2.8 Message Communication Platform Design Classes .................................................... 120 4.2.9 Data Integrators Design Classes.................................................................................. 122 4.2.10 Profile Execution Engine Design Classes ................................................................... 124 4.2.11 Web Service Creator Tool Design Classes ................................................................. 126


4.2.12 Emergency Maps Tool Design Classes ....................................................................... 130 4.2.13 GIS Server Design Classes ......................................................................................... 134 4.2.14 Sensor Protocol Adapter Tool Design Classes ............................................................ 138 4.2.15 Collaboration Environment Design Classes................................................................ 140 4.2.16 C2-SENSE Gateway Design Classes .......................................................................... 140

4.3 Detailed State Charts ........................................................................................................... 142 4.3.1 Emergency Ontology Creator Tool State Charts ........................................................ 142 4.3.2 Mapping Generator Tool State Charts ........................................................................ 144 4.3.3 Profile Monitoring Tool State Charts .......................................................................... 145 4.3.4 Profile Definition and Specialization Tool State Charts ............................................. 146 4.3.5 Security and Privacy Tool State Charts ...................................................................... 148 4.3.6 Conformance and Interoperability Testing Mechanism State Charts ......................... 150 4.3.7 Enterprise Service Bus State Charts ............................................................................ 151 4.3.8 Message Communication Platform State Charts ......................................................... 152 4.3.9 Data Integrators State Charts ...................................................................................... 154 4.3.10 Profile Execution Engine State Charts ........................................................................ 155 4.3.11 Web Service Creator Tool State Charts ...................................................................... 156 4.3.12 Emergency Maps Tool State Charts ............................................................................ 158 4.3.13 GIS Server State Charts .............................................................................................. 159 4.3.14 Sensor Protocol Adapter Tool State Charts ................................................................ 160 4.3.15 Collaboration Environment State Charts .................................................................... 161 4.3.16 C2-SENSE Gateway State Charts ............................................................................... 161

4.4 Detailed Class Diagrams and Associations ......................................................................... 162 4.4.1 Emergency Ontology Creator Tool ............................................................................. 162 4.4.2 Mapping Generator Tool ............................................................................................. 163 4.4.3 Profile Monitoring Tool .............................................................................................. 164 4.4.4 Profile Definition and Specialization Tool ................................................................. 165 4.4.5 Security and Privacy Tool ........................................................................................... 166 4.4.6 Conformance and Interoperability Testing Mechanism .............................................. 167 4.4.7 Enterprise Service Bus ................................................................................................ 168 4.4.8 Message Communication Platform ............................................................................. 169 4.4.9 Data Integrators ........................................................................................................... 170 4.4.10 Profile Execution Engine ............................................................................................ 171 4.4.11 Web Service Creator Tool ........................................................................................... 172 4.4.12 Emergency Maps Tool ................................................................................................ 173 4.4.13 GIS Server ................................................................................................................... 174 4.4.14 Sensor Protocol Adapter Tool ..................................................................................... 175 4.4.15 Collaboration Environment ......................................................................................... 175 4.4.16 C2-SENSE Gateway ................................................................................................... 176

5 CONCLUSION .......................................................................................................................... 176


TABLE OF FIGURES

Figure 1: Interoperability Stack of the C2-SENSE Project ................................................................... 16 Figure 2: C2-SENSE Framework ......................................................................................................... 17 Figure 3: Collaboration of Components in C2-SENSE System ............................................................ 22 Figure 4: Collaboration of Components with SPT and ESB ................................................................. 23 Figure 5: Emergency Ontology Creator Tool Subsystems ................................................................... 23 Figure 6: Subsystems and Packages identified for Emergency Ontology Creator Tool ....................... 24 Figure 7: Component Diagram of Content Model Importer Subsystem ............................................... 25 Figure 8: Component Diagram of Ontology Resource Editor Subsystem ............................................ 25 Figure 9: Component Diagram of Ontology Editor Subsystem ............................................................ 26 Figure 10: Mapping Generator Tool Subsystems ................................................................................. 27 Figure 11: Subsystems and Packages identified for Mapping Generator Tool ..................................... 28 Figure 12: Component Diagram of Mapping Generator Subsystem..................................................... 29 Figure 13: Component Diagram of Converter Engine Subsystem ........................................................ 29 Figure 14: Profile Monitoring Tool Subsystems ................................................................................... 30 Figure 15: Subsystems and Packages identified for Profile Monitoring Tool ...................................... 31 Figure 16: Component Diagram of Profile Monitoring Subsystem ...................................................... 32 Figure 17: Profile Definition and Specialization Tool Subsystems ...................................................... 33 Figure 18: Subsystems and Packages identified for Profile Definition and Specialization Tool .......... 34 Figure 19: Component Diagram of Profile Definition Subsystem ........................................................ 35 Figure 20: Component Diagram of Profile Specialization Subsystem ................................................. 35 Figure 21: Security and Privacy Tool Subsystems ............................................................................... 36 Figure 22: Subsystems and Packages identified for Security and Privacy Tool ................................... 37 Figure 23: Component Diagram of Authorization Manager Subsystem............................................... 38 Figure 24: Component Diagram of Encryption Manager Subsystem ................................................... 38 Figure 25: Component Diagram of Authentication Mechanism Subsystem ......................................... 39 Figure 26: Conformance and Interoperability Testing Mechanism Subsystems .................................. 40 Figure 27: Subsystems and Packages identified for Conformance and Interoperability Testing

Mechanism ............................................................................................................................................ 41 Figure 28: Component Diagram of Test Execution Monitoring Subsystem ......................................... 42 Figure 29: Component Diagram of Test Execution Subsystem ............................................................ 43 Figure 30: Component Diagram of Test Scenario Creator Subsystem ................................................. 43 Figure 31: Enterprise Service Bus Subsystems ..................................................................................... 44 Figure 32: Subsystems and Packages identified for Enterprise Service Bus ........................................ 45 Figure 33: Message Communication Platform Subsystems.................................................................. 46 Figure 34: Subsystems and Packages identified for Message Communication Platform ..................... 47 Figure 35: Data Integrators Subsystems ............................................................................................... 49 Figure 36: Subsystems and Packages identified for Data Integrators ................................................... 50 Figure 37: Profile Execution Engine Subsystems ................................................................................. 51 Figure 38: Subsystems and Packages identified for Profile Execution Engine .................................... 52 Figure 39: Web Service Creator Tool Subsystems ............................................................................... 53 Figure 40: Packages identified for Web Service Subsystem ................................................................ 54 Figure 41: Packages identified for Web Service Creator Subsystem ................................................... 56 Figure 42: Emergency Maps Tool Subsystems ..................................................................................... 57 Figure 43: Subsystems and Packages identified for Emergency Maps Tool ........................................ 58 Figure 44: GIS Server Subsystems ....................................................................................................... 60 Figure 45: Subsystems and Packages identified for GIS Server ........................................................... 61 Figure 46: Sensor Protocol Adapter Tool Subsystems ......................................................................... 63 Figure 47: Subsystems and Packages identified for Sensor Protocol Adapter Tool ............................. 64 Figure 48: C2-SENSE Knowledge Interoperability Layer Components. Collaboration Environment

encompasses those described in the text: the Emergency Maps Tool, the Sensor Protocol Adapter (i.e.

the Sensor Management Tool) and the GIS Server. .............................................................................. 66 Figure 49: C2-SENSE Gateway Subsystems ........................................................................................ 66


Figure 50: Subsystems and Packages identified for C2-SENSE Gateway ........................................... 67 Figure 51: UC-EOCT-1 Interaction Diagram ....................................................................................... 68 Figure 52: UC-EOCT-2 Interaction Diagram ....................................................................................... 68 Figure 53: UC-EOCT-3 Interaction Diagram ....................................................................................... 69 Figure 54: UC-EOCT-4 Interaction Diagram ....................................................................................... 69 Figure 55: UC-MGT-1 Interaction Diagram ......................................................................................... 70 Figure 56: UC-MGT-2 Interaction Diagram ......................................................................................... 71 Figure 57: UC-PMT-1, UC-PMT-2, UC-PMT-3, UC-PMT-4, UC-PMT-5 and UC-PMT-6 Interaction

Diagram ................................................................................................................................................ 72 Figure 58: UC-PDST-1, UC-PDST-2, and UC-PDST-3 Interaction Diagram ..................................... 73 Figure 59: UC-PDST-4 Interaction Diagram ........................................................................................ 74 Figure 60: UC-SPT-1 Interaction Diagram - 1 ..................................................................................... 75 Figure 61: UC-SPT-1 Interaction Diagram – 2 ..................................................................................... 75 Figure 62: UC-SPT-2 and UC-SPT-3 Interaction Diagram .................................................................. 76 Figure 63: UC-SPT-4 Interaction Diagram ........................................................................................... 76 Figure 64: UC-CITM-1, UC-CITM-5, and UC-CITM-6 Interaction Diagram ..................................... 77 Figure 65: UC-CITM-2 and UC-CITM-3 Interaction Diagram ............................................................ 77 Figure 66: UC-CITM-4, UC-CITM-7, UC-CITM-8, UC-CITM-9, and UC-CITM-10 Interaction

Diagram ................................................................................................................................................ 78 Figure 67: UC-ESB-1 Interaction Diagram .......................................................................................... 79 Figure 68: UC-ESB-2 Interaction Diagram .......................................................................................... 80 Figure 69: UC-ESB-3 Interaction Diagram .......................................................................................... 80 Figure 70: UC-ESB-4 and UC-ESB-5 Interaction Diagram ................................................................. 80 Figure 71: UC-ESB-6 Interaction Diagram .......................................................................................... 81 Figure 72: UC-ESB-7 Interaction Diagram .......................................................................................... 81 Figure 73: UC-ESB-8 Interaction Diagram .......................................................................................... 82 Figure 74: UC-ESB-9 Interaction Diagram .......................................................................................... 82 Figure 75: UC-ESB-10 Interaction Diagram ........................................................................................ 82 Figure 76: UC-MCP-1, UC-MCP-2 and UC-MCP-3 Interaction Diagram .......................................... 83 Figure 77: UC-MCP-4 Interaction Diagram ......................................................................................... 83 Figure 78: UC-MCP-5 Interaction Diagram ......................................................................................... 84 Figure 79: UC-MCP-6 Interaction Diagram ......................................................................................... 84 Figure 80: UC-MCP-7 Interaction Diagram ......................................................................................... 85 Figure 81: UC-DI-1, UC-DI-2, and UC-DI-3 Interaction Diagram ...................................................... 85 Figure 82: UC-DI-4 Interaction Diagram ............................................................................................. 86 Figure 83: UC-PEE-1 Interaction Diagram .......................................................................................... 86 Figure 84: UC-PEE-2 Interaction Diagram .......................................................................................... 87 Figure 85: UC-PEE-3 Interaction Diagram .......................................................................................... 87 Figure 86: UC-WSCT-1 Interaction Diagram ...................................................................................... 88 Figure 87: UC-WSCT-2 Interaction Diagram ...................................................................................... 89 Figure 88: UC-WSCT-4 Interaction Diagram ...................................................................................... 89 Figure 89: UC-WSCT-5 Interaction Diagram ...................................................................................... 90 Figure 90: UC-EM-1 Interaction Diagram ............................................................................................ 91 Figure 91: UC-EM-2 Interaction Diagram ............................................................................................ 92 Figure 92: UC-EM-3 Interaction Diagram ............................................................................................ 92 Figure 93: UC-EM-4 Interaction Diagram ............................................................................................ 93 Figure 94: UC-EM-5 Interaction Diagram ............................................................................................ 94 Figure 95: UC-EM-6 Interaction Diagram ............................................................................................ 95 Figure 96: UC-GS-1 Interaction Diagram ............................................................................................ 96 Figure 97: UC-GS-2 Interaction Diagram ............................................................................................ 97 Figure 98: UC-GS-3 Interaction Diagram ............................................................................................ 97 Figure 99: UC-GS-4 Interaction Diagram ............................................................................................ 98 Figure 100: UC-SP-1 Interaction Diagram ........................................................................................... 99 Figure 101: UC-SP-2 Interaction Diagram ........................................................................................... 99 Figure 102: UC-SP-3 Interaction Diagram ......................................................................................... 100


Figure 103: UC-SP-4 Interaction Diagram ......................................................................................... 100 Figure 104: UC-C2SG-1 and UC-C2SG-2 Interaction Diagram ........................................................ 102 Figure 105: Ontology Resource Editor GUI Design Class ................................................................. 102 Figure 106: Ontology Resource Editor Design Class ......................................................................... 102 Figure 107: Ontology Resource Repository Interface Design Class .................................................. 103 Figure 108: Ontology Resource Repository Design Class .................................................................. 103 Figure 109: Content Model Importer GUI Design Class .................................................................... 103 Figure 110: Content Model Importer Design Class ............................................................................ 104 Figure 111: Ontology Editor GUI Design Class ................................................................................. 104 Figure 112: Ontology Editor Design Class ......................................................................................... 104 Figure 113: DL Reasoner Design Class .............................................................................................. 105 Figure 114: Ontology Repository Interface Design Class .................................................................. 105 Figure 115: Ontology Repository Design Class ................................................................................. 105 Figure 116: Mapping Generator Interface Design Class..................................................................... 106 Figure 117: Mapping Generator Design Class .................................................................................... 106 Figure 118: Local Domain Ontology Importer GUI Design Class ..................................................... 106 Figure 119: Converter Engine GUI Design Class ............................................................................... 106 Figure 120: Converter Engine Design Class ....................................................................................... 107 Figure 121: Mapping Repository Interface Design Class ................................................................... 107 Figure 122: Mapping Repository Design Class .................................................................................. 107 Figure 123: Profile Monitoring Tool GUI Design Class .................................................................... 108 Figure 124: Profile Monitoring Tool Interface Design Class ............................................................. 108 Figure 125: Profile Monitoring Tool Design Class............................................................................. 108 Figure 126: Profile Definition Tool GUI Design Class ...................................................................... 109 Figure 127: Profile Definition Tool Design Class .............................................................................. 110 Figure 128: Profile Repository Interface Design Class....................................................................... 110 Figure 129: Profile Repository Design Class ...................................................................................... 111 Figure 130: Profile Specialization Tool GUI Design Class ................................................................ 111 Figure 131: Profile Specialization Tool Design Class ........................................................................ 111 Figure 132: Specialized Profile Repository Interface Design Class ................................................... 112 Figure 133: Specialized Profile Repository Design Class .................................................................. 112 Figure 134: Authorization Manager Interface Design Class ............................................................... 112 Figure 135: Authorization Manager Design Class .............................................................................. 113 Figure 136: Authentication GUI Design Class ................................................................................... 113 Figure 137: Authentication Mechanism Design Class ........................................................................ 113 Figure 138: Encryption Manager Interface Design Class ................................................................... 113 Figure 139: Encryption Manager Design Class .................................................................................. 114 Figure 140: Certificate Authority Mechanism Design Class .............................................................. 114 Figure 141: Account Repository Interface Design Class .................................................................... 114 Figure 142: Account Repository Design Class ................................................................................... 115 Figure 143: Test Execution Monitoring GUI Design Class ................................................................ 115 Figure 144: Test Execution Monitoring Interface Design Class ......................................................... 115 Figure 145: Test Execution Monitoring Tool Design Class ............................................................... 115 Figure 146: Test Scenario Repository Interface Design Class ............................................................ 116 Figure 147: Test Scenario Repository Design Class ........................................................................... 116 Figure 148: Test Scenario Creator Interface Design Class ................................................................. 116 Figure 149: Test Scenario Creator Design Class ................................................................................ 117 Figure 150: Test Scenario Adapter Design Class ............................................................................... 117 Figure 151: Test Execution GUI Design Class ................................................................................... 117 Figure 152: Test Execution Engine Design Class ............................................................................... 117 Figure 153: Semantic Verification Mechanism Design Class ............................................................ 118 Figure 154: Syntactic Validation Mechanism Design Class ............................................................... 118 Figure 155: Rule Manager Form Design Class ................................................................................... 118 Figure 156: Rule Manager Design Class ............................................................................................ 119 Figure 157: Service Manager Form Design Class .............................................................................. 119


Figure 158: Service Manager Design Class ........................................................................................ 119 Figure 159: System Traffic Logger Interface Design Class ................................................................ 120 Figure 160: System Traffic Logger Design Class ............................................................................... 120 Figure 161: User To Topic Adder Form Design Class ....................................................................... 120 Figure 162: Role Assigner Form Design Class ................................................................................... 120 Figure 163: Role Creator Form Design Class ..................................................................................... 120 Figure 164: User And Role Creator Design Class .............................................................................. 121 Figure 165: User From Topic Deleter Form Design Class ................................................................. 121 Figure 166: User From Topic Deleter Design Class ........................................................................... 121 Figure 167: Topic Unsubscriber Interface Design Class .................................................................... 121 Figure 168: Topic Unsubscriber Design Class ................................................................................... 122 Figure 169: Communication Handler Form Design Class .................................................................. 122 Figure 170: Communication Handler Design Class............................................................................ 122 Figure 171: Message Receiver Interface Design Class ....................................................................... 122 Figure 172: Message Receiver Design Class ...................................................................................... 123 Figure 173: Message Validator Interface Design Class ...................................................................... 123 Figure 174: Message Validator Design Class ..................................................................................... 123 Figure 175: Message Modifier Interface Design Class ....................................................................... 123 Figure 176: Message Modifier Design Class ...................................................................................... 123 Figure 177: Formatted Message Sender Interface Design Class ........................................................ 124 Figure 178: Message Sender Design Class ......................................................................................... 124 Figure 179: Emergency Profile Form Design Class ........................................................................... 124 Figure 180: Emergency Profile Manager Form Design Class ............................................................ 124 Figure 181: Emergency Profile Manager Design Class ...................................................................... 125 Figure 182: Process Starter Form Design Class .................................................................................. 125 Figure 183: Process Starter Design Class ........................................................................................... 125 Figure 184: WSCT_GUI Design Class ............................................................................................... 126 Figure 185: Web Service Creator Design Class .................................................................................. 127 Figure 186: Authentication Service Design Class .............................................................................. 127 Figure 187: SOAP Interface Design Class .......................................................................................... 127 Figure 188: Service Mapper Interface Design Class........................................................................... 128 Figure 189: Service Mapper Design Class .......................................................................................... 128 Figure 190: Data Model Local View Design Class ............................................................................ 128 Figure 191: Data Integrator Interface Design Class ............................................................................ 129 Figure 192: Connector Interface Design Class ................................................................................... 129 Figure 193: Emergency Maps Tool GUI Design Class ...................................................................... 130 Figure 194: Emergency Maps Tool Design Class .............................................................................. 131 Figure 195: Situation Information Repository Interface Design Class ............................................... 132 Figure 196: Situation Information Repository Design Class .............................................................. 132 Figure 197: Knowledge Layer Interface Design Class ....................................................................... 132 Figure 198: Knowledge Layer Design Class ...................................................................................... 132 Figure 199: MashUp Tool Interface Design Class .............................................................................. 133 Figure 200: MashUp Tool Class Design ............................................................................................. 133 Figure 201: Emergency Activity Data Repository Tool Interface Design Class ................................ 133 Figure 202: Emergency Activity Data Repository Tool Design Class ............................................... 134 Figure 203: GIS Server GUI Design Class ......................................................................................... 134 Figure 204: GIS Server Design Class ................................................................................................. 135 Figure 205: Geospatial Resource Repository Interface Design Class................................................. 136 Figure 206: Geospatial Resource Repository Design Class ................................................................ 136 Figure 207: Semantic Information Interoperability Layer Interface Design Class ............................. 136 Figure 208: Semantic Information Interoperability Layer Design Class ............................................ 136 Figure 209: Geo Servers Interface Design Class ................................................................................ 137 Figure 210: Geo Servers Design Class ............................................................................................... 137 Figure 211: Maps Server Interface Design Class ................................................................................ 137 Figure 212: Maps Server Design Class ............................................................................................... 137


Figure 213: Sensor Management Tool GUI Design Class .................................................................. 138 Figure 214: Sensor Management Tool Design Class .......................................................................... 138 Figure 215: PnP Sensor Detection Tool Interface Design Class ......................................................... 139 Figure 216: PnP Sensor Detection Tool Design Class ........................................................................ 139 Figure 217: AnySen Tool Interface Design Class............................................................................... 139 Figure 218: AnySen Tool Design Class .............................................................................................. 140 Figure 219: Physical Interface Connector GUI Design Class ............................................................. 140 Figure 220: Physical Interface Connector Design Class ..................................................................... 140 Figure 221: Enterprise Service Bus Interface Design Class ............................................................... 141 Figure 222: Enterprise Service Bus Design Class .............................................................................. 141 Figure 223: Emergency Ontology Creator Tool State Chart .............................................................. 142 Figure 224: Mapping Generator Tool State Chart .............................................................................. 144 Figure 225: Profile Monitoring Tool State Chart ................................................................................ 145 Figure 226: Profile Definition and Specialization Tool State Chart - 1 .............................................. 146 Figure 227: Profile Definition and Specialization Tool State Chart - 2 .............................................. 147 Figure 228: Security and Privacy Tool State Chart ............................................................................ 148 Figure 229: Conformance and Interoperability Testing Mechanism State Chart ............................... 150 Figure 230: Enterprise Service Bus State Chart .................................................................................. 151 Figure 231: Message Communication Platform State Chart ............................................................... 152 Figure 232: Data Integrators State Chart ............................................................................................ 154 Figure 233: Profile Execution Engine State Chart .............................................................................. 155 Figure 234: Web Service Creator Tool State Chart – 1 ...................................................................... 156 Figure 235: Web Service Creator Tool State Chart – 2 ...................................................................... 157 Figure 236: Emergency Maps Tool State Chart .................................................................................. 158 Figure 237: GIS Server State Chart .................................................................................................... 159 Figure 238: Sensor Protocol Adapter Tool State Chart ...................................................................... 160 Figure 239: C2-SENSE Gateway State Chart ..................................................................................... 161 Figure 240: Emergency Ontology Creator Tool and its Associated Classes ...................................... 162 Figure 241: Mapping Generator Tool and its Associated Classes ...................................................... 163 Figure 242: Profile Monitoring Tool and its Associated Classes ....................................................... 164 Figure 243: Profile Definition and Specialization Tool and its Associated Classes ........................... 165 Figure 244: Security and Privacy Tool and its Associated Classes .................................................... 166 Figure 245: Conformance and Interoperability Testing Mechanism and its Associated Classes ....... 167 Figure 246: Enterprise Service Bus and its Associated Classes ......................................................... 168 Figure 247: Message Communication Platform and its Associated Classes ...................................... 169 Figure 248: Data Integrators and its Associated Classes .................................................................... 170 Figure 249: Profile Execution Engine and its Associated Classes ...................................................... 171 Figure 250: Web Service Creator Tool and its Associated Classes .................................................... 172 Figure 251: Emergency Maps Tool and its Associated Classes ......................................................... 173 Figure 252: GIS Server and its Associated Classes ............................................................................ 174 Figure 253: Sensor Protocol Adapter Tool and its Associated Classes .............................................. 175 Figure 254: C2-SENSE Gateway and its Associated Classes ............................................................. 176


1 INTRODUCTION

1.1 Purpose

This document describes the conceptual design of the C2-SENSE project according to the document

guidelines presented in the IEEE-1016 Recommended Practice for Software Design Descriptions

(SDD).

The SDD shows how the software system will be structured to satisfy the requirements identified in

the software requirements specification. It is a translation of requirements into a description of the

software structure, software components, interfaces, and data necessary for the implementation phase.

In essence, the SDD becomes a detailed blueprint for the implementation activity. In a complete SDD,

each requirement must be traceable to one or more design entities.

In preparation of SDD, as C2-SENSE consortium we have executed three preparatory tasks. In Task

2.2 a survey of the state of the art technologies, architectures and projects have been prepared. This

report is presented as Annex I of this deliverable. Secondly in Task 2.3, the requirements specification

of C2-SENSE architecture is prepared and reported in conformance to IEEE 1233-1998 & IEEE 830-

1998. This report is presented as Annex II of this deliverable. Lastly in the first step of Analysis &

Design Workflow of Rational Unified Process (RUP), Use-Case Analysis process is applied. This

report is presented as Annex III of this deliverable.

1.2 Scope

1.2.1 Introduction to C2-SENSE

Effective management of emergencies, crises and disasters depends on timely available, reliable and

intelligible information. To achieve this, many different organizations having different Command and

Control (C2) Systems and Sensor Systems have to cooperate and this cooperation would only be

possible through interoperability. However, without standards and well-defined specifications, the

interoperability of these systems can be quite challenging, technologically complex, time consuming

and expensive. Furthermore, although there are commonly used standards and specifications

(addressing also different layers in the communication stack) in the command and control, sensor and

emergency management domains, there is no single specification of using these standards together in

an emergency situation. These dispersed standards and specifications in these domains create a crucial

interoperability challenge.

To address this challenge profiling is a practical approach to achieve seamless interoperability by

addressing all the layers of the communication stack in the security field. C2-SENSE project's main

objective is to develop a profile based Emergency Interoperability Framework by the use of existing

standards and semantically enriched Web services, which will expose the functionalities of C2

Systems, Sensor Systems and other emergency/crisis management systems.

The profile concept aims to eliminate the need for a prior bilateral agreement between any two

information exchange partners by defining a standard set of messages/documents, choreographies,

business rules and constraints. The profile compliant partners are able to exchange information and

services among themselves. This is in contrast to the bilateral agreements that have to be settled

between partners for each new exchange partner. Considering the nature of emergency management,

where the responding organizations can change at run time (especially in an international intervention

case), and these generic profiles will permit coordination flexibility to deal with the unexpected

circumstances and to prevent chaotic response to crises situations.


Profiling has already been successfully used in domains such as eHealth through “Integrating the

Healthcare Enterprise Profiles”1. However, the conventional profiling approach addresses only the

first three layers of the Interoperability Stack: The “Communication Layer” covers the transport and

communication layer protocols; “Document Layer” addresses the content format of the messages and

documents exchanged among the applications, and the “Business Process Layer” addresses the

choreography of the activities to be executed by the participants.

However for emergency management, organizational aspects, such as policies, procedures, operations

and strategies are as important as technical aspects of interoperability. Therefore the interoperability

stack2 shown in Figure 1 has been proposed for crises control and management.

The profiles to be developed in the C2-SENSE Project will address all the layers of this

Interoperability Stack exposing available applications and implementing the missing technologies,

and making them available to the emergency community.

The gaps in the technology and standards will be identified and one of the first full implementation of

the Interoperability Stack will be deployed through the C2-SENSE Emergency Interoperability

Framework. It should be noted that these profiles are not yet another information model or data

format. On the contrary, they can be regarded as best practice documents on the use of existing

dispersed standards in the addressed domain and situation.

Figure 1: Interoperability Stack2 of the C2-SENSE Project

The Emergency Interoperability Framework will be developed in three main steps:

1. First, an Emergency Domain Inventory will be created by surveying existing standards, real

life use cases of sensors, devices, C2 Systems and emergency management architectures for

different scenarios in security field.

1 Integrating the Healthcare Enterprise Profiles, http://www.ihe.net/profiles/index.cfm

2 Andreas Tolk, “Beyond Technical Interoperability – Introducing a Reference Model for Measures of Merit for

Coalition Interoperability”, Proc. of the 8th Intl. Command and Control Research and Technology Symp. June

2003.


2. After that based on this inventory a common, modular and focused Emergency Domain

Ontology will be developed to gather all stakeholders' knowledge in a unique and flexible

data model.

The Emergency Domain Ontology will also enable the development of mechanism for the

interoperability of different standards/specification in the emergency domain. In other words,

the ontology will be a lingua franca for this field. It is a fact that there are substantial amount

of existing work in developing emergency domain ontologies. However, these ontologies are

either immature to be used in real life or not focused on the interoperability of C2 Systems

and/or Sensor Networks. The Emergency Domain Ontology will be based on prominent, well-

accepted and commonly used standards in emergency management, command and control

(C2) and sensor domains.

3. Finally, by using the concepts in this ontology, Emergency Interoperability Profiles that will

constitute the framework will be developed. These Emergency Interoperability Profiles will

enable effective exchange of information among different rescue units, public safety units and

information systems without requiring any special technical a priori arrangements even for

the international relief operations. These profiles will take also into account both functional

and operational requirements as well as different countries' cultural, linguistic and legal

issues.

Figure 2: C2-SENSE Framework


1.2.2 Scope of this Deliverable

For preparing the Conceptual Design of the C2-SENSE Architecture, we have executed the following

steps:

- First of all within the scope of Task 2.2, a survey of the state of the art technologies,

architectures and projects have been prepared. In this report a comprehensible survey is

presented in the related fields including sensor devices, use of sensors, sensor data processing,

secured process, knowledge algorithm, operation planning, sensor web enablement, decision

support, plug and measure concept, crisis and disaster management, semantic web, semantic

interoperability, profiling, conformance and interoperability testing, network management,

situational awareness, surveillance system coherence, data modeling and processing, data

enrichment, distributed systems interoperability. This report helped us to build our

architecture on top of the most recent and relevant industry standards and trends. This report

is presented as Annex I of this deliverable.

- As a second step, the “User and Technical Requirements of the C2-SENSE Architecture” is

prepared in accordance to IEEE 1233-1998 & IEEE 830-1998. Initial software components

and the interactions between these were identified through use case descriptions, and

technical gaps were identified and eliminated. The resulting requirements analysis provides a

more consistent view of the challenge to be addressed by the C2-SENSE system and defines a

common terminology. This report is presented as Annex II of this deliverable.

- As the third and final step, we have initiated the conceptual design phase on top of the results

of the requirement analysis results as well as the critical issues and considerations described

in “D7.1 Requirement Specifications and Scenario of the Pilot Applications”. The details of

this step are the main focus of this deliverable.

During the design task of C2-SENSE project, an adapted version of Rational Unified Process (RUP)

is applied. The RUP is a Software Engineering Process. It provides a disciplined approach for

assigning tasks and responsibilities within a development organization. Its goal is to ensure the

production of high-quality software that meets the needs of end-users and enhance team productivity.

The Rational Unified Process is composed of several workflows, namely Business Modeling

Workflow, Requirements Workflow, Analysis and Design Workflow, Implementation Workflow,

Test Workflow, Project Management Workflow, Configuration and Change Management Workflow

and finally Environment Workflow. These workflows address different phases of a project. In the

design task of the C2-SENSE project (Task 2.4 Conceptual Design of C2-SENSE Architecture), the

“Analysis & Design Workflow” phase is applied and as a result, this document, Deliverable 2.3 –

Conceptual Design of the C2-SENSE Architecture, is produced.

In the Analysis & Design Workflow, the requirements are transformed into the design of the system.

The Analysis & Design Workflow is adapted according to the needs of C2-SENSE Project. The

following phases have been performed throughout the design task:

1. Use-Case Analysis

2. Architectural Design

3. Use-Case Design

4. Class Design

The leading partner of Task 2.4 Conceptual Design of C2-SENSE Architecture, SRDC, has provided

partners with design templates within the scope of Task 1.2 Quality Assurance. After each phase, the

leading partner has analyzed partner contributions, build a unified model and distribute them to all

partners.

In the “Use-Case Analysis” phase, the use cases presented in the “User and Technical Requirements

of C2-SENSE Architecture (Annex II)” are analyzed, and the following tasks are performed:

- Identification of the classes which perform a use case’s flow of events

- Distribution of the use case behavior to those classes, using use case realizations

- Identification of the responsibilities, attributes and associations of the classes


The analysis classes and initial use case analyses have been analyzed and checked whether they meet

the requirements specified in Requirement Specification Report. In addition to that, discussions have

been initiated to unify the analysis classes.

In the second phase, “Architectural Design”, the analysis classes has been grouped as “subsystems”

and “design classes”. The interfaces provided by these subsystems have been identified by each

partner.

For the third phase, “Use Case Design”, the interaction diagrams which were previously provided in

terms of analysis classes have been updated to reflect the newly created subsystems and design

classes.

In the fourth and final phase, “Class Design”, the class diagrams are prepared. All of these steps have

been documented, and the results of “Use Case Analysis Phase” are presented as Annex III of this

deliverable (Use Case Analysis Phase of Conceptual Design Process of the C2-SENSE Architecture).

The results produced in this process have been collected and restructured to create the Software

Design Document of C2-SENSE in conformance to IEEE 1016 Guidelines, and presented in this

deliverable: The “Architectural Design” results have been documented in Section 3 Decomposition

Description, while the results of “Use Case Design” and “Class Design” phases have been

documented in Section 4 Detailed Description.

1.3 Definitions, Abbreviations and Acronyms

Table 1: List of Abbreviations and Acronyms

Abbreviation/

Acronym DEFINITION

AnySen Any Sensor

C2 Command and Control

C2SG C2-SENSE Gateway

CDE Common Data Element

CE Collaboration Environment

CITM Conformance and Interoperability Testing Mechanism

CRUD Create/Read/Update/Delete

DI Data Integrators

DL Description Logic

EDXL Emergency Data Exchange Language

EM Emergency Maps

EOCT Emergency Ontology Creator Tool

ESB Enterprise Service Bus

GIS Geographic Information System

GS GIS Server

GUI Graphical User Interface. A computer based, graphic (i.e. not text only) MMI.

MCP Message Communication Platform

MGT Mapping Generator Tool

MMI Man Machine Interface

OGC Open Geospatial Consortium

OWL Web Ontology Language

PDST Profile Definition and Specialization Tool

PEE Profile Execution Engine

PMT Profile Monitoring Tool

PnP Plug and Play

RDF Resource Description Framework

SOA Service Oriented Architecture

SOAP Simple Object Access Protocol. RPC / XML based protocol used in many web based SOA.

SP Sensor Protocol

SPT Security and Privacy Tool

UC Use Case

WSCT Web Service Creator Tool

XML Extended Mark-up Language


Table 2: Acronyms of project partners

Acronym Full name

AIT AIT Austrian Institute of Technology GmbH

IP Innova Puglia S.p.A.

LUTECH Lutech S.p.A.

PIAP Przemyslowy Instytut Automatyki i Pomiarow PIAP

Regione Puglia Regione Puglia

Regola Regola S.r.l.

SAGEM Sagem Defense Securite

SRDC SRDC Software Research & Development and Consultancy Ltd.


2 REFERENCES

C2-SENSE Deliverable D1.3 – Quality Assurance Plan

C2-SENSE Deliverable D2.1 – Survey of the State of the Art Technologies and Architectures

C2-SENSE Deliverable D2.2 – User and Technical Requirements of the C2-SENSE Architecture

C2-SENSE Deliverable D7.1 – Requirement Specifications and Scenario of the Pilot Applications

3 DECOMPOSITION DESCRIPTION

This section describes the decomposition of C2-SENSE modules into subsystems and packages. It

describes the way the system has been structured and the purpose and function of each entity. The

subsystems that are constructed as a result of the Architectural Design of C2-SENSE are described

with their responsibilities and design classes. The interfaces provided by subsystems are also

presented in this section.

Figure 3 shows the collaboration of modules (components) in C2-SENSE system. Decomposition

description of each component is described in the subsections of this section. The full names of

components shown in Figure 3 are as follows:

- CITM : Conformance and Interoperability Testing Mechanism

- PEE : Profile Execution Engine

- PDST : Profile Definition and Specialization Tool

- MGT : Mapping Generator Tool

- CE : Collaboration Environment

- SP : Sensor Protocol Adapters

- PMT : Profile Monitoring Tool

- SPT : Security and Privacy Tool

- REWS : Registry of Emergency Web Services

- MCP : Message and Communication Platform

- EM : Emergency Maps Tool

- GS : GIS Server

- EOCT : Emergency Ontology Creator Tool

- WSCT : Web Service Creator Tool

- DI : Data Integrators

- ESB : Enterprise Service Bus

- C2SG : C2-SENSE Gateway

As it is mentioned before, the profiles to be developed in the project will address all the layers of the

Interoperability Stack. Therefore in Figure 3, each component is presented in the layer it resides. The

arrows between components interpret the interactions between components. For example, in order to

create profiles PDST in Knowledge Interoperability Layer uses the ontologies developed by EOCT in

Information Interoperability Layer. In Aligned Procedures, the profile is specialized by PDST and

MGT for specific organizations and/or incidents. PEE then retrieves the specialized profile from

PDST and executes it. In the figure, CITM do not reside in any layer since it is not a part of C2-

SENSE system, it will only be used for testing.


Figure 3: Collaboration of Components in C2-SENSE System

Figure 4 shows the collaboration of components with SPT and ESB (For the sake of simplicity, this

collaboration is not presented in Figure 3). In C2-SENSE system, the communication among the

components and services of the C2-SENSE architecture will be based on ESB. In other words, each

component in C2-SENSE system will use ESB to communicate with other components. Furthermore,

SPT will be used by all components for the security and privacy issues.


Figure 4: Collaboration of Components with SPT and ESB

3.1 Emergency Ontology Creator Tool

Emergency Ontology Creator Tool provides necessary graphical user interfaces (GUI) and mechanism

to represent each of the incorporated standards in OWL-DL (Web Ontology Language – Description

Logics) format. The harmonized ontology to be used in C2-SENSE environment is generated with this

tool.

Figure 5: Emergency Ontology Creator Tool Subsystems


Figure 5 displays the subsystems identified for the Emergency Ontology Creator Tool. The

subsystems are as follows:

- Content Model Importer Subsystem: This subsystem is responsible for creating the ontology

resources from the imported content models.

- Ontology Resource Editor Subsystem: This subsystem is responsible for managing the CRUD

(Create/Read/Update/Delete) operations on ontology resources.

- Ontology Editor Subsystem: This subsystem is responsible for creating the complete ontology

and managing the CRUD operations on this ontology.

In the following subsections, these subsystems are described in detail.

Figure 6: Subsystems and Packages identified for Emergency Ontology Creator Tool

3.1.1 Content Model Importer Subsystem

In this section the subsystems and packages identified for the classes used for importing content

models and creating the ontology resources are presented. The following use case is covered by the

subsystems/packages described in this section:

- UC-EOCT-1 Import a Local Content Model

As shown in Figure 6, the interface of the Content Model Importer Subsystem is fulfilled by the

Content Model Importer GUI class. The subsystem generates/consumes the classes in Emergency

Ontology Creator Model package and uses the Ontology Resource Repository package for storing

these model classes persistently. There are three main classes in Emergency Ontology Creator Model

package: Content Model, Ontology Resource and Ontology.

The interface of the subsystem is a graphical interface and the following functionalities are provided

by the Content Model Importer Subsystem to the users (Figure 7):

- Creation of Ontology Resources

o Ability to parse various formats (XML, Excel, RDF/OWL etc.)

o Allowance to various standards (EDXL, OGC, other content models etc.)

o Creation of Common Data Elements (CDEs) as Ontology Resources


Figure 7: Component Diagram of Content Model Importer Subsystem

3.1.2 Ontology Resource Editor Subsystem

In this section the subsystems and packages identified for the classes used for viewing the details of

ontology resources are presented. The following use cases are covered by the subsystems/packages

described in this section:

- UC- EOCT-2 Search Ontology Resource

- UC- EOCT-3 Browse/View Ontology Resource

As shown in Figure 6, the interface of the Ontology Resource Editor Subsystem is fulfilled by the

Ontology Resource Editor GUI class. The subsystem consumes the classes in Emergency Ontology

Creator Model.


by the Ontology Resource Editor Subsystem to the users (Figure 8):

- Searching Ontology Resources

o Defining a search criteria

- Retrieving all Ontology Resources

- Browsing/Viewing Ontology Resources

o Displaying details of selected Ontology Resources

Figure 8: Component Diagram of Ontology Resource Editor Subsystem

3.1.3 Ontology Editor Subsystem

In this section the subsystems and packages identified for the classes used for exporting C2-SENSE

harmonized ontology are presented. The following use case is covered by the subsystems/packages


- UC- EOCT-4 Export C2-SENSE Harmonized Ontology


As shown in Figure 6, the interface of the Ontology Editor Subsystem is fulfilled by the Ontology

Editor GUI class. The subsystem generates/consumes the classes in Emergency Ontology Creator

Model package and uses the Ontology Repository package for storing these model classes

persistently. There are three main classes in Emergency Ontology Creator Model package: Content

Model, Ontology Resource and Ontology.


by the Ontology Editor Subsystem to the users (Figure 9):

- Converting Ontology Resources into Ontology

- Finding relations among similar attributes of entities

- Inserting missing relations

- Editing existing relations

- Generating complete Ontology

Figure 9: Component Diagram of Ontology Editor Subsystem

3.2 Mapping Generator Tool

The ontology is a lingua franca in C2-SENSE system. Applications conforming to different standards

are able to interoperate through this ontology. Mapping Generator Tool enables local systems to map

their local domain ontology to C2-SENSE Harmonized Ontology so that they are able to

communicate with each other.


Figure 10: Mapping Generator Tool Subsystems

Figure 10 displays the subsystems identified for the Mapping Generator Tool. The subsystems are as

follows:

- Mapping Generator Subsystem: This subsystem is responsible for defining mapping rules

between local domain ontology and C2-SENSE Harmonized Ontology.

- Converter Engine Subsystem: This subsystem is responsible for converting a local content

model to another according to the predefined mapping rules.



Figure 11: Subsystems and Packages identified for Mapping Generator Tool

3.2.1 Mapping Generator Subsystem

In this section the subsystems and packages identified for the classes used for defining mapping rules

between local domain ontology and C2-SENSE Harmonized Ontology are presented. The following

use case is covered by the subsystems/packages described in this section:

- UC-MGT-1 Map Local Domain Ontology to C2-SENSE Harmonized Ontology

As shown in Figure 11, the interface of the Mapping Generator Subsystem is fulfilled by the Mapping

Generator Interface and Local Domain Ontology Importer GUI classes. The subsystem

generates/consumes the classes in Mapping Generator Model package and uses the Mapping

Repository package for storing these model classes persistently. There is one main class in Mapping

Generator Model package: Mapping.


by the Mapping Generator Subsystem to the users (Figure 12):

- Importing a Local Content Domain Ontology


- Retrieving C2-SENSE Harmonized Ontology

- Defining mapping rules between Local Domain Ontology and C2-SENSE Harmonized

Ontology

- Editing the predefined mapping rules

Figure 12: Component Diagram of Mapping Generator Subsystem

3.2.2 Converter Engine Subsystem

In this section the subsystems and packages identified for the classes used for converting a local

content model to another are presented. The following use case is covered by the


- UC-MGT-2 Convert Local Content Model to Another

As shown in Figure 11, the interface of the Converter Engine Subsystem is fulfilled by the Converter

Engine GUI class. The subsystem consumes the classes in Mapping Generator Model package.


by the Converter Engine Subsystem to the users (Figure 13):

- Importing a Local Content Model

- Retrieving the mapping rules

- Converting the local content model to another according to the predefined mapping rules

Figure 13: Component Diagram of Converter Engine Subsystem


3.3 Profile Monitoring Tool

Profile Monitoring Tool makes it possible to visually trace the execution of a specific instance of a

profile.

Figure 14: Profile Monitoring Tool Subsystems

Figure 14 displays the subsystems identified for the Profile Monitoring Tool. The subsystems are as

follows:

- Profile Monitoring Subsystem: This subsystem is responsible for tracing the execution of

specific profile.



Figure 15: Subsystems and Packages identified for Profile Monitoring Tool

3.3.1 Profile Monitoring Subsystem

In this section the subsystems and packages identified for the classes used for tracing the execution of

a specific profile are presented. The following use cases are covered by the subsystems/packages


- UC-PMT-1 Trace the Execution of a Specific Profile

- UC-PMT-2 Display Completed Tasks

- UC-PMT-3 Display Currently Running Tasks

- UC-PMT-4 Display Bottlenecks

- UC-PMT-5 Display Incomplete Tasks

- UC-PMT-6 Display Pending Tasks


As shown in Figure 15, the interface of the Profile Monitoring Subsystem is fulfilled by the Profile

Monitoring Tool GUI and Profile Monitoring Tool Interface classes. The subsystem generates the

classes in Profile Monitoring Model package. There are two main classes in Profile Monitoring Model

package: Monitoring Message and Log.


by the Profile Monitoring Subsystem to the users (Figure 16):

- Displaying the completed tasks of currently executed profile

- Displaying the currently running tasks of currently executed profile

- Displaying the bottlenecks of currently executed profile

- Displaying the incomplete tasks of currently executed profile

- Displaying the pending tasks of currently executed profile

Figure 16: Component Diagram of Profile Monitoring Subsystem

3.4 Profile Definition and Specialization Tool

Profile Definition and Specialization Tool consists of two parts. Profile Definition part provides a

graphical user interface (GUI) to define the profiles as an ad hoc workflow describing the order of

tasks that emergency staff should realize. It can also be regarded as a step-by-step guideline to the

emergency situation. Profile Specialization part enables customization of profiles to specific incidence

and organizations.


Figure 17: Profile Definition and Specialization Tool Subsystems

Figure 17 displays the subsystems identified for the Profile Definition and Specialization Tool. The


- Profile Definition Subsystem: This subsystem is responsible for providing necessary

mechanism for Domain Expert to define new profile.

- Profile Specialization Subsystem: This subsystem is responsible for customizing the generic

profiles to specific organizations and incidents.



Figure 18: Subsystems and Packages identified for Profile Definition and Specialization Tool

3.4.1 Profile Definition Subsystem

In this section the subsystems and packages identified for the classes used for defining new profile are

presented. The following use cases are covered by the subsystems/packages described in this section:

- UC-PDST-1 Define Actors of a Profile

- UC-PDST-2 Define Messages of a Profile

- UC-PDST-3 Define Transactions of a Profile

As shown in the Figure 18, the interface of the Profile Definition Subsystem is fulfilled by the Profile

Definition Tool GUI class. The subsystem generates/consumes the classes in Profile Definition and

Specialization Model package and uses the Profile Repository package for storing these model classes

persistently. There are six main classes in Profile Definition and Specialization Model package:

Profile, Specialized Profile, Profile Actor, Profile Message, Profile Transaction and Profile

Organization.


by the Profile Definition Subsystem to the users (Figure 19):

- Defining actors of a profile

- Editing/Deleting actors of a profile

- Defining messages of a profile

- Editing/Deleting messages of a profile

- Defining transactions of a profile

- Editing/Deleting transactions of a profile


Figure 19: Component Diagram of Profile Definition Subsystem

3.4.2 Profile Specialization Subsystem

In this section the subsystems and packages identified for the classes used for customizing the generic

profile to specific organizations and incidents are presented. The following use case is covered by the


- UC-PDST-4 Specialize Generic Profile to a Specific Case

As shown in the Figure 18, the interface of the Profile Specialization Subsystem is fulfilled by the

Profile Specialization Tool GUI class. The subsystem generates/consumes the classes in Profile

Definition and Specialization Model package and uses the Specialized Profile Repository package for

storing these model classes persistently. There are six main classes in Profile Definition and

Specialization Model package: Profile, Specialized Profile, Profile Actor, Profile Message, Profile

Transaction and Profile Organization.


by the Profile Specialization Subsystem to the users (Figure 20):

- Retrieving predefined profile

- Assigning organizations as actors of profile

Figure 20: Component Diagram of Profile Specialization Subsystem


3.5 Security and Privacy Tool

Security and Privacy Tool controls the integrity, confidentiality, authorization and authentication in

the Collaboration Environment.

Figure 21: Security and Privacy Tool Subsystems

Figure 21 displays the subsystems identified for the Security and Privacy Tool. The subsystems are as

follows:

- Authorization Manager Subsystem: This subsystem is responsible for arranging users’

permissions in C2-SENSE system and checking these permissions whenever user performs an

action

- Encryption Manager Subsystem: This subsystem is responsible for providing secure data

transmission over network.

- Authentication Mechanism Subsystem: This subsystem is responsible for handling login and

logout operations in C2-SENSE system.



Figure 22: Subsystems and Packages identified for Security and Privacy Tool

3.5.1 Authorization Manager Subsystem

In this section the subsystems and packages identified for the classes used for authorization are

presented. The following use case is covered by the subsystems/packages described in this section:

- UC-SPT-1 Authorization

As shown in Figure 22, the interface of the Authorization Manager Subsystem is fulfilled by the

Authorization Manager Interface class. The subsystem generates/consumes the classes in Security and

Privacy Model package. There are five main classes Security and Privacy Model package:

Authorization Log, Encryption Log, Account Permission, Policy and Account.

Following functionalities are provided by the Authorization Manager Subsystem to the users (Figure

23):

- Retrieving accounts

- Changing account permissions

- Checking account permissions

- Generating related logs


Figure 23: Component Diagram of Authorization Manager Subsystem

3.5.2 Encryption Manager Subsystem

In this section the subsystems and packages identified for the classes used for providing secure data

transmission over network are presented. The following use cases are covered by the


- UC-SPT-2 Integrity

- UC-SPT-3 Usage of Certificates

As shown in Figure 22, the interface of the Encryption Manager Subsystem is fulfilled by the

Encryption Manager Interface class. The subsystem generates/consumes the classes in Security and

Privacy Model.

Following functionalities are provided by the Encryption Manager Subsystem to the users (Figure 24):

- Generating encrypted hash

- Generating certificate

- Signing data to be sent over network

- Encrypting data to be sent over network

- Validating data retrieved over network

Figure 24: Component Diagram of Encryption Manager Subsystem


3.5.3 Authentication Mechanism Subsystem

In this section the subsystems and packages identified for the classes used for login and logout

operations are presented. The following use case is covered by the subsystems/packages described in

this section:

- UC-SPT-4 Authentication

As shown in Figure 22, the interface of the Authentication Mechanism Subsystem is fulfilled by the

Authentication GUI class. The subsystem consumes the classes in Security and Privacy Model

package.


by the Authentication Mechanism Subsystem to the users (Figure 25):

- Handling login operation

- Handling logout operation

Figure 25: Component Diagram of Authentication Mechanism Subsystem

3.6 Conformance and Interoperability Testing Mechanism

Only through testing, correct information exchange among crises management applications can be

guaranteed. Interoperability testing involves checking that the applications indeed conform to the

profile specifications that they claim to and hence can interoperate with other conformant systems.

Conformance and Interoperability Testing Mechanism is used to check the conformance of involved

systems to the developed profiles and the interoperability among them.


Figure 26: Conformance and Interoperability Testing Mechanism Subsystems

Figure 26 displays the subsystems identified for the Conformance and Interoperability Testing

Mechanism. The subsystems are as follows:

- Test Execution Subsystem: This subsystem is responsible for executing the test scenario.

- Test Execution Monitoring Subsystem: This subsystem is responsible for tracing the

execution of test scenario and displaying the details to the user.

- Test Scenario Creator Subsystem: This subsystem is responsible for creating test scenarios to

be executed later.



Figure 27: Subsystems and Packages identified for Conformance and Interoperability Testing

Mechanism

3.6.1 Test Execution Monitoring Subsystem

In this section the subsystems and packages identified for the classes used for monitoring the

execution of a test scenario are presented. The following use cases are covered by the


- UC-CITM-1 Provide Web Based Graphical Environment

- UC-CITM-5 Display Detailed Log Information

- UC-CITM-6 Display Error Location

As shown in Figure 27, the interface of the Test Execution Monitoring Subsystem is fulfilled by the

Test Execution Monitoring GUI and Test Execution Monitoring Interface classes. The subsystem

generates/consumes the classes in Test Execution Model package. There are three main classes in Test

Execution Model package: Test Execution Message, Test Report and Test Scenario.


by the Test Execution Monitoring Subsystem to the users (Figure 28):

- A Web based environment so that the user can execute tests over Web anytime

- Displaying detailed log information when a test is executed

- Displaying the location of errors of failed tests

- Generating comprehensive test report after the test execution is completed


Figure 28: Component Diagram of Test Execution Monitoring Subsystem

3.6.2 Test Execution Subsystem

In this section the subsystems and packages identified for the classes used for executing the test

scenario are presented. The following use cases are covered by the subsystems/packages described in

this section:

- UC-CITM-4 Execute Test Scenario

- UC-CITM-7 Automate Whole Testing Process

- UC-CITM-8 Capture Messages Exchanged Between Parties

- UC-CITM-9 Verify Emergency Messages and Documents Semantically

- UC-CITM-10 Validate Emergency Messages and Documents Syntactically

As shown in Figure 27, the interface of the Test Execution Subsystem is fulfilled by the Test

Execution GUI class. The subsystem generates/consumes the classes in Test Execution Model

package.

Following functionalities are provided by the Test Execution Subsystem to the users (Figure 29):

- Executing tests automatically

- Capturing messages exchanged between parties

- Verifying messages and documents semantically for conformance testing

- Validating messages and documents syntactically for interoperability testing


Figure 29: Component Diagram of Test Execution Subsystem

3.6.3 Test Scenario Creator Subsystem

In this section the subsystems and packages identified for the classes used for creating the test

scenario are presented. The following use cases are covered by the subsystems/packages described in

this section:

- UC-CITM-2 Provide Emergency Test Scenario

- UC-CITM-3 Simulate Missing Roles in the Scenario

As shown in Figure 27, the interface of the Test Scenario Creator Subsystem is fulfilled by the Test

Scenario Creator Interface class. The subsystem generates/consumes the classes in Test Execution

Model package and uses the Test Scenario Repository package for storing these model classes

persistently.

Following functionalities are provided by the Test Scenario Creator Subsystem to the users (Figure

30):

- Enabling user to provide the scenario with a computer interpretable test description language.

- Defining involved systems as actors of scenario

- Simulating missing roles in the scenario

Figure 30: Component Diagram of Test Scenario Creator Subsystem


3.7 Enterprise Service Bus

Enterprise Service Bus (ESB) is a software architecture construct which provides fundamental

services via an event-driven and standards-based messaging engine (the bus). An ESB can be viewed

as an enterprise messaging system which allows integration between different architectures through

the use of interface adapters and data transformation services.

Figure 31: Enterprise Service Bus Subsystems

Figure 31 displays the subsystems identified for the Enterprise Service Bus Platform. The subsystems

are as follows:

- Rule Subsystem: This subsystem is responsible for managing rules on the ESB.

- Service Subsystem: This subsystem is responsible for managing services on the ESB.

- Network Monitoring Tool Subsystem: This subsystem is responsible for managing the

monitoring features.



Figure 32: Subsystems and Packages identified for Enterprise Service Bus

3.7.1 Rule Subsystem

In this section the subsystems and packages identified for the classes used for adding, modifying and

deleting rules are presented. The following use cases are covered by the subsystems/packages


- UC-ESB-1 Add New Rule

- UC-ESB-2 Modify ESB Rule

- UC-ESB-3 Delete ESB Rule

The interface of the Rule Subsystem is fulfilled by the Rule Manager Form class. The subsystem

generates/consumes the Rule entity.

3.7.2 Service Subsystem

In this section the subsystems and packages identified for the classes used for adding, modifying and

deleting services are presented. The following use cases are covered by the subsystems/packages


- UC-ESB-6 Register New Service on ESB

- UC-ESB-7 View Registered Service

- UC-ESB-8 Delete Registered Service

- UC-ESB-9 Send Message

- UC-ESB-10 Receive Message

The interface of the Service Subsystem is fulfilled by the Service Manager Form class. The subsystem

generates/consumes the Service entity.

3.7.3 Network Monitoring Tool Subsystem

In this section the subsystems and packages identified for the classes used for monitoring network

activity and viewing system logs are presented. The following use cases are covered by the


- UC-ESB-4 Monitor Network Traffic

- UC-ESB-5 View System Logs


The interface of the Network Monitoring Tool Subsystem is fulfilled by the System Traffic Logger

Interface class. The subsystem generates/consumes the System Traffic Log entity.

3.8 Message Communication Platform

Message Communication Platform enables the individuals that make up the emergency team to

interact with each other during the group decision making process. It provides publish-subscribe

mechanism so that each user can register his interest in a particular type of message, and get a

notification whenever a new message matching the subscription arrives.

Figure 33: Message Communication Platform Subsystems


Figure 33 displays the subsystems identified for the Message Communication Platform. The


- User And Role Creator Subsystem: This subsystem is responsible for adding user to a topic

and assigning it a role.

- User From Topic Deleter Subsystem: This subsystem is responsible for removing the user

from a topic.

- Topic Unsubscriber Subsystem: This subsystem is responsible from un-subscription of user.

- Communication Handler Subsystem: This subsystem is responsible for sending and receiving

messages between users.


Figure 34: Subsystems and Packages identified for Message Communication Platform

3.8.1 User And Role Creator Subsystem

In this section the subsystems and packages identified for the classes used for adding user to a topic

and assigning related roles are presented. The following use cases are covered by the


- UC-MCP-1 Add User to Topic

- UC-MCP-2 Create Role

- UC-MCP-3 Assign Role

The interface of the User And Role Creator Subsystem is fulfilled by the User To Topic Adder Form,

Role Assigner Form and Role Creator Form classes. The subsystem generates/consumes the Topic

User and User Role entities.


3.8.2 User From Topic Deleter Subsystem

In this section the subsystems and packages identified for the classes used for removing the user form

a topic are presented. The following use cases are covered by the subsystems/packages described in

this section:

- UC-MCP-4 Deleting User from Topic

The interface of the User From Topic Deleter Subsystem is fulfilled by the User From Topic Deleter

Form class. The subsystem generates/consumes the Topic User and User Role entities.

3.8.3 Topic Unsubscriber Subsystem

In this section the subsystems and packages identified for the classes used for user’s self-

unsubscription are presented. The following use cases are covered by the subsystems/packages


- UC-MCP-5 Un-subscription from Topic

The interface of the Topic Unsubscriber Subsystem is fulfilled by the Topic Unsubscriber Interface

class. The subsystem generates/consumes the Topic User and User Role entities.

3.8.4 Communication Handler Subsystem

In this section the subsystems and packages identified for the classes used for handling

communications of the users are presented. The following use cases are covered by the


- UC-MCP-6 Send Message

- UC-MCP-7 Receive Message

The interface of the Communication Handler Subsystem is fulfilled by the Communication Handler

Form class. The subsystem generates/consumes the Message entity.

3.9 Data Integrators

Data Integrators convert the data format of the emergency systems/sensors according to specified

standard data format. It is used by Web Service Creator Tool to expose accessed data in standard data

format.


Figure 35: Data Integrators Subsystems

Figure 35 displays the subsystems identified for the Data Integrators. The subsystems are as follows:

- Message System Subsystem: This subsystem is responsible for receiving and validating the

messages.

- Message Sender Subsystem: This subsystem is responsible for forwarding the received and

validated messages to the ESB.



Figure 36: Subsystems and Packages identified for Data Integrators

3.9.1 Message System Subsystem

In this section the subsystems and packages identified for the classes used for receiving, validating

and modifying messages are presented. The following use cases are covered by the


- UC-DI-1 Receiving Events

- UC-DI-2 Validating Format

- UC-DI-3 Converting Data Format

The interface of the Message System Subsystem is fulfilled by the interfaces designated to receive the

validated messages. The subsystem generates/consumes the Message entity.

3.9.2 Message Sender Subsystem

In this section the subsystems and packages identified for the classes used for sending formatted

messages are presented. The following use cases are covered by the subsystems/packages described in

this section:

- UC-DI-4 Forwarding Formatted Data to the ESB

The interface of the Message Sender Subsystem is fulfilled by the interfaces designated to send

formatted messages. The subsystem generates/consumes the Message entity.


3.10 Profile Execution Engine

Profile Execution Engine executes the profiles specialized for specific organizations and incidents.

Figure 37: Profile Execution Engine Subsystems

Figure 37 displays the subsystems identified for the Profile Execution Engine. The subsystems are as

follows:

- Emergency Profiler Subsystem: This subsystem is responsible for uploading an existing

emergency profile or creating a new one.

- Process Subsystem: This subsystem is responsible for starting a new or existing process.



Figure 38: Subsystems and Packages identified for Profile Execution Engine

3.10.1 Emergency Profiler Subsystem

In this section the subsystems and packages identified for the classes used for uploading emergency

profiles are presented. The following use cases are covered by the subsystems/packages described in

this section:

- UC-PEE-1 Import Emergency Profile

- UC-PEE-2 Delete Emergency Profile

The interface of the Emergency Profiler Subsystem is fulfilled by the Emergency Profile Form and

Emergency Profile Uploader Form through which file is uploaded with the definition of an emergency

profile and its details. The subsystem generates/consumes the Emergency Profile and Process entities.

3.10.2 Process Subsystem

In this section the subsystems and packages identified for the classes used for starting previously

defined processes are presented. The following use cases are covered by the subsystems/packages


- UC-PEE-3 Start Process

The interface of the Process Subsystem is fulfilled by the Process Starter Form interface through

which processes are eventually started. The subsystem generates/consumes the Emergency Profile and

Process entities.


3.11 Web Service Creator Tool

Web Service Creator Tool exposes the functionality of legacy systems as web services that conform to

the developed Emergency Interoperability Profiles by creating all the necessary code. Once a query is

written for the desired function on the legacy system, Web Service Creator Tool turns this query into

a Web service ready to be invoked.

Figure 39: Web Service Creator Tool Subsystems

Figure 39 displays the subsystems identified for the Web Service Creator Tool. The subsystems are as

follows:

- Web Service Creator Subsystem: This subsystem is responsible from the web service creation

and management

- Web Service Subsystem: This subsystem is responsible from the web service hosting


3.11.1 Web Service Subsystem

In this section the subsystems and packages identified for the classes used for the Web Service are

presented. The following use cases are partially covered by the subsystems/packages described in this

section:

- UC-WSCT-1 Create a Service for a Given Legacy System


- UC-WSCT-2 Install the WSC Tool

- UC-WSCT-3 Start the WSC Tool

- UC-WSCT-5 Upgrade the Interface of a Legacy System

- UC-WSCT-6 Upgrade the Profiles

Figure 40: Packages identified for Web Service Subsystem

Two main packages appear here:

- Data Integrator, whose role is to translate proprietary messages / queries to C2-SENSE

standard ones

- Adapter, whose role is to connect to the legacy system (including sensor networks) using

these systems’ protocols


Both are to comply with a standardized interface, and both will be specialized by legacy system

and/or protocol set.

The Service Mapper is the main controller, assembling all elements and routing messages to and from

them. It complies to the SOAP Interface, which has to be specialized according to service profiles,

and to the Service Mapper Interface, which is used by the Web Service Creator to manage the service

(start, stop, configure it).

As a side note, these services are to be used by the semantic mediators.

3.11.2 Web Service Creator Subsystem

In this section the subsystems and packages identified for the classes used for the Web Service

Creator are presented. The following use cases are partially covered by the subsystems/packages


- UC-WSCT-1 Create a Service for a Given Legacy System

- UC-WSCT-2 Install the WSC Tool

- UC-WSCT-3 Start the WSC Tool

- UC-WSCT-4 Log into the Tool

- UC-WSCT-5 Upgrade the Interface of a Legacy System

- UC-WSCT-6 Upgrade the Profiles


Figure 41: Packages identified for Web Service Creator Subsystem

The Web Service Creator Tool is based on a GUI (WSCT_GUI), piloting a controller (Web Service

Creator).

The controller defines an external system by its protocol and data integration profiles, which list the

compatibilities, by the user defined queries, and, once the service is defined, by the representation of

its status.

The controller generates web server code, and allows monitoring the web service as defined earlier. In

the code generation, the controller takes into account the profiles. The use of a Data Integrator is

linked to the Data Integration Profile: if the legacy system is already compliant with C2-SENSE

recognized standards, this is not necessary.

3.12 Emergency Maps Tool

Emergency Maps Tool mashes up the emergency geospatial data and map data from the GIS Server,

and displays the emergency area geographically to the related authorized users.


Figure 42: Emergency Maps Tool Subsystems

There are four subsystems identified with the Emergency Maps Tool:

- Emergency Maps Importer Subsystem is responsible for creating a common situation

information resource from imported content file/model, for validating the user and invoking

the emergency map display.

- Knowledge Layer Subsystem is responsible for acquiring and providing geospatial

information and maps.

- MashUp Tool Subsystem is responsible for data rendering (from Knowledge Layer).

- Emergency Situation User Actions Subsystem is responsible for recording and playing the

emergency user activity data


In this tool, open source tools will be applied: OpenLayers3.

Figure 43: Subsystems and Packages identified for Emergency Maps Tool

3.12.1 Emergency Maps Importer Subsystem

The following use cases are (fully or partly) covered by the subsystems/packages described here:

- UC-EM-1 Provide a Common Operational Picture of the Crisis Situation

- UC-EM-2 Support Decision Making Process

- UC-EM-3 Display Emergency Area to User

- UC-EM-4 Show Maps and Situation Information

As shown in Figure 42 and Figure 43, the interface of the Emergency Maps Importer Subsystem is

fulfilled by the Emergency Maps Importer GUI class. The subsystem uses the classes in the Common

Situation Information Resource, and uses the Situation Information Repository package to save the

input/update.

3 http://openlayers.org

http://openlayers.org/


The interface of the subsystem is a graphical user interface and following functionalities are provided:

- Input emergency situation data

o Ability to parse specific file format

o Ability to provide GUIs for a direct user input

- Decision making activation

o Provide role activation

- Show a default map of the area in vicinity of user’s location

- Show a map with overlaid features

o Ability to select a map from several available maps

o Ability to apply GIS data

o Filter usage on map (GIS) features

3.12.2 Knowledge Layer Subsystem

As shown in Figure 42 and Figure 43, the interface of the Knowledge Layer Subsystem is fulfilled by

the Knowledge Layer Interface class.

The following functionalities are provided by the Knowledge Layer Subsystem:

- Retrieving GIS data/information from an external source

- Retrieving available maps from an external source

3.12.3 MashUp Tool Subsystem

As shown in Figure 42 and Figure 43, the interface of the MashUp Tool Subsystem is fulfilled by the

MashUp Tool Interface class.

The following functionalities are provided by the subsystem:

- Rendering of GIS data and maps

3.12.4 Emergency Situation User Actions Subsystem


- UC-EM-5 Track the Emergency Situation User Actions

- UC-EM-6 Analyze the Emergency Situation User Actions

As shown in Figure 42 and Figure 43, the interface of Emergency Situation User Actions Subsystem

is fulfilled by the Emergency Activity Data Repository Tool Interface class.


- Recording of the user action during an emergency situation

- Loading and playing user action (and all maps, feature etc.) – i.e. playing the scenario again

3.13 GIS Server

GIS Server generates detailed geospatial information about emergency situations and provides them

to Emergency Maps Tool for displaying to the emergency responders.


Figure 44: GIS Server Subsystems

There are three subsystems identified with the GIS Server:

- GIS Server Subsystem is responsible for providing the data access, and displaying data and

maps.

- Semantic Information Subsystem is responsible for providing the semantic information.

- Geo-Servers Subsystem is responsible for providing synchronized geo-spatial information.

- Maps Servers Subsystem is responsible for providing the geo-referenced maps.

In this subsystem, open source tools will be applied: GeoServer4 and MapServer

5.

4 www.geoserver.org

http://www.geoserver.org/


Figure 45: Subsystems and Packages identified for GIS Server

3.13.1 GIS Server Subsystem


- UC-GS-1 Share and Edit Geospatial Data

- UC-GS-2 Extract Spatial Information From Semantic Information Interoperability Layer

- UC-GS-3 Deliver Geo-Referenced Information from Different Sensors

- UC-GS-4 Provide Background Maps for the Geo-Referenced Presentation of Relevant Data

5 http://mapserver.org

http://mapserver.org/


As shown in Figure 44 and Figure 45, the interface of the GIS Server Subsystem is fulfilled by the

GIS Server GUI class. The subsystem provides access to maps, (synchronized) geo-referenced data

and semantic data.


- Input local geo-referenced data

o Ability to parse specific file format

o Ability to provide GUIs for a direct user input

- Access to geo-spatial data

o Editing data

o Saving data

- Semantic information extraction

- Synchronization

o Synchronize with other servers

- Data displaying

o Map display

o Select/set coordinates

o Zoom map

3.13.2 Semantic Information Subsystem

The following use case is (fully or partly) covered by the subsystems/packages described here:

- UC-GS-2 Extract Spatial Information from Semantic Information Interoperability Layer

As shown in Figure 44 and Figure 45, the interface of the Semantic Information Subsystem is fulfilled

by the Semantic Information Interoperability Interface class.


- Extracting semantic information/data

- Analyzing the semantic data

3.13.3 Geo Servers Subsystem


- UC-GS-3 Deliver Geo-Referenced Information from Different Sensors

As shown in Figure 44 and Figure 45, the interface of the Geo Servers Subsystem is fulfilled by the

Geo Servers Interface class.


- Synchronization with available sensors

- Providing (synchronized) geo-spatial data

3.13.4 Maps Server Subsystem


- UC-GS-4 Provide Background Maps for the Geo-Referenced Presentation of Relevant Data

As shown in Figure 44 and Figure 45, the interface of the Maps Server Subsystem is fulfilled by the

Maps Server Interface class.


- Requesting available maps

- Searching maps

- Providing map(s)


3.14 Sensor Protocol Adapter Tool

Sensor Protocol Adapter Tool provides interoperability of Sensor Networks and interprets the data

retrieved from sensors.

Figure 46: Sensor Protocol Adapter Tool Subsystems

There are three subsystems identified with the Sensor Protocol Adapter Tool:

- Sensor Management Tool Subsystem is responsible for providing the control of sensors.

- PlugNplay Tool Subsystem is responsible for providing the semantic information.

- AnySen Subsystem is responsible for providing synchronized geo-spatial information (from

other sensors). An already developed AnySen Data Handler will be used.


Figure 47: Subsystems and Packages identified for Sensor Protocol Adapter Tool

3.14.1 Sensor Management Tool Subsystem


- UC-SP-1 Sensor Management for Many Sensors

- UC-SP-2 Plug and Measure

- UC-SP-3 Gather Real-Time Data

- UC-SP-4 User Management of Sensors and Input

As shown in Figure 46 and Figure 47, the interface of the Sensor Management Tool Subsystem is

fulfilled by the Sensor Management Tool GUI class. The subsystem provides control of available

sensors.


- Sensor management:

o Listing of connected sensors

o Listing of available sensors

o Adding sensors

o Disconnecting sensors

o Showing sensor information

- Activating sensor data stream

o Selecting sensors

o Selecting sensor data range

o Selecting filters on sensor data


3.14.2 PlugNplay Subsystem



As shown in Figure 46 and Figure 47, the interface of the PlugNplay Subsystem is fulfilled by the PnP

Sensor Detection Tool Interface class. The subsystem provides the sensor detection.


- Sensor detection

- Sensor activation/selection

3.14.3 AnySen Tool Subsystem



As shown in Figure 46 and Figure 47, the interface of the AnySen Tool Subsystem is fulfilled by the

AnySen Tool Interface class. The subsystem is responsible from sensor driver configuration. In this

subsystem, AnySen Data Handler will be used.


- Sensor driver configuration

- Sending status messages to user

3.15 Collaboration Environment

Collaboration involves a collaboration process that includes the activities performed by humans and

applications in collaboration. In C2-SENSE, the profiles define the collaboration process determining

when, how and by whom each activity are performed. Collaboration Environment provides necessary

functionalities in that purpose.

The Emergency Maps Tool, the Sensor Protocol Adapter (i.e. the Sensor Management Tool) and the

GIS Server are all parts of the Collaboration Environment (CE). As such, the use cases UC-CE 1 to 5

are all directly related to the uses cases of these “sub-packages”. This is shown in Figure 48. We refer

to the above mentioned for further details.

The use cases relevant for the tool:

- UC-CE-1 Combination of Maps with Content Information from Different (Information)

Sources (see UC-GS-2 and 3)

- UC-CE-2 Visualize Crisis Situation (see UC-EM-3 and 4)

- UC-CE-3 Provide Information for Decision Making Process (see UC-GS-1 to 4, UC-EM-2)

- UC-CE-4 Provide Map Data and Content Information for Emergency Maps Tool (see UC-

GS-1 to 4)

- UC-CE-5 Gather User Input to Track the Changes of Crisis Situation (see UC-GS-1, UC-EM-

1).


Figure 48: C2-SENSE Knowledge Interoperability Layer Components. Collaboration Environment

encompasses those described in the text: the Emergency Maps Tool, the Sensor Protocol Adapter (i.e. the

Sensor Management Tool) and the GIS Server.

3.16 C2-SENSE Gateway

C2-SENSE Gateway enables exchange of data using prominent wired and wireless communication

mediums in the emergency domain. In order to provide physical communication interoperability, the

good practices of SECRICOM project will be applied.

Figure 49: C2-SENSE Gateway Subsystems

There are two subsystems identified in C2-SENSE Gateway:

- Physical Interface Connector Subsystem: is responsible for building a TCP/IP interconnection

of networks, which provide universal communication service over heterogeneous physical

network.

- Enterprise Service Bus Subsystem: is responsible for applying proper C2-SENSE data

aggregation rules and data storing.


Figure 50: Subsystems and Packages identified for C2-SENSE Gateway

3.16.1 Physical Interface Connector Subsystem

The following use cases are covered by the subsystems/packages described in here:

- UC-C2SG-1 Connect Data from External System/Data Source

This subsystem is responsible for receiving all restricted set of information and providing them to

Physical Interface Connector GUI. This module is under control of Physical Interface Connector GUI

containing specialized scripts for data flow control. This subsystem also enables the configuration of

all the functionalities for the administration, including communication protocol setup (to configure the

communication protocol with Data Resource), permission setup (to configure access security

policies), setup filtering and aggregation parameters (to configure the raw data filtering and

aggregation policies).

3.16.2 Enterprise Service Bus Subsystem

The following use cases are covered by the subsystems/packages described in here:

- UC-C2SG-2 Send Data in Unified Form to Enterprise Service Bus

This subsystem applies data aggregation and filtering configuration in order to start data pre-

processing to unified C2-SENSE data format. Both aggregation data controller and filtering data

controller are synchronized in real time according to the needs of data flow. It implements the

mechanisms that correct the output retrieved from Physical Interface Connector Subsystem. It also

provides rules for verification of data integrity. Transmission protocol module covers specialized

XML templates which enable further use for the system. To allow flexible communication, all

interactions are dealt with by exchanging XML messages over a TCP-IP connection.


4 DETAILED DESCRIPTION

4.1 Detailed Interaction Diagrams

4.1.1 Emergency Ontology Creator Tool Interaction Diagrams

4.1.1.1 Use Case: UC-EOCT-1 Import a Local Content Model

The interaction diagram for “UC-EOCT-1 Import a Local Content Model” is shown in Figure 51. As

shown in the figure, Domain Expert imports the Content Model graphically through Content Model

Importer GUI. Imported Content Model automatically parsed and analyzed by Content Model

Importer and Ontology Resources are created. Resultant Ontology Resources are saved to Ontology

Resource Repository.

Figure 51: UC-EOCT-1 Interaction Diagram

4.1.1.2 Use Case: UC-EOCT-2 Search Ontology Resource

The interaction diagram for “UC-EOCT-2 Search Ontology Resource” is shown in Figure 52. As

shown in the figure, Domain Expert defines search criteria and searches for Ontology Resources with

these search criteria through Ontology Resource Editor GUI. Ontology Resource Editor retrieves

Ontology Resources matching the search criteria from Ontology Resource Repository.



4.1.1.3 Use Case: UC-EOCT-3 Browse/View Ontology Resource

The interaction diagram for “UC-EOCT-3 Browse/View Ontology Resource” is shown in Figure 53.

As shown in the figure, Domain Expert first retrieves the ontology resources from Ontology Resource

Repository through Ontology Resource Editor GUI (Ontology Resources can also be retrieved by

searching through UC-EOCT-2). Then, Domain Expert selects the ontology resource(s) that s/he

wants to view the details and Ontology Resource Editor displays the details of selected ontology

resource(s) through Ontology Resource Editor GUI.


4.1.1.4 Use Case: UC-EOCT-4 Export C2-SENSE Harmonized Ontology

The interaction diagram for “UC-EOCT-4 Export C2-SENSE Harmonized Ontology” is shown in

Figure 54. As shown in the figure, Ontology Editor first retrieves the ontology resources which are

already saved in Ontology Resource Repository and converts the ontology resources into Ontology.

Ontology is then fed into DL Reasoner to find the relations among similar attributes of entities. After

that Domain Expert inserts the missing roles that DL Reasoner could not find and Ontology Editor

constitutes the harmonized Ontology and saves it to Ontology Repository through Ontology

Repository Interface.



4.1.2 Mapping Generator Tool Interaction Diagrams

4.1.2.1 Use Case: UC-MGT-1 Map Local Domain Ontology to C2-SENSE Harmonized

Ontology

The interaction diagram for “UC-MGT-1 Map Local Domain Ontology to C2-SENSE Harmonized

Ontology” is shown in Figure 55. As shown in the figure, Domain Expert first imports a Local

Domain Ontology to be mapped and retrieves the previously created C2-SENSE Harmonized

Ontology from Ontology Repository. After that, Domain Expert defines the mapping rules between

Local Domain Ontology and C2-SENSE Harmonized Ontology through Mapping Generator and

defined mapping rules are saved to the Mapping Repository through Mapping Repository Interface.

Figure 55: UC-MGT-1 Interaction Diagram

4.1.2.2 Use Case: UC-MGT-2 Convert Local Content Model to Another

The interaction diagram for “UC-MGT-2 Convert Local Content Model to Another” is shown in

Figure 56. As shown in the figure, Domain Expert imports the Local Content Model to be converted

and retrieves its mapping from Mapping Repository through Converter Engine GUI. Domain Expert

then also retrieves the mapping of Content Model that Local Content Model is to be converted and

initiates the conversion operation. Converter Engine converts the Local Content Model to another by

using these mappings and exports the resultant content model.


Figure 56: UC-MGT-2 Interaction Diagram

4.1.3 Profile Monitoring Tool Interaction Diagrams

4.1.3.1 Use Case: UC-PMT-1 Trace the Execution of a Specific Profile

The interaction diagram for “UC-PMT-1 Trace the Execution of a Specific Profile” is shown in Figure

57. As shown in the figure, Profile Execution Engine sends the monitoring messages to Profile

Monitoring Tool through Monitoring Tool Interface. Profile Monitoring Tool processes the

monitoring message and displays completed tasks, currently running tasks, bottlenecks and

incomplete tasks to the user through Profile Monitoring Tool GUI. Furthermore, Profile Monitoring

Tool saves the monitoring messages as log for future control and access.


Figure 57: UC-PMT-1, UC-PMT-2, UC-PMT-3, UC-PMT-4, UC-PMT-5 and UC-PMT-6 Interaction

Diagram

4.1.3.2 Use Case: UC-PMT-2 Display Completed Tasks

The interaction diagram for “UC-PMT-2 Display Completed Tasks” is the same as the UC-PMT-1’s

and shown in Figure 57. As shown in the figure, Profile Monitoring Tool displays the completed tasks

of currently executed profile to the user through Profile Monitoring Tool GUI.

4.1.3.3 Use Case: UC-PMT-3 Display Currently Running Tasks

The interaction diagram for “UC-PMT-3 Display Currently Running Tasks” is the same as the UC-

PMT-1’s and shown in Figure 57. As shown in the figure, Profile Monitoring Tool displays the

currently running tasks of currently executed profile to the user through Profile Monitoring Tool GUI.

4.1.3.4 Use Case: UC-PMT-4 Display Bottlenecks

The interaction diagram for “UC-PMT-4 Display Bottlenecks” is the same as the UC-PMT-1’s and

shown in Figure 57. As shown in the figure, Profile Monitoring Tool displays the bottlenecks of

currently executed profile to the user through Profile Monitoring Tool GUI.

4.1.3.5 Use Case: UC-PMT-5 Display Incomplete Tasks

The interaction diagram for “UC-PMT-5 Display Incomplete Tasks” is the same as the UC-PMT-1’s

and shown in Figure 57. As shown in the figure, Profile Monitoring Tool displays the incomplete

tasks of currently executed profile to the user through Profile Monitoring Tool GUI.

4.1.3.6 Use Case: UC-PMT-6 Display Pending Tasks

The interaction diagram for “UC-PMT-6 Display Pending Tasks” is the same as the UC-PMT-1’s and

shown in Figure 57. As shown in the figure, Profile Monitoring Tool displays the pending tasks of

currently executed profile to the user through Profile Monitoring Tool GUI.


4.1.4 Profile Definition and Specialization Tool Interaction Diagrams

4.1.4.1 Use Case: UC-PDST-1 Define Actors of a Profile

The interaction diagram for “UC-PDST-1 Define Actors of a Profile” is shown in Figure 58. As

shown in the figure, Domain Expert defines the actors of a profile to be created through Profile

Definition Tool GUI and saves the defined actors for the next steps. Profile definition consists of three

steps and actor definition is the first step of profile definition process. The sequence diagram below

contains all these three steps which are actor definition, message definition and transaction definition.

At the end of these three steps, Domain Expert saves the defined profile to the Profile Repository

through Profile Repository Interface.

Figure 58: UC-PDST-1, UC-PDST-2, and UC-PDST-3 Interaction Diagram

4.1.4.2 Use Case: UC-PDST-2 Define Messages of a Profile

The interaction diagram for “UC-PDST-2 Define Messages of a Profile” is the same as the UC-PDST-

1’s and shown in Figure 58. As shown in the figure, after Domain Expert defines and saves the actors,

he defines the messages between actors and saves them for the next steps.

4.1.4.3 Use Case: UC-PDST-3 Define Transactions of a Profile

The interaction diagram for “UC-PDST-3 Define Transactions of a Profile” is the same as the UC-

PDST-1’s and shown in Figure 58. As shown in the figure, after Domain Expert defines and saves the


messages between actors, he defines the orders of messages and finishes the profile definition process.

Defined profile is saved to the Profile Repository through Profile Repository Interface.

4.1.4.4 Use Case: UC-PDST-4 Specialize Generic Profile to a Specific Case

The interaction diagram for “UC-PDST-4 Specialize Generic Profile to a Specific Case” is shown in

Figure 59. As shown in the figure, Domain Expert first retrieves the profile to be customized for a

specific organization or incident from Profile Repository through Profile Specialization Tool GUI.

Domain Expert assigns specific organizations as actors by using Profile Specialization Tool and saves

the specialized profile to Specialized Profile Repository.

Figure 59: UC-PDST-4 Interaction Diagram

4.1.5 Security and Privacy Tool Interaction Diagrams

4.1.5.1 Use Case: UC-SPT-1 Authorization

The interaction diagrams for “UC-SPT-1 Authorization” are shown in Figure 60 and Figure 61. As

shown in Figure 60, Administrator of C2-SENSE system retrieves the account of which he is going to

change permissions from Account Repository through Account Repository Interface. After account is

retrieved, administrator changes the account permissions through Authorization Manager Interface

and saves/updates the account with its new permissions.


Figure 60: UC-SPT-1 Interaction Diagram - 1

As shown in Figure 61, for each operation performed by the user, C2-SENSE system checks the

account’s permission to check whether user is allowed to perform related action or not. When an

operation is performed, Authorization Manager is asked to check account’s permission through

Authorization Manager Interface. Authorization Manager retrieves the related account from Account

Repository and checks its permissions. Authorization Manager saves each operation as a log for future

control and access.

Figure 61: UC-SPT-1 Interaction Diagram – 2

4.1.5.2 Use Case: UC-SPT-2 Integrity

The interaction diagram for “UC-SPT-2 Integrity” is shown in Figure 62. As shown in the figure, data

is sent to Certificate Authority Mechanism and Encryption Manager through Encryption Manager

Interface before it is sent through network. When data is received, Certificate Authority Mechanism

generates an encrypted hash and certificate, and signs the data (Details are in UC-SPT-3). Encryption

Manager then encrypts the data and data gets ready to be sent through network. Furthermore,

Encryption Manager saves encryption log for future control and access.


Figure 62: UC-SPT-2 and UC-SPT-3 Interaction Diagram

4.1.5.3 Use Case: UC-SPT-3 Usage of Certificates

The interaction diagram for “UC-SPT-3 Usage of Certificates” is the same as the UC-SPT-2’s and

shown in Figure 62. As shown in the figure, data is signed by Certificate Authority Mechanism by

generating encrypted hash and certificate.

4.1.5.4 Use Case: UC-SPT-4 Authentication

The interaction diagram for “UC-SPT-4 Authentication” is shown in Figure 63. As shown in the

figure, user logs in/out of the C2-SENSE system through Authentication GUI. After user sends his

credentials, Authentication Mechanism validates the incoming data through Certificate Authority

Mechanism. Authentication Mechanism then retrieves the related account from Account Repository

through Account Repository Interface and validates user credentials.

Figure 63: UC-SPT-4 Interaction Diagram


4.1.6 Conformance and Interoperability Testing Mechanism Interaction

Diagrams

4.1.6.1 Use Case: UC-CITM-1 Provide Web Based Graphical Environment

The interaction diagram for “UC-CITM-1 Provide Web Based Graphical Environment” is shown in

Figure 64. As shown in the figure, user executes tests through Test Execution GUI which uses Test

Execution Engine as the controller class. Test Execution Engine sends test execution messages to Test

Execution Monitoring Tool through Test Execution Monitoring Interface during the test execution.

Test Execution Monitoring Tool processes the test execution message and displays detailed log

information and error location to the user through Test Execution Monitoring GUI. Furthermore, Test

Execution Monitoring Tool saves the test execution messages as a test report for future control and

access.

Figure 64: UC-CITM-1, UC-CITM-5, and UC-CITM-6 Interaction Diagram

4.1.6.2 Use Case: UC-CITM-2 Provide Emergency Test Scenario

The interaction diagram for “UC-CITM-2 Provide Emergency Test Scenario” is shown in Figure 65.

As shown in the figure, Test Designer first creates the test scenario through Test Scenario Creator.

Then he simulates the missing roles in the scenario through Test Scenario Adapter (Details are in UC-

CITM-3). At last, Test Designer saves the created test scenario to the Test Scenario Repository for the

users to execute it later.

Figure 65: UC-CITM-2 and UC-CITM-3 Interaction Diagram


4.1.6.3 Use Case: UC-CITM-3 Simulate Missing Roles in the Scenario

The interaction diagram for “UC-CITM-3 Simulate Missing Roles in the Scenario” is the same as the

UC-CITM-2’s and shown in Figure 65. As shown in the figure, Test Designer simulates the missing

roles in the scenario by connecting necessary adapters through Test Scenario Adapter.

4.1.6.4 Use Case: UC-CITM-4 Execute Test Scenario

The interaction diagram for “UC-CITM-4 Execute Test Scenario” is shown in Figure 66. As shown in

the figure, user retrieves the emergency test scenario to be executed from Test Scenario Repository

through Test Execution GUI. After test scenario is retrieved, he initiates the test execution process

through Test Execution Engine. During the execution process, Test Execution Engine captures the

messages exchanged between parties and verifies them semantically and validates them syntactically

(Details are in UC-CITM-9 and UC-CITM-10). Furthermore, Test Execution Engine creates and

saves test execution messages for Test Execution Monitoring Tool to display them to the user.

Figure 66: UC-CITM-4, UC-CITM-7, UC-CITM-8, UC-CITM-9, and UC-CITM-10 Interaction Diagram

4.1.6.5 Use Case: UC-CITM-5 Display Detailed Log Information

The interaction diagram for “UC-CITM-5 Display Detailed Log Information” is the same as the UC-

CITM-1’s and shown in Figure 64. As shown in the figure, test execution messages created by Test

Execution Engine are provided to Test Execution Monitoring Tool. Test Execution Monitoring Tool

processes the test execution messages and displays the detailed information to the user through Test

Execution Monitoring GUI.

4.1.6.6 Use Case: UC-CITM-6 Display Error Location

The interaction diagram for “UC-CITM-6 Display Error Location” is the same as the UC-CITM-1’s

and shown in Figure 64. As shown in the figure, test execution messages created by Test Execution

Engine are provided to Test Execution Monitoring Tool. Test Execution Monitoring Tool processes

the test execution messages and displays error location of failed tests to the user through Test

Execution Monitoring GUI.

4.1.6.7 Use Case: UC-CITM-7 Automate Whole Testing Process

The interaction diagram for “UC-CITM-7 Automate Whole Testing Process” is the same as the UC-

CITM-4’s and shown in Figure 66. There is actually no specific flow of events for this use case in the

figure but Test Execution Engine will be responsible for executing the test scenario automatically.


4.1.6.8 Use Case: UC-CITM-8 Capture Messages Exchanged Between Parties

The interaction diagram for “UC-CITM-8 Capture Messages Exchanged Between Parties” is the same

as the UC-CITM-4’s and shown in Figure 66. As shown in the figure, after Test Execution Engine is

asked to initiate the test execution process, it captures the messages exchanged between parties to feed

them into Semantic Verification Mechanism and Syntactic Validation Mechanism for conformance

and interoperability testing.

4.1.6.9 Use Case: UC-CITM-9 Verify Emergency Messages and Document Semantically

The interaction diagram for “UC-CITM-9 Verify Emergency Messages and Documents Semantically”

is the same as the UC-CITM-4’s and shown in Figure 66. As shown in the figure, Test Execution

Engine captures the messages exchanged between parties and verifies them semantically through

Semantic Verification Mechanism.

4.1.6.10 Use Case: UC-CITM-10 Validate Emergency Messages and Documents Syntactically

The interaction diagram for “UC-CITM-10 Validate Emergency Messages and Documents

Syntactically” is the same as the UC-CITM-4’s and shown in Figure 66. As shown in the figure, Test

Execution Engine captures the messages exchanged between parties and validates them syntactically

through Syntactic Validation Mechanism.

4.1.7 Enterprise Service Bus Interaction Diagrams

4.1.7.1 Use Case: UC-ESB-1 Add New Rule

The interaction diagram for “UC-ESB-1 Add New Rule” is shown in Figure 67. As shown in the

figure, ESB Admin adds a new rule through the Rule Manager Form. New rule is added to ESB.

Figure 67: UC-ESB-1 Interaction Diagram

4.1.7.2 Use Case: UC-ESB-2 Modify ESB Rule

The interaction diagram for “UC-ESB-2 Modify ESB Rule” is shown in Figure 68. As shown in the

figure, ESB Admin modifies the rule through Rule Manager Form. Rule is modified on ESB.



4.1.7.3 Use Case: UC-ESB-3 Delete ESB Rules

The interaction diagram for “UC-ESB-3 Delete ESB Rules” is shown in Figure 69. As shown in the

figure, ESB Admin deletes the rule through Rule Manager Form. Rule is deleted from ESB.


4.1.7.4 Use Case: UC-ESB-4 Monitor Network Traffic & UC-ESB-5 View System Logs

The interaction diagram for “UC-ESB-4 Monitor Network Traffic” and “UC-ESB-5 View System

Logs” is shown in Figure 70. As shown in the figure, ESB Admin monitors the system and network

traffic through System Traffic Logger.

Figure 70: UC-ESB-4 and UC-ESB-5 Interaction Diagram


4.1.7.5 Use Case: UC-ESB-6 Register New Service on ESB

The interaction diagram for “UC-ESB-6 Register New Service on ESB” is shown in Figure 71. As

shown in the figure, ESB admin adds new service through Service Manager Form. New service is

added.


4.1.7.6 Use Case: UC-ESB-7 View Registered Service

The interaction diagram for “UC-ESB-7 View Registered Service” is shown in Figure 72. As shown

in the figure, ESB Admin views registered service through Service Manager Form.


4.1.7.7 Use Case: UC-ESB-8 Delete Registered Service

The interaction diagram for “UC-ESB-8 Delete Registered Service” is shown in Figure 73. As shown

in the figure, ESB Admin deletes service through Service Manager Form. Service is deleted.



4.1.7.8 Use Case: UC-ESB-9 Send Message

The interaction diagram for “UC-ESB-9 Send Message” is shown in Figure 74. As shown in the

figure, ESB Connected System sends a message through Service Manager Form. Message is sent to

the connected system.


4.1.7.9 Use Case: UC-ESB-10 Receive Message

The interaction diagram for “UC-ESB-10” is shown in Figure 75. As shown in the figure, ESB

Connected System receives message through Service Manager Form. Message is retrieved from the

connected system.



4.1.8 Message Communication Platform Interaction Diagrams

4.1.8.1 Use Cases: UC-MCP-1 Add User to Topic & UC-MCP-2 Create Role & UC-MCP-3

Assign Role

The interaction diagram for “UC-MCP-1 Add User to Topic”, “UC-MCP-2 Create Role”, and “UC-

MCP-3 Assign Role” is shown in Figure 76. As shown in the figure, Domain Expert creates role using

Role Creator Form. After that, by using User And Role Creator, Domain Expert adds user to a topic

with an existent role through the two separated given forms, which are User To Topic Adder Form

and Role Assigner Form.

Figure 76: UC-MCP-1, UC-MCP-2 and UC-MCP-3 Interaction Diagram

4.1.8.2 Use Case: UC-MCP-4 Deleting User from Topic

The interaction diagram for “UC-MCP-4 Deleting User from Topic” is shown in Figure 77. As shown

in the figure, Domain Expert deletes user from topic through User From Topic Deleter Form.

Figure 77: UC-MCP-4 Interaction Diagram


4.1.8.3 Use Case: UC-MCP-5 Un-subscription from Topic

The interaction diagram for “UC-MCP-5 Un-subscription from Topic” is shown in Figure 78. As

shown in the figure, MCP User un-subscribes from topic through Topic Unsubscriber Interface.


4.1.8.4 Use Case: UC-MCP-6 Send Message

The interaction diagram for “UC-MCP-6 Send Message” is shown in Figure 79. As shown in the

figure, MCP User sends message to connected system through Communication Handler Form.


4.1.8.5 Use Case: UC-MCP-7 Receive Message

The interaction diagram for “UC-MCP-7 Receive Message” is shown in Figure 80. As shown in the

figure, MCP User receives message sent by connected system through Communication Handler Form.



4.1.9 Data Integrators Interaction Diagrams

4.1.9.1 Use Case: UC-DI-1 Receiving Events & UC-DI-2 Validating Format & UC-DI-3

Converting Data Format

The interaction diagram for “UC-DI-1 Receiving Events”, “UC-DI-2 Validating Format”, and “UC-

DI-3 Converting Data Format” is shown in Figure 81. As shown in the figure, message is received by

Message Receiver and validated by Message Validator. After that, if it is necessary, message is

modified to obtain the correct format by Message Modifier.

Figure 81: UC-DI-1, UC-DI-2, and UC-DI-3 Interaction Diagram

4.1.9.2 Use Case: UC-DI-4 Forwarding Formatted Data to the ESB

The interaction diagram for “UC-DI-4 Forwarding Formatted Data to the ESB” is shown in Figure 82.

As shown in the figure, message is sent from Data Integrators (DI) to Enterprise Service Bus (ESB)

through Message Sender.


Figure 82: UC-DI-4 Interaction Diagram

4.1.10 Profile Execution Engine Interaction Diagrams

4.1.10.1 Use Case: UC-PEE-1 Import Emergency Profile

The interaction diagram for “UC-PEE-1 Import Emergency Profile” is shown in Figure 83. As shown

in the figure, PEE Admin uploads the received emergency profile through the Emergency Profile

Uploader Form. Then he fills the Emergency Profile Form by inserting further requested profile data.

The uploaded file and the profile data are imported to the system.

Figure 83: UC-PEE-1 Interaction Diagram

4.1.10.2 Use Case: UC-PEE-2 Delete Emergency Profile

The interaction diagram for “UC-PEE-2 Delete Emergency Profile” is shown in Figure 84. As shown

in the figure, PEE Admin selects the emergency profile to be deleted through the dedicated form and

confirms the operation. The emergency profile is deleted from the system.



4.1.10.3 Use Case: UC-PEE-3 Start Process

The interaction diagram for “UC-PEE-3 Start Process” is shown in Figure 85. As shown in the figure,

PEE Admin selects the process of emergency profile to be started from the Process Starter Form, or

the C2-SENSE User starts the process by triggering an activity. The process is started.



4.1.11 Web Service Creator Tool Interaction Diagrams

4.1.11.1 Use Case: UC-WSCT-1 Create a Service for a Given Legacy System

All interactions with the user of tool go through the WSCT_GUI. All works are effectively done by

the Web Service Creator (acting as controller). This element is in charge of creating the various

instances in the data model (not shown on the sequence diagram) as the queries, the services, and so

on. To create a service, the user has to first select the concerned external system, and then create the

query. After that, he can create the service and set its query. Once that is all done, the service can be

started (see Figure 86).

Figure 86: UC-WSCT-1 Interaction Diagram

4.1.11.2 Use Case: UC-WSCT-2 Install the WSC Tool

The main work of this use case is external to the tool: Communication with the users, running the

installer, etc. The point is that the installer has to exist and that the services’ status should be recorded

so as to restart the right services and not all declared services (see Figure 87).



4.1.11.3 Use Case: UC-WSCT-3 Start the WSC Tool

No sequence diagram is provided here. However, the following steps should be respected:

1. The controller is the first to be instantiated

2. The controller instantiates the WSCT_GUI and the data model

3. The start command on the GUI restarts the services if appropriate

4.1.11.4 Use Case: UC-WSCT-4 Log into the Tool

The login sequence is initiated by the user, once for each session. User has to provide his username

and password. This information is used to verify credentials (see Figure 88).



4.1.11.5 Use Case: UC-WSCT-5 Upgrade the Interface of a Legacy System

The sequence diagram in Figure 89 shows an example sequence in case of an error on the interface of

the legacy system. The first obvious variation appears when the interface change is scheduled.

Actually, this should be the nominal case, even if it is often the second in occurrences in real life. In

that case, the C2-SENSE system administrator should study the impact of the change, and take care of

preventive actions, which may contain:

- Doing nothing (The change is minor, concerns unused features, or is already taken into

account by the system)

- Changing/upgrading the connector

- Changing/upgrading the WSC Tool (Major change in the interface needs changes in the

configuration)

- Modification of the procedures and modification of the services (The services offered by the

legacy system are changed and it impacts its roles in the system)

- Changing the whole system (Impact on the profiles)

The second variation is when some of the above actions are necessary (Changing connector,

upgrading the tool, changing the profiles). In that case, the nominal case goes in error and the C2-

SENSE system administrator is solicited to proceed to an analysis.

It should also be noted that the way the alert is raised to the user can be either proactive

(Publish/subscribe paradigm, using for example a SMS or a dynamic alert on the GUI – which means

that the GUI is open) or passive, in which case the user will be informed next time he attempts to

connect to the system. The diagram below takes for true that the alert can be provided through a tier

system, proactively.



4.1.11.6 Use Case: UC-WSCT-6 Upgrade the Profiles

Many profile changes should not impact the WSCT. The WSCT is impacted if the profiles declare/use

new services that can be declared by existing and already connected systems. The WSCT is not

necessarily impacted if services are not used any more, since unused services can run unsolicited with

no harm to the system (until the legacy system’s interface changes to make it impossible to provide).

Changes in the order of operations in services should have no impact on WSCT. The main flow is as

follows:

- The system administrator changes the profiles.

- The system administrator notes that there is an impact on existing services. S/he informs the

WSCT user.

- The WSCT user edits the services to render the services (see UC-WSCT-5). If not possible,

he informs the system administrator that the underlying layers or the available legacy systems

do not allow him to declare such services.

4.1.12 Emergency Maps Creator Tool Interaction Diagrams

4.1.12.1 Use Case: UC-EM-1 Provide a Common Operational Picture of the Crisis Situation

The interaction diagram for the use case is shown in Figure 90. The figure shows that the Domain

User imports the data graphically through the Emergency Maps Tool GUI. The imported data is

automatically validated by the Emergency Maps Tool, and the validation message is provided to the

Domain User. The data is then saved to the Common Situation Information Resource by the Situation

Information Repository after the request through the Situation Information Repository Interface.

Figure 90: UC-EM-1 Interaction Diagram

4.1.12.2 Use Case: UC-EM-2 Support Decision Making Process


User activates the support of decision making process through the Emergency Maps Tool GUI, which

uses the Emergency Maps Tool as control class. Furthermore, the Domain User selects the Actor Type

in the Emergency Maps Tool GUI, and the control class validates if the Domain User has the

permission to be the selected Actor Type. The message is then provided back to the Domain User.



4.1.12.3 Use Case: UC-EM-3 Display Emergency Area to User

The interaction diagram for the use case is shown in Figure 92. Domain User invokes the Emergency

Maps Tool GUI to show the default map. The Emergency Maps Tool renders the default map and the

map is displayed to the Domain User through Emergency Maps Tool GUI.



4.1.12.4 Use Case: UC-EM-4 Show Maps and Situation Information

The interaction diagram for the use case is shown in Figure 93. Domain User invokes the Emergency

Maps Tool GUI to provide the available maps. The list is provided by the Knowledge Layer classes

and the Domain User chooses the appropriate map. The Domain User activates the GIS data to

overlay the map with the situation information. The Knowledge Layer provides the situation data, and

the MashUp Tool classes render the map and the data to a situation picture. The situation is displayed

to the Domain User through the Emergency Maps Tool GUI. Moreover, the displayed data can be

filtered.


4.1.12.5 Use Case: UC-EM-5 Track the Emergency Situation User Actions

The interaction diagram for the use case is shown in Figure 94. The activation of the C2-SENSE

Collaboration Environment activates this use case (i.e. it is its default setup). The Emergency Activity

Data Repository Tool (and its Interface) records and saves the activities and data to the Emergency

Activity Data Repository. This is not merely a log, but a repository that allows user to re-run at a later

time. The Domain User will be informed through the Emergency Maps Tool GUI that the recording is

initialized.


Furthermore, the Domain User can de-activate the action. De-activation will be confirmed to the user.

Both of these actions are handled via the Emergency Maps Tool GUI.


4.1.12.6 Use Case: UC-EM-6 Analyze the Emergency Situation User Actions

The interaction diagram for the use case is shown in Figure 95. The Domain User activates the

analysis of a past emergency situation actions through the Emergency Maps Tool GUI. The list is

given upon request, where the available activity data is located in the Emergency Activity Data

Repository. The Domain User can then select the appropriate activity data (based on a date or

emergency ID), and activate the play commands (play, stop, pause, decrease/increase pace, etc.). The

Domain User can also deactivate play-commands. Selected activity data will still be available.



4.1.13 GIS Server Interaction Diagrams

4.1.13.1 Use Case: UC-GS-1 Share and Edit Geospatial Data


User imports the data graphically through the GIS Server GUI. The imported data is automatically

validated by the GIS Server class. The data is then saved to the Geospatial Resource Repository

through Geospatial Resource Repository Interface. The data in the Geospatial Resource Repository

can also be accessed and edited by the Domain User.


Figure 96: UC-GS-1 Interaction Diagram

4.1.13.2 Use Case: UC-GS-2 Extract Spatial Information from Semantic Information

Interoperability Layer


User can update the GIS Server information by execution extraction command of the spatial data

through the GIS Server GUI. The extraction process happens in the Semantic Interoperability Layer,

where the metadata is analyzed, then sent back to the GIS Server. There, the geospatial data is

updated based on the new semantic input.



4.1.13.3 Use Case: UC-GS-3 Deliver Geo-Referenced Information from Different Sources


User requests synchronization with different servers through the GIS Server GUI. The

synchronization process happens in Geo Servers which sends back the geospatial data. GIS Server

updates the information.


4.1.13.4 Use Case: UC-GS-4 Provide Background Maps for the Geo-Referenced Presentation

of Relevant Data


User requests geo-referenced map through the GIS Server GUI. The GIS Server interfaces with the

Maps Server and receives a map. The map is rendered with the feature data already presented on the

GIS Server, and the overlaid image is displayed on the GIS Server GUI. The Domain User zooms on

the map, or filters the features to be shown.



4.1.14 Sensor Protocol Adapter Tool Interaction Diagrams

4.1.14.1 Use Case: UC-SP-1 Sensor Management for Many Sensors

The interaction diagram for the use case is shown in Figure 100. Domain User invokes the Sensor

Management Tool GUI to list the available sensors. The Sensor Management Tool searches for

available and connected sensors, and provides the GUI with the list. Moreover, the Domain User can

add new sensor via the Sensor Management Tool GUI.


Figure 100: UC-SP-1 Interaction Diagram

4.1.14.2 Use Case: UC-SP-2 Plug and Measure

The interaction diagram for the use case is shown in Figure 101. In this use case, the Sensors activate

sensor detection through PnP Sensor Detection Tool Interface, and the PnP Sensor Detection Tool

detects the appropriate sensor type. Thereafter, the AnySen Tool configures the appropriate driver for

the detected sensor.


4.1.14.3 Use Case: UC-SP-3 Gather Real-Time Data

The interaction diagram for the use case is shown in Figure 102. In this use case, the Domain User

activates sensor input stream through Sensor Management Tool GUI. The sensor data is collected and

the sensor data stream is activated and collected by the Sensor Management Tool.



4.1.14.4 Use Case: UC-SP-4 User Management of Sensors and Input

The interaction diagram for the use case is shown in Figure 103. In this use case, the Domain User

controls the sensors (selects, activates), and controls the sensor data output. The Domain User can

activate one sensor and select the desired data range output, filter, etc.



4.1.15 Collaboration Tool Interaction Diagrams

4.1.15.1 Use Case: UC-CE-1 Combination of Maps with Content Information from Different

(Information) Sources

For information on this use case, we refer to use cases UC-GS-2 Extract Spatial Information from

Semantic Information Interoperability Layer and UC-GS-3 Deliver Geo-Referenced Information

from Different Sources.

4.1.15.2 Use Case: UC-CE-2 Visualize Crisis Situation

For information on this use case, we refer to use cases UC-EM-3 Display Emergency Area to User

and UC-EM-4 Show Maps and Situation Information.

4.1.15.3 Use Case: UC-CE-3 Provide Information for Decision Making Process

For information on this use case, we refer to use cases UC-EM-1 Provide a Common Operational

Picture of the Crisis Situation and UC-EM-2 Support Decision Making Process.

4.1.15.4 Use Case: UC-CE-4 Provide Map Data and Content Information for Emergency Maps

Tool

For information on this use case, we refer to use cases UC-EM-3 Display Emergency Area to User

and UC-EM-4 Show Maps and Situation Information.

4.1.15.5 Use Case: UC-CE-5 Gather User Input to Track the Changes of Crisis Situation

For information on this use case, we refer to the use case UC-GS-1 Share and Edit Geospatial Data.

4.1.16 C2-SENSE Gateway Interaction Diagrams

4.1.16.1 Use Case: UC-C2SG-1 Connect Data from External System/Data Source & UC-C2SG-

2 Send Data in Unified Form to Enterprise Service Bus

The interaction diagram for the use case is shown in Figure 104. C2-SENSE Gateway is a C2-SENSE

system component which communicates with Enterprise Service Bus. The main role of the C2-

SENSE Gateway is to provide universal communication service over heterogeneous physical network

in order to physically interconnect external application or networks with C2-SENSE network. C2-

SENSE Gateway applies data aggregation and filtering configuration in order to start data pre-

processing to unified C2-SENSE data format in order to establish communication with Enterprise

Service Bus. Each Enterprise Service Bus interface, implemented as web service, applies the

appropriate data acquisition configuration and communicates with the intended data source through

interfaces based on domain specific standards and predefined procedures in order to harvest any

relevant data and/or metadata.


Figure 104: UC-C2SG-1 and UC-C2SG-2 Interaction Diagram

4.2 Design Class Diagrams

4.2.1 Emergency Ontology Creator Tool Class Diagrams

Figure 105: Ontology Resource Editor GUI Design Class

The operations of the Ontology Resource Editor GUI class (Figure 105) are as follows:

- defineSearchCriteria: defines a search criteria

- searchOntologyResources: searches Ontology Resources according to search criteria

- getOntologyResources: retrieves Ontology Resources

- selectOntologyResources: selects Ontology Resources

- getDetailsOfOntologyResources: retrieves the details of selected Ontology Resources

Figure 106: Ontology Resource Editor Design Class


The operations of the Ontology Resource Editor class (Figure 106) are as follows:

- searchOntologyResources: searches Ontology Resources according to search criteria

- getOntologyResources: retrieves Ontology Resources

- selectOntologyResources: selects Ontology Resources

- getDetailsOfOntologyResources: retrieves the details of selected Ontology Resources

Figure 107: Ontology Resource Repository Interface Design Class

The operations of the Ontology Resource Repository Interface class (Figure 107) are as follows:

- saveOntologyResources: saves Ontology Resources to the repository

- getOntologyResources: retrieves Ontology Resources from the repository

- updateOntologyResources: updates Ontology Resources in the repository

- deleteOntologyResources: removes Ontology Resources from the repository

- searchOntologyResources: retrieves Ontology Resources matching the search criteria from

the repository

Figure 108: Ontology Resource Repository Design Class

The operations of the Ontology Resource Repository class (Figure 108) are as follows:

- saveOntologyResources: saves Ontology Resources to the repository

- getOntologyResources: retrieves Ontology Resources from the repository

- updateOntologyResources: updates Ontology Resources in the repository

- deleteOntologyResources: removes Ontology Resources from the repository

Figure 109: Content Model Importer GUI Design Class


The operations of the Content Model Importer GUI class (Figure 109) are as follows:

- importContentModel: imports the Content Model graphically

Figure 110: Content Model Importer Design Class

The operations of the Content Model Importer class (Figure 110) are as follows:

- importContentModel: imports the Content Model

- parseContentModel: parses the Content Model

- analyzeContentModel: analyzes the parsed Content Model to find and create Ontology

Resources

- createOntologyResources: creates the Ontology Resources

Figure 111: Ontology Editor GUI Design Class

The operations of the Ontology Editor GUI class (Figure 111) are as follows:

- exportOntology: generates the Ontology

- addRelation: adds new relation to the Ontology

- editRelation: edits existing relation in the Ontology

- deleteRelation: removes relation from the Ontology

Figure 112: Ontology Editor Design Class

The operations of the Ontology Editor class (Figure 112) are as follows:

- exportOntology: generates the Ontology

- convertToOntology: converts Ontology Resources to Ontology

- addRelation: adds new relation to the Ontology


- editRelation: edits existing relation in the Ontology

- deleteRelation: removes relation from the Ontology

- constituteOntology: constitutes the Ontology with complete relations

Figure 113: DL Reasoner Design Class

The operations of the DL Reasoner class (Figure 113) are as follows:

- findRelations: finds relations between similar attributes of entities in the Ontology

Figure 114: Ontology Repository Interface Design Class

The operations of the Ontology Repository Interface class (Figure 114) are as follows:

- addOntology: adds Ontology to the repository

- getOntology: retrieves Ontology matching the search criteria or with specified id from the

repository

- editOntology: edits Ontology in the repository

- deleteOntology: removes Ontology from the repository

Figure 115: Ontology Repository Design Class

The operations of the Ontology Repository class (Figure 115) are as follows:

- addOntology: adds Ontology to the repository

- getOntology: retrieves Ontology matching the search criteria or with specified id from the

repository

- editOntology: edits Ontology in the repository

- deleteOntology: removes Ontology from the repository


4.2.2 Mapping Generator Tool Class Diagrams

Figure 116: Mapping Generator Interface Design Class

The operations of the Mapping Generator Interface class (Figure 116) are as follows:

- defineMappingRule: defines mapping rule between two Ontologies

- editMappingRule: edits existing mapping rule between two Ontologies

- deleteMappingRule: removes mapping rule between two Ontologies

Figure 117: Mapping Generator Design Class

The operations of the Mapping Generator class (Figure 117) are as follows:

- defineMappingRule: defines mapping rule between two Ontologies

- editMappingRule: edits existing mapping rule between two Ontologies

- deleteMappingRule: removes mapping rule between two Ontologies

Figure 118: Local Domain Ontology Importer GUI Design Class

The operations of the Local Domain Ontology Importer GUI class (Figure 118) are as follows:

- importLocalDomainOntology: imports the Ontology

Figure 119: Converter Engine GUI Design Class


The operations of the Converter Engine GUI class (Figure 119) are as follows:

- importContentModel: imports the Content Model to be converted to another

- exportContentModel: exports the converted Content Model

- getMapping: retrieves the mapping between Content Model and C2-SENSE Harmonized

Ontology

- convert: converts the Content Model to another according to mapping rules

Figure 120: Converter Engine Design Class

The operations of the Converter Engine class (Figure 120) are as follows:

- importContentModel: imports the Content Model to be converted to another

- exportContentModel: exports the converted Content Model

- convert: converts the Content Model to another according to mapping rules

Figure 121: Mapping Repository Interface Design Class

The operations of the Mapping Repository class (Figure 121) are as follows:

- addMapping: adds new mapping to the repository

- getMapping: retrieves mapping with content model ID and ontology ID from the repository

- updateMapping: updates existing mapping in the repository

- deleteMapping: removes mapping from the repository

Figure 122: Mapping Repository Design Class

The operations of the Mapping Repository class (Figure 122) are as follows:

- addMapping: adds new mapping to the repository

- getMapping: retrieves mapping with content model ID and ontology ID from the repository

- updateMapping: updates existing mapping in the repository

- deleteMapping: removes mapping from the repository


4.2.3 Profile Monitoring Tool Design Classes

Figure 123: Profile Monitoring Tool GUI Design Class

The operations of the Profile Monitoring Tool GUI class (Figure 123) are as follows:

- displayCompletedTasks: displays completed tasks

- displayCurrentlyRunningTasks: displays currently running tasks

- displayBottlenecks: displays bottlenecks

- displayIncompleteTasks: displays incomplete tasks

- displayPendingTasks: displays pending tasks

Figure 124: Profile Monitoring Tool Interface Design Class

The operations of the Profile Monitoring Tool Interface class (Figure 124) are as follows:

- getMonitoringMessage: retrieves monitoring message from Profile Execution Engine

Figure 125: Profile Monitoring Tool Design Class

The operations of the Profile Monitoring Tool class (Figure 125) are as follows:

- getMonitoringMessage: retrieves monitoring message from Profile Execution Engine

- processMonitoringMessage: parses the monitoring message and displays it to the user

- saveLog: saves related log about monitoring message


4.2.4 Profile Definition and Specialization Tool Design Classes

Figure 126: Profile Definition Tool GUI Design Class

The operations of the Profile Definition Tool GUI class (Figure 126) are as follows:

- createActor: creates an actor of a profile to be created

- editActor: edits the actor

- deleteActor: removes the actor

- saveActor: saves the actor

- createMessage: creates a message between two actors

- editMessage: edits the message between two actors

- deleteMessage: removes the message between two actors

- saveMessage: saves the message

- createTransaction: creates a transaction by ordering messages between actors

- editTransaction: edits the transaction

- deleteTransaction: removes the transaction

- saveTransaction: saves the transaction

- createProfile: creates a profile with ordered messages (transactions) between actors

- editProfile: edits the profile

- deleteProfile: removes the profile

- saveProfile: saves the profile


Figure 127: Profile Definition Tool Design Class

The operations of the Profile Definition Tool class (Figure 127) are as follows:

- createActor: creates an actor of a profile to be created

- editActor: edits the actor

- deleteActor: removes the actor

- saveActor: saves the actor

- createMessage: creates a message between two actors

- editMessage: edits the message between two actors

- deleteMessage: removes the message between two actors

- saveMessage: saves the message

- createTransaction: creates a transaction by ordering messages between actors

- editTransaction: edits the transaction

- deleteTransaction: removes the transaction

- saveTransaction: saves the transaction

- createProfile: creates a profile with ordered messages (transactions) between actors

- editProfile: edits the profile

- deleteProfile: removes the profile

- saveProfile: saves the profile

Figure 128: Profile Repository Interface Design Class


The operations of the Profile Repository Interface class (Figure 128) are as follows:

- getProfile: retrieves profile from the repository

- addProfile: adds new profile to the repository

- editProfile: edits existing profile in the repository

- deleteProfile: removes profile from the repository

Figure 129: Profile Repository Design Class

The operations of the Profile Repository class (Figure 129) are as follows:

- getProfile: retrieves profile from the repository

- addProfile: adds new profile to the repository

- editProfile: edits existing profile in the repository

- deleteProfile: removes profile from the repository

Figure 130: Profile Specialization Tool GUI Design Class

The operations of the Profile Specialization Tool GUI class (Figure 130) are as follows:

- getProfile: retrieves profile

- assignOrganization: assigns the organization as an actor in the profile

- saveSpecializedProfile: saves the specialized profile

Figure 131: Profile Specialization Tool Design Class

The operations of the Profile Specialization Tool class (Figure 131) are as follows:

- assignOrganization: assigns the organization as an actor in the profile

- saveSpecializedProfile: saves the specialized profile


Figure 132: Specialized Profile Repository Interface Design Class

The operations of the Specialized Profile Repository Interface class (Figure 132) are as follows:

- getSpecializedProfile: retrieves specialized profile from the repository

- addSpecializedProfile: adds new specialized profile to the repository

- editSpecializedProfile: edits existing specialized profile in the repository

- deleteSpecializedProfile: removes specialized profile from the repository

Figure 133: Specialized Profile Repository Design Class

The operations of the Specialized Profile Repository class (Figure 133) are as follows:

- getSpecializedProfile: retrieves specialized profile from the repository

- addSpecializedProfile: adds new specialized profile to the repository

- editSpecializedProfile: edits existing specialized profile in the repository

- deleteSpecializedProfile: removes specialized profile from the repository

4.2.5 Security and Privacy Tool Design Classes

Figure 134: Authorization Manager Interface Design Class

The operations of the Authorization Manager Interface class (Figure 134) are as follows:

- checkAccountPermission: checks whether the account has the permission to perform the

operation or not

- changeAccountPermission: changes the account’s permission


Figure 135: Authorization Manager Design Class

The operations of the Authorization Manager class (Figure 135) are as follows:

- checkAccountPermission: checks whether the account has the permission to perform the

operation or not

- changeAccountPermission: changes the account’s permission

- checkAccountPolicy: checks the account’s policy

- saveAuthorizationLog: saves related log about authorization operations

Figure 136: Authentication GUI Design Class

The operations of the Authentication GUI class (Figure 136) are as follows:

- login: allows user to login to the system

- logout: allows user to logout from the system

Figure 137: Authentication Mechanism Design Class

The operations of the Authentication Mechanism class (Figure 137) are as follows:

- login: allows user to login to the system

- logout: allows user to logout from the system

Figure 138: Encryption Manager Interface Design Class

The operations of the Encryption Manager Interface class (Figure 138) are as follows:

- encryptData: encrypts the data


Figure 139: Encryption Manager Design Class

The operations of the Encryption Manager class (Figure 139) are as follows:

- encryptData: encrypts the data

- saveEncryptionLog: saves related log about encryption operation

Figure 140: Certificate Authority Mechanism Design Class

The operations of the Certificate Authority Mechanism class (Figure 140) are as follows:

- signData: signs the data with generated encrypted hash

- generateEncryptedHash: generates an encrypted hash

- generateCertificate: generates certificate for Certificate Authority

- validateData: validates the data

Figure 141: Account Repository Interface Design Class

The operations of the Account Repository Interface class (Figure 141) are as follows:

- getAccount: retrieves account from the repository

- addAccount: adds new account to the repository

- editAccount: edits existing account in the repository

- deleteAccount: removes account from the repository


Figure 142: Account Repository Design Class

The operations of the Account Repository class (Figure 142) are as follows:

- getAccount: retrieves account from the repository

- addAccount: adds new account to the repository

- editAccount: edits existing account in the repository

- deleteAccount: removes account from the repository

4.2.6 Conformance and Interoperability Testing Mechanism Design Classes

Figure 143: Test Execution Monitoring GUI Design Class

The operations of the Test Execution Monitoring GUI class (Figure 143) are as follows:

- displayDetailedLogInformation: displays detailed log information about tests that are being

executed

- displayErrorLocation: displays error location of failed tests

Figure 144: Test Execution Monitoring Interface Design Class

The operations of the Test Execution Monitoring Interface class (Figure 144) are as follows:

- getTestExecutionMessage: retrieves the test execution message from Test Execution Tool

Figure 145: Test Execution Monitoring Tool Design Class


The operations of the Test Execution Monitoring Tool class (Figure 145) are as follows:

- getTestExecutionMessage: retrieves the test execution message from Test Execution Tool

- processTestExecutionMessage: processes the test execution message and displays it to the

user

- saveTestReport: generates a test report about tests that are being executed

Figure 146: Test Scenario Repository Interface Design Class

The operations of the Test Scenario Repository Interface class (Figure 146) are as follows:

- getTestScenario: retrieves test scenario from the repository

- addTestScenario: adds new test scenario to the repository

- editTestScenario: edits existing scenario in the repository

- deleteTestScenario: removes test scenario from the repository

Figure 147: Test Scenario Repository Design Class

The operations of the Test Scenario Repository class (Figure 147) are as follows:

- getTestScenario: retrieves test scenario from the repository

- addTestScenario: adds new test scenario to the repository

- editTestScenario: edits existing scenario in the repository

- deleteTestScenario: removes test scenario from the repository

Figure 148: Test Scenario Creator Interface Design Class


The operations of the Test Scenario Creator Interface class (Figure 148) are as follows:

- createTestScenario: creates new test scenario

- simulateTestScenario: simulates missing roles in the test scenario by connecting necessary

adapters

- saveTestScenario: saves the test scenario

Figure 149: Test Scenario Creator Design Class

The operations of the Test Scenario Creator class (Figure 149) are as follows:

- createTestScenario: creates new test scenario

- saveTestScenario: saves the test scenario

Figure 150: Test Scenario Adapter Design Class

The operations of the Test Scenario Adapter (Figure 150) are as follows:

- simulateMissingRoles: simulates missing roles in the test scenario by connecting necessary

adapters

Figure 151: Test Execution GUI Design Class

The operations of the Test Execution GUI class (Figure 151) are as follows:

- getTestScenario: retrieves the test scenario

- executeTestScenario: executes the test scenario

Figure 152: Test Execution Engine Design Class


The operations of the Test Execution Engine class (Figure 152) are as follows:

- getTestScenario: retrieves the test scenario

- executeTestScenario: executes the test scenario

- captureMessages: captures messages exchanged between parties in the test scenario that are

being executed

- saveTestExecutionMessage: creates and saves execution message about tests that are being

executed

Figure 153: Semantic Verification Mechanism Design Class

The operations of the Semantic Verification Mechanism class (Figure 153) are as follows:

- verify: verifies the messages and documents semantically

Figure 154: Syntactic Validation Mechanism Design Class

The operations of the Syntactic Validation Mechanism class (Figure 154) are as follows:

- validate: validates the messages and documents syntactically

4.2.7 Enterprise Service Bus Design Classes

Figure 155: Rule Manager Form Design Class

The operations of the Rule Manager Form class (Figure 155) are as follows:

- addRule: adds new rule according to provided data

- modifyRule: modifies the selected rule

- deleteRule: deletes the selected rule


Figure 156: Rule Manager Design Class

The operations of the Rule Manager class (Figure 156) are as follows:

- addRule: adds new rule according to provided data

- modifyRule: modifies the selected rule

- deleteRule: deletes the selected rule

Figure 157: Service Manager Form Design Class

The operations of the Service Manager Form class (Figure 157) are as follows:

- viewService: displays the selected service

- createService: creates a new service according to provided data

- deleteService: deletes the selected service

- sendMessage: sends the message to connected system

- receiveMessage: receives the message from connected system

Figure 158: Service Manager Design Class

The operations of the Service Manager class (Figure 158) are as follows:

- viewService: displays the selected service

- createService: creates a new service according to provided data

- deleteService: deletes the selected service

- sendMessage: sends the message to connected system

- receiveMessage: receives the message from connected system


Figure 159: System Traffic Logger Interface Design Class

The operations of the System Traffic Logger Interface class (Figure 159) are as follows:

- monitorLog: monitors the traffic log

Figure 160: System Traffic Logger Design Class

The operations of the System Traffic Logger class (Figure 160) are as follows:

- monitorLog: monitors the traffic log

4.2.8 Message Communication Platform Design Classes

Figure 161: User To Topic Adder Form Design Class

The operations of the User To Topic Adder Form class (Figure 161) are as follows:

- addUserToTopic: adds the user with userID to the topic with topicID

Figure 162: Role Assigner Form Design Class

The operations of the Role Assigner Form class (Figure 162) are as follows:

- assignRoleToUser: adds role to an existing user

Figure 163: Role Creator Form Design Class


The operations of the Role Creator Form class (Figure 163) are as follows:

- createRole: creates a role

Figure 164: User And Role Creator Design Class

The operations of the User And Role Creator class (Figure 164) are as follows:

- addUserToTopic: adds the user with userID to the topic with topicID

- assignRoleToUser: adds role to an existing user

- createRole: creates a role

Figure 165: User From Topic Deleter Form Design Class

The operations of the User From Topic Deleter Form class (Figure 165) are as follows:

- deleteUserFromTopic: deletes user from a topic

Figure 166: User From Topic Deleter Design Class

The operations of the User From Topic Deleter class (Figure 166) are as follows:

- deleteUserFromTopic: deletes user from a topic

Figure 167: Topic Unsubscriber Interface Design Class

The operations of the Topic Unsubscriber Interface class (Figure 167) are as follows:

- unsubscribeFromTopic: unsubscribes user from a topic


Figure 168: Topic Unsubscriber Design Class

The operations of the Topic Unsubscriber class (Figure 168) are as follows:

- unsubscribeFromTopic: unsubscribes user from a topic

Figure 169: Communication Handler Form Design Class

The operations of the Communication Handler Form class (Figure 169) are as follows:

- sendMessage: sends message to ESB

- receiveMessage: receives message from ESB

Figure 170: Communication Handler Design Class

The operations of the Communication Handler class (Figure 170) are as follows:

- sendMessage: sends message to ESB

- receiveMessage: receives message from ESB

4.2.9 Data Integrators Design Classes

Figure 171: Message Receiver Interface Design Class

The operations of the Message Receiver Interface class (Figure 171) are as follows:

- receiveMessage: receives a message


Figure 172: Message Receiver Design Class

The operations of the Message Receiver class (Figure 172) are as follows:

- receiveMessage: receives a message

Figure 173: Message Validator Interface Design Class

The operations of the Message Validator Interface class (Figure 173) are as follows:

- validateMessage: validates the received message

Figure 174: Message Validator Design Class

The operations of the Message Validator class (Figure 174) are as follows:

- validateMessage: validates the received message

Figure 175: Message Modifier Interface Design Class

The operations of the Message Modifier Interface class (Figure 175) are as follows:

- modifyMessage: modifies the received message

Figure 176: Message Modifier Design Class

The operations of the Message Modifier class (Figure 176) are as follows:

- modifyMessage: modifies the received message


Figure 177: Formatted Message Sender Interface Design Class

The operations of the Formatted Message Sender Interface class (Figure 177) are as follows:

- sendMessage: sends the message

Figure 178: Message Sender Design Class

The operations of the Message Sender class (Figure 178) are as follows:

- sendMessage: sends the message

4.2.10 Profile Execution Engine Design Classes

Figure 179: Emergency Profile Form Design Class

The operations of the Emergency Profile Form class (Figure 179) are as follows:

- insertEmergencyProfileData: inserts data for creating new emergency profile

- deleteEmergencyProfile: deletes the selected emergency profile

Figure 180: Emergency Profile Manager Form Design Class

The operations of the Emergency Profile Manager Form class (Figure 180) are as follows:

- uploadEmergencyProfile: uploads an existing emergency profile


- selectEmergencyProfile: selects an emergency profile


Figure 181: Emergency Profile Manager Design Class

The operations of the Emergency Profile Manager class (Figure 181) are as follows:

- insertEmergencyProfileData: inserts data for creating new emergency profile

- uploadEmergencyProfile: uploads an existing emergency profile


- selectEmergencyProfile: selects an emergency profile

Figure 182: Process Starter Form Design Class

The operations of the Process Starter From class (Figure 182) are as follows:

- selectProcess: selects a process

- startProcess: starts the process

Figure 183: Process Starter Design Class

The operations of the Process Starter class (Figure 183) are as follows:

- selectProcess: selects a process

- startProcess: starts the process


4.2.11 Web Service Creator Tool Design Classes

Figure 184: WSCT_GUI Design Class

The operations of the WSCT_GUI class (Figure 184) are as follows:

- createReadModifyDeleteExternalSystem: manages CRUD operations on external system

declarations (called by user)

- createReadModifyDeleteQuery: manages CRUD operations on query declarations (called by

user)

- createReadModifyDeleteService: manages CRUD operations on service declarations (called

by user)

- listServicesForExternalSystem: displays the list of services that are declared for a given

external system (called by user)

- login: allows user to login to the system (called by user)

- runService: starts a service (called by user)

- selectExternalSystem: selects an external system from the list of external systems (called by

user)

- stopService: stops a service (called by user)

- listExternalSystems: displays the list of external systems (called by user)

- shutdown: stops the applications (called by user)

- displayAlert: displays an alert on the GUI (called by controller)


Figure 185: Web Service Creator Design Class

The operations of the Web Service Creator class (Figure 185) are as follows:

- createReadModifyDeleteExternalSystem: manages CRUD operations on external system

declarations (called by user)

- createReadModifyDeleteQuery: manages CRUD operations on query declarations (called by

WSCT_GUI)

- createReadModifyDeleteService: manages CRUD operations on service declarations (called

by WSCT_GUI)

- listServicesForExternalSystem: displays the list of services that are declared for a given

external system (called by WSCT_GUI)

- login: allows user to login to the system (called by WSCT_GUI)

- runService: starts a service (called by WSCT_GUI)

- selectExternalSystem: selects an external system from the list of external systems (called by

WSCT_GUI)

- stopService: stops a service (called by WSCT_GUI)

- listExternalSystems: displays the list of external systems (called by WSCT_GUI)

- shutdown: stops the applications (called by WSCT_GUI)

Figure 186: Authentication Service Design Class

The operations of the Authentication Service class (Figure 186) are as follows:

- verifyCredentials: verifies the right to login for a user and his password, which should be

done using the common security module in the system

Figure 187: SOAP Interface Design Class


The operations of the SOAP Interface class (Figure 187) are as follows:

- query: transmits a query to the service, and returns its response

- subscribeTo: subscribes the client to a given service, which means that a set of messages will

be sent to the subscribed client

Figure 188: Service Mapper Interface Design Class

The operations of the Service Mapper Interface class (Figure 188) are as follows:

- getStatus: returns the status of the service

- start: starts the service

- stop: stops the service

- subscribeToAlerts: subscribes the client to alerts from the service, which means that the client

will receive all the specified alerts

Figure 189: Service Mapper Design Class

The operations of the Service Mapper class (Figure 189) are as follows:

- getStatus: returns the status of the service

- query: transmits a query to the service, and returns its response

- start: starts the service

- stop: stops the service

- subscribeTo: subscribes the client to a given service, which means that a set of messages will

be sent to the subscribed client

Figure 190: Data Model Local View Design Class


The operations of the Data Model Local View class (Figure 190) are as follows:

- createProperty: manages create operations on the properties of the external system(s) as

viewed by the service

- deleteProperty: manages delete operations on the properties of the external system(s) as

viewed by the service

- getProperty: manages get operations on the properties of the external system(s) as viewed by

the service

- setProperty: manages set operations on the properties of the external system(s) as viewed by

the service

Figure 191: Data Integrator Interface Design Class

The operations of the Data Integrator Interface class (Figure 191) are as follows:

- configure: configures the data integrator

- translateFromStandard: translates a message from a standard message to an external system

specific standard

- translateToStandard: translates a message from an external system specific standard to a

standard message

Figure 192: Connector Interface Design Class

The operations of the Connector Interface class (Figure 192) are as follows:

- configure: configures the adapter

- functionX: provides access to the external system features (typically by sending messages and

getting response messages)

- subscribeTo: allows subscription to services or messages


4.2.12 Emergency Maps Tool Design Classes

Figure 193: Emergency Maps Tool GUI Design Class

The operations of the Emergency Maps Tool GUI class (Figure 193) are as follows:

- activateDecisionMaking: activates decision making support

- activatePlayCommands: activates play commands for a re-run of the data recorded

- confirmData: validates the received data

- deactivatePlayCommands: de-activates play commands for a re-run of the data recorded

- deactivateSaveActions: deactivates recording of all user actions and results

- displayActivityDataList: displays a list of all available formerly recorded activity data (for the

logged-in user)

- displayData: displays rendered data and maps

- displayFilteredData: displays rendered data and maps with filters activated

- getGISData: requests available GIS (and sensor) data

- importData: imports data provided by the user. For example, a user can provide information

on the availability of beds in a hospital

- informUserOfLogging: informs user of starting of recording of all user actions and results

- listAvailableActivityData: requests a list of all available formerly recorded activity data (for

the logged-in user)

- listAvailableMaps: requests available maps from Map Servers

- saveData: saves the user input retrieved with “importData” function

- selectActivityData: selects activity data

- selectActor: queries the user to choose a role

- selectFilters: is used to select filters (e.g., for sensor groups, different layers, etc.)

- selectMap: selects a map from the list of available maps

- showDefaultMap: invokes default map


Figure 194: Emergency Maps Tool Design Class

The operations of the Emergency Maps Tool class (Figure 194) are as follows:

- activateDecisionMaking: activates decision making support

- activatePlayCommands: activates play commands for a re-run of the data recorded

- confirmData: validates the received data

- confirmDeactivation: informs user of deactivation of recording of all user actions and results

- deactivatePlayCommands: de-activates play commands for a re-run of the data recorded


- displayActivityDataList: displays a list of all available formerly recorded activity data (for the

logged-in user)

- displayData: displays rendered data and maps

- displayFilteredData: displays rendered data and maps with filters activated

- getGISData: requests available GIS (and sensor) data

- importData: imports data provided by the user. For example, a user can provide information

on the availability of beds in a hospital


- listAvailableActivityData: requests a list of all available formerly recorded activity data (for

the logged-in user)

- listAvailableMaps: requests available maps from Map Servers

- saveData: saves the user input retrieved with “importData” function

- saveActions: activates recording of user actions and results of those actions

- selectActivityData: selects activity data

- selectActor: queries the user to choose a role and validates the chosen role (if allowed for the

user)

- selectFilters: activates filters (e.g., for sensor groups, different layers, etc.)


- showDefaultMap: renders default map


Figure 195: Situation Information Repository Interface Design Class

The operations of the Situation Information Repository Interface class (Figure 195) are as follows:

- saveData: saves the user input

Figure 196: Situation Information Repository Design Class

The operations of the Situation Information Repository class (Figure 196) are as follows:

- saveData: saves the user input

Figure 197: Knowledge Layer Interface Design Class

The operations of the Knowledge Layer Interface class (Figure 197) are as follows:

- invokeAvailableMaps: requests available maps from Map Servers

- invokeGISData: invokes available GIS (and sensor) data


Figure 198: Knowledge Layer Design Class

The operations of the Knowledge Layer class (Figure 198) are as follows:

- getGISData: gets available GIS (and sensor) data

- getMap: selects a map from the list of available maps

- searchMaps: requests available maps from Map Servers


Figure 199: MashUp Tool Interface Design Class

The operations of the MashUp Tool Interface class (Figure 199) are as follows:

- renderMapAndGISData: invokes rendering of data and maps

Figure 200: MashUp Tool Class Design

The operations of the MashUp Tool class (Figure 200) are as follows:

- renderData: renders data and maps

Figure 201: Emergency Activity Data Repository Tool Interface Design Class

The operations of the Emergency Activity Data Repository Tool Interface class (Figure 201) are as

follows:



- getAvailableActivityData: requests a list of all available formerly recorded activity data (for

logged-in user)

- getSelectedActivityData: gets selected activity data


- listAvailableActivityData: lists all available formerly recorded activity data (for logged-in

user)

- saveAllDataActions: activates recording of user actions and results of those actions


Figure 202: Emergency Activity Data Repository Tool Design Class

The operations of the Emergency Activity Data Repository Tool class (Figure 202) are as follows:



- getAvailableActivityData: requests a list of all available formerly recorded activity data (for

logged-in user)

- getSelectedActivityData: gets selected activity data


- listAvailableActivityData: lists all available formerly recorded activity data (for logged-in

user)

- saveAllDataActions: activates recording of user actions and results of those actions

4.2.13 GIS Server Design Classes

Figure 203: GIS Server GUI Design Class

The operations of the GIS Server GUI class (Figure 203) are as follows:

- accessGeoData: gives user access to imported data

- editGeoData: allows editing of imported data

- extractSemantics: extracts semantics from the data

- importGeoData: imports user provided data and sensor data

- requestCoordinates: provides user with the option to give coordinates for which the data and

maps are required

- synchronize: requests synchronization with Geo Server


Figure 204: GIS Server Design Class

The operations of the GIS Server class (Figure 204) are as follows:

- accessGeoData: gives user access to imported data

- analyzeGeoData: analyzes imported user (not sensor) data

- collectGeoReferencedInformation: collects geospatial data

- connectToServers: connects to servers for synchronization

- displayMap: displays a selected map

- editGeoData: allows editing of imported data

- extractSemantics: extracts semantics from the data

- filterFeatures: filters according to, e.g., group of sensors

- importGeoData: imports user provided data and sensor data

- parseGeoData: parses imported user (not sensor) data

- renderFeaturesAndMap: : renders a map and the imported data

- requestCoordinates: provides user with the option to give coordinates for which the data and

Maps are required

- requestMap: requests a Map from a Map Server

- saveGeoData: saves imported user (not sensor) data

- setCoordinates: sets coordinates for which to extract the data for a given zoom factor

- synchronize: requests synchronization with Geo Server

- updateGISServer: updates the server

- zoomMap: zooms on a map by the user


Figure 205: Geospatial Resource Repository Interface Design Class

The operations of the Geospatial Resource Repository Interface class (Figure 205) are as follows:

- accessGeoData: accesses imported data


- searchGeoData: searches data dependent on coordinates or user information

Figure 206: Geospatial Resource Repository Design Class

The operations of the Geospatial Resource Repository class (Figure 206) are as follows:

- accessGeoData: accesses imported data

- saveDifferenceVersionData: saves the difference between the old and the new (imported) user

data


Figure 207: Semantic Information Interoperability Layer Interface Design Class

The operations of the Semantic Information Interoperability Layer Interface class (Figure 207) are as

follows:

- extractSemantics: extracts semantic data from data

Figure 208: Semantic Information Interoperability Layer Design Class


The operations of the Semantic Information Interoperability Layer class (Figure 208) are as follows:

- analyzeSemantics: analyzes semantics data

- extractSemantics: extracts semantic data from data

- updateGeospatialData: sends semantic data back to geospatial server

Figure 209: Geo Servers Interface Design Class

The operations of the Geo Servers Interface class (Figure 209) are as follows:

- connectToServers: requests connections to servers

- requestSynchronization: requests synchronization with servers

Figure 210: Geo Servers Design Class

The operations of the Geo Servers class (Figure 210) are as follows:

- connectToServers: connects to servers

- requestSynchronization: synchronizes with servers (pushes and gets data)

Figure 211: Maps Server Interface Design Class

The operations of the Maps Server Interface class (Figure 211) are as follows:

- requestMap: requests available maps from Maps Server

Figure 212: Maps Server Design Class

The operations of the Maps Server class (Figure 212) are as follows:

- provideMap: provides map from Maps Server

- requestMap: requests available maps from Maps Server

- searchMap: searches for maps from Maps Server


4.2.14 Sensor Protocol Adapter Tool Design Classes

Figure 213: Sensor Management Tool GUI Design Class

The operations of the Sensor Management Tool class (Figure 213) are as follows:

- activateFilters: activates filters that define group of sensors (e.g., temperatures, data with

minimum xx water levels). Only those data are then streamed

- activateSensorDataStream: initializes the stream of data to the system from selected sensors,

i.e., makes the data available for graphical presentation

- addSensor: adds a new sensor which is not yet connected to the system (but is listed by the

“listSensors” method)

- disconnectServer: disconnects selected sensors (or all of them)

- displaySensorData: displays the data (so that it is available for selecting data range, sensors,

etc.)

- listSensors: gets the list of all available sensors, that are either connected or are available for

connection

- selectDataRange: offers the User to select data range of interest

- selectOneSensor: gives the possibility to add only one sensor

- selectSensors: gives possibility to stream data only from selected sensors. In the next step, the

data stream is activated

- showSensors: shows all available sensors to the User

Figure 214: Sensor Management Tool Design Class


The operations of the Sensor Management Tool class (Figure 214) are as follows:

- activateOverlay: activates filters that define group of sensors (e.g., temperatures, data with

minimum xx water levels). Only those data are then streamed

- addSensor: adds a new sensor which is not yet connected to the system (but is listed by the

“listSensors” method)

- collectRealTimeSensorData: collects the stream of data from selected sensors and sends them

to the system, i.e., makes the data available for graphical presentation

- disconnectServer: disconnects selected sensors (or all of them)

- displayRealTimeData: displays the data (so that it is available for selecting data range,

sensors, etc.)

- filterRealTimeSensorData: filters the data for the data range selected by User

- listSensors: gets the list of all available sensors, that are either connected or are available for

connection

- searchSensors: searches for all available (connected and reachable) sensors

- selectOneSensor: gives the possibility to add only one sensor

- selectSensors: gives possibility to stream data only from selected sensors. In the next step, the

data stream is activated

- showSensors: shows all available sensors to the User

Figure 215: PnP Sensor Detection Tool Interface Design Class

The operations of the PnP Sensor Detection Tool Interface class (Figure 215) are as follows:

- activateSensorDetection: allows user to initiate in order for system to detect and activate the

sensors that are supposed to stream the data

Figure 216: PnP Sensor Detection Tool Design Class

The operations of the PnP Sensor Detection Tool class (Figure 216) are as follows:

- activateConfigureDriver: initializes AnySen tool driver configuration suitable for the sensor

- activateSensorDetection: allows user to initiate in order for system to detect and activate the

sensors that are supposed to stream the data

- selectSensorType: assigns correct sensor type to the sensor (temperature, humidity, etc.)

Figure 217: AnySen Tool Interface Design Class


The operations of the AnySen Tool Interface class (Figure 217) are as follows:

- configureDriver: configures driver for a sensor

Figure 218: AnySen Tool Design Class

The operations of the AnySen Tool class (Figure 218) are as follows:

- configureDriver: configures driver for a sensor

- sendStatusMessageToUser: sends a message to the user with the status of the configuration

4.2.15 Collaboration Environment Design Classes

For information on this tool, we refer to Sec. 4.1.15.

4.2.16 C2-SENSE Gateway Design Classes

Figure 219: Physical Interface Connector GUI Design Class

The operations of the Physical Interface Connector GUI class (Figure 219) are as follows:

- connectData: connects new data source

- defineTransmissionProtocol: : defines transmission protocol of the new data source

- defineDataFormat: defines data format of the new data source

- defineSecurityLevel: defines security level of the new data source

Figure 220: Physical Interface Connector Design Class

The operations of the Physical Interface Connector class (Figure 220) are as follows:

- applyConfiguration: applies configuration of the new data source


Figure 221: Enterprise Service Bus Interface Design Class

The operations of the Enterprise Service Bus Interface class (Figure 221) are as follows:

- retrieveData: retrieves new data source

- translateDataFormat: translates new data source into C2-SENSE proper data format

- sendData: sends data to ESB

- runDataAggregation: runs data aggregation method

Figure 222: Enterprise Service Bus Design Class

The operations of the Enterprise Service Bus class (Figure 222) are as follows:

- saveData: saves data in the system data base

- getData: gets new data source

- analyzeData: analyzes new data source

- deleteData: deletes new data source

- sendData: sends new data source for subsequent processing in the system


4.3 Detailed State Charts

4.3.1 Emergency Ontology Creator Tool State Charts

Figure 223: Emergency Ontology Creator Tool State Chart

The state chart of Emergency Ontology Creator Tool is represented in Figure 223. This tool is used

for creating common Ontology to be used in C2-SENSE system. The steps of Ontology creation

procedure are as follows:

1. Ontology is created from disparate content models. Therefore, as a first step, Content Model

is imported.

2. After that, imported Content Model is parsed and analyzed, and Ontology Resources (or

Common Data Elements) are created.

3. Ontology Resources are converted to Ontology.

4. Created Ontology is fed into a DL Reasoner to find relations between similar attributes of

entities.


5. If there are any missing relations that DL Reasoner could not find, these relations are created.

6. Complete C2-SENSE Harmonized Ontology is created.


4.3.2 Mapping Generator Tool State Charts

Figure 224: Mapping Generator Tool State Chart


The state chart of Mapping Generator Tool is represented in Figure 224. This tool is used for ensuring

different types of organizations having different Content Models to communicate with each other. The

steps of this process are as follows:

1. Each organization maps its Content Model (Local Domain Ontology) to C2-SENSE

Harmonized Ontology.

2. After mappings are created, a message (or document) in one Content Model is imported.

3. Mapping of the Content Model being converted and the Content Model to be converted are

retrieved from the repository.

4. The message (or document) in one Content Model is converted to another by using these

mappings.

4.3.3 Profile Monitoring Tool State Charts

Figure 225: Profile Monitoring Tool State Chart


The state chart of Profile Monitoring Tool is represented in Figure 225. This tool is used for providing

detailed information to the user about profile execution process. The steps of profile monitoring

process are as follows:

1. Monitoring messages are continuously created by Profile Execution Engine and sent to

Profile Monitoring Tool.

2. Retrieved monitoring messages are processed by Profile Monitoring Tool.

3. If this is a message about a completed task, tool displays it as a completed task.

4. If this is a message about currently running task, tool displays it as a currently running task.

5. If this is a message about bottleneck, tool displays it as a bottleneck and provides necessary

details.

6. If this is a message about incomplete task, tool displays it as an incomplete task and warns the

user.

7. If this is a message about pending task, tool displays it as a pending task.

4.3.4 Profile Definition and Specialization Tool State Charts

Figure 226: Profile Definition and Specialization Tool State Chart - 1


The state charts of Profile Definition and Specialization Tool are represented in Figure 226 and Figure

227. This tool is used for creating Emergency Interoperability Profiles (see Figure 226) and

customizing them to specific organizations and specific incidents (see Figure 227). The steps of

profile definition process are as follows:

1. Actors of profile are defined.

2. Messages between actors are defined.

3. Messages are put in an order (transactions) according to the needs of the profile to be created.

4. As a result of these three steps, profile is created and saved.

Figure 227: Profile Definition and Specialization Tool State Chart - 2

The steps of profile specialization process are as follows:

1. Profile to be customized to specific organizations or incidents are retrieved from the

repository.

2. Organizations are assigned as actors in the profile.

3. Specialized profile is created and saved to be executed later by Profile Execution Engine.


4.3.5 Security and Privacy Tool State Charts

Figure 228: Security and Privacy Tool State Chart


The state chart of Security and Privacy Tool is represented in Figure 228. This tool is used for

providing necessary authentication and authorization mechanism for the C2-SENSE components. The

steps of security and privacy procedure are as follows:

1. User enters his login information (username and password) and sends a login request.

2. If credentials are invalid, user is asked to enter again.

3. If credentials are valid, user is logged in.

4. After that user performs an action within C2-SENSE system (It can be any operation in any

tool/component).

5. Tool automatically checks user’s permissions.

6. Necessary log information is created and saved about authorization control.

7. If user is not allowed to perform this action, the operation is aborted.

8. If user is allowed to perform this action, the operation continues.

9. Data to be sent over network is signed and encrypted.

10. Necessary log information is created and saved about encryption.

11. Action is performed.


4.3.6 Conformance and Interoperability Testing Mechanism State Charts

Figure 229: Conformance and Interoperability Testing Mechanism State Chart

The state chart of Conformance and Interoperability Testing Mechanism is represented in Figure 229.

This tool is used for checking the conformance of the involved systems to the developed profiles and

the interoperability among them. The steps of this procedure are as follows:

1. Test scenario is created. Test scenario is actually a profile that is specialized for specific

organizations and incidents.

2. It may not be possible to provide each organization to test the scenario. So instead missing

roles are simulated.

3. Test scenario is ready for execution.


4. Test scenario is executed.

5. The messages exchanged between parties are captured automatically.

6. The message content and documents in the message are verified semantically for

conformance testing.

7. The message content and documents in the message are validated syntactically for

interoperability testing.

8. Test execution messages are generated to inform the user about test execution process.

9. If a test fails, error location of test is displayed to the user.

10. If a test succeeds, information about successful test is displayed to the user.

11. All the information is saved as test report.

4.3.7 Enterprise Service Bus State Charts

Figure 230: Enterprise Service Bus State Chart


The state chart of Enterprise Service Bus is represented in Figure 230. Following steps are followed

for the actions that can be performed on the ESB:

1. User selects an operation to perform on ESB.

a. Rule Interface

i. User can perform add rule, modify rule and delete rule operations related to

rule management.

b. Service Interface

i. User can perform register new service, view service, delete service, send

message and receive message operations related to service management.

c. Logger Interface

i. User can perform monitor network traffic and view system logs operations

related to logger interface.

2. Actions are performed on the ESB.

4.3.8 Message Communication Platform State Charts

Figure 231: Message Communication Platform State Chart


The state chart of Message Communication Platform is represented in Figure 231. Following steps are

followed for the actions that can be performed on the MCP:

1. User selects an operation to perform on MCP.

a. User and Role Forms

i. User can perform create role, add user to topic and assign role to user

operations related to role management.

b. Delete Form

i. User can perform delete user from a topic operation.

c. Communication Form

i. User can perform receive message and send message operations related to

communication.

d. Unsubscribe Interface

i. User can perform unsubscribe from topic operation.

2. Actions are performed on the MCP.


4.3.9 Data Integrators State Charts

Figure 232: Data Integrators State Chart

The state chart of Data Integrators is represented in Figure 232. Following steps are followed on the

DI:

1. Message is received.

2. Message is validated.

3. If message is not valid, it is modified.

4. Formatted message is sent.


4.3.10 Profile Execution Engine State Charts

Figure 233: Profile Execution Engine State Chart

The state chart of Profile Execution Engine is represented in Figure 233. Following steps are followed

for the actions that can be performed on the PEE:

1. User selects an operation to perform on PEE.

a. Emergency Profile Form

i. User can perform insert emergency profile, upload emergency profile or

delete emergency profile operations.

b. Process Starter Form

i. User can perform select process and start process operations.

2. Actions are performed on the PEE.


4.3.11 Web Service Creator Tool State Charts

Figure 234: Web Service Creator Tool State Chart – 1

The state charts of Web Service Creator Tool are represented in Figure 234 and Figure 235. Figure

234 show the overall behaviour of the Web Service Creator Tool. This is classical control command

tool behaviour. The GUI actions are those identified in the WST_GUI class diagram as done by the

user.


Figure 235: Web Service Creator Tool State Chart – 2

Web services are event driven applications: their loop treat events received on one of their interfaces

(to client, to external system, to WSCT) and answer to them. Events from WSCT are stop,

subscribeToAlert, getStatus. Events on other interfaces are message based, and may have to be

translated by the Data Integrator.


4.3.12 Emergency Maps Tool State Charts

Figure 236: Emergency Maps Tool State Chart

The state chart of Emergency Maps Tool is represented in Figure 236. This tool is used for acquiring

the data and maps, and presenting it to the user. This includes decision making activation and

recording and replaying the user actions and results. The steps of this procedure are as follows:

1. The data is imported by a user.

2. Decision making process is activated.

3. The user is provided with a role.

4. Default map is shown to the user.

5. User can chose another map that is provided in a list.

6. Upon map choosing, the feature data is rendered with the map.

7. The rendered data and map are shown.

8. The user can activate and use filters.

9. All of these actions are recorded upon the activation of the tool.

10. User can deactivate action recording.

11. User request activity data from repository.

12. User replays activities, i.e., studies them.

13. Play commands are deactivated.


4.3.13 GIS Server State Charts

Figure 237: GIS Server State Chart

The state chart of GIS Server is represented in Figure 237. This tool is used for acquiring and

rendering the data and maps, and presenting it to the user. The steps of this procedure are as follows:

1. The user data and the sensor data are imported.

2. The data can be edited.

3. The data is synchronized (pushed) to servers.

4. Semantic extraction is performed.

5. A map is requested.

6. A map and data rendering is performed.

7. Filtering and zooming is performed, in order to limit the amount of generated rendered result.


4.3.14 Sensor Protocol Adapter Tool State Charts

Figure 238: Sensor Protocol Adapter Tool State Chart

The state chart of Sensor Protocol Adapter Tool is represented in Figure 238. This tool is used for

sensor and sensor data management. The steps of this procedure are as follows:

1. A list of available sensor is provided.

2. Selected, new sensors are added.

3. The sensor data stream is activated.

4. Range of sensor data is set, and only those data are streamed.

5. Filters are activated to provide only selected sensor groups.

6. Disconnecting sensors/system terminates the stream.


4.3.15 Collaboration Environment State Charts


4.3.16 C2-SENSE Gateway State Charts

Figure 239: C2-SENSE Gateway State Chart


The state chart of C2-SENSE Gateway is represented in Figure 239. This tool is used for connection

and interconnection of the new data source or external system with C2-SENSE system. The steps of

this procedure are as follows:

1. In order to connect the new data source, C2-SENSE Gateway opens new connection. If there

is no disruption in connection, the connection slot is continued.

2. Whenever any connection is disrupted or either signal or data are corrupted, the connection is

closed immediately due to security reasons.

3. When there is no connection disruption, the connection with new data source is completed.

4. Then the data format of new data source is defined.

5. Consequently the transmission protocol with new data source is defined.

6. Then the configuration of connection is applied in order to start aggregation rules of the new

data source.

7. After successful application of data configuration, the new data source is retrieved and saved

into the C2-SENSE system using dedicated software tools.

4.4 Detailed Class Diagrams and Associations

4.4.1 Emergency Ontology Creator Tool

Figure 240: Emergency Ontology Creator Tool and its Associated Classes


4.4.2 Mapping Generator Tool

Figure 241: Mapping Generator Tool and its Associated Classes


4.4.3 Profile Monitoring Tool

Figure 242: Profile Monitoring Tool and its Associated Classes


4.4.4 Profile Definition and Specialization Tool

Figure 243: Profile Definition and Specialization Tool and its Associated Classes


4.4.5 Security and Privacy Tool

Figure 244: Security and Privacy Tool and its Associated Classes


4.4.6 Conformance and Interoperability Testing Mechanism

Figure 245: Conformance and Interoperability Testing Mechanism and its Associated Classes


4.4.7 Enterprise Service Bus

Figure 246: Enterprise Service Bus and its Associated Classes


4.4.8 Message Communication Platform

Figure 247: Message Communication Platform and its Associated Classes


4.4.9 Data Integrators

Figure 248: Data Integrators and its Associated Classes


4.4.10 Profile Execution Engine

Figure 249: Profile Execution Engine and its Associated Classes


4.4.11 Web Service Creator Tool

Figure 250: Web Service Creator Tool and its Associated Classes


4.4.12 Emergency Maps Tool

Figure 251: Emergency Maps Tool and its Associated Classes


4.4.13 GIS Server

Figure 252: GIS Server and its Associated Classes


4.4.14 Sensor Protocol Adapter Tool

Figure 253: Sensor Protocol Adapter Tool and its Associated Classes

4.4.15 Collaboration Environment



4.4.16 C2-SENSE Gateway

Figure 254: C2-SENSE Gateway and its Associated Classes

5 CONCLUSION

In this document, conceptual design of the C2-SENSE project is described and it is the output of the

design task of the project. During the design task, an adapted version of Rational Unified Process

(RUP) is applied. The RUP is a software engineering process and composed of several workflows.

This document is produced by following “Analysis & Design Workflow” of RUP, which contains

Use-Case Analysis, Architectural Design, Use-Case Design, and Class Design phases.

While performing these phases, subsystems and packages of C2-SENSE components are described;

interaction diagrams, component diagrams, state charts, class diagrams and their associations are

drawn.

Although this document is due at M8 (November, 2014) of the project, provision is taken by the

partners and especially the leading partner (SRDC) for regular updates which are required during the

development and testing phases.

D2.3 Conceptual Design of the C2-SENSE Architecture

Documents

Transcript of D2.3 Conceptual Design of the C2-SENSE Architecture