EPIC - Online Service Delivery Baseline and Technical Requirements Report

DELIVERABLE

Project Acronym:

EPIC

Grant Agreement number:

270895

Project Title:

European Platform for Intelligent Cities

D2.3 Online Service Delivery Baseline and Technical Requirements Report Version: 1.0

Authors: Andreas Menychtas (NTUA)

Leonidas Kallipolitis (ATC)

PavlosKranas (NTUA)

Shenja Van Der Graaf (IBBT)

MargareteDonovang-Kuhlisch (IBM)

Werner Brebels (IBBT)

MaritaHeindrichs-Krusch (IBM)

Tanguy Coenen (IBBT)

Ravi W. Coote (FKIE)

Pukul Rana (MCC)

Ulrich Schade (FKIE)

Philippe Perennez (NAV)

Keith A. Osman (BCU) Internal Reviewers: Joshua Cooper (HIL)

Tanguy Coenen (IBBT)

Philippe Perennez (NAV)

Margarete Donovang-Kuhlisch (IBM)

Project co-funded by the European Commission within the ICT Policy Support Programme Dissemination Level P

Public

C

Confidential, only for members of the consortium and the Commission Services

X

EPIC – D2.3

Revision History Revision Date

Author

Organisation Description

0.1

31/03/2011 Pavlos Kranas NTUA

Initial Structure

0.2

1/4/2011

‘Executive Summary’ and ‘Web Services’ sections added

0.3

11/4/2011 Andreas Menychtas

NTUA

Changes on structure, input on section ‘EPIC Key Technologies’

0.4

12/4/2011 MDK

IBM

Additions

0.5

14/4/2011 RCO

FKIE

Input on section ‘Semantics’

0.6

18/4/2011 KAO

BCU

‘Internet of Things’ section populated with IoT

0.7

21/4/2011 Leonidas Kallipolitis

ATC

‘Front-­‐Ends – Mobile Devices Platforms’ section added by ATC

0.8

26/4/2011 Werner Brebels, Tanguy Coenen, Shenja Van Der Graaf

IBBT

Relocation app technology description

Pavlos Kranas NTUA

0.9

29/04/2011 Pavlos Kranas NTUA

‘Introduction’ section added by NTUA

0.10

30/4/2011 Philippe Perennez

NAV

‘Augmented Reality’ section added. Additions on User Requirements

0.11

4/5/2011

NTUA

Structure changed. A template for the user requirements has been provided

© EPIC Consortium

Andreas Menychtas

2

Version 1.0, 05/07/2011

EPIC – D2.3 0.12

5/5/2011

MDK

IBM

IBM’s provided user requirements

0.13

5/5/2011

RCO

FKIE

Input on ‘Geographic Information Systems’ and ‘Requirements Specification’ sections.

Remarks on ‘Front-­‐Ends’ and ‘Augmented Reality’

0.14

12/5/2011 LKA

ATC

Input on user requirements

0.15

12/5/2011 Pavlos Kranas NTUA

Input on section ‘Conclusions’ Additional input on user requirements

0.16

16/5/2011 MDK

IBM

Revision of Augmented Reality section

0.17

18/5/2011 Tanguy Coenen

IBBT

Comments on using web-­‐ apps instead of native apps

0.18

20/5/2011 Andreas Menychtas

NTUA

Minor changes on content and format

0.19

23/5/2011 Philippe Perennez

NAV

Input on IM/NAV pilot requirements

0.20

23/5/2011 Andreas Menychtas

NTUA

Minor changes on content and format

0.21

24/05/2011 PukulRana

MCC

Input on Smart Cities requirements

0.22

01/06/2011 Pavlos Kranas, NTUA Andreas Menychtas

Input on IOT Requirements

0.23

03/06/2011 MDK

1st reviewer comments

0.24

08/06/2011 Pavlos Kranas NTUA

© EPIC Consortium

IBM

3

Updates based on review

Version 1.0, 05/07/2011

EPIC – D2.3 comments 0.25

09/06/2011 Tanguy

IBBT

0.26

15/06/2011 Pavlos Kranas NTUA

Updates based on review comments

0.27

18/06/2011 MDK

IBM

Additional market insight for the era of smarter planet

0.28

20/06/2011 Philippe Perennez, Andreas Menychtas

NAV, NTUA

3rd reviewer comments and minor updates on format

0.29

24/06/2011 Joshua Cooper HIL, NTUA Andreas Menychtas

4th reviewer comments and relevant changes

0.30

28/06/2011 Ulrich Schade, Fraunhofer Ravi Coote FKIE

Review and minor changes and corrections

0.31

03/07/2011 Tanguy Coenen

Review and minor changes and corrections

0.32

04/07/2011 Pavlos Kranas NTUA

Minor changes based on MC’s comments

1.0

05/07/2011 Andreas Menychtas

Final Version

IBBT

NTUA

2nd reviewer comments

© EPIC Consortium

4

Version 1.0, 05/07/2011

EPIC – D2.3

Statement of originality:

This deliverable contains original unpublished work except where clearly indicated otherwise. Acknowledgement of previously published material and of the work of others has been made through appropriate citation, quotation or both. © EPIC Consortium

5

Version 1.0, 05/07/2011

EPIC – D2.3 Table of Contents 1 Executive Summary ...................................................................................................... 11 2 Introduction .................................................................................................................... 12 3 The Concept of ‘Smart Cities’ ..................................................................................... 12 3.1 IBM Definition of a Smart City .......................................................................................... 13 3.2 MIT Definition of a Smart City .......................................................................................... 15 3.3 Forrester Research Definition of a Smart City ........................................................... 15 3.4 Edinburgh City Council Definition .................................................................................. 15 4 EPIC Key Technologies ................................................................................................. 16 4.1 Web Services .......................................................................................................................... 16 4.1.1 Approaches, Implementations and Standards ................................................................... 17 4.2 Cloud Computing .................................................................................................................. 20 4.2.1 Approaches, Implementations and Standards ................................................................... 21 4.3 Service Discovery and Information Services .............................................................. 24 4.3.1 Approaches, Implementations and Standards ................................................................... 26 4.4 Semantics ................................................................................................................................ 32 4.4.1 Approaches, Implementations and Standards ................................................................... 33 4.5 Internet of Things ................................................................................................................ 35 4.5.1 Approaches, Implementations and Standards ................................................................... 36 4.6 Front-­‐Ends – Mobile Devices Platforms ........................................................................ 41 4.6.1 Approaches, Implementations and Standards ................................................................... 42 4.7 Augmented Reality .............................................................................................................. 55 5 Requirements Specification ....................................................................................... 56 5.1 Methodology .......................................................................................................................... 56 5.2 General Requirements ....................................................................................................... 59 5.2.1 Functional Requirements ............................................................................................................ 61 5.2.2 Non Functional Requirements .................................................................................................. 67 5.3 Pilot Application Requirements ...................................................................................... 69 5.3.1 Relocation Service .......................................................................................................................... 69 5.3.2 Urban Planning Service ................................................................................................................ 71 5.3.3 Smart Environment Service ....................................................................................................... 73 5.4 Development Environment .............................................................................................. 77 6 Conclusions ...................................................................................................................... 78 7 References ........................................................................................................................ 79

© EPIC Consortium

6

Version 1.0, 05/07/2011

EPIC – D2.3 Table of Figures Figure 1: IBM’s Definition of Smart City ....................................................................................... 14 Figure 2: Actors participating in terms of SOA .......................................................................... 17 Figure 3: The OSGi Framework ......................................................................................................... 18 Figure 4: WS-­‐Resource paradigm .................................................................................................... 20 Figure 5: The Cloud Computing overview ................................................................................... 21 Figure 6: Hype Cycle for Cloud Computing .................................................................................. 21 Figure 7: Towards the cloud computing enterprise ecosystem ......................................... 22 Figure 8: Analysts defining the Smarter Era ............................................................................... 25 Figure 9: Linked Open Data – W3C datasets ............................................................................... 26 Figure 10: Scan – Focus – Cue to enable a scarce Resource ................................................. 30 Figure 11: Organization’s usage of insights ................................................................................. 31 Figure 12: Estimated growth of mobile spend [35] ................................................................. 42 Figure 13: Mobile Business components [35] ............................................................................ 42 Figure 14: Smartphones’ operating systems distribution on the overall market ....... 43 Figure 15: Android component diagram [2] ............................................................................... 45 Figure 16: Relation between forthcoming WPs ......................................................................... 57 Figure 17: Initial Requirements Collection .................................................................................. 57 Figure 18: Requirements Analysis Workarea ............................................................................ 58 Figure 19: Template proposal for the collection of requirements .................................... 59 Figure 20: Components of an integrated collaborative information environment .... 60

© EPIC Consortium

7

Version 1.0, 05/07/2011

EPIC – D2.3 List of Tables Table 1: IP Suite ....................................................................................................................................... 37 Table 2: ISO/IEC 18000 standards .................................................................................................. 40 Table 3: Immoweb web service ........................................................................................................ 50 Table 4: WSGeloLoc UrbIS web service ......................................................................................... 51 Table 5: Applications consuming data from the UrbIS framework .................................. 52 Table 6: Requirement FR1 .................................................................................................................. 61 Table 7: Requirement FR2 .................................................................................................................. 61 Table 8: Requirement FR3 .................................................................................................................. 61 Table 9: Requirement FR4 .................................................................................................................. 62 Table 10: Requirement FR5 ............................................................................................................... 62 Table 11: Requirement FR6 ............................................................................................................... 62 Table 12: Requirement FR7 ............................................................................................................... 62 Table 13: Requirement FR8 ............................................................................................................... 63 Table 14: Requirement FR9 ............................................................................................................... 63 Table 15: Requirement FR10 ............................................................................................................. 63 Table 16: Requirement FR11 ............................................................................................................. 63 Table 17: Requirement FR12 ............................................................................................................. 64 Table 18: Requirement FR13 ............................................................................................................. 64 Table 19: Requirement FR14 ............................................................................................................. 64 Table 20: Requirement FR15 ............................................................................................................. 64 Table 21: Requirement FR16 ............................................................................................................. 64 Table 22: Requirement FR17 ............................................................................................................. 65 Table 23: Requirement FR18 ............................................................................................................. 65 Table 24: Requirement FR19 ............................................................................................................. 65 Table 25: Requirement FR20 ............................................................................................................. 65 Table 26: Requirement FR21 ............................................................................................................. 66 Table 27: Requirement FR22 ............................................................................................................. 66 Table 28: Requirement FR23 ............................................................................................................. 66 Table 29: Requirement FR24 ............................................................................................................. 67 Table 30: Requirement NF1 ............................................................................................................... 67

© EPIC Consortium

8

Version 1.0, 05/07/2011

EPIC – D2.3 Table 31: Requirement NF2 ............................................................................................................... 67 Table 32: Requirement NF3 ............................................................................................................... 67 Table 33: Requirement NF4 ............................................................................................................... 68 Table 34: Requirement NF5 ............................................................................................................... 68 Table 35: Requirement NF6 ............................................................................................................... 68 Table 36: Requirement NF7 ............................................................................................................... 68 Table 37: Requirement RRS2 ............................................................................................................. 69 Table 38: Requirement RRS2 ............................................................................................................. 69 Table 39: Requirement RRS3 ............................................................................................................. 70 Table 40: Requirement RRS4 ............................................................................................................. 70 Table 41: Requirement RRS5 ............................................................................................................. 70 Table 42: Requirement RRS6 ............................................................................................................. 71 Table 43: Requirement RUP1 ............................................................................................................ 72 Table 44: Requirement RUP2 ............................................................................................................ 72 Table 45: Requirement RUP3 ............................................................................................................ 72 Table 46: Requirement RUP4 ............................................................................................................ 72 Table 47: Requirement RUP5 ............................................................................................................ 73 Table 48: Requirement RSE1 ............................................................................................................. 73 Table 49: Requirement RSE2 ............................................................................................................. 74 Table 50: Requirement RSE3 ............................................................................................................. 75 Table 51: Requirement RSE4 ............................................................................................................. 75 Table 52: Requirement RSE5 ............................................................................................................. 75 Table 53: Requirement RSE6 ............................................................................................................. 76 Table 54: Requirement RSE7 ............................................................................................................. 76 Table 55: Requirement RSE8 ............................................................................................................. 76 Table 56: Requirement RSE9 ............................................................................................................. 77 Table 57: Requirement RSE10 .......................................................................................................... 77 Table 58: Requirement DE1 ............................................................................................................... 77 Table 59: Requirement DE2 ............................................................................................................... 78 Table 60: Requirement DE3 ............................................................................................................... 78 Table 61: Requirement DE4 ............................................................................................................... 78

© EPIC Consortium

9

Version 1.0, 05/07/2011

EPIC – D2.3

© EPIC Consortium

10

Version 1.0, 05/07/2011

EPIC – D2.3

1 Executive Summary This report consolidates the results of the survey on the desk based research and on the creation of technical requirements towards the EPIC platform related to WP2 (“User Requirements Analysis”) of the EPIC Project. The desk based research is expected to provide a view of the variety of technologies, products and research activities that are exploited within the EPIC platform, identifying the current technologies, their limitations and capabilities. On the other hand, the technical requirements analysis defines the major functionalities that the EPIC platform should provide, while identifying the core technologies that the platform should address in order to meet the users' needs.

The results of the desk based research and the technical requirements, presented within this document cover the technology spectrum that will be considered towards the realisation of the EPIC platform. The available specifications, approaches and implementations for each technology aspect are described in this document, while the full set of both functional and non-­‐functional requirements are presented in generic and application specific level. This document will provide valuable input to the development of the EPIC platform (WP3), the integration and deployment of the three pilot applications (WP4, WP7) and the evaluation and validation of the platform (WP8).

© EPIC Consortium

11

Version 1.0, 05/07/2011

EPIC – D2.3

2 Introduction The key aim of this report is to identify the various technological areas and concepts that are covered by the EPIC platform and present an extensive, in-­‐depth analysis of the State of the Art behind them, as a result of an exhaustive survey conducted by all partners involved in this task. Moreover, this report contains all the necessary user requirements that must be covered by the EPIC platform. To this direction, the report summarizes the results of the survey on the desk based research of the technologies required to realize the EPIC -­‐European Platform for Intelligent Cities-­‐ platform, as well as the definition of the user requirements, accrued from the workshops that were organised by the pilot leads for the necessity of T2.2. Those requirements are accrued through extended discussions between all technical partners and the relevant stakeholders of all three pilot applications.

In this context, the document is structured in three main sections. The first section (Chapter 3) is devoted to the presentation of the definition of 'Smart Cities'. First of all, an overview of the existing services and paradigms offered by European cities right now is presented, while the current trends and challenges are described.

Finally, we analyse our vision concerning what a 'Smart City' should become, and we describe how the EPIC platform will help the European cities to move towards this direction.

The second section of the document (Chapters 4 and 5) focuses on the presentation of the key technologies and concepts that will be exploited by the EPIC platform.

Each technology is briefly described, giving its general overview, while a list of all existing approaches and implementations is provided for each one of them.

The third section contains the analysis of the user requirements extracted from the pilot leads' workshops and all related discussions between pilot leads and all relevant stakeholders. This analysis is necessary to derive the requirements towards the virtualized hardware platform (i.e. the sizing of the infrastructure provided by the IBM SmartCloud Enterprise, formerly known as the Smart Business Test and Development Cloud) and finally identify the necessary EPIC platform capabilities (i.e. the core enterprise services deployed in the underpinning SOA foundation). We firstly identify the common functional and non-­‐functional requirements, and then we analyse the application-­‐specific requirements in combination with a short description of the use cases, exploiting the D2.2.

Finally, the conclusions on the outcomes of desk based research and requirements analysis are presented in chapter 7.

3 The Concept of ‘Smart Cities’ Definitions of a Smart City vary but collectively tend to suggest the use of innovative ICT-­‐based technologies such as the Internet of Things (IoT) and Web 2.0 to deliver more effective and efficient public services that improve living and working © EPIC Consortium

12

Version 1.0, 05/07/2011

EPIC – D2.3 conditions and create more sustainable urban environments. The EPIC Project Vision document [10] consolidates our view on “smart cities” and highlighted the challenges for providing and consuming “intelligent” public services in pan-­‐ European level. In addition, the following definitions present different understandings of what a “smart city” is and will be elaborated in the following sections: •

IBM: Smart Cities digitise and connect infrastructures (IOT) to infuse them with new intelligence. Smarter cities make their systems instrumented, interconnected and intelligent [19].

•

MIT: Networked intelligence in fabrication and construction (IOT) [23].

•

