Building The Internet of Things: Overabundance Of Access Technologies

Author Maciej Kranz discusses how to decide on the right access technology for your IoT solution.

Mar 9, 2017

As noted above, we’re all facing an overabundance of access technologies.

This is further complicated by disparate devices and the tasks we want our various IoT solutions to accomplish. To even begin to decide among this variety of access technologies, you need to answer these basic questions:

How many and which types of devices are in your network?
Are these devices mobile or fixed, and how geographically dispersed are they?
In which type of physical environment will these devices operate?
How much data is being transmitted, and what bandwidth is required?
How time-sensitive are the data transmissions?
For battery-powered devices, what likely duration of operation is required, and how long should the battery last?
What are the cost constraints?

Notice that these aren’t technical questions, just basic business questions any LOB manager would want answered. Deciding on the right access technology is only the first step in designing IoT capabilities that will drive efficiency and yield actionable insights and better decisions. Before you have a working IoT solution, you’ll also want to address the migration from proprietary technologies to open standards (yes, I know I sound like a broken record here), where and when data should be analyzed, security and risk assessments, and the evolving relationship between the central IT function and OT roles within LOBs.

Common IoT Framework

Are you overwhelmed yet? Fortunately, the industry quickly recognized that we can’t go through each building block in a solution and ask basic questions like those above without a decoder ring. Thus, we’ve started to converge on a common IoT framework. That IoT framework is not just a slick marketing gimmick. It actually represents the way serious IoT players think about issues such as architectures, terminology, and logical blocks. Put another way, it’s about using common designs, described in the same terminology, to refer to the same things. This isn’t cast in concrete yet; it’s only a starting point.

Such a framework can guide us on how to reduce the complexity of IoT technologies and solutions. It helps us determine which layers to abstract, where to focus on interoperability, and where to create open APIs as well as common and open standards. Since IoT is still evolving and will continue to evolve for years, we want a way to accommodate new innovations while ensuring that any new things can work with existing things. Otherwise, we’d all be in the position of reinventing everything anytime something changes. The IoT World Forum Reference Model is a good example of such an eff ort. (The IEEE IoT Architectural Framework is another example.) Its common framework drives interoperability across all IoT components: devices and controllers, networks, edge or fog computing, data storage, applications, and analytics. The model (Figure 10.2) organizes these components into layers and provides a graphical representation of IoT and all that it entails. Equipped with such a reference model, the IoT industry has been focusing on three different standardization thrusts:

1. Evolving existing horizontal standards. As has been the case with many previous technology transitions, the robust standards of the IT world are now evolving to include requirements from OT and IoT. Dozens of interest groups in the IEEE, IETF, and other standards bodies are working on requirements for IoT, including time-sensitive networking (TSN) for cars or industrial control systems and safety; high-speed mobile communications among diverse things such as cars, trains, and other vehicles; or high-coverage low-speed networking technologies for low-power low-bandwidth sensors.

2. Migrating specialized, proprietary, and semi-standard technologies to open standards. As we’ve discussed, major industry players in manufacturing, transportation, and other verticals have historically implemented proprietary technologies or established standards around their own protocols and technologies. This often created conflicting standards, thus inhibiting interoperability and adoption. The IoT industry is working with the major industry standards bodies, including ODVA, to avoid this issue by migrating to open standards while ensuring interoperability with legacy protocols.

3. Creating consortia to address key pain points. Major industry players are joining forces in new consortia, among them the Industrial Internet Consortium (IIC), the Open Connectivity Foundation (OCF), the OpenFog Consortium (OFC), and the OPC Foundation (for open platform communications).

IoT technologies are organized as a technology stack that moves up from physical devices at the bottom through data and applications, and finally processes. As I’ve mentioned, data analytics and vertical applications are key drivers for IoT. Most recently, I’ve seen an increased interest in data-in-motion and real-time/near-real-time data capabilities (think predictive analytics and fast payback scenarios), which are driving the latest interest in fog computing. One big challenge with such data is that the data streams tend to age, which drives down their value very quickly; thus, the need to implement real-time analytics capabilities at the edge. Think about using data to identify and stop fraud as it’s occurring.

This isn’t something you want to do hours, days, weeks, or months later. Besides the growing interest in fog-based analytics, the good news is that the industry is quickly adopting an open-source innovation model for both data storage and data governance, which should also speed data processing.

Finally, many of the challenges with IoT aren’t technology-related but instead come from the industry’s slow adoption and, often, resistance to change. One example of why creating common standards is so important: Wireless HART and ISA100, two different wireless standards focused on connecting sensors to the network. Both were derived from the IEEE 802.15.4 protocols, but each was created by a separate ecosystem of industry players and, as a result, is incompatible with the other.

When my team came across these standards a few years ago, we thought we could help the industry converge on a common open standard for the wireless connectivity of sensors. That way, customers could easily choose among many sensor vendors and infrastructure vendors and not be locked into buying devices that only support a given standard. We went to both camps and proposed that we work on a plan to converge Wireless HART and ISA100 into one new open standard. Unfortunately, the idea was dead on arrival. I still hope that someday both standards will converge, but I don’t see it happening in the near future. It will only happen when customers demand it and vote with their purchase orders.