The opnode concept

The OPNODE ("open node") project started some time ago when Alicia and me decided to return part of our experiences to the open community, having gathered lots of inputs from this community for years and having applied them into our professional projects. The building automation industry is something that I knew well and the home automation will always be one or my passions. On the other hand I've always considered the distributed systems a bit expensive for home applications. Thus, developing a set of low-cost open source controllers for building/home applications became the leitmotiv of this young project. The targets of this project have always been:

1. Define an automation system not only for the home but that could also be usable in buildings and the industry. Then, the system should be powerful and programmable.

2. The whole designs should be open source. I really believe in the open source philosophy, not only as a way of returning knowledge to the community but also as a business. Professional business I mean, not abusive business where a commercial company looks at the open source community only as a way of getting ideas and solutions. On the other hand, the open source formula allows the maintenance of big projects by independent enthusiasts, always following a collaborative criteria. I'll need some help on the development side soon and "open-sourcing" the project should open the door to anyone wanting to participate in the evolution of the project.

3. The controllers developed under this project should follow a distributed model. In other words:

3.1. Every controller should be capable of taking decisions by its own.

3.2. We need a multimaster communication technology in order to ensure the interoperability between devices. xAP not only covers this point but also allows the integration of any opnode in any existing xAP network, with the possibility of interacting with third-party devices. This protocol is in fact one of the key factors that make the opnode concept really open.

3.3. We should be able to define redundant tasks and secure procedures in order to guarantee the efficacy of our network.

4. Any opnode must be optimized in terms of power consumption. The choice of the hardware platform must be then justified in each case according to the role that the device will accomplish within the network.

5. The configuration and programming of any controller (or set of controllers) should be done via web. Besides, the web interface should provide a way of controlling/monitoring the endpoints managed by the device. This web interface will add some extra complexity to the developments but should finally provide a simple way of configuring and debugging our network from any location. The use of an external piece of software to program the system is then discarded.

The current status of the project, after the first year of life, is not bad I guess. Three high-configurable controllers, two of them focusing exclusively on control tasks and the third one targeting OEM applications:

opn-one

one-wire master with xAP and xPL interfaces.

opn-232

Ethernet-RS232 hardware platform aimed to integrate any RS232 device into the opnode (xAP) network. One available application at this moment: opn-x10.

opn-max

High-programmable xAP controller with Perl and PHP scripting.

The following schema shows the architecture of a typical distributed network following the opnode philosophy:



The above schema introduces some new concepts regarding the communication interfaces used in each case:

Orange network

This is the area where the field buses and low-end devices reside. The orange network is typically formed by low-power devices with no Ethernet interface. These devices communicate with a green-network node through a control-oriented technology.

Green network

Formed by high-end controllers communicating among them through xAP (or any other IP technology). Multimedia players, xAP controllers and gateways belong to this functional group.

Blue network

"Blue network" is a simple name given to the Internet connection of our system.

The architecture described in this article is not an invention of the opnode team. This architecture, where a TCP/IP network cohabits with control-oriented buses, is been widely used in the industry since long time ago. Control buses were specially conceived to transport control-oriented messages and the devices connected to these buses usually have lower requirements in terms of memory and power consumption. In summary, the orange network is totally oriented to the endpoint side. On the other hand, the TCP/IP network, much more capable in bandwidth but less oriented to control applications than field buses, is used as communication trunk and integration technology for all the high-end controllers.

I'm currently working some ideas about possible new opnodes. I still have to decide between a distributed music player system and a new multimaster control bus based on RS485. The important is not to stop I guess...