590ES 1

Design of Plant Care System

Mike SwiftSteve Swanson

Stefan Bjarni Sigurdsson

590ES 2

Scenario

• You buy a plant• You buy an automatic watering /

feeding system• You buy automatic plant lights• You buy plant monitoring system• You subscribe to www.burpee.com• You want this all to work together

590ES 3

Design Principles

• Components to system:– Base objects: hardware devices with

software interfaces• Sensors• Actuators

– Services– Service Manager– Data store

590ES 4

Base objects:

• Sensors (a hardware device)– Occasionally produces a measurement– Knows how to talk to store, or has a wrapper– If sensor can be controlled, it has an actuator

to control it• Poke it to make a measurement• Schedule future measurements

• Actuators (also a hardware device)– Make something happen– Knows how to receive commands, or has a

wrapper

590ES 5

Base Objects

• Description of component is downloaded from a URL– What is the interface used?– What is the precision / characteristics?– What are the measurement units?– What is the class of device (e.g.

temperature / moisture / sound / light / plant )

590ES 6

Services

• Services are software• They can provide simple services:

– Data aggregation / interpretation• Average temperature• dTemp/dt – temperature change

– Actuator aggregation• Lighting a whole area• Thermostat

– Publishing information from one data store to another

590ES 7

Services (2)

• They can provide high level functionality– Read from sensors / write to actuators– Access outside information sources– Example:

• Plant care system

590ES 8

Service Management

• The Service manager is responsible for:– Discovery– Adding services (join)– Binding: creating communication channels

between services– Dependency management for service

invocation– Authentication of services

• May store services in a tuple space

590ES 9

Data Store

• Shared data is kept in the store• Store contains XML documents with:

– Type information– Creator information

• The store can remember everything• The store implements access control• There is a 1-1 relationship with

service managers.

590ES 10

Data Store (2)

• There may be multiple data stores– One per room– One per apartment

• Data stores may be aggregated • Services may publish information

upwards– Has to be an explicit choice to release

information– May only release aggregated information

• E.g. daily average temperature, not instantaneous temp.

590ES 11

Data Store (3)

• Store may generate events– Notify services that a condition has

occurred• New services available• Existing services failed• New data available

590ES 12

Assumptions

• Everything communicates through interfaces or data sets

• There exists standards for common concepts, such as:– Location– Temperature– Time– precision

590ES 13

Step by Step

• Data store and service manager are already installed

• Devices are brought into house– Acquire network address (DHCP?)– Register with service manager

• Send URL & UID to service manager• Description downloaded from net• May periodically send aliveness information, or

respond to probes

– Sensors may start producing data immediately

590ES 14

Step by step (2)

• Customer purchases service from www.burpee.com

• Service is registered in service manager– Queries for components related to

plants– Download additional services needed

for operation• Eg: thermostat services

590ES 15

Service Installation

• Services register dependencies in service manager– What other services are needed?

• E.g. aggregator service for a particular sensor / set of sensors

– Each service that is depended on registers its dependencies• If measurements are needed, a service

may need to schedule an actuator to force a measurement

590ES 16

Service Installation (2)

• What if dependencies can’t be satisfied?– Reduce quality of service:

• Reduce precision• Reduce service

– Don’t water plants– Don’t adjust lighting– Don’t monitor plants individually

590ES 17

Operation

• Sensors periodically make measurements

• Aggregator services are notified by the data store of new data and convert data to more abstract information

• High level service polls / is notified of high-level information, makes a decision

• Propagates action to actuators

590ES 18

Fault Tolerance

• An aggregator service may hide the fault of a low level sensor– Aggregate around the missing data– Change precision of measurements

• Decreased location accuracy• Decreased time accuracy• Decreased value accuracy

• If fault is not recoverable, log to error log– Error handling service monitors error log,

determines what can be fixed– Pass up to next dependent service

590ES 19

Security

• Security depends on authentication• Authentication depends on consensus

knowledge– Secret key (on bar code?)– Public key/private key pair– Location

• Local devices are not on internet – they go through a proxy/firewall/intermediary

• All local communication is encrypted to prevent wiretaps

590ES 20

Security (2)

• User has to make some decisions– www.burpee.com is allowed to access

plant data– Needs policy specifications for class

of devices / usage• E.g. plant care• Climate control

– Or, allow user prompt for each service (not)

590ES 21

Security (3)

• Information in data store is purely local– Not accessible from WWW– Local services may upload

information to WWW – Any other info must be explicitly

published

590ES 22

Service Conflicts

• May have two services with conflicting commands– E.g. two plants near each other with conflicting

temperature needs

• There can be several resolution methods– Average the commands– Prioritize the commands

• E.g. fire sprinkler takes precedence over cactus

– Time division multiplexing– Propagate conflict up, let higher level service

change policies

590ES 23

Diagram

Data Store Service Mgr.

Temp Moist Bright Heater Water Food

Plant Care

Avg. Temp

Set Moist

590ES 24

Diagram Explained

• Dotted lines show virtual communication

• Triangles are sensors• Lightning is actuators• Ovals are services• Arrows show information flow

– From sensors– To actuators