Implementation of man down functionality in Perspective App

We intend to implement a man down system making use of the Perspective App, basically we have a script running an algorithm fed with the data of the mobile phone accelerometers to detect inactivity. One key requirement is that the tracking of the accelerometers must be “continuous”, hence the App should be permanently connected to the Gateway, once it is launched from the operator’s mobile phone and regardless of whether or not the user locks the phone.

According to the tests we have carried out so far, the App automatically disconnects form the Gateway after a given time, is it possible to change any parameter to achive the robustness we aim for?

I strongly recommend you not do anything safety critical in Ignition, or any other SCADA system. This sounds like something you should be doing in a dedicated Mobile App, that directly connects to an alert system. A dedicated mobile app can ask the OS to run in the background all the time.

3 Likes

Thank you Phil

Just to add a little to Phils response, you could use the web dev module in Ignition to have your dedicated app update Ignition using web services if you want to use Ignition as your monitoring system.

Uh, no. That would contrary to my response. Ignition isn’t designed for this sort of thing. If you wanted it as a secondary system for management, maybe. Not for the actual alert system. There are standards for such things.

1 Like

Whats the standard? I remember Inductive publishing a case study that talked about someone using Factory PMI for a man down system. I just have a really hard time imagining that the hundreds of apps and search results of man down systems are working on some standard that cant be met by Ignition serving as the monitoring service. Just to be clear, I am only talking about Ignition being sent data from the device that will be doing the movement monitoring and then doing the callouts when a device would sense no movement or fail to check in.

There’s no good standard for man-down, though some guidelines exist. This article summarizes the situation well. The issue is best practices for delivering the safety alert once triggered. The best available network for reliable signalling is practically always the phone network. That is regulated infrastructure with dedicated hardware and software purpose-designed for reliability and uptime. Relying on an application server that has no performance, reliability, or uptime specifications, open to just about anyone running a designer, and subject to Java’s occasional hiccups… Well, IANAL, but that sounds like lawyer-bait to me.

2 Likes

I guess it all depends on what you define as “man down”. We built an app in FactoryPMI/FactorySQL that used SpotGPS tranceivers, whict sent its GPS coordinates to the provider, who then push the message to our web server. We would then compare the coordinates to a table of geofences, and would use that to determine if they were on a hazardous location, in transit, or at home. It worked really well. If I were to build it again, I would do it a little differently. Depending on infrastructure, something like Traccar or OwnTracks would work. You won’t get the accelerometer, however. Zanzito was a good app, as it provided all the sensors over MQTT, but development of the app has stopped.

My recommendation would be to build a stand alone Android and IOS app, and report your data either over HTTPS to webdev, or via MQTT.

Thank you for your comments Kyle,

What we are looking for is a simpler approach, similar to this one https://staysafeapp.com/lone-worker-solution/lone-worker-app/#/solution/3

1 Like