CURRENT ISSUE
Contests
Feature Article
|
|
Issue #204 July 2007
Pyxos Power
by Tom Cantrell
Start | LAN-In-the-Box |Down to the Wire | Variable Interest | Hook 'Em Danno |Build it and they will come | Match point | Sources and PDF
VARIABLE INTEREST
Another thing I like is the way Pyxos FT networks (like their LonWorks brethren) utilize a simple “publish and subscribe” model based on “Standard Network Variable Types” (aka SNVTs). With this data-driven approach, the only thing a Pyxos FT Point knows about, or needs to know about, is the collection of network variables (e.g., temperature, humidity, and light level) that are relevant to its specific purpose. A particular Point is defined by those network variables it has interest in (i.e., inputs) and/or those it has the duty to provide (i.e., outputs). The Point will receive a message from the Pilot that includes input variable updates. The Point will send a message to the Pilot when an output variable needs updating. Simple, just the way I like it.
Here’s where the Point/Pilot asymmetry really pays off. For Points, life is easy since they need to do little more than wait for input updates to appear, and/or fire and forget output updates (see Table 2). That leaves plenty of cycles for a Point MCU to handle the local application or for that matter, just sleep a lot.
By contrast, it’s the Pilot that has to keep track of all the network variables in the system, figure out where updates should go, and make sure they get there in a timely fashion. Furthermore, the Pilot is responsible for monitoring the health of the system and intervening if necessary (e.g., resetting or hot-swapping a crashed Point). Finally, the Pilot needs to be able to handle the aggregate peak network bandwidth while Points need only the horsepower necessary to deal with their own contribution.
|
