Open-­‐data  pla+orm  for  integrated  urban  CPSs

Mateusz  Bonecki  Be#erSolu)ons  S.A.  

mateusz.bonecki@be#ersolu)ons.pl  ACCUS  

business  context:  the  city  of  Gdansk

§  valuable  partner  to  ACCUS  consor)um  §  signed  memorandum  of  coopera)on  to  establish  

long-­‐term  coopera)on  with  regard  to  “smart  city”  technologies  

§  host  of  the  pilot  deployment  §  source  of  user  requirements  

§  open-­‐data  leader  in  Poland  §  “manifesto  of  openness”  proclaimed  in  2014  §  ckan  plaKorm  deployed  and  operated  by  Orange  

R&D  Center  (Warsaw)  §  smart  city  development  strategy  

§  member  of  Bloomberg’s  “What  Works  City”  ini)a)ve  

§  partner  to  Ro#erdam,  Glasgow,  and  Umeå  in  “Smart  Ci)es  and  Communi)es”  H2020  “Lighthouse”  project  (TNO,  AIT,  ICLEI)  

Tristar

§  intelligent  transporta)on  system  (ITS)  §  provided  and  maintained  by  Star  ITS  

§  deployed  in  Tricity  agglomera)on  §  Gdansk,  Gdynia,  and  Sopot  

§  func)onali)es  and  modules:  §  street  traffic  control  §  accident  detec)on  §  traffic  conges)on  monitoring  §  traffic  flow  management  §  video  surveillance  §  weather  monitoring  §  signs  and  variable  message  signs  §  parking  informa)on  §  security  (red  light  crossing,  speeding)  §  public  transport  management  

open-­‐data  &  ckan  pla+orm

§ Open  data  and  content  can  be  freely  used,  modified,  and  shared  by  anyone  for  any  purpose.  (Open  Knowledge  Founda)on)  

§ open-­‐source  web-­‐based  plaKorm  §  maintained  by  Open  Knowledge  Interna)onal  §  meta-­‐data  model  §  data  exposi)on  process  management  §  SQLAlchemy  for  object-­‐rela)onal  mapping  §  API  for  third  party  applica)ons  §  more  at:  github.com/okfn/ckan  

challenge

§ urban  systems  (data  sources)  are  ofen  CPSs  §  traffic  management,  energy  management,  water  management,  etc.  

§  frequently:  cri)cal  func)ons  § highly  complex  segng  

§  opera)onal  and  technical  constraints:  permissible  load,  performance,  interoperability,  internal  systems  objec)ves  

§ management  constraints:  service  level  agreements,  use  and  integra)on  terms,  warranty  condi)ons,  other  constraints  

§ challenge  meets  SoSE  §  opera)onal  independence  of  components  § managerial  independence  of  components  

problem

§ find  solu)on  that  will  support  con)nuous  data  supply  to  ckan  plaKorm  

§  iden)fy  all  relevant  factors  that  constrain  the  integra)on  of  Tristar  and  ckan  (technical,  opera)onal,  managerial)  

§ support  adapta)on  of  data  exchange  process  to  iden)fied  constraints  

§ guarantee  reliability:  higher  level  services  (e.g.  open-­‐data  access  services)  won’t  interrupt  internal  processes  and  performance  of  Tristar  as  cons)tuent  system  

soluBon

§ decision  to  build  on  the  early  prototype  of  ACCUS  ICP  

§ ACCUS  ICP  –  seman)c  middleware  for  urban  CPSs  

§ Tristar  –  subsystem  interfaced  through  adapta)on  layer  

§ ckan  plaKorm  –  applica)on  running  on  the  top  of  ICP  

ACCUS  ICP  

Subsystem  Registry  

Service  Forwarding  

ACCUS  API  

Service  Registry  

Subsystem  Monitoring  

CKAN  pla;orm  <<applica>on>>  

TRISTAR  <<subsystem>>  

soluBon  architecture

Tristar  adaptor  

§  subsystem  registra)on  §  informa)on  on  subsystem  condi)on  

§  subsystem  services  forwarding  to  ACCUS  API  

§ managing  access  to  services  under  defined  constraints  

subsystem  registraBon

§ different  data  types  in  Tristar  §  sta)c  (line  schedule,  bus  stop  loca)on)  

§  near  real-­‐)me  (traffic  conges)on,  bus  posi)on,  delays)  

§  subsystem  adaptor  §  retrieves  data  model  §  retrieves  constraints  §  provides  services  to  access  data  from  subsystem  

§  provides  service  to  monitor  subsystem  state  (performance,  requests,  capacity)  

ACCUS  ICP  

Subsystem  Registry  

Service  Forwarding  

ACCUS  API  

Service  Registry  

Subsystem  Monitoring  

CKAN  pla;orm  <<applica>on>>  

TRISTAR  <<subsystem>>  

Tristar  adaptor  

adapBve  data  exchange

§  subsystem  data  access  services  are  forwarded  to  ACCUS  API  

§  subsystem  data  access  constraints  are  reflected  in  subsystem  registry  

§  subsystem  state  (condi)on)  is  reflected  in  subsystem  monitoring  component  

§  service  forwarding  mechanism  takes  into  account  constraints  and  manages  access  to  subsystem  services  accordingly  

ACCUS  ICP  

Subsystem  Registry  

Service  Forwarding  

ACCUS  API  

Service  Registry  

Subsystem  Monitoring  

CKAN  pla;orm  <<applica>on>>  

TRISTAR  <<subsystem>>  

Tristar  adaptor  

API  and  client  applicaBons

§ applica)ons  (e.g.  ckan  plaKorm)  retrieve  data  through  services  forwarded  to  ACCUS  ICP  API  

§ ckan  plaKorm  clients  query  subsystems  through  ACCUS  ICP  under  defined  constraints  

ACCUS  ICP  

Subsystem  Registry  

Service  Forwarding  

ACCUS  API  

Service  Registry  

Subsystem  Monitoring  

CKAN  pla;orm  <<applica>on>>  

TRISTAR  <<subsystem>>  

Tristar  adaptor  

conclusion

§ safe  and  secure  integra)on  of  cri)cal  CPS  with  external  open-­‐data  plaKorm  using  seman)c  and  adap)ve  middleware  

§ towards  commercial  exploita)on  of  another  ARTEMIS  project  

§ opened  data  from  urban  transporta)on  and  traffic  management  system  

§  future  work  plan  §  in  case  of  subsystem  service  unavailability  (due  to  the  constraints  of  use)  ACCUS  ICP  might  provide  alterna)ve  (complementary)  services  (e.g.  provide  seman)cally  fused  data  from  redundant  systems)