Column - Phil on IoT

Well it’s that time of the year again, spring is coming, the flowers are kind of starting to bloom and the IoT race is heating up. Several interesting changes have happened recently, Cisco has announced their Digital Ceilings concept, there are now three smart equipment vendors who are touting their intelligent equipment offerings, and the hardware manufacturers are in a real fight to take hold of the chip and board market for IoT.

Where does that leave us? In my March 2016 column, Exploring the World of IoT – Part 1, I discussed how IoT would exist in the traditional network and application layers. Since that column I’ve gotten a ton of great emails asking me about IoT and how does one get involved? Well my readers, you are in luck! This month’s column is going to take a higher-level look at the overall IoT space.

Now a quick note as I started to write this I intended to cover the entire IoT space in Part 2. However, as I started writing I realized I can’t fit all I need to write about in a single column. Therefore, I will be expanding this topic into several columns.

In this column, we will explore the current IoT space. We will focus specifically on IoT Standards Bodies and IoT Frameworks. While I’m sure there will be some areas we will skim over or miss outright, you will still leave the column understanding, who the main IoT Standards organizations are, the purpose they serve, and the frameworks and technologies they support.

According to AT&T’s Foundry (A IoT Incubator of Sorts) there are four layers of technology that make up an IoT “Stack” these are the Application, Service, Network, and Framework Layers. Quite honestly I don’t find these descriptions all that helpful. After all, CoAP is positioned as a framework but it is also a network protocol and an application layer technology.

After perusing various sites, the consensus seems to be that a traditional IoT solution, how anyone can call IoT traditional is beyond me since we still don’t have widely accepted reference architectures, should consist of the following modules:

In this column we will be covering the IoT Standards Bodies and IoT Framework’s.

Now if you read my March 2016 column, Exploring the World of IoT – Part 1, some of these categories will look familiar to the layers covered by the OSI model. That is because, guess what folks, they are! IoT really isn’t that confusing. Amidst all the marketing noise and confusion, IoT is really just a distributed hardware and software solution, just on a massive scale.

Please don’t take my attitude as being dismissive, there’s a lot of hard work to get millions of devices to communicate with each other. But at the end of the day, it’s simply about data. With that being said how is the data used, how is it transferred, how is it stored? The next several sections are going to discuss these exact topics.

Before I get too deep into the column I wanted to point out the Standards bodies that any IoT Technologist should be aware of. I do not claim that this is an exhaustive list in any shape or form as there are literally hundreds of standards bodies. My rationale behind selecting the following groups is based on how often I have heard these groups mentioned in both professional and non-professional conversations.

In the sections that follow I will detail out who each of these groups are and what they are doing in the IoT space.

ASA - AllSeen Alliance
The AllSeen Alliance is a group of over 200+ companies that are working on the AllJoyn Framework (which will be described in the next section).

I look at the AllSeen Alliance as similar to BTL (BACnet Testing Laboratories) in that they have a testing arm to test product compliance to the AllJoyn framework.

AllSeen is one of the three organizations today that I will discuss that has a full stack framework for IoT.

IEEE-SA – Institute of Electrical and Electronic Engineers Standards Association
The IEEE, founded in 1884, is the oldest standards body in this list. While I haven’t gone and counted them I believe the IEEE has the largest amount of potential standards and publications surrounding IoT. Logically it makes sense that the IEEE’s main area of focus is at the device and network level. Their main standards right now are focused in 4 key areas:

IETF - Internet Engineering Task Force
The IETF was formed in 1986 with the self-adopted mission statement to “Make the internet work better”. The structure of IETF is to have several working groups that work towards creating standards for Internet based technologies. The primary area of focus for the IETF around IoT is networking and data communications.

There is a good article surrounding the IETF’s involvement within several IoT standards.

IIC - Industrial Internet Consortium
The Industrial Internet Consortium is a group of industrial companies and providers that have come together to influence the standardization of Industrial Internet technologies, to test Industrial Internet Platforms and to develop an Industrial Internet Reference Architecture. While not directly equivalent to traditional smart building systems the IIC does provide an influential voice in the industrial sector.

