IoT is almost everywhere, even where it has not reached, it is either assumed or talked about. It is in our homes, our wearables, our cars, it is in our public buildings, cities and transport. Surely designing for all these ‘Things’ must come with special challenges and need new techniques and tools?
If we look at the technology to solve a problem twenty years ago, and look at the technology to solve the same problem today, then yes, the two are vastly different. We typically have more software included, and there are some features now that were not considered then. This change has mostly happened slowly. This year’s car has been a small improvement over last year’s. I have a remote control for my TV – how about I put one with the central heating controller.
IoT does bring some interesting challenges, particularly in the areas of security and standards, but much of it is a small step on from what we had before. I worked on equipment in the mid 1980’s that had BIT, Built In Test, it put a code on the simple front panel display to show the result. Many things now have self-test, diagnostics, or predictive maintenance features, but they send the result over the internet and become part of the Internet of Things.
When we design for the IoT, we still have to have the core functionality, and all the challenges that gives us. Understand the need, understand the environment into which the system or equipment will fit, understand the operation and disposal parameters. Requirements, modelling, testing, and such things. We already have tools for this, we already have processes to support this.
So what is really different?
The Internet of Things moves quickly, standards change, technology improves. If we are building a large system such as a car or a ship, we should expect a three, five or ten year development lifecycle. Trying to mesh this with an IoT standard that is changing on a one or two year lifecycle presents some challenges. Defining an architecture that has a clear interface to the ‘known unknown’ elements reduces the risk exposure. Modelling support is important here, and clearly identifiable interface requirements with traceability throughout the design artefacts will support the engineers who have to mesh the evolving standard with the longer lifecycle design.
If we have a range of products that have their IoT features in common, then we want to make use of the common design to reduce both cost and risk. Design for reuse helps here, making all the design artefacts reusable, not just the physical entity at the end. Supporting design for reuse includes supporting concepts of product families, a 150% solution, robust change and configuration management and robust traceability.
IoT will offer us more possibilities tomorrow than it offers us today. Ideally, whatever we design will be able to take advantage of these new possibilities, but that means designing with a crystal ball. Some flexibility can be designed in, allowing over the air updates, including more than the bare minimum of hardware specification, so that as yet unimagined software can exploit this. Now we have problems of managing Things when they are in the wild, and again robust change and configuration management is essential.
None of these challenges are beyond the tools available, but they do require a slightly different emphasis during design. Processes, checklists, reviews all need to be considered to see if they are suitable for ‘Design for IoT’, a new area of risk assessment has emerged where we are looking at protection from cyber-attacks. I think the current IBM tools do a good job of addressing these issues, with configuration management of requirements, models and tests, and tools such as RELM (Rational Engineering Lifecycle Manager), and dashboards to support the analysability of data.
Deciding what data could and should be sent off board and received from elsewhere is a different type of problem, this is exploiting the IoT capability in addition to whatever more traditional core functionality is required. How much edge processing, how much data to send, when to send it, who bears the cost of data transmission and of data storage, privacy concerns and more. These are problems that are more commonly discussed, and once you start thinking IoT are more obviously in need of attention. These are the areas where IoT is a new area of specialism to consider.
Great post, Hazel. Key things to consider when a previously stand-alone device is connected to the IoT include
– the fact that it now needs to communicate means that someone has to add that capability.
– the fact that it now needs to communicate means that it must have something to communicate, which means it must be able to monitor its own condition, sense the environment and / or receive control information
– the fact that it may need to receive control information means that it will be expected to act upon that information
All these additional capabilities mean that the device becomes more complex in itself.
Then there is the fact that a connected device becomes part of a system of systems, which suggests the probability of emergent, and hence unpredictable, behaviour.
Finally, any connected device, particularly one that is implicitly connected to potentially millions of other devices, poses new and challenging security concerns. This is often the thing that catches engineers out, witness the case of a car being remotely hacked through a vulnerability in its entertainment system.
Thanks Keith, I think the security concerns are a big deal, but I didn’t want to tackle that here, it *should* be an obvious area of consideration for anyone developing connected devices. Sadly this is not always the case, and there are many more tales of woe to come from this avenue.
The other points you make add complexity, but don’t bring any fundamentally new problems to the world of systems engineering. They do however move people up one level ‘up’ in complexity. A connected home appliance is far more complex than a standalone home appliance because of the system of systems aspects, a connected car is more complex than a non-connected car, but the designers are already looking at systems issues and system of systems issues, so the security risk factors will dominate the discussion.