There is a lot of stuff around, but nobody has stated goals very similar
to ours. The main problem seem to be that most designers think too
narrowly; what I feel we have been talking about is a general networking
system that scales down well to very small devices, but can also do
proper routing when needed for our goals of distribution and reliability.
At the opposite extreme is CEBus. It is very general and has a lot
of good ideas, but it soon becomes clear reading the gigantic (300+
page) spec (http://www.cebus.org/hpnp/778899) that this is classic
design-by-committee. It is vastly complicated, and you can clearly see
the joins between differently-authored sections.
Their layered approach is the standard and sensible way to build a
network stack and the idea of ``contexts'' is a nice way to provide
inter-operability of components. But instead of describing the simple
building blocks first and then showing how they join up, it goes on
about house contexts, instance variables, state vectors and umpteen
sorts of addressing modes with exceptions, special cases and complicated
state transition rules. Even now that I have finally understood roughly
what's going on and reduced it to the essentials, it all seems much more
complicated than necessary and I certainly can't imagine fitting it all
in a PIC!
Nevertheless, I do recommend wading through the CEBus spec because they
have thought in some detail about some interesting aspects of inter-device
communication, like synchronization or time, race conditions when setting
a state, and coping with conflicting goal priorities. And clearly
separating the data transport levels from the application layer makes
the design much clearer.
So, let me have a go at summarising CEBus in my own words. I'll gloss
over lots of details, but if I have anything omitted something crucial
or got it wildly wrong, please correct me:-)
There are five main applications: lighting, time, security, environment,
appliances, audio and computer. Each of these has a set of ``contexts''
which specify what sort of data exist and pass around the network.
A context is a collection of ``instance variables'' (IVs) together with
the rules that can alter them. An instance variable is a single datum
like a temperature reading or a switch output. Messages are either
``requests'' to change an IV, or ``reports'' that an IV has changed.
Devices implement the appropriate context(s) for their particular
function. Contexts are generally arranged so that they pair up nicely;
usually the report coming out of one device can be plugged directly in as
a request to another device. A ``macro'' defines the more complicated
interactions and specifies state transitions caused by message arrival
and timeouts.
Devices communicate over a virtual bus, which may be implemented as a
collection of disjoint segments coupled by ``routers'' and ``brouters'' (I
don't know what the difference is). The physical layer is not specified
in detail, but is assumed to pass data packets unreliably in a broadcast
fashion. Most traffic is unacknowledged. Although devices potentially
get to see all packets, they only respond to those packets addressed
to them. Addressing is selective on five levels: system address,
unit address, context index (if there are several instances of the same
context in a device) context type and unique serial number. The first
four can be wildcarded in various ways (straightforward broadcast, or
some sort of grouping). I think that serial numbers are only used during
set-up to allocate unique unit addresses. Manufacturers are expected
to give each device a different serial number; to ensure uniqueness,
each manufacture has their own code, for which they have to pay unless
they already have a DoD number.
Lighting has switches and dimmers, which can ramp to a specifed level
in a specified time, and a complicated concept called ``scenes'' which
just seems to be a way of setting presets for several lights at once.
Time is categorised by accuracy or source, so devices can choose the
best sort of time or their needs. There is a distinction between
internal (e.g. local quartz) time and external (e.g. radio receiver)
time so manual setting of one device can be made to work sensibly
in a mixed network.
Security specifies many sorts of alarm and ``trouble'' (failure)
conditions. The alarm system has only a few basic modes and I'm not
sure how zoning is achieved. Some devices transmit heartbeat messages
whose absence can be noted and used to trigger trouble indications.
There is a concept of a ``trusted key'' for a whole house, which can b
used to verify requests and encrypt packets. Some requests must also
be accompanied by a ``pass code'', entered by a user.
Environment and appliances have lots of complexity to do with load
monitoring (of gas, electricity and water demand) and knowledge of
time-based charging.
Audio equipment and computer data are also mentioned but there doesn't
seem to be much detail on either of these. The computer stuff allows
devices to request mass storage and print things.
There is a section on how to implement a standard user interface with
only one LED and one button. This is the only part that makes any mention
of how one might go about connecting up all the devices in a useful way.
On the whole, the design of contexts is such that pairs of devices just
have to be linked together and they do the right thing. Devices can
potentially do arbitrarily complicated things by registering all manner
of contexts and thus participating in all manner of transactions.
But actually implementing such a device would be very hard.
All in all, there are some good bits, but it is far too complex.
Robin.
-- R.M.O'Leary <robin.at.acm.org> +44 7010 707044 PO Box 20, Swansea SA2 8YB, UK