D2.1 Survey of the State of the Art Technologies and ... · ECI Electrical Critical Infrastructure...

D2.1 Survey of the State of the Art Technologies and Architectures

Due Date: May 31, 2014

Actual Submission Date: June 20, 2014e

Lead Beneficiary in charge of the Deliverable: PIAP

Revision: V1.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.1 Survey of the State of the Art Technologies and Architectures – /63

Document History:

Version Date Changes From Review

V0.1 6.05.2014

Initial Document Jan Piwinski

(PIAP)

All

V0.2 9.05.2014 input

Kluckner Sigmund

(AIT)

All

V0.3

12.05.2014 Draft

Lutech Security

Competence

Center

All

V0.4

15.05.2014 Description of European projects connected to C2-

Sense

Romuald Perinelle (Sagem)

François Gendry

(Sagem)

All

V0.5 23.05.2014 input SRDC All

V0.6 27.052014 Draft version

Jan Piwinski

(PIAP)

All

V0.7

27.05.2014 Final version of projects and architectures

Lutech Security

Competence

Center

All

V0.8

28.05.2014 Final version of projects

Romuald Perinelle (Sagem)

François Gendry

(Sagem)

All

V0.9 9.06.2014 Final version of deliverable

Jan Piwinski

(PIAP)

All

V.1.0 13.06.2014 Last version ready for review SRDC All

Contributors: Mert Gencturk, Yildiray Kabak, Gokce Banu Laleci Erturkmen (SRDC), Other Contributor

Names (Beneficiary)

Responsible Author Jan Piwinski Email [email protected]

Beneficiary PIAP Phone +48 22 874 01 26

mailto:[email protected]


Quality Control

Role Name Date

Peer Review Mert Gencturk 13/06/2014

Work Package Leader Kluckner Sigmund 17/06/2014

Project Manager Maria Banu 19/06/2014

Security Scrutiny Committee Review

Comments

No security sensitivity issues

Recommended Distribution

EC, Public.

Date 20/06/2014


EXECUTIVE SUMMARY

Following document is a starting point to Emergency Domain Inventory, which aims at describing

Partners previous projects as well as finding coherence with C2-SENSE objectives. Each project

presents current time used technology and systems, functional architecture or data model as well as

describe different use cases scenarios.


TABLE OF CONTENTS

Executive Summary ................................................................................................................................ 4 Table of contents ..................................................................................................................................... 5 Table of fıgures ....................................................................................................................................... 8 1 PURPOSE ...................................................................................................................................... 9

1.1 Definitions and Acronyms ...................................................................................................... 9 2 THE AVAILABLE TECHNOLOGY SOLUTIONS AND THE RESULTS OF THE

PREVIOUS COMMISSION SUPPORTED PROJECTS ..................................................................... 11 2.1 ARENA ................................................................................................................................. 11

2.1.1 Project Objectives & Results ........................................................................................ 11 2.1.2 Software and Hardware Components, System Architecture, Used Technology &

Platforms ...................................................................................................................................... 11 2.1.3 Similarity & Relevance to C2-SENSE Objectives and Layers ..................................... 12

2.2 P5 .......................................................................................................................................... 13 2.2.1 Project Objectives & Results ........................................................................................ 13 2.2.2 Software and Hardware Components, System Architecture, Used Technology &


2.3 DITSEF ................................................................................................................................. 13 2.3.1 Project Objectives & Results ........................................................................................ 13 2.3.2 Software and Hardware Components, System Architecture, Used Technology &


2.4 SmartMesh ............................................................................................................................ 15 2.4.1 Project Objectives & Results ........................................................................................ 15 2.4.2 Software and Hardware Components, System Architecture, Used Technology &


2.5 Safest ..................................................................................................................................... 16 2.5.1 Project Objectives & Results ........................................................................................ 16 2.5.2 Software and Hardware Components, System Architecture, Used Technology &


2.6 Heterogeneous Network (HeteroNet) ................................................................................... 17 2.6.1 Project Objectives & Results ........................................................................................ 17 2.6.2 Software and Hardware Components, System Architecture, Used Technology &


2.7 C4ISR on the move ............................................................................................................... 18 2.7.1 Project Objectives & Results ........................................................................................ 18 2.7.2 Software and Hardware Components, System Architecture, Used Technology &


2.8 SANY .................................................................................................................................... 19 2.8.1 Project Objectives & Results ........................................................................................ 19 2.8.2 Software and Hardware Components, System Architecture, Used Technology &


2.9 SUDPLAN ............................................................................................................................ 20 2.9.1 Project Objectives & Results ........................................................................................ 20 2.9.2 Software and Hardware Components, System Architecture, Used Technology &



2.10 CRISMA ............................................................................................................................... 20 2.10.1 Project Objectives & Results ........................................................................................ 20 2.10.2 Software and Hardware Components, System Architecture, Used Technology &


2.11 TaToo .................................................................................................................................... 21 2.11.1 Project Objectives & Results ........................................................................................ 21 2.11.2 Software and Hardware Components, System Architecture, Used Technology &

Platform 22 2.11.3 Similarity & Relevance to C2-SENSE Objectives and Layers ..................................... 22

2.12 SALUS .................................................................................................................................. 22 2.12.1 Project Objectives & Results ........................................................................................ 22 2.12.2 Software and Hardware Components, System Architecture, Used Technology &


2.13 iSURF ................................................................................................................................... 24 2.13.1 Project Objectives & Results ........................................................................................ 24 2.13.2 Software and Hardware Components, System Architecture, Used Technology &


2.14 RECONSURVE .................................................................................................................... 28 2.14.1 Project Objectives & Results ........................................................................................ 28 2.14.2 Software and Hardware Components, System Architecture, Used Technology &


2.15 TestBATN ............................................................................................................................. 32 2.15.1 Project Objectives & Results ........................................................................................ 32 2.15.2 Software and Hardware Components, System Architecture, Used Technology &


2.16 TALOS .................................................................................................................................. 36 2.16.1 Project Objectives & Results ........................................................................................ 36 2.16.2 Software and Hardware Components, System Architecture, Used Technology &


2.17 PROTEUS ............................................................................................................................. 41 2.17.1 Project Objectives & Results ........................................................................................ 41 2.17.2 Software and Hardware Components, System Architecture, Used Technology &


2.18 CARDINAL .......................................................................................................................... 44 2.18.1 Project Objectives & Results ........................................................................................ 44 2.18.2 Software and Hardware Components, System Architecture, Used Technology &


2.19 MICIE ................................................................................................................................... 49 2.19.1 Project Objectives & Results ........................................................................................ 49 2.19.2 Software and Hardware Components, System Architecture, Used Technology &


2.20 TMS/BDIR ............................................................................................................................ 53 2.20.1 Project Objectives & Results ........................................................................................ 53 2.20.2 Software and Hardware Components, System Architecture, Used Technology &



2.21 wHospital Framework (Lutech/Laserbiomed Project) .......................................................... 60 2.21.1 Project Objectives & Results ........................................................................................ 60 2.21.2 Software and Hardware Components, System Architecture, Used Technology &


2.22 OTRIONS ............................................................................................................................. 61 2.22.1 Project Objectives & Results ........................................................................................ 61 2.22.2 Software and Hardware Components, System Architecture, Used Technology &


3 CONCLUSION AND NEXT STEPS .......................................................................................... 63


TABLE OF FIGURES

Figure 1 Arena Architecture ................................................................................................................. 12 Figure 2 Field Commander (front view) ............................................................................................... 14 Figure 3 Field Commander (rear view) ................................................................................................. 14 Figure 4 DITSEF Architecture of the C2-SENSE ................................................................................ 15 Figure 5 DITSEF Architecture of the FR – Commander version ......................................................... 15 Figure 6 SmartMesh node ..................................................................................................................... 16 Figure 7 SmartNode .............................................................................................................................. 17 Figure 8 How SALUS extends current spontaneous reporting system to seamlessly exploit the already

existing clinical data in EHRs ............................................................................................................... 23 Figure 9 Interactions between different CPFR Communities ............................................................... 25 Figure 10 An Overview of the Upper Ontologies ................................................................................. 26 Figure 11 iSURF ISU Framework ........................................................................................................ 27 Figure 12 Overall RECONSURVE Architecture .................................................................................. 29 Figure 13 RECONSURVE system (blue boundary) improvements to the typical state-of-the-art

system (turquoise boundary) ................................................................................................................. 30 Figure 14 Hierarchical structure of RECONSURVE............................................................................ 31 Figure 15 Overall Architecture of the TestBATN Framework ............................................................. 33 Figure 16 TestBATN Conformance Testing Setup ............................................................................... 34 Figure 17 TestBATN Interoperability Testing Setup............................................................................ 35 Figure 18 The architecture of the TALOS system ................................................................................ 38 Figure 19 Proteus system components .................................................................................................. 42 Figure 20 Cardinal demonstrator architecture ...................................................................................... 45 Figure 21 Cardinal data model .............................................................................................................. 47 Figure 22 UML diagrams tree ............................................................................................................... 50 Figure 23 SMGW use case UML diagrams .......................................................................................... 51 Figure 24 SMGW detailed functional architecture ............................................................................... 52 Figure 25 SMGW detailed functional architecture ............................................................................... 53 Figure 26 Overview of the platform ..................................................................................................... 55 Figure 27 Lutech project – System architecture ................................................................................... 56 Figure 28 WSO2 Bus architecture ........................................................................................................ 57 Figure 29 Drools Fusion workflow ....................................................................................................... 59 Figure 30 wHospital Framework architecture ...................................................................................... 61 Figure 31. OTRIONS network topology ............................................................................................... 63


1 PURPOSE

The goal of this document is to present available technology solutions and the results of the previous

Commission supported projects.

Each partner provides several projects descriptions, whose results could be customized and

implemented into C2-Sense objectives.

To make this report transparent each project was divided into three sections. Firstly the projects

results and objectives are described, secondly the Software and Hardware components as well as

system architecture are presented and thirdly similarity between this project and C2-Sense is

characterized.

1.1 Definitions and Acronyms

Table 1 List of Abbreviations and Acronyms

Abbreviation/

Acronym DEFINITION

ACC Area Control Centres

AES Advanced Encryption Standard

API Application Programming Interface

ARENA Architecture for the REcognition of threats to mobile assets using Networks of multiple

Affordable sensors

ASCII American Standard Code for Information Interchange

ATM Air Traffic Management

B2B Business to Business

B2C Business to Customer

C2 Command & Control

C2-SENSE Definition of interoperability specifications for information and meta-data exchange

amongst sensors and control systems

CAP Control Access Parameter

CBN Chemical, Biological and Nuclear

CBRN Chemical Biological Radiological Nuclear (sensors)

CC Command Centers

CCI Communication Critical Infrastructure

CCMP Counter-Mode/CBC-Mac Protocol

CCTV Closed Circuit Television

CES Core Enterprise Services

CI Critical Infrastructure

CN Communication Network

COMSEC Communication Security

COPS Common Open Policy Service

COTS Commercial Off-The-Shelf

CPU Central Processing Unit

DB Database

DCC District Control Centre

DEM Digital Elevation Model

DES Data Encryption Standard

EC European Commission

ECI Electrical Critical Infrastructure

EDA European Defence Agency

EMD Engineering & Manufacturing Development

ESB Enterprise Service Bus

FAP False Alarm Probability

FDP Failure Detection Probability


FFBD Functional Flow Block Diagram

GAN Geographical Area Network

GENA General Event Notification Architecture

GNSS Global Navigation Satellite System

GPR Ground Penetrating Radar

GPRS General Packet Radio Service

GPS Global Positioning System

GSM Global System for Mobile Communications

GUI Graphic User Interface

HMM Hidden Markov Model

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol over Secure Socket Layer

ICT Information and communication Technology

IDF Information Discovery Framework

IDS Intrusion Detection System

IED Improvised Explosive Device

IFF Identification of Friend or Foe

IP Internet Protocol

IPSec Internet Protocol Security

IR Infrared

ISR Intelligence, Surveillance and Reconnaissance

IT Information Technology

LAN Local Area Network

MAC Message Authentication Code

MPLS Multi Protocol Label Switching

MSC Message Sequence Chart diagram

NASA National Aeronautics and Space Administration

NATO North Atlantic Treaty Organization

NMS Network Management System

NSOV NATO Service Oriented View

