City.Risks platform architectureproject.cityrisks.eu/wp-content/uploads/... · user-centric vision...

Deliverable D2.5

City.Risks platform architecture

Editor A. Litke, N.Papadakis (INFT)

Contributors K. Patroumpas, D. Skoutas, A. Belesiotis (ATHENA), J. Hellriegel, S. Pfennigschmidt, F. Fuchs-Kittowski, S. Burkhard, S. Himberger (FF), N. Papadakis (SPH), N. Bakalos (ICCS), A. Anagnostopoulos (INFT)

Version 1.0

Date February 29th, 2016

Distribution PUBLIC (PU)

City.Risks Deliverable D2.5

© City.Risks Consortium 2

Executive Summary

This task under which the specific deliverable is produced focuses on the City.Risks platform system definition and design. The identified use cases, requirements and key performance indicators in Task 2.3 are driving the design of the functionality that will be offered by the City.Risks services as well as the technical features, mechanisms and algorithms that will be provided. In particular, the results from the requirements analysis have defined the technical environment wherein the City.Risks technology will be developed (under WP3, WP4 and WP5). Various constraints from the technological, scientific and market domain have been taken into consideration during the task lifetime resulting in an adjusted approach for the finalization of the City.Risks platform architecture and to the various modifications that will be needed for its continuous adaptation to the user needs. The completed version of the system design will be validated against test scenarios to ensure that all the functional requirements are efficiently met. The elaborated architectural model will take into consideration all the parameters for the desired functionality of the City.Risks engine in order to avoid any “failures by design”.

Emphasis will be given to design an open architecture system ensuring both scalability and open software standards by including also a Privacy by Design approach to ensure that privacy and ethical issues are respected. City.Risks follows a User centric approach (with prominence on an “ease of use” interaction mode, efficiency, availability, accuracy etc.) and addresses the interoperability aspects of the platform. The interoperability requirements in program-to-program interactions (e.g. with third party systems or other remote instances of City.Risks) force the Web services protocol stack to be much more general purpose and to be based on open Web standards (e.g. HTTP, REST, JSON, etc.) by implementing a series of Web Services for its intra-communication needs. Application Programming Interfaces (APIs), data schemas and desired functionalities by the various modules are also detailed in the current document.



Table of Contents

1. MAPPING OF REQUIREMENTS TO ARCHITECTURAL CONSIDERATIONS .......................... 5

2. INFLUENCES FROM THE STATE-OF-THE-ART .......................................................... 7

2.1. Mobile Applications ............................................................................................ 7

2.2. Theft detection sensors ...................................................................................... 7

2.3. Core platform technologies ................................................................................ 8

2.4. Data access layer ................................................................................................. 8

2.5. Privacy by Design concepts of the City.Risks platform ....................................... 9

3. OVERVIEW OF CITY.RISKS ARCHITECTURE .......................................................... 12

4. CITY.RISKS CORE PLATFORM SPECIFICATION ....................................................... 15

4.1. Technical specification of components and interfaces .................................... 15

4.1.1. User network module: User management and user profile ................................. 15

4.1.2. Messaging: Notification triggering and storing .................................................... 15

4.1.3. Rules and Policies Implementation ...................................................................... 16

4.1.4. Logging and Reporting .......................................................................................... 16

4.1.5. Configuration and data model .............................................................................. 17

4.1.6. Security aspects and measures for the core platform .......................................... 17

4.2. Related diagrams and workflows...................................................................... 18

4.3. Linking to requirements .................................................................................... 21

5. CITY.RISKS MOBILE APPLICATION ..................................................................... 23


5.1.1. Profile Management ............................................................................................. 24

5.1.2. Service (Area) Management ................................................................................. 25

5.1.3. Content Management .......................................................................................... 27

5.1.4. Notification Service ............................................................................................... 28

5.1.5. Location Service .................................................................................................... 28

5.1.6. Communication Services ...................................................................................... 28

5.1.7. Visualisation Service ............................................................................................. 29

5.1.8. Operation Manager .............................................................................................. 29



6. THEFT DETECTION SENSORS SPECIFICATION AND COMMUNICATION PROTOCOL ........... 37






7. DATA APPLICATION PROGRAMMING INTERFACE LAYER ......................................... 40


7.1.1. PostgreSQL as content repository ........................................................................ 40

7.1.1.1. Spatial support with PostGIS ......................................................................... 40

7.1.1.2. Routing capabilities with pgRouting .............................................................. 41

7.1.2. Geoserver.............................................................................................................. 41

7.1.2.1. Web Map Service .......................................................................................... 42

7.1.2.2. Web Feature Service ..................................................................................... 42

7.1.3. Spring REST API ..................................................................................................... 43



8. CITY.RISKS SDK SPECIFICATION ...................................................................... 52

8.1. Central Programming Interface ........................................................................ 53

8.2. Debugger ........................................................................................................... 54

8.3. Visual Editor ...................................................................................................... 54

8.4. Other SDK Components .................................................................................... 54

9. DEPLOYMENT AND SCALING IN CITY.RISKS ......................................................... 55

10. CONCLUSIONS ........................................................................................... 57

BIBLIOGRAPHY ............................................................................................... 58

LIST OF ACRONYMS ......................................................................................... 60



1. Mapping of requirements to architectural considerations

The City.Risks architecture is primarily driven by a number of factors including:

Stakeholder’s requirements and use cases as illustrated in deliverable D2.4: The City.Risks architecture attempts to respond to most of the stakeholders requirements expressed as part of deliverable D2.4. Several of these requirements (including requirements for openness, modularity and privacy by design) are addressed by the City.Risks architecture. Note however that some of the expressed requirements will be also addressed at a component-level (i.e. that as part of the design/implementation of specific components)

State-of-the-art developments: The City.Risks architecture has been influenced by state-of-the-art development in several areas including mobile applications, location based services, social networks, graph data bases, recommendation and reasoning engines. In some case City.Risks will be (re)using readily available components and architecture designs in these areas, as also reflected in the City.Risks architecture.

Following paragraphs illustrate how the City.Risks architecture has been influenced by the above factors, including a mapping of key requirements to architecture considerations and architecture development guidelines.

The following table illustrates how some of the City.Risks stakeholders’ requirements (listed in deliverable D2.4) have driven the development of the architecture. Several of the requirements listed in D2.4 are addressed by individual components rather than by the City.Risks architecture as a whole. These requirements are not listed on the following table, but in the respective section of the individual component.

Code Requirements Description Impact on Architecture Development

R1.1.X

R1.9.X

Mobile Application User (MAU)

Selection of technologies for the notification mechanism, for communicating with the end users. Lightweight thin clients. Location based services.

R1.2.X

R1.3.X

R1.5.X

Operations Center and web portal related requirements.

Rules and policies which need to be managed and enforced. Need for an effective event management system with emergency response capabilities. Location awareness. Communication patterns and logging reporting mechanisms.

R1.7.X Application Layer – Core Platform Subsystem

Implementation of a SDK that will be able to support new applications and their registries in the platform.

Managing of communities and policies. Logging



and reporting capabilities.

R1.8.X Resource and Data Layer The ability to support different kind of data and from different data bases (e.g. crime reports and statistics, geospatial data, 3D environment data multimedia data -audio, video, images- etc.)

This makes evident the need for a flexible and efficient data access layer that will be able to orchestrate in the most appropriate and effective way the access to these data.

R1.10.X Theft detection subsystem The ability to create a lightweight, power-efficient and friendly to use sensor device that will be used in the theft detection subsystem.



2. Influences from the state-of-the-art

2.1. Mobile Applications

Mobile application platforms. There are two approaches currently used to develop mobile applications (1) native apps and (2) web apps. Native apps require its own development based on the target platform (iOS, Android, Windows Phone). Web apps are based on HTML5 and other browser standards (JavaScript, CSS) and promise to run regardless of the platform. While native apps can interface all of a device’s hardware features, web apps have only limited access to features like the gyroscope, camera or communication services. They are also limited in terms of performance, interaction gestures, notifications and background processing.

Mobile augmented reality. The mobile application enables visualization techniques by integrating state-of-the-art technologies for mobile augmented reality (mAR). Recently, advances have been accomplished in particular in the field of marker-less mAR systems. Such systems determine the user’s position in the physical world via image-based 3D tracking methods based on SLAM (Simultaneous Location and Mapping) approaches or by fusing data of GPS sensors and inertial measurement unit (IMU) sensors such as gyroscope, accelerometer and compass. Recent version of various popular mAR libraries, including Wikitude SDK, Vuforia SDK, ARMedia SDK and ARToolKit, provide implementations of these tracking approaches for mobile platforms [1].

2.2. Theft detection sensors

City Risks project intends to design and implement an innovative, small and discrete sensor coupling Bluetooth Low Energy and radio-based technologies to transparently identify and locate stolen objects within a specific urban range through the usage of the City.Risks network of citizens.

The perception for the City.Risks sensor design was highly influenced by state-of-the-art development, mostly in the section of radio link mechanism and its corresponding power consumption. There has been an in-depth examination and evaluation of all possible wireless candidate solutions available on the market, it was clear that critical point of sensor design involved the wake up radio device power consumption and coverage distance that it can reach. Under Task2.1 a survey of the state of the art has been performed in order to pinpoint, analyze and evaluate existing applications, radio hardware solutions and case studies related to our project so as to drive our research directions.

State of the art update studies were mainly concentrated on the selection of Radio Link Mechanism that would serve as a wake up controller for turning our anti-theft device to beacon mode.



2.3. Core platform technologies

The main technologies that influence the approach selected for architecting and specifying the City.Risks platform are based on emergency response systems, alerting and event management systems, mobile applications technologies as well as operation center and risk management systems. The technological approaches have been presented in detail in the deliverable D2.1 “Gaps and challenges for addressing security threats in urban environments”. At the same time, together with these technologies, specific techniques and methodologies will be adopted to structure, plan, design and implement the software solutions of City.Risks keeping in mind the user-centric vision of the project while fulfilling its goals for increasing the citizens' perception of security and safety in urban environments. The core platform overall architectural approach is driven by the following design and specification principles:

To allow for a seamless integration of various building blocks (functional components) that will provide the overall desired functionality and services to the stakeholders of the project.

To be effective and modular enough so that it meets the desired functionality without overhead of complex and unnecessary intermediate entities.

To offer enhanced privacy in user generated data and their control by applying state of the art security technologies for privacy and confidentiality.

