Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Framework Blueprint for Energy Management Systems

12a43b001bc8ad3bd1c4da9ebc32bacc?s=47 João Pinho
January 27, 2015

Framework Blueprint for Energy Management Systems

A framework for seamless deployment of energy efficient techniques targeting multiple buildings.

12a43b001bc8ad3bd1c4da9ebc32bacc?s=128

João Pinho

January 27, 2015
Tweet

Transcript

  1. Framework  Blueprint   Energy  Management  Systems   João  Pinho  

      January  27th,  2015  
  2. Contents Introduc)on   Problem       2  

  3. Contents Introduc)on   Problem   Methodology       3

     
  4. Contents Introduc)on   Problem   Methodology   Related  Work  

        4  
  5. Contents Introduc)on   Problem   Methodology   Related  Work  

    SoluAon  Proposal   5  
  6. Contents Introduc)on   Problem   Methodology   Related  Work  

    SoluAon  Proposal   EvaluaAon   6  
  7. Introduc<on Context   7  

  8. Introduc<on Context   8  

  9. Introduc<on Context   9   Ground  IrrigaAon  

  10. Introduc<on Context   10   Ground  IrrigaAon   Occupancy  DetecAon

     
  11. Introduc<on Context   11   Access  Control   Ground  IrrigaAon

      Occupancy  DetecAon  
  12. Introduc<on Context   12   Access  Control   Ground  IrrigaAon

      Occupancy  DetecAon   Lightning  
  13. Introduc<on Context   13   Air  CondiAoning   Access  Control

      Ground  IrrigaAon   Occupancy  DetecAon   Lightning  
  14. Introduc<on Context   14  

  15. Introduc<on BACSs  provide  automaAc  control  over  embedded  controllers!   Context

      15  
  16. Introduc<on Decentralized   Embedded  Controllers   Context   16  

    BACSs  provide  automaAc  control  over  embedded  controllers!  
  17. Introduc<on Context  –  Building  AutomaAon  Systems   17   Daylight

    Side Actuation (KNX) Sensors (Modbus) Actuation (BACnet) Actuation (EG2) HVAC   Sensors   Blinds   Lights  
  18. Introduc<on Context  –  Building  AutomaAon  Systems   18   • 

    Devices  communicate  over  dedicated     sensorial  networks   •  These  networks  connect  devices  (sensors  and  actuators)     enabling  control  over  building  equipment   •  Control  logic    of  those  devices  is  embedded  into  their  firmware  and  distributed   into  a  system  that  is  typically  decentralized   Daylight Side Actuation (KNX) Sensors (Modbus) Actuation (BACnet) Actuation (EG2)
  19. Mo<va<on Energy  Efficiency  ObjecAves   19   •  Monitor  energy

     consumpAon   •  Be  able  to  actuate  intelligently  and  automaAcally  over  building  devices     •  Measure  energy  savings  using  baselines  
  20. Mo<va<on Energy  Efficiency  Techniques   20   Actuation (KNX) Sensors

    (Modbus) Actuation (BACnet) Actuation (EG2) Auto open blinds during day time (one time setup by technician) K N X E G 2 Auto Dimming Luminaries Energy-­‐Efficiency   Technique  1   Energy-­‐Efficiency   Technique  2  
  21. Mo<va<on Energy  Efficiency  Techniques   21   Actuation (KNX) Sensors

    (Modbus) Actuation (BACnet) Actuation (EG2) Auto open blinds during day time (one time setup by technician) K N X E G 2 Auto Dimming Luminaries Energy-­‐Efficiency   Technique  1   Energy-­‐Efficiency   Technique  2   EE  Techniques  is  commissioned  into  distributed  and  embedded  hardware   controllers,  over  a  dedicated  network  
  22. Mo<va<on Energy  Efficiency  Techniques   22   Actuation (KNX) Sensors

    (Modbus) Actuation (BACnet) Actuation (EG2) Auto open blinds during day time (one time setup by technician) K N X E G 2 Auto Dimming Luminaries 1.  Most  automaAon  protocols  are  open,  but  their  commissioning  instrucAons  are   closed  to  their  vendors  
  23. Mo<va<on Energy  Efficiency  Techniques   23   Actuation (KNX) Sensors

    (Modbus) Actuation (BACnet) Actuation (EG2) Auto open blinds during day time (one time setup by technician) K N X E G 2 Auto Dimming Luminaries 1.  Most  automaAon  protocols  are  open,  but  their  commissioning  instrucAons  are   closed  to  their  vendors   2.  EE  techniques  are  installed  on  hardware  controllers  (like  a  BIOS),  therefore  hard   to  update  and  require  also  vendor  intervenAon  
  24. Mo<va<on Energy  Efficiency  Techniques   24   1.  Most  automaAon

     protocols  are  open,     but  their  commissioning  instrucAons  are  closed  to  their  vendors   2.  EE  techniques  are  installed  on  hardware  controllers  (like  a  BIOS),   therefore  hard  to  update  and  require  also  vendor  intervenAon   3.  In  presence  of  mulAple  BASs,  given  their  heterogeneity  the  same   techniques  must  be  programmed  repeatedly   Actuation (KNX) Sensors (Modbus) Actuation (BACnet) Actuation (EG2) Auto open blinds during day time (one time setup by technician) K N X E G 2 Auto Dimming Luminaries
  25. Mo<va<on Energy  Efficiency  Techniques   25   Actuation (KNX) Sensors

    (Modbus) Actuation (BACnet) Actuation (EG2) Auto open blinds during day time (one time setup by technician) K N X E G 2 Auto Dimming Luminaries Energy  Efficiency  techniques  should  be  done  on  socware,  but  there  is  no   infrastructure  to  support  it!  
  26. Contents IntroducAon   Problem   Methodology   Related  Work  

    SoluAon  Proposal   EvaluaAon       26  
  27. Problem 27   Statement   •  A  sophisAcated  centralized  control

     system  can  not  be  based  on  limited   hardware  controllers   •  There  is  no  framework  for  the  development  of  energy  efficiency  applicaAons,  or   any  kind,  but  specially  these  one’s     •  The  implementaAon  of  this  energy  efficiency  techniques  requires  real  Ame  data   processing  capabiliAes   •  CollecAng  such  data  requires  a  session  management  component,  because  BASs   aeach  and  detach  their  IP  gateways  in  an  intermieent  way  
  28. Problem 28   Impact   •  Queries  over  historical  data

     would  be  accessible  for  applicaAons   •  RegistraAon  of  new  data  points  based  on  the  exisAng  (virtual  data  points)   ones   •  A  real-­‐Ame  noAficaAons  and  alarms  could  be  triggered  based  on  sets  of   condiAons   •  UAlity  consumpAon  allocaAon  to  people,  spaces  and  Ame  periods  would  be   reachable  for  applicaAons  of  mulAple  buildings  
  29. Problem •  Is  it  possible  to  create  an  hardware-­‐independent  

     framework     enabling  development  of  applicaAon  for  buildings?   •  Can  such  framework  enable  the  deployment  of  energy  efficiency   applicaAons  for  mulAple  buildings?   •  Such  framework  would  allow  provider  independence,     thus  abolishing  vendor  lock-­‐in  pracAces   29   Statement  
  30. Contents IntroducAon   Problem   Methodology   Related  Work  

    SoluAon  Proposal   EvaluaAon       30  
  31. Methodology •  Literature  survey  regarding  middleware  for  BASs   • 

    Survey  of  exisAng  BEMS  soluAons  and  features   •  Development  of  a  small  set  of  applicaAon  to  validate  the  proposed   framework   •  Improve  the  core  framework  iteraAvely  based  on  the  obtained  results   and/or  problems  encountered   •  ValidaAon  in  a  real-­‐world  sejng,  featuring  some  heterogeneity  to  achieve   a  beeer  demo  (IST  Taguspark  campus)   31 Overview  
  32. Contents 32   IntroducAon   Problem   Methodology   Related

     Work   SoluAon  Proposal   EvaluaAon      
  33. Related  Work Overview   33   •  Standards   • 

    Middleware  for  BASs   •  BEMS  Commercial  Tools  
  34. Related  Work Standards   Space     Planning    

    Event   NoAficaAon     Alarm   NoAficaAon   Historical     Data   Scheduling     Scenarios     Standards   EN   15232   ISO   16484-­‐2   34  
  35. Related  Work Middleware  for  BASs   35   •  EnergyWise

      •  aWESoME   •  MEDUSA   •  PoliSave   •  LinkSmart   •  Home  SOA   •  DomoNet   Diverse BAS and Data OPC BAC net LON KNX Mod bus Applications for Energy-Efficiency
  36. Related  Work Middleware  for  BASs   36   •  EnergyWise

      •  aWESoME   •  MEDUSA   •  PoliSave   •  LinkSmart   •  Home  SOA   •  DomoNet   Domain   Middleware  
  37. Related  Work Middleware  for  BASs   37   •  EnergyWise

      •  aWESoME   •  MEDUSA   •  PoliSave   •  LinkSmart   •  Home  SOA   •  DomoNet   Domain   Middleware   Web  Services  
  38. Related  Work Middleware  for  BASs   38   •  EnergyWise

      •  aWESoME   •  MEDUSA   •  PoliSave   •  LinkSmart   •  Home  SOA   •  DomoNet   Domain   Middleware   Web  Services   Services   ComposiAon  
  39. Related  Work Middleware  for  BASs   39  

  40. Related  Work Middleware  for  BASs   40   Middleware  for

     BASs  exists,  but  none  seems  to  solve  the   infrastructure  problem  referred  earlier.  
  41. Related  Work Middleware  for  BASs   41   Therefore,  they

     expose  the  heterogeneity  of  their  own   supported  protocols!  
  42. Related  Work Commercial  Tools   42   •  EEM  Suite

      •  Energy  Witness   •  EnerWise  EM   •  Planoramix  (JC)  
  43. Related  Work Commercial  Tools   43   •  EEM  Suite

      •  Energy  Witness   •  EnerWise  EM   •  Planoramix  (JC)   Data   AcquisiAon   Data   Analysis   Alarms  /   NoAficaAon   Data   ReporAng   Real-­‐Ame   Monitoring  
  44. Related  Work Commercial  Tools   44  

  45. Related  Work Commercial  Tools   45  

  46. Related  Work Commercial  Tools   46  

  47. Related  Work Discussion   47   •  BEMS  features  are

     known,  therefore  the  variability  of   applicaAon  needs  are  low!   •  Middleware  for  BASs  exists,  but  do  not  solve  the   heterogeneity  problem  completely   •  There  is  no  plalorm  for  the  development  of  energy  efficiency   applicaAons  for  buildings  
  48. Related  Work Discussion   48   •  A  plalorm,  enabling

     applicaAons  to  perform  queries  over   real-­‐Ame  data  from  BAS,  would  unleash  endless  possibiliAes   •  Such  queries  are  hard  to  perform,  because  they  involve  real-­‐ Ame,  and  some  are  not  known  at  start  (ad-­‐hoc)   •  Moreover,  such  framework  must  be  able  to  deal  with  streams   of  data  coming  from  intermieent  data  sources  
  49. Contents IntroducAon   Problem   Methodology   Related  Work  

    Solu)on  Proposal   EvaluaAon       49  
  50. Solu<on  Proposal Overview   50   Security Layer Core Services

    Layer Data Access Layer Space Planning Billing Models Data Source Management Data Point Management Device Management User Management Notification Services Data Acquisition Data Querying Data History Application Layer Central Administration BEMS: An Architecture Blueprint Data Integration Layer Building Management API Building Data Endpoints Data Source Connectors Field Level / Technology Dependent Layer Energy Dashboard Other Energy Applications n 1 Building Management API Building Data Endpoint (Client - Uses SDK) Driver KNX Driver ModBus Other Driver Data Source Connector Data Source Connector Data Source Connector
  51. Solu<on  Proposal Overview   51   Security Layer Core Services

    Layer Data Access Layer Space Planning Billing Models Data Source Management Data Point Management Device Management User Management Notification Services Data Acquisition Data Querying Data History Application Layer Central Administration BEMS: An Architecture Blueprint Data Integration Layer Building Management API Building Data Endpoints Data Source Connectors Field Level / Technology Dependent Layer Energy Dashboard Other Energy Applications n 1 Building Management API Building Data Endpoint (Client - Uses SDK) Driver KNX Driver ModBus Other Driver Data Source Connector Data Source Connector Data Source Connector
  52. Solu<on  Proposal Overview   52   Security Layer Core Services

    Layer Data Access Layer Space Planning Billing Models Data Source Management Data Point Management Device Management User Management Notification Services Data Acquisition Data Querying Data History Application Layer Central Administration BEMS: An Architecture Blueprint Data Integration Layer Building Management API Building Data Endpoints Data Source Connectors Field Level / Technology Dependent Layer Energy Dashboard Other Energy Applications n 1 Building Management API Building Data Endpoint (Client - Uses SDK) Driver KNX Driver ModBus Other Driver Data Source Connector Data Source Connector Data Source Connector
  53. Solu<on  Proposal Overview   53   Security Layer Core Services

    Layer Data Access Layer Space Planning Billing Models Data Source Management Data Point Management Device Management User Management Notification Services Data Acquisition Data Querying Data History Application Layer Central Administration BEMS: An Architecture Blueprint Data Integration Layer Building Management API Building Data Endpoints Data Source Connectors Field Level / Technology Dependent Layer Energy Dashboard Other Energy Applications n 1 Building Management API Building Data Endpoint (Client - Uses SDK) Driver KNX Driver ModBus Other Driver Data Source Connector Data Source Connector Data Source Connector
  54. Solu<on  Proposal Overview   54   Security Layer Core Services

    Layer Data Access Layer Space Planning Billing Models Data Source Management Data Point Management Device Management User Management Notification Services Data Acquisition Data Querying Data History Application Layer Central Administration BEMS: An Architecture Blueprint Data Integration Layer Building Management API Building Data Endpoints Data Source Connectors Field Level / Technology Dependent Layer Energy Dashboard Other Energy Applications n 1 Building Management API Building Data Endpoint (Client - Uses SDK) Driver KNX Driver ModBus Other Driver Data Source Connector Data Source Connector Data Source Connector
  55. Solu<on  Proposal Overview   55   Security Layer Core Services

    Layer Data Access Layer Space Planning Billing Models Data Source Management Data Point Management Device Management User Management Notification Services Data Acquisition Data Querying Data History Application Layer Central Administration BEMS: An Architecture Blueprint Data Integration Layer Building Management API Building Data Endpoints Data Source Connectors Field Level / Technology Dependent Layer Energy Dashboard Other Energy Applications n 1 Building Management API Building Data Endpoint (Client - Uses SDK) Driver KNX Driver ModBus Other Driver Data Source Connector Data Source Connector Data Source Connector
  56. Solu<on  Proposal Overview   56   Security Layer Core Services

    Layer Data Access Layer Space Planning Billing Models Data Source Management Data Point Management Device Management User Management Notification Services Data Acquisition Data Querying Data History Application Layer Central Administration BEMS: An Architecture Blueprint Data Integration Layer Building Management API Building Data Endpoints Data Source Connectors Field Level / Technology Dependent Layer Energy Dashboard Other Energy Applications Buildin Driver KNX Data Source Connector
  57. Contents 57   IntroducAon   Problem   Methodology   Related

     Work   SoluAon  Proposal   Evalua)on      
  58. Evalua<on •  Prototype  ImplementaAon     •  Improve  the  core

     framework  iteraAvely  based  on  the   obtained  results  and/or  problems  encountered   •  ValidaAon  in  a  real-­‐world  sejng,  featuring  some   heterogeneity  to  achieve  a  beeer  demo  (IST  Taguspark   campus)   58 Overview  
  59. Evalua<on Prototype  Overview   59   Security Layer Core Services

    Layer Data Access Layer Data Source Management Data Point Management Device Management Authentication Only Notification Services Data Acquisition Data History Application Layer Central Administration Data Integration Layer Auto Dimming Lumaries App Auto Blind Shutoff App Building Management API Building Data Endpoints Data Source Connectors
  60. Planning Overview   5,2 months 2w 1,4w 3,05 months 4d

    2 weeks 3d 3 weeks 1,3 months 2w 3,2 weeks 1w 6 months 6 months 01/2015 02/2015 03/2015 04/2015 05/2015 06/2015 07/2015 Project :: Framework for BEMS 17/07/15 Dissertation Kick-off 01/02/15 Development 22/06/15 Data Connectors 13/02/15 Building Data Endpoints 24/02/15 Data Acquisition Phase 24/02/15 Framework Services 15/05/15 Data Acquisition 02/03/15 Data History 16/03/15 Building Management API 19/03/15 Mapping Services 09/04/15 Other Services 15/05/15 Unit Tests 29/05/15 Framework Integrated Testing 29/05/15 Applications Development 22/06/15 Unified Integration Tests 29/06/15 Prototype Review - Workshop 29/06/15 Writing MSc Thesis 17/07/15 Plan Document Index 01/02/15 Revision Request (via EasyChair) 30/06/15 Revision - Round 1 16/03/15 Revision - Round 2 16/04/15 Revision - Round 3 16/05/15 Revision - Round 4 01/06/15 Revision - Round 5 16/06/15 Revision - Round 6 30/06/15 Writting 17/07/15 Delivery 17/07/15 Expected End Title
  61. Conclusions 61 •  This  work  proposes  a  framework  that  will

     enable  the  development  of   energy  efficiency  applicaAons   •  As  we  have  seen  these  techniques  must  be  performed  via  socware   •  There  is  no  framework  for  achieve  this  purpose   •  Base  on  our  related  work,  we  propose  the  implementaAon  of  a  prototype   of  this  framework  that  will  be  validated  in  a  real  world  sejng.   Overview  
  62. Framework  Blueprint   Energy  Management  Systems   joao.pinho@tecnico.ulisboa.pt    

    January  26th,  2015