Forrester: The combined use of software systems, server infrastructure, network infrastructure, and client devices — which Forrester calls Smart Computing technologies — to better connect seven critical city infrastructure components and services: city administration, education, healthcare, public safety, real estate, transportation, and utilities. (IOT) [16].

•

Edinburgh City Council: Smart City is all about people based public services (Web 2.0) [9].

3.1 IBM Definition of a Smart City A new report from the IBM Institute for Business Value, "A Vision of Smarter Cities," makes the case that cities must use new technologies to transform their systems to optimise the use of finite resources.

As cities face these substantial and interrelated challenges, it becomes clear that the status quo – business as usual – is no longer a viable option. Cities must use their new power to become smarter. They must act now, using new technologies to transform their core systems to optimize the use of limited resources. Pervasive new technologies provide a much greater scope for instrumentation, interconnection and intelligence of a city’s core systems.

Technological advances mean that aspects of the operation and development that city managers have previously been unable to measure – and therefore unable to influence – are increasingly being digitized. This instrumentation creates brand new data points about, for example, the efficiency of a city’s water or transport systems.

In addition to being instrumented, different parts of a city’s systems can be interconnected, so that information flows between them. With the greater digitization and interconnection of a city’s core systems, the newly gained information can be used for intelligent and informed decision-­‐making.

© EPIC Consortium

13

Version 1.0, 05/07/2011

EPIC – D2.3

Figure 1: IBM’s Definition of Smart City

Smarter cities make their systems instrumented, interconnected and intelligent: •

Instrumentation, or digitization, of a city’s system means that the workings of that system are turned into data points and the system is made measurable.

•

Interconnection means that different parts of a core system can be joined and “speak” to each other, turning data into information.

•

Intelligence refers to the ability to use the information created, model patterns of behaviour or likely outcomes and translate them into real knowledge, allowing informed actions. Smarter cities transform their systems and their “system of systems”.

A smarter city is one that uses technology to transform its core systems and optimize the return from largely finite resources. The interrelationship between a city’s core systems must be taken into account to make this “system of systems” smarter, too. No system operates in isolation; instead, a web of interconnections exists. For example, transport, business and energy systems are closely interrelated – the transport and business systems are key users of energy. Connecting these systems will deliver even greater efficiency and address the interrelated, long-­‐term threats to sustainability.

Think revolution, not evolution: Rising to the challenges and threats of sustainability, requires a city to be more than just focused or efficient; it will requires the next generation of city to emerge – one based on smarter systems. These systems are interconnected – people and objects can interact in entirely new ways. These systems are instrumented – the exact condition of the system’s different parts can be measured. These systems are intelligent – cities can respond to changes quickly and accurately, and get better results by predicting and optimizing future events [9].

© EPIC Consortium

14

Version 1.0, 05/07/2011

EPIC – D2.3 Don’t forget the big picture: The interrelationships between the various systems mean that while cities obviously must prioritize, just “solving one” is not a viable long-­‐term option. The challenges and threats to sustainability come from all angles and require a holistic strategy that addresses all factors and feedback mechanisms.

3.2 MIT Definition of a Smart City How buildings and cities can become more intelligently responsive to the needs and desires of their inhabitants.

The research of the Smart Cities group focuses on intelligent, sustainable buildings, mobility systems, and cities. It explores the application of new technologies to enabling urban energy efficiency and sustainability, enhanced opportunity and equity, and cultural creativity. The group is particularly concerned with the emerging roles of networked intelligence in fabrication and construction, urban mobility, building design and intelligently responsive operation, and public space. It takes a broadly multidisciplinary approach, not constrained by traditional boundaries.

3.3 Forrester Research Definition of a Smart City Cities are becoming "smarter," as governments, businesses, and communities increasingly rely on technology to overcome the challenges from rapid urbanization.

What makes a "smart city" smart is the combined use of software systems, server infrastructure, network infrastructure, and client devices -­‐ which Forrester calls Smart Computing technologies -­‐ to better connect seven critical city infrastructure components and services: city administration, education, healthcare, public safety, real estate, transportation, and utilities. The concept of the smart city is pushing the CIOs in federal, state, and local governments and their technology teams to further evaluate emerging technologies and engage with key stakeholders within and outside of their organizations. To successfully deliver the smart city vision, CIOs should have a clear understanding of what the smart city is, its key drivers and their roles in it.

3.4 Edinburgh City Council Definition A Smart City vision is basically a Council's action plan for e-­‐Government implementation and modernisation.

Information and Communication Technologies (ICT) are radically changing the way people undertake their daily business. Customer expectations are high with the 24 hour society leading them to expect personalised and joined up services, available where and when they want them.

Smart City is all about people based public services. It is about changing the way the Council organises and delivers its services in order to become efficient, effective and customer focused. Its aim is to use ICT efficiently and effectively to support the delivery of all these services to citizens, businesses and organisations. © EPIC Consortium

15

Version 1.0, 05/07/2011

EPIC – D2.3 In particular, the Smart City will: •

Use leading-­‐edge ICT to change the way services behind the scenes (in the "back office") are delivered to improve customer service, productivity, effectiveness and efficiency.

•

Improve information and internal communication to help strategic planning and prioritising resources as well as promote innovative thinking and collaboration (involving Council staff in the process).

•

Provide the tools and infrastructure to let citizens and community organisations take advantage of the information age and to participate and express their views as part of local decision-­‐making.

•

Deliver new "value-­‐added" services to citizens, visitors and local businesses using leading-­‐edge technology to improve their quality of life, their experience of visiting the city or competitiveness.

4 EPIC Key Technologies In this section, the key technologies that will be exploited by the EPIC platform are being analysed. For each one of them, there is a brief overview that describes their most important characteristics, followed by an extended presentation of the existing implementations, standards and approaches.

4.1 Web Services A Web Service is a software system designed to support interoperable machine-­‐to-­‐ machine interaction over a network. Its interface is described in a machine-­‐ processable format, WSDL [1] (Web Service Description Language), which provides a model and an XML [44] (EXtensible Markup Language) format for describing Web Services. WSDL enables one to separate the description of the abstract functionality offered by a service from concrete details of a service description such as "how" and "where" that functionality is offered. WSDL describes a Web Service in two fundamental levels: the abstract level and the concrete level. Within each of these two levels, the description uses a number of constructs to promote reusability of the description and separate independent design concerns.

Web Services provide a standard way of interoperating between different software applications, running on a variety of platforms and/or frameworks. Regarding the drawbacks of the Web Services technology often is mentioned its complexity and orientation to large software vendors more than open source software.

Service Oriented Architecture Service Oriented Architecture (SOA) is an architectural style that emphasizes implementation of components as modular services that can be discovered and used by clients. Infrastructures based on the SOA paradigm are called Service Oriented

© EPIC Consortium

16

Version 1.0, 05/07/2011

EPIC – D2.3 Infrastructures (SOIs). A more formal definition for SOA is that it is "a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides uniform means to offer, discover, interact with and use capabilities to produce desired effects, consistent with measurable preconditions and expectations" (OASIS). The basic building block of a SOI is the service. The business logic of a SOI is encapsulated into its services, which interact with each other through common interfaces, by exchanging messages with well-­‐ defined formats, in order to deliver well defined functionality.

Within the context of SOA we can identify three major roles. The service provider, who is responsible to create the service and makes it available by exposing it to the service broker. The latter is used to publish advertisements for services and it is responsible for making all registered services available to any potential service requester. The term service consumer is used for the client of the service who discovers entries in the Service Registry that meet its needs and after selecting one, binds to the corresponding service in order to begin interaction with it.

Figure 2: Actors participating in terms of SOA

4.1.1 Approaches, Implementations and Standards 4.1.1.1 SOAP Web Services The Simple Object Access Protocol (SOAP) is a protocol specification that relies on common protocols, like Extensible Markup Language (XML) for serializing its message format, and Hypertext Transfer Protocol (HTTP) for negotiation and transmission. This allows the web Services to provide a standard means of interoperating between different software applications, running on a variety of platforms and/or frameworks. SOAP is used as the envelope for sending the messages over the network.

The following list outlines the steps involved in a Web Service invocation using the SOAP [36] approach: 1. The client application uses the client stub to turn its request into a proper SOAP request. This is often called the serializing process. © EPIC Consortium

17

Version 1.0, 05/07/2011

EPIC – D2.3 2. The SOAP request is sent over a network using the HTTP protocol. The server receives the SOAP requests and passes it to the server stub. The server stub deserializes the SOAP request.

3. The server stub invokes the service implementation of the requested operation, which carries out the work.

4. The result of the requested operation is handed to the server stub and converted into a SOAP response message.

5. The SOAP response is sent over a network using the HTTP protocol. The client stub receives the SOAP response and deserializes it.

6. Finally the client receives the result of the Web Service operation.

4.1.1.2 OSGi Service An OSGi (Open Service Gateway Initiative) is a Java framework for developing and deploying modular software programs and libraries.

OSGi has two parts: 1. The specification for modular components called bundles. The specification is responsible for bundle's life cycle and determines how bundles will interact.

2. The Java Virtual Machine (JVM)-­‐level service registry that bundles can use.

Figure 3: The OSGi Framework

An OSGi Service Platform provides a standardized, component-­‐oriented computing environment for cooperating networked services and provides the functions to change the composition dynamically on the device of a variety of networks. It is used to manage smart appliances and other Internet-­‐enabled devices at home as most of the mobile applications are using Java software framework which is embedded in a hardware platform. The framework acts as the central message broker for the device on the home's local area network (LAN). The idea and the advantage of OSGi is to create a standardized middleware for smart devices and make managing cross-­‐dependencies easier for software developers. This architecture significantly reduces the overall complexity of building, maintaining © EPIC Consortium

18

Version 1.0, 05/07/2011

EPIC – D2.3 and deploying applications. Furthermore it introduces an efficient way of building services.

4.1.1.3 REST Web Services REST [31] is another architectural style that can be used to design Web Services and it's becoming popular again during the recent years. The basic concept behind REST is the existence of sources of specific information, called resources, each of which can be referred to using a URI. The management of these resources is controlled by components that communicate via HTTP, using its standard methods (e.g. GET, POST, PUT, and DELETE).

REST asks developers to use HTTP methods explicitly and in a way that's consistent with the protocol definition. This basic REST design principle establishes a one-­‐to-­‐ one mapping between create, read, update, and delete (CRUD) operations and HTTP methods. According to this mapping: • • • •

To create a resource on the server, use POST. To retrieve a resource, use GET. To change the state of a resource or to update it, use PUT. To remove or delete a resource, use DELETE.

4.1.1.4 Web Services Standards Regarding the REST paradigm, resources are managed by the clients. A different approach is that resources are managed by the web service, enabling it to maintain information about state, while keeping it stateless. This is achieved by splitting the Web Service from the state and keeping them completely separate. In more detail, state is stored inside a separate entity that is called a resource that has a unique key we can use to interact with it.

More formally, a WS-­‐Resource [26] is the composition of a resource and a Web Service through which the resource can be accessed. The aforementioned are illustrated in the above figure:

© EPIC Consortium

19

Version 1.0, 05/07/2011

EPIC – D2.3 Resources

A Service Request Web Service

Client

B

Service Response C

Figure 4: WS-­‐Resource paradigm

A WS-­‐Resource is further defined as follows: •

•

•

A reference to a WS-­‐Resource is represented by an endpoint reference (EPR), or more precisely an XML element type of which is, or is derived from (by extension), the complexType named EndpointReferenceType defined by the [WS-­‐Addressing] specification. Such EPRs MUST reference exactly one WS-­‐ Resource.

The set of properties of the resource must be expressed using an XML Infoset described by XML schema. The WS-­‐Resource MUST support accessing resource properties through message exchanges defined by the WS-­‐ ResourceProperties specification [WS-­‐ResourceProperties] [26].

A WS-­‐Resource MAY support the message exchanges defined by the WS-­‐ ResourceLifetime specification [WS-­‐ResourceLifetime] [27].

In order to define a generic framework for modelling and accessing WS-­‐Resources using Web Services the Web Services Resource Framework (WSRF) [25] is used.

WSRF is the mean to incorporate state in the resource following a Web Service compliant way and therefore, extending the latter to support stateful resources.

4.2 Cloud Computing Cloud Computing is both a user experience of IT and a business model that is built on the inspiration of consumers using internet services and providers delivering them. It is a style of IT delivery in which applications, data and IT resources are rapidly provisioned and provided as standardized offerings to users over the web in a flexible pricing model and through self-­‐service.

© EPIC Consortium

20

Version 1.0, 05/07/2011

EPIC – D2.3 In addition, cloud computing is an infrastructure management and service delivery methodology; it provides a way of managing large numbers of highly virtualized resources such that, from a management perspective, they resemble a single large resource. This can be used to deliver services with elastic scaling representing industrialization of IT services.

Figure 5: The Cloud Computing overview

4.2.1 Approaches, Implementations and Standards Cloud computing is considered the foundation for the future internet of people, things and services as envisioned in the Digital Agenda Europe (DAE), too. In 2010, Gartner [13] published the Hype Cycle for Cloud Computing as depicted in Figure 6.

Figure 6: Hype Cycle for Cloud Computing

© EPIC Consortium

21

Version 1.0, 05/07/2011

EPIC – D2.3 Interestingly enough, “cloud computing for the enterprise” is judged to be more than 10 years away. Within the smart cities living labs and EPIC, we want to shorten this outlook by improving the economics of scale beyond virtualized infrastructure.

Figure 7: Towards the cloud computing enterprise ecosystem

Standardization of data formats and semantics and procedures will raise operational efficiency; automation of workflows allows for flexible delivery and self-­‐ service and shared resources enable dynamic provisioning of workloads for smarter work.

4.2.1.1 Deployment Options There are five different options to implement a virtualized – cloud – infrastructure: •

•

•

•

Smart City Data Center – Private Cloud: This option provides the strongest ownership and control of the IT infrastructure. It is privately owned, installed on the organisation’s premises and operated by the organisation.

Smart City Data Center – Managed Private Cloud: A third party is responsible for the operation of the IT infrastructure which is owned by the organization. Typically, mission critical and packaged applications are run in this cloud. Compliancy and security and trust are the most common drivers for chosen this option – on top of a closed internal network.

Smart City – Hosted Private Cloud: A third party is hosting and operating a dedicated IT environment over an internal network to in a standardized, centralized and secure fashion – typically in an outsourcing relationship.

Smart Cities – Member Cloud Services: Here we encounter a mix of shared and dedicated resources, managed and operated for the members by a

© EPIC Consortium

22

Version 1.0, 05/07/2011

EPIC – D2.3

•

common staff in a shared facility. Access is provided via VPN over the internet. Either subscription or membership enrolment model are supported.

This option will be used for the build-­‐up of the EPIC platform – providing BPaaS and AaaS (applications as a Service) to the pilots.

Users – Public Cloud Services: which are offered via the public internet on a pay as you go basis. They allow elastic scaling leveraging shared resources.

The EPIC applications will be provided by the stakeholders in this fashion to the public.

4.2.1.2 Cloud Service Categories Cloud vendors build on a cloud (hardware) management platform to deliver the whole cloud value stack: •

•

•

•

Infrastructure as a service (IaaS): providing hardware (servers, storage, network devices) and virtual machines (native operating systems) to the client. In EPIC, we use the IBM SmartCloud Enterprise offering for IaaS. Platform as a Service (PaaS): providing API’s and core enterprise services as information access, security and process management services to the client. In EPIC, we use the core of the IBM Government Industry Framework, a comprehensive SOA and Business Process Management Foundation with inherent Analytics Capabilities to instantiate the EPIC platform Software as a Service (SaaS): providing applications and business logic from the cloud. In EPIC, the Navidis urban planning services are an example of SaaS. Business Process as a Service (BPaaS): provisioning aggregated applications and processes. In EPIC, the semantic engine from Fraunhofer enables relocation as a BPaaS to be consumed from the platform. The relocation pilot is derived from a joint case study of IBM and Fraunhofer ([8]).

4.2.1.3 Outlook and Call to Actions Cloud computing is an emerging consumption and delivery model for many IT-­‐ based services leveraging the value of for example: • • • • • •

30 billion embedded RFID tags by 2010 50% of all sensors in transportation, facilities and production equipment being smart sensors 33% of the world’s population being on the web by 2011 billions of mobile subscribers globally by the end of 2010 15 petabytes of new information generated every day 64 billion credit card transactions/annum.

In EPIC, we take the first steps to leverage these and other trends and to •

Implement a cloud environment for the European Smart Connected City Network:

© EPIC Consortium

23

Version 1.0, 05/07/2011

EPIC – D2.3