To allow for future extensions so that new services can be built on top of the platform.

2.4. Data access layer

The City.Risks repository needs to store and manage diverse types of content, coming from a variety of sources, both external and internal, and involving different data models and formats. Based on the state of the art, there are two main approaches that can be followed.

The first is to employ different technologies for different parts of the repository. For instance: users and communities can be stored in a graph database, such as Neo4j [2]; sensor logs and user-contributed content (text comments, media, etc.) can be stored in a document-oriented NoSQL database, such as ElasticSearch [3]; geographic information and maps can be stored either in files on disk (e.g., ESRI shapefiles) accessible via open source GIS libraries (like OpenLayers [4] or GeoTools [5]) or in a spatially-aware DBMS, e.g., using the PostGIS [6] extension for PostgreSQL. The second approach is to employ a relational DBMS, such as PostgreSQL [7].

Although the former strategy would allow for more optimisations in certain cases, it would also incur additional overhead as it would be harder to coordinate, correlate, and analyse content across different parts of the repository, potentially introducing significant delays when responding to user requests; moreover, it would be more difficult to maintain, e.g., handling different software versions and updates, conflicting dependencies in third-party libraries, etc.



On the other hand, the data volumes that the City.Risks repository is expected to store are certainly manageable by a relational DBMS. If scalability and high availability become a concern, modern DBMS provide powerful replication mechanisms, which allow the creation of clusters of commodity database servers and parallelisation of query execution over big data. Moreover, it is easy to define users, roles, and different access rights. In addition, geospatial support is of utmost importance for City.Risks, e.g., for hot-spot analysis, safety-aware routing, evacuation, etc. Modern DBMS technology (and PostgreSQL with PostGIS in particular) offer mature and advanced support and functionality for handling geospatial data. Finally, data organisation in a DBMS offers the ability to define referential (e.g., foreign keys) and integrity constraints (e.g., checking validity of data values). Furthermore, operations that involve filtering, joining, and aggregating data are best carried out in a DBMS with the support of suitable indexing schemes that can boost performance.

2.5. Privacy by Design concepts of the City.Risks platform

When talking about privacy by design we refer mainly to the Privacy-Enhancing Technologies (PETs) which have been studied in depth for many years now. A well-known definition, and one that was later adopted almost literally by the European Commission [8], was given by Borking and Blarkom et al. [9] as follows:

“Privacy-Enhancing Technologies is a system of ICT measures protecting informational privacy by eliminating or minimising personal data thereby preventing unnecessary or unwanted processing of personal data, without the loss of the functionality of the information system.”

Privacy by Design is summarized by Cavoukian [10] (who was the first to coin this term) in 7 principles providing also a description of their implementation and mapping of Fair Information Practices. A clear and detailed study on the subject is presented also by ENISA [11].

In City.Risks the overall architecture and specification of the platform is driven by the following strategies which are integral parts of the overall Privacy by Design approach.

1) Proactive not Reactive

The Privacy by Design approach is characterized by proactive rather than reactive measures. It anticipates and prevents privacy invasive events before they happen. In City.Risks the main focus during the design phase of the platform and its modules was to have security and privacy preservation. This is reflected for instance on the way that the databases have been structured so as to avoid data breaches and having a concrete definition of user roles and access policies for the various involved stakeholders.

2) Privacy by default

If a user does nothing, their privacy still remains intact. No action is required on the part of the individual to protect their privacy since it will be built into the system, by



default. Having a very sensitive approach on handling the user generated data (including the user profiles, and the user communities), the City.Risks platform is adopting the following principles for privacy by default:

i) Data minimization - the collection of personally identifiable information is kept to a strict minimum while identifiability, and linkability of personal information will be minimized. This is evident in the data base of the City.Risks platform where the data of the users are only the minimum possible with including sensitive data such as ID numbers, VAT numbers, insurance numbers, ethnicity, religion or others.

ii) Purpose Specification – the purposes, for which personal information is collected, used, retained and disclosed will be communicated to the user before the time the information is collected. This is going to be enforced by the City.Risks policies engine which will act as a guard of maintaining the purpose of the data usage.

3) Privacy embedded into design

A systemic, principled approach to embedding privacy should be adopted − one that relies upon accepted standards and frameworks, which are amenable to external reviews and audits. Privacy by Design is embedded into the design and architecture of City.Risks platform and operational / business practices. The result is that privacy becomes an essential component of the core functionality being delivered. This feature is enhanced even more with the modern state-of-the-art technologies that will be used during the implementation (such as Spring Security detailed later in the deliverable) which bring is by default security aspects of authentication and authorization as an embedded characteristic of the core development framework of Spring.

4) End-to-end security

Without strong security, there can be no privacy. Thus, privacy must be continuously protected across the entire City.Risks system and throughout the life-cycle of the data it handles with no gaps in either protection or accountability. In general, applied security standards, technology frameworks and protocols must assure the confidentiality, integrity and availability of data (especially the sensitive ones) throughout its lifecycle including, appropriate encryption, strong access control (through authentication and authorization) and logging methods. All these are present in the specification of the City.Risks platform.

4) Respect for user privacy

The best Privacy by Design results are usually those that are consciously designed around the interests and needs of individual users, who have the greatest interest in the management of their own personal data. Respect for User Privacy is relying in the following principles:

Consent – The user of the City.Risks platform is going to give data under his/her explicit consent. A specific procedure is already described in the Description of Action of the project. Consent may be withdrawn at a later date.



Access – Users will be provided access to their personal information and will informed of its uses. This is going to be supported by the user management modules and the user friendly interfaces of the City.Risks platform which will make this access handy.



3. Overview of City.Risks architecture The current section provides an overview description of the City.Risks platform. The following figure gives an overview of the main components. The system adheres to the n-tier architecture, with emphasis on being open, modular, scalable and extensible, and on using open standards and protocols. It consists of four (4) different layers: the Access Layer, the Application Layer, the Data Access Layer and the Resources and Data Layer.

Figure 1: Main components to be developed within City.Risks

The four layers and their main components and interactions are briefly presented below.

The Access layer interacts with the external environment and the Application Layer and includes the following modules:

The Remote Interface which renders the content and dispatches it over the web (forms, results, etc.). The responses directed to mobile applications will be output using standard JSON objects containing the relative information and data. A Web UI will, also, be implemented using the web framework Spring MVC [12]. Special care will be given to provide a user friendly, flexible, secure, dynamically generated UI. Augmentation facilities are available to provide augmented interfaces populated with various different layers, e.g. the crime maps layer, user networks layer, etc.

The User Management module, which is responsible for providing the tools and means to manage users, administrators, etc. This module will be built on top of the PostgreSQL relational database manager and a NoSQL database, the Neo4j popular open-source graph database. On the module a set of user directories will be created, containing user objects, groups, permissions, roles, etc.



Authentication and Authorization, for controlling access and enforcing permissions and policies. The module will be implemented using the Spring Security. Spring Security is a framework that focuses on providing both authentication and authorization to Java applications. A part from its comprehensive and extensible support for both Authentication and Authorization it also features mechanism for protection against attacks like session fixation, clickjacking, cross site request forgery, etc.

Accounting and Policy Manager for handling the various contracts signed with any other City.Risks instances in order to exchange data and services. The communication between two or more City.Risks installations will be performed in an unattended way without human intervention.

Communication APIs and Web Services, providing interfaces to external software components to communicate with the City.Risks platform. This is a desirable feature for a service-oriented and a “Software as a Service” approach that will be followed in City.Risks.

The Application layer includes the following subsystems:

The Risks management subsystem that further includes the Alarm manager and scheduler, the Multimedia stream handler, the Sensor-based theft detection module and a set of Risk management algorithms implementations (e.g. evacuation management, etc.). This subsystem is triggered when responding to an ongoing security threat. A citizen end user on the crime scene can act as reporter by streaming live video directly from the scene. This is handled by the multimedia stream handler which prioritizes streams and informs the responsible to handle the crisis (in the operations center) about the severity. The sensor-based theft detection module is responsible for collecting information from mobile devices about stolen objects identified in their range.

The Operations center subsystem, which allows to monitor particular crime incidents in real time, visualize gathered information from “ground reporters'” video streams and other data, automatically correlate past incidents, make simulations based on environment data (3D models, maps, etc.) and evacuation models, and act as needed by eventually involving other organizations (e.g. police, etc.). The subsystem further comprises the Simulation and visualization module, a repository of 3D models, GIS maps, environment models covering the monitored urban area, the Incident and history analyzer module and the BI and mining module. These analyze particular scenarios and data based on previous knowledge of the system, in order to find patterns, recognize seasonality and to prepare the population of the “crime layer” on top of geographical maps, which are eventually, displayed also as geo-based augmented reality views or interactive maps to the end users.

The Core platform includes the Tools and implementations registry, allowing tools and implementations to be easily included as new services and modules. It also includes the Logging and Reporting module to easily create reports based on various criteria and parameters, the Configuration and data



model for defining internal data representations and configure the platform, the User Network module to keep the interconnection between members and exploit the social aspects of the platform, and the Messaging module that handles the communication with the mobile users, able to push notifications and receive information form mobile handsets. An additional module of this subsystem includes the Data acquisition module, for collecting and integrating data from various sources.

The Data Access Layer, containing a set of frameworks that optimize the access to the data sources. Among others the Hibernate framework is an object-relational mapping framework which facilitates the mapping of an object-oriented domain model to a traditional relational database (e.g. by mapping Java classes to database tables and from Java data types to SQL data types).

The Resources and Data layer, including the City.Risks' enhanced crime-related data repository. This layer also includes the database containing the device Ids used in the theft prevention and detection sensors, GIS maps and environment data and models. The databases design will offer a flexible model based on a “concept dictionary” schema that describes all the data items that can be stored in the system such as data needed by third party applications, new developed applications, etc.

The following figure gives a more detailed view on the interactions between the City.Risks core platform and the user devices.

Figure 2: Main interactions of the City.Risks core platform



4. City.Risks core platform specification

4.1. Technical specification of components and interfaces

4.1.1. User network module: User management and user profile

As a core functionality of every platform that deals with users, the specific module is responsible for allowing a set of functionalities that have to do with the user: registration, profile management, functionalities regarding the forming of communities etc. The data that are provided by the user during his registration should contain among others, the name, the username, birthday, gender, email and the country. Not all of them are mandatory, but at least should be able to provide a full profile following the trends applied in the widely used social networks. Additional features will be created and maintained by the system such as various timestamps (profile creation date), if the user is active, what is the role of the users, what is the networking of the user and the connections he has with other users of the platform etc.

