Share

Almost exactly a year ago, I wrote about one of the Linux Foundation's Collaborative Projects, with the rather disconcerting name of AllSeen. I found that problematic, since the AllSeen Alliance hopes to create the de facto standards for the much-hyped Internet of Things. One of the my chief concerns with this idea is that it could make today's surveillance look positively restrained - imagine if spy agencies and general ne'er-do-wells had access to detailed knowledge about and perhaps even control over individual components of your "intelligent" home.

Almost exactly a year ago, I wrote about one of the Linux Foundation's Collaborative Projects, with the rather disconcerting name of AllSeen. I found that problematic, since the AllSeen Alliance hopes to create the de facto standards for the much-hyped Internet of Things. One of the my chief concerns with this idea is that it could make today's surveillance look positively restrained - imagine if spy agencies and general ne'er-do-wells had access to detailed knowledge about and perhaps even control over individual components of your "intelligent" home.

That issue notwithstanding, the AllSeen Alliance has just celebrated its first year, grown to include 100 members - but still not changed its name:

In just one year, through the power of a shared vision and a commitment to collaborate across industry lines, the AllSeen Alliance, the world’s largest collaborative open source project focused on the Internet of Things, has become the place to solve IoT’s biggest challenges -- interoperability and fragmentation. We have nine Working Groups that are producing code to address critical areas impacting IoT interoperability, including lighting, home automation, security, cloud and analytics. Those include QEO’s data-driven APIs and security enhancements contributed by Technicolor; new lighting service APIs and connected lighting framework from LIFX; a new gateway agent from Affinegy; software update services from Red Bend; analytics from Tellient; and a smart home gateway from Haier; among others.

Those nine working groups are perhaps the most important development in the last twelve months, since they represent a move from a generalised intention to come up with an open source framework for the Internet of Things, to producing detailed specifications for making that happen. This, for example, is the working group for intelligent light bulbs - well, not just light bulbs, but lighting in general:

The Connected Lighting Working Group develops the Lighting Service Framework (LSF) providing an open and common way of communicating with AllJoyn-based connected lighting products, regardless of manufacturer. This will enable lighting manufacturers to make their products interoperable with each other as well as other connected things, and provide 3rd party application developers with a common interface (API) to communicate with lights across manufacturers.

Examples of features of LSF include the ability to group lamps together and control their hue, saturation, brightness, and color temperature to match a users preference or mood. Other features include the ability to personalize the lighting experience to an individuals tastes and preferences by setting lighting Scenes, and the ability for users to add lighting Effects like pulsing lights for notifications purposes.

Here's how the Lighting Service Framework (LSF) is designed:

1. Lamp Service

The Lamp Service is implemented by the Lamp (light bulb) Manufacturer inside the connected Lamp firmware to make the Lamp LSF compatible. The Lamp Service is designed to run in a very small footprint (1KB SRAM/5KB Flash) on an embedded RTOS in the Lamps Microcontroller (MCU)

...

2. Lighting Controller Service

The Lighting Controller Service is a mandatory component of the LSF and works in conjunction with and is dependent on the AllJoyn Core Standard Client and Router. It stores group, scene, and preset information and discovers and connects with devices on the same network running Lamp Service. If multiple Lighting Controller Services are running on the same network, they arbitrate and one becomes a Leader and the rest become Followers. Group, Scene, and Preset information is synchronized between Leaders and Followers, and if a Leader leaves the network a Follower will be promoted and take over controlling the Lamps. Lighting Controller Service runs outside of the Lamp on a Hub, Router, Switch, Gateway, or any other Linux-based device (such as OpenWrt) on the same network as the Lamps. It can also be bundled in with the mobile application running on an Android or iOS Smartphone or Tablet that the end user uses to discover and control the Lamps. The Lighting Controller Service footprint is roughly 270KB Flash / 25KB RAM not including the AllJoyn Core.

If you're wondering what exactly can be done with this technology, there's a useful presentation and video of a talk that both run through some of the basic applications. Alongside flagging up situations of concern - smoke detection, or babies waking up in their cots etc. - there are also gaming applications for creating immersive experiences by changing the lighting according to the game environment. Naturally, more sophisticated devices will have a richer range of responses. But one over-arching issue is that of security - something that I concentrate on in my previous post. Security is part of the Core Working Group:

The goal of the Security 2.0 feature is to allow an application to validate access to secure interfaces or secure objects based on policies installed by the owner. This feature is part of the AllJoyn Core library. It is not an option for the application to enforce permission. It is up to the user to dictate how the application performs based on the access control lists (ACLs) defined for the application. The AllJoyn Core Permission Management component does all the enforcement including the concept of mutual authorization before any message action can be taken.

That all sounds rather sketchy for something which really is critically important to the whole Internet of Things concept. Although it's great that the AllSeen Alliance is making good progress, it must make a first-class security approach an absolutely priority for the project. It will only take a few serious security failures in the early days of product introduction for a pall to be cast over the whole endeavour. The could be a disaster not just for the AllSeen Alliance, but also for open source in this area, since it would doubtless be exploited by companies offering their own proprietary frameworks. Let's hope that next year's anniversary sees continuing growth for the AllSeen projects, and also a considerable enrichment and filling out of the security framework.

Follow me @glynmoody on Twitter or identi.ca, and +glynmoody on Google+