BSC - Distributed intelligence DRAFT

[mark_harrison_uk2]

Guys,

Thanks for all your input on this subject over the weekend. Please
find attached a write-up of the various discussions I had.

It's actually harder to write up than it is to implement, so there is
a bit of reading involved :-)

Mark

-----------------------------------------

BACKGROUND

BSC (Basic Status and Control) has proved a robust method of allowing
different devices with basic (digital I/O, lighting level)
functionality to communicate. While some of these devices are PC
applications, these devices are typically characterised by relatively
low computing power.

One of the long-term design goals of xAP has been to provide a
mechanism for distributed processing, and the BSC specification has
proved a very solid foundation to this.

BSC Mapper has likewise proved a solid, simple, tool for allowing BSC
endpoints to be "connected." (So that if endpoints 1 and 2 are
"connected", as soon as endpoint 1 changes, and raises a
bscstatus.event message, BSC mapper will raise a bsccmd.state message
to change endpoint 2 to the same value.)

Associations can be created with wildcards on the input side, so that
an endpoint can be changed to the "latest value" of ANY of a set
of
inputs. (This might be useful to allow an alarm to turn on if any of a
set of triggers went high.) Wildcards are NOT allowed on the "output
side" of the association.


REMOTE PROCESSING

This schema - "BSC Associations" - provides an optional extension
to
BSC devices to allow them to "take responsibility" for
implementing
this association.

There are six schema / classes. Given the relative low power of BSC
devices, the first three take only a single body part as an input.

- assoc.create
- assoc.delete
- assoc.created
- assoc.deleted
- assoc.query
- assoc.status


The general principle is that a high-end controller, such as BSC
mapper will try to create an association as follows:

- Send an assoc.create message TARGETted at the endpoint that is meant
to react

- If the endpoint confirms that it can react by sending back and
assoc.created message, then simply log the association, but flag it
for "remote processing" intenally.

- If no confirmation is received, then take responsibility for sending
an appropriate xapcmd.state message TARGETted at the output whenever a
xapstatus.event message comes in matching a rule input.

- If an association is deleted, and the association is flagged for
remote processing, then send an assoc.delete message (which is
acknowledge by a assoc.deleted) message.

- Assoc.status messages are larger, containing multiple body parts,
and are send by devices to report their entire association table
(either in response to request, or optionally periodically.)

- Assoc.query messages are TARGETted at a specific device, and contain
a dummy body part, and are used to query remote configurations.


CREATING ASSOCIATIONS

Rather than use abstact terms, I will use a specific example - A user
wants to set barionet.myhouse:output.1 to go high-low to match
homevision.myhouse:flag.3

The barionet software supports both BSC and BSC Associations.

1.1: The user selects homevision.myhouse:flag.3 in the "left hand -
input side" of BSC Mapper (or other tool)

1.2: The user selects barionet.myhouse:output.1 in the "right hand -
output side" of BSC Mapper (or other tool)

1.3: The user clicks the "create association" button in BSC
Mapper

1.4: BSC mapper displays the association in the lower part of the
screen (in a normal font)

1.5: BSC mapper sends a message as follows

- SOURCE: bscmapper.myhouse
- TARGET: barionet.myhouse:output.1
- CLASS: assoc.create

- Assoc.create
- {
- trigger=homevision.myhouse:flag.3
- }

It is important to note that the trigger MAY contain wildcards.

(Note that there is no need to repeat the output.1 in the body, since
this is in the xAP header)

1.6: BarioNet sends a message as follows

- SOURCE: barionet.myhouse:output.1
- UID: (to match, including UID mapping of endpoint)
- CLASS: assoc.created

- Assoc.created
- {
- trigger=homevision.myhouse:flag.3
- }

(Once again, there is no need to repeat the output.1 in the body,
since this is in the xAP header.)

If the trigger contains wildcards, then the device should only
acknowledge if it can support such wildcarding.

1.7: At this point, BSC mapper "greys out" visually the
connection to
show that it is being processed remotely. From then on, it does NOT
send out a xapcmd.state message in response to a xapstatus.event
message matching that rule, since there is no need.


1.8: From then on, output.1 on the Barionet will be sent to match
whatever flag.3 on the Homevision is. This will, obviously, be
triggered by a xapstatus.event message. (However, it is good practice
to check the values of any xapstatus.info messages in case the state
tables have slipped out of alignment.)

Obviously, if this causes the output.1 to change, then output.1 will
raise a xapstatus.event message in the normal way. It is good practice
to send a xapstatus.info message if a pattern is matched, even if
there is no change.


DELETING ASSOCIATIONS

2.1: To delete an association, BSC Mapper sends:

- SOURCE: bscmapper.myhouse
- TARGET: barionet.myhouse:output.1
- CLASS: assoc.delete

- Assoc.delete
- {
- trigger=homevision.myhouse:flag.3
- }

2.2: ... which is confirmed by:

- SOURCE: barionet.myhouse:output.1
- UID: (to match, including UID mapping of endpoint)
- CLASS: assoc.deleted

- Assoc.deleted
- {
- trigger=homevision.myhouse:flag.3
- }


QUERYING ASSOCIATIONS

It is best practice to target queries at a specific endpoint. If a
query is sent wildcarded, then EACH endpoint should send back a
SEPARATE xAP message in response with its own configuration.

3.1: A device is queried by a message like the following. (The name of
the body part is ignored - it is included because xAP requires there
to be at least one.)

- SOURCE: bscmapper.myhouse
- TARGET: barionet.myhouse:output.1
- CLASS: assoc.query

- dummy.body
- {
- }

3.2: ... and the response is along the lines of:

- SOURCE: barionet.myhouse:output.1
- CLASS: assoc.status

- assoc.1
- {
- trigger1=homevision.myhouse:flag.3
- }

There are multiple body parts, one for each match, numbered
consecutively starting at 1