The user will be able to manage his profile and update the respective fields. Moreover, he has the ability to register through his profile information regarding theft detector sensors that he is deploying in his assets and manage them accordingly (create, read, update, delete). The data that the user can provide for such a registration include among others the device ID, the type, model and serial number of such a device, the verification code (required for the activation and validation of the device), comments etc.

Another important functionality of the user network module is about the creation of a user community within the City.Risks platform. Every registered user in the platform is able to create a community (a social network of participating City.Risks users) or subscribe to an already existing one. This procedure of community building and management is of course subject to moderation according to the role of the user in the core platform. The communities can be built around a neighborhood in the city or around specific categories of population or of crime related events.

4.1.2. Messaging: Notification triggering and storing

The City.Risks core platform is equipped with the appropriate mechanisms to send specific notifications to the mobile devices of the end users, supporting thus an important functionality which has to do with updating end users in cases of emergency (e.g. in order to evacuate an area or be particular careful due to an ongoing incident). Every user device is going to be registered in the core platform when the user is creating his/her profile. When the user downloads the City.Risks mobile application from the respective Application Store (Google for Android devices and App store for iOS devices) the respective mobile application will be assigned a unique device ID which will be registered in the City.Risks data base. Whenever, the



operator of the Operations Center needs to send a specific message to an individual user or user group (based on various parameters such as location etc.), he will define the message and the user groups to receive it. In the sequel the messaging mechanism will retrieve the device IDs of the specific users and will send the message through the application which will cast it directly to native application of the devices as those are identified by the device ID. The specific functionality will be able to support also the casting of stored messages which will be triggered and sent in specific occasions under a set of predefined conditions and parameters that are set by the operator.

4.1.3. Rules and Policies Implementation

The rules and policies module will cover a very important functionality of the core platform which has to deal with the definition and enforcement of conditions under which various activities of the platform will be performed. The policies will be stored in the data base of the platform as a set of conditions that influence the functionalities and the workflow of the City.Risks services. The policies that will be applied will have to do with:

i) Privacy issues: the specific policy will handle the privacy parameters of the content and the interactions between the end users with the operation center, and between the user communities that will be formed in the City.Risks.

ii) User communities: definition of policies regarding the formation and management of user communities, ways of interaction and exchange of information.

iii) Application specific policies: for every application to be provided in the City.Risks use cases a set of policies will be defined and applied. The policy will deal with “what will be casted from the devices”, “who is responsible for receiving and managing the messages”, “who is authorized to send information to the end users through the notification mechanism” etc.

The aforementioned policies will be detailed in a set of rules parameterized as a configuration schema which will influence the functionalities of the platform. In this way the entities participating in a workflow will adhere to the specific rules and conditions implementing thus the determined policies. The enforcement of the policies will be monitored through the logging and reporting system.

4.1.4. Logging and Reporting

The logging and reporting module is responsible for keeping the overall logging of events and transactions that are being performed with the City.Risks core platform. The specific module will be useful as a mechanism for keeping track of platform specific events for purposes of debugging, performance, optimization and accounting of usage. Moreover, it is responsible to provide reports as part of a



broader mechanism that will derive usage results and information insight about the usage of the City.Risks platform.

The logging-side functionality of the module is going to contain a log ID, a description of the value that is logged, the value itself, the nature of any other media captured as part of the specific event (e.g. an image).

The reporting-side functionality of the module is going to facilitate the extraction of specific and custom made reports as part of predefined (or tailor-made) queries in the City.Risks platform data base. The reporting functionality will deliver various report based on the events occurred in the core platform including overall usage, events occurred (in specific time windows), number of users registered, number of active users, nature of events/transactions of the core platform and others. Reporting module is based on the Eclipse's Business Intelligence and Reporting Tools (BIRT). BIRT [13] is an open source software project that provides the BIRT technology platform to create data visualizations and reports that can be embedded into rich client and web applications, especially those based on Java and Java EE.

A single report can include data from any number of data sources while a significant feature is that it allows disparate data sources to be combined using inner and outer joins in the data bases. Reports will present data sorted, summarized, filtered and grouped to fit the user's needs allowing also more sophisticated operations such as grouping on sums, percentages of overall totals and others. Moreover, business logic will be applied to data converting raw data residing in the data bases into information useful for the user. The reports will be visualized through a wide range of options including tables, charts, text and more.

4.1.5. Configuration and data model

The City Risks data model is built using J2EE technologies. Namely, it uses the JPA 2.1 specification (JSR-000338), implemented, in this case, by the Hibernate ORM framework. All database tables & relationships between them are mapped to matching Java JPA entities (i.e. POJOs enhanced with annotations). During the initial design stage, a 'bottom-up' approach was followed, by reverse-engineering a pre-compiled SQL database schema into the aforementioned POJOs. Future model changes can, however, use the 'top-down' approach, by directly having changes made to POJOs reflected onto the database schema.

4.1.6. Security aspects and measures for the core platform

The City.Risks core platform is designed taking into consideration that it has to contain state-of-the-art measures for security. In particular, the main security aspects that are addressed involve authentication, authorization and confidentiality which will be achieved through the adoption of specific technologies and tools.

The main technological pillar upon which the security aspects of City.Risks core platform will be based is the Spring Security framework [14]. Spring Security is a framework that focuses on providing authentication and authorization to Java



applications, protecting against attacks like session fixation, clickjacking, cross site request forgery, and others, Servlet API integration and many other functionalities that ensure security and privacy of the services offered to the users.

“Authentication” is the process of establishing a principal is who they claim to be (a “principal” generally means a user, device or some other system which can perform an action in your application). “Authorization” refers to the process of deciding whether a principal is allowed to perform an action within your application. To arrive at the point where an authorization decision is needed, the identity of the principal has already been established by the authentication process. These concepts are common in Spring Security. Moreover, “confidentiality” refers to the process of having a guarantee that a message will not be read by an un-authorized person (basically through encryption which is based on keys that only the two communicating parties know). Confidentiality can be achieved by protocols such SSL or HTTPS, in order to protect passwords from eavesdropping or end users from man-in-the-middle attacks. This is especially helpful to protect password recovery processes from brute force attacks, or simply to make it harder for people to duplicate the application's key content. Spring Security fully supports automatic "channel security", together with JCaptcha integration for human user detection.

Spring Security provides a deep set of authorization capabilities. There are three main areas of interest in respect of authorization, these being authorizing web requests, authorizing whether methods can be invoked, and authorizing access to individual domain object instances. Spring Security provides deep capabilities in all of these important areas.

4.2. Related diagrams and workflows

The following diagram gives an overview of the device registration procedure in the core platform of City.Risks.

Figure 3: Message sequence diagram for the Registration of a device



The following figure gives an overview of the use case diagram with the functionalities offered to the end user by the platform.

Figure 4: Use Case diagram for the end user of the City.Risks platform

The following figure presents the use case diagram with the policy management functionalities offered to the Operation Center (OC) user.

Figure 5: Use Case diagram for the City.Risks policies

The following two figures provide an overview of the message sequence for the logging and reporting functionalities of the core platform respectively.



Figure 6: Message sequence diagram for the event logging

Figure 7: Message sequence diagram for the reporting mechanism

The following figure provides an overview of the notification mechanism message sequence and the participating entities in this workflow.



Figure 8: Message sequence diagram for the notification mechanism

4.3. Linking to requirements

The following table illustrates how some of the City.Risks requirements (listed in deliverable D2.4) have driven the definition of the architecture.

Code Requirements Description Impact/Relation to Architecture

R1.7.2 The Core Platform can provide low level system monitoring and event logging.

A dedicated component has been designed for this purpose allowing to have a variety parameter event logging for auditing and reporting issues.

R1.7.3 The Core Platform subsystem is able to provide an infrastructure for managing user communities, e.g., creating communities and updating community memberships.

End users of the City.Risks platform should be able to form social networks and communities as it is the case with the most spread social networks. Moderation of these communities should be provided as well. This is part of the user management module.

R1.7.4 The Core Platform subsystem is able to provide an infrastructure for managing community policies, e.g., roles and access.

Rules and policies are part of the privacy preservation mechanisms. A dedicated module is therefore implemented allowing the definition, monitoring and enforcement of these rules and policies.

R1.4.1 The Interoperability subsystem can enable program-to-program interoperability using an API and open web standards-based protocols (e.g. HTTP, SOAP, XML, etc.).

The City.Risks core platform is implemented around its ability to interoperate with other services through open interfaces and APIs.

R1.4.2 The Interoperability subsystem Third party applications can provide and



can allow a third-party application to access and query data to provide additional features on top of the City.Risks platform.

query data from the core platform as long as the authorization scheme (imposed through the authentication, authorization and access mechanisms) is allowed.

R1.3.1 The Web Portal subsystem can provide an interface to create and edit user profile with personal information and preferences, including rules and policies for sharing information.

This is part of the functionality offered to the end user when registering his/her profile and managing the data provided there accordingly.

R1.3.3 The Web Portal subsystem can allow the registration of a theft detection sensor with the Operation Center.

This is part of the functionality offered to the end user when registering his/her profile and managing the devices he/she is associated with. This includes the mobile phone and the theft detection sensors.

R1.3.4 The Web Portal subsystem can provide an interface to create communities.

As in R1.7.4.

R1.3.5 The Web Portal subsystem can allow a user to join an existing community or leave an existing community that she/he is a member of.

This functionality is part of the broader user management and community formation procedure that is supported by the core platform ant the City.Risks data base.

R1.3.6 The Web Portal subsystem can allow a user to post text messages in the community that she/he is a part of.

The specific functionality is covered by the messaging and notification mechanism.

R1.3.7 The Web Portal subsystem can allow a user to post multimedia files, such as images, audio and videos, in the community that she/he is a part of.

As in R1.3.6.



5. City.Risks mobile application

The City.Risks App provides an interface to City.Risks functionality for the end user, the citizen. It connects to City.Risks services to retrieve or supply information in a situation-related way, that is, it takes context information such as a user’s profile, location or time into account.

It, furthermore, connects to City.Risks Apps of other users in the immediate vicinity, to support peer-to-peer functionality as well as to small sensor devices, to locate them or exchange data directly.

The App provides a simple, easy-to-use interface, employing augmented reality visualisation techniques for the user to display information in context and to get in contact with authorities or other City.Risks users.

Communication between City.Risks apps, sensors and services use an event-driven approach to enable near real-time notifications about important changes in the global, local or personal situation of a user.

The City.Risks App is one building block of the City.Risks system that is integrated in a wider network of services and components. On order to be open and, flexible, useful and to increase the reach of City.Risks functionality, the system needs to support the various deployment options (see figure below).

Figure 9: City.Risks building blocks.




The City.Risks App uses different local services as well as interface components to connect to City.Risks and third party services.

Figure 10: App components.

Currently, eight components have been identified on a more general level that can be assigned to four categories.

City.Risks service interfaces

Profile Management

Service Area Management

Content Management

Notification Management

Third-party service interfaces

Location Service

Geocoding Service

Communication interfaces

Peer-to-Peer Communication Services

User interface services

Visualisation Services

5.1.1. Profile Management

Profile management is responsible for managing a user’s personal information on device as well as – in an anonymised way – on the City.Risks server. The major component is the Profile Manager that provides interfaces to bind profile management functionality into the application logic of the app. It uses a Profile



Service interface component to connect to the City.Risks profile services to create, load or update the user’s profile.

To store the master profile of the user with all sensitive data (not or only partially shared with different services) locally on the device, the Profile Manager uses a Profile Database.

The Profile Service connects to an HTTP REST-based interface provided by the City.Risks profile services to exchange information in JSON format in an asynchronous way. The concept for implementing asynchronous operations is detailed below (Sec 5.1.8).

The Profile Database is based on an on-device sqlite database. It also uses platform-dependent storage facilities to store sensitive data in a safe and secure way, if available.

Figure 11: Profile management.

Implementation and Deployment

The profile management will be implemented as an independent, platform-specific library module. The module will be then integrated in the City.Risks app. This enables to easily create different versions of the app based on a robust implementation of underlying functionality.

To facilitate integration of smaller parts of City.Risks functionality into external third party apps, the profile management module will include a light variant, exposing only the most necessary parts like registering an anonymous user or device identification.

5.1.2. Service (Area) Management

Service areas describe geographical areas in which a City.Risks service is available. The concept of service areas provides modularisation and distribution of data as well as responsibility for content delivery. A service area specifies the location (URL) of the content delivery endpoint providing the data of a certain content service for a



certain geographical area. For example, to provide crime incident information for different cities, we would define separate crime incident service endpoints for the cities. All of these endpoints may have their own databases and data management responsibilities. The service areas for the crime incident service tell users the geographical extents specific endpoints are covering.

In so far the concept facilitates the idea of service roaming, such that services can be distributed and managed locally, but remain globally available.

Furthermore, the service area concept allows for discovery of certain content services, based on a user’s location.

The major component is the Service Area Manager that provides interfaces to bind service discovery functionality into the application logic of the app. It uses a Service Area Service interface component to connect to the City.Risks service area service to load or update the service availability information on the device.

To enable information caching, the Service Area Manager uses a Service Area Cache.

The Service Area Service connects to an HTTP REST-based interface provided by the City.Risks service area service to load information in JSON format in an asynchronous way. The concept for implementing asynchronous operations is detailed below (Ref).

The Service Area Cache is based on an on-device sqlite database.

Figure 12: Service area management.


The service management will be implemented as an independent, platform-specific library module. The module will be then integrated in the City.Risks app. This enables to easily create different versions of the app based on a robust implementation of underlying functionality.



5.1.3. Content Management

The content management is responsible for accessing, storing and providing content information. Content means here pieces of information (text, audio, and video). In general content will have a spatio-temporal validity attached to it, described by geo-location and valid time information. This meta information is used for filtering, sorting and prioritising when loading, accessing and displaying content.

For City.Risks, it is planned to support two paradigms for communicating content.

• a request response model

• a streaming model (http streaming)

The request-response model will be implemented by the content management. For the streaming model there will be a two-step implementation; in the initial phase we plan to link to periscope.tv [15] a well-known App and scalable platform for live-streaming videos, in a second phase we may integrate streaming functionality directly into the app by connecting to a media server provided by the City.Risks core platform.

The major component is the Content Manager that provides interfaces to bind content management functionality into the application logic of the app. It uses a Content Service interface component to connect to the City.Risks content services to create, load or update content.

To enable caching of content locally on the device, the Content Manager uses a Content Cache.

The Content Service connects to an HTTP REST-based interface provided by the City.Risks content services to exchange information in JSON format in an asynchronous way.

The Content Database is based on an on-device sqlite database.

Figure 13: Content management.




The content management will be implemented as an independent, platform-specific library module. The module will be then integrated in the City.Risks app. This enables to easily create different versions of the app based on a robust implementation of underlying functionality.

5.1.4. Notification Service

The Notification Service is responsible for registering with the platform- specific push infrastructure and to handle incoming notifications. Since this handling is very platform-specific and need to be implemented using the schemes the respective platform provides.

Geocoding Service

The Geocoding Service will be used to integrate with the platform-dependent geocoding and reverse geocoding service of the mobile platform, the App is running on, as well as dedicated geo-based services of the City.Risks platform. The functionality of the service will be used to resolve address information from geolocations and vice versa.


The geocoding service will be implemented as utility class inside the City.Risks app.

5.1.5. Location Service

The Location Service will be used to tap into the operation-system-specific positioning services of the mobile device (e.g., GPS and/or network-based positioning) to get single or continued updates of a devices position, for instance, to add metadata to content recorded, or to query location-related content depending on the concrete application case.


The location service will be implemented as utility class inside the City.Risks app.

5.1.6. Communication Services

Communication Services will provide functionality for users to communicate directly with each other or to other user groups based on a publish/subscribe messaging infrastructure. This functionality is not intended to replace existing messaging infrastructures, but to replicate most fundamental functions for text-based messaging for use within the app.

A second group of functions the communication services provide is proximity based communication with theft detection tokens. Recovery of and data exchange with such tokens will be based on common Bluetooth LE functionality, that is available on newer Smartphone hardware.




The communication services will be implemented as independent, platform-specific library modules. The modules will be then integrated in the City.Risks app. This enables to easily create different versions of the app based on a robust implementation of underlying functionality.

5.1.7. Visualisation Service

The Visualisation Service provides the user interface with 1D (POIs), 2D (Lines, Areas) and potentially 3D (Models) representations used for maps or augmented reality views. It encapsulates platform specific details and provides a unified programming interface (API). The visualisation service might also make use of cloud based rendering or presentation services to off-load processing or data intensive tasks from the smartphone which can improve performance or enable complex visualisations.


The visualisation service will be implemented as an independent, platform-specific library module. The module will be then integrated in the City.Risks app. This enables to easily create different versions of the app based on a robust implementation of underlying functionality.

5.1.8. Operation Manager

The Operation Management provides a way for an app to execute asynchronous service calls. If one has an App that is a bit more complex, the problem is that the App will need to execute specific service calls, which may depend on the result of more general service calls. For example, requesting updated content for a certain location, the App needs to know which content services covering the location are currently available, in order to contact them afterwards. Since these requests need to be made asynchronously we need to chain them, such that the result of the first is delivered as parameter to the next. This can be done using a functional programming paradigm known as Futures or Promises.

The second problem is that different parts of the App may try to do the same things in parallel. Imagine a tablet App with two parallel views for different types of content that need to be updated at start-up. Both will try to get the last known device location, then the list and details of available content services, in order to finally query the service delivering their content to be displayed.

In order to be able to execute commonly used queries only once and share its results, service requests will be wrapped by operations; a single operation instance being responsible for executing a specific service request. A caller submitting an operation can register a completion handler (a function that is called as soon as the result is available). Operations can be chained by specifying dependencies.

Note. This is to be meant as a description of an abstract concept of asynchronous operations, not as a blueprint for implementation. Both, the iOS and Android platform provide the necessary means to implement the kind of scheme described, although, at very different levels of abstraction.



Figure 14: Asynchronous operations.


The following diagrams illustrate major workflows within the mobile app.

Profile Management

On startup, the app will try to synchronize its profile information with the version on the server. It first tries to get the profile stored locally on device. If a local profile cannot be found, it tries to load the remote profile from the server. If the remote profile exists, the profile manager stores it locally on the device.

Figure 15: Loading an existing profile from the server.

If a remote profile does not yet exist, the profile manager creates a new one, stores it locally and sends it to the server.



Figure 16: Creating a new profile.

If a local profile is found on app startup, the profile management loads version information of the remote profile from the server, compares it with version information found for the local one and updates the remote profile if there is a conflict.

Figure 17: Syncing a local profile with the server-stored version.

Content Management

Also content management will check on app startup whether there are updates to specific content. It therefore retrieves version information from the local cache and uses it when loading content from the remote server. If the server returns an updated version the item will be stored in the local cache.

Figure 18: Updating a content item.

Service Area Management



Using information from the user profile (current or favourite locations) the service area manager updates area of service information relevant to the user. Service area information specifies URLs pointing to content services providing City.Risk content for a user’s location. These URLs will be used afterwards to access relevant content.

Figure 19: Discovering content services.

Operations

Asynchronous operations are used to help loading information from City.Risks services (e.g., from profile, service area and content services). On startup, the app creates an operation manager (which in turn creates an operation queue and an executor). The executor, then, waits for operations to be executed. Afterwards, the application logic can create an operation, for instance, to synchronize the profile; it submits the operation along with a code block (a completion handler) that is to be executed when the operation is finished. The operation is queued and then forwarded to excutor. The executor executes the operation, takes the results and calls the completion handler.

Figure 20: Executing asynchronous operations.




The following table illustrates how City.Risks requirements (listed in deliverable D2.4) have driven the definition of the architecture.


R1.1.1 An MAU is able to create and edit her/his profile with personal information and preferences, including rules and policies for sharing information.

handled by profile management

R1.1.2 An MAU is able to create and send an incident report to the Operation Center.

handled by content management

R1.1.3 An MAU is able to receive location-based notifications, including warnings and alerts.

handled by notification service

R1.1.4 An MAU is able to capture and send multimedia content, such as audio, video and images, via the mobile application to the Operation Center subsystem.


R1.1.5

An MAU is able to view crime statistics by location, time and type on a map.

this functionality will be shifted from the mobile app to the end user web portal

R1.1.6 An MAU is able to view safety indicators for an area, e.g., safety levels for women, LGBT citizens or ethnic minorities.

handled by UI

R1.1.7

An MAU is able to use augmented reality to view the crime-related information about her/his surroundings.

