Eric Gnoske and Colin O’FlynnColorado Micro Devices

Who is Colorado Micro Devices?

Colorado Micro Devices makes small radio devices called RadioBlocks. The RadioBlock integrates a microcontroller, radio chip, and antenna all into a single device. This doesn’t sound very exciting and there are many vendors of such devices. But unlike almost all other vendors, the firmware which makes our modules useful is open source, allowing modifications as you see fit.

CMD and the IPSO Challenge

The IPSO CHALLENGE 2013 was a chance to showcase a product using smart objects. Our fundamental products (the RadioBlocks) are sold to developers, and not end customers. We created an example product which an end customer could use called the “CMD Asset Management” system, which also uses our radio devices. CMD Asset Management is designed to monitor assets in a commercial environment, and report back state changes. “State Changes” depends on the asset – it could simply be that the asset is outside of radio range, it could be an accelerometer detecting movement of the asset, or it could be a specific sensor monitoring some state of the asset. For the last example we created a sensor package that monitors the state of a door lock, but does so by simply being inserted into the door jamb. This physically detects the dead bolt being locked, requiring almost no modification to existing environments. Since it’s detecting the dead bolt state, it can let you know if someone left a door closed but unlocked, something typical security systems cannot tell you. Simple, but invaluable!

Standardize This!

The idea of wireless smart objects isn’t new technology – carrier pigeons could even be seen as predecessors to our current mobile nodes! But what made the IPSO CHALLENGE interesting was its focus on the use of standards for making your network, and eschewing proprietary protocols.

Proprietary protocols often seem to evolve in engineering projects, part of the “Not Invented Here” culture of engineers. Engineers see short-falls with the current way things are done, and can make a better system. Unfortunately these “improved” systems often won’t work with each other. Even with IP-based systems one may still run into proprietary blocks. The network could be using some open standard like CoAP, but it relies on closed-source front-end software for controlling the devices. Sure the protocol is open, but the parameters you need to specify around its use are unavailable. In such a case you ultimately are not doing much better than the proprietary case – you are still locked into a single vendor, despite the fact they are touting their use of “open IP standards”.

CMD Asset Trackers use of Standards

For our design, we aimed at maximizing the use of existing technology, especially open-source programs and open protocols. Our small wireless nodes require an edge router to access the IP network and we used the popular Raspberry Pi with one of our RadioBlocks plugged into it. The choice of supported protocols was designed to demonstrate how IP allows direct connections/control for several user types: a local administrator, a central administrator, and other computers.

A simple local webserver runs on the Raspberry Pi, which generates a basic dynamic website using Python. This website provides status information about directly attached sensors, and contains information about settings for M2M communication. The Raspberry Pi sends mDNS messages to broadcast the local website address, in this case meaning the user simply goes to http://cmd.local . In real situations one might print a unique local URL on each device. To install the device simply plug in the border router to the network. It will be assigned an IP address, and the technician can navigate to the local website, without needing to figure out what IP address was assigned or other information.

This local website could be accessed from anywhere of course, however, that is a poor demonstration of what IP-enabled smart objects can do, since it is a proprietary interface to our network. Instead we use M2M protocols to allow a central management authority to monitor the device, which may also be monitoring devices from different vendors or at different locations. For the asset management case, it means a central security service could monitor the status of door locks across buildings at multiple sites. The IT department might have asset tracker tags on computers, and they monitor the status of computers during normal work hours when they might be moving the computers. Outside of regular office hours the asset tag monitoring turns over to the central security department. Since everything is done with IP, such transitions are trivial.

Our demonstration of a central monitoring station used the Icinga server installed on a “cloud server”. The MQTT protocol is used to monitor the status of asset tags, and a script interfaces between the MQTT monitor and the Icinga backend. If the user wishes to have another front-end they could subscribe to the MQTT resources of interest to get access to the data.

As a final example of the power of IP-enabled devices, we demonstrated how the entire system can integrate into already existing web applications. For this demonstration we used the popular GMail interface. Google Talk uses the XMPP (Jabber) protocol to send text messages between users. The Raspberry Pi has a GMail account, which it can use to send Google talk messages to another user. Thus a user can see an alert right in their email inbox about an ongoing event, such as a door being left unlocked or an asset moving when it shouldn’t be. XMPP is widely supported on many other devices (including mobile phones), meaning this message could easily follow the user as they transition from desktop to mobile.

All of these examples are implemented using some simple Python programs, using existing open-source libraries. The real power of this system is that by specifically using such libraries, we have made it exceedingly easy for further changes. Embracing IP standards means more than just running some part of your proprietary system on IP, but instead the system should be extendable and flexible, like IP itself.

Where does CMD Asset Tracker go now?

We plan on releasing the source code and design details for our system. The asset tracker is unlikely to become a product you buy off-the-shelf in a blister pack. Instead we wanted this system to demonstrate the use of our underling technology in a viable commercial solution.

Advice to Future Participants

Hopefully some of you reading this will become participants in the next iteration of this contest. When choosing a design for your entry, be sure it truly demonstrates how IP makes the product better. Don’t just assume because you happen to use IP at some layer you are embracing IP.

Instead, the objective should be to demonstrate how “because” your product uses IP, it can interface with devices and systems which would be otherwise impossible. This means your customers don’t need to use your proprietary interface to control the system. You can still provide one of course in case they ask for it, but it is much better to integrate into their existing network and device management infrastructure.

The IPSO CHALLENGE is an amazing opportunity for international exposure of your IP-based smart object solutions. But this contest means your product will be judged on how well it actually uses IP, and you can’t get away with giving lip service to IP as some companies try to do. If you are ready to embrace the true value of IP-based smart objects, we hope to see you as a finalist in next year’s IPSO Challenge!