OASIS Organization for the Advanced of Structured Information Standards

OGC Open Geospatial Consortium

OPC Open Connectivity

OWL Web Ontology Language

OWL-DL Web Ontology Language – Description Logic

PC Personal computer

PCA Principal Component Analysis

PT Prediction Tool

QoS Quality of Service

RF Radiofrequency

RGB Red Green Blue

RTU Remote Terminal Unit

SA Situation Awareness

SCADA Supervisory Control and Data Acquisition IEC also uses as a Command and Control

System

SLA Service Level Agreement

SLS Service Level Specification

SNMP Simple Network Management Protocol

SOAP Simple Object Access Protocol

SP Service Provider

SSDP Simple Service Discovery Protocol

SSH Secure SHell

SSL Secure Socket Layer

STB Simulation Test Bench

SW Software

SWE Sensor Web Enable

TCAS Traffic Alert and Collision Avoidance System

http://de.wikipedia.org/wiki/Intelligence,_Surveillance_and_Reconnaissance


TCP Transmission Control Protocol

TLS Transport Layer Security

TRANSEC Transmission Security

TRL Technology Readiness Level

UAS Unmanned Aerial System

UAV Unmanned Aerial Vehicle

UDDI Universal Description Discovery and Integration

UDP User Datagram Protocol

UGV Unmanned Ground Vehicle

UML Unified Modelling Language

VPN Virtual Private Network

WiFi Wireless Fidelity

WLAN Wireless Local Area Network

WS Web Service

WSDL Web Services Description Language

WSDM Web Service Distributed Management

WSM Web Service Management

XML eXtended Mark-up Language

2 THE AVAILABLE TECHNOLOGY SOLUTIONS AND THE

RESULTS OF THE PREVIOUS COMMISSION

SUPPORTED PROJECTS

2.1 ARENA

2.1.1 Project Objectives & Results

Architecture for the REcognition of threats to mobile assets using Networks of multiple Affordable

sensors (ARENA) is an FP7 project (SEC-2010.2.3-3) dealing with the automatic detection and

recognition of threats to critical assets in large unpredictable environment. The project aims at

developing methods for automatic detection and recognition of threats, based on multisensory data

analysis, for mobile platforms such as trucks. The project is coordinated by FOI, SAGEM being a

partner.

2.1.2 Software and Hardware Components, System Architecture, Used

Technology & Platforms

The system architecture has been developed on existing video sensors with associated video

processing. Some local PCs supported the data algorithms and sent the information & alert to the C2

center. Main work has been focused on the data process and algorithms.

Arena architecture is service oriented and distributed. It is based on treatment pipelines that can

communicate to each other and share their knowledge of the situation as well as alerts.


Figure 1 Arena Architecture

2.1.3 Similarity & Relevance to C2-SENSE Objectives and Layers

Arena share with C2-SENSE:

use of sensors

processing sensor data

using a data model

using semantic interpretation of collected data

using a communication framework

The Arena architecture uses also standards like XML and JAXB. The use of application servers and

security mechanisms are detailed in the architecture, but were not necessary in the scope of the

demonstrator.

Truck / Lorry (protected asset) Truck's dispatching center

ARENA HQ Node

Integration PlatformARENANode

ARENARepository

ARENAService

HMI

Company ERP System

IR camera

Fish-eye camera

Radar

Truck with ARENA Node

Truck driver

CCTV cameraon-board computer

GPS

AN

Parking site with CCTV cameras

Arena Analyst


2.2 P5


P5 project (Privacy Preserving Perimeter Protection Project) is an FP7 capability project (Topic

“Early warning systems: physical protection of critical buildings”), which started recently; it is

coordinated by FOI with the participation of SAGEM. Its goal is to define an intelligent perimeter

proactive surveillance system, which will monitor the region outside the security area of critical

buildings and infrastructure, and give early warning if terrestrial or airborne threats are detected.



System is based on unattended ground sensors for the protection of infrastructure. Effort is made on

video processing for detection and track of pedestrian or vehicles;

the data fusion.


Both projects have distributed sensor data processing.

2.3 DITSEF


This is a FP7 project coordinated by SAGEM with nine partners, which aimed at increasing the

effectiveness and safety of First Responders by optimal information gathering and sharing with their

command levels.

DITSEF contributed to the study and the demonstration of:

Self-organising, robust ad-hoc communication between First Responders and between them

and their command level;

Accurate novel 3D positioning in indoor environments;

Sensors that offer a reliable overview of the situation and of the potential threats (explosives,

chemicals, fire, etc.);

Enhanced vision for the First Responder in visually-impaired conditions.


Figure 2 Field Commander (front view)

Figure 3 Field Commander (rear view)



The DITSEF project focused on new technologies of gas sensor, low power consumption Infrared

camera, and 3D indoor positioning equipment. Communication level was based on the tetrapol device

of Cassidian, on SONNET and on WiMax.


Figure 4 DITSEF Architecture of the

C2-SENSE

Figure 5 DITSEF Architecture of the FR – Commander

version


Both projects use sensor devices. The first responders, which are the main focus of DITSEF, are one

of many partners in C2-SENSE.

2.4 SmartMesh


The SMARTMESH (supported by a local innovation cluster in France) project has been managed by

SAGEM and attempted to define and build a prototype of intelligent wireless sensor network for

several applications in surveillance.

The aim has been to define, prototype and test a demonstrator of a lightweight, multiple wireless

sensor (electro-optic, acoustic…) system, autonomous in energy, able to detect, track and identify

persons and vehicles passing the controlled area.



System has been based on several networking “SmartNodes” linked to a C2 Center through an ad hoc

radio network. SmartNodes are low consumption weather resistant bi processor computers that are

able to monitor some ground sensors (acoustic and video), with associated data processing & data

fusion algorithms. They can run a few hours on battery in the demonstrator version.


Figure 6 SmartMesh node

Application and sensor messages are optimised for low bandwidth networks. This project used a

slightly optimized version of SNMP on IPv6.


This project shares with C2-SENSE the use of in-the-field sensors, and the problematic of the

interpretation of the collected data.

2.5 Safest


Safest is a security binational project (supported by the research agencies in France & Germany) led

by the Free University of Berlin.

SAFEST is a project aiming at providing a comprehensive solution to ensure the safety and security

of the general public and critical infrastructures. The approach of the project is to design a

lightweight, distributed system using heterogeneous, networked sensors, able to aggregate the input of

a wide variety of signals (e.g. camera, PIR, radar, magnetic, seismic, acoustic...).

The project aims for a proof-of-concept demonstration focusing on a concrete scenario: crowd

monitoring, area and perimeter surveillance in an airport, realized with a prototype of the system,

which must be deployable and foldable overnight, and leverages auto configuration based on wireless

communications and Internet of Things.




Following the SmartMesh concept, the System is based on networking SmartNodes linked to a C2

Center. Effort is made on the processing of crowd monitoring and threat alarms inside a public area,

with the secured network and private data processing.

Figure 7 SmartNode


Secured process and knowledge algorithms.

2.6 Heterogeneous Network (HeteroNet)


The aim of Heterogeneous Network (EDA) project was to provide or identify solutions which allow

receiving the right information at the right time and place using civilian as well as military networks

involved during Crisis Management Operations. The transmission of this information could use

different communication systems such as networks on land, sea or in space.

From the analysis of three use cases as well as an analysis of existing technologies, this project

proposed an abstraction model of heterogeneous networks, and then built an overview of the risks and

constraints implied by the use cases, and finally proposed requirements for SLAs, and

recommendations for network evolutions.



This study was done on paper, no demonstrator was developed. The system architecture is not

publicly available.



The second scenario, the civil military crisis management scenario, aims at showing the quantity of

information exchanged and the civil/military network interconnection needs. This has a good overlap

with the field of study of C2-SENSE, as both deal with interconnecting police, health care systems,

and sensor networks.

HeteroNet is an EDA project, and concerns also military networks. As such, its full conclusions are

not publicly available.

2.7 C4ISR on the move


To improve operations in a complex coalition environment, tactical systems will require a higher level

of interoperability. In particular, increasing safety, flexibility of mutual support, as well as improving

mutual understanding will have to rely on smart tactical exchanges across the coalition force at

battalion and below. The German (GE) project SPRINT, the US project Mission Command Gateway

(MCG), and the French (FR) demonstrator ORTAC merged in one experiment, are all focused on

experimenting with new information technologies to support commanders’ interactions at the tactical

level during combined joint operations. The multi-national (GE/US/FR) experiment “From Data to

Decision” conducted in October 2012 in SAGEM facilities builds on Limited Objective Experiments

(LOE) conducted over the past five years in Germany, the USA and France under ARTIST Technical

Arrangement for FR/GE, C4ISR Experiment Project Arrangement for US/FR and Battle Command

Systronics Project Arrangement for US/GE.



The US/FR project has focused on two areas of interest: rapid service development in Service

Oriented Architecture (SOA) and decision support based on optimizing agents. Previous experiments,

performed between US and France focused on collaborative mission planning Web Services (WS).

The operational added value from the experimentation has been to improve mutual understanding

between allied forces, to dynamically plan for assistance between ground supports troops (logistics,

MEDEVAC, and other areas) as well as to improve their coordination. This experimental mission

planning service relies on the CERDEC Mission Command Gateway (MCG) architecture, on an

optimizing software agent developed by DGA and SAGEM, taking into account near real-time multi-

media SA and readiness status from the edge entities (Systronics-enables vehicles, UGV, UAV,

dismounted infantry) developed by BWB and Diehl.

Previous experiments were performed bilaterally between the USA and France as well as between the

USA and Germany at Fort Dix and between USA and Germany at Roethenbach. These experiments

highlighted the benefit of operational Web Services, automated decision support, and assessed shared

awareness involvement in the joint tactical planning processes.

Current operational doctrine mandates interoperability at the brigade and possibly the Battalion level.

Nevertheless, the Research and Development projects, nationally and jointly under the

aforementioned Project Agreements or Technical Arrangements are exploring new ways to manage

tactical interactions at lower echelons. The final experiment entitled from “Data to Decision” has

scaled this scope up to three nations operating in coalition force and will interface with their

respective chains of command. In order to provide live data and to represent lower echelons, the


experiment also integrates the German Vetronics/Systronics Demonstrator called SAMSON, as well

as German tactical UAVs. A FELIN platoon was also integrated, with soldier robotic systems.


SoA, operations planning, interoperable forces.

2.8 SANY


The SANY (Sensors Anywhere) project focuses on interoperability of in-situ sensors and sensor

networks. The goal for the SANY architecture is to provide a quick and cost-efficient way to reuse

data and services from currently incompatible sensors and data sources in future environmental risk

management applications. SANY is an Integrated Project partly funded by the Information Society

and Media Directorate General of the European Commission, as part of the European Commission's

6th framework program.

A standard open architecture and a set of basic services for all kinds of sensors, sensor networks, and

other sensor-like services, the SANY IP supports and enhances both GMES (Global Monitoring for

Environment and Security, a major European space initiative) and GEOSS (Global Earth Observation

System of Systems) in the area of in-situ sensor integration. Though the SANY work enhances

interoperability for monitoring sensor networks in general, the application focus is on air quality,

bathing water quality, and urban tunnel excavation monitoring.



Standard service-oriented architecture for environmental sensor networks. SANY services

shall be self-describing and capable of seamless "plug and measure" and sharing (“virtual

networks”).

Reference implementations of reusable sensor- and domain-agnostic services, including

decision support and generalized data fusion services;

Three innovative risk management applications covering the areas of air pollution, marine

risks and geo hazards


Sensor Web Enablement

Decision Support

Plug and Measure concept


2.9 SUDPLAN


The SUDPLAN project - Sustainable Urban Development Planner for Climate Change Adaptation -

aims at developing a web-based planning, prediction and training tool to support decisions in long

term urban planning. This will help to assure population’s health, comfort, safety and life quality as

well as sustainability of investments in utilities and infrastructures within a changing climate. With its

open nature and architectural design, SUDPLAN will contribute to a shared information space in

Europe.

SUDPLAN has the ambition to be compliant with existing infrastructures supporting the emerging

SISE (Single Information Space in Europe for the Environment). Today, there are many autonomous

applications focusing on flooding, water runoff and air pollution. Some also include risk assessments

with a changing climate. The models are hard-wired into such applications and adaptations are

difficult to undertake.

The project intends to close this gap by providing planners and decision makers in the urban context