handled by the visualisation service

R1.1.8 An MAU is able to interact with objects presented in augmented reality, i.e., add information to objects, update objects and create new objects.

handled by the visualisation service

R1.1.9 An MAU is able to register a theft detection sensor with the Operation Center.

handled by profile management

R1.1.10 An MAU is able to report a theft to the Operation Center via the mobile application.


R1.1.11 An MAU is able to reject or confirm a received vehicle theft notification.




R1.1.12 An MAU is able to inform the Operation Center about the sighting of a stolen vehicle.


R1.1.13 An MAU is able to notify the Operation Center subsystem about the need for help.


R1.1.14 An MAU is able to create a trusted network who will be informed when she/he might be in danger.


R1.1.15 An MAU is able to receive personalized and visualized risk information about an area through updates, maps and mAR based on their profile, location, time and preferences.


R1.1.16 An MAU is able to search for routes between two locations on a map.


R1.1.17 An MAU is able to view safety related information on routes between two locations on a map.

handled by UI and visualisation services

R1.1.18

An MAU is able receive ride sharing recommendations from the Operation Center.


R1.1.19

An MAU is able to send requests for ride sharing recommendations to the Operation Center.


R1.1.20

An MAU is able to report problems and complaints, such as illegal dropping of waste and illegal business activity, to the Operation Center subsystem.


R1.1.21 An MAU is able to create communities.


R1.1.22

An MAU is able to post text messages in the community that she/he is a part of.

handled by communication services

R1.1.24

An MAU is able to post multimedia files, such as images, audio and videos, in the community that she/he is a part of.


R1.1.25

An MAU is able to send requests for witnesses to the Operation Center subsystem with the incident location




and time.

R1.1.26 An MAU is able to specify a storage limit for her/his history of locations and timestamps on the mobile device.

handled by UI and content management

R1.1.27

An MAU is able to receive requests for witnesses by the Operation Center subsystem.


R1.1.28

An MAU is able to confirm or reject requests for witnesses from the Operation Center subsystem.

handled by UI and content management

R1.9.1 The mobile application is able to communicate with the Operation Center subsystem over wireless interfaces.

handled through the use of asynchronous operations

R1.9.2 The mobile application is able to identify a specific theft detection sensor or IoT device, i.e., a sensor or IoT device attached to an item/vehicle that was stolen


R1.9.3 The mobile application is able to provide a dynamic, high-performance, cloud-based and OGC-conforming Web Processing Service (WPS) for generating and providing dynamic mobile Augmented Reality (mAR) representations in real-time.

handled by visualisation services

R1.9.4 The mobile application provides an interface for rendering, generating and modifying content based on the mAR data description language.


R1.9.5 The mobile application is able to interact with the mAR WPS for generating and displaying dynamic mAR representations in real-time.


R1.9.6 The mobile application is able to display safety and risk information in the mAR view of the mobile device.


R1.9.7 The mobile application is able to communicate with theft detection sensors via a proximity-based mechanism.


R1.9.8 The mobile application is able to receive a short-range signal from a theft detection sensor.


R1.9.9 The mobile application is able to handled by content management



send a notification with the position, time and ID of a nearby theft detection sensor to the Operation Center.

R1.9.10 The mobile application is able to receive vehicle theft notification from an IoT device.


R1.9.11 The mobile application is able to send vehicle theft information to the Operation Center.


R1.9.12 The mobile application is able to poll the Operation Center subsystem for cases that require witnesses.


R1.9.13 The mobile application is able to evaluate based on location history if it was in the spatial and temporal range of an incident.

this functionality will be provided by the application services of the City.Risks backend

R1.9.14 The mobile application is able to send a confirmation to the Operation Center subsystem only after the MAU has verified that she/he would like to act as a witness in the case.


R2.5.1 The mobile application, Operation Center and Web Portal interfaces are is user-friendly.

through UI and visualisation services

R2.5.4 The registration of theft detection sensor with the Operation Center is user-friendly and straightforward.

through UI and communication services



6. Theft detection sensors specification and communication protocol


Following the findings from the state of the art update it was concluded that an alternative technical approach could be considered and realized. The proposed system architecture is illustrated in the following figure:

Figure 21: Basic architecture of BLE device activated by a BLE/WiFi Gateway

Our approach foresees two alternative activation mechanisms:

via BLE/WiFi gateway, and

via the smartphones of the community users, which forward the wake up signal to the BLE device

The key challenge of the design is how distance between a Base Station and BLE device can be covered. Therefore instead of implementing a WuR (wake-up radio receiver) along with a BLE device positioned in the asset, it should equally be advantageous to deploy a BLE/WiFi gateway that would equally cover and reach the BLE anti-theft sensor.

The core components of the architecture are the following:

Battery powered BLE sensor device

BLE/ WiFi Radio gateway to enable communication with the City.Risks

Platform

City Risks Mobile application to communicate with BLE devices and report

asset’s position to the City.Risks platform

The solution as proposed with the BLE installed on the base station is an alternative approach that could also reliably work for our application.




BLE device shall be able to operate in two different roles, in particular observer (scanning mode) and advertiser (beacon mode).

Observer (scanning mode): This is the mode the device is when a theft

incident occurs. We use this mode instead of advertising so we can make our

device as untraceable as we can. In this state the device does not transmit

anything. Outside sources can connect to it by using the Unique Device

Identifier (UDI). The UDI is provided to the Authority by the user that reports

the theft. The Authority in turn provides the selected app-users and beacons

with it so they can activate the device. This is the way to secure that none can

activate the device if it is not stolen.

Beacon (advertiser mode): In this mode the device is activated and notifies

every app-user or beacon for its status.

To achieve optimal power consumption when the device is in range of the owner’s

mobile, the device will be connected to the owner in sleep mode. Workflow chart is

presented below:

Figure 22: BLE Device Operational scenario


The following table illustrates how certain City.Risks requirements as listed in deliverable D2.4 (associated with Use Case 1) have driven the definition of the architecture:


R1.1.10.1 The theft detection sensor is able to function for a long time period without an

BLE anti-theft device shall be designed to be powered on by a small battery (CRC type)



external power source

R1.10.2 The theft detection sensor can be attached to a personal item, such as handbag, luggage or bicycle.

Design of sensor shall take into consideration the overall size in order to be easily positioned or installed in bicycles or medium-scaled belongings (luggage, bag, etc.)

R1.10.3 The theft detection sensor is able to communicate with the mobile application using Bluetooth Low Energy radio.

Communication between anti-theft device and mobile application shall be based on BLE. Related services and informational data exchanged between them shall be designed according to BLE protocol stack.

R1.10.4 The theft detection sensor is able to broadcast a signal periodically to mobile devices in proximity.

Software Application of the BLE device shall include the required functionality to turn the device into beacon mode and enable its periodical transmission of the alarm signal.

R1.10.5 The theft detection sensor is able to go into hibernation mode.

Device application logic shall envisage the sleep status for the BLE device for maintain low battery consumption.

R1.10.6 The theft detection sensor is able to get activated by a remote signal from the Operation Center subsystem.

BLE/Radio Bridge shall operate as a transmission medium broadcasting the alarm signal, initially generated by the Operation Center subsystem hosted in Authority premises.



7. Data Application programming Interface layer


7.1.1. PostgreSQL as content repository

PostgreSQL is a powerful, cross-platform, open-source, object-relational DBMS. It can handle varying workloads, ranging from small single-machine applications to large web applications with many concurrent users. Moreover, it can be extended with user-defined data types, functions, operators, indexing methods, etc.

PostgreSQL employs a client/server model, and each session consists of two types of processes. A server process works in the backend and manages the database files, accepts connections to the database from client applications, and performs database actions (insert, delete, update, select, etc.) requested by the clients. A client is a frontend application (like a command-line terminal, a graphical interface, a web server, etc.) that can perform database operations. It also provides native programming interfaces for many languages, including C/C++, Java, .Net, Perl, Python, Ruby, Tcl, ODBC, etc.

In addition to relational data, recent versions of PostgreSQL can be used to store raw JSON data in the database, retaining all the orders of any keys and any duplicate keys in a special JSON data type. Not only can the entire document be preserved without loss, but its parsing can be effectuated once data is inserted and then stored in a JSONB representation. Afterwards, no parsing is required in order to access this JSON data. What is more, a Generalized Inverted Index (GIN) can be constructed over the key/value pairs, offering fast retrieval.

7.1.1.1. Spatial support with PostGIS

Regarding support for geospatial data management, in the City.Risks repository we make use of open-source PostGIS, which is an extension to PostgreSQL. There is also support for raster datasets with module PostGIS Raster integrated in its latest versions. PostGIS implementation takes advantage of several open-source elements. Among the most important ones, Proj4 library offers coordinate re-projection support within PostGIS, i.e., functions that can help transforming geometries from one SRID to another. Besides, GEOS library provides functions that are used to determine topological relationships and to compute geospatial set operations, in addition to improvements in geometry validation.

Spatial vector features are stored in an attribute of a PostgreSQL table of special type GEOMETRY or GEOGRAPHY. Both Well-Known-Text (WKT) and Well-Known-Binary (WKB) representations of geometries include information about the type (point, polygon, linestring, etc.) of the object and its coordinates. Internal storage in GEOMETRY requires that each spatial object must include a spatial referencing



system identifier (SRID) as well. However, PostGIS enhances the OGC standard with its EWKB/EWKT formats for GEOMETRY with more than 2 dimensions.

Various de facto GIS formats (ESRI shapefiles, MapInfo, GML, DGN, AutoCAD DXF, etc.) can be read through GDAL/OGR libraries and readily imported into PostGIS with a great variety of tools. Stored geometries can be accessed through external applications via ODBC and JDBC. Last, but not least, PostGIS data can be used as source for serving geospatial content on the Web, easily coupled with software like MapServer or GeoServer, as well as for map visualisations according to OGC-specified services like WMS or WFS.

7.1.1.2. Routing capabilities with pgRouting

Since geospatial data will be hosted in a PostGIS/PostgreSQL database, we will make use of its pgRouting extension in order to provide geospatial routing and other network analysis functionality. pgRouting provides functions for Shortest Path (various algorithms like Johnson, Floyd-Warshall, A*, Dijkstra, etc.), Traveling Sales Person (TSP), and more. Furthermore, in case that the original road network comes from OSM, pgRouting offers osm2pgrouting, a command line tool that allows importing OSM data into a pgRouting database in PostGIS. It builds the routing network topology automatically and creates tables for feature types and road classes.

