An Operating System for the Home
HomeOS: An OS for the home
HomeStore
Video
recording
Remote
unlock
Climate
control
HomeOS
Z-Wave, DLNA,
UPnP, etc.
HomeOS logically
centralizes all
devices
Users interact with
HomeOS, not
individual devices
HomeStore helps
find compatible
devices and apps
HomeOS architecture
Application layer
Tasks
Management layer
Control
Device functionality layer
(DFL)
Device
Device connectivity layer (DCL)
Topological
Heterogeneity source
handled
DCL and DFL (Drivers)
DCL provides basic connectivity to devices
– Discovery
– Abstract differences in protocols
– Connectivity
DFL exports device functionality as a service
–
–
–
–
–
Services are protocol-independent
Exposed as roles and operations
Kernel does not parse or understand services
Allows subscriptions (e.g. when light is toggled)
Applications do not require changes
App layer
Mgmt layer
DFL
DCL
Application layer
App layer
Mgmt layer
Apps compose abstract rules from DFL
Management layer interposes on accesses
Manifests help with compatibility testing
– Lists of mandatory and optional features
– E.g., mandatory: {TV, SonyTV}, {MediaServer}
optional : {Bass Speaker}
DFL
DCL
Interaction between Apps and Drivers
Applications
Exposes Ports
Core Platform
Exports Ports
Drivers
Device (camera, thermostat)
What are ports (classical definition)
Hardware ports
sockets that a device can plug into
e.g., printer ports, mouse ports?
Software ports
locations/addresses that processes run
e.g., Http (port 80), ssh (port 22)
processes can read and write from ports
Ports in Home Lab (HomeHub)
Ports are uses as a communication abstraction
between Drivers Platform (kernel) 
Applications
All modules (drivers, kernel, applications) can read/write
using ports
Driver
Applications
platform
Read/write data
Read/write data
HomeHub ports are associated with Roles
What are Roles?
Roles define service and capabilities that a
device offers
Example role for a pan-tilt-zoom video camera: up, down,
left, right, getImages
Roles may be shared between devices
same roles can be provided by multiple devices
e.g. getTemperature() is a role that can be provided by a
temperature sensor and a thermostat
Interaction between Apps and Drivers
Applications
Bind Ports
Invoke Roles
Exposes Ports with Roles
Core Platform
implements
roles
Exports Ports with Roles
Drivers
Device (camera, thermostat)
How would a camera device work?
Camera Viewer Application
Bind Ports
Invoke Roles
Scan for ports that exports a CamerRole
Invoke the roles exported by CameraRole
Core Platform
implements
roles
Port roles
(CameraRoles: move camera up, down,Left, right)
Drivers
Pan/Tilt/Zoom Camera
How would you implement different
components like kernel, drives, and
apps
Design goals
you want isolation between the kernel, drivers, and
applications
Sandbox execution of different components?
How would you implement something like this?
What are different ways of
implementing this?
Processes
High communication overhead
High overhead for switching processes on and off
Threads
substantial amount of sharing
minimal isolation
.Net provides Application domains to
implement this?
Somewhere in between process and threads
The common language infrastructure runs as a process
and the sub processes or applications runs within the CLI
process
Each application domain has a separate virtual address
space
Provides isolation
Exception in one domain does not affect other application
domain, each application domain are assigned different
access levels, and multiple threads can run in one domain
How would you implement ports
Use a framework called .Net Remote
There are two ways to pass Objects from one process to
the other
By object copying and passing object references
System.AddIn.AddIn Attributes provides a fairly complex
way of implementing the communication using a similar
idea.
App
domain 1
proxy
responsible for
marshalling/unmarshalling
App
domain 2
Implications to Garbage collection
Object passed across boundaries are garbage
collection
It is slower than garbage collection inside app domains
Each application domain has a separate virtual address
space
Programming Abstraction for
HomeHub
Drivers and Apps are modules
Extends ModuleBase class
provides four methods (start, stop, portregistered,
portderegistered)
Uses the System.AddIn.AddIn(“Appname”) attribute
Modules export services and can use service
Drivers and Apps therefore theoretically can export and
use services
Services are operations defined in roles associated with
ports
Input and output parameters of operations are of
ParamType
ParamType
Used for transferring data between modules
using
ParamType class has two fields
MainType: this can be an integer, image, sounds, txt
MainType can be simple of complex object
Value: captures the actual object
Example ParamType (maintype=image, value=byte[])
Helper Functions
Logger class
Generate log messages
When a module is instantiated, HomeOS passes a
pointer to the log object
Redirect messages to a log or stdout
logger.log();
SafeThread
Focusses on communication between modules
Example of Using SafeThread
Logic inside the thread
Parameter passed to the thread
Parameter passed to the thread
Writing Applications
Two main steps for writing applications
Discover Interesting ports
Building application logic
Example
(discovering and registering ports)
Port object
Gets all the ports that are registered with the HomeOS platform
This serves a dual purpose:
(1) callback when a new port is registered (2) determine ports of interest
Finding a port of interest
Making Role
calls to operations in roles
port
Synchronous invocation
Operations
arguments
Making calls to operations in roles
(Asynchronous)
Putting all of this together
lets see an example.
HomeOS apps + Web interface
.Net App
WCF framework
Web App
Use WCF (Windows Communication Foundation)
Allows communication between .Net and non-.Net entity
This is unlike .Net Remote that is between .Net modules
Web app is written in
HTML+Javascript
Web App
(html, index.html)
Invokes
Javascript functions
Calls made into
.NET application
How does WCF work
server
Javascript functions
interface
Service class that
implements the
interface
client
Interfaces define the contracts
contracts are the functionality that the server implements and
the client uses
has two attributes
[ServiceContract] – interface attribute
[OperationContract] – function attribute
[WebInvoke] --- function attribute stating that the function
would be invoked through Javascript/WCF Rest interface
Every HomeOS app has a index.html
<div class="dashboard_toolbar">
<div class="homeID_title"><a href="../GuiWeb/index.html">Dashboard</a> | Dummy
</div>
</div>
<div class="page">
<div class="row">
<div class="page_title col">Dummy Application</div>
</div>
<div><button class="app_button" id="Button1"
onclick="ShowDummyPortsInfo()">Update</button></div>
<textarea id="DummyList" class="app_form" rows="30" cols="50"
wrap="hard"></textarea>
<br />
The Javascript function
<script>
function ShowDummyPortsInfo() {
new
PlatformServiceHelper().MakeServiceCall("webapp/GetReceivedMessages", "",
GetReceivedMessagesCallback);
}
function GetReceivedMessagesCallback(context, result) {
var portsInfo = result.GetReceivedMessagesResult;
$("#DummyList").html('');
for (i = 0; i < result.GetReceivedMessagesResult.length; i++) {
$("#DummyList").append(portsInfo[i] + "<br />");
}
}
</script>
How to instantiate the service from
the server
Start the server service
DummyService dummyService = new DummyService(logger, this);
serviceHost = new SafeServiceHost(logger,typeof(IDummyContract), dummyService , this,
Constants.AjaxSuffix, moduleInfo.BaseURL());
serviceHost.Open();
string binarydir = moduleInfo.BinaryDir(); //directory of where the dlls and libraries are
string baseurl = moduleInfo.BaseURL(); // baseurl for the application
appServer = new WebFileServer(moduleInfo.BinaryDir(), moduleInfo.BaseURL(), logger);
Lets take a look at the
implementation of the service class
Writing Drivers
Five steps for writing applications
Instantiating Roles
Instantiating Ports
Binding roles to ports
Registering the port with the platform
Implementing functions for handling operation
invocations
Roles Data Structure
Base class: Role (Your role will extend Role)
e.g.: DummyRole:Role
Roles have Operation
Operation (name, arguments, returnvalue)
name: :dummy:->echo (Name, function name)
arguments, returnvalue of type ParamType
List<VParamType> args = new
List<VParamType>() { new ParamType(0) };
Writing Drivers (setting up Roles)
Writing Drivers (instantiating ports)
portInfo = GetPortInfoFromPlatform(name)
InitPort(portInfo)
BindRoles(port, RoleList)
Writing Drivers logic (synchronous)
Putting all of this together
lets see an example.
Scouts
Scouts are used for discovering devices
Discovers devices in the environment
Makes the core platform aware of the devices
User can query the platform for discovered devices
that are not part of the platform
Device setup is performed through HTML pages
Initial page enables setting up the configurations
What do Scouts do
Discover devices and report to the platform
Host the UI for custom device configuration
Hand over control to the platform by pointing to the
generic device addition page