•

•

o Improve economics of scale of existing infrastructure through better service management o Develop better security around existing or planned infrastructure for a broader exposure of services to new channels Develop cloud-­‐based applications o Integrate existing and cloud based data, applications and processes o Reduce cost and complexity of application development, deployment and runtime through patterns and reuse o Develop and test applications for the cloud platform Raise consumption of cloud services o Deliver a set of collaboration services that dramatically simplifies and improves the business interactions o Streamline, document and run processes on top of the cloud platform o Reduce the complexity of marketing cloud services across multiple channels o Gain insight and additional value from data through cloud-­‐based analytics.

4.3 Service Discovery and Information Services Smart cities, operating in an environment of efficient collaboration and informed decision making in a value network, bear the only effective way to meet the challenges and threats we face in this modern, interconnected world. Enhanced inter-­‐agency and inter-­‐company communication and collaboration has been defined as the capability to deliver information superiority when required to enable agile and informed decision making to underpin effects-­‐based operations and to gain competitive advantages: delivering the right effect, at the right time, to achieve the outcome required.-­‐ be it energy savings, citizen empowerment or planning in the city for economic growth.

Challenges and threats in our modern world are global and multi-­‐faceted requiring complex responses: governments and corporations, buoyed by the realization that the interests of both are mutually engage, are pursuing joint corporate social responsibility to make life and business conduct safe and sustainable. One outcome is increasing openness: organizations increasingly publish data and knowledge in open formats and open spaces and (others) provide tools to gain insight from this open and accessible data. Within smart cities, there is an increasing tendency to publish open government data to be used within “smart computing” [34].

Cities are becoming smarter by transforming traffic systems, water systems, security-­‐every possible form of municipal infrastructure. Business process is evolving across every industry-­‐banking, trading, manufacturing as well as government. Changes take place in the way people live, enjoy advancements ranging from reduced congestion and pollution to new ways of communication and collaboration. Every aspect of life benefits from the instrumentation, interconnection and infusion of intelligence into the systems of the world. In EPIC, © EPIC Consortium

24

Version 1.0, 05/07/2011

EPIC – D2.3 we have chosen the pilots to validate the benefits to be gained from these global trends whenever hosted on the scalable platform.

Nothing is changing more than the underpinning information technology: the way it's accessed, applied and architected. Analysts around the world are developing their own terms, definitions and outlooks for the smarter planet era.

• Intelligent Economy • Automated systems to make decisions

• Big Data • At an inflection point

“Convergence of intelligent devices, social networking, pervasive broadband networking, and analytics is ushering in a new economic system that is redefining relationships among producers, distributors, and consumers. The flood of new data, the faster cycle times, and the adoption of analytics prevalent in the intelligent economy make it clear that there is both a need and an opportunity to change how decisions are made to harness these new circumstances to achieve advantage in the market.”

“There are many ways big data can be used to create value across sectors of the global economy. Indeed, our research suggests that we are on the cusp of a tremendous wave of innovation, productivity, and growth, as well as new modes of competition and value capture – all driven by big data as consumers, companies, and economic sectors exploit its potential.”

• Operational Technology • In asset-intensive industries

• Smart Computing • $272B by 2015

“Operational technologies include: Systems that deal with the actual running of plant and equipment; Devices to ensure system integrity and to meet technical constraints; Event-driven and frequently real-time software applications or devices with embedded software; Systems used to manage and control mission-critical production or delivery processes; Data historians storing large quantities of time series and condition data.”

“The convergence of innovations in software architectures; back-room data center operations; wireless and broadband communications; and smaller, powerful, and numerous client devices connected to the network lets technology work together in unprecedented ways to solve smarter and more complex business problems that the last generation of computing could not address.”

Sources: IDC “A Fast Growing Opportunity to Drive the Intelligent Economy” December, 2010; Mckinsey & Co “Big Data the Next Frontier” May, 2011; Forrester Research “Next Wave of IT Investment is Smart Computing” Jan 2010; Gartner Group “Operational Technology Convergence with IT” July, 2010

Figure 8: Analysts defining the Smarter Era

The opportunities for innovation have never been greater. Enterprises in every industry can use breakthroughs in technology to create new business models, find new ways of delivering technology-­‐based services and generate new insights, from IT to fuel innovation and dramatically improve the economics of IT. New technology innovations sign that the world is entering a new era of smarter computing, the era of insight for discovery. This new era is made possible by the integration of: •

•

•

Big Data o Better understand human behaviour and needs o Optimize decisions in real time o Foster collaborative decision making o Continually assess risk Optimized Systems o Reduce deployment times from months to days o Improve performance with utilization rates up to 90 percent o Reduce floor space, power consumption, labour and total cost per workload by 55 percent Clouds o Capture new value by creating new offerings and services

© EPIC Consortium

25

Version 1.0, 05/07/2011

EPIC – D2.3 o Deliver IT without boundaries by breaking down silos and simplifying access to information 4.3.1 Approaches, Implementations and Standards 4.3.1.1 Big Data Within the semantic web, data is identified and accessed via Uniform Resource Identifiers (URI). Coding, referencing and linkage between data resources can (and should) be done using the Resource Descriptor Framework (RDF [32]). Linked Open Data (LOD) is defined as the “cloud” of freely accessible data defined and linked via these open standards. Figure 9 depicts one initiative to populate this knowledge base in a W3C community project ([40]) and shows the current topology of the included network of open datasets.

Figure 9: Linked Open Data – W3C datasets

Open Government Data ([40]) is the LOD subset made available by governmental institutions for free and for potentially even commercial use – in and via the internet. Openness in public sector comes in different flavours: •

• •

Machine readability and technical accessibility: even open standards like “pdf” or “html” are often difficult to interpret. Publishing textual data in descriptive formats like “csv” (comma separated values) or providing application programming interfaces (APIs) to original data sources are preferable options.

Free access enables evaluation and experimentation with data and helps to create more and more datasets within LOD. Reuse permitting licensing: open data that is commercially exploited i.e. that is used in chargeable applications or web services offered by third

© EPIC Consortium

26

Version 1.0, 05/07/2011

EPIC – D2.3 •

•

parties can be billed by the original publisher.

Discovery: data creation and maintenance (by the owner and publisher) and data consumption (by the public) should be decoupled. Publishing data in a “public data catalogue” using open standards such as Web Service Description Language (WSDL) and Universal Description, Discovery and Invocation (UDDI) are good best practices to ensure data quality and improve the retrieval success of “open data as a service”.

Semantics and Linkage: ontologies within and between the open datasets complete the growing knowledge base.

The “Re-­‐Use of Public Sector Information (PSI) Directive”, 2003/98/EC, encourages and strives for extensive publication and opening of open government data – and therefore also recommends a fundamental change of paradigm and policy from the “need-­‐to-­‐know” to the “need-­‐to-­‐share” principle fundamental for network enabled capabilities (NEC) and successful engagements in smart connected city operations: •

•

•

Publicity: ° Old: everything is classified if not explicitly marked public ° New: everything is public by default.

Scope: ° Old: the creator can decide the amount and date of his data to be published ° New: all data that does not carry security or privacy tags is proactively published.

Usage rights: ° Old: published data is for private information only ° New: published data can be exploited for any purpose. This includes the analysis and further dissemination of data and derived insight.

Big data, as defined by Gartner, and information integration capabilities make it possible to generate insight from vast quantities of data, fundamentally changing the way organizations use information. It means filtering petabytes of data per second from almost any connected device, analysing the data while still in motion, deciding what, if any, data must be stored and even using analytic tools to virtually integrate the data with data stored in traditional warehouses. Organizations can integrate and analyse unstructured data wherever it is located -­‐ including the Internet -­‐ without overwhelming enterprise data warehouses.

One example for open Analytics is IBM City Forward, launched on December 13th, 2010 ([6]), a donation to cities’ and city subsystems’ stakeholders. It is a one-­‐stop shop for elected and appointed officials and citizens of cities for ongoing analysis of city information and the city’s current state. It encompasses an aggregation of global best practices and provides the kind of community knowledge repository that can be further populated by using LOD as raw data input.

City Forward is a tool for helping cities or city-­‐like entities such as an airport, become smarter; it provides: © EPIC Consortium

27

Version 1.0, 05/07/2011

EPIC – D2.3 •

Predictive modelling and simulation and decision support for future policy

•

Comparison to an ideal smarter city (model)

•

Exploration and visualization tools that allow subject matter experts from academia, government and industry to illustrate ideas and trends and encourage discussions of their validity and potential impact

•

Illustration of a city’s journey via historical snapshots of its data

•

Best practices information and lessons learned from other geographies

•

Social media and collaboration tools to engage citizens in city decision-­‐ making

•

Interrelated and integrated information from sources ranging from real-­‐time social sensors to decennial censuses providing ad hoc situational awareness and a foundation for new insights.

The City Forward rationale is to provide tools to create a consolidated source of information to enable city, state, regional or national leaders to collaborate with citizens in priority setting to make their cities smarter. Participation and inclusion of citizens in policy setting is considered not only to be a way of becoming more efficient and effective in a municipality, but also make the city a safer place to live in.

IT departments integrating big data with already-­‐stored data can enable new forms of analysis, such as forecasting and predictive modelling.

The amount of data isn’t the only challenge that the enterprises are facing today; the Big Data challenges come in four’s: •

•

•

•

Volume – Businesses today are dealing with a tidal wave of data, amassing to gigabytes, terabytes to even petabytes of information. Terabytes an hour during peak operations is becoming quite common. This includes web pages, web log files, click streams, search indexes, social media forums, instant messaging, text messages, email, documents, consumer demographics, and sensor data from active and passive systems, etc.

Velocity – Being able to perform analytics on thousands of transactions a second is becoming mission critical. Analytic modelling, continual scoring and efficiently storing the throughput of this high volume has become critical.

Variety – Harnessing structured, semi-­‐structured and unstructured information to gain insight by correlating them together has become a key business requirement for many organizations.

Vitality – Neither problems nor opportunities are static. Big Data analysis and predictive models need to be updated as changes occur to seize opportunities as they come.

Cities worldwide are not only focused on reducing costs and improving operational efficiency, but are also addressing business growth objectives, including business © EPIC Consortium

28

Version 1.0, 05/07/2011

EPIC – D2.3 analytics and optimization. Enterprises are looking for greater efficiencies beyond individual department and beyond the enterprise. This focus, combined with rapid growth of internet scale data and availability of sophisticated innovation to harness this Big Data cost effectively, is creating a groundswell of opportunity, leading to greater competitive advantage. In EPIC, enabling connected cities to efficiently and effectively share information an analytics capabilities e.g. through the semantics enabled search in the citizen-­‐centric, one-­‐stop Government relocation service sets the context for this new way of city operations – to reduce cost and stimulate the local economy.

All of this is resulting in two important technology drivers: •

•

New Types of Analytics Workloads: Semi-­‐structured and unstructured information management technologies require new approaches to finding predictive patterns and insights. IBM InfoSphere BigInsights is ideally suited for this challenge due to its ability to handle these volumes and information types. The platform runs on commonly available, low-­‐cost hardware in parallel, supporting linear scalability. Flexible enough to be used for semi or unstructured information, the platform does not require lengthy pre-­‐pre-­‐ processing and allows for structure and associations to be added on the fly across information types. Industry strength analytics are core to massive scale data processing.

Combining “in the moment” with “after the fact:” Big Data strategies need to be in context with existing database, data warehouse, stream analytics and ETL (Extract, Transform and Load) infrastructures. IBM can also provide comprehensive objective guidance to customers on when to choose pure Hadoop [3] versus hybrid Hadoop-­‐warehouse strategies.

IBM as the acknowledged research and market leader in data analytics enables new solutions to gain insights from unprecedented information flows, which are exploding in volume, variety, velocity and vitality. These flows are so large that they define a new category: Big Data. They offer tremendous potential for deep insights that provide greater efficiencies, value add services and opportunity for transformation.

© EPIC Consortium

29

Version 1.0, 05/07/2011

EPIC – D2.3

Figure 10: Scan – Focus – Cue to enable a scarce Resource

From ultra-­‐low latency information-­‐in-­‐motion analytics capabilities, analytics oriented data warehouse solutions to innovative solutions like InfoSphere BigInsights, the IT market can offer the whole portfolio of Big Data capabilities with a holistic approach. InfoSphere BigInsights is an analytics platform that delivers unique IBM Research, IBM Emerging Technologies and IBM Software capabilities on top of Apache Hadoop framework enabling new solutions on a business-­‐ready platform. IBM has a holistic approach, expanding analytics to encompass Big Data, information streams, and structured data in Data Warehouses.

The newest part of the IBM Big Data portfolio is the InfoSphere BigInsights family of products, based on Apache Hadoop. While supporting open standards, InfoSphere BigInsights extends Hadoop into new types of analytics workloads and brings the power of Hadoop to business analysts, not just very technical developers.

Example use patterns include: • • • • • • • •

Holistic and proactive risk management and forecasting at Internet scale Entity identification and sentiment trending analytics Cross line of business fraud detection and prevention Unified modelling of in-­‐person and online customer purchasing behaviour IT management and system log analytics for better systems availability and management Customer intimacy and recommendation engines working at Internet scale Developing new lines of business that are Big Data dependant Bioinformatics workloads and genomic analytics.

4.3.1.2 Analytics – New Path to Value As stated in one of the last studies of the IBM Institute of Business Value [5], at organizations in every industry, in every part of the world, senior leaders wonder © EPIC Consortium

30

Version 1.0, 05/07/2011

EPIC – D2.3 whether they are getting full value from the massive amounts of information they have within their organizations. New technologies are collecting more data than ever before, yet many organizations are still looking for better ways to obtain value from this data and compete in the marketplace and/or support the digital society.

Questions about how to best achieve value persist; it is no longer adequate to know what happened and why. Whether focused on growth, efficiency or innovation, organizations need to know what is happening now, what is likely to happen next and what actions should be taken to get the optimal results. By embedding information and insights into every day operations, it is possible to provide that value.

Among the key findings of the study: top-­‐performing organizations use analytics five times more than lower performers. Overall, our study found widespread belief that analytics offers value. Half of the respondents said that improvement of information and analytics is a top priority in their organizations. And more than one in five said they were under intense or significant pressure to adopt advanced information and analytics approaches.

While these findings showed that organizations tend to wait until they have gained some experience before they apply analytics to growth objectives, this may be more a common practice than a “best practice.” Experience indicates that analytics, applied wisely to an organization’s operational capabilities, can be used to accelerate a broad range of business objectives, even at the earliest stages of analytics adoption. Top performing organizations put analytics to use in the widest possible range of decisions, large and small. They were twice as likely to use analytics to guide future strategies, and twice as likely to use insights to guide day-­‐ to-­‐day operations (see Figure 11).

Figure 11: Organization’s usage of insights

Despite popular opinion, getting the data right is not a top challenge organizations face when adopting analytics. Only about one out of five respondents in this study © EPIC Consortium

31

Version 1.0, 05/07/2011

EPIC – D2.3 cited concern about data quality or ineffective data governance as a primary obstacle. The adoption barriers that the organizations face are mostly related to management and culture rather than data and technology. The leading obstacle to widespread analytics adoption is lack of understanding of how to use analytics to improve the business, according to almost four of ten respondents. More than one in three cites lack of management bandwidth due to competing priorities.

Organizations that use analytics to tackle their biggest challenges are able to overcome seemingly intractable cultural challenges and, at the same time, refine their data and governance approaches.

Executives need better ways to communicate complex insights so they can quickly absorb the meaning of the data and take action on it. Over the next two years, executives say they will focus on supplementing standard historical reporting with emerging approaches that make information come alive. These include data visualization and process simulation, as well as text and voice analytics, social media analysis and other predictive and prescriptive techniques.

It takes big plans followed by discrete actions to gain the benefits of analytics. But it also takes some very specific management approaches. Based on data from that study, IBM’s engagement experience, case studies and interviews with academics and experts, a new framework has been identified for successfully implementing analytics-­‐driven management and for rapidly creating value: •

•

•

Pick your spots. Search for your organization’s biggest and highest priority challenge. Change is hard for most, so select an initiative worthy of sustained focus that can make the biggest difference in meeting your most important business goals.

Prove the value. Use reason and benchmarks for initial executive sponsorship, but use a proof-­‐of-­‐value pilot to keep sponsors engaged.

Employ embedded analytics techniques to illustrate and prioritize the types of organizational changes that are needed to achieve the value. Pull it all together using an implementation roadmap with a clear starting point and a range of options for future opportunities.

