The heart of the promise of IoT lies in the realization of the value of the insights created from the data. Business owners implementing a Digital Transformation strategy continuously ask themselves, “Am I receiving critical information which is helping me to improve my business?” and “Am I getting the Return on Investment (ROI)?”. Very often the answer is “Not yet”. There are many reasons projects often get stuck in “Pilot Purgatory” – and in this article we will focus on the path to success – and how to ensure bright IoT ideas can reach their “Proof of Value” (POV) destination quickly.
Use the Keep it Simple Stupid (K.I.S.S.) method to define the MVP, which should likely include:Just like any project, IoT Pilots are subject to scope creep. And given the nature of many of the digital transformation objectives being more ‘art of possible’ – it is important to take a step back and create a Minimum Viable Product (MVP) approach which starts with only the most crucial requirements needed to ensure that the foundation of the system ‘works’. You can’t build a house without building the groundwork first. Furthermore, don’t forget to build into the pilot the “Why are we doing this” business goal. Without crisply defining technology goals that dovetail into business strategies, IoT projects are destined to die in the lab as a ‘science experiment’.
The first challenge is simply ‘connecting’ existing machines/devices into a common data repository. Often in OT, devices live on ‘islands of information’ – that is they are completely autonomous, and not operating within the overall context of the organization. Basic data integration first requires that the information from the device is liberated from its proprietary heritage - often through an edge gateway with built in protocol conversion capabilities. Once interoperability is achieved on the ‘south bound’ (gateway to device (or sensor)) the problem gets much cleaner to solve. Common protocols like Modbus are typically much easier to convert to more IT friendly formats such as OPC – or even to altogether new protocol transport like MQTT – which are more ‘cloud friendly’. However, there a dozens of OT protocols and fieldbuses which require very specialized protocol conversion capabilities to support even more obscure formats such a PLC protocols.
Northbound connectivity is the potentially more complex half of the equation, as this is where the OT truly meets the IT. For example, is your destination a ‘cloud host’ like Microsoft Azure or Amazon Web Services (AWS)? Or perhaps some hybrid OT/IT IoT platforms like ThingWorx, Siemens Mindsphere, etc? Does your edge device handle the conversion from OT protocol to IT formats (like MQTT) and/or payloads over rest based web services?
A critical component of any IoT solution is to ensure that it adheres to your company's (and your customer’s) IT/Security guidelines, therefore comprehensive security policies are required to ensure success. When choosing a solution, equipment manufacturers need to follow best practices regarding cybersecurity. Taking guidance from common standards like ISO27002, IEC 62443-2-4 and NIST Cyber security Framework 1.1 is strongly recommended. This means choosing a solution that employs a defense-in-depth approach, so that no single point of failure will cause the solution to become compromised. Additionally, the way in which remote connectivity is achieved should be considered. Does the solution have crucial cyber security certifications like ISO27001? Has the solution undergone penetration testing? Is there an audit trail of connections? Is there control over when the solution is active and who can access it? The answer to all these questions needs to be yes.
Sometimes a quickly assembled pilot might pass the “hello world” test, but that does not mean it is an indicator of production ready environments. It is important to truly stress test an application in different ‘real world’ environments and ensure that several stakeholders all can witness the same repeatable success. Often, it becomes valuable to actually exceed the limits of the design – to potentially learn about how the solution may outperform the specifications (or at least learn new boundary edges to avoid). And if failures happen, was it easy to update? How do you define easy?
Assuming you pass the robustness test, it is also important to understand if the solution can scale. One or two pilots might be manageable, but can the solution easily be amplified to 50 or 100? Defining availability requirements up front ensure that your customer are not disappointed when they finally trust you on that big order!
An example of defining the connectivity, robustness and scalability might be something like:
“Pilot just begin no later than July 15 and must be proven no later than August 31”
“Using Modbus TCP Connect to PLC and read 10 Tags (specify which) as 1 second interval and communicate to data historian (define app) via OPCUA over local network (define protocol/payload) and also Microsoft Azure IoT Hub (via MQTT) with data logging and HTML web page data value readout status on local on edge devices for period of 1 month without any failures”
“Data values indicating equipment health must reliably communicate a ‘Red, Yellow, Green” status on customer site (define customer) with daily solution status update to key stakeholders for 1 week to prove our new 2020 Smart Machine Service initiative in time for Fall launch on Sept 15”
My grandfather always said, “Measure Twice, Cut Once” and that mantra holds true especially when creating new Proof of Value strategies. Create a great plan and make it realistic, and you can fail fast and learn - or potentially succeed fast and WIN quicker! To learn more on how HMS Networks can help you on this journey visit our digital transformation page: