1 / 22

An Energy Perspective on IoT

Interoperability. An Energy Perspective on IoT. An Energy Perspective on IoT. Bruce Nordman Lawrence Berkeley National Laboratory February 18, 2016. WHY?. Lack of Interoperability wastes energy, money, and carbon. WHY?. … m istakes can last a long time ….

lindabishop
Download Presentation

An Energy Perspective on IoT

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Interoperability An Energy Perspective on IoT An Energy Perspective on IoT Bruce NordmanLawrence Berkeley National Laboratory February 18, 2016

  2. WHY? • Lack of Interoperability wastes energy, money, and carbon

  3. WHY? • … mistakes can last a long time … US San Francisco Bay AreaChapter

  4. Interoperability • /ˌɪntərˈɒprəbələti/ • “work between”, “function between” • Standard interfaces • Physical/mechanical, electrical, signaling, data formats, … • Technology standards • Exist; Few; Good

  5. before we start • energy vs. electricity • residential and commercial buildings – 70% of elec. (U.S.) • IoT ?? • ‘Thing’ – “object, entity” — IooT — IT vs. IoT • IoT – interaction with physical world • location, environment, physical processes, movement … lots of new semantics • IT • 14% of buildings electricity • Only 9% in data centers

  6. Getting to Interoperability • Necessary ingredients • Ways to fail • What to do

  7. Need: Universal Interoperability • Any device should work with all other objects in any space • Across building types • Residential, commercial, vehicles, … • Across geography • Countries, language, … • Across time • Worthy of durability • Across end uses • Coordination, cooperation • Across people • Age, disability, culture, activity, context, … US San Francisco Bay AreaChapter

  8. Need: Layered Model • Application • Presentation • Session • Transport • Network • Data link • Physical • Isolate complexity • Enable interoperability • Enable technology evolution Narrow waist critical .

  9. Need: Layered model for power “Network Power Integration” [ [ [ Price Quantity

  10. Need: Networked power (locally) • “Local Power Distribution” • Network model of power • Nanogrid as base unit of organization All connections peer-to-peer and can be changed dynamically Price is how devices know which way power should flow

  11. Fail: Smart Grid: Architecture run amok

  12. Need: Simplicity • Technology should be simple unless proven that it cannot be

  13. Fail: Integrate with cloud when not needed • Products communicate with others in building only via cloud interfaces • Opens up privacy/security risks • Reduced or no operation when Internet connectivity is lost • Creates gatekeeper that can restrict or eliminate interoperability • Brittle • Business failure could render devices inoperative • Optional cloud connection is fine

  14. Fail: Technology designed around a business model • Good technology can adapt to many business models • Internet example • Business models need to compete

  15. Fail: Inconsistent user interface elements

  16. Need: User Interface Standards • Familiar – both de jure and de facto

  17. Need: Design around people first • Define concepts, terms, metaphors around people’s needs • Then move into data models and protocols • Fail: UI content derived from internal technical standards User Interface Device

  18. What to do ? • Protocols – will be multiple – try to minimize # • Use gateways to accommodate multiple protocols • Create reference standard data model • Start from (mostly) blank slate • Harmonize towards this • Start with user interface • Converge protocol standards over time - upgrades • Create common ‘network services’ for IoT

  19. Fail: Data Model Issues • Manufacturer • vendor-identifier (a 2-byte numeric value) and vendor-name (BACnet) • Vendor (FSGIM) • VendorName (MODbus) • Instrument/Manufacturer (sMAP) • Vendor name (VT) • ENERGY STAR Manufacturing Partner and Brand Name (ENERGY STAR) • Manufacturer and Make (BEDES) • Manufacturer (HPXML) • Manufacturer and Brand (NILM) • Manufacturer (XMPP) • Manufacturer (DMTF) • deviceManufacturer and deviceVendor (Haystack) • MakeModel (CTA 2047) Model model-name (BACnet, 70) Model (FSGIM) ModelName and ProductCode (MODbus) Device model number (VT) Instrument/Model (sMAP) Model Name and Model Number (ENERGY STAR) Model (DMF and VT) ModelNumber (HPXML) Model (NILM) Brand and Product Line / Family Name (TPEx). Name (XMPP) Also: SKUs, UPC codes, retail numbers, descriptions, Global Trade Item Number and version UPC (Universal Product Code), Part Number, … • Even when name of field is same, definition/content often very different

  20. Need: Network Services • Function like layers to isolate complexity • Examples • DHCP, DNS, file sharing, directory, printing, time, … • Buildings IoT needs • Discovery, occupancy, location, energy reporting, preferences, …

  21. Summary • IoT has huge interoperability issues • Will get worse • But we know how to do better • And should start ASAP

  22. Thank You I bop it interlayerI try it inoperableNo irritable pietyIrritable I type onInitiate orb replyTry liberation pieYe liberation tripRetry pie libationRiper libation yetBipolar eternityI pin a terrible toyI pity eternal orb II be on reality tripA brittle irony pieBilinear pottery Bruce Nordman bnordman@lbl.gov nordman.lbl.gov

More Related