Column - Phil on IoT

In last month’s article we discussed how the IoT space is full of standards, protocols, and companies competing for front runner status. This month’s article will be a two-parter.

In Part One we will cover how IoT aligns and differs from a typical Network/Application Stack. This part will be a rather technical article and it may be the first time some of you have seen this information covered this deeply. If you find yourself not understanding some of the concepts covered here don’t worry. The purpose of this article is to help show the complexity of IoT and to provide a frame of reference for future articles.

In Part Two, we will cover the common standards and protocols that exist within the IoT Space. This article will help you understand the technologies in the IoT space and will enable to effectively specify IoT products for your projects.

Quick, envision an IoT architecture, ok, got it? What does it look like? Chances are it has some sensors, maybe even a device or two, but what is it connected to? Some of you would say your IoT architecture uses WiFi, others would say that ZigBee is the communications method of choice, and some of you would say that in a world of risks wired is the way to go.

Truth is each one of you could be both right and wrong. IoT at its core leads with a promise of a network or networks filled with devices capable of communicating with one another. But how does one leverage this concept right now? How can you build your own Internet of Things?

In order to describe IoT we need to have a point of reference. What better point of reference then a model that has been used to describe modern network communications for decades?

The OSI Model or (Open Source Interconnection) Model consists of seven layers across which networked communications travel. I am going to walk you through each of the layers describing how IoT functions at each level. At the end of this article you should have an understanding of how IoT functions at each level of network and applications.

Layer 1: The Physical Layer
Where would we be without physical connections? The physical layer describes how devices are physically connected and there are a ton of physical layer standards being proposed. In the next article we will go through several of these standards but suffice to say right now there’s about 8 different IoT physical standards in review at IEEE.

Without the physical layer you can’t talk to your devices, so it would seem that the physical layer would be the most important area to look at when selecting an IoT device. After all, if your IT group will not allow you to use ZigBee but yet the sensors you bought only speak ZigBee then you might as well just send a check to me because you are throwing away dollars on sensors that you cannot deploy to your production network.

Layer 2: The Data Link Layer
One of the biggest wars is going on right now is located at the Data Link layer. Currently IP devices use MAC (Media Access Control) addresses to communicate across the data link layer on a local subnet. This works great even across a 1024 (/22 subnet) host failure domain. However, how well will the whole Address Resolution Protocol (ARP) to IP Address table strategy work when you have thousands if not millions of sensors on a local subnet? Ask yourself, when it comes to IoT, is the current approach of the Subnetwork still viable?

I recently read the book “Rethinking the Internet of Things” in which the author argues against the traditional Data Link approach. Rather the author believes in having a modified data package that simply populates data into a message que which then consolidates data into a single data link packet. If all of this blows your mind and is too deep take a look at this article.

The thought of segmenting IoT at the data link layer makes sense especially if you want your IoT devices to play nice with traditional Building Systems that have a very specific type of traffic they expect from our next layer…

Layer 3: The Network layer
IP, the area in which so many Building Systems are seeking to expand is also the area in which a lot of IoT devices are struggling to find their place. This is a difficult space with a series of issues but for the sake of brevity I will focus on the issue of network design.

When I was writing this article this section consumed about three hours of my life. There are so many interrelated pieces within the network layer and they all apply to IoT. For example, who is responsible for the IP addresses? Does IT need to provide ports for each IoT device? How do you handle rogue devices? These are just three of hundreds of design concerns that popped into my head.

Does IoT fit into the traditional IP design process? If so when and how? One sensor by itself will not tax a system but thousands of sensors could add significant load to an already provisioned IP network.

Finally you have network management, who will maintain, patch, and service these devices? All of these concerns come to a head at the network layer.

This is what makes the network design of IoT one of the most pressing issues alongside application development and data integration. Building Systems have always had a rocky relationship with IT departments. IoT will amplify this conflict and maybe it will finally bring it to a head.

Layer 4: The Transport Layer
The transport layer details out how data is transported across networks. If you are familiar with the concepts of reliable and unreliable communication then this will be a refresher for you. In networked communications most traffic breaks out as either reliable or unreliable communication. One of the most common building communication protocols is BACnet/IP. BACnet/IP is an unreliable communication protocol. This does not mean that BACnet is not as good as a “reliable” protocol. Rather it simply means that BACnet messages are fire and forget.

If you are looking for existing approach from which to design a way to transport data then BACnet is a good starting point. BACnet supports device discovery and change of value subscription. IoT promises to unite millions of sensors and the overhead with transmitting data reliably would be enormous. The average size of a TCP datagram is 64 bytes where as a UDP datagram is 52 bytes. Multiple this difference across thousands to millions of sensors and you have a massive data load.

