DELIVERABLE  

 
Project Acronym: Grant Agreement number: Project Title: EPIC 270895 European Platform for Intelligent Cities

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

Authors: Andreas Menychtas (NTUA) PavlosKranas (NTUA) MargareteDonovang-Kuhlisch (IBM) MaritaHeindrichs-Krusch (IBM) Ravi W. Coote (FKIE) Ulrich Schade (FKIE) Keith A. Osman (BCU) Internal Reviewers: Joshua Cooper (HIL) Philippe Perennez (NAV) Tanguy Coenen (IBBT) Margarete Donovang-Kuhlisch (IBM) Leonidas Kallipolitis (ATC) Shenja Van Der Graaf (IBBT) Werner Brebels (IBBT) Tanguy Coenen (IBBT) Pukul Rana (MCC) Philippe Perennez (NAV)

Project co-funded by the European Commission within the ICT Policy Support Programme Dissemination Level P C Public Confidential, only for members of the consortium and the Commission Services X

EPIC – D2.3

  Revision  History  
Revision  Date   0.1   0.2   Author   Organisation   Description   Initial  Structure   ‘Executive  Summary’  and   ‘Web  Services’  sections   added   Changes  on  structure,   input  on  section  ‘EPIC   Key  Technologies’   Additions   Input  on  section   ‘Semantics’   ‘Internet  of  Things’   section  populated  with   IoT   ‘Front-­‐Ends  –  Mobile   Devices  Platforms’   section  added  by  ATC   Relocation  app   technology  description     31/03/2011   Pavlos  Kranas   NTUA   1/4/2011   Pavlos  Kranas   NTUA  

0.3  

11/4/2011   Andreas   Menychtas   12/4/2011   MDK   14/4/2011   RCO   18/4/2011   KAO  

NTUA  

0.4   0.5   0.6  

IBM   FKIE   BCU  

0.7  

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

ATC  

0.8  

IBBT  

0.9   0.10  

29/04/2011   Pavlos  Kranas   NTUA   30/4/2011   Philippe   Perennez   4/5/2011   Andreas   Menychtas   NAV  

‘Introduction’  section   added  by  NTUA   ‘Augmented  Reality’   section  added.  Additions   on  User  Requirements   Structure  changed.  A   template  for  the  user   requirements  has  been   provided  
Version 1.0, 05/07/2011  

0.11  

NTUA  

© EPIC Consortium

2  

EPIC – D2.3 0.12   0.13   5/5/2011   5/5/2011   MDK   RCO     IBM   FKIE   IBM’s  provided  user   requirements   Input  on  ‘Geographic   Information  Systems’  and   ‘Requirements   Specification’  sections.   Remarks  on  ‘Front-­‐Ends’   and  ‘Augmented  Reality’   Input  on  user   requirements   Input  on  section   ‘Conclusions’   Additional  input  on  user   requirements   0.16   0.17   16/5/2011   MDK   18/5/2011   Tanguy   Coenen   20/5/2011   Andreas   Menychtas   23/5/2011   Philippe   Perennez   23/5/2011   Andreas   Menychtas   24/05/2011   PukulRana   IBM   IBBT   Revision  of  Augmented   Reality  section   Comments  on  using  web-­‐ apps  instead  of  native   apps   Minor  changes  on  content   and  format   Input  on  IM/NAV  pilot   requirements     Minor  changes  on  content   and  format   Input  on  Smart  Cities   requirements   Input  on  IOT   Requirements   1st  reviewer  comments   Updates  based  on  review  

0.14   0.15  

12/5/2011   LKA  

ATC  

12/5/2011   Pavlos  Kranas   NTUA  

0.18   0.19   0.20   0.21   0.22  

NTUA   NAV   NTUA   MCC  

01/06/2011   Pavlos  Kranas,   NTUA   Andreas   Menychtas   03/06/2011   MDK   IBM  

0.23   0.24  

08/06/2011   Pavlos  Kranas   NTUA  

© EPIC Consortium

3  

Version 1.0, 05/07/2011  

