IoT Tips

    Use Analytics Manager to automatically perform engine analytical calculations.   Guide Concept   This guide will use ThingWorx Analytics Manager to compare external-data from an Edge MicroServer (EMS) "Engine Simulator" to a previously-built analytical model.   Following the steps in this guide, you will learn how to deploy the model which you created in the earlier Builder guide.   We will teach you how to utilize this deployed model to investigate whether or not live data indicates a potential engine failure.   You'll learn how to   Deploy and execute computational models Define and trigger Analysis Events Map incoming data to the Model Map analytic outputs to applications   NOTE: This guide's content aligns with ThingWorx 9.3. The estimated time to complete this guide is 60 minutes       Step 1: Scenario   In this guide, we're continuing the same MotorCo scenario, where an engine can fail catastrophically in a low-grease condition.   In previous guides, you've gathered and exported engine vibration-data from an Edge MicroServer (EMS) and used it to build an engine analytics model.   The goal of this guide is to now operationalize that previously-created model to analyze individual, external readings to see if the "low grease" condition is currently happening.     Analytical model creation can be extremely helpful for the automotive segment in particular. For instance, each car that comes off the factory line could have an EMS constantly sending data from which an analytical model could automatically detect engine trouble.   This could enable your company to offer an engine monitoring subscription service to your customers.   This guide will show you how to put an analytic model of your engine into service to actively monitor performance.       Step 2: Configure Provider   In ThingWorx terminology, an Analysis Provider is a mathematical analysis engine.   Analytics Manager can use a variety of Providers, such as Excel, Mathcad, or even Analytics Server pre-built ones.   In this guide, we use the built-in AnalyticsServerConnector, a Provider that has been specifically created to work seamlessly in Manager and to use Builder Models.   From the ThingWorx Composer Analytics tab, click Analytics Manager > Analysis Providers > New....   In the Provider Name field, type Vibration_Provider. In the Connector field, search for and select TW.AnalysisServices.AnalyticsServer.AnalyticsServerConnector.   Leave the rest of the options at default and click Save.     Step 3: Publish Analysis Model   Once you have configured an Analysis Provider, you can publish Models from Analytics Builder to Analytics Manager. On the ThingWorx Composer Analytics tab, click Analytics Builder > Models.   Select vibration_model_s1_only and click Publish.   On the Publish Model? pop-up, click Yes. A new browser tab will open with the Analytics Manager's Analysis Models menu. Close that new browser tab, and instead click Analysis Models in the ThingWorx Composer Analytics navigation. This is the same interface as the auto-opened tab which you closed.   Click the model to select it. At the top, click Enable. Note the pop-up indicating that the Enable was successful.       Step 4: Modify EdgeThing   In previous guides in this Vehicle Predictive Pre-Failure Detection Learning Path, you have created various Entities, including Things such as EdgeThing.   In order to automate the process of pushing data from EdgeThing to Analytics Manager, we need to add a few more Properties to EdgeThing.   These Properties are simple STRING variables, and we'll also set Default Values for them to configure parameters of Analytics Manager.   The first is causalTechnique, which tells Analytics Manager which criteria to use when measuring the impact of a feature on a range of goal values.   The second is goalField, which is simply the data field for which Analytics Manager should try to identify the correlation. In this case, it'll be our primary issue, i.e. low_grease.   It is not mandatory that these suggested Property names match, but they are the names used within ThingWorx Analytics. You could use any Property name you wanted, as you'll be mapping from a particular Property to the functionality within Analytics in a later step.   Return to EdgeThing > Properties and Alerts.   Click + Add.   In the Name field, type causalTechnique. Check Has Default Value. In the text field under "Has Default Value", type FULL_RANGE. Note that you MUST type FULL_RANGE, including capitalization, as that is a command within Analytics Server.   Click the "Check with a +" icon for Done and Add. In the Name field, type goalField. Check Has Default Value. In the text field under "Has Default Value", type low_grease. Note that you MUST type low_grease, including being all lower-case, as that is the exact name of the Analytics Server goal.   Click the "Check" icon for Done. Click Save.   Results Storage   We also need a place in which to store the results that Analytics Manager returns. We'll utilize a few additional Properties for that as well.   On the EdgeThing > Properties and Alerts tab, click + Add. In the Name field, type Result_low_grease. Check the Base Type to BOOLEAN. Check Persistent.   Click the "Check with a +" icon for Done and Add. In the Name field, type Result_low_grease_mo. Change the Base Type to NUMBER. Check Persistent.   Click the "Check" icon for Done. Click Save.       Step 5: Create Event   Events are automatic analysis jobs which are submitted based on a pre-defined condition. In this step, we'll configure an Analysis Event, which will execute automatically whenever there is a data-change in our simulated engine.   On the ThingWorx Composer Analytics tab, click Analytics Manager > Analysis Events.   Click New.... If not already selected, change Source Type (Required) to Thing.   In Source, search for and select EdgeThing. In Event, select DataChange. In Property, select s1_fb1. If there are multiple s1_fb1 Properties, select the first one, as the second one is the s1_fb1 entry in the Info Table Property. In Provider Name, select Vibration_Provider. In Model Name, select the published Model.   Click Save.       Click here to view Part 2 of this guide.  

    Step 6: Map Data   Now that the event is created, we need to map the Properties of EdgeThing to the fields required to invoke an Analysis Job.   We'll start with the Inputs.   Select the previously-created Event, and click Map Data....   Click Inputs Mapping.   In Source Type, select Thing. In Source, search for and select EdgeThing.   On the left, scroll down and select s1_fb1. Note that you do NOT want the s1_fb1 that is part of the InfoTable Property, because the Info Table Property only stores recorded data, not live data. On the right, select _s1_fb1, the first frequency band required for the Model to make a prediction.   Click the Map button in the center.   Repeat this mapping process for for s1_fb2 through s1_fb5.   Map causalTechnique to causalTechnique in the same manner. This is a String Property in EdgeThing with a Default Value of "FULL_RANGE". Map goalField to goalField in the same manner. This is a String Property in EdgeThing with a Default Value of "low_grease".   Map Results   Now that the Inputs are mapped, we also want to map the Results.   Click Results Mapping on the left.   Map _low_grease to Result_low_grease. Map _low_grease_mo to Result_low_grease_mo.   Click Close to close the mapping pop-up.   Enable Event   Now that we've done the mapping from Foundation to Analytics, let's Enable the Analysis Event so that it can automatically generate and process Analysis Jobs. Select the mapped Analysis Event. Select Enable.   Now that you have enabled the Analysis Event, the new data will be submitted to Analytics Manager whenever EdgeThing's s1_fb1 Property changes.   An Analysis Job will automatically run, with a predictive score sent back and stored in EdgeThing's Result_low_grease (Boolean) and Result_low_grease_mo (Number) Properties.     Step 7: Check Jobs   In this step, we'll confirm that the automatic analysis of information coming from remote devices is operational.   On the ThingWorx Composer Analytics tab, click Analytics Manager > Analysis Jobs.   Uncheck Filter Completed Jobs.   Select a Job and click View.... Click Results.   NOTE: You will see true or false, corresponding to either a low grease or no low grease condition. Using this technology, you could create a paid customer service, where you offered to monitor remote engines, in return for automatically shutting them down before they experience catastrophic engine failure.   For that example implementation, you would utilize the EdgeThing.Result_low_grease BOOLEAN Property to trigger other actions.   For instance, you could create an Alert Event which would be triggered on a true reading.   You could then have a Subscription which paid attention to that Alert Event, and performed an action, such as sending an automatic shutdown command to the engine when it was experiencing a likely low grease event.   NOTE: We recommend that you return to the ThingWorx Composer Analytics > Analytics Manager > Analysis Events tab and Disable the Event prior to continuing. Since the simulator generates an Event every ~1 seconds, this can create a large number of Events, which can fill up your log.       Step 8: Next Steps   Congratulations. You've completed the Manage an Engine Analytical Model guide. In this guide you learned how to:   Define an Analysis Provider that uses the built-in Analytics Server Connector Publish a Model from Analytics Builder to Manager Create an Analysis Event which takes data from ThingWorx Foundation and decides whether or not a failure is likely   The next guide in the Vehicle Predictive Pre-Failure Detection with ThingWorx Platform learning path is Engine Failure-Prediction GUI.   Learn More   We recommend the following resources to continue your learning experience:    Capability     Guide Build Implement Services, Events, and Subscriptions Guide   Additional Resources   If you have questions, issues, or need additional information, refer to:    Resource              Link Community Developer Community Forum Support Analytics Manager Help Center      

    Step 7: Add Grid   It might also be helpful to display the data you've used to build the ThingWorx Analytics model.   In the future, this might be split out into an entirely separate page/Mashup that is exclusively devoted to backend model creation, but that would be beyond the scope of this guide.   For now, we'll simply display that collected data via the Grid Widget      1. On the EEFV_Mashup, drag-and-drop a Grid Advanced Widget onto the bottom-left Canvas section..     2. On the top-right Data tab, click the green </> button beside Things_EdgeThing. Note that this will open the Add Data pop-up, but with EdgeThing pre-selected.   3. In the Services Filter field, type getproperties.   4. Click the right-arrow beside GetProperties to add it to Selected Services on the right.   5. Check Execute on Load.     6. Click Done.   7. Under the Data tab, expand GetProperties to reveal the options.     8. Drag-and-drop Things_EdgeThing > GetProperties > infoTableProperty onto the Grid Advanced Widget.     9. On the Select Binding Target pop-up, click Data.     10. Click Save.   11. Click View Mashup.         Step 8: Add Controls   Throughout this Learning Path, it has been recommended that you stop Analysis Events when not actively using their functionality.   However, this requires going into the backend of ThingWorx Analytics to disable the event, which is not ideal.   Instead, let's enable or disable the Analysis Event from inside the Mashup by adding some Button Widgets to directly interface the Analytics backend for us.       1. Click the bottom-right Canvas section to select it.         2. In Mashup Builder top-left, click the Layout tab.         3. Under Positioning, click the Static radio-button.         4. Click the Widgets tab.       5. Drag-and-drop a Button Widget onto the bottom-right section.         6. Drag-and-drop another Button Widget onto the bottom-right section.       7. Drag-and-drop a Text Field Widget onto the bottom-right section.       8. Click Save.       Bring in More Data   Now that we have Buttons to trigger enable/disable, as well as a Text Field to display information, we now need to bring in some additional Mashup Data Services to interact with the ThingWorx Analytics backend.       1. Click the green + button at the top of the Data tab.       2. In the Entity Filter field, search for and  select TW.AnalysisServices.EventManagementServicesAPI.       3. In the Services Filter field, search for and add QueryAnalysisEvents by clicking the right arrow.       4. Check Execute on Load.         5. In Services Filter, search for and select EnableAnalysisEvent by clicking the right arrow. Note that you should NOT check "Execute on Load", as we'll trigger this Service only when the Button is clicked.     6. In Services Filter, search for and select DisableAnalysisEvent by clicking the right arrow. Likewise, do NOT check "Execute on Load" here either.       7. Click Done.         8. Click Save.     Display Event Key   To enable or disable Analytics Events, we need to know the eventId, which is returned by QueryAnalysisEvent Service as the parameter labeled key.   We'll bind that to the Text Field Widget for later usage in enabling/disabling.        1. Change the top-button's Label Property to Enable Analytics Event.       2. Change the bottom-button's Label Property to Disable Analytics Event.         3. Under the Data tab, expand QueryAnalysisEvents > Returned Data > All Data to reveal the options. .       4. Drag-and-drop QueryAnalysisEvents > Returned Data > All Data > key to the TextField Widget.         5. On the Select Binding Target pop-up, click Text.         6. Click Save.     Enable/Disable Analytics Events   Now that we know the key/eventId, we can call the EnableAnalysisEvent and DisableAnalysisEvent services.       1. Under the Data tab, expand EnableAnalysisEvent > Parameters to reveal eventId.       2. Click the Text Field Widget to select it, and then click the top-left drop down to reveal the options.         3. Drag-and-drop the Text Field's Text Property onto EnableAnalysisEvent > Parameters > eventId.         4. Repeat steps 1-3 for DisableAnalysisEvent.         5. Click the Enable Analytics Event Button Widget to select it, then click the top-left to reveal the drop down option .       6. Drag-and-drop the Clicked Event onto the EnableAnalysisEvent Service under the Data tab.         7. Repeat steps 5-6 for DisableAnalysisEvent, using the other Button Widget.         8. Click Save     Step 9: View Mashup   Throughout this guide, we've added various additional functionality to our MVP Mashup. At this point, you could continue to update the Mashup as you see fit.   For instance, you could change the background color of the top-left section to better match the header. Or you could further modify the original Mashup shown in the Contained Mashup Widget so that it better fits in the allowed space. You could add another Label Widget to the Header section to also display the company's motto / tag-line.   Regardless, when you are done with modifications, Save and click View Mashup.     Note that you can left-click-and-drag on the Time Series Chart to select particular time ranges. Or you could add a Time Selector Widget to the bottom-right section to control it there.   Similarly, you could add controls for the Grid Widget to only show the Identifier ranges in which you were interested.   Or you could split out the Model-creation values to a completely separate Mashup as previously discussed.   The extent to which you develop your Mashup is entirely up to you.        Step 10: Next Steps   Congratulations. You've completed the   Enhanced Engine Failure Visualization   guide. In this guide, you learned how to:   Create a Mashup with a Header Divide your Mashup into Sub-sections Use a Contained Mashup to reuse development Store historical data in a Value Steam Display historical data in a Line Chart Show spreadsheet data via a Grid Advanced Widget Tie Mashup controls into the ThingWorx backend   This is the last guide in the Vehicle Predictive Pre-Failure Detection with ThingWorx Platform learning path.   Learn More   We recommend the following resources to continue your learning experience:   Capability  Guide Build Implement Services, Events, and Subscriptions Guide   Additional Resources   If you have questions, issues, or need additional information, refer to:   Resource Link Community Developer Community Forum Support Analytics Manager Help Center

  Step 5: Contained Mashup   Our Minimum Viable Product (MVP) Mashup which we created in the last guide did have valid information.   Being able to display the inputs coming from the engine, as well as the analytical results coming from ThingWorx Analytics, are certainly items we don’t want to lose in this new, more complete Mashup.   Rather than recreating that work from scratch, we’ll simply include that previous Mashup in one of our sub-section via the Contained Mashup Widget.       1. Click on the top-left section to select it, and ensure that you’re on the Widgets tab in the top-left.       2. Drag-and-drop a Contained Mashup Widget onto the top-left section.       3. With the Contained Mashup Widget selected, return to the Properties tab in the bottom-left.       4. Scroll down and locate the Name Property.       5. Search for and select EFPG_Mashup       6. Click Save.     Add Column Labels   The original Mashup we created (and have now embedded in the new one) had some labels for the inputs and outputs. However, you had to know what things like “s1_fb1” meant to understand that that was an input.   We can go back to the original EPFG_Mashup, make some modifications for greater clarity, and those changes will also carry over to our new Mashup.       1. Reopen the old EPFG_Mashup on the Design tab.       2. Move all of the Widgets down to leave some extra room at the top.       3. Drag-and-drop two Divider Widgets onto the Canvas above both the Inputs and Results columns.       4. Select a Divider Widget, and go to its Style Properties.       5. Expand Base > Line to reveal the background Style Property.       6. Click on the default gray color to see the available options.       7. Choose the built-in black at the bottom, and click Select.       8. Make the same modification to the other Divider Widget.       9. Drag-and-drop two more Label Widgets onto the Canvas above the two columns.       10. Change their LabelText Properties to Inputs and Results, respectively.     Change Background and Size       1. From the Explorer tab in the top-left, select the container.       2. Select the Style Properties tab in the bottom-left and expand Base > Container.       3. Change the background Style Property to a color you prefer.       4. With the container still selected in the Explorer tab, drag the corners of the Mashup to reduce its size.       5. You could even move the Results column over, place the Auto Refresh Widget underneath, and then reduce the container size even further.       6. Click Save.     View Mashup Thus Far   With the changes to the previous EFPG_Mashup now complete, let’s ensure that everything carried over to our new Mashup.       1. Return to EEFV_Mashup.       2. Click Save.       3. Click View Mashup.   Note how the various changes we made to the base Mashup are also being shown, via a Contained Mashup Widget, in our new Mashup.   Splitting out functionality to a separate Mashup that is then embedded where needed is a great way to re-use content and simplify development.       Step 6: Add Chart   Our original Mashup (which has now been embedded in our new one) shows the instantaneous analytical results based on the inputs coming from the Edge MicroServer (EMS).   However, when investigating remote customer issues, it might be helpful to see some historical trends. A temporary "blip" of a low-grease indication might be worrisome, but it may not require immediate intervention unless the issue was occuring consistently or for extended periods of time.   Fortunately, creating a historical record is relatively simple in ThingWorx Foundation.   All that is really needed is a place in which to store the past records.   One of the easiest such storage methods is a Value Stream.       1. In ThingWorx Foundation, click Browse > Data Storage > Value Streams.       2. Click + New.       3. On the Choose Template pop-up, select ValueStream and click OK.       4. In the Name field, type EEFV_ValueStream.       5. If Project is not already set, search for and select PTCDefaultProject.       6. At the top, click Save.     Link Value Stream and Begin Storage   Now that we have a Value Stream to act as a storage location, we want to link it to EdgeThing.   After EdgeThing knows where to store historical data, we can simply instruct it which Property we want to archive by setting it to Logged.       1. Return to EdgeThing and its General Information tab.       2. In the Value Stream field, search for and select EEFV_ValueStream.       3. Click Save.       4. Still on EdgeThing, click Properties and Alerts.       5. Click Result_low_grease_mo to trigger the slide-out from the right-side.         6. Check Logged.       7. Click the Check icon in the top-right to close the slide-out.       8. Click Save.     Add Line Chart and Data   As per most guides in this Learning Path, it is assumed that you have an active connection to the EMS Engine Simulator and have your Analytics Event currently set to active.   This provides both the engine-sensor inputs and the analytical results for our Mashup.   After adding the Value Stream above, you'll need to let it run for a bit for the historical data to be archived. After it's run for a while and we have a valid history build-up, you can display that history in a Line Chart.       1. Return to EEFV_Mashup on the Design tab.       2. Click on the top-right section to select it.         3. From the Widgets tab, drag-and-drop a Line Chart onto the top-right section.         4. In the top-right of Mashup Builder, ensure the Data tab is selected.         5. Click the green + button.         6. On the Add Data pop-up in Entity Filter, search for and select EdgeThing.       7. In Services Filter, type queryprop.       8. Click the right arrow button besides QueryPropertyHistory.       9. Check Execute on Load.         10. Click Done.       11. Expand Data > Things_EdgeThing > QueryPropertyHistory > Returned Data.       Bind Data and View Mashup   Now that we have both our method of displaying the historical data, i.e. a Line Chart, as well as a method to bring backend data into the Mashup, i.e. QueryPropertyHistory, we can bind them together and see how our Mashup is progressing.       1. From the right under the Data tab, drag-and-drop EdgeThing > QueryPropertyHistory > Returned Data > All Data onto the Line Chart in the top-right of the Canvas.         2. On the Select Binding Target pop-up, click Data.         3. With the Line Chart selected, explore its Properties in the bottom-left.       4. Change XAxisField to timestamp.         5. Click Save.       6. Click View Mashup.     Your own Line Chart will vary depending on what values your Engine Simulator is sending to Foundation and Analytics.   NOTE: Remember that the Analysis Event needs to be Enabled for new values to be fed into Result_low_grease_mo.     Click here to view Part 3 of this guide.  

  Step 4: Simulated Model   Models are primarily used by   Analytics Manager   (which will be discussed in the next guide), but they can still be used to estimate the accuracy of predictions.   When Models are calculated, they   inherently withhold a certain amount of data   (~20%). The prediction model is then   run against the withheld data. This provides a form of "accuracy measure".   The withheld-data is selected randomly, so you'll actually get a slightly different model and accuracy measure each time that you create a Model versus the same dataset.   On the left, click   Analytics Builder > Models.   Click   New….   In the   Model Name   field, enter   simulated_model. In the   Dataset   field, select   simulated_dataset.   Click   Submit. After ~60 seconds, the Model Status will change to   COMPLETED.     Select the model that was created in the previous step, i.e.   simulated_model. Click   View…   to open the Model Information page.   As with Signals and Profiles, our Model is once again "too good". In fact, it's perfect.   The expected "Precision" is 1.0, i.e. 100%. The True vs False Positive rate shown in the graph goes straight up to the top immediately.   While you want a graph that is "high and left", you're very unlikely to ever see real-world scenarios such as shown here.   Still, you've been able to progress the process of using Foundation (and now Analytics) to build an analytical model of MotorCo's prototype engine.   What needs to happen now is to receive   real world data   from your R&D engineers.     Step 5: Upload Real World Data   In your process of using the EMS Engine Simulator, the idea has always been to get a headstart on the engine developers.   At some point, they would wire sensors into the EMS and start providing real world data.   In our scenario, that has now happened.   Real world data   is being fed from the EMS to Foundation, Foundation is collecting that data in an Info Table Property, and you've even exported the data as a .csv. file.   This new dataset is over periods of both good and bad grease conditions. The engineers monitoring the process can flip a sensor switch connected to the EMS to log the current grease situation as either good or bad at the same time that the vibration sensors are taking readings.   We will now load this real world dataset into Analytics in the same manner that we did earlier with the simulated dataset.   Download the attached analytics_vibration.zip file to your computer. Unzip the   analytics_vibration.zip   file to access the   vibration_data_and_header.csv   and   vibration_metadata.json   files. On the left, click   Analytics Builder > Data. Under   Datasets, click   New....   In the   Dataset Name   field, enter   vibration_dataset. In the   File Containing Dataset Data   section, search for and select   vibration_data_and_header.csv. In the   File Containing Dataset Field Configuration   section, search for and select   vibration_metadata.json.   Click   Submit.     Step 6: Real World Signals and Profiles   Now that the real-world vibration data has been uploaded, we’ll re-run   Signals   and   Profiles   just as we did before.   Hopefully, we’ll start seeing some patterns.   On the left, click   Analytics Builder > Signals. At the top, click   New….   In the   Signal Name   field, enter   vibration_signal. In the   Dataset   field, select   vibration_dataset.   Click   Submit. Wait ~30 seconds for   Signal State   to change to   COMPLETED     The results show that the five Frequency Bands for   Sensor 1   are the   most highly correlated   with determining our goal of   detecting a low grease condition.   For Sensor 2, only bands one and four seem to be related, while bands two, three, and five are hardly relevant at all.   This is a very different result than our earlier simulated data. Instead, it looks like it’s   possible   that the vibration-frequencies getting pickup up by our first sensor are explicitly more important.   Profiles   We’ll now re-run Profiles with our real-world dataset. On the left, click   Analytics Builder > Profiles. Click   New….   In the   Profile Name   field, enter   vibration_profile. In the   Dataset   field, select   vibration_dataset.   Click   Submit. After ~30 seconds, the Signal State will change to   COMPLETED.     The results show several Profiles (combinations of data) that appear to be statistically significant.   Only the   first few Profiles, however, have a   significant percentage of the total number of records. The later Profiles can largely be ignored.   Of those first Profiles, both Frequency Bands from Sensor 1 and Sensor 2 appear.   But in combination with the result from   Signals   (where Sensor 1 was always more important), this could possibly indicate that   Sensor 1 is still the most important overall.   In other words, since   Sensor 1 is statistically significant both by itself and in combination   (but Sensor 2 is only significant in combination   with Sensor 1), then   Sensor 2 may not be necessary.     Click  here  to view  Part 3 of this guide.

    Generate engine-failure predictions and gain insight into your data with machine learning.   GUIDE CONCEPT   This guide will upload captured data from an Edge MicroServer (EMS) "Engine Simulator" to ThingWorx Analytics Builder.   Following the steps in this guide, you will create an analytical model, and then refine it based on further information from the Analytics platform.   We will teach you how to determine whether or not a model is accurate and how you can optimize both your data inputs and the model itself.   NOTE: This guide's content aligns with ThingWorx 9.3. The estimated time to complete ALL parts of this guide is 60 minutes     YOU'LL LEARN HOW TO   Load an IoT dataset Generate machine learning predictions Evaluate the analytics output to gain insight     Step 1: Scenario   In this guide, we’re continuing the same MotorCo scenario, where an engine can fail catastrophically in a low-grease condition.   In previous guides, you’ve gathered and exported engine vibration-data from an Edge MicroServer (EMS).   The goal of this guide is to now import that previously-exported Comma-Separated Values (.csv) data into   ThingWorx Analytics, and then   create an analytical model for predictive maintenance.   Analytical model creation can be extremely helpful for the   automotive segment   in particular. For instance, each car that comes off the factory line could have an EMS constantly sending data from which an analytical model could   automatically detect engine trouble.   This could enable your company to offer an   engine monitoring subscription service   to your customers.   This guide will show you how to build an analytic model of your engine to facilitate this monitoring service.     Step 2: Upload Simulated Data   This guide assumes that you are using either the   hosted trial   (with has both Foundation and Analytics pre-installed) or a combination of the Foundation and Analytics   downloadable installers.   To confirm that Foundation is communicating with Analytics, perform the following steps:   On the ThingWorx Foundation left-side navigation column, click   Analytics > Analytics Builder > Settings.   At the top-right in the   Analytics Server Version   field, ensure that you see   an appropriate version number.     NOTE:  If you use your own dataset, it's possible that you're results in the following steps will differ from those created by the provided-dataset. If you were unable to generate a 30,000+ entry dataset in the last guide, then you may download testCSVfile.csv attached here,instead. You will also need to download and extract  vibration_metadata.zip which describes each column of the dataset. On the left, click   Analytics Builder > Data.   Under   Datasets, click   New....   In the   Dataset Name   field, enter   simulated_dataset. In the   File Containing Dataset Data   section, search for and select   testCSVfile.csv. In the   File Containing Dataset Field Configuration   section, search for and select   vibration_metadata.json.   Click   Submit. Note that the time it takes to import the dataset is determined by its size.       Step 3: Simulated Signals and Profiles    The   Signals   section of ThingWorx Analytics looks for the   most statistically correlated   single field   in the dataset which relates to your selected goal.   This doesn't necessarily indicate that it is the cause of your goal, whether maximizing or minimizing. It just means that the dataset indicates that this single field happens to correlate with the goal that you desire.   On the left, click   Analytics Builder > Signals.   At the top, click   New….   In the   Signal Name   field, enter   simulated_signal. In the   Dataset   field, select   simulated_dataset.   Click   Submit. Wait ~30 seconds for   Signal State   to change to   COMPLETED     Unfortunately, our results aren't very good. Or, more accurately, they're   too good.   Our simulated dataset has some noise in it from adding random values to our five frequency bands on each our two sensors. However, ThingWorx Analytics has instantly seen through that noise and discarded it. Instead, it's only detected that s2_fb5 isn't relevant.   If you look back at the   Use the EMS to Create an Engine Simulator   guide, you'll see that s2_fb5 has the same base value between both a "good grease" and a "bad grease" condition, i.e. a base of 190.   This   does   show already that Analytics is working, though. Since s2_fb5 didn't change between good and bad grease conditions, our Signal analysis is indicating that it's not relevant to our model.   Profiles   Now, let's do the same for a   Profile.   The Profiles section of ThingWorx Analytics looks for   combinations of data   which are highly correlated with your desired goal.   On the left, click   Analytics Builder > Profiles.   Click   New....   In the   Profile Name   field, enter   simulated_profile. In the   Dataset   field, select   simulated_dataset.   Click   Submit. Wait ~30 seconds for the Profile State to change to   COMPLETED.     Just like with Signals, our Profile is too good. In fact, Analytics is indicating that just s1_fb2 by itself is the primary indicator of good vs. bad grease conditions.   This is likely due to random chance. The random noise added to s1_fb2 just happened to be slightly less than the other frequency bands, so everything else was discarded.   Regardless, ThingWorx Analytics is quickly seeing through our simulated data.   Next, we'll actually create a Model using the simulated dataset.     Click  here  to view  Part 2  of this guide  