with a web-based scenario management environment providing advanced modelling services.

The web-based tool will allow end-users to manage scenarios, to execute, visualise and compare them

with each other and with real developments over 3-space and time, in order to carry out scenario-

based prediction, damage assessment, planning and training.

SUDPLAN will connect to existing systems and infrastructures using existing service-oriented

architectures (SOA). Emerging SISE developments (INSPIRE, GMES) use the SOA paradigm

because it offers dynamic recombination of services in a loosely coupled fashion.

The SUDPLAN communication and service infrastructure will be based on the standards and

specifications of OGC, and will re-use FP6 ORCHESTRA and FP6 SANY concepts, specifications

and software components, as well as other open source software, where appropriate for the

communication and service infrastructure.



SUDPLAN connects to existing systems and infrastructures using service-oriented architectures,

offering dynamic recombination of services in a loosely coupled fashion. The SUDPLAN

communication and service infrastructure is based on standards and on specifications of the Open

Geospatial Consortium, it reuses earlier EU-developed concepts, specifications and software

components, as well as other open source software.


Interoperability

Service oriented architecture

2.10 CRISMA



CRISMA Integration Project focuses on large scale crisis scenarios with immediate and extended

human, societal, structural and economic, often irreversible, consequences and impacts. Typically,

these crisis scenarios cannot be managed with regular emergency and first responder resources only,

but require multi-organisational and multi-national cooperation including humanitarian aid.

The CRISMA project shall develop a simulation-based decision support system, for modeling crisis

management, improved action and preparedness. The CRISMA System shall facilitate simulation and

modeling of realistic crisis scenarios, possible response actions, and the impacts of crisis depending

on both the external factors driving the crisis development and the various actions of the crisis

management team.

The CRISMA Framework is implemented as an integration toolkit which offers a set of defined

functionalities represented by software components (Building Blocks – BBs). The architecture of the

Framework ensures reusability of BBs especially in the context of integrating them into external

systems. It must be possible (and easy) to extend the CRISMA Framework and applications with new

models and additional functionality, as well as to exchange data with third-party systems and

applications.



Integrated Crisis Management Middleware

Flexible GUI Integration Approach

CRISMA Building Blocks

World State and Decision Making


High level objectives are in coherence with crisis and disaster management.

2.11 TaToo


The core of the project will focus on the development of tools allowing third parties to easily discover

environmental resources (data and/or services residing on different information nodes) on the Web

and to add valuable information in the form of semantic annotations to these resources, thus

facilitating future usage and discovery, and kicking off a beneficial cycle of information enrichment.

The proposed TaToo framework will allow the integration of semantics, taking into account the

challenges of different domain ontologies in a multi-domain and multilingual context. TaToo provides

three complex and extensive validation scenarios and therefore foresees skilled or expert users as the

primary target user group.

TaToo provides a semantic framework for discovery and access to environmental resources in a

multilingual and multi-domain context. Therefore, it provides tools for:

Discovery of resources

Annotation of resources

Semantic Interpretation of resource annotations


Information Enhancement (Knowledge Base) and Services (based on standards where

possible) for Integration and Processing of meta-data (e.g. semantic processor)

Storing / Archiving of TaToos (semantically enriched annotations)


Technology & Platform

A middleware infrastructure was developed to fill the gap between environmental resources and end-

users (discovery gap). This framework facilitates the life-cycle of environmental information from its

collection and persistent storage up to its discovery and purpose-oriented exploitation.


Usage of Semantic Web technologies (Ontology development, reasoning)

Knowledge Interoperability

2.12 SALUS


Scalable, Standard based Interoperability Framework for Sustainable Proactive Post Market Safety

Studies (SALUS) is an R&D project co-financed by the European Commission's 7th Framework

Programme (FP7), coordinated by SRDC.

Pre-approval clinical trials cannot guarantee that drugs will not have serious side effects after they are

marketed. Post-approval drug safety data studies aim at addressing this problem. However, their

effectiveness is started to be discussed especially after recent examples of drug withdrawals. This is

due to the fact that, current post market safety studies largely depend on the submission of

spontaneous case reports where underreporting is a major problem. Effective integration and

utilization of electronic health records (EHR) can help to improve post-market safety activities on a

proactive basis. SALUS aims at facilitating this through providing functional interoperability profiles

and supporting open source toolsets enabling EHR systems and clinical research systems to

communicate and exchange EHR data. Implementing semantic interoperability solutions enable

meaningful interpretation of the exchanged EHR data. Implemented security and privacy mechanisms

and open source toolsets ensuring that clinical information are shared in an ethical and safe way and

providing a novel exploratory analysis framework for open-ended temporal pattern discovery for

safety studies on top of disparate, distributed, heterogeneous EHR Systems. In short, SALUS aims at

creating the necessary semantic and functional interoperability infrastructure to enable secondary use

of EHR data in an efficient and effective way for enabling pro-active post market safety studies.

SALUS is currently ongoing project and it will end in January 2015.



SALUS plugs different rule based intelligent data analysis algorithms on top of available EHRs to

detect adverse event incidents by checking the administered drugs, laboratory test results, and


diagnoses and report them to the medical practitioners in order to increase the reporting rates of

ADEs. In order to integrate several different ADE detection tools with heterogeneous EHR systems

easily to conduct scalable distributed post market safety studies, standard based protocols are

introduced to specify the data to be screened in a machine computable manner, to feed these data to

the intelligent data analysis algorithms, and to send the suspected ADE list back to the medical

practitioners within an EHR session seamlessly as shown in Figure 8-A.

Upon detection of such ADE events through these enabling mechanisms, if confirmed by the

physician, these should be reported to regulatory bodies through standard based individual case safety

reports. Most of the data that needs to be reported within these reports such as patient demographics,

allergies, diagnoses, administered drugs and clinical events are already available in the EHRs. In order

to avoid duplication of effort to fill in these data to the case safety reports once again manually,

SALUS provides interoperability profiles to fill in these standard based forms within an EHR session

by extracting the required information from the underlying EHR system, and sending the forms

through the specified protocol to the respective regulatory bodies as shown in Figure 8-B.

Spontaneous reports only report the adverse incidents. The information related to the percentage of

other patients who used the drug but not experienced adverse events, i.e. the denominator data, is

missing. On top of that, these reports may fail to take into account important information about the

patient such as underlying medical conditions and the other drugs the patient may be taking. For these

reasons, upon signal detection based on the spontaneous reports collected, the pharmaceutical

companies and regulatory bodies need to conduct follow-up studies to collect more information

related to reported and unreported incidents. Currently such studies are manually conducted, since

there is no mechanism for communicating with the underlying distributed heterogeneous EHR

systems in an interoperable manner. An ideal system for ADR surveillance would combine the

strength of case reports with those of EHRs. SALUS provides standard interfaces for tracing case

reports to their corresponding patient records, to query the EHRs to enable absolute reporting rates to

be computed, and to retrieve additional information on extended parts of the underlying medical

history of the patient as shown in Figure 8-C.

Figure 8 How SALUS extends current spontaneous reporting system to seamlessly exploit the already

existing clinical data in EHRs



Main common subjects are profiling and semantic Interoperability.

SALUS project aims at achieving syntactic and functional interoperability between EHR systems and

clinical research systems. To achieve this, it is needed to define standardized interfaces between EHR

systems and clinical research systems. To define such standardized interfaces, “profiling” approach is

followed in the project in health domain. C2-SENSE project will follow similar “profiling” approach

for security domain.

SALUS project provides semantic interoperability framework to enable two or more computer

systems to exchange information, automatically interpret the information exchanged meaningfully and

accurately in order to produce useful results. In C2-SENSE project, dynamic information will be

mapped to each other in Information Interoperability Layer. Although C2-SENSE will expose the

functionality of emergency applications as Web services with standard interfaces, there are

overlapping standards and it is not realistic to expect all emergency responding parties to conform to

the same standards. Therefore, in C2-SENSE project, semantic interoperability suite will be

developed based on the know-how obtained in SALUS project.

2.13 iSURF


An Interoperability Service Utility for Collaborative Supply Chain Planning across Multiple Domains

Supported by RFID Devices (iSURF) is an R&D project co-financed by the European Commission's

7th Framework Programme (FP7), it is coordinated by Middle East Technical University (METU).

SRDC participated to the project as a partner.

To be able to cope with the requirements of today’s competitive and demanding digital world of

business, companies, especially SMEs, need to be more agile, and be ready to react to the changing

requirements of the sector. This requires a better view and a more comprehensive analysis of the

whole marketplace. Trading partners within a supply chain usually have different competencies based

on their business strategies and varying sources of information. When this information is not shared,

the decision making capability of companies is reduced since the impact of a decision on the supply

chain as a whole cannot be assessed correctly. An environment needs to be created to facilitate the

collaborative exploitation of this distributed intelligence of multiple trading partners in order to better

plan and fulfil the customer demand in the supply chain. As a response to this need, iSURF project

provides a knowledge-oriented inter-enterprise collaboration environment to SMEs to share

information on the supply chain visibility, individual sales and order forecast of companies, current

status of the products in the manufacturing and distribution process, and the exceptional events that

may affect the forecasts in a secure and controlled way. iSURF project was successfully completed in

July 2010. Although iSURF enables a generic collaborative environment, the outcomes were

demonstrated in the textile domain through the iSURF Pilot Application by Fratelli Piacenza S.p.A.

which is a manufacturer of fine cashmere fabrics and supplier to many world-leading apparel brand

manufacturers, including Boss and INCO/Zegna.



There are various standard initiatives addressing the standardization of communication in exchanging

the supply chain planning documents in different domains, such as RosettaNet, OAGIS, CIDX and

GS1 eCom. Hence, when companies involving in more than one supply chain need to exchange this


planning information across multiple domains, they face electronic business document interoperability

problem as shown in Figure 9.

Figure 9 Interactions between different CPFR Communities

Considering business document interoperability, the leading effort for defining business document

semantics came from the UN/CEFACT Core Components Technical Specification (CCTS) which

provides a methodology to identify a set of reusable building blocks, called Core Components to

create electronic documents. CCTS gained widespread adoption by both the horizontal and the

vertical standard groups. Universal Business Language (UBL) was the first implementation of the

CCTS methodology in XML. Some earlier horizontal standards such as Global Standard One (GS1)

XML and Open Applications Group Integration Specification (OAGIS) have also taken up CCTS.

However, because they use CCTS differently, there was still an interoperability problem among the

CCTS based electronic document standards. In order to address these problems, iSURF describes the

Interoperability Service Utility (ISU) which provides interoperability between different UN/CEFACT

CCTS based document standards for planning and forecasting information by means of ontology

reasoning based on both the description logics and the predicate logics. In order to help with the

interoperability of the document artifacts, iSURF explicates the CCTS based business document

semantics. By “explicating”, it is meant to define their semantic properties through a formal, machine

friendly. The semantics is explicated at two levels: At the first level, an upper ontology describing the

CCTS document content model is specified. As shown in the upper part of Figure 10, the ontology

classes are constructed from the concepts used in CCTS methodology. At the next level, the semantics

of the document schemas in each standard are described through “document schema ontologies”,

which are based on their corresponding upper ontologies. These ontologies are harmonized using a

Description Logics (DL) reasoned.


Figure 10 An Overview of the Upper Ontologies

As shown in Figure 11, the ISU Framework is composed of the following components:

Harmonized Ontology: This ontology contains two types of OWL-DL ontologies: (1) the

Upper Ontology and (2) the Document Schema Ontologies

DL-Reasoner: A Description Logic (DL) Reasoner is used to identify the equivalence and

subsumption relations in the Harmonized Ontology

Predicate Logic Rule Engine: In some cases, the Description Logic is not sufficient to find

relations between document artifacts. Therefore, in these cases, generic heuristics in the form

of Predicate Logic Rules are used

Ontology-PL Facts Wrapper: The document artifacts are represented through OWL classes

and properties in the Harmonized Ontology and they are represented as facts in the Predicate

Logic Rule Engine. This wrapper converts the OWL definitions to facts definitions which are

then asserted to the rule engine

Additional Heuristics: These heuristics are given through the Predicate Logic Rules to

identify the relations among the document artifacts which cannot be identified through

Description Logic


Figure 11 iSURF ISU Framework


Semantic Interoperability.

When companies involved in more than one supply chain need to exchange this planning information

