Are you an IIoT startup grappling with customer engagement or on-site implementation issues? If this sounds like a familiar problem, here is an insightful point of view from an industry veteran on what can go wrong and the best way out to achieve a successful IIoT adoption.
In this edition of the fireside chat conducted by TiE Industrial SiG, we summarize the learning and insights from Raman Vaidyanathan about IIoT adoption. Sushrut Mair caught up with Raman on the 9th Dec 2022 and Raman has some straight-to-the-point advice on what works and what does not work in IIoT.
Raman Vaidyanathan brings over 35 years of experience in embedded systems and IoT design and development. He has had stints with Alstom, Siemens, and Tech Mahindra and currently serves as a senior technical advisor to Cyient. Raman touches upon the typical scenarios in the IIoT project engagements and draws from his rich experience and failures to provide insightful recommendations for startups and companies to mitigate the risks associated with IIoT.
The Incubation Drag in IIoT Projects: First PoC, Then Pilot, and then Stalemate.
Raman uses the term “PoC syndrome” to describe this situation, wherein a startup or a service provider jumps into the implementation of multiple projects by proposing a PoC, which never sees the light of day. This syndrome is witnessed more in IIoT projects compared to other domains. It is a result of a long incubation cycle which ultimately does not lead to any value for the business.
Raman fully concurs with this trend and further adds that these issues were also faced earlier in IoT wherein a company would execute PoCs after PoCs and since the technology was new and untested, there were challenges that could never be discovered and addressed at a PoC level. It is also a case of a solution looking to find the problem since many IIoT projects are taken up as a technology-led initiative without identifying a use case that really adds value to the business. And since companies grapple upfront with identifying the use case, there is no firm commitment or understanding at the time of commencement of the PoC project.
According to Raman, this problem of PoC syndrome is more profound in IIoT, since IIoT involves cross-collaboration across IT and OT teams. In most organizations, these two departments operate in silos. The personnel in both these departments have different worldviews, which are influenced by their workspace, as they operate different systems with different technical architectures. They do not talk to each other. This creates a significant barrier to integrating these two departments to arrive at a business outcome. As a result, the business unit head sponsoring the PoC has no definitive guarantee of the success of the engagement.
From PoC to PoV (Proof of Value)
Raman emphasizes that PoCs are done in a controlled environment where these integration challenges are not considered. But after moving on from PoC to pilot, there are these real-world interpersonal challenges. Stakeholders on the shopfloor would not give a buy-in for implementing the pilot, and the CDO (Chief Data Officer) would not have links with the engineering teams or the on-ground staff to convince them. These and other similar challenges result in nearly 75% of the projects being held up without being fully operationalized. All these problems culminate in a situation where the emphasis is more on the technology outcome, rather than the business outcome.
Raman points out other critical aspects, such as security, which become an impediment to the success of IIoT adoption. As an example, in some deployments, having a wireless IIoT system component is not allowed, since it can lead to a breach through the wireless medium. This is also applicable to IT policies, which sometimes block OT access, resulting in barriers to integration. These problems are mostly identified only in the pilot stage, and they can further complicate the further rollout.
As per Raman, for large enterprises, the scale of implementation further complicates these scenarios. Large enterprises need to see the IIoT adoption across the board, to realize the full potential of Industry 4.0, and realize any ROI from it. But due to these stumbling blocks, the ROI is never seen and consequently, there are budget constraints imposed on these projects. For a startup trying to meander through these challenges, the integration complexities, and additional delays, it can be the death knell.
Raman’s advice is to have a good amount of interaction and due diligence upfront to identify the business value and ROI potential, before committing to any PoC, and just not look at the technical feasibility alone. Raman also warns against committing to PoCs without the cost to the customer, which is essentially a free PoC, since such engagements are not taken seriously by the customers and the perceived value proposition of the PoC is diminished.
Raman's mantra is to look at PoC as a PoV, that is, Proof of Value, which prioritizes business feasibility over technical feasibility for every IIoT deployment.
The Ideal Engagement Model for IIoT Startups
Raman’s advice to startups is to put more effort into the contract and the nuances of the engagement. One of the main points to consider here is: how the PoCs will be tied down to a list of success criteria to move to the pilot phase. Similarly, success criteria for the pilot must be defined to move to the next phase of the rollout. All of this boils down to defining a clear demarcation of phases and success/exit criteria for phase transition.
Also, Raman’s recommendation is to commence the pilot in a sizable number of sites, so that all the additional, unforeseen effort during PoC can be realized as a substantial revenue. All these considerations must be agreed upon with the customer side stakeholders, and technical and business unit sponsors, along with a commitment to budget and a clear policy from the management for the implementation. It is also important to undertake a survey to identify the manufacturing plants and classify them based on legacy, and modern equipment so that the integration challenges can be estimated beforehand. Overlooking these things may lead to bottlenecks in rollouts when the plant environment for PoC or pilot is different than the actual rollout.
Raman cites one example from his experiences where he witnessed differences in cultures and local equipment configurations across plants in different geographies of one Tier 1 automotive company. If each of these plants is run independently as a separate center, and the company does not have buy-in from the plant management, then rollout becomes a hurdle due to these factors as Raman explains. In the worst case, a rollout in a different geography becomes a separate pilot project which ends up burning efforts and resources for customization.
Raman recommends IIoT startups tie-up with service providers and system integrators to approach large enterprises. Startups are inherently perceived as risky and any big enterprise would want to have some commitment and support for their large deployment base which can easily exhaust the resources of any startup.
Therefore startups should project themselves as technology providers and should align with a limited set of verticals within a service provider to take IIoT solutions to potential large customers.
Addressing the Diversity in Shopfloors
Raman agrees that different manufacturing setups have equipment having different connectivity interfaces, such as Modbus, ZigBee Ethernet, or some form of wireless interface. This poses a challenge in the overall project implementation because the PoCs might be done on one interface, and pilot and rollout need to happen across multiple interfaces. These considerations should also be taken into account during PoC or pilot phase. Irrespective of the different interfaces, there is a need to aggregate them into a common platform so as to make the data available in one place, preferably at the edge. Further, the data processing at the edge should be segregated into realtime and non-realtime requirements, such that data associated with realtime processing can reside at the edge, while the data associated with non-realtime processing can be pushed to the cloud. For enhanced performance, the edge gateway can be connected to 5G or similar faster communication technology. All these architectural considerations must be thought out at the PoC or pilot phase of the project to ensure the proper rollout, and that is where the survey is very important as emphasized by Raman during the initial discussion on engagement.
As per Raman, today the challenges around multiple connectivity interfaces and pulling the data are already solved. But finding out the right information from the data is still a challenge. This is due to diversity in different domains and process operations performed by machines so that predictive analytics can be leveraged. As an example, if there is a five-axis machine performing a milling operation for 10 hours, then the predictive analytics should kick in to stop the operation if some parameter of the process is not within permissible limits, to avoid the risk of faulty product coming out of the process after wasting 10 hours. An even bigger challenge is to ensure that the machines are not held up during the PoC or pilot implementation.
As per Raman, there is this additional challenge in the case of legacy machines, to understand the process parameters. Legacy machines were designed with diagnostic capability which alerts the operator in case of faults. But these machines did not possess any capability for aiding in the prediction of faults. Many a time, a hack or a surrogate method is needed to extract parameters that can predict a failure in such machines. In modern machines, data can be directly pulled. However, for legacy machines, there is a need to put additional interfaces or external sensors to pull the data. These activities require additional customization and also subject matter expertise on those legacy machines.
Raman observes that there is also this issue of the pile-up of faulty parts getting produced through automation. In such cases, drifts in production parameters are not arrested and it is assumed that the manufactured parts meet the quality parameters, since the entire process is automated, only to be discovered later that this was not the case. This is also applicable in robotic automation wherein instead of employing image-based analytics on the outcome of the process, the parameters controlling the robotic arms are measured to predict failures.
Raman also notes that there is diversity across the size of organizations. For large enterprises aiming for Industry 4.0 adoption, the challenges are different that the small and MSME industries, which are still in the industry 1.0 or 2.0 stage, especially in the context of India. Also, many of these small industries employ cheap manual labor and employ a host of Jugaar measures to make things work without automation and much investment. Such situations are not conducive to the implementation of standardized IIoT solutions.
Finally, the cost is also a big issue for smaller industries. Therefore rollouts tend to fail as a result of using low-cost sensors which do not meet requirements. The cost factor is applicable for IoT also, as Ramam recalls one use case which needed accurate location tracking for mobile pushcarts selling perishable food items, but the pilot was plagued due to a low-cost GPS device giving hugely inaccurate location readings, even though the PoC had earlier gone very well with a better device. But due to the huge number of pushcarts, the cost of the GPS device had to be brought down to suit the budget feasibility, ultimately leading to the project being shelved.
The Fusion of IT and OT
Raman has some interesting viewpoints on the fusion of IT and OT which is a critical factor in the success of any IIoT solution. Raman states an example of asset management and production planning. Historically, asset management was a static operation and nowhere linked to production planning. With IoT, asset management becomes more dynamic. For example, if one looks at the power tools used on a shop floor, then it is beneficial to know the operational state of these tools and their remaining useful life. With dynamic asset management, these data can be captured and that helps in production planning since it is easier to know if the tools and usable and available or not. Additionally, tracing the power tools within the shop floor, tracking their usability parameters to detect misuse or failure, and tracking their utilization helps thwart any unforeseen circumstances in production planning.
This is one of the ways in which the IT systems can provide a complete view of the assets required in production planning, through an interaction with the power tool’s data interfaces that comes under the domain of OT. Apart from the production planning, there is an opportunity to leverage IT to better manage the OT assets, such as by geo-fencing the power tools so that their movement outside the premises is detected, and they can be remotely disabled.
Raman points out aerospace and automotive setups as the main industries which benefit from this type of IT OT integration as these are spanned across a large area with a large number of power tools. With IoT, it is also possible to offer the power tools as a pay-per-use model, such that all the operational, availability, and maintenance of the power tools are managed by the power tool manufacturers, and the manufacturing companies pay for the actual usage only, instead of purchasing the power tools. This opens up newer avenues for power tool manufacturers and also offers flexibility to the customer. One such example is the useful information about the power tool which helps in identifying if the tool is being used in the correct manner or not. This is especially applicable to the aerospace industry, where safety is a first priority and it is impossible to manually inspect some operations, such as the holes being drilled and screws being fixed in the fuselage. Under this circumstance, the power tool can provide some information to certify the correctness of the operation, which can be immediately vetted, rather than spending time post-inspection.
We thank Raman for giving his time to share his valuable experience with IIoT. You can follow or connect with him on Linkedin.