IoTC - Internet of Things Consortium
I debated including this group here as they seem primarily focused on Home and Wearable technologies. I have said multiple times that I believe the home IoT movement will drive the commercial IoT movement which will be an interesting change from the past where commercial product development drove the development of home technologies.

OCF – Open Connectivity Foundation
I actually have a lot of excitement for what the Open Connectivity Foundation is doing. They are all about data standardization in order to create an open standard for IoT. As I mention later in this column data normalization is a big problem with IoT. In my opinion they are one of the more advanced groups in terms of usable frameworks and standards.

If you’re feeling techie go take a look at all of the RAML and JSON data models they’ve created for data standardization. I think OCF has this one nailed as they are one of the few IoT groups that I’m aware of who are starting off with a robust data model.

TG – Thread Group
The Thread Group is a consortium of several well-known companies.
While predominantly focused on creating IoT products for the home I have been finding Thread Group’s Thread Framework increasingly mentioned as a standard for commercial IoT as well. Thread’s framework combines UDP, IP Routing, and 6loWPAN (which will be discussed in Part 3 of this series).

While this area is still coalescing there seem to be a few key frameworks that I keep hearing come up in both my research and my professional dealings.

Key Emerging IoT Frameworks in the IoT Space
The three main frameworks that I keep hearing come up are the AllJoyn, IOTivity, and Thread frameworks. Some would argue that CoAP is a framework but I consider it a full stack protocol standard as it doesn’t address the data model, platform, and other things you would expect a framework to address.

AllJoyn-
AllJoyn is an open framework created by the AllSeen Alliance. The framework consists of a Core Module and several SDK’s. The Core Module can be deployed on almost any OS type (no Windows Phone support that I am aware of which leaves me and my poor Windows Phone out).

The SDK’s are hit or miss on platform support. You can see on the download page what OS is supported by an SDK.

AllJoyn Core
The Core Module is coded in C, C++, Java, and Objective C. This means that developers can use the Core Module with most existing software solutions. The Module consists of a couple core features.

Networking and Device Discovery
The AllJoyn devices join a network by utilizing the AllJoyn BusObject, which I believe is similar in concept to the Java WebObject. AllJoyn uses this object to connect to the AllJoyn Router. Once connected these AllJoyn devices can use advertisement and auto-discovery methods to communicate with one another. The session supports point-to-point or multi-point communication. This would be equivalent to unicast and multi-cast messages in the IP world.

You will notice that AllJoyn has several characteristics of the BACnet Standard. AllJoyn can utilize what is called a Session Signal to discover signals from devices without creating a session. This seems a lot like the BACnet Who-Is function. In addition to this AllJoyn can perform what is called Introspection. Introspection allows AllJoyn devices to discover all object paths and objects belonging to an AllJoyn device.

Object Enumeration
Moving on to the device itself, while AllJoyn uses an auto-discovery method to find fellow devices, for point and object enumeration AllJoyn follows a pattern similar to Modbus and BACnet Standards. An AllJoyn application/device will add metadata to its signals and methods that allow fellow AllJoyn devices to interpret the devices capabilities.

Security
Security is a hot topic right now and rightfully so. It seems that every other day some system is in the news for a vulnerability. Security has been a concern in the IoT space due to the computing and memory requirements of encryption. AllJoyn’s default approach to this solution is to provide security only at the Application level. This is a bit concerning as it would seem this would allow for replay and man-in-the-middle attacks. AllJoyn does state that authentication can be applied to the interface and can exist on demand between any two application layer connections, however I still believe this would only apply at the Application level.

IOTivity
IOTivity by the Open Connectivity Foundation is one of several projects the foundation is working on. It would appear that IOTivity is more open in the technologies that their framework supports whereas AllJoyn and Thread are more prescriptive as to how to utilize their frameworks and the technology stacks that they recommend.

With IOTivity there is a ton to discuss and I could spend a whole column just covering the framework itself. Because of this I am providing a link to the IOTivity wiki page and the detailed architecture for those who want to dig deeper into the framework.