EPIC – D2.3 comments   0.25   0.26   0.27   09/06/2011   Tanguy   IBBT   2nd  reviewer  comments   Updates  based  on  review   comments   Additional  market  insight   for  the  era  of  smarter   planet   3rd  reviewer  comments   and  minor  updates  on   format   4th  reviewer  comments   and  relevant  changes   Review  and  minor   changes  and  corrections     Review  and  minor   changes  and  corrections   Minor  changes  based  on   MC’s  comments   Final  Version  

15/06/2011   Pavlos  Kranas   NTUA   18/06/2011   MDK   IBM  

0.28  

20/06/2011   Philippe   Perennez,   Andreas   Menychtas  

NAV,  NTUA  

0.29  

24/06/2011   Joshua  Cooper   HIL,  NTUA   Andreas   Menychtas   28/06/2011   Ulrich  Schade,   Fraunhofer   Ravi  Coote   FKIE   03/07/2011   Tanguy   Coenen   IBBT  

0.30   0.31   0.32   1.0      

04/07/2011   Pavlos  Kranas   NTUA   05/07/2011   Andreas   Menychtas   NTUA  

 

© 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 Client Service  Response C  
Figure  4:  WS-­‐Resource  paradigm  

Web   Service

 

B

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  
22   Version 1.0, 05/07/2011  

© EPIC Consortium

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.   Implement   a   cloud   environment   for   the   European   Smart   Connected   City   Network:  
23   Version 1.0, 05/07/2011  

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

© EPIC Consortium

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
“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.”

• Big Data • At an inflection point
“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.”

• Smart Computing • $272B by 2015
“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.”

• Operational Technology • In asset-intensive industries
“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.”

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  
25   Version 1.0, 05/07/2011  

© EPIC Consortium

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  
26   Version 1.0, 05/07/2011  

• •

© EPIC Consortium

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   ISO/IEC  18000-­‐1:2004   ISO/IEC  18000-­‐2:2004   ISO/IEC  18000-­‐3:2010   ISO/IEC  18000-­‐4:2004   ISO/IEC  18000-­‐6:2010   Title   Radio  frequency  identification  for  item  management.  Reference   architecture  and  definition  of  parameters  to  be  standardized   Radio  frequency  identification  for  item  management.  Parameters  for  air   interface  communications  below  135  KHz   Radio  frequency  identification  for  item  management.  Parameters  for  air   interface  communications  at  13,56  MHz   Radio-­‐frequency  identification  for  item  management.  Parameters  for  air   interface  communications  at  2,45  GHz   Information  technology.  Radio  frequency  identification  for  item   management.  Parameters  for  air  interface  communications  at  860  MHz   to  960  MHz   Information  technology.  Radio  frequency  identification  for  item   management.  Parameters  for  active  air  interface  communications  at  433   MHz  

SO/IEC  18000-­‐7:2008  

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 Health Care
IMPROVE IMPROVE OPERATIONAL OPERATIONAL EFFICIENCIES AND EFFICIENCIES AND REDUCE COSTS REDUCE COSTS

Telecom

Retail

Government

Others

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

DIFFERENTIATE THE DIFFERENTIATE THE CUSTOMER CUSTOMER EXPERIENCE EXPERIENCE

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

Business Results
Mobile Commerce Asset Management Business Analytics Customer Interaction Collaboration & Social Networking Services and Business Model Innovations Service Assurance Information Management Location Awareness Dynamic Process Integration BSS/OSS Transformation Configuration Management

Device & App Management Management Management

MOBILE APPLICATION CAPABILITIES

Device Hardware
SERVICE CREATION & TRANSFORMATION SERVICE EXECUTION
NETWORK SERVICES

MOBILITY DATA

MOBILITY ANALYTICS

SERVICE MANAGEMENT

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   GETESTATE   GETRESULTS   GETINFOS   GETQUERY   DELQUERY   GETPROJECT   Description   information  about  one  property  (ad)   list  of  properties  (ads)    (search  result)   list  of  Belgium’s  areas  and  countries   get  criteria’s  and  counters  from  saved  queries   delete  a  saved  query   get  all  the  individuals  estates  belong  to  a  project  estate  

© EPIC Consortium

50  

Version 1.0, 05/07/2011  

