In the past few months as work progressed on the VDC Embedded Cloud report, I posted a few blogs on classic examples of M2M connectivity and the values that can be obtained by many stakeholders. Even so, I believe many M2M cases do not fully extract all of the value that can be obtained by that connectivity and, in particular, the data that is collected, processed, and stored in the cloud. In this blog, I thought I would explore in more detail two examples of M2M connectivity to look for that elusive added value.
M2M Example 1: Semiconductor Tester - The latest versions of Advanced Mixed Signal/System on Chip testers have to perform faster than the chips they are testing and are likely using liquid cooling systems. The timing of the digital channels have to be perfect and, at the same time, precise analog sourcing and capture channels are needed for the many analog functions found on the system on chip devices they are testing. These testers are typically on isolated networks as device speeds, capabilities, and product yields are highly confidential particularly during product development. These testers are typically used 24 x 7 and downtime is particularly expensive.
If that semiconductor tester could be connected to the suppliers cloud service, significant value can be seen by all participants especially the owner. The cooling system would be a prime example. In many cases these are closed loop systems and a low level of flow or coolant and/or a high temperature reading can shut the system down automatically. If these sensors could be polled and the data stored and processed, the system owner or supplier could be alerted to possible problems before they cause a shutdown. Small coolant leaks could be detected and mitigated before they cause issues. If the data were made available to coolant suppliers, they could proactively deliver new stock on a just-in-time basis.
Semiconductor testers can generate a lot of data in the process of calibrating and testing themselves. If that self-test and/or calibration data were moved to the cloud it could provide more value by using processes that compare past results with current ones. Even tests that pass in both cases can be statistically evaluated to look for drifting toward limits. In this way, a digital or analog channel boards could be removed before they failed in the middle of a production run.
Now, we will take it up one more notch. If the self-test data from all of the tester supplier’s customers were aggregated in the cloud they could provide even more value particularly in cases where failures occur. By comparing the data from a current failure with those that happened in the past, it is likely that a root cause is already known and therefore can be quickly applied by the service personnel.
If you think that this is all the value that can be extracted from this case of M2M, you would be mistaken. If the semiconductor tester could sense that another machine in the test cell was down, it could run its own self-test programs to take advantage of the lull in the action. If a time based calibration was needed in the near future, it could pull that in as well. In the failure cases noted above, the cloud based data could be used in a Failure Reporting and Corrective Actions System (FRACAS) which might identify problems with a particular component or batch of components. This type of data could be filtered and shared and the benefits would be seen by multiple OEMs as well as component suppliers.
M2M Example 2: Wind Turbine - In some cases, wind turbines are individual units and, in other cases, they are part of a large array of units. This can represent a very fragmented deployment as large arrays are likely in remote areas and single units are very spread out in more populated areas. This makes the service model a lot more complicated both in regards to equipment and personnel. From a personnel perspective, you need expertise in electrical, mechanical, and aeronautical systems. The fact that they are so large and high also requires crane and rigging and heavy construction expertise as well. If the array is located offshore, that is another area of expertise that might be needed. From what I know, wind turbines don’t fail that often but, when they do, the convergence of material and expertise needed to fix them can be costly with respect to downtime and expenses.
M2M connectivity could benefit wind turbine installations by providing them with advance knowledge of wind gusts and anomalies for which they could adjust in advance. There are lots of sources for this kind of data from satellites, radar, and sensors located in many places. Aggregated and processed in the cloud, they could provide actionable intelligence for a turbine operator. On a similar note, this type of aggregated data is of high value to grid operators as they need to level out the supply of wind-generated electricity with the demand of the customers.
As in the semiconductor tester, I believe there are several ways the service model I discussed could be made less expensive. A wind turbine is likely chock full of sensors that detect motion, position, and most importantly strain on components. The rotating blades are very heavy but need to be balanced and oriented precisely. If the data from the turbines are moved to the cloud, degradation of components could be detected before outright failure.
Now, we look to a higher derivative value of the aggregated wind turbine data. If a wind turbine blade begins to have a problem and the sensors detect it, the owner has a tough choice to make because of the logistics and expenses that could be involved in the repair process. If the owner, crane company, and/or repair crew, knew there were other wind turbines in that area that also had problems, costs could be shared.
In the final embedded cloud M2M value derivative, the supplier of the wind turbine blades could use the aggregated data from all of the deployed turbines to learn more about strains and product failures to improve designs and production processes. If needed, they could begin to produce a replacement part on proactive just-in-time basis rather than having to maintain a significant inventory.
Summary: In both the tester and turbine cases we see where the primary stakeholders such as the equipment owner and the supplier that made it have tangible benefits from the M2M cloud connectivity. The interesting but sometimes less obvious benefits come from other data sources and where the equipment data can be used to provide benefits to other stakeholders. In each market, these secondary and somewhat elusive opportunities are there for the taking but only to those who look for them.