IIoT product development: lessons from past projects

In this overview article on industrial IoT product development we will guide you along the essential questions and directions to consider. We will go with you along the relevant topics and preconditions, when you start to connect large numbers of small and medium-sized computing devices and sensors to your first IIoT project. Maybe you are already working towards a PoC or even a full-blown product. You are making great progress, but are you overseeing something? Let us give your project the best possible start.

Most of our customers have realized their first (Industrial) Internet of Things (IoT) idea as a proof of concept (PoC) by themselves. We have been involved in several IoT projects recently. These projects involve combinations of computing devices, sensors and actuators along with the controlling software and hardware. These combinations are designed to be interconnected and – ideally – to use open platforms. They are novel and that is exactly what we want to sell: a novel and useful combination of known parts and domains.

We will use an exemplary IoT project as a general guide and to clarify what we intend. The project’s goal was to automate the growth of plants. It is an enclosed system which controls temperature and light, adds water and nutrients to the plants and exchanges the air regularly. The plant grower is able to view the status of each device in an online dashboard while the customer receives raw sensor data in a cloud storage service for predictive maintenance. To tackle the defined goals, we need to build software to connect to the sensors and actuators, store data in the cloud as well as display aggregated data in the dashboard.

The spectrum of technical domains involved in this project is typical for and the key challenge in IIoT product development. They involve hardware design, firmware implementation, wiring, testing, device management, prototyping, UI&X design, cloud connection, and data analytics, to name only a few. It is clear that this cannot be done by a few people only.

Every product, no matter how technically sophisticated and interesting, ultimately has to be attractive to our customers. Clearly, our focus must be on what our customers want, need or could use. We want a profitable product which will be accepted by the market. So we have to create a good foundation for our product by making the right decisions.

The costs of wrong decisions

The fear of making wrong decisions can be paralyzing. When potentially wrong decisions have enormous consequences, e.g. generate high costs, ideas can come to a stop. In software development we are used to simply trying things out. Without a lot of engineering work, an idea is quickly validated and just as quickly discarded. It’s easy because we can try out our ideas on our computer with methods and tools that allow for cheap, rapid prototyping. So it happens from time to time that a wild idea turns into the next big thing, while another one crashes without big consequences.

Often, wrong decisions arise from not knowing which questions need to be asked and answered. They include: What is needed for our PoC? What is irrelevant? What do we have to achieve for a profitable product? How can we split up the idea into small, manageable parts and address each independently?

In our example, it was clear that the PoC must keep the plants alive and growing. It was not important to reach the ideal temperature with 0.1°C accuracy or have the smallest possible power consumption. The availability of sensors and actuators had to be above 99%. Therefore we use simple, resilient systems.

Many of these questions define how we tackle and present the PoC, but they also address who has to join the project early on. Who might be interested in the project and its development? We need people from different backgrounds, mainly from OT (operational technology) and IT.

Why change from OT to IT & OT?

In OT, if we need a PoC, we will have to build the device itself, i.e., we need machines, space and other people’s help. In IT, we can create a PoC with a small, focused team. Combining IT with OT allows for a PoC to be reduced to the most essential hardware parts while implementing or simulating the remaining parts in software. Thus, we quickly learn and iterate through what works and what doesn’t before building the first version. These increases in speed and flexibility, along with the reduction of required machines, personnel and space, save costs.

Furthermore, we can base our PoC on open-source software (OSS) and a flexible prototyping language, e.g. Python. Instead of building everything from scratch, we start with a more general framework. This framework may not be the optimal solution for our product, but it simplifies the prototyping. Instead of having a complete team dedicated to the project all the time, we can start building simple components with the staff we actually need, while the rest of the team contributes to other projects. Combining IT and OT frees up resources while using the needed ones flexibly and efficiently.

So instead of sticking to just OT or IT, we combine their strengths and abilities. Both are engineering tasks, therefore many principles of one field are applicable to the other. Many modern methodologies from software development are easily applied in the context of hardware engineering and vice versa. This leads to new decisions, e.g., do we fail fast with a prototype or do we do accurate engineering and develop a complete proof platform? By combining IT and OT, we reduce the costs of wrong decisions and increase the speed with which we verify our ideas.

How to deal with preconditions

