Logical Approach To Home Automation
Logical Approach To Home Automation
Logical Approach To Home Automation
We shall now describe the operation of a few devices \subsubsection{Some Push Logic Semantics}
in the automated home to outline the types of rules in Push Logic interacts with pebbles by monitoring and
operation. To facilitate understanding, we shall use changing fields held inside a pebble. Pebbles also
standard logic symbols. Details of the semantics and monitor and change these fields. When a pebble
syntax of Push Logic for doing the same can be found changes a field, we call this a ‘unilateral’ change. For
in ~\cite{Semantics paper DJG}. example, a keypad pebble will make a unilateral
change to one of its fields when a user presses a button.
Figure 2 [\emph{the big diagram}] is a schematic Equally, a local timer pebble will make a unilateral
embodying common home devices such as alarm change to a field as it expires. Push Logic object rules
clock, heating control, TV, etc. It shows a mobile [define source and object] are predicates over subsets
phone commanding heating control and the front door of the fields in a domain of participation and have three
lock through an SMS pebble. An alarm clock is forms: executable, liveness and safety.
controlling a DVD player, heating control, and a
curtain opening mechanism. The fire alarm controller Safety:
is responsible for generating a fire alarm through
klaxons in case smoke is detected by a smoke sensor 2
A field is a scalar variable name in a global namespace. Our Push
pebble. It also takes inputs from a timer and general- Logic implementation is part of a distributed tuple space platform
purpose keypads installed at various locations in the and hence variables are called fields.
klaxon pebbles that ensures that a klaxon will sound if
S ( q ) true any klaxon in its local domain is sounding:
[GIVE EXAMPLE]
$# sounding : $domain# klaxons# sounding
where S is the safety predicate.
The domain was set up by the rehydration stage when
Executable:} [not clear] the klaxon first switched on.
Liveness and safety rules are assertions to be checked if ($domain# firealarm # muted )
by a model checker invoked by the loader (the model $ domain# klaxons# sounding
checker can be run as a network service or as a process
on the target execution platform). The combination of Imagine that the user forgets to reset the fire alarm and
the current bundle and all other rules in the domain of there is another fire—there will be no alarm now as the
participation is model checked. If all assertions still klaxons are still muted. To avoid this hazard, we can
hold, then the new bundle is acceptable to the domain use a timer to clear the mute after, say, twenty minutes
and becomes part of it. Execution of its executable if a fire is detected.
rules is then allowed. Normally, one bundle is loaded
onto one bytecode interpreter (execution platform) for if ( dom ain #
tim e # fi r
fir
ealar
execution, but it could potentially be split over several if (tim e # fireal ar
if required rule associations that use local field names $ domai n # fire
SMS Pebble:[CHECK]
If we receive an SMS message on our mobile phone
that a fire alarm is sounding but [WHAT
SCENARIO?]…
if ( self .msg :' MuteFireAlarm' )
$domain# firealarm # muted 1
\section {Conclusions}
[to be written]+[enhance references]
\begin{thebibliography}{99}
\bibitem{goalspaper}`A Case for Goal-oriented
Programming Semantics' in System Support for
Ubiquitous Computing Workshop at the Fifth Annual
Conference on Ubiquitous Computing (UbiComp '03).
Umar Saif, Hubert Pham, Justin Mazzola Paluska,
Jason Waterman, Chris Terman, Steve Ward.
http://www.cag.lcs.mit.edu/~umar/publications/ubisys.
pdf
http://o2s.csail.mit.edu/goals.html
\end{thebibliography}