The VANTIQ videos in this series are designed to show developers and operations managers the simplicity of building real-time, event-driven applications with VANTIQ. A specific use-case involving real-time field service of IoT-connected machines is discussed but please keep in mind that ANY event-driven application can be easily built in VANTIQ, supporting a wide range of use-cases.
This second video in the series shows human and machine collaboration. This video builds a collaboration in which to act on the situation we identified in the previous video. We look at the activities step by step for identifying a technician based on proximity to the situation, assigning the repair task, interacting through a mobile app, and tracking their location to the destination.
In our previous video, we built an application that takes in data from two different sources, and correlates them to identify a situation where temperature and revolutions per minute exceed certain values for an extended duration. Now we need to act on this. In VANTIQ acting on a situation is handled with what we call a collaboration.
We’ll start by adding a collaboration to the Danger situation we created in the previous video.
This creates the DangerCollaborationType, and we see it has a single initiate action.
Let’s configure the Collaboration Type.
Collaborator Roles Identify Variable names that will refer to certain stake holders that participate in our collaboration. Since the pump is going to be repaired by a technician, I’ll add a collaborator role called tech.
We also want to configure any entity roles, such as the VANTIQ types that we’ll need data from. In this case the pumps type and since we’ll only be referring to one pump in the context of this collaboration, we’ll reference it with the name pump.
Next we’ll configure the key types, and I’ll add the pumps and technicians type. This gives us the ability to search for a collaboration by these entity objects. For example, I could ask VANTIQ, “Show me all open collaborations for a given user, or a specific piece of equipment”.
Now we’ll configure the Initiate activity. The initialTrigger has already been filled out for us, so we just need to associate the entityRole we created a moment ago, which we called pump.
The next thing we’ll do is find the nearest technician in proximity to our pump so we’ll add a recommendationActivity and I’ll call it findTech.
We’ll configure this activity pattern, and set the output of the recommendation to technicians. meaning we want to find records of the type technicians.
We’ll also set some match directives, such as how many technicians we want to recommend, which in this the example will be just one and any properties that should not be considered for match criteria. Our technician type has: location, phone and username, of which we don’t want to consider the username or phone as part of the match criteria so we’ll exclude them.
Finally we’ll use a built in procedure called nearbyRecommendations, that uses the location as the primary search criteria.
Now we’ll configure the runTime property what we will pass into the recommendation engine, which in this case is simply the location of the pump. So our findTech activity will use the pumps location and our technicians location to determine which tech is closest to the pump.
Now that we have found our technician, we’ll use the assignment activity to associate our technician with the collaboration our collaborator role, who we are assigning is the tech, and the roll type is collaborator.
In the runtime parameters we’ll set the output of the findTech activity from above.
Now that our technician has been assigned to the collaboration, lets send a notification to their mobile device with the pump details.
We’ll use the Realtime Collaborative Services Editor to include information about the pump, such as its id, the current temperature and rpm values, as well as a map with the pumps location.
And we’ll set this forms name to “Pump Detail”.
Back in our collaboration we’ll add a Notification activity we’ll configure the mobile notification with a Title: Pump Issue, a body which will include the pumps name, and indicate that it is experiencing a technical issue and in the runtime parameters, we’ll identify who to send the form to which will be our tech, and we’ll set the payload or form details, to the form we created in the RCS editor which we called ”Pump Detail”.
At the same time, let’s make sure we know where this person is in relation to the pump. To do this will add a location tracking activity which uses the technicians mobile device for location updates. We’ll call it trackTech.
We could configure things like the desired accuracy, the proximity to the destination that triggers an arrival event, and some other parameters, but in this example we’ll just take the defaults.
For the runtime parameters we need to supply the users who we want to track which in this case is just our tech and the destination which is the pumps location, we’ll also add the ability to send a text message to our technician when they are in close proximity to the pump.
We’ll add an event task, and set the event type to arrival, and the task type to service. For the service name we’ll choose sendTextMessage.
This custom service takes 2 parameters, the message that we want to send, which we’ll set to “You have arrived at your destination”, and the username that we want to send the text message to which we’ll set as a reference to our tech that was previously assigned to the collaboration.
Our application will now collaborate with a technician when our Danger situation is triggered by using a mobile application to send detail to the technician, as well as provide location tracking so that our technician will know when they are in close proximity to the pump.
Proceed to the next video in this series.