Interoperability
An Energy Perspective on IoT
An Energy Perspective on IoT
Bruce Nordman
Lawrence Berkeley National Laboratory
February 18, 2016
1
US San Francisco Bay Area Chapter
WHY?
Lack of Interoperability wastes energy, money, and carbon
2
US San Francisco Bay Area Chapter
WHY?
… mistakes can last a long time …
3
US San Francisco Bay Area Chapter
Interoperability
/ˌɪntərˈɒprəbələti/
• “work between”, “function between”
• Standard interfaces
• Physical/mechanical, electrical, signaling, data formats, …
• Technology standards
Exist; Few; Good
4
US San Francisco Bay Area Chapter
before we start
• energy vs. electricity
• residential and commercial buildings – 70% of elec. (U.S.)
• IoT ??
• ‘Thing’ – “object, entity” — IooT —
• IoT – interaction with physical world
IT vs. IoT
 location, environment, physical processes, movement … lots of new semantics
 IT
• 14% of buildings electricity
5
• Only 9% in data centers
US San Francisco Bay Area Chapter
Getting to Interoperability
• Necessary ingredients
• Ways to fail
• What to do
6
US San Francisco Bay Area Chapter
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, …
7
US San Francisco Bay Area Chapter
Need: Layered Model
Application
• Isolate complexity
Presentation
• Enable interoperability
Session
• Enable technology evolution
Transport
Network
Narrow waist critical
.
Data link
Physical
8
US San Francisco Bay Area Chapter
Need: Layered model for power
“Network Power Integration”
Network layers
Application
Transport
NPI layers
[
Physical
9
4. Device discovery and events
Price
3. Internal integration
Quantity
[
Network
Data Link
5. Functional coordination
[
2. Exchange within/between grids
1. Transport of electrons
US San Francisco Bay Area Chapter
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
10
US San Francisco Bay Area Chapter
Fail: Smart Grid: Architecture run amok
11
US San Francisco Bay Area Chapter
Need: Simplicity
Technology should be simple unless proven that it cannot be
12
US San Francisco Bay Area Chapter
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
13
US San Francisco Bay Area Chapter
Fail: Technology designed around a
business model
• Good technology can adapt to many business models
• Internet example
• Business models need to compete
14
US San Francisco Bay Area Chapter
Fail: Inconsistent user interface elements
15
US San Francisco Bay Area Chapter
Need: User Interface Standards
•Familiar – both de jure and de facto
16
US San Francisco Bay Area Chapter
Need: Design around people first
• Define concepts, terms, metaphors around people’s needs
• Then move into data models and protocols
User
Interface
Device
• Fail: UI content derived from internal technical standards
17
US San Francisco Bay Area Chapter
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
18
US San Francisco Bay Area Chapter
Fail: Data Model Issues
Manufacturer
Model
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-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, …
•
19
Even when name of field is same, definition/content often very different
US San Francisco Bay Area Chapter
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, …
20
US San Francisco Bay Area Chapter
Summary
•IoT has huge interoperability issues
• Will get worse
•But we know how to do better
• And should start ASAP
21
US San Francisco Bay Area Chapter
Thank You
Bruce Nordman
[email protected]
nordman.lbl.gov
22
I bop it interlayer
I try it inoperable
No irritable piety
Irritable I type on
Initiate orb reply
Try liberation pie
Ye liberation trip
Retry pie libation
Riper libation yet
Bipolar eternity
I pin a terrible toy
I pity eternal orb I
I be on reality trip
A brittle irony pie
Bilinear pottery
US San Francisco Bay Area Chapter