In regard to how to position ThingWorx Analytics and Connected Quality

While you are correct that both tools can assist you with predictive analyses, I would really consider these two tools as being complimentary to one another, not overlapping.

First, let’s talk about the advantages of Connected Quality.  This tool was specifically designed with Reliability Engineering in mind, so we are focusing really on predicting how the item will fail.  As such, it provides access to several analysis tools that are native to the field of Reliability Engineering: accepted FMEA standards (i.e. MIL, AIAG, SAE), built-in MTB calculations, customizable workflow processes (i.e. 4D/8D FRACAS processes), etc.  It also has built-in reporting and graphing capabilities.

Connected Quality also has advantages as to when it can be utilized.  You can start your analysis in the early design stages of the system with very little in the way of historical data, whereas ThingWorx Analytics will require a historical data set to produce accurate results.  The more data you have, the more accurate the results.  Also, ThingWorx Analytics will also need information on successes in addition to failures to get a good baseline, which may not necessarily be something a customer would capture in a standard FRACAS for example, where failure events are going to be the primary focus.

ThingWorx Analytics has the advantage when it comes to versatility, in that it can be applied to fields other than Reliability Engineering.  It will also be very useful in scenarios where you have a comprehensive historical data set, consisting of data on both failures and successes.

Now, let’s take this one step further.  What if instead of thinking of these tools as two separate entities, we used one to augment the other?  For example, if a FRACAS user was capturing data surrounding failures in their systems, processes, etc., maybe even data that may seem extraneous at the time, and also capturing data on successes related to the system or process, and then feeding that data into ThingWorx Analytics, this is going to be a powerful combination.  The predictive engine is going to help speed up the root cause analysis process by quickly identifying the top failure drivers in the system for us, or it may help to connect some dots that a user may not have even thought about previously.

In the case where we may not have enough data from our failure analysis to feed into ThingWorx Analytics just yet, we could use the preliminary results from the reliability analysis to help us determine where we need to place sensors to capture more details surrounding a failure to give us a stronger data set to supply to the analytic engine.  Is our equipment prone to overheating?  Let’s get a temperature sensor in place to monitor the operating temperature of critical components in the system.  Is our CNC machine’s cut precision an area of concern?  Maybe we add in a vibration sensor to help with the analysis.  The more data we can capture surrounding our failing components, the better our chances are for identifying the root cause of the problem.

So as you can see, while both tools are useful in their own right, each can really benefit from the other as well.  I hope this explanation helps!