EPIC – D2.3
GETZIP   CHECKZIP   GETSAVEADS   DELSAVEDADS   SAVEADS   LOGIN   NEWUSER   NEWPSWD   SENDOWNER   SENDFRIENDS   SAVEDQUERY   provide  the  zip  code  for  given  values  of  latitude  and  longitude   control  the  value  of  zip  code   provide  the  list  of  all  the  saved  ads  for  a  given  customer   remove  an  estate  from  the  list  of  saved  ads   add  an  estate  in  the  list  of  saved  ads   to  log  into  MyImmoweb   creation  of  a  new  customer  in  MyImmoweb   to  modify  an  existing  password   send  information  to  a  seller   send  information  to  a  friend  about  an  estate   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   GetExtension   GetXYCoord   GetStreet   GetStreetName   GetAddressFromCoord   GetStreetFromID   GetZITType   GetZI   GetZIFromCoord   Description   Gets  the  spatial  extent  of  a  street   Gets  X  and  Y  coordinates  of  a  street   Finds  streets  (by  name)  and  returns  coordinates   Find  streets  (by  name)     Finds  an  address  and  its  Lambert-­‐72  coordinates  (by   Lambert-­‐72  coordinates)   Finds  a  street  (by  ID)   Returns  the  types  of  points  of  interest  in  UrbIS   Finds  points  of  interest  (by  name  and  by  type)   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   Geoloc   Organization   CIBG   Description   location  address,  display  the  result  on  the  base  map   Urbis,  route  calculation,  adding  dynamic  maps  in  a   website   One-­‐way  road  traffic  overview   URBIZONE  WiFi  access  points   WebGIS  application  of  real-­‐time  tracking  of   participants  to  test  the  20  km  of  Brussels  

OneWayMap   URBIZONE   Running  for  UrbIS   PortailBruxellesmobilit é   PortailBruxellesespace   publics   site  des  arbres   Primes  à  la  renovation  

CIBG   CIBG   CIBG  

Brussels  Mobility   mobility  in  the  Brussels  region   Brussels  Mobility   Management  of  public  spaces  in  the  Brussels  region   Brussels-­‐Capital   Region   Brussels-­‐Capital   electronic  cadastre  and  aerial  photos  of  trees  in  the   Brussels  region   renovation  grants  in  the  Brussels  region  

© EPIC Consortium

52  

Version 1.0, 05/07/2011  

EPIC – D2.3
Region   BruGIS   RRU   Monitoring  des   quartiers   Bâtimentsexemplaires   Espaces  verts  et   promenade  verte   GISMOB   Brussels-­‐Capital   Region   Brussels-­‐Capital   Region   Brussels-­‐Capital   Region   Brussels   Environment   Brussels   Environment   Brussels   Environment   Cartographic  site  of  the  Brussels-­‐Capital  Region   Regional  Planning  Regulations   monitoring  of  the  145  districts  of  Brussels   exemplary  buildings  and  sustainable  neighborhoods   Map  of  green  spaces   company  mobility   aerial  thermography  mapped   community  facilities  in  the  Brussels  region:  health,   welfare,  housing,  culture   transit  routes   social-­‐health  in  the  Brussels  region  

thermographieaérienne   Brussels   Environment   Wegwijs  in  Brussel   STIB   Bruxelles  social   VGC   STIB   CoCoF  

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  (%)  
54   Version 1.0, 05/07/2011  

• •

© EPIC Consortium

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 Implementation
Technical   Requirements  & Implementation   Guidelines

Requirements  Analysis  –  WP2
Internal  Meetings

Evaluation/Validation WP7
EPIC  Platform  &   Roadmap

WP3 WP4

Workshops

SotA  Survey

WP6

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   Name   Description   FR1   Severity   High  

Common  role-­‐based  portal  server   All  pilots  will  get  access  to  the  services  solely  via  the  EPIC  platform  portal,  which   needs  to  contain  a  portal  server  to  manage:   • • • • • • 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   Name   Description   FR2   Registration  of  a  service   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.   Severity   High  

 
Table  8:  Requirement  FR3   ID   Name   Description   FR3   Severity   High  