Connectivity
The IOTivity Framework consists of two device types called a Rich Device and a Lite Device. A rich device will have expanded capabilities through a service layer that will allow for resource management, group administration, and power management. The Rich device also includes a base layer that handles discovery, messaging, connectivity, and security.

The Lite device on the other hand exists for data collection/sensing and only implements the base layer.

Connectivity for these devices is providing using multi-cast for discovery and CoAP for messaging. One thing that is particularly interesting is the Rich device has the capability to interface with non OIC devices. This is a capability I did not see within the AllJoyn or Thread frameworks (if I missed it feel free to let me know).

Security
This is one of the areas that really excites me about IOTivity. We all know that BACnet, as it is implemented by many companies, is insecure. While BACnet has released an addendum to the standard that includes inter-device authentication, I do not know of a single implementation of this in production ready product.

IOTivity has built in what is called a Secure Resource Manager. This SRM utilizes a IOTivity Secure Virtual Resource (SVR) database which provides for access control lists, PSK credentialing, and Device Certificating. This is one way to solve the issue of resource capacity in regards to devices. While not perfect, as it provides a single point of failure, it at least pushes security down to the device level.

Thread
The Thread Stack, which is the formal name for the Thread Framework, provides for Direct device to device communication. Thread Stack is focused on four primary principles for its stack. These principles are: Security, Range, No Single Point of Failure, and Low Power.

Technology wise the Thread Stack utilizes UDP, IPV6, 6LowPAN, and the Mesh (802.15.4) Network Standard. These technologies come together to form a low overhead, self-healing network.

Connectivity
Similar to other frameworks, the Thread Stack utilizes only a few device types to establish its network. These devices are:

A good way to envision the Thread network architecture, is to think of the router as collecting and coordinate the exchange of data between a series of networks. Under each of these routers there are end devices and sleepy devices that feed data up to the network. The whole Thread network can then interface with external networks utilizing the Border Router.

Device joining and discovery is handled by Mesh Link Establishment Messages or (MLE). These messages discover the neighboring devices in order to effectively route messages. The MLE message will contain the capabilities of the device along with pertinent routing information.

Security
Thread seems to take a somewhat similar approach to IOTivity in that a Joiner Router, is used to authenticate new devices with the commissioner. Once the device is “joined” it will utilize a network key that will encrypt all MAC data frames (Layer 2).

[an error occurred while processing this directive] This approach is similar to IOTivity in the use of a centralized security management device. I did not however, find a clear answer as to how the Thread devices handle the resource consumption associated with encrypting and decrypting devices.

In this column, you learned about the current state of IoT Standards Bodies and IoT Frameworks. I provided many links for those of you who want to take a deeper dive into these technologies. My hope is that, while I wasn’t able to dive into deep technical details, you are still able to leave this column having an increased understanding of the technologies within the IoT space.

In next month’s column I will be discussing Data Encoding and Full-Stack Protocols. We will dive deep into topics like Message Queuing Telemetry Transport (MQTT) and the Constrained Application Protocol (CoAP). We will compare and contrast these protocol standards, look at sample messages, and will discuss how, where, and when they should be used.

I appreciate you reading this column and if you have any questions for me please don’t hesitate to reach out to me via the contact information below.

Phil has been working with technology for the past 14 years. He is the creator of Building Automation Monthly and is currently a Senior Technology Program Manager for Johnson Controls. In this role he manages multiple products and technical programs. He also works as a liaison between marketing, sales, and engineering in order to translate sales and technical speak to meet customer needs.

Phil is known for his variety of knowledge. He is fluent in several programming languages, has designed the IT Infrastructure for several of Johnson Controls customers, and has worked on and integrated almost every Building Controls Product in existence.

Phil runs the popular blog Building Automation Monthly at http://blog.buildingautomationmonthly.com and has written for the ASHRAE Journal as well as other trade magazines and has spoken at IBCon. In his off time he likes to program, write, and spend time with his wife and three young children.
______________

As always, the views expressed in this column are mine and do not necessarily represent Johnson Controls Inc. or any other organization. If you want to send comments to me directly, feel free to email me at Phil@philzito.com

[an error occurred while processing this directive]
[Click Banner To Learn More]

Events	Want Ads
Our Sponsors	Resources