External links

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:

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.

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.

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

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

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.

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

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.

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 two years of life, is not bad at all. 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-max

High-programmable xAP controller with Perl and PHP scripting.

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.

Besides, a set of sensors and actuators is currently being developed so that the family is going to increase shortly.

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...