across multiple domains, they face an interoperability problem. iSURF project provides a Semantic

Interoperability Service Utility (ISU) for achieving the semantic reconciliation of the planning and

forecasting business documents exchanged between the companies according to different standards.

In order to standardize the semantic specifications developed for the iSURF Interoperability Service

Utility, a technical committee namely “OASIS Semantic Support for Electronic Business Document

Interoperability (SET)” was initiated by the iSURF Project under OASIS umbrella. C2-SENSE will

use the approach developed in the “OASIS Semantic Support for Electronic Business Document

Interoperability (SET) TC ” which is to explicate the semantics of different but overlapping electronic

business document standards as ontologies and then provide semantic mediation among these

ontologies.


2.14 RECONSURVE


A Reconfigurable Surveillance System with Communicating Smart Sensors (RECONSURVE) is an

R&D project co-financed by the ITEA2 which is the EUREKA Cluster programme supporting

innovative, industry-driven, pre-competitive R&D projects in the area of Software-intensive Systems

& Services (SiSS). Project is coordinated by ASELSAN which is the largest electronics integrator in

Turkey in terms of both revenue and employee headcount. SRDC participated to the project as a

partner.

The RECONSURVE project has been motivated by and aims at addressing the need to control the

rapidly increasing number and complexity of maritime surveillance issues such as illegal immigration

especially using small vessels, interoperability between heterogeneous systems, automated cost-

effective and efficient decision support. Although there are some maritime surveillance systems

available, they lack the technical and architectural maturity to tackle all these requirements at once.

Some companies have some of the RECONSURVE subsystems as individual, disparate systems;

some have “unified” systems that display several data feeds all at once without the critical automated

decision making and support component and yet some have an integrated system with only very

limited algorithmic capabilities. A maritime surveillance system with a diverse set of smart sensors

installed on various platforms forming a coherent network via interoperability interfaces would

address maritime border security needs properly. The RECONSURVE project goes beyond the typical

maritime surveillance system. RECONSURVE is currently ongoing project and it will end in

December 2014.



Major architectural components of the RECONSURVE system, as shown in Figure 12, are the

following:

Sensors and Platforms

o Routing and Deployment

Command and Control

o Threat Analysis

Sensitivity Map

o Data Processing

Detection, Classification, Tracking and Data Fusion

Interoperability

Situational Awareness

Intelligent Decision Support

External Data Interfaces


Sensors

Platforms

EO/IR Radar AIS

Detection

Tracking

UAV

BoatLand Mobile

& Stationary

Interoperability Layer

Command and Control

Classification

Data Fusion

Behavioural

Analysis

Situational Awareness

Knowledge Management

Inteligent Decision Support

Data Processing

Sensitivity

Map

Threat

Analysis

Routing & Deployment Data

Figure 12 Overall RECONSURVE Architecture

RECONSURVE introduces improvements to the state-of-the-art represented by existing and planned

systems and projects as illustrated in Figure 13. In Figure 13 the system components found in area

covered by turquoise boundary are typical state-of-the-art system components, while the ones found

in area covered within blue and turquoise boundary are the components which RECONSURVE

Project improves with technical developments.


RadarEO

AIS

Situational Awareness Support

Data

Fusio

n

Dete

ctio

n/C

lass

ifica

tion

Data

Fusio

n

Situational Awareness Support

Dete

ctio

n/C

lass

ifica

tion

Behavioural

Analysis

Situ. Awareness

Knowledge Mgt

UAV

Intelligent

Decision

Support

Image

Classification

Figure 13 RECONSURVE system (blue boundary) improvements to the typical state-of-the-art system

(turquoise boundary)

Using the components shown in Figure 12, the RECONSURVE system is constructed on a

geography-based hierarchy with four levels as shown in Figure 14:

1. Segments: This represents the bottom of the hierarchical construct. Due to the differences in

the size of extended sea borders, a particular state may be covered by a single segment (e.g.

Malta) whereas several segments might be needed for others (e.g. Italy). (The segment level is

not depicted in Figure 14).

2. States: The area encompassed by the basin is divided into sea borders of the states in that

particular basin.

3. Basin: The whole EU sea border is divided into a number of basins, such as, Mediterranean,

Atlantic, Baltic, etc.

4. Europe: This is the top of the hierarchy which consists of a single node, the parent of all

basin nodes.


Figure 14 Hierarchical structure of RECONSURVE

The working principle of each node is similar regardless of their level. Likewise, the communication

between two nodes at the same level is accomplished through their parent nodes. During operation,

each node goes through the following:

1. Receive information from the parent and children nodes.

2. Update recognized maritime picture accordingly.

3. Communicate updated information according to a predefined policy to the parent and the

children nodes.


Semantic Interoperability.

A common language is needed for surveillance systems to exchange information with other national

and international entities, such as fisheries control (VMS), law enforcement agencies, automatic

identification system (AIS) and long range identification and tracking (LRIT). Lack of an agreed-

upon common language is one of the main reasons for the fragmented state of the current status of the

surveillance systems and inadequate cooperation between entities. RECONSURVE addresses this

issue by developing an Interoperability Framework, where interfaces with maritime surveillance

systems are defined through an ontological framework. In C2-SENSE project, semantic

interoperability suite will be developed based on the know-how obtained in RECONSURVE project.


2.15 TestBATN


Today, interoperability is the major challenge for e-Business and e-Government domains. The

fundamental solution is the standardization in different levels of business-to-business interactions.

However publishing standards alone are not enough to assure interoperability between products of

different vendors. In this respect, testing and certification activities are very important to promote

standard adoption, validate conformance and interoperability of the products and maintain correct

information exchange. In e-Business collaborations, standards need to address different layers of

interoperability stack; communication layer, business document layer and business process layer.

Although there have been conformance and interoperability testing tools and initiatives for each one

of these categories, there is currently no support for testing an integration of the above within a test

scenario which is similar to real life use cases. Together with the integration of different layers of

testing, testing process should be automated so that test case execution can be done at low cost, and

repeated if required.

TestBATN Framework is designed to allow dynamic, configurable and fully automated execution of

conformance and interoperability test scenarios. Conformance to a standard is a system’s ability to

satisfy all the requirements expressed within the standard. Conformance Testing is realized through a

collection of test cases each evaluating whether the requirements are satisfied. On the other hand,

Interoperability Testing involves not only the conformance evaluation for each role, but also testing

their ability to function collaboratively to achieve a set of requirements.

TestBATN Framework has the following features:

A Test Execution Model consisting of high level test constructs which can handle or simulate

different parts or layers of the interoperability stack. This makes it possible to test different

scenarios based on different standards by generating the corresponding test scenarios and

plugging in different adaptors.

A computer interpretable test description language allowing dynamic set up of test cases. This

provides flexibility to design, modify, maintain and extend the test functionality in contrast to

a priori designed and hard coded test cases.

Ability to automate the whole testing process addressing all the layers of the interoperability

stack. Partly automating the test process, that is, providing tools for certain layers of the

interoperability stack and doing the rest manually results in human labour intensive, error

prone, costly to develop test processes.

The system aims for “low cost of entry” for the test participants and hence provides a

graphical environment where a test designer can assemble the reusable test constructs for

conformance and interoperability tests.

The TestBATN framework is Web based. At the age of Internet, interoperability testing

should not be restricted in time and place. Vendors should be able to test their products over

the Web anytime, anywhere and with any party willing to do so



TestBATN Framework is designed to allow dynamic, configurable and fully automated execution of

conformance and interoperability test scenarios. Conformance to a standard is a system’s ability to

satisfy all the requirements expressed within the standard. Conformance Testing is realized through a

collection of test cases each evaluating whether the requirements are satisfied. On the other hand,

Interoperability Testing involves not only the conformance evaluation for each role, but also testing

their ability to function collaboratively to achieve a set of requirements. The overall architecture of

the TestBATN Framework is given in Figure 15.


Figure 15 Overall Architecture of the TestBATN Framework

The main components of the system are as follows:

Messaging Interface: A Messaging Interface is used to test communication layer

interoperability. In order to address the challenge of handling different standards and

protocols used at the communication layer, two common messaging interfaces are developed,

namely the Transport Interface and the Packaging Interface through which various adaptors

can be registered to the system and used.

Evaluation Interface: Evaluation interfaces are used at the document interoperability layer for

syntactic validation and semantic verification of messages and documents. There are several

different validation and verification adaptors provided by the TestBATN Framework such as

XML Schema Validators or XPATH verifiers.

Test Engine: Test engine drives the test scenario defined through the TestBATN Test

Description Language by communicating with the SUT (System Under Test) Administrators,

Evaluation Interfaces and Messaging interfaces as needed.

Test Design GUI and Test Management GUI: To facilitate the test design and monitoring

Web based graphical tools are provided to the users.

Test Framework Database stores all the re-usable test material including the test descriptions

and the adaptors.

TestBATN framework allows integrated testing covering all layers of interoperability stack; the

business process layer, the document layer and the communication layer. Rather than testing each

layer independently with specific tools and integrating the results, TestBATN has an integrated testing

approach which permits test restrictions on all of these three layers of the interoperability stack within

the scope of a test scenario.


Figure 16 TestBATN Conformance Testing Setup

The Figure 16 illustrates the main concepts of the framework and the setup for conformance testing. A

Test Scenario is the abstraction of the complete description involving the participating entities and the

steps required to achieve a specific test purpose; testing the systems against the conformance or

interoperability requirements of (a part or the whole of) a standard or a profile. The TestBATN

framework follows the business process terminology and calls the participating systems of the test

scenarios as parties.

Generally, Test Parties correspond to the abstraction of the framework for the actors specified in the

business process in the base standard. In the TestBATN framework, Test Parties can be of two types;

the Simulated Actors or Actors Under Test (AUT). The parties that are specified as AUT are the entry

points for Systems Under Test (SUTs) to participate in the test execution. The simulated parties are

the actors that take part in the business process or message choreography specified in the base

specification, but that are not intended to be tested in the test scenario. They are simulated by the

framework by means of test scripts to achieve the test purpose.

The Test Steps mentioned in the Test Scenario description are the abstraction for actions or

instructions that will be performed by the Test Framework or by the SUT to execute the test case. The

backbone of these steps is the message choreography specified for the Test Scenario (or derived from

the base specification conformance or interoperability criteria). Other steps are the instructions to the

Human Test Drivers controlling the SUTs and the validation steps that will contribute to the test

verdict.

Test Scenario is the abstraction and it should be interpreted as the sequence or flow of actions in Test

Designer’s mind to achieve the test purpose. In order to automate the test execution, this description is

defined in TestBATN machine readable language; TestBATN TDL. By following the conformance

and interoperability testing literature terminology, this definition which describes a test scenario is

called Test Case.

Conformance Testing in TestBATN

The Figure 16 shows the basic concepts and setup for conformance testing. During the test execution,

two entities; TestBATN Engine and TestBATN Control and Monitoring GUI take part at the


framework side. The TestBATN Engine is the system which interprets and executes the Test Case

definition and manages the whole process. The TestBATN Control and Monitoring GUI is the

interface between the engine and the Human Test Driver to provide real time monitoring on the test

execution, some control on the scenario and reporting of the test results. The Human Test Driver,

while monitoring the test execution with the “TestBATN Control and Monitoring GUI”, controls the

SUT according to the instructions shown through the GUI.

The purpose of conformance testing is to determine conformance of a single implementation against a

particular standard. Therefore, in the setup shown in Figure 16, there is only one SUT playing the role

of the Actor Under Test (AUT) specified in the conformance test case. The TestBATN Engine, on the

other hand, can simulate more than one party according to the business process specified in the base

standard or according to the testing purpose of the test scenario. The Means of Communication is the

physical setting that enables communication among systems which can be Internet, local network or

any other instrument.

For any given testing instance, there will be a test report which includes the final test verdict,

intermediate test verdicts for each step, and the detailed reports showing the logs and errors for each

step. In fact, the reports and the verdicts for each step are shown to the Human Test Driver at run time

without waiting the end of the test case. The interface between the TestBATN engine and the

TestBATN Control and Monitoring GUI realize this run-time monitoring facility. In addition, a

presentation model is defined in the framework and used to present the test scenario to the Human

Test Drivers in a more user friendly way.

Interoperability Testing in TestBATN

The Figure 17 illustrates the interoperability testing setup of the TestBATN when there are two SUTs.

