Most devices are designed to operate independently, generally with a single point of control. Controls are either integrated into the product, or a single remote panel is provided. Multiplexing demands certain provisions to allow every node to be controlled from multiple sources.
All nodes fit into one of three categories:
* Conventional components such as sensors, lights, gensets, slide rooms that are monitored and controlled,
* User interface items such as control panels and switches, and
* Embedded intelligences, such as thermostats and genstart modules, that automate and control other nodes.
Many products encapsulate more than one type. For example, a thermostat may embody both a temperature sensor and a heating control. But it should be noted that logically the “intelligence” that determines when the furnace is turned on could be implemented in a wall thermostat, in the furnace itself, or in some other module. This fact has important implications.
A node should be as simple as possible – but no simpler! For example, although when designing a furnace, it may seem wise to integrate a thermostat logic into the furnace, that may be a mistake. At least, it is extremely important that the thermostat feature can be disabled. The RV designer may intend to use a different thermostat control, perhaps with additional features that the furnace designer could not anticipate. The furnace must be able to operate as just a furnace – something that turns off and on upon command.
A well-designed node is autonomous – self-sufficient for its general operation. Conventional products often store their configuration information in their control panel – this is a problem in a multiplexed environment which may have several (or no) control panels. Whatever configuration information a node needs should be contained in its own non-volatile memory. It should not assume any other node is on-line, except whatever is absolutely necessary for its operation.
Of course, some products naturally require others to be installed. For example, a thermostat is useless without a furnace and/or air conditioner. In such cases, it is important that the product fails “gracefully” if the other node is taken off-line. A furnace, for example, should probably turn off if no thermostat is present. Sometimes this is a safety issue – mechanical products especially require proper programming. In some cases this means a mechanical override should be provided for emergency use.
The autonomy principle also means that certain safety features always be integrated into the product. For example, most generators shut down when their coolant gets too hot. Although it is possible to implement this feature through a remote controller, it would be a serious mistake. Fundamental safety and self-preservation features should remain integrated into the product.
An important point to remember: if some other device commands your node to perform an unsafe or self-destructive action consider that it is your node's fault if it obeys! For example, if a slide room is extended while the coach is in motion, it is the fault of the slide room for failing to check the chassis status. Do not expect every other manufacturer to understand all the safety issues associated with your product and to properly implement the solutions.