7.1.2. Geoserver

Access to content having a geospatial dimension in the City.Risks repository will be based on GeoServer [16], an open source, community-driven server written in Java that enables sharing and editing of geospatial data. It can be used to publish geospatial data on the Web from a multitude of data sources (spatially-enabled DBMS, various file formats, rasters, etc.). In particular, GeoServer is the reference implementation of a server for the following OGC standards:

Web Map Service (WMS) supports requests for map illustrations and returns

images (not only in raster, but in graphics format as well) composed from the

geographical features.

Web Feature Service (WFS) supports requests for geographical feature data

and returns vector geometry objects and their attributes that qualify to user

specified filters (spatial, temporal, scalar, etc.).

Web Coverage Service (WCS) supports requests for coverage data (i.e.,

rasters) that represent space-varying phenomena. In contrast to WMS that

can also return an image, the result of WCS includes metadata to the raster

and thus can allow queries for further analysis over the received data.

Next, we provide some more details about WMS and WFS and how they can be used to provide access to the City.Risks content repository through GeoServer.



7.1.2.1. Web Map Service

WMS is a standard protocol specified by OGC in order to serve georeferenced map images on the Web using HTTP. These images are composed upon a user request using a standard web URL to a map server, which dynamically retrieves data from preconfigured sources, such as a geospatial database (e.g., PostGIS) or geographical files. A WMS server usually returns a screenshot of the map in a bitmap format (i.e., raster), such as PNG (default), JPEG, GIF, TIFF, or GeoTIFF. However, vector graphics may be provided as a result, like points, lines, curves and text, expressed in SVG or WebCGM format.

WMS standard specifies various types of requests:

GetCapabilities provides metadata about the properties of the WMS (image

format, service version, contact/publisher etc.) as well as the actual data

layers available (bounding box, spatial reference system, etc.).

GetMap operation requests the server to generate a map and return an

image. Parameters for this most frequently used request include: width and

height of the map, spatial reference system, image format, possibly a

rendering style specified according to the Styled Layer Descriptor (SLD)

standard [SLD], etc.

GetFeatureInfo requests data at a user-specified coordinate on the map,

provided that the respective map layer has been configured as queryable.

DescribeLayer returns the feature types of the specified layer(s), and its

support depends on whether a SLD Profile has been created in this WMS to

allow user-defined symbolisation and colouring of geographic features.

7.1.2.2. Web Feature Service

WFS is a standard protocol specified by OGC for discovering, querying, and manipulating vector geospatial data over the Web using HTTP. Clients can query both the data structure (e.g., identify the spatial table and its attributes) and also access its contents (i.e., the source data). The basic WFS allows querying and retrieval of geometry features. A transactional Web Feature Service (WFS-T) allows also creation, deletion, and updating of features. When a client posts such a request over HTTP, the WFS server executes it against the underlying geographical data and returns back the results. Vector results from a WFS request can be returned in various formats: principally GML (versions 2.x or 3.x), but also in GeoJSON, as ESRI shapefiles or .CSV files (Comma Separated Values).

The WMS standard specifies various types of requests. Those mostly related to our objectives in City.Risks are:

GetCapabilities provides metadata about the properties of the WFS (service

version, contact/publisher etc.) as well as a list of the operations, parameters

and services supported by the server.



DescribeFeatureType returns information about one or more feature types

(i.e., spatial tables corresponding to map layers). This will fetch a list of

features and attributes for each requested feature type and may be useful in

order to specify further requests to get the actual data.

GetFeature operation returns a selection of features from the data source

according to filters specified in the request, e.g., fetch all features, return

those qualifying in a bounding box, specify which attribute(s) to return

(geometry and other attributes), etc.

Each of the aforementioned requests should specify values for certain parameters in such operations. However, GeoServer will automatically provide default values if any parameters are omitted from a request.

In addition to the parametrization prescribed by the OGC standard, GeoServer implementation also includes WFS vendor parameters to provide enhanced capabilities. Among those supported are:

The cql_filter parameter is similar to the standard filter parameter, but the

filter is expressed using Extended Common Query Language, which provides a

more compact and readable syntax compared to the OGC XML filters.

Reprojection of geometries using parameter srsName: data may be actually

stored in any valid spatial reference system, but may be transformed into the

one specified by this parameter.

format_options parameter can be used to specify values that are format-

specific (e.g., for ESRI shapefiles or for generating identifiers in JSON output).

Moreover, the querylayer module in GeoServer adds filter functions that implement cross-layer filtering between two layers. This is very useful for analysis, since it can be used to retrieve features from a primary layer that qualify to a topological predicate (e.g., Intersects, Within, etc.) with respect to a secondary layer. For example, it can be used to identify locations of crime incidents (contained in the primary layer) that have occurred within selected administrative areas (the secondary layer).

7.1.3. Spring REST API

The Spring REST API that is used for the data API follows the HATEOAS (Hypermedia as the Engine of Application State), that is a constraint of the REST application architecture. HATEOAS as an approach brings actually the benefit that it decouples client and server in a way that allows the server functionality to evolve independently. This is particularly beneficial for modern applications which evolve in their server-side while being able to support a multitude of clients.

An additional characteristic of a RESTful API is the way it exposes to be discovered by third parties with no prior knowledge of its structure and services. This means practically that the client should be able to navigate the API by doing a GET on the root. Moving forward, all state changes are driven by the client using the available



and discoverable transitions that the REST API provides in representations (hence Representational State Transfer).

A hypermedia-driven site provides information to navigate the site's REST interfaces dynamically by including hypermedia links with the responses.

A HATEOAS-based response for example would look like this:

{

"name": "Alice",

"links": [ {

"rel": "self",

"href": "http://localhost:8080/customer/1"

} ]

}

This response not only has the person's name, but includes the self-linking URL where that person is located. “rel” means relationship and in this case, it is a self-referencing hyperlink (it can be also "rel":"customer" for example). “href” is a complete URL that uniquely defines the resource.

The City.Risks RESTful API supports the generation of a HATEOAS-based document profile as it can be seen below. This profile increases the re-usability of documents across media types by defining simple descriptions of application level semantics for every available repository. It contains information about both the RESTful transitions as well as the attributes of each repository, as it can be seen in the following profile in JSON format.

{

"_links" : {

"self" : {

"href" : "http://core.cityrisks.eu/cityrisks/api/profile"

},

"medias" : {

"href" : "http://core.cityrisks.eu/cityrisks/api/profile/medias"

},

"sensors" : {

"href" : "http://core.cityrisks.eu/cityrisks/api/profile/sensors"

},

"pois" : {

"href" : "http://core.cityrisks.eu/cityrisks/api/profile/pois"

},

"formats" : {

"href" : "http://core.cityrisks.eu/cityrisks/api/profile/formats"

},

"crUsers" : {

"href" : "http://core.cityrisks.eu/cityrisks/api/profile/crUsers"

},



"statuses" : {

"href" : "http://core.cityrisks.eu/cityrisks/api/profile/statuses"

},

"countries" : {

"href" : "http://core.cityrisks.eu/cityrisks/api/profile/countries"

},

"notifications" : {

"href" :

"http://core.cityrisks.eu/cityrisks/api/profile/notifications"

},

"types" : {

"href" : "http://core.cityrisks.eu/cityrisks/api/profile/types"

},

"metadatas" : {

"href" : "http://core.cityrisks.eu/cityrisks/api/profile/metadatas"

},

"devices" : {

"href" : "http://core.cityrisks.eu/cityrisks/api/profile/devices"

}

}

}




Figure 23: Data processing workflow diagram.

Data management in City.Risks involves several phases, ranging from data collection, cleansing and exploration, to their efficient processing, analysis and mining, up to their availability for queries and updates. Figure 23 illustrates this flow.

First, safety-related information may come from static data from open data catalogues, Law Enforcement Agencies, government organisations, or the pilot cities

Data sources

Content repository

Staging area

Cri

me

dat

a

Geo

grap

hic

in

form

atio

n

Dem

ogr

aph

ics

Soci

al m

edia

Sen

sors

&m

ob

ile d

evic

es

Web

ExtractTransform

Load

AnalysisIntegration

WMS à Maps WFS à Vector Geometries

Users & Communities

Mobile devices & user reports

Sensors

static data real-time feeds

GeoServer APISpring REST API



offering content regarding crime incidents and statistics, geographic maps, city demographics, etc. In addition, real-time data feeds may be crowdsourced from City.Risks users (comments, multimedia, etc.) and sensors (e.g., alert notifications). Moreover, online safety-related information may be collected from social media (e.g., Twitter) or the Web (e.g., news websites). As data gets collected, it will temporarily reside in a staging area before its acquisition in the City.Risks repository.

A collection of ETL (Extract-Transform-Load) tools will be employed for cleaning, converting and importing all collected datasets into the City.Risks repository. These tools may be custom scripts (e.g., written in Python or Java) developed specifically for each type of data, or out-of-the-shelf software (e.g., GeoTools) that can be used to manipulate the data.

Once the data is acquired in the City.Risks repository, it can be used for analysis and mining, whereas it will be also accessible to users according to specific policies. Original data may be used for mining tasks (e.g., identifying crime hotspots), machine learning (e.g., classifying zones w.r.t. safety risk), and any other kind of analysis (e.g., extracting statistics). Results derived from such tasks may be also archived in the repository in order to be permanently available.

Regarding data access, a RESTful API will be provided, allowing querying and managing data about users and communities, mobile devices and user reports, and sensors. Moreover, GeoServer will be used to serve geospatial data over the Web using open standard protocols endorsed by the OGC, in particular: (a) Web Map Service (WMS), which allows for map illustrations as images composed from the geographical features, and (b) Web Feature Service (WFS), which provides vector geometry features and their attributes that qualify to user-specified filters (spatial, temporal, scalar, etc.).


The following table outlines how the City.Risks requirements (listed in deliverable D2.4) have driven the definition of the architecture.


R1.1.5 An MAU is able to view crime

statistics by location, time

and type on a map.

Crime statistics can be aggregated

over varying spatial, temporal, and

classification granularities. Standard

visualisation functionality is offered by

GeoServer WMS/WFS.

R1.1.6 An MAU is able to view

safety indicators for an area,

e.g., safety levels for women,

LGBT citizens or ethnic

Once such safe indicators become

available for a given area (e.g., a

statistical zone or neighborhood), they

can be readily visualized through



