How to Build an IoT Solution in 4 Basic Steps
Previously, we discussed how to build the right IoT mindset and the diverse skill set required to exploit the true potential of the Internet of Things (IoT). These are all critical and foundational to success. However, when it comes to development and implementation, it is also vital to understand the major building blocks of an IoT-enabled solution.
By incorporating these blocks, one can create a more detailed and robust reference architecture, which is a set of best practices for designing and developing an IoT solution. As a result, you can make sure that your application delivers greater value to the end-users by satisfying the specific requirements of each building block.
In this blog post, I introduce the major components of a typical end-to-end IoT solution in 4 basic steps and give examples to address them with relevant technologies based on my hands-on experience.
Challenge & Requirements
Recently, I had the opportunity to work on a project that aims at measuring the cycle time, as a part of wider Key Performance Indicators (KPIs), of a production line and each of its stations. The results had to be presented in a way that enables the users to immediately identify changing trends, and take further actions accordingly. The production line includes some legacy controllers that interact with sensors and actuators, but can only communicate with the outside world and exchange the data via vendor-developed protocols. The controllers neither had storage nor visualisation capabilities. Therefore, such valuable KPI data never really used for drawing actionable business insights. Remember, “the true value of IoT is in creating new experiences, improving processes, products, and services…”. How can we meet the requirements of this project?
Solution
Figure-1 below shows the high-level representation of a typical end-to-end IoT solution that consists of four major components: starting from sensing and collecting data, then applying some sort of logic, after that storing data, and finally computing information in order to create customer insights. Let’s have a look at each of them more closely.
1) Sense and Collect Data
The “things” part of the IoT refers to a wide range of sensors, actuators, tags, devices, and so on. One of the most obvious common features, is that these things are great sources of data required for further analysis. Basically, this step involves all kind of sensing and data collection activities take place within industrial equipment and their surrounding environment.
Today, unfortunately, only a very small percentage of industrial data is collected and used properly in a way that adds value to the business. The complexity of working with vendor-dependent legacy protocols is one of the most prominent reasons. Security concerns, poor integration, and lack of supporting architecture are among others.
In the project, the production line is broken down into several stations. Each station is built from moving actuators, sensors, stationary fixtures, etc., and controlled by a Programmable Logic Controller (PLC). Sensor data and all other state changes of the actuators can be collected if the correct logic is developed for the controllers. PC-PLC communication is handled by industrial Ethernet protocols provided by the automation suppliers (i.e. PLC OEMs). However, these protocols usually have custom specifications on top of TCP, and more importantly, do not provide any built-in security mechanisms. It is still fine to use them in a private-facing shop-floor network but can be a big problem in a wider network topology when security and interoperability related potential issues are taken into account. Furthermore, PLCs are either from different vendors or they are different models by the same vendor, which makes connectivity requirements even more complex. By starting small, then scaling up once a process that seems to work, each station has been addressed individually to include the whole production line in the end.
Considering the aforementioned reasons, I decided to use a leading connectivity platform called KepServerEX (already purchased by the company but never fully utilised) as a source of industrial automation data, and upgrade the proprietary protocols to a platform-independent, industry-standard one, OPC UA. Performing as an OPC UA server, KepServerEX provides data access for client applications in the solution. This gives the required flexible and reliable event-driven communication capability that insures data interoperability in an efficient way, along with advanced security options.
2) Apply Logic
Industrial IoT extends existing industrial IT networks. The protocols we use in an industrial network and a modern IoT-enabled solution are likely to be different. Usually, this is the place where we should address by a gateway solution in order to forward the obtained data to back-end services. You can host the back-end services either on cloud or on-premises depending on your needs. A gateway bridges the communication gap between two isolated systems. It can be a physical device or software program. In any case, it generally supports including, but not limited to the following functionalities:
- Protocol-related operations: translation, transformation, validation, and exception handling.
- Message-related operations: translation, transformation, encryption, enrichment, and filtering.
To satisfy this critical requirement, I used an in-house developed gateway application to transform the protocol from OPC UA to HTTP/S, and the message to JSON by removing unnecessary metadata.
3) Store Data
Without having data, you won’t be able to measure anything. And without measuring, there is no way to improve a process, product, or service.
“If you can’t measure it, you can’t improve it” — Peter Drucker.
Database selection is the first challenge at this stage. I have seen so many projects that follow the conventional known (also so called “secure”) ways for technology selection ignoring the actual use case. For instance, using a relational database management system even though there is no relation between records. The only reasonable explanation for this unreasonable call seems to be that the decision makers have lack of knowledge (or courage) of using other available options. I would recommend developing a solid understanding of your data needs as a prerequisite. Think carefully about the collected data; its volume, velocity, variety, and processing requirements before coming to any conclusion. Also, consider how the data should be stored, scaled, managed, and accessed securely. At the end of the day, all these factors have a direct impact on the success.
In my solution, the collected data is transmitted securely from the OPC UA Server to the HTTP/S endpoint through the gateway application. The back-end application server hosts RESTful APIs to deal with database-related operations such as storing and querying industrial data. Therefore, the end-users never have direct access to any database object. Moreover, the API layer makes data available for 3rd party applications, services, and platforms if required. The APIs are secured by user credentials and TLS (Transport Layer Security). Lastly, considering the specific characteristics of the data, I recommended using a NoSQL database that provides the functionality for handling time-series data.
4) Compute and Create Insights
Undoubtedly, the real value of IoT is in the data you collect. Having said that, it is not only about collecting and storing but also about answering the famous ‘so what’ question: “What are we going to do with all this data?”
“What are we going to do with all this data?”
From an end-user point of view, the hard work you put into the first three stages does not make a lot of sense, to be honest. Because they won’t be able to see or interact with those parts directly although we cannot talk about a solution without them. You must always focus on providing value to your customers through improved processes, operations, better or new products and services. In this way, you’ll be more likely to find success.
In the project, the stored data is processed by applying a variety of algorithms and then presented via highly interactive and responsive web user interfaces developed, targeting different end-user roles. For example, a technician monitors abnormal changes in manufacturing processes and sees push notifications referring to defined thresholds through a mobile device on site. This helps to increase machine utilisation and predict failures earlier and much more accurately. Simultaneously, back office engineers and managers are able to identify patterns and trends of cycle time easier than ever before. Thus, by using new insights, they can make data-driven decisions to maximise the efficiency and performance of the production line.
Finally, the figure below shows the high-level system architecture of the solution:
Conclusion
IoT is not a silver bullet to industry challenges but can provide key pieces to the puzzle of a digital transformation strategy if you know how to make the most of it in practice. Since we know there is no one single solution that would fit the specific needs of all IoT-based scenarios, it is crucial to understand the major building blocks of an end-to-end IoT-enabled application. In practical terms, I have shown how you can use a four-step approach to deliver stronger value to your customers by meeting their individual needs and expectations. Try to use it in your IoT initiatives and feel free to share your comments below!
Note: As always, if you have any further questions, do not hesitate to reach out! You can also follow my latest thoughts and updates on @KahveciSinan.
If you enjoyed this article, you might also like:
