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.