Build a Predictive Analytics Model Guide Part 2   Step 5: Profiles   The Profiles section of ThingWorx Analytics looks for combinations of data which are highly correlated with your desired goal. On the left, click ANALYTICS BUILDER > Profiles. Click New....The New Profile pop-up will open. NOTE: Notice the Text Data Only section which is new in ThingWorx 9.3.         3. In the Profile Name field, enter vibration_profile. 4. In the Dataset field, select vibration_dataset. 5. Leave the Goal field set to the default of low_grease. 6. Leave the Filter field set to the default of all_data. 7. Leave the Excluded Fields from Profile field set to the default of empty. 8. Click Submit. 9. After ~30 seconds, the Signal State will change to COMPLETED. The results will be displayed at the bottom.                 The results show several Profiles (combinations of data) that appear to be statistically significant. Only the first few Profiles, however, have a significant percentage of the total number of records. The later Profiles can largely be ignored. Of those first Profiles, both Frequency Bands from Sensor 1 and Sensor 2 appear. But in combination with the result from Signals (where Sensor 1 was always more important), this could possibly indicate that Sensor 1 is still the most important overall. In other words, since Sensor 1 is statistically significant both by itself and in combination (but Sensor 2 is only significant in combation with Sensor 1), then Sensor 2 may not be necessary.     Step 6: Create Model   Models are primarily used by Analytics Manager (which is beyond the scope of this guide), but they can still be used to measure the accuracy of predictions. When Models are calculated, they inherently withhold a certain amount of data. The prediction model is then run against the withheld data. This provides a form of "accuracy measure", which we'll use to determine whether Sensor 2 is necessary to the detection of a low grease condition by creating two different Models. The first Model (which you will create below) will contain all the data, while the second Model (in the next step) will exclude Sensor 2. On the left, click ANALYTICS BUILDER > Models.   Click  New… . The New Predictive Model pop-up will open.   3. In the Model Name field, enter vibration_model. 4. In the Dataset field, select vibration_dataset. 5. Leave the Goal field set to the default of low_grease. 6. Leave the Filter field set to the default of all_data.         7. Leave the Excluded Fields from Model section at its default of empty.       8. Click Submit. 9. After ~60 seconds, the Model Status will change to COMPLETED.   View Model   Now that the prediction model is COMPLETED, you can view the results. Select the model that was created in the previous step, i.e. vibration_model. Click View… to open the Model Information page.   Review the visualization of the validation results. Note that your results may differ slightly from the picture, as the automatically-withheld "test" portion of the dataset is randomly chosen. Click on the ? icon to the right of the chart for details on the information displayed.   The desired outcome is for the model to have a relatively high level of accuracy. The True Positive Rate shown on the Receiver Operating Characteristic (ROC) chart are much higher than the False Positives. The curve is relatively high and to the left, which indicates a high accuracy level. You may also click on the Confusion Matrix tab in the top-left, which will show you the number of True Positive and True Negatives in comparison to False Positives and False Negatives.     Note that the number of correct predictions is much higher than the number of incorrect predictions.     As such, we now know that our Sensors have a relatively good chance at predicting an impending failure by detecting low grease conditions before they cause catastrophic engine failure.     Step 7: Refine Model   We will now try comparing this first Model that includes both Sensors to a simpler Model using only Sensor 1. We do this because we suspect that Sensor 2 may not be necessary to achieve our goal. On the left, click ANALYTICS BUILDER > Models.   Click New…. In the Model Name field, enter vibration_model_s1_only. In the Dataset field, select vibration_dataset. Leave the Goal field set to the default of low_grease. Leave the Filter field set to the default of all_data.   On the right beside Excluded Fields from Model, click the Excluded Fields button. The Fields To Be Excluded From Job pop-up will open. 8. Click s2_fb1 to select the first Sensor 2 Frequency Band. 9. Select the rest of the Frequency Bands through s2_fb5 to choose all of the Sensor 2 frequencies. 10. While all the s2 values are selected, click the green "right arrow", i.e. the > button in the middle. 11. At the bottom-left, click Save. The Fields To Be Excluded From Job pop-up will close.           12. Click Submit. 13. After ~60 seconds, the Model State will change to COMPLETED. 14. With vibration_model_s1_only selected, click View....   The ROC chart is comparable to the original model (including Sensor 2). Likewise, the Confusion Matrix (on the other tab) indicates a good ratio of correct predictions versus incorrect predictions.     NOTE: These Models may vary slightly from your own final scores, as what data is used for the prediction versus for evaluation is random. ThingWorx Analytics's Models have indicated that you are likely to receive roughly the same accuracy of predicting a low-grease condition whether you use one sensor or two! If we can get an accurate early-warning of the low grease condition with just one sensor, it then becomes a business decision as to whether the extra cost of Sensor 2 is necessary.   Step 8: Next Steps   Congratulations! You've successfully completed the Build a Predictive Analytics Model guide, and learned how to:   Load an IoT dataset Generate machine learning predictions Evaluate the analytics output to gain insight    This is the last guide in the Getting Started on the ThingWorx Platform learning path.   This is the last guide in the Monitor Factory Supplies and Consumables learning path.   The next guide in the Design and Implement Data Models to Enable Predictive Analytics learning path is Operationalize an Analytics Model.     Additional Resources   If you have questions, issues, or need additional information, refer to:   Resource Link Support Analytics Builder Help Center    

  Step 7: Real World Model   We’ll now rerun model creation with the Real World data.   Even though Signals and Profiles are possibly telling us that only Sensor 1 is needed, the   first Model   you’ll create will contain   all the data, while the   second Model   will   exclude Sensor 2. We’ll then compare the Models to see which one is going to work the best for predicting engine failures.   On the left, click   Analytics Builder > Models. Click   New….   In the   Model Name   field, enter   vibration_model. In the   Dataset   field, select   vibration_dataset.   Click   Submit. After ~60 seconds, the Model Status will change to   COMPLETED. Select the model that was created in the previous step, i.e.   vibration_model. Click   View…   to open the Model Information page. Note that your model may differ slightly from the picture below, as the automatically-withheld "test" data is randomly chosen.       Unlike our simulated dataset, this real-world data is not perfect. However, it’s still pretty good, and is much more representative of what a real-world scenario would indicate.   The   True Positive Rate   shown on the Receiver Operating Characteristic (ROC) chart are much higher than the False Positives.   The curve is relatively high and to the left, which indicates a high accuracy level.   You may also click on the   Confusion Matrix   tab in the top-left, which will show you the number of True Positive and True Negatives in comparison to False Positives and False Negatives.     NOTE: The number of correct predictions is much higher than the number of incorrect predictions.   As such,   we now know that our Sensors have a relatively good chance at predicting an impending failure   by detecting low grease conditions before they cause catastrophic engine failure.   Refined Model   We can now compare this   first Model   that includes   both Sensors   to a   Model using only Sensor 1, since we suspect that   Sensor 2 may not be necessary   to achieve our goal. On the left, click   Analytics Builder > Models. Click   New…. In the   Model Name   field, enter   vibration_model_s1_only. In the   Dataset   field, select   vibration_dataset.   On the right beside   Excluded Fields from Model, click the   Excluded Fields   button.   Select   s2_fb1   through   s2_fb5.   While all the s2 values are selected, click the green "right-arrow", i.e. >   button, in the middle.   At the bottom-left, click   Save.   Click   Submit. After ~60 seconds, the Model State will change to   COMPLETED. With   vibration_model_s1_only   selected, click   View….     The ROC chart is comparable to the original model (including Sensor 2).   Likewise, the Confusion Matrix (on the other tab) indicates a good ratio of correct predictions versus incorrect predictions.     NOTE: These Models may vary slightly from your own final scores, as what data is used for the prediction versus for evaluation is random.   ThingWorx Analytics’s Models have indicated that you are likely to receive roughly the same accuracy of predicting a low-grease condition whether you use one sensor or two!   If we can get an accurate early-warning of the low grease condition with just one sensor, it then becomes a business decision as to whether the extra cost of Sensor 2 is necessary.     Step 8: Next Steps   Congratulations! You've successfully completed the   Build an Engine Analytical Model   guide, and learned how to:   Load an IoT dataset Generate machine learning predictions Evaluate the analytics output to gain insight   The next guide in the Vehicle Predictive Pre-Failure Detection with ThingWorx Platform learning path is Manage an Engine Analytical Model.   Learn More   We recommend the following resources to continue your learning experience:   Capability Guide Analyze Operationalize an Analytics Model Build Implement Services, Events, and Subscriptions Additional Resources   If you have questions, issues, or need additional information, refer to:   Resource Link Community Developer Community Forum Support Analytics Builder Help Center

  Use the Statistical Calculation Thing Shape to Execute Common Statistical Functions   GUIDE CONCEPT   This project will introduce the Statistical Calculation Thing Shape.   The steps in this guide outline how to utilize Descriptive Analytics in ThingWorx Analytics to perform common mathematical analyses on data sets. You will learn how to use the Statistical Calculation Thing Shape's built-in functionality to calculate the mean, median, mode, and other useful insights.     YOU'LL LEARN HOW TO   Create a Value Stream and Data Shape Create a Thing with the Statistical Calculation Thing Shape Modify a Property to record values to the Value Stream Utilize various built-in services to perform the Mean, Median, Mode, and Standard Deviation calculations   NOTE: The estimated time to complete this guide is 30 minutes.     Step 1: Introduction   Descriptive Analytics enables users to perform on-demand common statistical calculations and enable statistical monitoring. Output from these Services can then easily be added to IoT applications built with the ThingWorx platform.   For example, output generated by Descriptive Analytics can be used to build solution-specific visualizations (Mashups or Widgets), create Alerts based on logged Property values, or generate transformed data for machine learning processes.   Descriptive Analytics includes two microservers, each with its own set of statistical Services. This guide will deal specifically with the   Statistical Calculation Thing Shape.   This Thing Shape will add a variety of built-in Services to any Thing or Thing Template you choose, such as calculations for   Mean,   Median,   Mode, or   Standard Deviation.   To perform these statistical calculations, a Property must have time-series data logged to a   Value Stream.   In addition, the Statistical Calculation Thing Shape has been optimized to perform calculations only on   particular time ranges   and with a   maximum entry-count. This helps minimize some of the performance hits that can occur from repeatedly accessing Value Streams.   You perform this "data grooming" via the   QueryTimedValuesForProperty   Service, which is also part of the Statistical Calculation Thing Shape.   In addition to the name of a Property with values logged to a Value Stream, you also provide a Start Date, End Date, and Max Item Count.   The QueryTimedValuesForProperty Service then   formats   the values from the Value Stream to work with for the other built-in statistical calculation Services.   Step 2: Create Prerequisites   The inputs to the built-in Services of the Statistical Calculation Thing Shape require time-series data stored in a   Value Stream. Setting a Thing's Properties to be   Logged   will store valid time-series data on which to perform Descriptive Analytics.   Create Value Stream   Follow the steps below to create a Value Stream that you will later tie to a Thing.   On the ThingWorx Composer   Browse   tab, click   DATA STORAGE > Value Streams,   + New.   Select   ValueStream   and click   OK.   In the   Name   field, enter   scts_valuestream. If Project is not already set, search for and select PTCDefaultProject.   At the top, click   Save.   Create Data Shape   You will need a   Data Shape   to format the timed_values Property we will create in the next step.   On the ThingWorx Composer   Browse   tab, click   MODELING > Data Shapes,   + New.   In the   Name   field, enter   scts_timed_values_datashape. If Project is not already set, search for and select PTCDefaultProject.   At the top, click   Field Definitions.   Click   + Add. On the right slide-out, in the   Name   field, enter   value. Change the   Base Type   to   NUMBER.   At the top-right, click the "check with a +" icon for   Done and Add. In the   Name   field, enter   timestamp. Change the   Base Type   to   LONG.   At the top-right, click the "check" icon for   Done. At the top, click   Save.       Step 3: Create Thing   Next, you will create a   Thing   and tie the previously-created Value Stream to it.   You will assign the Statistical Calculation Thing Shape to get a variety of built-in analytics Services to manipulate the data. You will also create a series of Properties to facilitate the new Services.   On the ThingWorx Composer   Browse   tab, click   MODELING > Things,   + New.   In the   Name   field, enter   scts_thing. If Project is not already set, search for and select PTCDefaultProject. In the   Base Thing Template   field, search for and select   GenericThing. In the   Implemented Shapes   field, search for and select   StatisticalCalculationThingShape. In the   Value Stream   field, search for and select   scts_valuestream.   At the top, click   Save.   Add Properties   Next, you will add a series of   Properties   to   scts_thing.   Perform the following steps repeatedly until all Properties have been added.   At the top, click   Properties and Alerts.   Click   + Add. On the right slide-out, in the   Name   field, enter   numbers. Change the   Base Type   to   NUMBER. Click   Persistent. Click   Logged.   At the top-right, click the "check with a +" icon for   Done and Add. Repeat steps   3-7   until all of the properties in the table below have been added. NOTE: For the final   standarddev_result   Property, do   NOT   click   Done and Add; you'll just click the check for   Done   instead. Property Name Base Type Data Shape Persistent  Logged start_time DATETIME N/A Checked NOT   checked end_time DATETIME N/A Checked NOT   checked timed_values INFOTABLE scts_timed_values_datashape Checked NOT   checked mean_result NUMBER N/A Checked NOT   checked median_result NUMBER N/A Checked NOT   checked mode_result INFOTABLE none, i.e. leave it blank Checked NOT   checked standarddev_result NUMBER N/A Checked NOT   checked     At the top-right, click the "check" icon for   DONE. At the top, click   Save .   Step 4: Set Properties   You will now set the properties to guarantee that each calculation gives us a different answer.   Mean is the average. Median is the "middle" number from the dataset. Mode is the most common number. Standard Deviation is a measure of the "dispersion" of the dataset.   You will use the following dataset:   1, 5, 9, 5, 9, 1, 9.   The   mean   is 39 / 7 =   5.571...   The   median   is   5, as 5 is the middle of 1, 5, and 9.   Mode   is   9, because 9 appears most commonly in the dataset.   Standard Deviation   is   3.5989...   Perform the following steps to enter the above values into the   numbers   property.   Set numbers   Under the   Value   column and on the   numbers   property row, click the "pencil" icon for   Set value of property.   On the right slide-out, enter   1.   At the top-right, click the "check" icon for   Done. At the top, click   Save.   Repeat steps   1-4   above, changing the value each time according to the table below: Value Change Count  Entered Value 2nd 5 3rd 9 4th 5 5th 9 6th 1 7th 9   You also need to set the   start_time   and   end_time. These are dates used to define the time-period in which the Statistical Calculation Thing Shape will search for values.   For instance, you could set the calculations to run at midnight, and then use the past 24-hours as your time-period.   For this example, set dates to be 24 hours prior to the time at which you set the above values of the numbers property, through 24 hours in the future.   Set start_time   Under the   Value   column and on the   start_time   Property row, click the "pencil" icon for   Set value of property.   On the right slide-out, search for and select the previous day.   At the top-right, click the "check" icon for   Done. At the top, click   Save.   Set end_time   Under the   Value   column and on the   end_time   property row, click the "pencil" icon for   Set value of property.   On the right slide-out, search for and select the following day. At the top-right, click the "check" icon for   Done. At the top, click   Save.     Click  here  to view  Part 2  of this guide.

  Use the Edge MicroServer (EMS) to simulate an engine with vibration sensors.   GUIDE CONCEPT   The Edge MicroServer (EMS) facilitates connectivity from Edge devices to ThingWorx Foundation.   It’s often easier, though, to start development with simulated Edge values rather than hooking up sensors.   This guide will show you how to simulate vibration values of an engine using the EMS.     YOU'LL LEARN HOW TO   Modify an EMS Template Provision Thing Properties and Values from an EMS rather than Foundation Send information from an EMS to Foundation Store large amounts of data in an InfoTable Property Create a simulator for testing   NOTE:  The estimated time to complete all parts of this guide is 30 minutes.     Step 1: Scenario   MotorCo manufactures, sells, and services commercial motors.   Recently, MotorCo has been developing a new motor, and they already have a working prototype.   However, they’ve noticed that the motor has a chance to   FAIL CATASTROPHICALLY   if it’s not properly serviced to replace   lost grease   on a key moving part.     In order to prevent this type of failure in the field, MotorCo has decided to instrument their motors with   sensors which record vibration.   The hope is that these sensors can detect certain vibrations which indicate required maintenance   before   a failure occurs.   In this guide, you’ll begin this monitoring process by using ThingWorx Foundation to monitor and record vibration data from the prototype motor. In particular, you will learn how to provision   Thing Properties and Values   from an EMS, as well as how to permanently store these values for analysis in an   Info Table Property.   These types of modifications to an EMS can be extremely helpful for the   automotive segment   in particular. For instance, each car that comes off the factory line could have custom, auto-generated EMS scripting that would   dynamically create Foundation information for each car in the fleet. This could be a massive time-savings versus manually generating Thing Properties directly within Foundation.   Because the motor is still in the process of being instrumented with sensors, you’ll get all the functionality in-place beforehand by constructing a   motor simulator   using the   Edge MicroServer (EMS).     Step 2: Modify config.lua   In the previous   Use the Edge MicroServer (EMS) to Connect to ThingWorx    guide, you installed the EMS on a Windows PC, configured it to talk to ThingWorx Foundation, and then created an   EdgeThing   on Foundation to complete the connectivity.   This guide assumes that you have already completed that Windows EMS guide and have an active EMS connection to the EdgeThing.   Perform the following steps to modify this connection to increase the   task rate   of the EMS, which we'll use in the following steps to update Properties more quickly.   On your Windows PC, select the   Windows PowerShell   window where the   luaScriptResource.exe   program is running.   Type   Ctrl-C   to close the luaScriptResource.exe operation, i.e. hold the   Control   key and hit the   C   key.   Minimize   the luaScriptResource.exe PowerShell window, and activate the   wsemse.exe   PowerShell window.   Type   Ctrl-C   to close the wsems.exe operation.   Return to Foundation, and note that   EdgeThing is not connected.   Navigate to the   C:\CDEMO_EMSE\etc   directory.   Open   config.lua   in your prefered text-editor.   Change   scanRate   to   1000. Add the following line below the   scanRate   line:   taskRate = 1000,   The final code of config.lua should be the following Note that the EMS may have slightly modified your config.lua file, such as adding a   data_security_key   line. Leave these EMS-generated modifications alone. scripts. log_level = "WARN" scripts. script_resource_ssl = false scripts. script_resource_authenticate = false scripts. EdgeThing = { file = "thing.lua" , template = "YourEdgeThingTemplate" , scanRate = 1000 , taskRate = 1000 , sw_update_dir = "C:\\CDEMO_EMS\\updates" } Save   the   config.lua   file.     Click here to view Part 2 of this guide.

    Step 3: Modify YourEdgeThingTemplate.lua   Now that the task rate has been decreased to 1000ms (one second), we can create a series of Thing Properties.   In Windows, navigate to C:\CDEMO_EMS\etc\custom\templates.   In your prefered text-editor, open YourEdgeThingTemplate.lua.   We now want to add several lines of Lua code to define some Properties for EdgeThing. You’ll do some with some references that are pre-built into the EMS, primarily the properties structure.   Working with the engine R&D team, their plan is to place two vibration sensors on the proptype engine. In addition, each vibration sensor will have five frequency bands. As such, we’ll need ten Properties to represent the vibration readings.   In addition, we also want a Property that will record whether or not the engine is currently experiencing the low grease condition. This will be entered via manual-inspection at the same time that the frequency readings are recorded.   Perform the following to implement the ten vibration frequency bands and the low grease condition.   Below the module line of YourEdgeThingTemplate.lua, add the following line to create a low_grease Property: properties.low_grease={baseType= "NUMBER" , pushType= "ALWAYS" , value= 0 } Below that, add the following lines to create the five frequency bands for the first vibration sensor: properties.s1_fb1={baseType= "NUMBER" , pushType= "ALWAYS" , value= 0 } properties.s1_fb2={baseType= "NUMBER" , pushType= "ALWAYS" , value= 0 } properties.s1_fb3={baseType= "NUMBER" , pushType= "ALWAYS" , value= 0 } properties.s1_fb4={baseType= "NUMBER" , pushType= "ALWAYS" , value= 0 } properties.s1_fb5={baseType= "NUMBER" , pushType= "ALWAYS" , value= 0 } Below that, add the following lines to create the five frequency bands for the second vibration sensor: properties.s2_fb1={baseType= "NUMBER" , pushType= "ALWAYS" , value= 0 } properties.s2_fb2={baseType= "NUMBER" , pushType= "ALWAYS" , value= 0 } properties.s2_fb3={baseType= "NUMBER" , pushType= "ALWAYS" , value= 0 } properties.s2_fb4={baseType= "NUMBER" , pushType= "ALWAYS" , value= 0 } properties.s2_fb5={baseType= "NUMBER" , pushType= "ALWAYS" , value= 0 } Your code should now look like the picture below.   The code above adds each new Property to the properties structure, and the name of the Property will be what follows after the “.”, i.e. low_grease, s1_fb1, s1_fb2, etc.   In addition, the baseType defines the type of each Property, in this case, all Numbers.   The pushType of ALWAYS means that there are no restrictions on sending new Property values up to Foundation, and the value of 0 indicates the default value to which each Property will initially be set.   Generate Property Values   Now that we have the Properties defined, we want to add code which will give us different values.   To do so, we’ll define a queryHardware function, and tie the calling of it to the task rate which we had set earlier. This queryHardware function will use random numbers to simulate code that would gather actual data.    Add the following Lua code to define a GetSystemProperties function. Note that this calls a separate queryHardware function which we split out to also be called by the tasks timer. serviceDefinitions.GetSystemProperties( output { baseType= "BOOLEAN" , description= "" }, description { "updates properties" } ) services.GetSystemProperties = function (me, headers, query, data) queryHardware() return 200 , true end Add the following Lua code to define queryHardware. Note that Lua’s random number generation requires a new seed on each calling, and the randomseed function is using the built-in os.time function (plus some additional noise created by turning that time into a string and back). function queryHardware () math .randomseed( tonumber ( tostring ( os .time()):reverse():sub( 1 , 6 )) ) local temp = math .random( 10 ) if temp < 6 then properties.low_grease.value= 0 properties.s1_fb1.value= 161 + math .random() properties.s1_fb2.value= 180 + math .random() properties.s1_fb3.value= 190 + math .random() properties.s1_fb4.value= 176 + math .random() properties.s1_fb5.value= 193 + math .random() properties.s2_fb1.value= 130 + math .random() properties.s2_fb2.value= 200 + math .random() properties.s2_fb3.value= 195 + math .random() properties.s2_fb4.value= 165 + math .random() properties.s2_fb5.value= 190 + math .random() else properties.low_grease.value= 1 properties.s1_fb1.value= 90 + math .random() properties.s1_fb2.value= 170 + math .random() properties.s1_fb3.value= 170 + math .random() properties.s1_fb4.value= 95 + math .random() properties.s1_fb5.value= 190 + math .random() properties.s2_fb1.value= 165 + math .random() properties.s2_fb2.value= 195 + math .random() properties.s2_fb3.value= 190 + math .random() properties.s2_fb4.value= 140 + math .random() properties.s2_fb5.value= 190 + math .random() end end Finally, we want to tie the calling of queryHardware to the tasks timer by adding the following code: tasks.refreshProperties = function (me) queryHardware() end   We now have code in our EMS template that not only defines the low grease condition and the five frequency bands of our two vibration sensors, but also generates some values in the ranges that R&D have typically seen in both good grease amount and bad grease amount conditions.   The final Lua code of the YourEdgeThingTemplate.lua file should look like the following:   require "shapes.swupdate" module ( "templates.YourEdgeThingTemplate" , thingworx.template.extend) properties.low_grease={baseType= "NUMBER" , pushType= "ALWAYS" , value= 0 } properties.s1_fb1={baseType= "NUMBER" , pushType= "ALWAYS" , value= 0 } properties.s1_fb2={baseType= "NUMBER" , pushType= "ALWAYS" , value= 0 } properties.s1_fb3={baseType= "NUMBER" , pushType= "ALWAYS" , value= 0 } properties.s1_fb4={baseType= "NUMBER" , pushType= "ALWAYS" , value= 0 } properties.s1_fb5={baseType= "NUMBER" , pushType= "ALWAYS" , value= 0 } properties.s2_fb1={baseType= "NUMBER" , pushType= "ALWAYS" , value= 0 } properties.s2_fb2={baseType= "NUMBER" , pushType= "ALWAYS" , value= 0 } properties.s2_fb3={baseType= "NUMBER" , pushType= "ALWAYS" , value= 0 } properties.s2_fb4={baseType= "NUMBER" , pushType= "ALWAYS" , value= 0 } properties.s2_fb5={baseType= "NUMBER" , pushType= "ALWAYS" , value= 0 } serviceDefinitions.GetSystemProperties( output { baseType= "BOOLEAN" , description= "" }, description { "updates properties" } ) services.GetSystemProperties = function (me, headers, query, data) queryHardware() return 200 , true end function queryHardware () math .randomseed( tonumber ( tostring ( os .time()):reverse():sub( 1 , 6 )) ) local temp = math .random( 10 ) if temp < 6 then properties.low_grease.value= 0 properties.s1_fb1.value= 161 + math .random() properties.s1_fb2.value= 180 + math .random() properties.s1_fb3.value= 190 + math .random() properties.s1_fb4.value= 176 + math .random() properties.s1_fb5.value= 193 + math .random() properties.s2_fb1.value= 130 + math .random() properties.s2_fb2.value= 200 + math .random() properties.s2_fb3.value= 195 + math .random() properties.s2_fb4.value= 165 + math .random() properties.s2_fb5.value= 190 + math .random() else properties.low_grease.value= 1 properties.s1_fb1.value= 90 + math .random() properties.s1_fb2.value= 170 + math .random() properties.s1_fb3.value= 170 + math .random() properties.s1_fb4.value= 95 + math .random() properties.s1_fb5.value= 190 + math .random() properties.s2_fb1.value= 165 + math .random() properties.s2_fb2.value= 195 + math .random() properties.s2_fb3.value= 190 + math .random() properties.s2_fb4.value= 140 + math .random() properties.s2_fb5.value= 190 + math .random() end end tasks.refreshProperties = function (me) queryHardware() end       Step 4: Modify EdgeThing   Now that our EMS has been updated with Properties, as well as code to generate values for those Properties, we want to re-connect the EMS to Foundation and update the EdgeThing.   Note once again that EdgeThing was previously created in the Use the Edge MicroServer (EMS) to Connect to ThingWorx guide.   Restart the wsemse.exe program by returning to its PowerShell window and executing the following command: .\wsems.exe   Restart the luaScriptResource.exe program by returning to its separate PowerShell window and executing the following command: .\luaScriptResource.exe   Return to ThingWorx Foundation's EdgeThing. Note that EdgeThing is connected.   On the Properties and Alerts tab, click Manage Bindings.   At the bottom-left of the Manage Bindings pop-up, click + Add all properties.   At the bottom-right of the pop-up, click Done.   At the top, click Save.   Near the top, click Refresh repeatedly. Note that the Property values consistently change.          Click here to view Part 3 of this guide.

  Enhance your Engine Failure-Prediction GUI.     GUIDE CONCEPT   This guide will use ThingWorx Foundation’s Mashup Builder to create a more advanced Graphical User Interface (GUI) than the one we originally created to display results from Analytics Manager’s engine-failure predictions.   Following the steps in this guide, you will learn how to utilize Widgets and backend data to more completely visualize customer failure conditions.       YOU'LL LEARN HOW TO   Create a Mashup with a Header Divide your Mashup into Sub-sections Use a Contained Mashup to reuse development Store historical data in a Value Steam Display historical data in a Time Series Chart Show spreadsheet data via a Grid Widget Tie Mashup controls into the ThingWorx backend   NOTE: The estimated time to complete all parts of this guide is 60 minutes.     Step 1: Scenario   In this guide, we’re taking our previous MotorCo Minimum Viable Product (MVP) Mashup and expanding it.   Our original Mashup showed the results from ThingWorx Analytics as it determined whether or not a low-grease condition was currently present.   The goal of this guide is to create an Enhanced GUI to visualize those predicted “low grease” conditions in a more complete manner.     GUI-creation to visualize analytical model deployment can be extremely helpful for the automative segment in particular. For instance, each car that comes off the factory line could have an EMS constantly sending data from which an analytical model could automatically detect engine trouble.   This could enable your company to offer an engine monitoring subscription service to your customers.   This guide will show you how to visualize the results of an engine analytic model for a smart, connected products play.     Step 2: Create Mashup   Just like in the last guide, we're now going to create a Mashup to visualize ThingWorx Analytics results.   This one is simply going to be more complicated to include additional functionality.   But before we can start designing our GUI, we must first instantiate a Mashup onto which we can place our Widgets.       1. In ThingWorx Foundation, click Browse > Visualization > Mashups.         2. Click + New.       3. On the New Mashup pop-up under Responsive Templates, click Header Only.       4. Click OK.       5. In the Name field, type EEFV_Mashup.       6. If Project is not already set, search for and select PTCDefaultProject.       7. At the top, click Save.       8. At the top, click Design.         Step 3: Set Layout   Now that we’re in Mashup Builder, you can see the separate top-section of the central Canvas area created by our selection of “Header Only” on the New Mashup pop-up.   Unlike the original Mashup where we used Static Positioning, most of this Mashup will continue to use Responsive so that it can grow and shrink as resolution changes on various viewing devices.   To add multiple Responsive Widgets to a Responsive Positioning Mashup, though, you need to create some additional sub-sections. We’ll do so now.       1. In the top-left of Mashup Builder, click the Layout tab.       2. Click the main, bottom section of the Canvas, i.e. the non-header section, to select it.       3. On the Layout tab, click Add Top.       4. With the top-half of the original bottom section still selected, click Add Left.       5. Click in the bottom section to select the bottom-half of the original container.       6. Click Add Left.       7. At the top, click Save.      You now have a Responsive Positioning Mashup with five (5) sub-sections, i.e. :   Header Top-left Top-Right Bottom-left Bottom-right       Step 4: Adjust Header    In this step, we'll outfit the Header sub-section with a company name and logo.       1. Select the top Header section and ensure that you're still on the Layout tab in the top-left.         2. Change the Positioning to Static.       3. In the top-left, select the Widgets tab.       4. Drag-and-drop an Image Widget onto the Header section.       5. Expand the size of the Image Widget by dragging the corners.       6. Drag-and-drop a Label Widget onto the Header section.       7. Expand the size of the Label Widget.       8. With the Label Widget still selected, change the LabelText Property (in the bottom-left) to MotorCo, and hit the keyboard Tab key to lock-in your modification.         9. In the bottom-left, change to the Style Properties tab.       10. Expand Base > Label, and change font-size to 72px.       11. At the top, click Save.   Upload Media Image   We want to set the earlier Image Widget to the company logo.   To do so, we need to upload it to Foundation by creating a Media Entity.       1. Click Browse > Visualization > Media.       2. Click + New.       3. In the Name field, type EEFV_Logo.       4. If Project is not already set, search for and select PTCDefaultProject.       5. Right-click and "Save as" to download motorco-logo.jpg.       6. Under Image, click Change.       7. Navigate to and select the motorco-logo.jpg file you just downloaded.       8. Click Open.       9. At the top, click Save.   Change Image to Logo   Now that we have the company logo stored within ThingWorx, we can update the Image Widget to reference it.       1. Return to EEFV_Mashup.       2. Click the Image Widget to select it, and ensure that the bottom-left Properties tab is active.         3. Scroll down in the Properties until you find SourceURL.         4. In the Search Media field, type eefv.         5. Select EEFV_Logo.         6. Click Save.     Change Background Color   Finally, we want to change the background color of the Header.       1. In the top-left, select the Explorer tab. Note that the Explorer tab may be in the top-left drop-down if you're using a lower-resolution screen.         2. Select the Header itself.         3. In the bottom-left, select the Style Properties tab and expand Base > Container.         4. Beside background, click the white square to open a color-selector.       5. Select a color you desire.         6. Click Select.         7. Click Save.     Click here to view Part 2 of this guide.

  Step 6: Record Data   Now that we have a place to permanently store the values coming from the EMS engine simulator, we'll write a   Service   to take samples and place them within the Info Table.   Part of that Service, though, will be incrementing the   identifier, so we'll need to create one last Property.   Ensure that you're on the   Properties and Alerts   tab of   EdgeThing. At the top-left, click   + Add.     In the   Name   field of the slide-out on the right, type   identifier. Change the   Base Type   to   NUMBER. Click   Persistent. Click   Has Default Value. In the   Has Default Value   field, type   0.   At the top-right, click the "Check" button for   Done. At the top, click   Save.   Store the Property Values   With all the pieces in place, we can now create our Service to add entries to our Info Table Property.   At the top of   EdgeThing, click   Services.   At the top-left, click   + Add.   On the "+ Add" drop-down, select   Local (JavaScript). In the   Service Info > Name   field, type   recordService.     Expand   Me/Entities > Properties.     Click the   arrow   beside   infoTableProperty.     Type   .AddRow({   after me.infoTableProperty to being the process of calling the "AddRow()" function.     We now have called the function which will add a row of information to the Info Table Property, one entry for each column of the formatting Data Shape.   We just need to specify which values go into which column.   Add the following lines to store the individual Identifier count into the first column of the Info Table Property: identifier:me .identifier , Because we want the identifier in the stored data to increment on each run, and we want to start the count at   1   (and the Default Value is 0), add the following line to the top of the Service: me .identifier= me .identifier+ 1 ;       Add the low_grease value with the following line: low_grease:me .low_grease , Add the following lines to store the five frequency bands of the first sensor: s1_fb1:me .s1_fb1 , s1_fb2:me .s1_fb2 , s1_fb3:me .s1_fb3 , s1_fb4:me .s1_fb4 , s1_fb5:me .s1_fb5 , Add the final lines to store the five frequency bands of the second sensor and close out the AddRow() function: s2_fb1: me .s2_fb1, s2_fb2: me .s2_fb2, s2_fb3: me .s2_fb3, s2_fb4: me .s2_fb4, s2_fb5: me .s2_fb5 }); You completed Service should look like the following: me .identifier= me .identifier+ 1 ; me .infoTableProperty.AddRow({ identifier: me .identifier, low_grease: me .low_grease, s1_fb1: me .s1_fb1, s1_fb2: me .s1_fb2, s1_fb3: me .s1_fb3, s1_fb4: me .s1_fb4, s1_fb5: me .s1_fb5, s2_fb1: me .s2_fb1, s2_fb2: me .s2_fb2, s2_fb3: me .s2_fb3, s2_fb4: me .s2_fb4, s2_fb5: me .s2_fb5 });     At the top, click   Done. At the top, click   Save.       Run the Service   With our Service completed, let's run it to store a sampling of the data coming from our EMS Engine Simulator.   Under the   Execute   column in the center, on the   recordService row, click the "Play" icon for   Execute service. At the bottom-right, click   Execute.     At the bottom-right, click   Done. At the top, click   Properties and Alerts.   Under the   Value   column, on the   infoTableProperty   row, click the "Pencil" icon for   Set value of property.   Note that the Service has captured a snap-shot of the vibration data and grease condition and permanently stored it within the Info Table Property. You now have not only an Engine Simulator that is constantly sending data from a remote EMS, but a way to permanently record data at points that you deem significant.   Feel free to return to the Service and call it several more times. Each time, the values coming from the Engine Simulator will be stored in another entry in the Info Table Property.       Step 7: Next Steps   Congratulations! You've successfully completed the   Use the EMS to Create an Engine Simulator   guide, and learned how to:   Modify an EMS Template Provision Thing Properties and Values from an EMS rather than Foundation Send information from an EMS to Foundation Store large amounts of data in an InfoTable Property Create a simulator for testing   The next guide in the Vehicle Predictive Pre-Failure Detection with ThingWorx Platform learning path is Engine Simulator Data Storage. Learn More We recommend the following resources to continue your learning experience: Capability Guide Build Engine Simulator Data Storage Build Implement Services, Events and Subscriptions Additional Resources If you have questions, issues, or need additional information, refer to: Resource Link Community Developer Community Forum Support Analytics Builder Help Center  

    Step 5: Create InfoTable   Now that we have connected values coming from our EMS engine simulator, we want a method of permanent storage whenever we feel it's appropriate to take a sample.   From repeated sampling, we'll be able to build up a historical record usable for both manual inspection, as well as automatic analysis via   ThingWorx Analytics   (though ThingWorx Analytics is beyond the scope of this guide).   To hold these records, we'll use an   Info Table Property.   But any time that you create an Info Table, you first need a   Data Shape   to format the columns.   Click   Browse > MODELING > Data Shapes.     At the top-left, click   + New.   In the   Name   field, type   esimDataShape.     If Project is not already set, search for and select PTCDefaultProject. At the top, click   Field Definitions.     We now want to add a separate   Field Definition   for each entry of our engine simulator data, i.e. low_grease, s1_fb1 through s1_fb5, and s2_fb1 through s2_fb5.   In addition, we'll add an additional field named   identifier   which simply keeps a rolling count of the current log entry number.   Click   + Add.     In the   Name   field on the right slide-out, type   identifier Change the   Base Type   to   NUMBER. Check   Is Primary Key   At the top-right, click the "Check with a +" button for   Done and Add.     Repeatedly add additional definitions as per the chart below: Note that you will   NOT   check the "Is Primary Key" box, as you only need one, i.e. identifier. Name Base type low_grease NUMBER s1_fb1 NUMBER s1_fb2 NUMBER s1_fb3 NUMBER s1_fb4 NUMBER s1_fb5 NUMBER s2_fb1 NUMBER s2_fb2 NUMBER s2_fb3 NUMBER s2_fb4 NUMBER Create one additional entry for   s2_fb5   and   NUMBER, but click the "Check" button for   DONE. At the top, click   Save.     Create Info Table   Now that we have a   Data Shape   we can add an   Info Table Property   to   EdgeThing. Return to the   Properties and Alerts   tab of   EdgeThing.   At the top-left, click   + Add.   In the   Name   field of the slide-out on the right, type   infoTableProperty.   Change the   Base Type   to   INFOTABLE.   In the new   Data Shape   field, search for and select   esimDataShape.   Check the   Persistent   checkbox.   At the top-right, click the "Check" button for   Done. At the top, click   Save.     Click here for Part 4 of this guide.

