One of the fundamental challenges with developing IoT devices is the fundamental mis-match between the demands of hardware and splitting software development; at times it feels like Internet vs Things.
The internet (or software) world is characterised by much greater tolerance of faults, less robust testing and faster iteration and time to market. The hardware industry, in contrast, comes from a heritage of organisations that are much more risk averse, understandably so because when hardware fails people die. The hardware world is also typically much more highly regulated. Flip over or open up any hardware device and there will be various stamps attesting to the regulatory requirements with which it needed to comply. The software space doesn’t even come close, although this is slowly changing with some of the recent consumer privacy and data management regulations such as GDPR coming into force. The upshot of this divergence is that product design that would have been appropriate in either world was not exactly appropriate for IoT. Products were either too buggy or non-compliant, or they were too inflexible or slow to market.
These issues were not really a problem for the development of operational technology (OT) systems seen in building control systems or industrial equipment. These involved a high degree of integration of hardware with the control layer/software. OT systems were developed with the high levels of security and resilience typically required of the hardware. The two elements worked hand-in-hand. However, the biggest challenge with OT systems is that they are inflexible and limit innovation. The reason for the obsession in recent years with so-called “IT/OT integration” was to open up the OT systems to the innovative approaches seen in the IT sphere. Of course, this brings problems. Automotive electronics systems were completely secure until companies started connecting to the CAN BUS to build new connected car services. The necessary security and resilience had yet to be properly implemented in the early days, although things have improved somewhat now.
This experience of the OT community is illustrative of a broader trend, the need to separate the software and hardware layers of any technology in order to see true innovation. We have recently started talking about a three step approach: Separation, Innovation, Explosion.
The first step of separation means the splitting of the software and hardware development approaches. Innovation comes when both sides are liberated to build according to the requirements of their platform. Explosion is the result, in terms of massive take off in usage. For instance, in the personal computing space this happened decades ago when hardware and software were provided by different players. The result was a mass of innovation in both, less so in hardware, more so in software.
The kind of separation that happened early on in the PC world is also happening in IoT sectors. Connected cars was mentioned earlier. This has historically been a slow moving market with long lead times and developments splitting software, but the shift to electric vehicles and the move to autonomous vehicles could trigger a change in approach. There have been suggestions that Tesla may consider switching from being a provider of integrated hardware and software to licensing just the software to other car manufacturers. While we may think of Tesla as an innovative player, perhaps it will become infinitely more so if it becomes solely focused on software. Factory robotic systems are also seeing increasing separation of hardware (e.g. from companies like ABB and KUKA) from software (e.g. from MTEK or Bright Machines). To take a consumer example, connected TVs have perhaps been uninspiring because the software layer is provided by the same companies making the hardware.
The fundamental underlying issue is that it is easier to innovate in one area than in more than one. What are the chances that the most innovative company in making the hardware will also be able to match that in software? Separate the two and it allows best-in-class from both. What is required for most of IoT splitting software to take off is for companies making hardware to have access to common large scale software options. Increasingly we’re seeing this from the likes of AWS with FreeRTOS and Microsoft with IoT Plug and Play. Most areas of IoT started from a position of Separation, but the software element lacked the scale necessary to take off.
Originally Publish at: https://iotbusinessnews.com/