The situation is similar when there are more than two SUTs. There is not much difference between the

conformance and interoperability testing in the testing process. Since the purpose of interoperability

testing is to check the end-to-end functionality between two or more communicating systems, usually

there is no simulated actor. However, interoperability test scenarios including simulated actors can be

designed for more complex tests. Generally, in the interoperability test scenarios, the aim is to listen

to the messaging between SUTs. The TestBATN framework achieves this by its specific instructions

for listening. The monitoring and reporting process is the same for conformance testing setup.

Figure 17 TestBATN Interoperability Testing Setup



Conformance Testing, Interoperability Testing

In C2-SENSE, TestBATN Framework will be adapted to crises management to check the

conformance of the involved systems to the developed profiles and the interoperability among them.

TestBATN provides a Test Execution Model consisting of high level test constructs which can handle

or simulate different parts or layers of the interoperability stack. This makes it possible to test

different scenarios based on different standards by generating the corresponding test scenarios and

plugging in different adaptors. It also provides a computer interpretable test description language

allowing dynamic set up of test cases.

2.16 TALOS


TALOS (System – Mobile Solution For Surveillance Of Land Borders And Large Areas) is an

international research project co-funded from EU 7th Framework Programme funds in Security

priority. The main objective of TALOS project is to develop and field test the innovative concept of a

mobile, autonomous system for protecting European land borders. The conventional border protection

systems are based mainly on expensive ground facilities installed along the entire length of the border

complemented by human patrols. The system developed within the TALOS project will be more

versatile, efficient, flexible and cost effective.

The complete system applies both aerial and ground unmanned vehicles, supervised by command and

control centre. The ground platforms will be both the watching stations and the first reaction patrols,

which will inform the Control and Command Centre and an illegal immigrant about her/his situation,

and will undertake the proper measures to stop the illegal action almost autonomously with

supervision of Border Guard Officers. It shall be emphasized that no other action than observing and

detecting illegal entry attempts will be taken by vehicles, thus there is no risk to human health and

life.

The most important features of the system are scalability, autonomous operation, mobility,

adaptability and modular construction. Through its flexibility it will be easy to adjust the system to the

local requirements such as border length and topographic conditions. Important role in the project is

given to Border Guards from countries with EU external land border in order to tailor system to end

user needs and requirements.

TALOS project consortium has adequate resources to face the challenge. The system will be

developed by experts working for 14 institutions from 8 EU member states (Belgium, Estonia,

Finland, France, Greece, Poland, Romania, Spain) as well as 1 EU candidate (Turkey) and 1

associated country (Israel). A wide range of the necessary competencies has been ensured by

composing the consortium of industrial companies, research institutions, small and medium

enterprises (SMEs) and a technical university. Project budget sums up to about 20 million Euros, 13

million of which has been granted by the EC.

Motivation behind the TALOS project

Character of the eastern border of the European Union (EU) has changed diametrically in

consequence of the EU extension in the recent years, when more than 10 countries, mainly from

Central and Eastern Europe, have joined the Union. Nature of the new external EU border differs

from the one before the accession. The frontier in its current shape extends between Finland in the

North and Bulgaria in the South of Europe. It is diversified with regard to topographic characteristics,

climatic conditions, as well as probability of occurrence and intensity of illegal activities. The borders

of new member states, shared with the former Soviet Union countries, are particularly exposed to

illicit trafficking. This part of the eastern EU frontier is a buffer between the relative prosperity of the


West and the poverty of the former Soviet Republics. The average salaries on its West side are much

higher than the ones on the East side. The border might be used as the Union’s backdoor for illegal

immigration and as an area of illicit activities, such as human trafficking and smuggling. European

Union is aware of the challenges created by the new frontier. Border security mission is one of the

priority security missions recognized by the European Security Research Advisory Board (ESRAB)

and European Commission. FRONTEX with its headquarters in the capital of Poland is one of the

agencies that were established in order to co-ordinate EU activities related with border protection.

EUROSUR (European Surveillance System for Borders) is another initiative aimed at preventing and

counteracting the illegal immigration.[1]



Transportable Adaptable Patrol for Land Border Surveillance (TALOS) is a robotic system that will

address the problems of surveillance of the large land border areas, which is one of the capabilities

critical for the border security mission recognized by the European Commission. The aim of TALOS

is to help in detecting, tracking and preventing persons from crossing the land border illegally

between the border crossing points. Its goals are in line with the concept of European Surveillance

System for Borders (EUROSUR) and conclusions of the European Security Research Advisory Board

(ESRAB). A prototype of the TALOS system, serving as a proof-of-concept, is going to be designed,

implemented and tested in a research project under the 7th EU Framework Programme.

To meet the requirements connected with the diversified nature of the Eastern EU land border, the

system should be adaptable, transportable and cost-efficient. These features are going to be achieved

by using unmanned patrolling vehicles with a high level of autonomy and controlled from

transportable Unmanned Unit Command Centre (UUCC), in place of the fixed infrastructure

consisting of fences and static sensors. Semi-autonomous operation of the vehicles will allow efficient

monitoring of large areas without engagement of large human resources. The main benefits of this

approach are:

Transportability of the system – initiatives like CRATE (Centralized Record of Available

Technical Equipment) and RABIT (Rapid Border Intervention Teams) have shown that EU

member states are ready for sharing the equipment and personnel for border surveillance in

case of emergency. TALOS system can be used in the same manner. The possibility of

deployment in distant mission areas, unavailable in case of systems based on static

infrastructure, is going to ensure the effective utilization of the system.

Adaptability of the system – the intended versatility of the system demands a design, which

allows the high degree of adaptability, with regard to topographic conditions, intensity and

probability of illegal operations in the border section. TALOS system will be easily

configurable to meet the requirements of a particular mission area, by selecting an accordant

set of unmanned vehicles to be deployed. Selection of number and configuration of the

vehicles will provide adaptability both to the length of the border section and the specific of

illicit activity. Availability of different types of unmanned platforms will enable the

maximum adaptation to the terrain conditions. The system can also be scaled on a higher level

of command, by adjusting the number of Unmanned Unit Command Centres, supervising and

controlling the operation of unmanned units, and commanded by a transportable Theatre

Command Centre;

Semi-autonomous operation – autonomy of the vehicles patrolling the border is the key

success factor of the concept behind the TALOS system. A system can be used for effective

surveillance of large areas only when a minimum engagement of the operator is ensured. This

is connected with the effectiveness of the system, both in terms of engagement of human

resources and economy. Autonomy of the Unmanned Ground Vehicles (UGVs) in TALOS

system is a particular challenge. The vehicles are going to operate in a complex and variable

environment. To meet this challenge, vehicles will use precise terrain models, laser scanners

and state of the art navigation modules.


While introducing advantages over systems based on static infrastructure (fences and static sensors)

TALOS will to maintain their high effectiveness. The system is going to allow the Border Guards to

react to trespassing within minutes. The vehicles can engage or trace illegal immigrant before the

arrival of manned forces. This ensures the person not being left unattended since he/she has been

detected by the sensors.

Figure 18 The architecture of the TALOS system

Prototype of the system will be composed of the Unmanned Unit Command Centre (UUCC) and two

Unmanned Ground Vehicles (UGVs). Unmanned Air Vehicle (UAV) and transportable Sensor Tower

will be integrated into the system in future. In the first phase of the project communication with these

elements is going to be simulated.

The Unmanned Units Command Centre (UUCC) will be used to control and monitor the operation of

the Unmanned Units. Mission commander and operators of the unmanned vehicles are going to be

seated at the Operator Control Units (OCUs). These will allow Border Guard officers to plan the

surveillance mission and control the vehicles, and provide also an operational awareness in the

mission area. The commander will be presented with a visualization of the mission area, including

position of the system elements, patrol routes and data from all the sensors, on different map layers.

Personnel operating the UGV’s and UAV’s OCUs will have the possibility of viewing the information

from sensors carried by the vehicles, as well as planning vehicle routes and operating the vehicles

manually.

Commands and data flow between the command centre and system’s end units will be ensured by the

communication network. Wireless network for TALOS system is going to be implemented in MESH

architecture. The main goal of its design is the network reliability, which is crucial to the whole

system’s performance.

Unmanned Ground Vehicles (UGVs) will be designed to constantly patrol the border section.

Vehicles will be equipped with long-range detectors of moving vehicles and people, as well as sensors

allowing the operator to recognize the detected subjects. They are going to be controlled from the

UUCC: either ‘driven’ by the operator, using a kind of ‘joystick’ and cameras carried by the vehicle

or, in semi-autonomous mode of operation, being ordered to drive from one point in the mission area


to another without ‘hands-on control’. The latter will be possible owing to state-of-the-art navigation

systems and advanced mechanisms of obstacle detection and avoiding.

Two types of vehicles will be implemented: the Observer, used for patrolling the given section, and

the Interceptor, used for engaging the illegal immigrant before arrival of the Border Patrol. The

Interceptor will enable communication of the operator with the trespasser, for example by means of a

microphone and loudspeaker.

TALOS system architecture was developed basing on the functional and technical requirements

gathered - both from the end-users (Border Guards) and the TALOS Project Consortium’s own

knowledge and experience. It has been designed according to the Joint Architecture for Unmanned

Systems (JAUS) standards. The following system nodes have been identified in the high level

architecture description:

In the first phase of TALOS both the Headquarters and Theatre Command Centre were not

implemented, but their functionalities were assumed to be fulfilled so that the Unmanned Unit

Command Centre behaved accordingly. Also, the functionalities of Patroller UGV and Interceptor

UGV were joined in a single UGV (Interceptor UGV). The UAV and Sensor Tower were simulated,

in order to show the capability of the system to have those element integrated at any time, like any

other unmanned units, such as USVs.

TALOS system demonstrator

TALOS Project Phase-I was aimed at the development of the TALOS system demonstrator, by using

the already existing solutions and development of the parts which are not existing yet. It has been

composed of the Unmanned Units Command Centre (UUCC) and two Unmanned Ground Vehicles

(UGVs). For the purpose of the system demonstrator, communication with Unmanned Air Vehicle

(UAV) and transportable Sensor Tower was simulated on the dedicated computers, placed in the

UUCC.

The Unmanned Units Command Centre (UUCC) controls and monitors operation of all the unmanned

units. It contains of the Operator Control Units (OCUs) for the Commander and the Operator of the

UGVs. The Commander is presented with a visualisation of the mission area, position of the system

elements, patrol routes and data from all the sensors on different map layers. UGV Operator has the

possibility of viewing the information from sensors carried by the vehicles, planning vehicle routes

and operating the vehicles manually.

Usage description

The TALOS system demonstrator contains of two UGVs, able to operate simultaneously, based on the

same mobile platform, and equipped with the sets of payloads, which correspond with the vehicle’s

function, as described in the next section. First UGV (Observer) is designed for the performance of

the surveillance and detection missions (preset patrolling route and observation tasks), the second

vehicle (Interceptor) is intended for interception of the suspicious objects (individual, vehicle etc.) and

following it until the manned Border Guard patrol will arrive to intervene, so the Observer UGV can

continue its surveillance mission. Even though the unmanned units are equipped with autonomy, the

constant supervision of the human operators is essential. In the system vehicle routes can be

calculated automatically, but the operator always needs to accept the proposed route. Similarly, the

identification of the trespasser (after he is detected by the sensors) is always performed by the

personnel, with use of the optic devices carried by the vehicle. No weapons or any coercive measures

are being used by the robots towards the detected and followed objects. In case of a need the

communication with the tracked intruder is possible via the interrogation system.

Unmanned Air Vehicle (UAV) will be responsible for the aerial surveillance and can be used as

communication node in particular situations. The prototype will not contain the UAV. In order to

make TALOS system ready for future UAV integration, the interaction of UAV OCU (console for

UAV management) with other subsystems will be simulated by the computer in UUCC.

Sensor Towers will be deployed in places requiring ceaseless surveillance 24/7, or in places not

accessible to the vehicles. The towers can be used both for sensor placement and as communication

nodes. They will be transportable together with the whole system. In the 1st phase of TALOS, data


flow between the towers and other subsystems will be simulated. The towers will be implemented in

future project phases.


TALOS system design similarity

Design of the overall architecture of the system as well as main system components, i.e.

Command Control, UGVs, communication system.

Overall architecture of the system as well as the main subcomponents designed in UML 2.0.