minorities. GeoServer WMS/WFS.

R1.1.16 An MAU is able to search for

routes between two

locations on a map.

Functionality available through the

pgRouting module.

R1.1.17 An MAU is able to view

safety related information on

routes between two

locations on a map.

Functionality available through the

pgRouting module (for route

calculation) and the querylayer

module of GeoServer (for identifying

safety-related information along a

given route).

R1.2.1 An OCU is able to keep track

of ongoing incidents using

map and text-based

interfaces.

Ongoing incidents will be spatially

referenced, hence they can be

depicted on maps.

R1.2.2 An OCU is able to filter event

information based on event

attributes, such as location

and time.

All recorded events will carry spatial

and temporal reference, hence they

can be filtered using the respective

attributes.

R1.2.3 An OCU is able to aggregate

event information from

different sources.

This is handled by the integration /

contextualization modules.

R1.2.4 An OCU is able to visualize

event information over a

map.

All recorded events will carry spatial

and temporal reference, hence they

can be depicted on maps.

R1.2.6 An OCU is able to view

reports of an incident over a

map.

All incidents will be accompanied with

a spatial reference (location), hence

they can be illustrated on maps.

R1.2.7 An OCU is able to locate MAU

within a specific range of an

incident occurrence.

Provided that MAU report their

current location, an OCU can specify a

suitable spatial range query (using a

radius or a rectangle) in order to

identify them.

R1.2.8 An OCU is able to send

advisories and instructions to

MAU based on their location.

Provided that MAU report their

current location, an OCU can send

notifications and instructions (e.g.,

safe routes).



R1.3.2 The Web Portal subsystem

can display crime statistics by

location, time and type on a

map.

Crime statistics can be aggregated

over varying spatial, temporal, and

classification granularities. Standard

visualisation functionality is offered by

GeoServer WMS/WFS.

R1.5.1 The Operation Center

subsystem is able to provide

specific crime-related

structured data to the

security services via a REST

API based on parameters like

time period, area or type.

Safety-related data can be extracted

as GeoJSON or XML through properly

specified WFS requests to GeoServer

involving temporal, spatial and

thematic criteria for the data

extraction.


subsystem is able to extract

contextual data about an

incident from web sources.

This is handled by the integration /

contextualization modules over data

collected from Twitter, news articles,

etc.


subsystem is able to

determine an estimate reach

area around the last location

of a vehicle based on time.

Based on the routable road network

graph and the functionality of the

pgRouting module.


subsystem is able to re-

estimate the reach area

around the stolen area with

time.

Based on the routable road network

graph and the functionality of the

pgRouting module.


subsystem is able to provide

MAU information about

persons near them who need

help.

Through a spatial query in PostGIS

over available MAU locations.

R1.6.1 The Risks Management

subsystem is able to track the

position of an MAU.

Every relayed position from MAU may

be recorded in the repository.


subsystem is able to monitor

MAU near a specific MAU.

Every relayed position from MAU may

be recorded in the repository.




subsystem is able to monitor

static (maps, crime statistics)

and real-time (current events

and conditions) data about a

location.

Both static and real-time data feeds

will be spatially referenced at a

geographical location or zone.

Monitoring a given location can be

carried out through queries in PostGIS

or GeoServer WFS/WMS requests

involving spatial/temporal/thematic

criteria.


subsystem is able to

aggregate and visualize

event-related information.

Aggregation will be carried through

the data integration /

contextualization module.

Visualization through GeoServer

WFS/WMS.


Subsystem is able to mine

patterns, such as hotspots

and seasonality, using

internal and external crime-

related and contextual data.

This will be supported by the data

mining and contextualization modules.


subsystem is able to find ride

sharing recommendations for

a user.

Based on the routes computed by the

pgRouting module.

R1.8.1 The Resource and Data Layer

is able to add, update and

provide data through an API.

A Spring REST API will offer read/write

access to the content repository.

Especially for geospatial-related

information GeoServer will provide

read-only access to the content

repository.

R1.8.2 The Resource and Data layer

is able to access and update

different types of content

from different data sources.

This includes:

crime reports and

statistics

geospatial data

(maps)

Content repository for data collected

from different sources is implemented

in PostgreSQL using PostGIS for spatial

support. The database schema covers

all available sources either regarding

external, third-party data (such as

maps, crime statistics, demographics,

3D environment data, etc.) or internal,

user-contributed information (from



demographic data

3D environment data

(if available)

multimedia data

(audio, video, images)

theft detection sensor

registration data

(sensor registry)

applications and

services registration

data (tools registry)

user IDs, user profiles,

user groups and roles

(user registry)

sensors, users, applications, etc.).

R1.8.3 The Resource and Data layer

is able to support different

types of attribute-based

queries.

PostgreSQL (with its PostGIS spatial

extension) enables a variety of queries

involving spatial, temporal, and

thematic criteria. Similar requests can

be submitted for visualization and

data extraction using GeoServer

WFS/WMS.


is able to support different

types of analysis (i.e., offline,

real-time and continuous).

This will be handled by the data

analysis components.


is able to manage large

volumes of different types

(geospatial, multimedia,

crime, sensor, user, etc.) of

data.

PostgreSQL with its extensions offers

robust, solid support for storing and

querying large amounts of various

data types.



8. City.Risks SDK specification

The City.Risks SDK will be a “software development kit” for cities and developers that aims at harmonizing application programming interfaces (APIs). This will enable new services and applications to be rapidly developed, scaled and reused through providing a range of tools and information for both cities and developers.

An SDK is a library that is often bundled with extra tool applications, data files, and sample code that aids a programmer in developing code for a particular system. In addition, the SDK also contains the emulators required to test apps, utilities to interact with physical devices and sample applications highlighting different features of the included libraries. Documentation for include libraries etc. The SDK contains all the required elements to begin developing for the corresponding platform [17].

Platform SDKs are required to develop apps for a platform. For example, the Windows 8.1 SDK is required to develop apps for Windows 8.1 [18].

An SDK is more than just a set of APIs provided to developers. A complete SDK provides a consumer focused API for interacting with the system, and it additionally includes:

Documentation aimed at users consuming the SDK and system.

Clear examples of usage, including functioning, executable examples.

The SDK may optionally include tools to help developers use the SDK, such as IDE plugins or batch scripts.

It essentially acts as a generator of applications compatible with the City.Risks core platform. The main features of the City.Risks SDK will be:

Online – resources will be freely available and online

Accessible – the project uses open data and source code will be made available through GitHub through open licenses. Where there is a requirement to register to an API or service this will be to ensure that we can provide the necessary support to users, and ensure consistency of service for existing users.

Reliable – these APIs will be tested with the partner cities and so will be evaluated through a number of quality control processes to get to this point.

Commitment – partner cities commitment to the project means that the majority of open data sets required will be available and in a trusted format.

Best Practice – we are committed to developing best practice examples, for instance through the adoption of particular standards or processes.

Scalable – the SDK will have the ability to continue to function well even when user needs change in size or volume.

We will develop a modular flexible kit, comprising advanced risk management and response algorithms and tools operating on top of an enriched and enhanced content repository for security related information.



Over the years, many software engineering activities have relied on the automated support afforded by tools. In order to maximize the benefits provided by tools, they are often retrofitted to pre-existing development environments that enable them to capitalize on facilities provided by compilers, debuggers, and profilers. Integrated Development Environments (IDEs), for instance, comprise a myriad of tightly-knit tools (i.e., plugins) designed to boost programmer productivity. Due to the advantages that such integrated environments have brought to the mainstream, they have become a de facto standard to implement complex software systems [19].

The City.Risks SDK will be created on the Eclipse IDE. Eclipse provides IDEs and platforms nearly every language and architecture. It is well established for its Java IDE, C/C++, JavaScript and PHP IDEs built on extensible platforms for creating desktop, Web and cloud IDEs. These platforms deliver the most extensive collection of add-on tools available for software developers [20].

The SDK will take the IDE’s capabilities and the .jar files developed by the consortium to create a Java application. This application will act as an interface between the core platform and third party developers.

The City.Risks SDK will include a central Programming Interface, a Debugger, and a Visual Editor

8.1. Central Programming Interface

The Central Programming Interface will be an essential part of the SDK, as it will help third party developers to write applications that request services or resources from the core platform.

It will use the following packages to edit the RunTime, the WorkSpace and the WorkBench:

Platform Runtime Packages

org.eclipse.core.runtime

Provides core support for plug-ins and the plug-in

registry.

Workspace Packages

org.eclipse.core.resources

Provides basic support for managing a workspace and

its resources.

Workbench Packages

org.eclipse.jface.action

Provides support for shared UI resources such as

menus, tool bars, and status lines.

org.eclipse.jface.dialogs Provides support for dialogs.

org.eclipse.jface.operation Provides JFace support for long-running operations.

org.eclipse.jface.preference Provides a framework for preferences.

http://ftp.ntua.gr/eclipse/eclipse/downloads/documentation/2.0/html/plugins/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/runtime/package-summary.html

http://ftp.ntua.gr/eclipse/eclipse/downloads/documentation/2.0/html/plugins/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/resources/package-summary.html

http://ftp.ntua.gr/eclipse/eclipse/downloads/documentation/2.0/html/plugins/org.eclipse.platform.doc.isv/reference/api/org/eclipse/jface/action/package-summary.html

http://ftp.ntua.gr/eclipse/eclipse/downloads/documentation/2.0/html/plugins/org.eclipse.platform.doc.isv/reference/api/org/eclipse/jface/dialogs/package-summary.html

http://ftp.ntua.gr/eclipse/eclipse/downloads/documentation/2.0/html/plugins/org.eclipse.platform.doc.isv/reference/api/org/eclipse/jface/operation/package-summary.html

http://ftp.ntua.gr/eclipse/eclipse/downloads/documentation/2.0/html/plugins/org.eclipse.platform.doc.isv/reference/api/org/eclipse/jface/preference/package-summary.html



org.eclipse.swt SWT constants and error handling support.

org.eclipse.ui

Application programming interfaces for interaction

with and extension of the Eclipse Platform User

Interface.

8.2. Debugger

The debugger will be used for fixing program errors. We will use the JDT debugger, with which we can execute Java programs line by line and examine the value of variables at different points in the program

8.3. Visual Editor

The visual editor will allow developers to create and edit the program's graphical user interface (GUI). This will utilise developments to other Eclipse and Java projects (e.g. Visual Editor Project (VEP), Java Development Tools (JDT), Plug-in Development Environment (PDE), e Web Standard Tools (WST)).

