Transcript SW architecture

Mobile and Wireless Computing
CITS4419
Week 6: Software Architecture
Rachel Cardell-Oliver
2014
Software architectures for
co-ordinating Sensing and Actuation
in Smart Homes
Smart Homes (Pilich 2004)
• Controllable
– Integrated remote control
– Interconnected devices
– Voice, gesture or movement control
• Programmable
– Reacting to time and simple sensor inputs
– Assessing and recognising situations
• Intelligent
– Learns repeated actions and reacts automatically
SOFTWARE ARCHITECTURE
What is Software Architecture
• Process of defining a structured SW solution to
given technical and operational requirements
• Optimises common quality attributes
(performance, security, manageabilty)
• A series of decisions
• “the decisions that are hard to change” [Fowler]
• Further reading: http://msdn.microsoft.com/en-us/library/ee658098.aspx
Software Components
Source: http://msdn.microsoft.com/en-us/library/ee658124.aspx
SW Architectures for Smart Homes
• Client/Server
– System comprises 2 applications: client(s) makes
requests to a server (2-Tier architecture)
• Service-Oriented (SOA)
– Applications expose and consume functionality as
loosely-coupled services that use contracts and
messages
• Component Based / Resource Oriented (ROA)
– Reusable functional/logical components expose welldefined communication interfaces
Client / Server
•
•
•
•
•
1 or more clients send requests to a server
Server listens for requests and responds
Example: desktop UI and database server
Processing can be client-side or server-side
PRO: simple maintenance, high security of data,
central data management
• CON: one point of failure, close coupling of
application data and business server = poor
extensibility
• 3-Tier and N-Tier client server can be used to improve
extensibility and reliability
Service Oriented (SOA)
• SW components provide application functions as services to
other systems.
• A service is a distinct, self-contained function such as
submitting, changing or retrieving data.
• Protocols define how services exchange data.
• For the web, XML is used to describe data and metadata,
• Web service description language (WSDL) for defining
services, and
• Simple Object Access Protocol (SOAP) as comms protocol
• Services are combined to build large ad hoc applications
• PROS: domain alignment, abstraction, discoverable,
interoperable, removes duplication
• CONS: data overhead
Resource Oriented (ROA)
ROA supports internetworking of resources
Resource = anything important enough to be referenced as a thing itself
Resource name
= unique identification of the resource (uniform resource identifier (URI))
Resource representation
= useful information about the current state of a resource
Resource link
= link to another representation of the same or another resource
Resource interface
= uniform interface for accessing the resource and manipulating its state
In a ROA each device has its own URI, HTTP GET requests query its state and
POST request sets a value.
Fielding, R.T., Architectural Styles and the Design of Network-based Software Architectures, Ph.D. dissertation, in University of
California, Irvine. 2000.
Leonard Richardson, S.R., RESTFul Web Services. 2007: O'Reilly.
http://inspire.ec.europa.eu/rports/ImplementingRules/network/Resource_orientated_architecture_and_REST.pdf
SOA vs ROA for smart homes
• Bovet [2007] argues:
• Since, large overhead of XML and
• complexity of the service description language
WSDL,
• So, Service-Oriented arch (and its SOAP
protocol) is not well suited for sensor/actuator
things
• But, resource oriented architecture (ROA)
offers new ways for accessing things
Incorporating Low Power Sensors
ROA is not suitable for energy harvesting (really low power)
sensors and actuators such as enocean
Solution:
1. gateway listens to sensor telegrams and saves info (values
and ids) which are used to respond to get requests
2. actuators can not be discovered so their name is filled by
user, and then actuation telegrams can be sent using data
from POST requests.
3. One solution is for a bridge to brokers enocean requests,
but this does become a single point of failure.
4. They propose a hybrid mode in which both gateway and
sensors know about actuators and can drive them
SERVER EXAMPLES
FHEM http://fhem.de/
• FHEM is an open source PERL web server
designed for home automation
• Users can control the program via the web,
smartphones, telnets or TCP/IP
• In addition, the project offers various contributed
front end user interfaces and back end protocols
and modules for many proprietary sensor
protocols including enocean, Zwave, KNX.
• It supports house automation devices,
audio/video devices, weather services, online
calendars and more.
Lighttpd http://www.lighttpd.net/
• Lighttpd is a lightweight webserver with a small
memory footprint compared to other webservers.
• It can easily be setup to serve PHP websites.
• It is more suitable than Apache for Raspberry Pis,
since Apache can use up to 30% of the Pis
resources in idle mode
• Source: http://www.scandio.de/2012/11/setting-up-alightweight-webserver-with-lighttpd-php5-and-sqlite3/
Python http.server
• Python 2 supports SimpleHTTPServer
• In Python 3 see http.server
• On the Raspberry Pi, call python3 for version 3
and just python for version 2.7.x
• To use the web server, use one of the following
• python3 -m http.server 8000
• python -m http.server 8000 --bind 127.0.0.1
• python -m SimpleHTTPServer 8000
COMMUNICATION PROTOCOLS
MQTT
• MQTT stands for MQ Telemetry Transport. It is a
publish/subscribe, extremely simple and
lightweight messaging protocol, designed for
constrained devices and low-bandwidth, highlatency or unreliable networks.
• http://mqtt.org/faq
• http://www.sigfox.com/static/media/Files/Docu
mentation/SIGFOX_Whitepaper.pdf
• There is a python library Mosquitto for MQTT
that can be used with Raspberry pi.
• http://mosquitto.org/documentation/python/
Zigbee
•
•
•
ZigBee is used in applications that require only a low data rate, long battery life,
and secure networking. ZigBee has a defined rate of 250 kbit/s, best suited for
periodic or intermittent data or a single signal transmission from a sensor or input
device. Applications include wireless light switches, electrical meters with inhome-displays, traffic management systems, and other consumer and industrial
equipment that requires short-range wireless transfer of data at relatively low
rates.
Zigbee is for personal area networks built from small, low-power digital radios.
ZigBee is based on an IEEE 802.15 standard. Though low-powered, ZigBee devices
can transmit data over long distances by passing data through intermediate
devices to reach more distant ones, creating a mesh network
As one of its defining features, ZigBee provides facilities for carrying out secure
communications, protecting establishment and transport of cryptographic keys,
cyphering frames and controlling devices. It builds on the basic security framework
defined in IEEE 802.15.4. This part of the architecture relies on the correct
management of symmetric keys and the correct implementation of methods and
security policies.
Z-Wave
http://en.wikipedia.org/wiki/Z-Wave
• Z-Wave is one of the most popular home automation protocols
• Supported by the Z-wave alliance of 250 technology companies.
• Lots of products: sensors, lighting switches and dimmers, thermostats and
radiator valve actuators, alarms
• Z-wave creates a mesh network, with low power radio protocol designed
for remote control applications
• Optimised for reliable, low-latency communication of small data packets
with data rates up to 100kbit/s.
• Unlike Wi-Fi and other IEEE 802.11-based wireless LAN systems that are
designed primarily for high-bandwidth data flow, Z-Wave operates in the
sub-gigahertz frequency range, around 900 MHz.
• Z-wave mesh network can contain up to 232 nodes: control and slave
devices, which can use multi path up to 4 hops to relay messages.
• Security includes encryption, authentication and key exchange protocols.
EnOcean
• EnOcean self-powering sensors come with
their own proprietary ultra-low-power
protocol
• Devices publish data telegrams
• Packets only 14 bytes long, trans. 125 kbit/s
• RF only tx for 1s (saves energy on 0s)
• Devices at 902, 928.35, 868.3, 315 MHz
6LoWPAN and COAP
6LoWPAN (IPv6 over low power wireless personal area networks)
IPv6 packets sent over IEEE 902.15.4 networks for limited form factor devices
(sensors and actuators)
Compressed headers, low data rate, IETF working group
Constrained Application Protocol CoAP is a draft internet standard IETF for
constrained devices
Application layer protocol, multi-cast, designed to translate to HHTP
URI and content support, resource discovery, requests and responses
CoAP for the Web of Things: From Tiny Resource-constrained Devices to the Web Browser, M. Kovatsch, WoT 2013: Fourth
International Workshop on the Web of Things, http://dx.doi.org/10.1145/2494091.2497583
Shelby, Z., Hartke, K., and Bormann, C. Constrained Application Protocol (CoAP). I-D: draft-ietf-core-coap-17, 2013
FURTHER READING
Universal Remote Console
• URC standard for devices that can be used
remotely.
• Remote devices = “controller”
• Controlled device = “target”
• Controller presents a user interface for the
target
• FHEM
Zero-Configuration Networking
• Automatic discovery of devices on a local
network
• Publish and Discover TCP/IP services
• Apple implementation Bonjour, See also
Windows version