Warning
This post is quite long, has various chapters and you might get bored reading it.
If you just want a summary read the "Use case" and "Conclusion" chapter - and maybe the "Required Logic" chapter, because I made a cool graph for it. The rest is all about implementation...
Introduction
I recently had the opportunity to deliver a ThingWorx training for Saint Gobain.
One of the use cases for their ThingWorx application is monitoring machine errors and outages on the production line. If an outage or error status is triggered, the machine operator will see a popup on the monitoring screen where he is forced to select a root cause. This root cause will then be persisted in ThingWorx for more data transformation, analytics and reporting - like cost analysis or optimization opportunities.
During the training we were also discussing on how such a forced root cause monitoring can be implemented via Mashups and the usage of modal popups.
I've compiled the details into this post as it might also interest other developers.
The ThingWorx Entities I'm using in this example can be downloaded from here
Note: I'm using the word "Alert" here - but not in the context of a ThingWorx Property Alert... just beware to not be confused due to the wording.
Use Case
One of the requirements for Saint Gobain's IoT Solution was an interactive alert monitoring directly in the factory on the production machines. Let's say the machine has stopped, the root cause should be recorded. For this an interactive popup will be displayed on the machine's monitoring display and an employee has to choose the root cause from a pre-defined list.
This could be planned outages, e.g. for maintenance or unplanned outages, e.g. material jam.
The root cause will then be recorded and a history of outage causes can be stored in a ThingWorx value stream. This can then be later analyzed with e.g. ThingWorx Analytics capabilities to understand and optimize the machine's production capabilities and efficiency.
As the root cause must be entered, the popup will be forced to be displayed when a certain condition / criteria is met - and it will only disappar when a root cause is chosen. The user should not be able to interact with any other elements of the Mashup and not be able to just close the popup. The popup will close itself and reset the initial condition once the root cause has been identified and chosen.
Requirements
Note: Just to make it easier to manage and export Entities, I will add all of the created elements in a new Project called RootCausePopups. All of the elements will have a "rcp_" added in front of their name - just to make it easier for me to find and identify them.
Implementation
Conclusion
- Certain conditions (like the state of a checkbox) can be used to trigger modal popups.
- A modal popup forces a user interaction and the interaction will not offer any other option until a choice is made.
- With these parameters it's easy to have mandatory reaction from users when it's important to capture data which rely on the analysis of an engineer or a user - e.g. reasons for machine outages.
- Using this technique there's not much training required for staff, other than pushing a button with an option of their choice - this saves quite some time in capturing data in any other way (e.g. updating Excel files or manual pen-and-paper techniques).
- As this data is now part of the ThingWorx instance it can be used for further transformation, analysis or just for monitoring purposes
- There's of course more possibilities when it comes to states and formatting which would exhaust the context of this post - but feel free to explore...
- In the example we wouldn't need the textbox, but it's there to demonstrate if the correct values are persisted or not
- In the example we could of course also set the visibility of the checkbox to false, so that we would only see the popup and the Grid holding historic information
- We could also create different StateDefinitions to color-format / text-format the input differently from the output in the Grid
If you found this interesting (and actually made it to the end of this post) - feel free to play with this concept a bit more...
The dependencies might seem a bit difficult, but it should be easy to implement and to adjust to your own ideas and requirements.