Design interfaces between elements of the TALOS system and between TALOS system and

external systems.

Specification of interfaces between TALOS system and external systems (e.g. legacy

systems) in XML.

Command Control similarity

Analysis of forming a common operational picture using data gathered from fusion of various

unmanned systems

Analysis of Mission Planning activities for various unmanned systems

Analysis of 3D Map/Terrain Model generation from different sources

Implemented software for situational awareness and command & control

Communications similarity

Network management – in each network, the management part is very important, as it has direct

impact on maintenance cost. Network management is especially important in very dynamic networks

in which topology or user density can change very often.

End-to-end communication needs to be efficiently managed. It is important due to mesh networking,

QoS and reliability. The operation and management center (O&M) will be equipped with all the

solutions existing in telecommunication networks, e.g., surveillance, controlling, remote switching of

resources, etc. O&M staff will be able to decide which procedures should be executed in order to

counteract malfunctions or congestion.

Compatibility of the radio end-systems – because of historical reasons border guards may use various

radio systems (e.g. analogue trunking, TETRA, GSM/UMTS, WiFi, WiMax). The concept of

software defined radio may allow them to use one single equipment in various networking

environments.

Some communication routes may be based on alternative radio solutions. Besides GSM that will be a

main back-up communication channel, we plan to elaborate a software radio module that will work in

analogue trunking, TETRA, UMTS or other systems available in the border zone. This approach

seems to be the most suitable because it is also the most flexible for future improvements. Moreover it

allows reducing the size of the device.

Integration with external application – heterogeneous communication networks (e.g. PSTN, GSM,

and WLAN) are used by many different application that exchange data between users of that

application. Providing standardize interface to an application can help companies to develop different

applications that can use heterogeneous networks.

Technical Standards Profile and Technical Standards Forecast

Technical Standards Profile” concerns with delineating systems standards rules and conventions that

apply to architecture implementations. “Technical Standards Forecast” contains expected changes in

technology-related standards and conventions, which are documented in “Technical Standards

Profile”.


“Technical Standards Profile” collects the various systems standards rules that implement and

sometimes constrain the choices that can be made in the design and implementation of TALOS

architecture.

“Technical Standards Forecast” aims at identifying critical technology standards, their fragility, and

the impact of these standards on the future development and maintainability of the architecture and its

constituent elements.

2.17 PROTEUS


Industrial Research Institute for Automation and Measurements with other scientific and research

institutes have started work on the innovation project, which results will be an answer for the new

challenges, which faced services responsible for the rescue, the critical management and the public

safety.

The project “Integrated Mobile System for Counterterrorism and Rescue Operations” – Proteus is

realized by consortium of leading science centres in Poland headed by Industrial Research Institute

for Automation and Measurement – PIAP.

The Proteus Project is aimed at development of a modern system, which in the future will be able to

support operations of police, fire service and the other services responsible for security of our society.

The designed system will include i.e.: three multi-functional robots, unmanned aircraft and mobile

command centre. The Proteus is going to make use of a range of innovative technologies integration

of which into one efficiently functioning system poses a serious challenge to engineers working on the

project.

Intensification of violent weather phenomena, of terrorism and ever increasing dependency of a man

on technology are the circumstances in which fire service and police have to reach for newer

technological solutions, which can improve their operations. One of solutions like that will be the

Proteus system. An idea of development of a system supporting anti-terrorist and crisis management

operations was conceived in PIAP already in 2003.

Climate changes and escalation of vehement weather phenomena, globalization, and development of

international terrorism, the rising dependence on technique in everyday life, all of them cause that the

critical situations happen very often and they touch a number of people. Because of the rising

challenges, new solutions, based on the newest technologies will be used more often.



The task of PROTEUS is to break number of the technological barriers and to create a demonstrator

of the system, which will offer a new quality of the actions in the critical situations. As a result of the

planned project in the years 2009-2013 will come into being integrated system, which will include:

Unmanned Plane (Aerial Vehicle (UAV)) to remote monitoring;

Three robots to various use;

Mobile post to action management.


Figure 19 Proteus system components

The system will allow instant situation recognition, current tracking of its development and taking up

emergency actions rapidly, what will exert an effect in the limitation of the crisis size and enlargement

of the victims and rescuers.

Unmanned Plane

Unmanned plane for the PROTEUS Project is prepared in the Research Laboratories of the Mobile

Systems in the University of Technology in Poznań.

Its task will be to support actions during the crisis situations, thanks to the observations, other data

collecting from the dangerous places and data transferring to the Master Control Station. Information,

which is provided by the Unmanned Planes, helps with making the decisions and coordination of the

services involved in the rescue actions. The deck computers in the unmanned planes enable the

autonomous flights, even beyond the area of the radio link. Unmanned plane will carry out the risky

tasks without the pilot’s life risk. Besides its usage will enable the costs limitation and time saving in

comparison with manned flights.

The Unmanned plane may be equipped with:

optical cameras;

thermo-visual cameras;

sensors of the chemical and radioactive contamination.

According to that it will be possible to:

determine the security zones

create the contamination maps;

support during the action control on the tactical level;


estimate the damages;

search victims in the extreme situations in example under the ruins;

measure the fire temperature;

detect the areas endangered by the fire;

predict the fire and contamination spreading.

The fundamental advantage of the Unmanned Planes is the possibility to supplement and

modification, as well as constructions, equipment and software, which will enable its adaptation to the

crisis situation specification.

Robots

1. Small Mobile Robot

Collapses, cracks, canals, narrow passes are the places, where it is hard to get into by a person. That is

why the one of the PROTEUS element will be small a mobile robot, which will enable the

observation and realization of easy tasks in the most inaccessible places. This ability is assured thanks

to the following robots’ features:

The stable construction with small overall directions and small mass;

The hybrid carriageable construction, which allows defeated terrain roughness and small

vertical obstacles;

The manipulator, which allows for easy operating;

The modular construction;

The visual cameras and sensors;

The intuitive control system.

2. Mobile Robot with accelerated functionality

In emergency services and services responsible for public safety actions there are many situations,

when a person’s help is impossible. That is why in PROTEUS system will be used Mobile Robot with

an accelerated functionality. It will be able to transfer the diverse data, containing the information

about environment, in which it works and take the complicated tasks. Robot will be autonomous

equipped, what will support the actions provided by the operator of the robot.

3. Interventionist Robot

Actions provided by the emergency services and the services responsible for public safety very often

are connected with the health hazard and danger of life of people, who take a part in these actions.

That is why one of the robot, which will be used in PROTEUS project is an interventionist robot,

which can support or even replace people during the most dangerous tasks.

Mobile Commanding Centre

One of the main elements of the PROTEUS will be Mobile Commanding Centre. This Centre has to

be more functional, modern and automated than crisis staff and other commanding centre, which are

used now.

In the projected the MCC will be elaborated, implemented and tested following solutions:

1. Complicated timing-spatial analysis, which will use advanced algorithms of mobile

processing, which will simplify a display of complicated phenomenon.

2. Expert system, which analyze crisis situation and present for operators and action’s manager

the list of possible scenarios, used in problem solution.

3. Elements of virtual reality, which are used for better presentation of tactical situation, very

modern intuitive interfaces of all implement subsystems, as well as mobile ones.

4. Integration with many external systems, which will provide constant supply of needed

information, which will simplify the decisions making on the ground.

5. Unlimited operating range of the system through the connection to the global network

6. Unique functionalities, which are the effects of usage of complicated computable geometry

algorithms, the theory of graphs, the communication management, which helps in fast


decision making or rather automation of selected process (evaluation of robot’s tracks,

defining of areas of visual visibility, tracking of information in distracted communication

system);

7. Open architecture which permissive for full scanning in case of rising user requirements;

As an effect the projected commanding centre will be a modern mobile distracted system, which will

be also an integrated element of complicated system delivering an unique. In the European scale

functionality for the users.

The Project is financed thanks to the financial support of the European Regional Development Fund

within the framework of the 1st priority axis of the Innovation Economy Operational Programme,

2007-2013, the sub-action is 1.1.2 Strategic Programme of Scientific Research and Development

Working.


Project objectives, crisis management and surveillance system coherence.

2.18 CARDINAL


The goal of the CARDINAL (CApability study to investigate the essential man-machine Relationship

for improved Decision making IN urbAn miLitary operations) project is to develop an information

management system that manages networked information flows to improve situational awareness. The

CARDINAL system consists of a CARDINAL Workstation (CWS) and a human operator, the

Information Manager (IM).

The CWS allows storage, retrieval and filtering of information that may be or become relevant to the

mission. The CWS also provides decision support or planning tools, for instance for route planning or

threat analysis. The information in the CWS is derived from various sensors and human intelligence

sources. The CWS is operated by an Information Manager (IM) whose task it is to support the troops

on the ground. The IM uses the CWS to combine and reason with the available information. The IM

also plays a role in adding information to the system.

Vision:

The envisioned role of the CARDINAL project is to demonstrate how to make the extensive flow of

information for military commanders available in a coordinated way. This means that while

operations are being performed, mission planning and immediate changed can be executed at tactical

level without the loss of leadership.

Main objective:

To develop an integrated and validated concept of networked information and observation systems.

Secondary objectives:

Validate and precise the user needs

Define a human factors design methodology

Develop improved perception support

Develop improves decision support

Develop improved user interfaces

To develop a human factors engineered working station

Develop a test bed for the workstation

Evaluate, demonstrate and disseminate the project result

Via task and requirements analysis including several international military end user sessions, a

functional description of the hard- and software (varying in TRL 3 to 6) was made.

The Cardinal prototype, integrated and demonstrated used during the experiment with end users in a

military unit in Swietoszow in Poland, consists of two main components:


KDA Simulator, which was operated by 3 soldiers (Driver, Gunner and Commander)

Cardinal WorkStation (CWS), which was operated by an Information Manager (IM):

The CWS allows storage, retrieval and filtering of information that may be or become relevant to a

mission. The CWS also provides perception and decision support as well as planning tools, for

instance for route planning, threat analysis and drag/drop icons.

The most important functionality of the prototype, which we saw during the demonstration, was that

the system increased soldier’s situation awareness significantly.

Figure 20 Cardinal demonstrator architecture



In order to support the functionality envisioned for the CARDINAL concept, the CARDINAL system

needs to be very flexible. It should be possible to integrate third party tools and sensors in the system.

When new sensors and tools become available, it should be easy to add support for these as well. In

order to fulfil these requirements, three types of components are distinguished in the CARDINAL

system:

1. Core functionality of CARDINAL

2. Middle-ware components that provide support for tools and sensors

3. Loosely coupled (third party) tools and sensors

The core functionality consists of a user interface and central data storage, the so called CARDINAL

World component. Also part of the workstation is dedicated middleware components, called

connectors. Connectors add support for specific sensors and tools. Finally, the sensors and tools,

providing data and functionality, are not viewed as integrated part of the workstation, but as loosely

coupled components that only interact trough the specialized connectors.


CARDINAL World database

The CARDINAL World database (CWDB) component is the central data store of the CARDINAL

system. The data in the CWDB are structured in such a way that they form a model of the real world,

hence the name “CARDINAL World”. The CWDB gets its data (i.e. new data or updates of existing

data) from two sources. The first source of data is the IM, who can add data via the GUI. The second

source is sensor data that can be processed automatically. The processing of sensor data is taken care

of by dedicated components called “Sensor Connectors”.

Due to the special nature of the CARDINAL system, a number of specific requirements were

determined for this database:

the data model must be flexible to allow for changes based on new insights during

development

the database must be interoperable to allow a wide range of different components utilizing

different technologies to interface

the database must remember the historical state of the information about the world

contained in the database.

Data from the CARDINAL World database can be used in multiple ways. The data are used

for all kinds of visualizations in the GUI. The data can also be used by tools, such as a path

planner tool or a threat assessment tool. Dedicated components called “Tool Connectors”

retrieve the data a tool requires and feed the data to the tool.

Data model

To facilitate integration of components, a data model is required that describes the format and

structure of the data in the CWDB. This data model needs to capture the structure of the world, the

objects in it and the relations between these objects. For CARDINAL this means that the data model

is capable of representing people, objects, events and relations between these people, objects and/or

events. In other words, a model of the world to represent the mission area is required: the

“CARDINAL World”.

The data model is based on the Object Oriented Modelling (OOM) paradigm: object types inherit their

