Background
Mobile devices, like smartphones, can be used as "terminals" of IoT networks because they are equipped with numerous sensors that can record the environment. Smartphones nowadays are a commodity, almost always carried by their users, including when they are drivers or passengers of vehicles. Therefore, they can be used as automatic crash notification IoT devices, with the following important limitations:
- The sensors in personal mobile devices are designed to address specific user needs, like gaming. They have very good specifications on their sensitivity and their resolution, but they have minimum range: The best accelerometer in a mobile phone can measure acceleration values of ±8g, when the forces involved in a car accident can create a negative acceleration of 100g. These sensors cannot record an accident. They can only POSSIBLY identify the beginning of an accident.
- Any unusual sensor readings, a phenomenon common on cell phones, can be misinterpreted as the POSSIBILITY of an accident and initiate an ALARM dispatch procedure, when the phenomena most likely are FALSE ALARMS (also noted as false positives). The sheer amount of such FALSE ALARMS will create a distributed denial of service (DDoS) to the public safety answering point (PSAP).
- In the case of a severe accident, where the passengers of the involved vehicle(s) will not be able to ask for help, it is almost certain that any phone in the vehicle(s) will be not operational.
For the above reasons it is obvious that smartphones lack the functionality and reliability required for a life-depending device because they can not monitor a severe traffic accident through its full timeline and cannot issue a VERIFIED alarm. On the other hand, a smartphone using its sensors can recognize the forthcoming of an accident from the unusual change of its kinetic state and pass this critical (but not definite) information to an external monitoring system before it is destroyed by the crash. A solution, called PODIS, is using this approach. A distress signal will leave the phone in time, before its possible destruction, and cancel the alarm transparently to the PSAP if the phone remained operational after the suspicious event. The system is issuing fail-safe crash notifications and is monitoring not only the driver of a vehicle but also the passengers of cars, professional vehicles, public transport and cyclists
This is the simple operating principle of the PODIS system.
PODiS (POst DIstress Signal)
System description
A cloud-based client-server system, where the client is an application installed in a mobile device (smartphone or tablet) and the server is a virtual private cloud (VPC) of processing and database servers, load balancers, security devices, etc.
Monitoring stage
The PODIS client is reading the mobile device sensors in a high frequency rate (minimum 50 Hz) and is calculating its kinetic state by fusing the readings of the sensors. It is then predicting the next kinetic state of the mobile device by using a specialized signal processing algorithm.
The client is comparing the difference between the predicted and the current state against a predefined threshold in every single operating cycle.
See also: 7 Imperatives for Moving Into the Cloud
Provisional alarm (Client side)
If the difference between the predicted and the actual current kinetic state exceeds a threshold, a provisional flag is raised by the client and a provisional alarm (PA) is transmitted to the cloud server. The client is capable of transmitting a complete PA in milliseconds, well before the main vehicle parts and the client itself start to destruct. The latter typically takes in the range of 150 ms.
Provisional alarm (Server side)
When a PA is received by the cloud server, all received data (including user ID, location coordinates and timestamps) are recorded as a predicted event, and the server puts the specific client under supervision and starts monitoring for its next signal.
False alarm (Client side)
The client is checking in pre-defined intervals, for example every 5 seconds, if the PA flag is raised; if it is, the client transmits to the server a false alarm signal and sets off the flag. In case the PA flag is ON, the client is keeping pushing the kinetic and the location data to the server(s) for a short time for the server to check if the client survived from a severe accident (very unlikely).
False alarm (Server side)
When a PA signal is received, the server is waiting for a false alarm (FA) signal from the specific client for a predefined period, for instance 20 seconds, and if an FA is received then the event will be recorded internally as a false alarm with no further action.
Real alarm (Server side only)
If no false alarm is received from a client that raised a PA within a predefined period, then the server is raising a verified alarm ticket with all available data to the connected PSAP.
Unverified accident (Server side)
If the server receives data showing very little kinetic activity and short distance movement after a PA, then a non-verified alarm ticket is pushed to PSAP for further investigation.
Threshold processing method
Each smartphone, which for Android means 24,000 distinct devices from more than 1,000 different manufacturers, has its own characteristics and specifications. Thus, the same sensor from a certain manufacturer does not have the same characteristics in different smartphone models. Moreover, each individual driver has his/her own driving behavior. For example, a hard braking can be an emergency sign for one driver, while it can be an everyday driving practice for someone else. The server side is using a self-learning system that, at a very high level, is recording the PA values for each individual smartphone model and every single user when a PA is followed by a FA, and it adjusts accordingly the specific threshold. The new threshold value is pushed to the server for the record of the specific client. The system is effective: It will take just a few driving hours to eliminate the FA for a newly registered user if he/she is using a new smartphone model.
See also: Profiles in the Customer Experience
Energy consumption and data traffic
The client is running in the background as a service, only when it is in a moving vehicle with limited battery consumption. The maximum flow of mobile data is 2.6 MB per day for 24 hours driving use.
NB: The above description is a simplified version of the principles behind the system. The system is already in use by insurers as a running service, while successful extended pilots have been performed around the world.
The system and the method
are patented: USPTO patent No. 9,758,120.
