Working with IoT is not as easy as it sounds

It seems that everywhere we look these days, all we hear about is how the Internet of Things (IoT) is going to connect everything to everything via Ethernet/IP networks, and simply by doing so, enable a new utopia. Unfortunately, as we've discussed in this column in the past, having an IP address is like giving someone a phone number. Just because I can "dial you up" doesn't mean we can communicate.

Continuing with our phone analogy, the first requirement once we make a connection is agreeing on a language. In the case of networks, protocols are the approximate equivalent to a language. So, if you're speaking English and I'm speaking Spanish, we both realize we're trying to communicate, but we aren't really doing so. Similarly, if one network node is sending Modbus/TCP packets but another is configured to only receive Ethernet/IP packets, again, the message is not getting through.

Making the Industrial Internet of Things real

Then, just as we want to filter our phone calls with things like call blocking and "do not call" lists, industrial networks must manage who can connect with whom. as well as confirm the authenticity of information packets. We consider these aspects part of the cybersecurity requirements, which are especially a concern with IP-based networks because they share much of their infrastructure with commercial networks, so they are prone to the same vulnerabilities.

We've written in the past about the different organizations such as ISA, IEEE, IEC, ISO, ITU, IETF, etc. developing and issuing standards or rules on which to build the necessary infrastructure for IoT. Just like with the different field-level protocols, trade organizations also play an important role, allowing members to cooperate to convert these standards into products that effectively work together. Two organizations for IoT are the European Lighthouse Integrated Project's Internet-of-Things Architecture group (IoT-A) and the Industrial Internet Consortium.

During its three-year mandate (2011-13), IoT-A developed a proposed architectural reference model together with the definition of an initial set of key building blocks. It combines top-down reasoning about architectural principles and design guidelines with simulation and prototyping in exploring the technical consequences of architectural design choices.

Coincidentally, the Industrial Internet Consortium (IIC) was founded in March 2014 to bring together the organizations and technologies necessary to accelerate the growth of the Industrial Internet by identifying, assembling and promoting best practices, thus effectively building on the previous standards work and that of IoT-A. The IIC is a virtual who's who of network-related developers with the stated objectives to: 1) define and develop the reference architecture and frameworks necessary for interoperability; 2) influence the global development standards process for internet and industrial systems; 3) facilitate open forums to share and exchange real-world ideas, practices, lessons and insights; and 4) build confidence around new and innovative approaches to security.

Though the IIC indicates that it's developing use cases for IoT, to do so, it requires input and participation from end users dealing with the types of problems that need to be solved. In my experience, though they do good work by forming the foundation on which to build something, standards groups that don't have end-user (customer) input can easily fall into the trap of defining an elegant solution that then needs to find a problem to solve.

We're able to send more bits than ever to even more nodes than before, but until we make sense of all the 1's and 0's, that is what they will remain: bits, not bytes of useful information. As many practitioners know, once you can actually read the bytes, the next step is deciding which ones  matter to your application and present operating conditions, which opens a whole new can of worms and challenges.