properties from their “parent” object type, e.g. a Building is also a StaticObject and is also a generic

CardinalData object, and has the properties contained in these object types.


CARDINAL Application Programming Interface

The different components making up the CWS are implemented using a variety of programming

languages and tools. To allow flexible communication between these components, an Application

Programming Interface (API) was developed. The API allows different components (the GUI,

sensors, tools) to interface with the CWDB by storing, editing, and retrieving data. All interactions are

dealt with by exchanging XML messages over a TCP-IP connection. In order to make this work and

to allow for changes to the design and implementation later on in the project, the communication

between components needs to be standardized on different levels:

The (high-level) semantics of the message: What does the message mean? This is described

using a formalized XML format

The message XML format: Cardinal XML schema. This XML message needs to be

“encoded” into a series of bits according to an agreed-upon encoding.

The (low-level) way in which text is encoded into bits, to allow for exchange between

different platforms. For CARDINAL, the UTF-8 encoding is used as this is the dominant way

of encoding text, so choosing this format should make interoperability between the different

platforms that are used easier.

GUI and integrated tools

The IM interacts with the CARDINAL system through the Graphical User Interface (GUI) that is part

of the CWS. The IM can both retrieve data/information from the CWS and add data to the system.

Adding data is an important aspect of the IM’s task, since not all information streams can or will be

processed automatically. Even if data are processed automatically, the IM will often need to do some

post-processing, such as adding additional metadata or associating the data with other, existing data.

Figure 21 Cardinal data model


This means that the GUI should provide ways to manually add or update data and should be able to

connect to CARDINAL World to store the data appropriately.

While the GUI has a technological interface to the database, an aspect that is just as important, or

more important, is how the interface “connects” with the human IM. The challenge in the

CARDINAL project is to coordinate information flows such that military decision-makers in the field

receive the right information at the right time to guide their decision process. The CARDINAL work

station should assist in increasing situational awareness and selecting the relevant information to

improve the quality of decision-making.[2]

Sensors and Sensor Connectors

Some sensors provide data streams that can be processed automatically, to alleviate the workload of

the IM. Examples of such data streams are blue force positions from GPS sensors, internet weather

services, video streams from UAV’s, etc. Note that in some cases some manual labour by the IM may

still be required, for example by adding meta-data to the data stream, but the aim should be to process

data automatically if at all possible.

To make sure that CARDINAL is compatible with any kind of sensor and data stream, an interfacing

layer of software components, called Sensor Connectors, is proposed. For each new data stream or

sensor type, a dedicated sensor connector is developed.

The connector pre-processes the data stream and converts it into the standard format that is required

for the CARDINAL World Database. In this process, the connector provides as many meta data tags

as possible. Examples of meta data that could be provided automatically by the connector are an ID of

the data source or sensor, a time stamp, the location of the sensor, the type of data, etc. Of course,

which meta data are available and relevant depends on the type of sensor and type of data.

Tools and Tool Connectors

The Information Manager will have access to support tools such as a path planning tool and a threat

assessment tool. These tools require data that are stored in the CARDINAL World Database. They

should publish the results, such as the planned path or the threat analysis, to the GUI. An interfacing

layer of connector components, called Tool Connectors, is proposed, to connect tools to the CWS.

This approach is similar to the way sensors are connected.

By adding an interfacing layer of connector components, the core CWS functionality can stay

separated from the implementation of the tools. This allows for a clean design of the core

functionality while still providing the possibility to connect all kinds of third party tools.


The project aimed to design and develop an information coordination and support system that

provided real-time tactical support to dismounted military troops while they are performing their tasks

in urban environments. The support was able to automatically a) fuse heterogeneous information

streams into information elements to increase situational awareness, and b) select the relevant

information to improve the quality of decision-making.

The support system allowed to storage, retrieval and filtering of information that may be or become

relevant to a mission. The system also provided perception and decision support as well as planning

tools, for instance for route planning, threat analysis and drag/drop icons what increased soldier’s

situation awareness significantly.

Therefore similarities could e find in decision support and scenario planning and execution as well as

data modelling & processing and threat analysis.


2.19 MICIE


MICIE (Tool for systemic risk analysis and secure mediation of data exchanged across linked CI

information infrastructures) project designed and implemented a so-called ‘MICIE alerting system’

that identifies, in real time, the level of possible threats induced on a given Critical Infrastructure (CI)

by ‘undesired ‘ events happened in such CI and/or other independent CI’s. In particular, whenever

such events occur, the MICIE alerting system will support the CI operators providing them with a real

