Limitations of pre-IoT era digital representations
While the as-designed view of the asset and associated insights are useful, there is seldom direct feedback that designers obtained about the assets in the field. Service engineers would document the failure or performance misses of the asset, and only in situations where there are recurring part issues, that information would be sent all the way back to the engineering design teams. Designers were also not aware about the product performance in the field – even if there were no failures. In other words, they seldom had an ‘as-used’ view of their design. Based on certain rules and design limitations laid out by the designer, the service engineer would evaluate the product, and, as long as any recordable readings of product performance were within limits, the product was deemed to perform as per design expectations.
The era of IoT
As internet connectivity spread, humans became more interconnected, and thereby had access to more information. Cloud-hosted consumer and enterprise-focused applications became popular. Around the same time, businesses began exploring the benefits of machines being connected to each other – and, subsequently, also to the internet. Machines talking to machines, so-called M2M communication, was again not new; such communication was quite popular in the manufacturing industry. Connecting machines to the internet was, however, new. By connecting machines to the internet, convergence of operational technology and information technology became a reality. Product (or asset) manufacturers introduced sensors and connectivity mechanisms into their newer “smart” machines. Manufacturers created sensor-enabled, internet-connected boxes that allowed operators to connect their “dumb” brown-field equipment to the internet. Data analytics, ML and AI services moved to the cloud, and sensor data, performance statistics, and associated insights could be displayed on cloud-hosted dashboards. With just cellular or WiFi connectivity, machines deployed in the field could now communicate to the internet. Asset operators could monitor equipment performance from anywhere. The current IoT era was born. This era also led to the so-called fourth industrial revolution, or Industry 4.0.
Before long, service engineers began asking how performance data could be exploited to provide better customer experiences and also optimize after-sales service agreements. If there was no real need to shut down and service a machine, you didn’t have to! This meant no more unplanned downtimes, which ultimately led to improved customer experience. Now, IoT provided manufacturers with avenues to boost bottom line profits. With so much data – more so, in near-real time – coming from the machines in the field, engineers could evaluate whether there were anomalies in the field data and recommend condition-based maintenance. All of this data was encapsulated in a digital twin of the asset. Design engineers began providing design insights on the asset to the service engineers, and companies augmented the digital representation of the asset with physics-based models, probabilistic techniques, machine learning, artificial intelligence, and immersive visualization. Both cloud-hosted and on-premise applications that provided insights to field engineers and designers alike gained in popularity. In the current IoT era, such digital twins found a unique role in any digital transformation journey.
Limitations of current IoT era digital representations
Digital twin representations in the current IoT era clearly are extremely useful, however, given the numerous flavors of digital twins, not all references to digital twins are consistent and uniform across the industry. Each variant has some unique limitations. Actionable insights associated with each of these digital twin representations are also very different.
For instance, a digital twin that contains only the CAD data model and field sensor data allows engineers to perform prognostics and visualize how the asset is performing in the field. However, these insights are not enhanced by insights obtained from design of the asset. Here, the link between ‘as-designed’ and ‘as-used’ states of the asset is not complete. Even with this representation, however, the engineer can determine anomalies in the sensor data and flag them appropriately so corrective action can be taken. In the absence of expert guidance or a thorough root cause analysis, this representation does not necessarily shed light on ‘why’ the anomaly occurred.
When this representation is augmented with design insights, engineers gain an understanding from the design phase as well as from field performance of the assets, and therefore the link between the ‘as-used’ and ‘as-designed’ view of the asset is maintained. Clearly, this representation provides the engineer with a better ability to identify the root cause of the anomalies by comparing performance with design considerations and taking corrective action. This insight can impact how the asset is designed.