Continuous value delivery. Reduce your rework by using business analytic and process management tools that you have selected for the long haul – information governance, business analytics and business rules. As you make progress, don’t forget to analyse feedback and business outcomes to determine where your analytics model and business vision can be improved.

Over time, data-­‐driven decision making branches out across the organization.

As experience and usage grow, the value of analytics increases and business benefits accrue more quickly.

4.4 Semantics In multilateral scenarios in which different organizations or nations exchange their data there is a definite need to avoid misinterpretation and misunderstanding when using terms and data structures. Technologies for technical as well as semantic © EPIC Consortium

32

Version 1.0, 05/07/2011

EPIC – D2.3 interoperability and knowledge representation by ontologies will ensure to overcome technical and semantic interoperability problems as well as multilingual barriers in the EPIC platform. XML, XML schema languages and data models implemented as ontologies, are technologies identified by the European Interoperability Framework 1.0 (EIF 1.0 [11]) for achieving interoperable integration of pan-­‐European IT services.

4.4.1 Approaches, Implementations and Standards In the following, semantically related approaches, technologies and standards to be used in EPIC are discussed.

4.4.1.1 XML Schema and semantic models XML schema, published by W3C as recommendation, is one of several XML schema languages. An XML schema is a description about the structure of XML documents.

The schema constraints XML documents and enforces them to have a specific struc-­‐ ture and also enables to restrict the XML documents so that they consist of particular data elements and values. However, XML schema does not, and cannot by itself, deliver semantic interoperability. This is achieved through common semantics to be developed on the basis of XML. Semantic Annotations for WSDL and XML Schema (SAWSDL) is a recommendation of W3C which provides a mechanism to supply XML schemata with semantic models. It is not a language for representing semantic models. Instead it provides a mechanism for referencing concepts from the semantic models, from within the XML schema.

4.4.1.2 Ontologies The term ontology is defined as “an explicit specification of a conceptualization” [45]. Such a representation provides a shared vocabulary which can be used to model a domain. An ontology can then be employed as a knowledge representation of concepts (terms) that are referred from within XML schemata. Here, the ontology represents the semantic models being used by the XML schema, providing the actual meaning of terms and their differences.

In the context of EPIC, ontologies will be used for interoperability purposes between multilingual cooperating partners, like different nations. Ontologies consist of a common knowledge representation of the domain to be described on which all partners agree. Lexical items (words) for concepts/objects that are missing in one language might occur in another language. In order to avoid misunderstandings all those terms have to be arranged into an ontology and to be interrelated in a manner that the computer can understand the differences and relations between specific terms. Therefore, confusion about (multilingual) terms is avoided.

Several ontology description languages for constructing ontologies are suggested for ontological engineering.

© EPIC Consortium

33

Version 1.0, 05/07/2011

EPIC – D2.3 Resource Description Framework schema (RDF schema), published by W3C, is an extensible knowledge representation language suited for building ontologies. RDF provides formal information about objects, so called Recourses identified by a unique identifier (URI). RDF is nowadays widely used in applications including catalogue services, social networks, semantic web browsers, music databases and others.

Besides, the Web Service Modelling Language (WSML) represents a family of ontology description languages for semantic web services. These languages are used to describe aspects of web services semantically and therefore help to develop a semantic web. In the context of EPIC such a language can be employed to describe each web service that EPIC provides, make it accessible to other parties and provide additional semantic information about the service that can be processed by other IT systems in a meaningful manner. WSML was used in the EU project SemanticGov which aims at providing integrated public services to citizens with the use of Semantic Web Technologies.

4.4.1.3 An Artificial controlled language grammar The Command and Control Lexical Grammar (C2LG) was initially developed to ensure semantic interoperability of multilateral command and control operations between different nations. It provides a means to define unique and unambiguous artificial languages for communication in multilingual scenarios. A message of a language modelled on C2LG consists of sentences that are human-­‐readable as well as machine-­‐readable and thus automatically processable. Because of its low complexity, it is easy to be adopted and understood by new cooperation partners. It also provides a means for semantic interoperability and an approach to handle multilinguality because a C2LG message in one language can easily be transformed into another language.

In addition, every C2LG language is defined by an XML schema. In the context of EPIC an artificial language based on C2LG which is in harmony with the XML schema to be developed for semantic interoperability will enable the EPIC platform to generate natural language sentences out of XML data. Because those sentences can be generated in arbitrary languages, the sentences can then be well used in front-­‐ end and back-­‐end multilingual delivery of services to the end-­‐user. Again, by ensuring a common understanding within several nations this contributes to ensuring semantic interoperability.

The XML schemata and the semantic models (in form of ontologies) agreed upon should be provided with the platform in order to reduce cost and to avoid the need to develop separate mechanisms for interchanging data for applications that were developed with different vocabularies and with different perspectives on the data.

By specifying those constraints about the XML data to be interchanged, all applica-­‐ tions using the schema are enforced to have a unified common understanding of domain-­‐specific terms and data structures.

© EPIC Consortium

34

Version 1.0, 05/07/2011

EPIC – D2.3

4.5 Internet of Things The Internet of Things (IoT) is a term used widely to describe a vision of a world of interconnected heterogeneous objects, which communicate and exchange information using a combination of short-­‐range wireless and Internet backhaul. The use of Radio-­‐Frequency Identification (RFID) tags or other forms of data carriers such as 2D codes is an implicit element of IoT, to identify uniquely each “object” and therefore provide the link to data about each object held somewhere within IoT. The foundations of the IoT started as a vision developed within the AutoID Center at Massachusetts Institute of Technology (MIT), as a potential solution to the problem of tracking fast-­‐moving consumer goods in retail supply chains. IoT was predicated on the future availability of very low-­‐cost passive radio-­‐frequency identification (RFID) technology, which would allow individual items to carry a unique identifier, termed an Electronic Product Code (EPC).

Using pervasive connectivity to the Internet, the EPC read from the RFID tag could be used to link the item to information held about the item distributed across the Internet. This also required a series of standards, in part built on standards for the Internet, to allow the EPC to access product data. These standards included the EPC code; Physical Markup Language (PML) based on XML for describing objects, and Object Naming Services (ONS) which in essence acts in a similar way for object to the way DNS works for web-­‐domains, where DNS translates a web-­‐site domain name into IP address. For more information consult http://autoid.mit.edu/cs/. The predominant focus on EPC and the necessary underpinning technologies and standards have since been widened to encompass wireless sensor networks, which have the ability to contribute local contextual information to supplement item-­‐based data.

The USA view of EPC and the IoT initially focused primarily on retail items, driven by the business needs to deliver enhanced supply-­‐chain visibility to large corporations such as Gillette and Proctor & Gamble. In Japan however things took a very different turn, partly due to the very rapid development of high-­‐speed mobile data networks (mobile broadband) in conjunction with the Japanese semiconductor and mobile handset manufacturers. The combination of mobile phones with significant computing power and data storage connected to the Internet by a high-­‐ speed Cellular network drove an alternative model of what was termed Ubiquitous Computing.

The mobile phone became the interface of choice between objects and data about those objects, with a particular emphasis on information about places and location based services to support individuals. This was in one-­‐sense “inside”-­‐out from the USA model driven by supply-­‐chain visibility needs. EPC envisaged billions of items carrying EPC tags moving amidst networks of fixed and mobile readers to deliver business intelligence via the Internet to major manufacturers.

The Japanese model was rather different. Mobile readers (mobile phones) owned by citizens and connected to Internet by high-­‐speed mobile networks moved through © EPIC Consortium

35

Version 1.0, 05/07/2011

EPIC – D2.3 the built environment. These used identifiers and location based services to display on the user’s mobile handset information about the current location and environment generally within a social rather than business context. In this usage model, RFID tags had little relevance as phone handsets were not equipped with RFID readers and the built-­‐environment was not “marked-­‐up” with RFID tags.. 2D codes which could be readily printed and deployed became a significant enabler for ubiquitous computing approaches, exemplified by QR code in Japan The rise of Cloud Computing and in particular access to both large data clouds and seamless mechanisms to identify available web-­‐services that provide data about objects, combined with mobile computing, provides the infrastructure for IoT type systems. From one perspective this is simply the cumulative result of the progression towards greater inter-­‐ connectivity between increasingly intelligent objects and the convergence of fixed and mobile computing and the Internet. As such, IoT can act as a societal enabler, empowering citizens and democracy by providing free access to information about “things”. From an alternative perspective, IoT could represent a disturbing vision of a “Big Brother” surveillance society, where everything is known about everything and everyone, thereby removing entitlements to privacy.

One of the challenges for IoT is to maintain a balanced perspective, respecting the rights of citizens to individual freedom and privacy whilst empowering them and others through greater access to relevant personalised information feeds in real-­‐ time.

4.5.1 Approaches, Implementations and Standards Although we use freely the term “Internet of Things”, what is meant by this term varies according to the context of use. There is no single “standard” that defines what IoT is or how devices that form part of an IoT application should operate.

Given the diverse range of technologies that represent core components of IoT, there are many different sets of existing standards that together represent part of the IoT standards.

4.5.1.1 IP Networks To become a part of IoT, devices must be able to communicate using established IP protocols. The Internet Protocol (IP) suite is a four layer model that provides the protocols for devices that intercommunicate using the Internet and the four layers from Application (top layer) to Link (lowest layer) are shown below, together with key IP elements.

© EPIC Consortium

36

Version 1.0, 05/07/2011

EPIC – D2.3 Table 1: IP Suite Internet Protocol (IP) Suite Application Layer Transport Layer Internet Layer Link Layer

DHCP, DNS, HTTP etc.

TCP, UDP, etc.

IPv4 , IPv6, etc.

Local devices and local network connectivity

4.5.1.2 End-Point Devices Whilst it is tempting to assume naively that every Thing within the IoT will have a unique and static IPv6 address by which it will be identified, this is not a feasible proposition and dynamic IP addressing will be the norm for a considerable period, given the legacy of IPv4. Furthermore the majority of Things will carry only low-­‐cost passive RFID tags or 1D or 2D codes that cannot support the concept of dynamic addressing. Sensors of varying degrees of smartness also form elements of IoT and can form wireless sensor networks which may have an Internet / IoT gateway.

Mobile data devices, including mobile phones, mobile computers, RFID tag readers on buses, etc. also represent end-­‐point devices on IoT, as they provide a local connectivity point for Things, whether these are smartcards for transport or receivers of data driven services.

The sensors that feed data into web services, accessible through the EPIC cloud platform, could range from very simple single variable sensors such as electrical power or temperature, through small networks of wired and wireless sensors, to extensive sensor networks common within Building Management Systems (BMS) used in commercial premises, social housing, etc. The key requirement here is that, given the heterogeneous nature of sensors and the need to consume data from sensors currently in place, it will be necessary to define which standards can be supported and a range of meta-­‐data descriptions for sensor data payloads to ensure that these can be readily accommodated within the EPIC platform.

The IEEE Standards Association describes IEEE 1451 ‘as a family of Smart Transducer Interface Standards, which describe a set of open, common, network-­‐ independent communication interfaces for connecting transducers to networks.

These standards rely on Transducer Electronic Data Sheets (TEDS) which is a local memory device that stores transducer identification, calibration, correction data and manufacture-­‐related information. The goal of 1451 is to allow the access of transducer data through a common set of interfaces whether the transducers are connected to systems or networks via a wired or wireless means. The family of IEEE 1451 standards is sponsored by the IEEE Instrumentation and Measurement Society’s Sensor Technology Technical Committee’ [20].

As described on the site, the most relevant of these standards are: © EPIC Consortium

37

Version 1.0, 05/07/2011

EPIC – D2.3 •

IEEE P1451.0 defines a set of common operations and TEDS for the family of IEEE 1451 smart transducer standards. The functionality is independent of the physical communications media between the transducer and a network connected Applications Processor (NCAP). This makes it easy to add other proposed 1451.X physical layers to the family.

•

IEEE 1451.1 defined a common object model and programming paradigm for smart transducer systems. This software runs on the NCAP and interacts with transducers through the other 1451.X physical layers standards.

Communications between groups of NCAPs and higher-­‐level systems are supported in a network neutral manner.

•

IEEE 1451.2 defined a transducers-­‐to-­‐NCAP interface and TEDS for a point-­‐ to-­‐point configuration. This standard is being revised to support two popular serial interfaces: UART and USB.

•

IEEE 1451.3 defined a transducer-­‐to-­‐NCAP interface and TEDS for multi-­‐drop transducers using the HPNA communication protocol. It allows many transducers to be arrayed as nodes, on a multi-­‐drop transducer network, sharing a common pair of wires.

•

IEEE 1451.5 defines a transducer-­‐to-­‐NCAP interface and TEDS for wireless transducers. Wireless standards such as 802.11 (Wi-­‐Fi), 802.15.1 (Bluetooth), 802.15.4 (ZigBee) are being considered as some of the physical interfaces.

In the context of IoT, clearly an NCAP could be an intelligent node that aggregates data feeds from local sensors of varying degrees of smartness, effectively acting as the IoT access point to the network of building sensors. The NCAP could be a simple gateway box for a small number of sensors or could actually be a gateway to a building management systems or other system in larger systems. The NCAP, assuming this is local to a property or building zone, could contain meta-­‐data about the building or zone. Alternatively it might be possible to contain some of this is the TEDS. Whilst it is probably not realistic that every sensor used within EPIC for energy monitoring should comply with IEEE 1451, it is essential that meta-­‐data markup of both the sensor data and the context of use of the sensor is carefully considered to allow data aggregation and comparison from for example similar property types / regions / households, etc.

4.5.1.3 RFID Air-Interface Standards From an IoT perspective, EPC has become synonymous with RFID and in particularly the concept of an EPC tag, i.e. a very low cost RFID tag which holds an EPC identifier attached to items or things. The EPC concept was initially built on the assumed availability of very low-­‐cost UHF (860-­‐930 MHz) passive (battery-­‐less)

© EPIC Consortium

38

Version 1.0, 05/07/2011

EPIC – D2.3 tags at a pricing point which would allow the tags to be disposable and therefore useable on low-­‐cost everyday grocery items for example.

RFID tags have two primary characteristics that affect usage, namely operating frequency and maximum allowable RF power, both defined by International Standards. RFID devices are currently allocated five main frequency bands for worldwide operation: • • • • •

LF: 125-­‐135 KHz, typically used for access control, animal tagging; industrial use HF: 13.56 MHz, common for libraries and also used for contactless smartcards VHF: 433 MHz, commonly for active tags for real-­‐time location UHF:860-­‐960 MHz (regional variations in spectrum slot), EPC tags operate in this region Microwave:2.45 GHz and some 5.8 GHz, including Wi-­‐Fi 802.11x active tags

The ISO/IEC 18000 series of standards defines the operation of radio frequency identification (RFID) air interfaces for item identification and management. ISO/IEC 18000 has been designed to encompass a full range of data capture and carrier functionality. Both read and write operations are enabled, and the interfaces can efficiently support both simple and complex data transactions. Developments such as EPC have focused attention on 'identification data element' operation of RFID systems, where the RFID tag primary holds only sufficient data to permit reference to attribute information held elsewhere. ISO/IEC TR 24710:2005 has been prepared to assist users intending to implement ISO/IEC 18000 RFID air interface standards, with particular focus on so-­‐called elementary tags, i.e. tags possessing limited memory -­‐ typically but not exclusively 256 bits or less -­‐ and lacking write capability.

Bodies external to ISO also specify identification data element length and structure for particular applications.

The ISO/IEC 18000 standards primarily govern the air-­‐interfaces of the tags in each of the allocated frequency slots. The issues surrounding data protocols, data representation and data encoding for specific purposes are also held in other standards.

© EPIC Consortium

39

Version 1.0, 05/07/2011

EPIC – D2.3 Table 2: ISO/IEC 18000 standards Standard

Title

ISO/IEC 18000-­‐1:2004

Radio frequency identification for item management. Reference architecture and definition of parameters to be standardized

ISO/IEC 18000-­‐2:2004

Radio frequency identification for item management. Parameters for air interface communications below 135 KHz

ISO/IEC 18000-­‐3:2010

Radio frequency identification for item management. Parameters for air interface communications at 13,56 MHz

ISO/IEC 18000-­‐4:2004

Radio-­‐frequency identification for item management. Parameters for air interface communications at 2,45 GHz

ISO/IEC 18000-­‐6:2010

Information technology. Radio frequency identification for item management. Parameters for air interface communications at 860 MHz to 960 MHz

SO/IEC 18000-­‐7:2008

Information technology. Radio frequency identification for item management. Parameters for active air interface communications at 433 MHz