Registration  of  a  stakeholder  –  providing  credentials  and  trust  evidences   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   Name   Description   FR4   Subscription  to  a  web  service   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.   Severity   Low  

 
Table  10:  Requirement  FR5   ID   Name   Description   FR5   Severity   Medium  

Federated  single  sign  on  using  various  e-­‐Identity  means   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   Name   Description   FR6   Search  for  a  web  service   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).   Severity   Low  

 
Table  12:  Requirement  FR7   ID   Name   Description   FR7   Severity   Medium  

Provide  comfortable  possibility  to  insert  and  edit  contents  of  the  EPIC  web   portal   The   platform   has   to   provide   web   content   management   functionality   for   web   masters  via  the  portal  interface.  

© EPIC Consortium

62  

Version 1.0, 05/07/2011  

EPIC – D2.3
  Table  13:  Requirement  FR8   ID   Name   Description   FR8   Severity   Medium  

Possibility  to  negotiate  SLAs  when  needed   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   Name   Description   FR9   Severity   High  

DBMS  capable  for  manipulating  significant  amount  of  data     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   Name   Description   FR10   Severity   High  

Time  zone  and  multicurrency  support   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   Name   Description   FR11   Role-­‐based  user  interface   The   Front-­‐end   must   provide   a   different   set   of   functionalities   depending   on   the   user  that  is  currently  logged  on.   Severity   High  

© EPIC Consortium

63  

Version 1.0, 05/07/2011  

EPIC – D2.3
  Table  17:  Requirement  FR12   ID   Name   Description   FR12   Administration  interface   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   Name   Description   FR13   Registration  Page   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   Name   Description   FR14   Service  registration  screen   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   Name   Description   FR15   Personal  Space   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.   Severity   Medium   Severity   High   Severity   High   Severity   High  

 
Table  21:  Requirement  FR16   ID   FR16   Severity   Low  

© EPIC Consortium

64  

Version 1.0, 05/07/2011  

EPIC – D2.3
Name   Description   Advanced  search  for  services   A   search   form   allowing   the   users   to   search   for   services   using   multiple   criteria   (category,  location,  etc.).  

 
Table  22:  Requirement  FR17   ID   Name   Description   FR17   Notification  List   A  list  with  the  updates  on  services  that  the  users  have  been  subscribed  to.   Severity   Low  

 
Table  23:  Requirement  FR18   ID   Name   Description   FR18   Promoted/Latest  services  area   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.   Severity   Low  

  5.2.1.3 IOT Requirements
Table  24:  Requirement  FR19   ID   Name   Description   FR19   Severity   High  

Easy  integration  into  cloud  services   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   Name   Description   FR20   Interoperability   Data   feeds   coming   from   a   from   a   variety   of   domestic   and   industrial   monitoring   equipment   will   be   published   within   the   EPIC   platform,   consumed   by   other   Severity   High  

© EPIC Consortium

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   Name   FR21   Multilanguage  support   semantics  technology.   Severity   Medium  

Description   The   EPIC   platform   should   support   Multilanguage   capabilities,   exploiting   the  

 
Table  27:  Requirement  FR22   ID   Name   FR22   Severity   Medium  

Semantic  annotation  for  web  services   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.  

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

  5.2.1.5 Other Requirements
Table  28:  Requirement  FR23   ID   Name   Description   FR23   Feedback   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.   Severity   Low  

 

© EPIC Consortium

66  

Version 1.0, 05/07/2011  

EPIC – D2.3
Table  29:  Requirement  FR24   ID   Name   Description   FR24   Statistics  &  Analytics   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.).   Severity   Low  

  5.2.2 Non Functional Requirements
Table  30:  Requirement  NF1   ID   Name   Description   NF1   Usability   The  EPIC  platform  should  ensure  its  usability,  especially  for  the  processes  where   the  actor  is  the  end-­‐user  such  as  the  front-­‐ends.     Severity   High  

 
Table  31:  Requirement  NF2   ID   Name   Description   NF2   Privacy  Protection   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.   Severity   Medium  

 
Table  32:  Requirement  NF3   ID   Name   Description   NF3   Severity   Low  

Security  –  rule-­‐based  authentication  and  authorization   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   67   Version 1.0, 05/07/2011  

