We were discussing standards upon which to build standards today. Before systems can communicate, there is a lot of work building the platform they communicate from. So much of the small work that will be needed for the internet of things is based upon constrained communications between resource-constrained devices. I found myself spitting out acronyms right and left – a veritable techno-glossolalia.

There is a whole set of standards needed by the utilities to share billing information with a third party, such as Google Energy or Microsoft Hohm. The utilities are constrained by their mandate to make all services universally available. This means they are trying to accomplish the goals they call OpenADE (Automated Data Exchange) using only the equipment they already have in homes.

http://www.smartgridipedia.org/index.php/OpenADE_Charter 

oBIX is a low level (the the extent REST or SOAP is ever low level) protocol for talking to control systems. oBIX was designed as an object-oriented model from which higher level objects could be created (a process that oBIX call defining contracts). Today, all contracts are proprietary, but the work plan has always anticipated standard contracts…standard contracts currently anticipated include include WS-Calendar scheduling, Energy Interoperation, and energy profiles. Non-energy related plans include binding for RSS and ATOM.

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=obix

There is a suite of low-level pre-standards efforts to develop applications extremely constrained in resources and communications. They all seem to have names that are one-offs of 6LoWPAN (IPv6 over Low power Wireless Area Networks). Note: ZigBee pre-dates 6LoWPAN and is not entirely compatible with IPv6.

• There is the compressed HTTP over PANs (CHOWPAN) recently submitted to the IETF.
  http://ftp2.kr.vim.org/internet-drafts/draft-frank-6lowpan-chopan-00.txt 

• There is the Applications for 6LoWPAN work in the IETF, submitted by the Utilities
  http://zachshelby.org/2009/07/07/6lowapp-embedded-application-protocols/ 

• There is the new Service Discovery for 6LowApp submitted to the IETF by PGE.
  http://tools.ietf.org/html/draft-sturek-6lowapp-servicediscovery-00 

There is also considerable work done on discovery and profiles this summer in the OASIS Web Services Discovery and Web Services Devices Profile (WS-DD) TC. This work is subtitled “Enabling secure Web service messaging, discovery, description, and eventing on resource-constrained endpoints” Note: while WS-DP defines how to communicate a profile, it does not actually define any particular profiles—for example, an energy profile could be communicated if we knew what an energy profile looked like.

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-dd

One of the interesting aspects of this committee which had the major OS companies, the major enterprise management software companies, and the major printer companies represented, was that Schneider Electric was on board. Schneider representatives have stated that all of their switch-gear will support WS-DD and WS-DP eventually. Schneider contracted with a 3rd party to develop WS-DD and WS-DP for very small devices as an open source project. They used this project to assert (as all OASIS TC’s must) that they had successfully implemented WS-DD and WS-DP. This site can be found at the address below and downloaded under the BSD license.

https://forge.soa4d.org/

So keep up, folks!

[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]