The active RFID technology and increasing numbers of battery assisted passive (BAP) or semi-­‐active tags is increasingly capable of delivering sensor data, for example, to monitor and log temperature within refrigerated transport. As RFID devices can only communicate when interrogated by a suitable device, local data is buffered into the tag memory and communicated only when the tag is interrogated.

4.5.1.4 Item Identification Standards and the Electronics Product Code (EPC) The term EPC or Electronic Product Code has become synonymous with item identification, IoT and RFID, despite the large number of well-­‐developed RFID standards that pre-­‐dated the emergence of EPC. Significant numbers of widely used standards associated with item identification have existed since the 1970’s, when barcodes offered the first very low-­‐cost machine readable identifiers that could be used to link to item data held in a networked system. The standards for Retails Supply-­‐Chains were administered by the European Article Numbering Association (EAN) in Europe and by the Uniform Code Council (UCC) in the USA. Subsequently, and in response to the rise of global trade, EAN and UCC formed GS1, an international not-­‐for-­‐profit association with Member Organisations in over 100 countries. GS1 is dedicated to the design and implementation of global standards and solutions to improve the efficiency and visibility of supply and demand chains globally and across sectors.

The GS1 system of standards is the most widely used supply chain standards system in the world and has been widened in response to worldwide developments in ecommerce, ICT, RFID and EPC. GS1 in essence deals with the number systems and © EPIC Consortium

40

Version 1.0, 05/07/2011

EPIC – D2.3 identification schemas that are used to identify objects. The barcode identifiers found on retail items are allocated to manufacturers by GS1 and are more correctly referred to as GTINs or Globally Traded Identifying Numbers. The GS1 standards accommodate EPC, which while is being increasingly adopted for supply chain use, typically at a case level rather than item level, will for many years – come to a need for co-­‐existence with existing barcode and other standards for item identification.

4.5.1.5 Summary of Standards EPIC will host a generic sensing, monitoring and control framework to nurture the smart energy service as described below and therefore can afford to be agnostic of these “low-­‐level” communication standards. The framework instead will be cognisant of, and build on where appropriate, the myriad of existing, emerging and proposed standards that govern both communications within and across IP networks and increasingly govern the operation, data protocols and data mark-­‐up for devices forming part of the Internet of Things. This will provide the future extensibility path which must be an integral component of integrated and intelligent monitoring services for Smart Cities applications, allowing extension to socially important tasks such as tele-­‐monitoring of vulnerable people etc.

This is particularly important for the Energy Monitoring pilot, where the nature of the application, i.e. a heterogeneous network of widely distributed sensors of differing degrees of complexity presents very different challenges to that of the other two demonstrators in EPIC.

4.6 Front-Ends – Mobile Devices Platforms Mobile Business comprises a new era in computing. The explosive mobile growth through 2010 depends on infrastructure; mobile devices are a catalyst for IT growth: just like the browser sparked the growth of the web and e-­‐business, mobile devices are bringing on new opportunities, growth and IT spending.

© EPIC Consortium

41

Version 1.0, 05/07/2011

EPIC – D2.3

Figure 12: Estimated growth of mobile spend [35]

4.6.1 Approaches, Implementations and Standards Banking

Insurance

EXTENDING EXTENDING BUSINESS BUSINESS TO TO MOBILE MOBILE CUSTOMERS CUSTOMERS AND AND WORKFORCE WORKFORCE

Health Care

Telecom

IMPROVE IMPROVE OPERATIONAL OPERATIONAL EFFICIENCIES EFFICIENCIES AND AND REDUCE REDUCE COSTS COSTS

Retail

Government

DIFFERENTIATE DIFFERENTIATE THE THE CUSTOMER CUSTOMER EXPERIENCE EXPERIENCE

Others

ENABLE ENABLE NEW NEW SERVICES SERVICES AND AND BUSINESS BUSINESS MODELS MODELS

Business Results Customer Interaction

Asset Management

Collaboration & Social Networking

Business Analytics

Services and Business Model Innovations Service Assurance

Information Management

Dynamic Process Integration

Location Awareness

BSS/OSS Transformation

MOBILE APPLICATION CAPABILITIES

Configuration Management

Device & App Management

Mobile Commerce

Device Hardware SERVICE CREATION & TRANSFORMATION

SERVICE EXECUTION

MOBILITY DATA

MOBILITY ANALYTICS

SERVICE MANAGEMENT

NETWORK SERVICES

END-TO-END SECURITY & PRIVACY INFRASTRUCTURE AND VIRTUALIZATION SERVICES – CLOUD AND TRADITIONAL

Mobile Foundation

Figure 13: Mobile Business components [35]

Growth in demand for advanced mobile devices boasting powerful processors, abundant memory, larger screens and open operating systems has outpaced the rest © EPIC Consortium

42

Version 1.0, 05/07/2011

EPIC – D2.3 of the mobile phone market for several years and introduced the smartphone market which is constantly increasing its shares. A smartphone can be defined as a cellular telephone with built-­‐in applications and Internet access. Smartphones provide digital voice service as well as text messaging, e-­‐mail, Web browsing, still and video cameras, MP3 player, video viewing and often video calling. In addition to their built-­‐in functions, smartphones can run myriad applications, turning the once single-­‐minded cell phone into a mobile computer.

A key feature for smartphones is the operating system that they are based on. The market leaders in the area of operating systems are Symbian, Android, iOS, Research in Motion (Blackberry) and Microsoft Windows Mobile. The following diagram [14] depicts an analysis of the overall market.

Figure 14: Smartphones’ operating systems distribution on the overall market

Applications that run on smartphones depend on the relevant operating system of each device. A new approach to this multi-­‐platform oriented development of applications is the use of HTML5 which aims to achieve the ‘build once, run everywhere’ goal. A brief description for each of the aforementioned operating systems, as well as HTML5 is following: 4.6.1.1 Symbian Symbian [37] is one of world’s most popular smartphone platforms. It’s implemented in a diverse range of devices and provides app and media developers with a consistent set of technologies. The flexibility of Symbian means it can offer users classic mobile devices, utilising a standard keypad and QVGA screen, through to high-­‐end smartphones that offer nHD touch screens with tactile feedback, full © EPIC Consortium

43

Version 1.0, 05/07/2011

EPIC – D2.3 keyboards, and device sensors in innovative flip and slide form factors. Equally at home delivering advanced enterprise apps, games, or music, Symbian provides developers with unparalleled opportunities in the mobile space.

To create apps, developers can use the recommended Nokia Qt SDK and a set of other technologies. Content developers have comprehensive support for audio, image, and video formats. In addition, Adobe Flash Lite and SVGT can be used for animated content, while the S60 Browser supports standard desktop web technologies. Artists and graphic designers can create themes for S60 devices that can completely alter a device’s look and sound. The applications that run on Symbian can be found on Nokia’s online market called Ovi Store. Moreover customers can download mobile games, videos, images, and ringing tones to their Nokia devices from the same place.

It must be noted that Nokia, the owner of Symbian, has announced [38] an agreement with Microsoft to use the Windows Phone 7 operating system in the future, so the production of Symbian-­‐based smart-­‐phones from Nokia will stop in the future.

4.6.1.2 Android Android [2] is a software stack for mobile devices that includes an operating system, middleware and key applications and it is developed and released by Google. All Android applications are written using the Java programming language.

A large number of smartphones built by different manufacturers is based on Android.

The main features of the Android platform are the following: • • • • • • • • • •

Application framework enabling reuse and replacement of components Dalvik virtual machine optimized for mobile devices Integrated browser based on the open source WebKit engine Optimized graphics powered by a custom 2D graphics library; 3D graphics based on the OpenGL ES 1.0 specification (hardware acceleration optional) SQLite for structured data storage Media support for common audio, video, and still image formats (MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, GIF) GSM Telephony (hardware dependent) Bluetooth, EDGE, 3G, and WiFi (hardware dependent) Camera, GPS, compass, and accelerometer (hardware dependent) Rich development environment including a device emulator, tools for debugging, memory and performance profiling, and a plugin for the Eclipse IDE

© EPIC Consortium

44

Version 1.0, 05/07/2011

EPIC – D2.3

Figure 15: Android component diagram [2]

Android, through its open development platform, offers developers the ability to build extremely rich and innovative applications. The application architecture is designed to simplify the reuse of components and the developers have full access to the same framework APIs used by the core applications. Any application can publish its capabilities and any other application may then make use of those capabilities (subject to security constraints enforced by the framework). This same mechanism allows components to be replaced by the user.

Android Market is the online software store developed by Google for Android devices. An application program ("app") called "Market" is preinstalled on most Android devices and allows users to browse and download apps published by third-­‐ party developers, hosted on Android Market.

4.6.1.3 iOS iOS [21] is Apple’s mobile operating system. iPhone 4 is the latest mobile device in the market based on iOS 4.3. Technologies shared between iOS and Mac OS X includeOS X kernel, BSD sockets for networking, and Objective-­‐C, and C/C++ compilers for native performance. The iOS also delivers a wide-­‐range of graphics capabilities, ranging from comprehensive 2D drawing to accelerated 3D rendering and direct access to the system’s video playback and capture capabilities. Accessible through high-­‐level frameworks, these capabilities make it easy to create animations and transitions within the application’s UI. Some of the major features that are supported by iOS are: © EPIC Consortium

45

Version 1.0, 05/07/2011

EPIC – D2.3 • • • • • • • • •

Multitasking which enables instant switch between apps Folders to help users organize apps into folders with drag-­‐and-­‐drop simplicity Game Center an online multiplayer social gaming network Email client which allows viewing of messages from different accounts Multi-­‐Touch Gestures Push Notifications Core Location using information from the present network connection, and GPS signals where available to determine the present location.

Cut, Copy and Paste support to easily move text, HTML and images Gyro + Accelerometer to be used by motion-­‐aware applications

iOS SDK is the software development kit created by Apple to develop native applications for iOS. Developers have to use this SDK in order to create applications to be distributed through the App Store, which is Apple’s online store.

4.6.1.4 RIM (Blackberry) BlackBerry OS [4] is a proprietary mobile operating system, developed by Research In Motion for its BlackBerry line of smartphone handheld devices. The operating system provides multitasking and supports specialized input devices that have been adopted by RIM for use in its handhelds, particularly the trackwheel, trackball, and most recently, the trackpad and touchscreen.

The BlackBerry platform is perhaps best known for its native support for corporate email, which allows complete wireless activation and synchronization with various email servers. The latest version is BlackBerry OS 6.0. The BlackBerry platform supports several different ways of developing applications, themes, rich mobile websites and widgets. These include the BlackBerry Tablet OS SDK, the BlackBerry WebWorks platform for web applications, the BlackBerry Theme Studio for BlackBerry smartphone themes and animated graphics and an API for Java application development.

The BlackBerry App World is RIM’s online storefront for application and theme distribution for Blackberry devices.

4.6.1.5 Windows Phone 7 Windows Phone 7 [43] is the mobile operating system developed by Microsoft.

Windows Phone features a new user interface, based upon Microsoft's Windows Phone 7 design system, codenamed Metro. The home screen, called the "Start screen", is made up of "Tiles" which are links to applications, features, functions and individual items (such as contacts, web pages, applications or media items). Several features of Windows Phone 7 are organized into "hubs", which are trying to bring together related content into a single place for consumption and interaction. There are 6 hubs on Windows Phone 7 Series devices [7] including:

© EPIC Consortium

46

Version 1.0, 05/07/2011

EPIC – D2.3 1. People. This hub delivers an engaging social experience by bringing together relevant content based on the person, including his or her live feeds from social networks and photos. It also provides a central place from which to post updates to Facebook and Windows Live in one step.

2. Pictures. This hub makes it easy to share pictures and video to a social network in one step. Windows Phone 7 Series also brings together a user’s photos by integrating with the Web and PC. 3. Games. This hub delivers the official Xbox LIVE experience on a phone, including Xbox LIVE games, Spotlight feed and the ability to see a gamer’s avatar, Achievements and gamer profile.

4. Music + Video. This hub offers multimedia experience to users, including content from a user’s PC, online music services and even a built-­‐in FM radio into one simple place that is all about music and video.

5. Marketplace. This hub allows the user to easily discover and load the phone with certified applications and games.

6. Office. This hub brings Microsoft’s Office software to the Windows Phone.

This allows users to easily read, edit and share documents. With Outlook Mobile, users are also able to follow their emails while on the go.

Other future features [12]of the Windows Phone 7 platform include: • • • •

Copy and paste functionality.

Twitter integration directly into the People Hub Support for Office documents in the cloud Enhanced Web browser experience based on Internet Explorer 9

Microsoft also provides a set of tools for the development of applications and games for Windows Phone 7 with Visual Studio 2010 and Expression Blend being the major ones. Several APIs are also available to give developers access to more of the phone’s hardware like the Motion Sensor library and the camera which enable the development of augmented reality applications.

The Windows Phone Marketplace is used to digitally distribute music, video content, podcasts, and third party applications to Windows Phone handsets. The marketplace is managed by Microsoft and it includes an approval process for every application before it can be available through it.

4.6.1.6 HTML5 for Mobile HTML 5 [18] represents the biggest leap forward in web standards since the current (4.01) specification, which was completed in September 1999. But unlike the specifications that came before it, HTML 5 is not merely intended to present content in a web browser. Its goal is to bring the web to maturity as a full-­‐fledged application platform and to become a level playing field where video, sound, images, animations and full interactivity between computers are all standardized. Support for offline data syncing is a big part of the drive toward standardizing the way browsers interact with some of the cutting-­‐edge web apps being created.

© EPIC Consortium

47

Version 1.0, 05/07/2011

EPIC – D2.3 HTML5 is still in its infancy, but one of the more promising tools it offers is a built-­‐ in, offline data storage format. The Application Cache API, as the offline tool is known, allows web applications to store their current state on the client side -­‐ that is, the web browser. Using this method, the user can continue to interact with web applications even without internet access. The next time he/she connects, all of the changes they made locally are synced with the web service.

HTML5 supports is already being incorporated into WebKit, the underlying code in browsers like the iPhone’s Mobile Safari and Android’s built-­‐in browser. Within WebKit-­‐powered browsers, offline access just works -­‐ no extra plug-­‐ins needed.

There’s no need to write a separate app for every mobile platform -­‐ the same interface will work on any mobile device so long as the browser supports HTML 5.

Some of the key elements that HTML 5 [17] provides and could lead to the goal of “Write Once, Run everywhere” for mobile web applications are: •

•

•

•

Offline Support: The AppCache and Database make it possible for mobile developers to store things locally on the device and now that interruptions in connectivity will not affect the ability for someone to get their work done.

Canvas and Video: These two features are designed to make it easy to add graphics and video to a page without worrying about plugins. When supported by the phone’s hardware, as is the case with the iPhone, they provide a powerful way to get media into a page.

GeoLocation API: This is actually not part of HTML5, but is a separate specification [15] but it is often bundled together because the mobile phones that are including HTML5 are generally supporting the GeoLocation API. Advanced Forms: Even simple things like the improvements in HTML5 for forms could make life easier for mobile applications. Fields that can be validated by the browser are improvements for mobile devices. The more that can be handled by the browser means less time downloading JavaScript code and less round trips to the server if validation can be found before the form is posted.

4.6.1.7 Client/Mobile Programming The current smartphone market seems to be evolving towards domination by Google’s Android and Apple’s iOS operating systems. Although Nokia is still an important player in this market, its Symbian OS has been discontinued and a partnership with Microsoft to use Windows Phone has been announced [24].

Whereas the success of this partnership on the smartphone market is still to be determined, it is a safe to say that iOS, Android and Windows phone will be the operating systems that need to be targeted in the coming years.

As there is no dominant mobile OS yet, a strategy that allows the porting of applications to different mobile OS with as much code-­‐reuse as possible would offer significant cost reductions. A number of development platforms provide this opportunity. We will briefly discuss 3 different platforms that allow this.

© EPIC Consortium

48

Version 1.0, 05/07/2011

EPIC – D2.3 •

•

•

AppceleratorTitatinum mobile [39] is an open source framework that allows the creation of native applications for Android and iOS. It does not support Windows phone. Titanium mobile seems to be a promising platform, but last time we checked (January 2011), there were a large number of unsolved compiling issues, slowing down the application development process.

Phonegap [30] like Titanium mobile, Phonegap is an open-­‐source framework that allows applications to be create using mainstream, low threshold technologies, like HTML, CSS and JavaScript. A number of native API’s are available to allow the application to access native device functionality, like geolocation, the camera or multimedia playback. Once the app has been created, it can be built for several mobile OS, like iOS, Android, Palm, Symbian and BlackBerry. Windows Phone support is under development but should be available soon.