© EPIC Consortium

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   Name   Description   NF4   Support  for  mobile  devices   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).   Severity   Medium  

 
Table  34:  Requirement  NF5   ID   Name   Description   NF5   No  need  for  training   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.   Severity   Medium  

 
Table  35:  Requirement  NF6   ID   Name   Description   NF6   Severity   Medium  

Attractive  design  of  EPIC  web  portal  and  pilot  applications   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   Name   NF7   High  availability   Severity   Medium  

© EPIC Consortium

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   Name   Description   RRS1   Severity   Low  

Multi-­‐Cultural  Description  of  the  Real  Estate  Properties   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   Severity   High  

© EPIC Consortium

69  

Version 1.0, 05/07/2011  

EPIC – D2.3
Name   Description   GIS/Map  for  showing  points  of  interest,  real  estate  properties,  etc.   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   Name   Description   RRS3   Severity   Medium/Low  

Reach   as   many   smart   phone   platforms   as   possible   and   minimize   software   development  effort   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   Name   Description  

RRS4  

Severity   High  

Realise  augmented  reality  functionality  (only  mobile  part)   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   Name   Description  

RRS5  

Severity   High  

Ensure  good  performance  of  video  flow  in  augmented  reality  view   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   Name   Description   RRS6   Severity   High  

Enable   for   communication   between   the   mobile   application   and   the   portal   server   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  
71   Version 1.0, 05/07/2011  

© EPIC Consortium

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   Name   Description   RUP1   GIS   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.   Severity   High  

 
Table  44:  Requirement  RUP2   ID   Name   Description   RUP2   Performance  of  architecture   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.   Severity   High  

 
Table  45:  Requirement  RUP3   ID   Name   Description   RUP3   Middleware  Interfaces   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.   Severity   High  

 
Table  46:  Requirement  RUP4   ID   Name   RUP4   Middleware  Administration   Severity   High  

© EPIC Consortium

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   Name   Description   RUP5   IM/NAV  Marketplace   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.   Severity   High  

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   Name   Description   RSE1   Severity   Medium  

Domestic  Energy  Monitoring  (Hildebrand  /  Manchester)   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   73   Version 1.0, 05/07/2011  

© EPIC Consortium

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   Name   Description   RSE2   Severity   Medium  

Generic  Energy  Monitoring  Framework  (BCU)   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.   •   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  

  1.
2. 3. 4. 5. 6.

© EPIC Consortium

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   Name   Description   RSE3   User  Login   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.   Severity   High  

 
Table  51:  Requirement  RSE4   ID   Name   Description   RSE4   Severity   High  

Examine  overall  household  energy  usage   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   Severity   High  

© EPIC Consortium

75  

Version 1.0, 05/07/2011  

EPIC – D2.3
Name   Description   Compare  energy  usage  to  local  average   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   Name   Description   RSE6   Installing  a  household  system   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.   Severity   High  

 
Table  54:  Requirement  RSE7   ID   Name   Description   RSE7   Recording  user  notes   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.       Severity   High  

 
Table  55:  Requirement  RSE8   ID   Name   Description   RSE8   Raise  issue  ticket   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.     Severity   High  

© EPIC Consortium

76  

Version 1.0, 05/07/2011  

EPIC – D2.3  
Table  56:  Requirement  RSE9   ID   Name   Description   RSE9   Severity   High  

Update  household  configuration   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   Name   Description  

RSE10   User  defined  Alerts  

Severity   High  

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   Name   Description   DE1   Application  Development   This  task  is  performed  individually  by  all  project  partners  –  ideally  using  an  IDE   environment  as  a  common  solution  development  platform  integrating  individual   development  tools.   Severity   Low  

 

© EPIC Consortium

77  

Version 1.0, 05/07/2011  

EPIC – D2.3
Table  59:  Requirement  DE2   ID   Name   Description   DE2   Portal  Configuration   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.   Severity   High  

 
Table  60:  Requirement  DE3   ID   Name   Description   DE3   Web  Service  Publication   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.   Severity   High  

 
Table  61:  Requirement  DE4   ID   Name   Description   DE4   Application  Adapters   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.   Severity   Low  

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] 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    

[12] [13]

© 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  

Sign up to vote on this title
UsefulNot useful