So now we know how to understand the different decisions, what and whom we need. We have chosen our hardware, the requirements of our software and what we actually want to achieve. All these decisions create more boundaries than we expected.

In IIoT, many sensors, actuators and controllers communicate with each other through a number of protocols. Each protocol has its own advantages and disadvantages. Each protocol has to be implemented in software and hardware and has to be maintained. Thus, the more protocols there are, the more overhead and redundant tasks are potentially created. Are all these protocols really needed or is there one protocol which most devices support? Could replacing one sensor with a similar one using a different protocol simplify the architecture and complexity of the software? Can the cost of too many protocols be reduced?

This applies elsewhere, too. Are all the features and abilities seen as “must-haves” really must haves at the current state of the project? Would they be better suitable for a second roll-out? Would a simpler product shorten the path to the market, thus reducing costs and time to initial release? It boils down to having a clear, simplistic answer to what the project has to achieve and why it has to do so.

All this must be handled within the scope of the budget. This is one of the many strong points of open source: it is free and we can contribute new features. The number of features and devices of the PoC also increases cost. Are they really essential or can we simplify our design and have a first, simpler but profitable product? In the age of big data, even data gets a price tag. What data do we really need, how often and where?

In the end, all preconditions are connected to time. Time we need to plan, time we need to order and receive hardware, time we need to design software, time for testing, time for fixing what went wrong and time for presenting the product to the company or our customer. So where can we save time? Which process needs to be improved or slackened to reduce time to market?

In our case, significant parts of the hardware were chosen by our customer, e.g. the main control unit, the temperature sensors and the watering system. They decided what protocols were to use, what interfaces had to be present and even the programming language. The customer will sell different versions of the units to allow the plant grower to choose between a cheap and simple or a more powerful and expensive system. Sensors and actuators differ for different versions. Since ideally all we want to change between different versions is the hardware itself, we built our system to be highly flexible.

How to know if we decided right

The solution to these questions depends on the PoC and thus what it has to achieve. We have gathered experience, derived best practices as well as many ways on how not to do something.

We recommend the following:

• Make the product modular. Small components and segments, each interacting through an interface with the others, can be easily replaced.
• Define a timeline which component and segment is needed when and what has to happen before you start working on it. Plan to have all components working together as soon as possible in a simplistic way. Then, iterate and improve the part that is currently relevant. This implies building the system transparent and open.
• Build your interfaces and APIs generically. It does not matter which exact component is placed on the other side as long as it does the task required. If we notice that one sensor fails too often or a provider lacks a required feature, we change it.

Understanding which decision was right boils down to being able to change that decision with minimal cost if it turns out to be wrong. And there will be many wrong decisions coming from all parts and members of the project. If our product is resilient, if it can be easily improved upon and works even if some components or parts are removed, we are on the right track.

Who is doing what?

There are many jobs to be done. Someone chooses and integrates the hardware, someone develops the firmware, while others take care of the frontend and the cloud connection. These tasks must be done in an interdisciplinary team. An advantage of IT is that one can easily use a remote, distributed team. Expensive office space is not needed all the time.

A kick-off at which everybody gets to know each other in person is ideal. Clarify how everyone is being updated on the status, the scope and the tasks of the project. Choose simple, but effective communication tools. These tools will differ depending on the state of the project and the composition of the team. It has to be clear how topics are discussed, how requirements are structured and how the progress to success is measured.

Every member of the team must be able to say whether he or she is working towards the goal of the project or on a side project. Everyone needs to live the vision of the project. This is the most important outcome of the kick-off meeting: everybody has understood the vision, what the project is about, why it is important and therefore why the people who work on it work on it right now.

In our case, we had daily meetings with the development team and one with the customer. We were a small team of about ten people who were used to remote work and calls. A shared board with relevant tasks as well as a simple overview table of the progress of the PoC were available to everyone. This enabled our sales colleague to advertise and market the product properly.

Conclusion

We guided you through our experience with IIoT projects. The key obstacles of IIoT projects are their complexity, their requirements for many different specialists and wide range of required knowledge. Still, the steps to address these hurdles are similar to standard procedures in IT and OT. By combining both, we gain simple mechanics on how to tackle the project and reach market quickly.