Flash/flex/Air: This technology by Adobe has been experiencing a troubled relationship with Apple, largely keeping it from the burgeoning Apple app store. Therefore, it has been unsure if developing expertise on this platform would be a good choice for the future. However, since some months, it is possible to publish Flash applications to iOS. Still, the resulting apps remain disappointing in terms of performance and UI responsivity. Beside these shortcomings, this is a solid technology with a strong position on the web that allows applications to be created for other important mobile OS, like Android.

Beside native applications, mobile browsers can also run applications in a browser.

Such web apps have the advantage that they don’t require any installation, are always up-­‐to-­‐date and can be relatively easily developed to work across multiple mobile OS. On the down side, web apps need an internet connection to work and are not able to access a number of native functionalities, like e.g. the camera on iOS through the mobile Safari browser.

An abstraction from the OS is desired in order to reduce effort for the development of the application and to avoid to be forced to develop several applications for each OS (Android and IOS).Given the state of mobile technology at the time of writing, we are researching (through the creation of small proof-­‐of-­‐concept prototypes) the creation of native apps using PhoneGap as a development framework for creation of mobile applications. This should allow us to support different mobile OS with a relatively small development effort.

As mentioned in D2.2, it is intended to employ the already existing augmented reality frameworks Layar or WikiTude, because they provide sophisticated AR functionality. Combining this, next it has to be discovered if augmented reality technology in form of existing frameworks (Layar, WikiTude) can be used within OS abstracting frameworks like Phonegap. Through a further inspection of the frameworks documentation and or prototypal experiments with the Phonegap framework this has to be discovered. In the worst case, one had to develop one AR part for Android and one AR part for IOS. © EPIC Consortium

49

Version 1.0, 05/07/2011

EPIC – D2.3 4.6.1.8 Immoweb Data Services Produpress is the company behind Belgium’s leading online real estate platform (http://www.immoweb.be). Produpress is currently expanding its services towards other channels (with a strong focus on mobile), and in order to do so is creating a re-­‐ usable web services infrastructure. Within the context of the project and the pilot, Produpress will provide access to and allow the use of the web services with geo-­‐ located real estate information.

The real estate data used by Produpress in the Immoweb application is provided by real estate brokers or private individuals. The data can be separated into 3 categories: •

•

•

Public address and location: address and location of the property is known to all users (only 30% of the real estate properties in Brussels delivered to Immoweb have an address and thus can be directly plotted on a map) Location only: only the location of the property is known. Because of risk of losing exclusivity, brokers are not always willing to make an address public because they don’t want the user to directly bargain with the owner of the property.

Postcode only: only postcode is available

Produpress has released an Immoweb application for iOS (iPhone) which, at the time of writing, had been downloaded approximately 15.000 from Apple’s App Store. Produpress is currently working on a 2nd version of the application that will also include geo-­‐locating technologies.

The data used by the iPhone app is completely disclosed and all (Brussels related) data used by the Immoweb website can be made available to the EPIC Relocation Service. The iPhone app uses REST web services to address Immoweb’s data sources. The resulting format of such a data request is delivered in the JSON-­‐format (JavaScript Object Notation).

The web services currently consumed by the iPhone app are: Table 3: Immoweb web service Immoweb web service

Description

GETESTATE

information about one property (ad)

GETRESULTS

list of properties (ads) (search result)

GETINFOS

list of Belgium’s areas and countries

GETQUERY

get criteria’s and counters from saved queries

DELQUERY

delete a saved query

GETPROJECT

get all the individuals estates belong to a project estate

© EPIC Consortium

50

Version 1.0, 05/07/2011

EPIC – D2.3 GETZIP

provide the zip code for given values of latitude and longitude

CHECKZIP

control the value of zip code

GETSAVEADS

provide the list of all the saved ads for a given customer

DELSAVEDADS

remove an estate from the list of saved ads

SAVEADS

add an estate in the list of saved ads

LOGIN

to log into MyImmoweb

NEWUSER

creation of a new customer in MyImmoweb

NEWPSWD

to modify an existing password

SENDOWNER

send information to a seller

SENDFRIENDS

send information to a friend about an estate

SAVEDQUERY

to save the criteria’s of a search query

CIBG data services CIBG (Brussels Regional Informatics Center) will provide access to services and combine Brussels government data-­‐sources into relevant services for the relocation application. Examples include population registry, school information, environmental data, crime rates, access to broader city-­‐related information. CIBG will also provide access to their UrbIS data sources (Brussels Urban Information System). These datasources contain cartographic and alphanumeric data for the Brussels-­‐Capital Region.

The UrbiS services can be separated into 6 parts – all of them to be visualized via the EPIC portal: • • • • • •

UrbIS-­‐Fot: arial picture sets UrbIS-­‐Ortho: edited arial picture sets UrbIS-­‐Topo: topographical data sets UrbIS-­‐Adm: administrative data sets UrbIS-­‐Map: vectorial graphical data used for maps UrbIS-­‐P&B: vectorial database of parcels and buildings

The data being returned by UrbIS services is intended for localization purposes and doesn’t contain metadata (detailed information).All UrbIS data can be consumed with the help of SOAP web services and data is returned in XML. Some of the web services provided by UrbIS: Table 4: WSGeloLoc UrbIS web service

© EPIC Consortium

51

Version 1.0, 05/07/2011

EPIC – D2.3 WSGeoLoc UrbIS webservice

Description

GetExtension

Gets the spatial extent of a street

GetXYCoord

Gets X and Y coordinates of a street

GetStreet

Finds streets (by name) and returns coordinates

GetStreetName

Find streets (by name)

GetAddressFromCoord

Finds an address and its Lambert-­‐72 coordinates (by Lambert-­‐72 coordinates)

GetStreetFromID

Finds a street (by ID)

GetZITType

Returns the types of points of interest in UrbIS

GetZI

Finds points of interest (by name and by type)

GetZIFromCoord

Finds points of interest (by Lambert-­‐72 coordinates)

There are already some applications written for the Brussels Region that consume data from the UrbIS framework. Most of them are GIS-­‐applications: Table 5: Applications consuming data from the UrbIS framework Name

Organization

Description

Geoloc

CIBG

location address, display the result on the base map Urbis, route calculation, adding dynamic maps in a website

OneWayMap

CIBG

One-­‐way road traffic overview

URBIZONE

CIBG

URBIZONE WiFi access points

Running for UrbIS

CIBG

WebGIS application of real-­‐time tracking of participants to test the 20 km of Brussels

PortailBruxellesmobilit é

Brussels Mobility mobility in the Brussels region

PortailBruxellesespace publics

Brussels Mobility Management of public spaces in the Brussels region

site des arbres

Brussels-­‐Capital Region

electronic cadastre and aerial photos of trees in the Brussels region

Primes à la renovation

Brussels-­‐Capital

renovation grants in the Brussels region

© EPIC Consortium

52

Version 1.0, 05/07/2011

EPIC – D2.3 Region BruGIS

Brussels-­‐Capital Region

Cartographic site of the Brussels-­‐Capital Region

RRU

Brussels-­‐Capital Region

Regional Planning Regulations

Monitoring des quartiers

Brussels-­‐Capital Region

monitoring of the 145 districts of Brussels

Bâtimentsexemplaires

Brussels Environment

exemplary buildings and sustainable neighborhoods

Espaces verts et promenade verte

Brussels Environment

Map of green spaces

GISMOB

Brussels Environment

company mobility

thermographieaérienne Brussels Environment

aerial thermography mapped

Wegwijs in Brussel

VGC

community facilities in the Brussels region: health, welfare, housing, culture

STIB

STIB

transit routes

Bruxelles social

CoCoF

social-­‐health in the Brussels region

CIBG will also be launching a new website in the coming months, containing points of interest in the city of Brussels. This new website will plot several types of interesting spots (like schools, libraries, etc.) onto a map (for now Google Maps).

Detail information of the points of interest is not (yet) available. This website could interact as a starting point for defining the points of interest used in the Relocation Application.

Points of interest (POI) suggestion The following POI data is available from CIBG (dispersed over multiple data sources) and will be considered for inclusion in the final relocation application scenario definition: •

Education: o Nursery schools o Primary schools o Secondary schools o Higher education: colleges/universities o European and international schools o Adult education centres

© EPIC Consortium

53

Version 1.0, 05/07/2011

EPIC – D2.3 •

•

•

•

•

Public transport: o Bus stations o Metro stations o Tram stations o Railway stations o Airports Security and healthcare: o Hospitals o Police stations o Day and child care facilities o General practioners Culture and youth: o Libraries o Youth centres/clubs o Youth movement Recreation and sports: o Sport centres o Children’s playgrounds o Parks o Green zones Entertainment: o Museums o Movie theatres

Filtering/querying points of interest The following filtering categories seem relevant in the context of the relocation application. As part of the future work, we will investigate their feasibility.

•

•

•

• •

Demographic (area): o Families with/without children (%) o Singles (%) o Age (%) Economy (area): o Unemployment rate (%) o Labour force participation rate (%) o Traffic congestion rate (%) Environment (area): o Noise pollution (Lden) o Air pollution (Nox): (µg/m³) o Water quality Health (area): o Mortality rate (%) Housing (area): o Property ownership: housing units occupied by owner or rented by tenants (%)

© EPIC Consortium

54

Version 1.0, 05/07/2011

EPIC – D2.3 •

o Social accommodation rate (%) Morphology (area): o Building heights (levels) o Population density (people/km2)

4.7 Augmented Reality Augmented Reality is a simple concept where there is overlay of a virtual image to reality. It could also be the reverse, meaning in adding to virtual 3D an image coming from the “real word” (Photo, Video or sounds).

There are several ways to implement augmented reality and the most common and successful at present is using a marker. Basically, you find a marker on a website or on the back of a magazine and you visit a website dedicated to the operation.

Connect your Smartphone towards the marker or use the GPS function and after few seconds a virtual image is superimposed on your marker, providing you additional information relative to what you are pointing with your Smartphone or with your mouse in a 3D real time virtual model.

Augmented reality has been used by military in the 80s with information dissemination in real time superimposed on the helmet visor pilots of fighter planes.

More and more applications propose augmented reality and in different domains: •

•

•

•

•

Advertisement: Augmented reality is used for example to insert advertisements in video images shot on sports fields: the logos of corporate partners of events can thus be always visible regardless of the angle chosen by the director; he is possible to display various messages on the same site.

Leisure: Augmented Reality can also plunge the user into the heart of a world partially real (real sets) and partly virtual (objects, animals ...). The user becomes an actor interacting with virtual objects by means of sensors.

Industrial: Augmented reality can insert cars existing only in a computer filmed in real locations (cities for example) and make them interact with the actual items to see the integration of the prototype in the real landscape.

E-­‐Commerce: Augmented reality is an aid to decision making in the purchasing for e-­‐commerce. This allows, in the case of the furniture industry, view the furniture in their own home just with a photo. The furniture is modelled in 3D and shown in its true proportions, at home for example.

Tourism: The principle of augmented reality is used in several applications on Smartphone (iPhone, Blackberry, Android). Augmented reality helps enrich the visitor experience by offering content related to what is being watching.

© EPIC Consortium

55

Version 1.0, 05/07/2011

EPIC – D2.3

5 Requirements Specification The overarching goal of the EPIC Project -­‐ European Platform for Intelligent Cities -­‐ is to develop a scalable, openly accessible platform that enables cities, citizens and service providers (in Europe) to create and share innovative web service-­‐based information and applications by offering different means of on-­‐boarding and subscription.

5.1 Methodology EPIC, as a CIP-­‐Pilot Action, cannot be considered a typical RTD project. The key role of LLs and the various stakeholders in all processes of the project lifecycle as well as the fact the outcomes do not refer only to software but also to a roadmap, required adaptation of the management, analysis and implementation methodologies to the particular needs of the project. In that sense, the definition and analysis of the user requirements did not follow an off the shelve methodology. Instead, but based on partners expertise and taking into consideration well-­‐established methodologies such the “Agile Development Methodology”. The principles of this methodology are well defined in the ‘Agile Manifesto’ [22]. According to the latter, changes in the user requirements are welcome, even late in the development process, while updated versions of the software are being delivered frequently. Agile development process encourages close and daily cooperation between business people and developers.

This means a numerous set of interactions between all partners, leading to the continuous definition of new requirements and the rapid delivery of useful working software. With this approach, it is more likely to meet the user’s needs, as they are involved at the process of the development having working software instead of presentation documents and slides.

The requirements analysis outcomes presented in this document are very important for the successful completion of the EPIC project as they are key input to the forthcoming WPs for the implementation of the platform and the roadmap. As Figure 16 indicates, D2.3 consolidates the results of all WP2 processes, namely the state-­‐of-­‐the-­‐art survey made by the technical partners along with the outcomes from the internal meetings that took place during this period and the three workshops at the pilot cities. Important contributors to the requirements acquisition and elicitation were the technology experts of the project, who in close collaboration with the pilot leads, identified and categorized the requirements for each platform element. This work will provide value input for the WP3 (“Platform Adaptation”) and WP4 (“Service Application Integration”) as it identifies the key guidelines to be taken into account during the implementation of the platform.

Considering the fact that part of the outcomes of the workshops was closely related to the business view of the project, it also affects WP6 for the development of the roadmap. With respect to the agile software development principals, the forthcoming packages will provide feedback to WP2 and requirements list which will be updated as the project evolves. In addition, the validation and evaluation of the platform both during the deployment phase for each scenario and the proof of © EPIC Consortium

56

Version 1.0, 05/07/2011

EPIC – D2.3 concept for the Tirgu Mures City will provide valuable feedback through test cases being linked with the user requirements (degree of fulfilment).

Technology Experts

Pilot Leads -­‐ WP5

Requirements Analysis – WP2 Internal Meetings

Implementation

Evaluation/Validation

WP3

Technical Requirements & Implementation Guidelines

WP4

Workshops

WP7 EPIC Platform & Roadmap

WP6

SotA Survey

WP8

Feedback

Figure 16: Relation between forthcoming WPs

With respect to the Agile paradigm, the collection of the user requirements started with a face-­‐to-­‐face meeting between all WP2 partners. The participants were divided into three focus groups: the city administrators, the application developers and the technical experts that will contribute to the development of the platform.

Each focus group had a brainstorming session, trying to identify key issues that need to be clarified. After this session, there was an extended discussion between all partners, trying to analyse every identified remark from different points of view.

This leaded to the recording of the initial list of issues that needed to be studied and discussed in the pilot workshops.

Figure 17: Initial Requirements Collection

© EPIC Consortium

57

Version 1.0, 05/07/2011

EPIC – D2.3 Having the first set of questions, the discussions continued internally between WP2 partners “fine-­‐graining” and extending the questions that should be discussed in the workshops. After numerous iterations, we came up with two separate questionnaires to be used as a basis for collection the user requirements, one containing the technical issues to be solved, and another to be answered by the end-­‐ users and the city administrators. Furthermore WP2 collaborated closely with WP6 lead – Deloitte in order to acquire additional input for the workshop discussions and ensure that the WP2 outcomes will be effectively exploited for the roadmap development.

Figure 18: Requirements Analysis Workarea

© EPIC Consortium

58

Version 1.0, 05/07/2011

EPIC – D2.3

Figure 19: Template proposal for the collection of requirements

Afterwards, three workshops took place in each pilot city. Pilot leads had to identify the key target groups of stakeholders to attend these meetings and propose the agenda based on the guidelines and the initial discussions in WP2. The application developers as well as the relevant technical partners to each scenario participated to the workshops in order to enrich the process of those meetings with their technical expertise and to identify key technical issues. The outcomes were a list of answers to each question, addressing the different needs of every specific scenario.

Those answers were circulated between all partners in numerous iterations, and produced the initial list of the technical requirements. Moreover, the partners’ technical expertise produced additional requirements related with their platform elements covering all aspects of the project.

5.2 General Requirements Technical requirements arise towards the underpinning platform as well as towards the data and service providing parties. In addition, we have to distinguish between functional and non-­‐functional requirements on both sides: 1. Functional Requirements –referring to specific set of capabilities and behaviour for a system or a component.

2. Non-­‐functional Requirements – referring to restrictions on the types of solutions that will meet the functional requirements.

© EPIC Consortium

59

Version 1.0, 05/07/2011

EPIC – D2.3 Collaboration, i.e. information and service sharing, in EPIC has both the human factors and the process management aspect to it, and requires the building of extensive and flexible knowledge bases.

In order to get to knowledge-­‐based centres of excellence, solutions need to be provided for: • • • • •

support of internal and external collaboration processes threat and operation control centres, integrated intelligence exploitation and enhanced decision making (policy maker, process managers, commanders) maintaining public safety and security federated identity management, incl. identification and verification capabilities integrated case management

Figure 20: Components of an integrated collaborative information environment

A service-­‐oriented architecture and infrastructure is the cornerstones that ensure the needed flexibility. In fact, without the dynamic discovery capability of SOA services, the collaboration environment would be based on the usual ‘all or nothing’ paradigm, where failure in the availability of one of the participants makes the entire process to stop. With SOA instead, the presence of alternate providers is made transparent to the process, as well as the customization of capabilities to the different user roles. In addition, the federated identity standards which are at the basis of distributed access and authorization are better carried out on SOA infrastructures.

© EPIC Consortium

60

Version 1.0, 05/07/2011

EPIC – D2.3 5.2.1 Functional Requirements The EPIC platform needs to become a self-­‐contained interoperability solution for pan-­‐European information and service sharing between stakeholders. Therefore, it needs to deliver the following capabilities: 5.2.1.1 Platform Requirements Table 6: Requirement FR1 ID

FR1

Name

Common role-­‐based portal server

Description

All pilots will get access to the services solely via the EPIC platform portal, which needs to contain a portal server to manage: • • • • • •

Severity High

Different user groups/roles, e.g. for the pilots The different stakeholders, users of the platform Presentation of portal pages on different mobile and non-­‐mobile devices Access control to services Single sign-­‐on to back-­‐office applications and processes Secure platform access from the internet via a DMZ (Demilitarized Zone)

Table 7: Requirement FR2 ID

FR2

Severity High

Name

Registration of a service

Description

The EPIC platform must provide services for any web service provider to register new services to be offered to city administrations, citizens/tourists and other service providers. This registration must include e.g. the web service description (WSDL); it can include also e.g. a service pricelist for different user groups.

Table 8: Requirement FR3 ID

FR3

Severity High

Name

Registration of a stakeholder – providing credentials and trust evidences

Description

Likewise, the platform must enable the on-­‐boarding of new stakeholders, in particular city and commercial service providers. This registration service should be implemented in a self-­‐service portal to allow new stakeholders to register and upload necessary credentials and trust evidences e.g. licences and certificates as a trusted public supplier.

© EPIC Consortium

61

Version 1.0, 05/07/2011

EPIC – D2.3 Table 9: Requirement FR4 ID

FR4

Severity Low

Name

Subscription to a web service

Description

In addition to the search of the repository, subscription to periodic services should be facilitated by the platform e.g. pushing an event list to a user on a monthly basis.

Table 10: Requirement FR5 ID

FR5

Severity Medium

Name

Federated single sign on using various e-­‐Identity means

Description

All users authenticate themselves at the EPIC portal with their EPIC user id. The services they access from the portal might need different access credentials e.g. a social security number to apply for and receive state pensions. The platform needs to manage those credentials in an inherent vault and use them purpose-­‐ driven to perform a transparent single sign on (SSO).

Table 11: Requirement FR6 ID

FR6

Severity Low

Name

Search for a web service

Description

Visitors of the EPIC portal need to be able to search for and locate available web services related to a certain topic e.g. finding sports events. The EPIC platform therefore has to offer a search portlet for a keyword-­‐based inquiry of the web-­‐ service repository (WSRR).

Table 12: Requirement FR7 ID

FR7

Name

Provide comfortable possibility to insert and edit contents of the EPIC web portal

Description

The platform has to provide web content management functionality for web masters via the portal interface.

© EPIC Consortium

Severity Medium

62

Version 1.0, 05/07/2011

EPIC – D2.3

Table 13: Requirement FR8 ID

FR8

Severity Medium

Name

Possibility to negotiate SLAs when needed

Description

In cases where the application is offered via a specific fee, the use of SLAs will ensure the pre-­‐agreed QoS and the data access to existing data resources.

Table 14: Requirement FR9 ID

FR9

Severity High

Name

DBMS capable for manipulating significant amount of data

Description

Many pilot applications manipulate data relating to rich medias. Considering the fact that the end-­‐users should be able to store rich medias, the DBMS must be able to manipulate a significant amount of data (up to a number of Petabytes).

Table 15: Requirement FR10 ID

FR10

Severity High

Name

Time zone and multicurrency support

Description

The EPIC platform must be capable of supporting multicurrency and different time zones.

5.2.1.2 Front-end Requirements Table 16: Requirement FR11 ID

FR11

Name

Role-­‐based user interface

Description

The Front-­‐end must provide a different set of functionalities depending on the user that is currently logged on.

© EPIC Consortium

Severity High

63

Version 1.0, 05/07/2011

EPIC – D2.3

Table 17: Requirement FR12 ID

FR12

Severity High

Name

Administration interface

Description

The administration interface will provide the elements needed to allow user management, role handling and access control – administrators being one defined user role in the central user directory.

Table 18: Requirement FR13

ID

FR13

Severity High

Name

Registration Page

Description

The users of the EPIC Portal will have to register themselves using a registration form which will allow the provision of credentials and trust evidences if needed.

Table 19: Requirement FR14

ID

FR14

Severity High

Name

Service registration screen

Description

This screen will ask the users to provide all the information that is required in order to register a service to the EPIC platform.

Table 20: Requirement FR15

ID

FR15

Severity Medium

Name

Personal Space

Description

The logged users will have to be presented with a personal page where they will be presented with the services which they have bought/registered/subscribed and also with the details of their EPIC account.

Table 21: Requirement FR16 ID

FR16

© EPIC Consortium

Severity Low

64

Version 1.0, 05/07/2011

EPIC – D2.3 Name

Advanced search for services

Description

A search form allowing the users to search for services using multiple criteria (category, location, etc.).

Table 22: Requirement FR17 ID

FR17

Severity Low

Name

Notification List

Description

A list with the updates on services that the users have been subscribed to.

Table 23: Requirement FR18 ID

FR18

Severity Low

Name

Promoted/Latest services area

Description

The EPIC Portal could provide an area where the latest available services can be viewed by the users. The same or a similar area could be also used for promoted (if exist) services.

5.2.1.3 IOT Requirements Table 24: Requirement FR19 ID

FR19

Severity High

Name

Easy integration into cloud services

Description

IoT elements (services, components, devices) should be effectively integrated into cloud services and make use of their capabilities for scalability, high availability etc.

Table 25: Requirement FR20 ID

FR20

Name

Interoperability

Description

Data feeds coming from a from a variety of domestic and industrial monitoring equipment will be published within the EPIC platform, consumed by other

© EPIC Consortium

Severity High

65

Version 1.0, 05/07/2011

EPIC – D2.3 services and interoperable through a semantic layer within EPIC.

5.2.1.4 Requirements for Semantics Table 26: Requirement FR21 ID

FR21

Severity Medium

Name

Multilanguage support

Description The EPIC platform should support Multilanguage capabilities, exploiting the semantics technology.

Table 27: Requirement FR22 ID

FR22

Severity Medium

Name

Semantic annotation for web services

Description Semantic annotation of web services enables other systems to interpret what

meaning a particular web service and the provided information/functionality has.

This feature belongs to the development of the semantic web in which it’s aimed at achieving an “understanding” among it-­‐systems and web services.

The portal server should provide the possibility to employ Semantic Annotations for WSDL and XML Schema (SAWSDL), Web Service Modelling Language (WSML)and Resource Description Framework schema (RDF schema) of W3C which together provides a mechanism to supply XML schemas with semantic models.

Semantic annotations and models have to be created at a later point for the web services.

5.2.1.5 Other Requirements Table 28: Requirement FR23 ID

FR23

Severity Low

Name

Feedback

Description

The EPIC platform should allow the end-­‐users to provide feedback regarding the application experience, and report any bugs, malfunctions or suggestions that could be used for the improvement of the application.

© EPIC Consortium

66

Version 1.0, 05/07/2011

EPIC – D2.3 Table 29: Requirement FR24 ID

FR24

Severity Low

Name

Statistics & Analytics

Description

The EPIC platform should monitor the usage of the applications in order to provide statistical data. Moreover, the platform should allow the city administrators to extract intelligent information based on the end-­‐users measures (i.e. Aiming to identify abnormal usage of the city resources, like abnormal energy peaks etc.).

5.2.2 Non Functional Requirements Table 30: Requirement NF1 ID

NF1

Severity High

Name

Usability

Description

The EPIC platform should ensure its usability, especially for the processes where the actor is the end-­‐user such as the front-­‐ends.

Table 31: Requirement NF2 ID

NF2

Severity Medium

Name

Privacy Protection

Description

The digital information society demands bridging between critical technical, business and legal issues in identity management. To enable safe and secure interaction while allowing users to keep control of their private spheres, the access control paradigm needs to change from a “one fits all” to a more granular approach: “what properties are really needed for accessing a specific resource?”

This way the data release for authentication towards communication partners can be minimized.

Table 32: Requirement NF3 ID

NF3

Name

Security – rule-­‐based authentication and authorization

Description

A minimal-­‐disclosure credential system should enable strong authentication and privacy at the same time. It is to allow users to selectively reveal attributes contained in the credential without revealing any of their information

© EPIC Consortium

Severity Low

67

Version 1.0, 05/07/2011

EPIC – D2.3 whatsoever. It addresses all requirements of a privacy protecting public key infrastructure (PKI). It protects privacy via an efficient, minimal-­‐ disclosure credential system which builds on the principle of purpose-­‐oriented and policy-­‐driven federation of credentials (using an open privacy policy language called PPL).

Table 33: Requirement NF4 ID

NF4

Severity Medium

Name

Support for mobile devices

Description

Support for mobile devices should be two-­‐folded. On one hand portal page presentation should be optimized regarding the device specification e.g. resolution or incremental page build-­‐up. On the other, application specific client code could be downloaded and governed by the platform (portal server).

Table 34: Requirement NF5 ID

NF5

Severity Medium

Name

No need for training

Description

The EPIC platform’s front end should be easy to use. The end-­‐user shouldn’t need a special training in order to use the platform and access the accommodated services.

Table 35: Requirement NF6 ID

NF6

Severity Medium

Name

Attractive design of EPIC web portal and pilot applications

Description

The EPIC web portal will be the entry point to the pilot applications. EPIC specific graphical elements and HTML templates should be well designed in order to ensure an attractive appearance as well as recognition value. Based on each pilots application workflow (yet to be created) a navigation concept through the web application should be developed.

Table 36: Requirement NF7 ID

NF7

Name

High availability

© EPIC Consortium

Severity Medium

68

Version 1.0, 05/07/2011

EPIC – D2.3 Description

Some application scenarios require that the users provide row data to the EPIC platform in a per minute basis, and as a matter of fact, the EPIC platform must be able to receive them continuously.

5.3 Pilot Application Requirements Existing applications can be consumed from the platform unchanged if and only if they are “wrapped” as a web service – via the usage of the web services. Each application/service will be invoked via the common EPIC portal server via portlets; according to the role and personal customization each user can be authorized for a different set of services all managed in the web service repository.

5.3.1 Relocation Service The relocation service consists of a non-­‐mobile a mobile part. For these parts different requirements are claimed because those parts run in completely different environments: A portal server with cloud computation power and smart phone operating system with less computation power and less memory. Also, the non-­‐ mobile application can make use of much more already available software and libraries than the mobile application.

This life-­‐event scenario is based on a semantic layer allowing the end-­‐user to: • • • • • •

Create a relocation profile Create a search query Execute that query Save the query and the result Request government-­‐related information View query and result both on pc and on a mobile device Table 37: Requirement RRS1

ID

RRS1

Severity Low

Name

Multi-­‐Cultural Description of the Real Estate Properties

Description

Citizens from different countries refer differently to properties. E.g. some citizens talk about size in terms of square feet or square metres and number of bathrooms, while other citizens might specify in terms of number of bedrooms and number of reception rooms. The semantic engine with the help of EPIC platform should map user needs onto the different descriptions provided by realtors and letting agents.

Table 38: Requirement RRS2 ID

RRS2

© EPIC Consortium

Severity High

69

Version 1.0, 05/07/2011

EPIC – D2.3 Name

GIS/Map for showing points of interest, real estate properties, etc.

Description

For the user acceptance the visual appearance of the map plays an important role.

Our solution has to compete against those which are commonly known nowadays.

State of the art products could be also used taking into consideration any license restrictions.

5.3.1.1 Mobile Table 39: Requirement RRS3 ID

RRS3

Severity Medium/Low

Name

Reach as many smart phone platforms as possible and minimize software development effort

Description

Minimizing the effort of software development for the mobile part of the relocation part can be achieved by OS abstracting layers like PhoneGap. Hardware and operation system abstracting frameworks may decrease the performance of the application. Of course, at the same time they minimize programming effort by reaching several smartphones at once.

Ideally, applications would be browser-­‐based and would run on any mobile device. However, as this would limit the functionality of the applications, EPIC will aim to find a balance between native and browser-­‐based applications.

Table 40: Requirement RRS4

ID

RRS4

Severity High

Name

Realise augmented reality functionality (only mobile part)

Description

Software: First, it is intended to employ already available frameworks or software libraries that provide augmented reality functionality like Layar or Wikitude.

Hardware: Smartphones nowadays provide necessary hardware sensors to localise them self by GPS, compass and acceleration sensors.

Table 41: Requirement RRS5

ID

RRS5

Severity High

Name

Ensure good performance of video flow in augmented reality view

Description

RRS2 requires reaching many smart phones as possible by employing hardware abstracting frameworks.

In general, when building mobile applications with the OS abstraction framework approach the application is not native. That means access to hardware devices of

© EPIC Consortium

70

Version 1.0, 05/07/2011

EPIC – D2.3 the phone (camera, compass, etc.) is wrapped by the framework. This can cause to slow down the flow of data between the application and the devices. While this should not be a problem for many non-­‐real-­‐time applications, a real-­‐time application that heavily makes use of camera this aspect has to be considered when making the decision for the software architecture of the application.

Table 42: Requirement RRS6 ID

RRS6

Severity High

Name

Enable for communication between the mobile application and the portal server

Description

The mobile application has to able to access the EPIC portal server, where the end-­‐user has stored POIs, real estate properties etc. previously. Because smartphones are usually integrated into the internet via IP networks, the usage of web services for communication should not be a problem.

5.3.2 Urban Planning Service Navidis has developed a digital solution for managing, sharing and communicating the urban planning and development projects of the city. This digital consultation and participation solution provides innovative content and a considerable rich media data base, adapted to the needs and expectations of the City – a web based solution for professionals and citizens to meet and exchange information. Through the application, politicians, professionals and citizens can access, explore, better understand and work together on representation and information of different sites and major development projects of the city.

The application is a real time 3D Model of the city (ISSY 3D) to provide an innovative augmented reality experience for professionals (urban planners, architects, etc.) and citizens (residents associations, community groups and individuals) who can access the Internet to virtually fly over and move around a digital 3D model of the city and access major sites like in a video game. This application helps users to understand the vision for the city and experience potential developments by accessing and experiencing relevant information like sounds, statistics, geometrics, dynamic flows and media etc. The services will be extended and adapted by Navidis for use within the EPIC platform. An advertising sales system will be put in place to enhance the level of communication available at a global level. Another extension will be developed based on NAVIDIS Urbadeus concept for making citizens able to publish specific content through the platform by Internet or with a Smartphone.

The Issy-­‐Les-­‐Moulineaux application allows the user to: • •

Choose the topic of interest Select the points of interest

© EPIC Consortium

71

Version 1.0, 05/07/2011

EPIC – D2.3 • •

Query the points of interest Report incidents in the city

Additionally, local government agents are also able to report problems/dysfunctions in the city, while the local SMEs are able to inquire information regarding the local companies registered in Issy-­‐Les-­‐Moulineaux.

Table 43: Requirement RUP1 ID

RUP1

Severity High

Name

GIS

Description

Availability of GIS (like ESRI or openGIS) and 3D Data should be available in/through the Cloud for being able to provide visualization of the territory in 3D with Navidis design and features.

Table 44: Requirement RUP2 ID

RUP2

Severity High

Name

Performance of architecture

Description

In addition to 3D representation users will manipulate in real time, lot of rich media like photos, videos and sounds will be treated by the applications. That means availability and bandwidth of the system will be highly stressed. The architecture must be optimized to find the right balance between the execution on the client device and the server.

Table 45: Requirement RUP3 ID

RUP3

Severity High

Name

Middleware Interfaces

Description

Applications/Services developed by partners should be able to access Navidis API and Navidis Data Base for selection of POI, geo-­‐referenced information, style and templates for representation, etc.

Table 46: Requirement RUP4 ID

RUP4

Name

Middleware Administration

© EPIC Consortium

Severity High

72

Version 1.0, 05/07/2011

EPIC – D2.3 Description

Clients and Partners should be in a position to administrate easily their own data, contents and customers. They should be able to manage also customer’s access rights function of level of profile and details required.

Table 47: Requirement RUP5 ID

RUP5

Severity High

Name

IM/NAV Marketplace

Description

Different business models could be put in place, especially those coming from local partners. Advertising, Couponing, Purchase discounts, etc... Specific API will be available for making it possible.

5.3.3 Smart Environment Service The smart environment service (SES) focuses on monitoring of energy consumption in privately owned and social housing, public buildings and commercial premises. A personal energy monitoring portal, EnergyHive, developed by Hildebrand will be used to demonstrate how an end-­‐to-­‐end commercial service that could be developed around energy monitoring web services.

The applications for energy monitoring will be broadened by a BCU-­‐designed generic monitoring and control framework. This will enable the EPIC platform to consume a diverse range of data feeds and accommodate existing and emerging hardware/software and data streams that will complement the Hildebrand domestic energy monitoring application.

The SES application, through the broader BCU framework, will also provide access to energy data from public buildings and commercial premises, maximising the use of data that can be obtained by accessing energy data feeds from building management and HVAC systems. This will demonstrate the potential applications for energy monitoring in the wider smart-­‐city context, to complement the consumer focussed domestic energy monitoring application. SES web-­‐services exposed within the generic framework will also allow energy usage data from domestic homes and public buildings to augment the Relocation and City Planning applications, encompassed under the BCU generic monitoring and control framework.

Table 48: Requirement RSE1 ID

RSE1

Name

Domestic Energy Monitoring (Hildebrand / Manchester)

Description

Tasks to be performed by Hildebrand / MCC and BCU. The Hildebrand solution fairly well developed but will need wrapping as a portlet for delivery through the

© EPIC Consortium

Severity Medium

73

Version 1.0, 05/07/2011

EPIC – D2.3 EPIC portal server.

In the domestic element of the Smart Environment Service, the end-­‐user can: • Create a personal user account • Install and register their household energy monitoring system • Examine the overall household usage • Compare their usage to the local “average” and to similar properties / communities in other regions / countries.

• Elect to feed anonymised data on their energy usage to the “energy data pool” for others to use for comparison purposes • Record user notes

Table 49: Requirement RSE2 ID

RSE2

Severity Medium

Name

Generic Energy Monitoring Framework (BCU)

Description

The BCU generic framework is a new development designed to widen the scope of energy monitoring to include other energy portals for domestic users and to consume data feeds from public buildings, commercial premises, etc.

In the generic framework of the Smart Environment Service, users can: • View energy consumption from households which are not part of the Hildebrand solution, but who are already feeding energy data to Google PowerMeter or contributing public data feeds to Pachube • View energy consumption of individual public buildings and commercial premises which have elected to provide energy usage information to the Smart-­‐ City energy portal • Compare the usage to the local “average” and to similar public building and commercial properties in other cities / regions / countries.

•

1.

2.

3.

4.

5.

6.

© EPIC Consortium

View the energy consumption of selected social housing and other properties that have been retro-­‐fitted with energy reduction measures by, or with incentives from, the City Administration To accept data-­‐streams submitted to existing web-­‐based energy monitoring portals, including Hildebrand EnergyHive, GooglePower and Pachube.

To accept “raw” energy usage feeds from selected commercially available domestic energy and other monitoring systems, where these are not currently supported by existing web applications.

To accommodate existing and developing standards for sensors and actuators commonly used in home automation, Telecare and similar applications, including X10 wired and wireless for home automation.

To accommodate existing and developing standards for industrial networked sensors and smart-­‐sensors, including the IEEE 1451 “Plug and Play Smart Sensors” family of standards, active RFID tags (ISO-­‐18000-­‐7), etc.

To define meta-­‐data descriptions to supplement raw energy data streams from domestic premises, to provide context but with due reference to privacy concerns.

To define a data “wrapper” for generic sensing devices that provide

74

Version 1.0, 05/07/2011

EPIC – D2.3 contextual data for energy consumption in buildings, including temperature, humidity, light levels, occupancy, etc.

7. To support data feeds from Building Management and HVAC Systems used in public and commercial buildings, supporting the most commonly used data protocols and data formats.

8. To support registration of individual end-­‐point sensors and / or end-­‐point systems using an Internet of Things methodology, allowing meta-­‐data mark-­‐ up of data and context, probably based on a variant or extension of the Transducer Electronic Data Sheets (TEDS) used by IEEE 1451.

9. To implement a generic approach to all variable rate sampling for different sensor types and to allow different encoding mechanisms for time-­‐series data, to ensure economy of short / medium / long term data storage whilst retaining maximum information.

10. To implement a range of web-­‐services that provide unified access to the pool of sensor data and contextual data created by the aggregation of heterogeneous data feeds 11. To implement a generic approach to anomaly and alarm condition detection, plus appropriate escalation and annunciation mechanisms.

Table 50: Requirement RSE3 ID

RSE3

Severity High

Name

User Login

Description

Individual users must be authenticated when connecting to the system, based on username and password in order to be granted access to the functionality. Users must be identified and associated with a household and given access to areas of functionality in order to configure the system to their preferences – accessibility issues to be considered.

Table 51: Requirement RSE4 ID

RSE4

Severity High

Name

Examine overall household energy usage

Description

System must record overall energy consumption of a household at a regular intervals which provide ‘real-­‐time’ data – minimum of 10 second intervals. This energy usage should be displayed on-­‐screen in a manner which allows the end-­‐ user to review their data at resolutions of 1 hour, 1 day, 1 week, 1 month, 1 quarter.

Table 52: Requirement RSE5 ID

RSE5

© EPIC Consortium

Severity High

75

Version 1.0, 05/07/2011

EPIC – D2.3 Name

Compare energy usage to local average

Description

The system must be able to compare the overall time series data for an individual household against an average across households meeting specific criteria. The comparisons and criteria, must take into account geographical location, building type (size, insulation type and energy rating), number of occupants and seasonal temperatures.

Table 53: Requirement RSE6

ID

RSE6

Severity High

Name

Installing a household system

Description

The system must accommodate a ‘plug-­‐and-­‐play’ approach from the end-­‐user, therefore must be compatible with a range of IoT sensors and equipment allowing for effective integration and communication with the platform. User set-­‐up and online guidance must be provided by EPIC and the generic framework, allowing for testing as part of system set-­‐up, including registering a unique identifier for the household and the ability to carry out diagnostic checks for any anticipated set-­‐up errors or requesting technical support for successful set-­‐up.

Table 54: Requirement RSE7 ID

RSE7

Severity High

Name

Recording user notes

Description

Users should be able to record and share comments and notes on the experiences, which are time-­‐stamped, linked to a particular user and household and particular point in the energy usage history. User notes should allow project researchers should be able to filter, analyse and annotate individual comments, linking directly to household and energy history – even after being exported for use by research and technical staff.

Table 55: Requirement RSE8 ID

RSE8

Severity High

Name

Raise issue ticket

Description

Users must be able to request technical support, estimated annual energy savings and changes to their account e.g. change of password, change of energy tariffs, appliance rating and user profile details.

Technical staff should be able to raise issue tickets on system bugs and issues.

© EPIC Consortium

76

Version 1.0, 05/07/2011

EPIC – D2.3

Table 56: Requirement RSE9 ID

RSE9

Severity High

Name

Update household configuration

Description

The system must allow users to set thresholds on average household usage per week, per calendar month and with appropriate metrics (kWH or alternative energy measures [33]), be able to view individual appliance performance against household average, compare energy usage patterns against local average.

When the user’s defined thresholds are exceeded the system must issue an alert via the users preferred channel of communication that is supported by the EPIC platform.

Table 57: Requirement RSE10

ID

RSE10

Severity High

Name

User defined Alerts

Description

The system must allow users to activate and deactivate alerts, whilst also being able to monitor communications between the system and IoTs sensors within the home – alerting project technicians and end-­‐user with appropriate recommendations to correct failure.

5.4 Development Environment Development in the EPIC project is performed at two levels. First, each individual pilot performs “local” application development in various extents. In a second step, the results need to be deployed on the EPIC platform. This section summarizes the requirements for the EPIC Deployment Environment.

Table 58: Requirement DE1 ID

DE1

Severity Low

Name

Application Development

Description

This task is performed individually by all project partners – ideally using an IDE environment as a common solution development platform integrating individual development tools.

© EPIC Consortium

77

Version 1.0, 05/07/2011

EPIC – D2.3 Table 59: Requirement DE2 ID

DE2

Severity High

Name

Portal Configuration

Description

For each use case within all scenarios in the pilots, the acting players (users) have to be identified and defined, including their roles, authorisations and capabilities.

These definitions have to be entered into the EPIC identity management directory.

In addition, portal page layout has to be done and portlets oriented towards the application services and processes have to be written.

Table 60: Requirement DE3 ID

DE3

Severity High

Name

Web Service Publication

Description

Once the application services have been developed by the respective stakeholders, they need to be described and published as web services in the EPIC service repository. A portal interface has to be provided for this task.

Table 61: Requirement DE4 ID

DE4

Severity Low

Name

Application Adapters

Description

In addition to the provisioning of web services, it might become necessary to directly connect to applications (e.g. SAP) or information (e.g. databases) from the portal or from applications. In that case, the adapters inherent in the platform’s enterprise service bus (ESB) need to be configured.

6 Conclusions This report presents the results of the work carried out in the scope of T2.3 (“Desk Based Research") and T2.4 (”Technical Requirements Creation") of EPIC project.

Initially, in this report we provided a short description regarding our vision about the 'Smart Cities', while trying to analyse also the existing trends in the European Union. As a result, we briefly presented the EPIC platform explaining how the platform will solve all issues identified by this process and how the EPIC platform will take the European cities a step forward in order to provide smarter services to their citizens.

© EPIC Consortium

78

Version 1.0, 05/07/2011

EPIC – D2.3 Finally, we consolidated all user requirements that the EPIC platform should cover.

Each one of them has a unique identification number, its severity measure, followed by a small description. They are categorized in three types: general, application specific and those related to the development environment. The user requirements that are reported in this section were defined from one part by the D2.2 of the project and from the other part by the technical partners' experience. It should be noted that the requirements analysis is an iterative process and in that sense the requirements will be also updated and extended exploiting that feedback from the technical WPs as the project progresses. For this reason, the whole document will be updated to meet the needs of the D2.4.

It is expected that this report will provide useful input for the whole project, as it will be used as the basis for the design and implementation of the EPIC platform and will be taken into consideration for the evaluation and validation processes.

7 References [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11]

[12] [13]

A Vision of Smarter Cities”, p. 13,: http://www-­‐ 03.ibm.com/press/attachments/IBV_Smarter_Cities_-­‐_Final.pdf Android: http://www.android.com Apache Hadoop: http://hadoop.apache.org Blackberry: http://us.blackberry.com/developers Business Analytics and Optimization solutions: http://www-­‐ 01.ibm.com/software/data/new-­‐intelligence City Forward Introduction: http://www.youtube.com/watch?v=DeZ6Sgu2Pu8, last access: January 2011 Developer Tools for Windows Phone 7 platform, 2011, April 13: http://www.microsoft.com/presspass/features/2011/apr11/04-­‐ 13MIXphone.mspx (accessed 11 May 2011) Donovang-­‐Kuhlisch, M. and Schade, U.: Smart e-­‐Government Services by the Recognition of Common Intent, ICSOC Proceedings, 2010 e-­‐Government Smart City: http://www.edinburgh.gov.uk/info/691/council_performance/967/e-­‐ government_smart_city/1 EPIC D2.1 document, Project Vision European Interoperability Framework 1.0, Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens programme (IDABC), European Communities, Luxembourg, 2004 http://ec.europa.eu/idabc/servlets/Docd552.pdf?id=19529 Future features for Windows Phone 7 Platform: http://www.zdnet.com/blog/cell-­‐phones/mwc-­‐2010-­‐microsoft-­‐announces-­‐ windows-­‐phone-­‐7-­‐series-­‐with-­‐xbox-­‐and-­‐zune-­‐integration/3091 Gartner Cloud Hipe Cycle, 2010;: http://www.gartner.com/it/page.jsp?id=1447613

© EPIC Consortium

79

Version 1.0, 05/07/2011

EPIC – D2.3 [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35]

Gartner Smartphone share for Q3 2010, 2010, November 10: http://www.guardian.co.uk/technology/blog/2010/nov/10/smartphone-­‐ market-­‐growth-­‐gartner-­‐q3-­‐2010 (accessed 03 May 2011) Geolocation API Specification: http://dev.w3.org/geo/api/spec-­‐source.html Helping CIOs Understand "Smart City" Initiatives: http://www.forrester.com/rb/Research/helping_cios_understand_smart_cit y_initiatives/q/id/55590/t/2?src=56670.pdf HTML5 from a Mobile Perspective: http://www.cloudfour.com/html5-­‐from-­‐ a-­‐mobile-­‐perspective HTML5: http://www.w3.org/TR/html5 IBM's vision of Smarter Cities: http://www.ibm.com/smarterplanet/uk/en/sustainable_cities/ideas/index. html IEEE 1451 family of smart transducer interface standards: http://grouper.ieee.org/groups/1451/0/body%20frame_files/Family-­‐of-­‐ 1451_handout.htm iOS: http://www.apple.com/ios Manifesto for Agile Software Development: http://agilemanifesto.org MIT and the Building/Construction Industries,: http://www.mit.edu/images/briefs/industry_brief_build_cnsrt.pdf Nokia strategy for 2011: http://conversations.nokia.com/nokia-­‐strategy-­‐ 2011 OASIS Web Services Resource Framework (WSRF): http://www.oasis-­‐ open.org/committees/tc_home.php?wg_abbrev=wsrf OASIS, “Web Services Resource 1.2”: http://docs.oasis-­‐open.org/wsrf/wsrf-­‐ ws_resource-­‐1.2-­‐spec-­‐os.pdf OASIS, “Web Services Resource Lifetime 1.2 (WS-­‐ResourceLifetime)”: http://docs.oasis-­‐open.org/wsrf/wsrf-­‐ws_resource_lifetime-­‐1.2-­‐spec-­‐os.pdf OASIS, “Web Services Resource Properties 1.2 (WS-­‐ResourceProperties)”: http://docs.oasis-­‐open.org/wsrf/wsrf-­‐ws_resource_properties-­‐1.2-­‐spec-­‐ os.pdf Open Government Data: http://opengovernmentdata.org/, last access: January 2011 Phonegap: http://phonegap.com Representational State Transfer -­‐ REST definition: http://en.wikipedia.org/wiki/Representational_State_Transfer Resource Description Framework (RDF): -­‐ http://www.w3.org/RDF/, last access: January 2011 Seven ways to measure energy consumption: http://smart-­‐home-­‐ blog.com/archives/784 Smarter Computing: http://www-­‐ 03.ibm.com/systems/data/flash/smartercomputing/index.html Smith, Jeff S., Mobile Business -­‐ A New Era in Computing, The ISV Conference for Mobile Business, San Jose, California, November 16-­‐17, 2010

© EPIC Consortium

80

Version 1.0, 05/07/2011

EPIC – D2.3 [36] [37] [38] [39] [40] [41] [42] [43] [44] [45]

SOAP definition: http://www.w3.org/TR/soap Symbian: http://www.forum.nokia.com/Devices/Symbian (accessed 04 May 2011).

The announcement of Nokia and Microsoft agreement, 2011, February 11: http://www.wired.com/gadgetlab/2011/02/microsoft-­‐and-­‐nokia-­‐team-­‐up-­‐ to-­‐build-­‐windows-­‐phones (accessed 04 May 2011) Titanium Mobile Application Development: http://www.appcelerator.com/products/titanium-­‐mobile-­‐application-­‐ development W3C SWEO Linking Open Data Community Project: http://esw.w3.org/SweoIG/TaskForces/CommunityProjects/LinkingOpenD ata, last access: January 2011 W3C, “Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language”: http://www.w3.org/TR/2003/WD-­‐wsdl20-­‐20031110 Wikipedia contributors. "Web service." Wikipedia, The Free Encyclopedia.

Wikipedia, The Free Encyclopedia, 7 Jun. 2011. Web. 8 Jun. 2011.

Windows Phone: http://www.microsoft.com/windowsphone XML definition: http://www.w3.org/XML Gruber, Thomas . "A translation approach to portable ontology specifications". Knowledge Acquisition 5 (2): 199–220. 1993.

© EPIC Consortium

81

Version 1.0, 05/07/2011