Welcome to the ThingWorx Analytics Training Course! Through these 11 modules, you will learn all about the functionality of this software, as well as techniques to help you build a successful and meaningful predictive analytics application.

This video is Module 11: ThingWorx Analytics Mashup Exercise of the ThingWorx Analytics Training videos. It shows you how to create a ThingWorx project and populate it with entities that collectively comprise a functioning application. 

This video is  Module 10: ThingWorx Foundation & Analytics Integration  of the  ThingWorx Analytics Training  videos. It gives a brief review of core ThingWorx Platform functionality, and how the Analytics server works on top of the platform. It also describes the process of creating a simple application, complete with a mashup to display the information from a predictive model.

This video concludes  Module 9: Anomaly Detection  of the  ThingWorx Analytics Training  videos. It gives an overview of the "Statistical Process Control (SPC) Accelerator"

This video continues  Module 9: Anomaly Detection  of the  ThingWorx Analytics Training  videos. It begins with a ThingWatcher exercise, and concludes by describing Statistical Process Control (SPC). The "SPC Accelerator" will be covered in Module 9 Part 3.

This video begins  Module 9: Anomaly Detection  of the  ThingWorx Analytics Training  videos. It describes how Thingwatcher can be set up to monitor values streaming from connected assets, and send an alert if its behavior deviates from its 'normal' behavior.

This video concludes  Module 8: Time Series Modeling  of the  ThingWorx Analytics Training  videos.