Updating the Status of a Fire Unit

[MeleKoneya]

Good Afternoon,

We are using field maps to track our Fire Department staff during the Event Season in Scottsdale (Barrett Jackson Auto Auction, WM Phoenix Open Golf Tournament)

With the tracking view updated by Field Maps, we are enriching the input with GeoEvent Server and updating a hosted feature layer in ArcGIS Online with additional data from a hosted table layer.

The hosted enrichment table, above left, includes the first and last names, and most importantly the call sign that the user is assigned each day.   This assignment changes daily.  For example, one day MC610 (medical cart) is staffed by one team and a  different team the next. 

Additionally, we have a tag in the enrichment table for Medics as they leave to event sites.   

Following the lead of @RJSunderman with the concept of partial updates, the top input/output where the call sign is set rounds every 180.   

The bottom input/output of the fields from the track view updates every 10 seconds.   This approach has worked well and created a stable update.

The username is the Unique Feature Identifier Field (Track_ID) in both parts of the service

The next phase I tried to implement this year was to update the unit status of the units on site at the event.  I have another GeoEvent service which processes CAD data to generate SQL records based on the status of a unit (Available, On Call). 

In the above service, I am using a map service to push the unit status to the same hosted feature layer that is used to update the locations and call signs in a hosted feature layer.

However, in this above example, I am using the call sign as the Unique Identifier Field (Track_ID) so in theory when MC610 gets a call there status would change.     I had tested this approach but during the event season it did not prove to be reliable.   

I could see that the service was pushing the values to the hosted feature layer, but that hosted feature layer did not update.    

I was wondering if I need to use the same Unique Identifier of username for both processes, but did not have the time to try it out once the events started.

It also seemed that a side effect of using the call sign as the Unique Identifier Field, was that the hosted feature layer might toggle to the wrong call sign despite what the first service doing the enrichments was setting the value as. 

Let me know if anyone has any thoughts on how best to do this.    

Thank you 

Mele

[JeffSilberberg]

It would seem you have the flow correct. You are dispatching the Unit ID so the feature layer using that as that Track ID and maintaining the unit status is what you should've updated.  

Is it as simple as the refresh rate on the map/dashboard needs to be tweaked?  Not sure you can update a dashboard/map based on a triggering event which could be an alternative to the refresh rate and of course, you need to balance update frequency and bandwidth availability.   

[RJSunderman · Accepted solution]

Thank you @JeffSilberberg for reviewing the problem and considering a solution. @MeleKoneya and I are working off-line on this.

Our current suspicion is that data in the first enrichment table (retrieving username and callSign) is getting call signs from prior day(s) operations such that that the same callSign value might be assigned to more than one EMT in the target hosted feature layer (using the username as the unique identifier).

Then, when a secondary enrichment process retrieves status data from the CAD system, the first feature record found with a particular callSign is updated and the dashboard shows an an EMT's status incorrectly (correct real-time status, wrong EMT).

We are going to try clearing out the assigned callSign each morning before daily operations, so that each day's assigned call signs are assigned to a single EMT. Then evaluate to see if status values from the CAD are able to use the unique call sign to update each EMT's status.

[JeffSilberberg]

Just curious what your resolution was as I now have a similar need with a project..

[MeleKoneya]

@JeffSilberberg as RJ was describing, the issue seemed to be that we have a carryover and duplication of the call signs each day and GeoEvent Server didn't know which was the 'correct' one to use.   I have  been testing my GeoEvent Services since I received further info from RJ and things look good so far.    I am testing it now as two active fire units in the City.    The real test will be during our events, but I suspect that the clear out of call signs is the key for us each day.