Not all IIoT platforms are created equal
Having the best Industrial Internet of Things (IIoT) architecture with the most modern and state-of-the-art technology will not benefit any company unless it is tied to a specific purpose and business outcome.
The Internet of Things (IoT) or Industrial Internet of Things (IIoT) is not an end in itself. It should exist to achieve some purpose. The purpose can be to solve a business problem, increase operations or supply-chain efficiency and effectiveness, or enable more accurate tracking. Many reasons or business cases are out there along with an equal amount of business questions to be answered. However, companies sometimes ask the wrong question. The question is technology and architecture first and business value as an after-thought, where it should be the other way around.
Having the best architecture with the most modern and state-of-the-art technology will not benefit any company unless it is tied to a specific purpose and business outcome. If the technology does not answer the business question or solve the business problem, it is money wasted. In light of the above, the first question in the IIoT journey should then always be why?
Once the company knows what operations challenge to solve, the next question is on where to start? What plant, support service, logistics, warehouse or utility problem should the company focus on first. This is important because the company wants to show value and payback with the first project. However, the company should not be limited in thinking and design for the limited scope. It is a fine line between delivering a pragmatic solution to a specific problem and creating a long-term global vision for the company.
That brings us to the how? Many companies are great on the what, but very light on the how. We also need to answer the how question to make IIoT strategies real for companies.
IoT and IIoT architectures defined
Considerable time has been spent defining IoT and IIoT architectures by local and global forums. The IoT World Forum Reference model come close to defining a good overview model. The reference model below contains all the elements/components required to provide a complete IIoT solution for real-world challenges.
The IoT World Forum Reference model contains seven layers. The model outlined here has eight layers to make a distinction between local connectivity and global connectivity.
For us, machine-to-machine connectivity, or instrument to edge-device connectivity (such as Bluetooth, Smart Bluetooth, Zigbee and Wi-Fi) is not the same as what is classified as global connectivity. There are, of course, those like Sigfox and LoRaWAN that can be seen as both local and global, but they are usually sold as global connectivity solutions. In terms of the IoT World reference model, this is the only area we deviate.
For IIoT, the local connectivity is the area that will make or break any solution. By virtue of the real-time environment IIoT operate in, sound local connectivity is critical in the successful implementation of any solution.
Technology providers, whether hardware or software, will tell you about their “IoT platforms.” When evaluating platforms against the above reference architecture, most platforms are incomplete or if they are complete, it is only for a specific niche area.
Having evaluated a number of vendors “IoT platforms”, it has become clear vendor “platforms” fall into two broad areas, those with a hardware focus (levels 2 to 5) and those with a software focus (levels 5 to 8). Evaluation also indicated that for software-focused “platforms,” those platforms are typically strong on levels 5 and 6 with levels 7 and 8 available only for niche functionality.
Reading up on completed IoT projects, it is apparent that the above is a true state of affairs. It is estimated that a complete, value-adding IoT solution involves an average of 20 to 35 vendors. This is not necessarily a bad thing, as different customers have different requirements, but it does mean more points of potential failure. Some customers may have the bottom layers sorted out already but need a software platform and applications and others may need connectivity between the lower levels and their existing software applications.
Factors to consider when selecting a platform
There are a lot of things to consider when selecting an IIoT platform and implementation partner. The types of services and service model provided by the vendor is important. Although most platforms are moving towards cloud and an as a service model, some still provide capital expenditure (CAPEX) and on-premise solutions. Especially for IIoT in industries where real-time feedback and response are critical, this is a major consideration. For these some vendors also make a hybrid model available, where fast response edge devices and/or applications sit at plant level and reporting, data analytics and dashboarding is done in the cloud.
Domain expertise or platform use-cases are also very important, especially within the IIoT environment, as is the reliability of the connectivity, data storage and data extraction for business value. It is also important to know how easy it is to manage the devices connecting to the platform and how easy the support of the platform and devices are going to be.
Cost or the costing model needs to fit the business need. Here it is important to not only look at the current business need, but also at the big (future needs) picture. Although a low per-device cost may be appealing for a small implementation, it can get very costly very fast. It is also important to understand how compatible the platform is to the business and how it will connect to the current infrastructure. Scalability and security are very important, not only from a cost perspective but also from a device management and support perspective.
Platform security is a factor which is easily overlooked. Security is applicable across the various layers. It is important that any device connected to the platform should be authenticated and the communication channel should ideally be encrypted. The platform itself should be able to securely store the data and allow access to the data and dashboards based on grouped user rights such as administrative rights, write-back, read-only, and which sets of data that will be visible to which group.
The last big consideration is the tools and ability to integrate and handle data, both from bottom (level 2) to top (level 8) also called north-bound integration and top (level 8) to bottom (level 2) also called south-bound integration. This is very important as some vendors are very good at north-bound integration but struggle with south-bound integration.
Especially for IIoT, the ability to send information down to instruments is very important as pure reporting within a fast-paced environment will be inadequate. Look specifically at the drivers or protocols supported by the platform and ensure that it supports IIoT protocols such as OPC, fieldbus, Profibus, etc., for south-bound integration and have adequate API’s, etc., for north-bound integration. Again, access to the data should be secure, authenticated and tracked.
When selecting an IIoT platform it is very important to work through the various factors to ensure the platform fits your specific long- and short-term needs.
Functionality required by an IoT platform
Looking at the full stack of IIoT, a number of functions need to be available in the IIoT platform to ease the implementation and reduce the number of vendors involved in an IIoT solution. The platform needs a front end or user interface development environment that is user friendly and easy to use. It must make provision for and enable the handling of a variety of communication protocols, both northbound and southbound. It needs a user interface that enables device management, device status monitoring and device grouping. The platform needs to provide a data storage environment that is scalable and secure, but allows easy data access and retrieval. It also needs to provide tools for the easy development of dashboards for live values and trending as ultimately, this is the view the customer needs to make better business decisions.
Although multi-tenancy (one platform for multiple and separated users) is not required by all users, it may be that a company wants to segregate data within a platform so that not all data are visible to all users and each user company can have their own branding and “look and feel”. When used specifically in the IIoT environment, workflow management, notifications, and alarming are very important to inform plant operators, supervisors and managers when things do not go as planned.
Tools need to be available to enable advanced data analytics, such as machine learning (ML), advanced pattern recognition (APR), artificial intelligence (AI), robotic process automation (RPA) acoustic analysis and facial and image recognition. Ultimately, these tools will increase the efficiency and effectiveness of businesses when applied correctly. If the platform does not have these tools (and very few do), then at least the data should be available and easily extracted via standard tools and protocols into other applications that have these tools available.
The platform needs to be flexible regarding where it will be hosted, especially for IIoT as a hybrid model will probably be the most effective, specifically for real-time process industries. The availability of after-sales and platform back-end administration support is also very important for a long-term sustainable solution.
Not all platforms are created equal. To get the best IIoT platform, companies need to take the time to evaluate the vendors. Look under the hood and ask the vendor to explain how the vendor incorporates the various consideration factors. Look at all eight layers, determine what is part of the platform and what is “bought-in” third-party functionality. Find the best fit to solve the current and future business problems.
Gerhard Greeff, MESA EMEA Board Member. This article originally appeared on MESA International’s blog. MESA International is a CFE Media content partner. Edited by Chris Vavra, production editor, Control Engineering, CFE Media, email@example.com.
Original content can be found at blog.mesa.org.