So why does this matter? In the case of IoT, you are looking at device level sensors. These sensors are often taking in data every second. With that kind of data rate does it make sense to have reliable communication? Furthermore does it even make sense to establish a constant trickle of information? We will discuss this question in the session layer.

There is a natural divide between Layers 1-4 and Layers 5-7. The divide is really the shift from purely network architecture to a focus on application centric devices. At Layers 1-4 you are dealing with internetwork communication, however when you switch to Layers 5-7 you begin to focus on a feature set that is dictated by the application. For the sake of this discussion an application is the functional equivalent of a supervisory device within the Building System space.

Layer 5: The Session Layer
Previously when we discussed reliable and unreliable communication you may have asked yourself how do devices know when and who they are in communication with? Better yet with IoT is it practical to have sessions? At first glance the value of sessions may be unclear, it may seem that sessions are not valuable. After all, for IoT to scale it necessitates unreliable data flows. However, just because IoT is unreliable does not mean it has to be insecure and that brings us to one of the hottest IoT topics, security.

Right now IoT is all about sensors, but it doesn’t take a rocket scientist to see that IoT will quickly evolve to include control devices. How can the security of these devices be guaranteed and how can violations be detected from within the noise of millions of devices chatting it up?

The prevailing approach seems to be the concept of a gateway. In the gateway approach, all communications will route to a gateway and then the traffic will be controlled based on authentication and authorization rules that live inside the gateway. This will look very similar to rules based Access Control Lists (ACL), and for good reason, column based ACL’s are fast and they are immediately recognizable to most IT professionals.

The other aspect of Session control is session tagging (not to be confused with TCP Sequencing). Right now most building systems are sessionless. It doesn’t make sense to establish session tagging when the devices you need to communicate with are a twisted-pair hop away. However, when you start to include massive sensor quantities or data sources that are geographically dispersed, you run into a problem.
It kind of helps to have your data present when you are using large amounts of sensor data to drive your controls logic. What do you do then if your data is still in transit? That is where session control comes into play. Session tagging allows you to tag data temporarily as you wait for the rest of your data to come in. Once you have the data you need to present it to your application…

Layer 6: The Presentation Layer
There are some aspects of the presentation layer that apply to IoT but they are so deep that it really doesn’t make sense to discuss them here. At a high level the areas covered by the presentation layer are serialization (think JSON or XML formatting), encoding, and encryption. A key point is most modern API’s serve up data in one of three formats JSON, XML, or HTTP. If you are an application builder or system integrator you will want to consider how your IoT devices present the data they collect.

Layer 7: The Application Layer
This is quite possibly the most under appreciated area for IoT. I’ve met with many IoT companies that are completely focused on the device. While devices are important, most people buy stuff for the experience. Therefore I would predict that the IoT platform which finally breaks into the mainstream will do so because of its applications.

Have you ever tried to run reports on multiple disparate data sources? How do you run these reports? What platform would you use? How would these data sources roll up? This is a persistent problem in my day job. With the advent of IP everything we have a ton of data sources feeding into our building systems and IoT is only going to exasperate that problem. Therefore the company who produces a reliable, easy way to consume data sources and then presents the data in a user friendly fashion will rule the IoT world.

Currently the trend is towards responsive HTML/5 user interfaces. The thought is that if you develop your application in a HTML/5 then the application will be natively “mobile friendly”. While I’m all for mobile and responsive web pages I think the issue is less on how the data is viewed and more on how the data is accessed. That last sentence sounds like the same thing right? Let me explain.

Think about it, have you ever used an application that was seamless and required no effort to use? What about it made the application so easy? Chances are the application was easy because it was intuitive. Let’s use budgeting software for our example. How practical would budgeting software be if each time you wanted to link to a bank account you had to go and hard code an interface or do data type conversion? I’d be amazed if you even completed the interface but yet most modern building system software expects the user to be part coder, part technician, part magician. The IoT application that resolves this issue with a reliable set of integrations will be the one that stands above the rest.

In what I just described the application is solving an access problem not a viewing problem. After all pretty graphics and mobile interfaces are useless if you cannot consume your data.

Closing

This is one of the more technical articles I’ve written and with it you’ve been given a behind the scenes look at how IoT currently functions and the prevailing theories on how IoT applies within the current building/IT environment. As you can see there is so much more to IoT.

Looking forward to next month’s article in which we will begin to unpack the protocols/standards that currently exist and how they are being used for IoT.

I leave you my reader with some questions. How are you currently using IoT in your enterprise? What has worked and what hasn’t? Feel free to reach out to me on social media and let me know your thoughts.

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