We will use (among others):

WindowBuilder Engine — the core extensible framework providing support for all of the features listed above.

SWT Designer — an exemplary implementation of an GUI design tool that supports SWT, JFace, RCP, eRCP and XWT. This tool also provides excellent support for the Nebula widget collection and the Eclipse Data Binding framework.

Swing Designer — an exemplary implementation of an GUI design tool that supports Swing. This tool also provides excellent support for 3rd party layout managers such as JGoodies FormLayout and MiGLayout as well as support for the Swing Data Binding framework.

8.4. Other SDK Components

The developed SDK, like most, will contain sample code, which provides developers with example programs and libraries. These samples will help developers learn how to build basic programs with the SDK, which will enable them to eventually create more complex applications.

Finally the City.Risks SDK will also offer technical documentation, which includes tutorials and FAQs.

The City.Risks SDK will be an open source software that will be available to developers through the project’s website and hosted on GitHub. This way it will be a tool for the sustainability of the project and make our solutions available to other developers for similar applications.

http://ftp.ntua.gr/eclipse/eclipse/downloads/documentation/2.0/html/plugins/org.eclipse.platform.doc.isv/reference/api/org/eclipse/swt/package-summary.html

http://ftp.ntua.gr/eclipse/eclipse/downloads/documentation/2.0/html/plugins/org.eclipse.platform.doc.isv/reference/api/org/eclipse/ui/package-summary.html



9. Deployment and scaling in City.Risks

The deployment of the City.Risks platform and its services is achieved by using LXC (LinuX Container [21]) technology at the City.Risks' base server. LXC is an operating system-level virtualization method that allows running multiple isolated Linux systems, called Linux containers, on a single control machine. The containers may run a variety of different userspace interfaces to the same kernel (that is the kernel of the control host).

Services within Linux containers can be managed using numerous tools like docker.io [22] or juju [23] etc. providing an extra layer of abstraction and automation for the applications hosted on a server. Docker, for instance, can package an application together with its software dependencies in containers that are running within a server. Containers offer a high level of security and isolation while sharing the same machine resources (CPU, memory, etc.). Juju, from the other hand, can assist the administrator/deployer in his/her every-day cloud operations. Specifically through juju one can configure, manage, maintain, deploy and scale efficiently any public or private cloud. Juju uses “charms” that may be deployed in LXCs. Except from the private LXC based clouds in a data center, Juju enables to use Charms to deploy application architectures to EC2, OpenStack, Azure, and HP.

The deployment of the City.Risks (see deliverable D3.1) has been achieved using three different virtual containers (LXCs) all running the same OS (Ubuntu server 14.04.1 64bit) and forming an n-tier architecture system. Internal network and subneting will be handled by open vSwitch. Open vSwitch is a software implementation of a virtual multilayer network switch, designed to enable effective network automation.

Figure 24: Usage of virtual switch1 featuring multiple virtual machines

Given the limited number of needed LXCs to deploy the Core platform of City.Risks the containers have been configured using the command line. The three containers 1 Source M. Tim Jones (October 27, 2010). "Virtual networking in Linux". IBM. Retrieved April 9, 2014.



(named: web, app and db for the web layer, the application layer and the database layer respectively) have been assigned to a different internal (non-routable) IP (24-bit block following the RFC1918) as shown in the following table:

NAME STATE IPV4 AUTOSTART*

app RUNNING 10.0.3.105 YES

db RUNNING 10.0.3.242 YES

web RUNNING 10.0.3.38 YES

Note: Autostart denotes that the LXC will be auto-started when the host machine reboots.

The non-routable IP assignment approach places an additional security entrenchment given that the virtual machines (LXCs) are not visible from the external while remaining accessible and addressable by the host machine.

Given the fact that the LXCs are not visible from the external network, the administrator has to maintain them by explicitly login-in to their terminals and performing house-keeping operation or updates. This can be done by first login into the host machine, e.g. by using an ssh client, and then by “attaching” to the respective console offered by the LXC package.

Although in our initial City.Risks installation we deployed the platform onto three different nodes (LXCs), the system is able to “grow” as our needs change. Scale can result from buying bigger servers (vertical scale, or scaling up) or from involving more servers (horizontal scale, or scaling out). However vertical scale has its limits although, of course, City.Risks can benefit from more-powerful hardware. Serious scalability comes from horizontal scale, which means the ability to add more nodes to a specific cluster and be able to spread load and reliability between them.

Depending on the server (application, or database), scaling horizontally usually requires a major overhaul of the application to leverage of extra nodes. In contrast, Application servers like Jboss, or Data base servers like PostgreSQL or Neo4J are distributed by nature: it is able to manage multiple nodes to provide scale and high availability and thus ensure that our data is safe from hardware failure.



10. Conclusions

In this document we have described the architecture specifications and design of the City.Risks core platform. The core platform of the City.Risks overall system comprises the core functionalities for the user management, logging, reporting and policies management, the mobile applications, the theft detection sensor, the Data management Application Programming Interface and the Software Development Toolkit. The document describes the functionalities of the individual modules, the interfaces and the linking of the functionalities with the derived requirements as these have been described in the deliverable D2.4.

The document contains the finalised version of the architecture and will serve as a reference point for future developments under Workpackages WP3 and WP4, as well as for the pilot operations setup including software and device deployments. The consortium partners may create new versions of this document if changes will be needed during the next development phase, updating thus the overall specification of the City.Risks core platform.



Bibliography

[1] D. Amin, S. Govilkar, “Comparative Study of Augmented Reality SDK’s”, International Journal on Computational Sciences & Applications, Vol. 5, No. 1, February 2015

[2] http://neo4j.com

[3] https://www.elastic.co/products/elasticsearch

[4] http://openlayers.org

[5] http://geotools.org

[6] http://postgis.net

[7] http://www.postgresql.org

[8] http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=URISERV%3Al14555

[9] Gilles W. van Blarkom, John J. Borking, and Paul Verhaar. PET. In Gilles W. van Blarkom, John J. Borking, and Eddy Olk, editors, Handbook of Privacy and Privacy-Enhancing Technologies - The case of Intelligent Software Agents, chapter 3, pages 33–54. College bescherming per-soonsgegevens, The Hague, The Netherlands, 2003.

[10] https://www.iab.org/wp-content/IAB-uploads/2011/03/fred_carter.pdf

[11] https://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/privacy-and-data-protection-by-design

[12] http://spring.io/

[13] http://www.eclipse.org/birt/

[14] http://projects.spring.io/spring-security/

[15] http://periscope.tv

[16] http://geoserver.org

[17] http://www.twinprime.com/the-mark-of-a-good-sdk/

[18] https://msdn.microsoft.com/en-us/library/hh768146.aspx

[19] Araujo ,R. F., Barboza, D. H. , Pontes, O. B., Teixeira, R. M., João,R. S., Santos, W., Vinicius, M., and Durelli, H. S., «IBM software development kit for PowerLinux», Proceedings of the Second International Workshop on Developing Tools as Plug-Ins pp. 86-87 IEEE Press Piscataway, NJ, USA 2012

[20] https://eclipse.org/#sec_ide

[21] https://linuxcontainers.org

http://neo4j.com/

https://www.elastic.co/products/elasticsearch

http://openlayers.org/

http://geotools.org/

http://postgis.net/

http://www.postgresql.org/

http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=URISERV%3Al14555

http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=URISERV%3Al14555

https://www.iab.org/wp-content/IAB-uploads/2011/03/fred_carter.pdf

https://www.iab.org/wp-content/IAB-uploads/2011/03/fred_carter.pdf

https://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/privacy-and-data-protection-by-design

https://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/privacy-and-data-protection-by-design

http://spring.io/

http://www.eclipse.org/birt/

http://projects.spring.io/spring-security/

http://periscope.tv/

http://geoserver.org/

http://www.twinprime.com/the-mark-of-a-good-sdk/

https://msdn.microsoft.com/en-us/library/hh768146.aspx

https://eclipse.org/#sec_ide

https://linuxcontainers.org/



[22] https://www.docker.com/

[23] https://juju.ubuntu.com/

https://www.docker.com/

https://juju.ubuntu.com/



List of Acronyms

Acronym Explanation

API Application programming interface; an API is a set of protocols, models, and functions specifying the interface of a software component or software service

BLE Bluetooth low energy; a wireless personal area network technology aiming at resource-constrained devices

CSS Cascading style sheets; a style sheet language used for describing the presentation of a document written in a markup language (e.g., HTML)

CSV Comma Separated Value

DB Data base

DBMS Data base Management System

ESRI

GPS Global positioning system

HTML/HTML5 Hypertext markup language; the standard markup language used to create Web pages

HTTP Hypertext transfer protocol; the major communication protocol used by the World-Wide Web

ICT Information & Communication Technologies

ID Identification/Identifier

IDE Integrated Development Environment

IMU inertial measurement unit, using sensors such as gyroscope, accelerometer and compass

J2EE Java 2 Platform Enterprise Edition

JDBC Java Database Connectivity (JDBC) is an application programming interface (API) for the programming language Java that defines how a client may access a database.

JSON Javascript object notation

JSR Java Specification Requests are the actual descriptions of proposed and final specifications for



the Java platform.

LXC LinuX Container

mAR mobile augmented reality

MAU Mobile Application User

MVC Model View Controller

OC Operation Center (a major building block of the City.Risks end system)

ODBC Open Database Connectivity (ODBC) is a standard application programming interface (API) for accessing database management systems (DBMS).

OGC Open Geospatial Consortium

ORM Object-relational mapping: is a technique (design pattern) of accessing a relational database from an object-oriented language.

OS Operating System

OSS Open Source Software

POI Point of interest

POJO Plain Old Java Object

RDBMS Relational Data Base Management System

REST Representational state transfer; a Web service interface paradigm based on the HTTP protocol

SDK Software development kit; a set of APIs and tools used to build software applications

SLAM Simultaneous location and mapping

UDI Unique Device Identifier

UML Unified modelling language; a general-purpose, graphical software engineering language providing a standard way to visualise the design of a system

URL Uniform resource locator; a unified way to address internet resources such as documents, images, Web pages or services

VAT Value Added Tax

City.Risks platform architectureproject.cityrisks.eu/wp-content/uploads/... · user-centric vision...

Documents

Transcript of City.Risks platform architectureproject.cityrisks.eu/wp-content/uploads/... · user-centric vision...