Embed Size (px)
Citation preview
1
Smart Home Abstraction Layer
Dr. Lindsay Frost HGI Board Member, Vice-chair of HGI SmartHome
(NEC Laboratories Europe) [email protected]
Copyright 2013 by HGI – All rights reserved
Abstraction Layer ? What's that?
2
Cloud-based Applications
Access Network
Sensors
&
Actuators
HOME GATEWAY HOME GATEWAY HOME GATEWAY
Network Driver A
Network Driver B
Abstraction Layer
Proxy Local Applications
Abstraction Layer
=
magic in the middle
to interwork the services
with all kinds of devices
Huge number of device types
connected on
diverse networks
Ecosystem of services
from 3rd Parties
to monitor and control
real-world devices
Copyright 2013 by HGI – All rights reserved
Smart Cities
Why do Smart Cities need to consider
Abstraction Layers ?
Copyright 2013 by HGI – All rights reserved
Wind/Solar +
E-Cars sensed for
SmartCharging
Smart Cities
Crop Alert from
ice damage !
Overcrowding detected
in SuperStore venue. IF fire-alarm,
then people directed to best exits
HomeGateway interacts with
Calendar + SmartGrid + Billing
+ Home Automation + Safety V2X GW. of passing cars collect
environmental data and sends
later to M2M application.
Pollution or Agriculture Sensors
managed by dedicated M2M Gateways
Building Controller senses
room occupancy and people
flows and helps avoid panic.
Needed: Gateways and Abstraction Layers
Copyright 2013 by HGI – All rights reserved
Why HGI ? What do we bring to the discussions?
5
HGI: Connecting Homes, Enabling Services
Copyright 2013 by HGI – All rights reserved
HGI’s Mandate
To set requirements for the broadband-enabled home, the equipment and services deployed by the operators
Scope: Home Gateway, Home Network, End Devices
Including Smart Home services, software and hardware
To offer a test program to check the vendor compatibility with operator requirements
Remote testing of software compatibility begins 12/2013 !
To build the ecosystem with all stakeholders (device vendors, services providers, application developers)
Dialogue with other SDO
Develop PLATFORM approach (Home Gateway + cloud)
6
Copyright 2013 by HGI – All rights reserved
HGI’s Working Groups & Liaisons
Business Group Business need and use cases
Technical Group Networking and hardware needs
Test Task Force Test plans and logo program
Smart Home architecture &
software
Key Use Cases
Home Energy Management
Alarms & Home Security
Ambient Assisted Living
Comfort & Home Automation
NG Communications
Media Re-Distribution
7
Liaison Partners
Copyright 2013 by HGI – All rights reserved
HOME GATEWAY
Reference Architecture
8
RP1 – Abstraction Application Interface
RP2 – Device Application Interface
RP4 – Remote Representation (e. g. ETSI M2M)
RPx – Cloud API
There are more reference points for LAN side access and inter-application communication, but HGI focuses on RP1, RP2, RP4 and probably RPx.
RPx is not defined yet, but considered to be a cloud side API (i.e. for M2M platforms)
D1 D2 D3 Dx
Abstraction Layer
RP2
Remote Access Agent
App 1 App N …
RP4
Remote Access Middle
ware
RPx
RP1
Copyright 2013 by HGI – All rights reserved
Goals for HGI Abstraction Layer
1. Enable unified APIs for application developers
1. command, control and query home appliances
2. Be independent of HAN (Home Area Network) technologies
1. developer doesn’t need to know details about Zigbee, Z-Wave, wireless m-bus etc.
2. developer can concentrate on modeled devices available
3. Make applications portable across various devices
4. Enable extensibility of the system to additional HANs
5. Allow a pass-through mechanism so Applications can use HAN-specific functions
9
This all assumes Developers know the devices !
Copyright 2013 by HGI – All rights reserved
Needed: a common Device Model Template
A common template used to specify device capabilities
When instantiated, enables a common API for all devices of the same class (eg “Doorbell”)
Should be approved by all participating organizations (BBF, HGI, ETSI SmartM2M, OneM2M, OSGi-A, …)
Template has an informal (text) and a formal section (machine-readable, probably XML based)
10
Copyright 2013 by HGI – All rights reserved
Needed: a common Device Model Template Device instances
Friendly Name – user readable
Manufacturer – text or agreed id
Model Name – exact model name
Model Number – not unique
Serial Number – unique to manufacturer
Universal Product Code
Identifier –unique in customer area
11
Services (aka “interfaces”)
(grouping of actions)
Actions (aka “operations”)
e.g. on/off, “methods”, ...
etc, etc etc ....
Device classes (aka “types”)
States (aka “state variables”)
Events (asynchronous info)
i.e. what info, when, what is trigger
Copyright 2013 by HGI – All rights reserved
Potential Contributors ?
Device Manufacturers
System Architects SmartM2M
Automation Protocols ULE
EU/National Projects
EC Smart
Appliance
Semantics
12
Copyright 2013 by HGI – All rights reserved
A pseudo code XML example: Concrete device using standardized modules
13
<Domain xmlns=“http://hgi.org/xml/dal”
name=“com.smartdev.home”/>
<Device>
<DeviceInfo>
<Name>PowerSwitch</Name>
<Vendor>Smart Device Inc.</Vendor>
<ModelInfo>
<Model>SD-PS-*</Model>
</ModelInfo>
</DeviceInfo>
<Modules>
<Module name=“status”
extends=“org.hgi.core.BooleanState”>
<Events>
<Event name=“batteryLow”/>
<Event name=“alive”/>
</Events>
</Module>
<Modules>
</Device>
</Domain>
DAL XML Schema
HGI DAL
HGI Core
BooleanState
Smart Device
PowerSwitch
PowerSwitch
status : BooleanState status : BooleanState
batteryLow alive
Actions
Events
Copyright 2013 by HGI – All rights reserved
(Our) Next Steps
HGI invites your contact re:
Device template design
Instantiated device models for major smart home devices
Smart home interface requirements (applications & networks)
Evaluating how to enable Cloud-based applications
An open, reliable, low-barrier Device Model repository
HGI invites your participation:
Guest at next meetings: California (December), Malta (March)
Remote SWEX Test Event for HGI members Nov/Dec 2013 (still time to get involved)
HGI plans to input above work to OneM2M during 2014
14
Copyright 2013 by HGI – All rights reserved
Questions ?
15
