|Network as Platform: Cisco Developer Contest|
|By David Adams on 2009-09-30 18:03:19|
|Cisco recently announced the finalists in its "Think Inside the Box" Developer Contest. The contest is intended to "promote the concept of the network as a platform" and it's based on the capabilities of the Cisco Integrated Services Router Application Extension Platform (AXP), which is essentially a Linux blade that plugs into the Cisco Integrated Services Router. Teams from all over the world entered the contest, and seemed to really run with the idea of offloading tasks to the network hardware. Read on for our interview with one of the contest's finalists.
I reviewed the finalists' projects, which included a tool for managing call processing and one enabling management of ads deployed through LCD screens in retail stores. But since I've been on a building automation kick lately, I was particularly interested in MADNetwork's project, which dealt with monitoring and managing building systems (HVAC, lighting, plumbing, presence, fire, flooding, and smoke detectors) of branch locations from a central office. AXP is useful in this case because it obviates the need for dedicated monitoring hardware aside from the already-existing network hardware. We interviewed David Perez, from team MADNetwork.
OSNews: What made you choose this project? Do you have experience with trying to remotely manage building systems?
MADNetwork: When I read about the "Think inside the box" contest, I considered two alternatives: 1) developing a proposal in a field I wasn't an expert, but that could be more "in fashion", or 2) developing in a field that I knew well. I've been studying and developing in the building automation field for some years now, so I chose option 2, although HVAC or plumbing could sound not so high tech at first. I have never developed a commercial and serious solution. My work in this field has been mainly constrained to theory and very limited prototypes, and some demos for X10.
OSNews: Obviously, you see a need for managing building systems remotely, and you think that the Cisco AXP would be a good platform to use for that. What kind of platform are people currently using to manage these kinds of systems today.
MADNetwork: There are different managers, mainly proprietary, offered by the same manufacturers of the devices or associations that define the building automation protocols. Many of them are now defining an IP interface, being the web access a trend that I don't see really useful for managing a high number of branch offices. Most of them (few exceptions) are run on a PC with Windows.
OSNews: Do you think this has any applications in a residential setting? How long do you think it would be before this kind of system could be deployed with in a low-cost residential router, like a Linksys?
MADNetwork: Yes, I see it very practical in a residential setting. Not only in condominiums or apartment buildings (where it could help the owners to control each apartment in a centralized way), but in houses, where it can help owners/residents control or monitor their houses from inside the house or via the Internet or their smart phones.
There are currently some solutions that run on very low-cost routers, but they are still very do-it-yourself, and you need to know about Linux and how to install a package. Probably when the network providers start deploying more sophisticated home gateways in which they (or other service providers) can install and maintain applications, we'll see that these solutions become more popular. However, they will need to demonstrate they are useful and have a real value and are not just an entertainment.
OSNews: I think this would be a great first step for localities that are trying to promote smarter commercial and residential buildings in order to conserve energy. Do you have any ideas on how much energy something like this could save?
MADNetwork: In these systems, high savings in energy can be achieved without a remote control; only by associating presence detectors to lighting or controlling the temperature with more resolution, for example, energy consumption may be reduced. Studies in the European Union have estimated that savings in energy could be around 20%. I estimate that adding a remote control system like the one I have proposed could increase this saving in a small percentage. This solution can provide other savings to the companies by alerting about breakdowns in any branch office in a really short time, reducing the cost of the failure.
OSNews: Would any inputs or outputs need to be added to the network hardware to facilitate implementing your ideas?
MADNetwork: Currently, the building automation systems that I have implemented the control code for can be accessed via a serial or an Ethernet port, which are provided by dedicated devices (gateways), so no additional hardware is really necessary for implementing this solution. However, these gateways can add some hundreds of dollars to the bill of the deployment, so I estimate that designing hardware for the AXP that implement these gateways could result not only in cheaper deployments, but in less devices in the branch office.
OSNews: Would integrating emergency systems like fire alarms or security systems in with networking systems introduce any new availability or security challenges? Is the router hardware as reliable as standalone security systems, for example?
MADNetwork: I don't know about the USA, but in Spain, the conditions that a security system has to fulfill are very strict, and include using different resources than the data network (for example), so a certified security system couldn't be implemented in the data network. However, if you plan to deploy your own security solution the AXP+ISR is a very good solution. If communications of the branch office rely in the AXP, this sort of security solutions could rely in it too.
OSNews: Can you give us some details on how it was to develop for the AXP platform?
MADNetwork: Well, the coding was done on a Linux box, where source Java files were compiled to classes. At the beginning I had to build a package to install in the AXP every time I had a new version for testing. This was a longer-than-desired process, so I found a shortcut: once I gained access to the Linux shell in the AXP, I could load new versions of the application in the AXP by FTPing the .class files into the corresponding AXP directories. This way the development cycle was dramatically shortened. Once I got to this solution, developing-testing became a very fluent process.