Why protocols and hacking won’t hold back the Internet of Things
We are still in the early days of the Internet of Things (IoT). Rapid innovation is happening constantly in nimble startups, but many potential enterprise creators of IoT products seem to be stalling. Why?
Corporate leadership teams are avoiding two primary risk areas. First, there is a proliferation of available IoT protocols and standards, and concerns about interconnectivity in this expanding landscape lead to paralysis of choice.
Second, increasing visibility of huge losses from IoT hacks create internal legal deadlock, while solutions like encryption are notoriously difficult in constrained devices, requiring technical teams to reach beyond their current skillsets.
Uncertainty around the direction of innovation signaled by the development of protocol standards poses a risk in the minds of many potential IoT creators.
Just a few of the most common standards available for IoT applications include CoAP, MQTT, Thread, HomeKit, 6LoWPAN, Zigbee, BLE, Wi-Fi and LoRa.
Some of these specify the physical radio layer, some the application data layer, and some other communication layers or a combination, which means a device might use multiple of these protocols together.
Given this great diversity of standards and protocols, business leadership cannot afford to wait for wide adoption of any one standard.
Product development teams can feel paralysed by choice, fearing that any chosen stack may not win in the long run and knowing that they may not have the flexibility to change and react as new standards grow in popularity. If they wait for “VHS to beat Betamax”, they’ll be too late.
Importantly, in real products and enterprise solutions, only one or two key integrations are desired by users or product teams at any moment. More appear over time, but iteration allows for innovation now, not after we’ve waited for the next big thing to come along.
Interoperability should not, at this early stage, be a goal in itself. Product creators must select precise use cases that require some specific compatibility.
Under the banners of interoperability and easy integration, some industry players are aiming to own as much IoT market share as possible – think of Apple’s HomeKit and the Thread Group (born out of Google Nest) vying for the home.
The RTOS space is heating up too. FreeRTOS leads the market; ARM is pushing a new product called mbed OS; and Express Logic’s ThreadX has notable adoption and a growing line of related products.
The real solution to interconnectivity at the moment is at the server API layer. While some complain that this requires us to independently build infrastructure unique to each potential partner, that’s only partially true, and in the web service space, these integrations can be created in days or weeks.
At the device level, such collaborative efforts can easily take years. Global device protocol interconnectivity and compatibility is, at least for now, a pipe dream.
There is no general way to make devices universally discoverable, interoperable and secure because then any malicious device could cause undesired behaviors elsewhere in the system.
Human intervention is always required for authorisation. The best organisations can do at the device level is interoperate with the most successful products, and realistically even this usually involves the web service API layer.
New standards and protocols are constantly being developed by industry leaders working together to shape the future. When debating the scope and content of an emerging standard, the authors walk a fine line between creating an easy path to wide adoption in the short term and future-proofing the protocol by anticipating technologies that will be ubiquitous not too far down the road.
Teams developing internet-connected hardware and software are having to learn new skills. Cyber security and defense against remote access and information leakage have never before been on the CVs of embedded systems engineers.
Good encryption (providing proven confidentiality, integrity and authentication) is now table stakes in IoT. Any IoT solution without encryption by default is not suitable for an enterprise deployment.
The constrained devices of the IoT typically have limited resources and special needs when it comes to security. Libraries familiar from workstation and server systems won’t run on these ‘things’, so programmers have to learn new tools.
This situation – embedded engineers not knowing enough about cryptography and server-side engineers not understanding the constraints of embedded systems – means that cross-functional teams have to communicate better and work harder to break down barriers than they have in the past.
IoT projects thus require tightly knit teams of these engineers, plus others to handle the interlocking electrical, mechanical and user-experience requirements.
Source | Information-Age