time risk level (e.g. expressed in a chromatic scale such as white, green, yellow, orange, red.

The alarm conditions will be evaluated by means of an on-line prediction tool making use of properly

designed abstract CI models fed with aggregated metadata describing the CI status.

Project Objectives:

1. Design and analysis of qualitative and quantitative interdependency metrics and indicators

accounting the service continuity and data integrity of the ICT infrastructure of the CIs and

the impact of such attributes on the delivery of service of any other cross-domain

infrastructure.

2. Design and analysis of a hierarchical modelling framework for interdependency analysis

based on the integration of heterogeneous modelling techniques.

3. Development of an on-line (real-time) "cascade failure induced" alarm level predictor able to

provide a qualitative indication of the actual level of exposure to cascade failure;

4. Design of a suitable commutation network able to assure availability, authenticity, integrity,

confidentiality and non-repudiation of metadata exchanged.

5. Validation of the interdependency alarm -predictor system on the infrastructure of an Electric

Company, Israel Electric Corp, partner in the project

General Concept

Improving the security of European CIs has become a top priority. Significant actions are under way

to assess and reduce vulnerabilities to potential terrorist attacks, to plan for and practice response to

emergencies and incidents and to develop new security technologies to detect security breaches.

In normal working condition each CI provides a set of services with a target Quality of Service (target

QoS) (e.g. expressed in terms of continuity/readiness of service, integrity of data, etc), i.e. the QoS

matching the requirements of the CI users. In a given CI the provision of such target QoS can be

threatened by the occurrence of undesired events (e.g. failures, incidents, terrorist attacks) happening

either in the reference CI, or in other CIs which are interdependent with the reference one. In this

respect, MICIE project aims to improve the CI Protection capability (in Europe) through the design

and implementation of a MICIE alerting system that identifies, in real time, the level of possible

threats induced on a given CI by undesired events happened in the reference CI and/or in other CIs

which are interdependent with the reference CI.

The above-mentioned threats will be expressed in terms of risk level for a given CI of being no more

able of providing its services with its target QoS in consequence of some events happening in other

CIs; such a risk level will be hereinafter referred to as CI risk level. So, the MICIE alerting system

will be able to provide, in real time, each CI operator with a CI risk level measuring the probability

that, in the near future, he will no more be able to provide the CI services with the desired QoS in

consequence of certain undesired events happened in the reference CI and/or in other interdependent

CIs.

Scientific And Technological Objectives

MICIE project pursued the following three innovative specific scientific and technological objectives

which will be detailed in the following three main points:

Designing CI modelling techniques in order to model the effects of undesired events

happening in a given CI on the QoS of the services provided both by the CI in question and


by the interdependent CIs. In particular, CI modelling includes the identification of key CI

interdependency indicators accounting for the mutual interdependencies among CIs

Designing and implementing an infrastructure for Secure Cross CIs' Information sharing and

mediation. Such infrastructure will include the design and prototype of proper MICIE Secure

Mediation Gateways able to collect sensible CI-specific data in the associated CIs, to translate

them in CI independent metadata, to exchange these metadata on secure ICT links and to

aggregate such metadata according to proper composition rules.

Designing and implementing a MICIE on-line risk prediction tool which encompasses the CI

modelling techniques mentioned in issue (1) and makes use, as key inputs, of the metadata

mentioned in issue



Secure Mediation Gateway (SMGW) Architecture

This section presents the architecture of the Secure Mediation Gateway (SMGW).

Specifications for the implementation of the SMGW are given using UML diagrams, describing both

the structure of the SMGW and its behaviour.

Figure 22 UML diagrams tree

In particular, as shown in Figure above presents the ‘Component diagram’ of the SMGW to describe

its structure, while the ‘Use case diagram’, the ‘State machine diagram’ and the ‘Sequence diagram’

are used to describe its behavior:

Use case diagrams provide an overview of the external services offered by the SMGW, i.e. an

external characterization of the system;

Component diagrams are used to identify the internal entities of the SMGW and their

interfaces, i.e. the internal components of the SMGW architecture;

State Machine diagrams are used to specify the behavior of each SMGW component, i.e.

internal operation of each component;


Sequence diagrams provide a description of the interaction among SMGW components, i.e.

external behavior of each component.

SMGW use cases

As a starting point for the design of the SMGW, a list of use cases has been identified in order to

understand the role of the SMGW in the MICIE system with respect to the other entities of the

system.

In the various use cases, the following actors are involved:

The Operator performing management actions on the local SMGW;

The Adaptor allowing interfacing of a CI with the local SMGW;

The Prediction tool performing risk analysis in a CI;

The local SMGW in a CI providing secure communication among peer remote CIs;

The external SMGW network consisting of the set of all the remote SMGW which the local

SMGW is connected to through a communication network.

Figure 23 SMGW use case UML diagrams

Figure above shows, in a graphical form, the SMGW use cases UML diagrams. Elementary use cases

can be grouped into two categories:

System management: handled completely by the operator;

Information update: involving the Adaptor the PT and the SMGW network in active

information exchange.

Figure below shows the UML component diagram of the SMGW, realized using StarUML software

tool.


Figure 24 SMGW detailed functional architecture

The role of the interfaces and of the functional modules:

Interfaces (i/f):

SMGW control i/f: is used by the operator to configure the SMGW, set policies, perform tests

and acquire information when needed. It is a GUI interface;

SGMW-Adaptor i/f: is used to connect the SMGW and the adaptor. Through this interface,

the adaptor sends new structured data to the SMGW.

SMGW-Prediction Tool i/f: is used to interconnect the SMGW and the prediction tool.

Through this interface the SMGW send new information (both local and remote) to the

prediction tool, while the prediction tool send to the SMGW updated results of its predictions

to make them available for remote prediction tools;

SMGW-SMGW i/f: is used to interconnect the local SMGW with remote SMGWs, in order to

enable the exchange of information among them.

Functional Modules:

SMGW manager: is responsible for the configuration of the policies in the SMGW and the

synchronization with the time server;

Auditing engine: is responsible for the acquisition and the collection of information about the

operation performed by the SMGW and by the other entities interacting with it;

Data/Metadata DB: stores all the information used by the prediction tool to perform risk

predictions (data related to the local CI and the predictions of remote prediction tool), as well

as the results of its prediction that are made available for remote prediction tools;

Information sharing framework: is responsible for the exchange of information among remote

SMGWs;

Communication engine: is responsible of the transmission and the reception of information

and data coming from remote SMGWs. It performs all the security functionalities needed to

guarantee that all the security requirements are satisfied.

Figure below shows a detailed SMGW functional architecture.


Figure 25 SMGW detailed functional architecture


Both projects have high-level objectives in crisis management, data modelling & processing,

networking process.

2.20 TMS/BDIR


The TMS/BDIR (Threat Management System/ Breach Detection and Incident Response) project was

implemented in Lutech to meet the need of having a dedicated platform for:

Detection from heterogeneous and distributed sources with different data format and different

network availability and performance issues.

Response to cyber security threats by using different available-on-the-market open source

technologies, allowing contextualization of information in order to drive prompt, focused,

efficient and effective reaction.

Coordination of different actors involved in the incident handling and response phases

allowing them to operate in the same shared context.

SMGW-SMGW-PT i/f

Network i/f

Firewall

WS-

SMGW WS application

SMGW WS client

SMGW

SMGW administati

on,

Subscription and security

Identity

Subscription and Security policies

AAA

Auditing

Auditing Log

MICIE Service

Subscribed Service register




The system work within four different phases:

1. Collection and Standardization: Every Security Data Telemetry (SDT) from cyber threat

intelligence, customer event and data from distributed, heterogeneous and multisite systems

are collected and standardized by a specific layer of the ESB. The platform can collect raw

data from various and different technological devices (e.g.: logical security devices, honey

pots and honey nets , databases, applications, POS systems, ATM systems, etc... ) in both real

time and batch mode.

2. Transport: All SDT data and every communication among the other layers, modules and peers

flow through the system, in a continuous shipping guaranteed data flow and in real-time (or

near real-time) by means of the ESB (Enterprise Service Bus), which also provides

categorization based on on-topbusiness rules.

3. Detection: The Complex Event Processing System (CEP) is a distributed rule and analysis

engine which analyzes and correlates all the received SDT parameters through ad-hoc

business driven rules and raises alerts in case one or more of the previous rules is matched.

4. Enrichment and Response: The SDT are enriched by specific distributed modules and on-

demand querable service which provide Cyber Threat Intelligence information and a Security

Knowledge Base. The Knowledge Base offers information about the whole asset perimeter

characterized by a security “criticality” defined as the impact that a threat coming from or

directed against the asset represents during a cyber-attack. The Cyber Threat Intelligence

offers information characterized by the maliciousness level of the source of threat. In case the

Detection layer Identifies some cyber threat or some malicious activity, then the Response

layer manages notification and alerts the Operators, which usually include Security Operation

Center operators of all the actors potentially involved by the attack: telecom operators,

customer security operators, law enforcement agencies operators, external companies

specialized security operators, etc.. The Security Operation Center operators perform an

incident analysis by examining the gathered data through the platform. The Operators can

also add evidences and other internal and external information by on-demand referring to

external data sources such as a data repository or a vulnerability management system that may

be essential to incident analysis to understand vulnerability posture of the specific targeted

asset: this latter query and the resulting response are again en routed through the ESB (on-

demand flow). The aim of the incident analysis is to rebuild the whole cyber kill chain.

The entire data flow is enriched and categorized through the different steps that compose the kill

chain as an input to the following incident handling phase, in order to support decision-taking by

Security Operation Center operators in the incident response phase.

Below is represented an overview of the platform:


Figure 26 Overview of the platform

As represented in the above figure, the Event Flow component (ESB) can reach every other layer and

component of the TMS/BDIR system and query it directly: it’s therefore possible to add context

dynamically. Even not trusted components can be managed dynamically through the Event Flow

component.

Platform Architecture

In details, the main components of this project are:

Drools Fusion : Complex Event Processing System

WSO2 ESB : Enterprise Service Bus to route and manage the data flow

Logstash: Event shipper system to send the SDT to the Enterprise Service Bus and to make an

initial parsing of the raw data


Figure 27 Lutech project – System architecture

How the platform works

The platform monitors and detects the intrusions over the target system belonging to different

customers, such as the technical support agency of a Regional Public Administration and various

national and international banking companies.

In this scenario the system is used to manage a large amount of Security Data Telemetry (SDT), to

collect, analyze, detect and response to cyber security incident.

The system uses security data telemetry (SDT), which allows to understand the flow of the entire

system.

The platform behaves as following:

1. Every SDT created is recovered in real time and sent to the ESB system through the Logstash

instances

2. The ESB system manages the SDT files and send it to the Complex Event Processing System

(CEP) and to the other components

3. The Complex Event Processing System (CEP) receive every events and by means of

appropriate rules is able to detect the intrusions that occur in the system

4. If intrusion or anomaly in the correct flow of the system is discovered, the Complex Event

Processing System (CEP) raise an alarm or a notification to the administrator

2.20.2.1 Wso2 Enterprise Service Bus

The ESB allows decoupling in the system, so when a new component (CEP, SDT shipper, Breach

notification suite) is added to the system, it does not require to know all the addresses of the other

already existing components. The whole effort is made by the Enterprise Service Bus that cares about

finding all nodes with which it has to communicate.


Architecture (reference: https://docs.wso2.org/display/ESB481/Architecture)

In the figure below is represented the architecture of the Bus

Figure 28 WSO2 Bus architecture

Transports : This level supports all the most used transports methods like HTTP/s, JMS, VFS. To

add a new transport method it can be done by the using of Axis 2 the embedded transport framework.

In this layer are present two sub layer:

Message Builders: Allow identifying the message by using the content type and make it to

common XML info set. So there are message builders associated with each content type

(JSON, XML, Syslog, ecc…). WSO2 ESB contains message builders for text based content

as well as binary content.

Message Formatters: The opposite partners of the builders. The formatter converts back the

message to the original format by referring the content type just before the message handover

to the transports. Similar to the transports user can implement new message builders and

formatters by using the Axis2 framework.

Endpoints : Endpoints stay as a logical component with the transports. Two sets of endpoints

Address and WSDL. An address endpoint can use any available transport to dispatch the messages.

Proxy Services : Proxy Services are the virtual services in the WSO2 ESB that implemented using

message receivers and open up to accept the messages. A Proxy Service can access using a URL


similar to a normal web service address. Proxy Service allows publishing a WSDL to suite for

advance usage. Any available transport can be used to receive and send messages from the Proxy

Services.

Topics : Topics are another implementation of message recover to handle messages on eventing

including subscriptions and events.

Mediators : The power of the WSO2 ESB remains with the comprehensive mediator library that

service for different aspects. Using the mediator library one can implement widely used MEPs and

EIPs. Writing a mediator is a simple task for a developer because WSO2 ESB provides a healthy

framework for that. Mediators can implement using various technologies including Java, scripting and

Spring.

Sequences : The sequences act as the configuration component for the mediators. Sequences allow to

organize the mediators to implement pipes and filters pattern.

Tasks and Commands : Tasks provide facility to configure scheduled jobs in the WSO2 ESB and

tasks allow to execute internal and external commands for mediation.

QoSComponents : QoS components implement reliable messaging and security for the Proxy

Services comes with the Apache implementations of those two modules Rampart and Sandesha.

Configuration, Repository/Registry : Configuration is the architecture diagram for an ESB

architect. WSO2 ESB has an inbuilt Registry/repository to store the configuration and configuration

metadata and it provides the facility to use a remote repository as well.

Gartner’s opinion

Gartner’s report “Magic Quadrant for On-Premises Application Integration Suites”, published on 27th

June 2013, places WSO2 in the Visionaries quadrant with high potentials to become a Leader.

In this report, Gartner praise WSO2 integration platform capabilities highlighting its focus on real

useful functionalities instead of rarely used features, thus making easier the deployment of new kind

of applications and architectures.

WSO2 competes well with other both open-source and commercial solutions and its integration suite

is currently used in hundreds of organizations, including cloud services providers.

Gartner also underlines that most of WSO2 products are based on previous Apache projects, so all

components are completely open-source.

2.20.2.2 Drools Fusion Complex Event Processing System

The Complex Event Processing System is fundamental within the system for the detection and

response to cyber security threats

The CEP used in this configuration is Drools Fusion, the module of the Drools suite doing complex

event processing. Drools allows to correlate, with a strong temporal constraint and the using of the

sliding windows, all the events that flow into the system.

Architecture

The Drools CEP architecture consists of the following components:


Figure 29 Drools Fusion workflow

Input Stream : This first module of the architecture receive the stream of System Data Telemetry

(SDT) from a source. It’s possible to use many type of communication type like:

1. TCP

2. UDP

3. SSL

Convert : When the events are received from the system, the events are converted from the original

format into a POJO (Plain Old Java Object) or a MAP that are compatible with the complex event

processing System.

Extract Parameters : Once the event are correctly converted into one of the format, the parameter

are extracted from the POJO or the MAP and then are send to the Complex Event Processing Engine

Defining rules : To process the events it is necessary to define the rules, the rules are added to the

engine

Event Processing : When the above step are properly taken place then the parameter extracted from

the events are send to the Complex Event Processing Engine. The engine processes the events through

the correlation rules. If some events match a rule then another Event is created and sent to the output

stream.

Output Stream : The output of the above phase are sent to the breach notification module that takes

care of generate alarms or notifications towards the Security Operators in order to manage the incident

in near real-time. Incident notification is based on preset rules that use severity levels, expressly

created for each rule according to the involved asset, to determine the risk of every alarm. The risk

parameter allows the Security Operators to understand at a glance the real hazard of the threat.



Data enrichment, distributed systems interoperability, data shipping in distributed environments, data

retrieving capabilities to support decision-taking phase.

The Enterprise Service Bus used in this project will be adapted to perform data routing through the

C2-Sense system and to guarantee interoperability among connected components. The Complex

Event Processing system and ad-hoc rules can be adapted to the specific needs of C2-Sensebusiness

rules.

2.21 wHospital Framework (Lutech/Laserbiomed Project)


Laserbiomed is a startup company born at Politecnico di Milano on direct financing of the General

Directorate of Health of Lombardy Region and, since 2009, the medical software house of Lutech

Group.

Laserbiomed is the developer of the wHospital® Framework, a healthcare web application framework

to build Electronic Health Records (EHR) that allows doctors and nurses to handle their mainstream

activities via web-based EHR.

wHospital can be interconnected to applications that provide administrative information and clinical

reports typically used on EHR. The standard integration method is through TCP/IP message exchange

based on HL7 protocol.

Since the end of 2012, wHospital® Framework solution is certified for the Documentum HIP

environment (Healthcare Integration Portfolio) on the EMC2 Solution Catalog for the EMEA market.

Laserbiomed has been recently involved in the implementation of a Clinical Operating System for a

new Central Electronic Medical Record (cEMR) database in the Republic of Georgia. In close co-

operation with the Ministry of Health and Social Affairs of Georgia and other stakeholders,

Laserbiomed contributed to boost the Health Management Information System (HMIS) for the whole

Georgian country by delivering a project where wHospital® Framework is the principal part of the

architecture.




Figure 30 wHospital Framework architecture

The figure above represents the architecture of wHospital implementation:

External Enterprise Service Bus (ESB) exposes web services which allow external interaction

with the platform (Users, Doctors, Citizens, Hospital IS). It also guarantees data exchange

among repositories, clinical apps and the wHospital Manager.

Internal ESB manages all the requests flowing between the intermediate layer (web services, clinical

app, repository) and the system libraries


HL7 interoperability, Hospital Availability Data, clinical data management.

The system is able to ensure user management in order to grant access to the system with different

type of privileges, roles and digital rights.

The knowledge on HL7 protocol and healthcare-related formats will be an advantage to perform

interoperability between C2-Sense and Hospital Information Systems (HIS).

2.22 OTRIONS


OTRIONS project (multi-parametric network for the study and monitoring of natural hazards in the

Otranto channel and the Ionian sea) aims to develop a system platform that integrates different


technologies for land monitoring and analysis of data in order to improve the analysis of natural

hazard in the Mediterranean sea with particular reference to the Otranto channel and the Ionian sea.

The project has been funded under the 1st call for project proposals of European Territorial

Cooperation Programme “Greece – Italy” 2007-2013 co-financed by the European Regional

Development Fund (ERDF) in the priority axis n.3 (Improving the quality of life, protection of the

environment and enhancement of social and cultural cohesion) and specific object n.3.2 (Valorisation

& improvement of joint protection, management of natural resources, natural and technological risks’

prevention)

The fundamentals are:

creation of a multi-sensor network to monitor the seismicity, deformation of the crust and

changes in sea level;

definition models of propagation of seismic waves with a deeper level of detail;

development of vulnerability maps by integrating the risk maps and cartography available

(Geographic Information System)



The architecture is formed by:

tide gauges for monitoring the level of sea;

seismic stations integrated with modules for satellite transmission of data;

mobile seismic stations in order to improve the local model of the propagation velocity of

seismic waves;

Four coordination centres for data processing that are located in Italy and Greece

Two collection centres for the treatment and processing of the data that are located in Italy

and Greece

The following figure shows the network topology:


Figure 31. OTRIONS network topology


Acquisition and processing of the data acquired by the sensors.

3 CONCLUSION AND NEXT STEPS

In this report consortium was looking for similarities between their EU previous projects and C2-

Sense. It occurred that consortium has a huge project experience and the results could significantly

boost and enrich C2-sense objectives and work process.

1 Andrzejczak M., Koziński M., Sprońska A., The concept of TALOS – Transportable Autonomous Patrol for

Land Border Surveillance System, proceedings of Trust and Confidence in Autonomous Systems Workshop,

2008, Orlando, Florida, USA 2 NATO, (2011). Allied Procedural Publication 6C (APP-6C) Military Symbols for Land Based Systems. In:

STANAG 2019 edition 6

D2.1 Survey of the State of the Art Technologies and ... · ECI Electrical Critical Infrastructure...

Documents

Transcript of D2.1 Survey of the State of the Art Technologies and ... · ECI Electrical Critical Infrastructure...