The problem PODIS solves

Infographic explaining the concept of the 'Golden Hour', emphasising that casualties have a better chance of survival if delivered to a hospital within one hour of the accident. It outlines the factors affecting the golden hour's efficiency, including reporting delays and location fixing by PSAPs. The infographic also highlights that the golden hour encompasses call-out, travel, extrication, transport, and resuscitation times. The PODIS system is the solution to automate and minimise the time needed to identify the accident's location.

Industry Challenges




  • False Positives, or simply False Alarms:  A Denial of Service to Call Centers:  Costs, Wasted resources, Risk of missing out actual Alarms, Bad end-Customer eXperience


  • On-vehicle, permanently installed systems:   The end to end system i.e., the device, the wiring, the connections and the antenna, must be fully functioning for a period that must equal the time needed to process the signals and transmit accident related information. This period of time is finite in the range of milliseconds. The survivability of involved system elements, especially wiring and antennas, is not guaranteed in cases of severe accidents and in cases where the impact point is in the proximity of their installation.


  • Phones and apps:  sensors designed for gaming cannot record an accident. They can only POSSIBLY identify the beginning of an accident. Any unusual sensor readings, a phenomenon common on cell phones, will create FALSE ALARMS

THE PODIS METHOD / HIGH LEVEL SYSTEM DESCRIPTION


A cloud based client - server system. The Client is an application installed in the motor vehicle. It can be either onboard, or aftermarket. The Server is a virtual private cloud of processing and database servers, load balancers, security devices etc, where processing is based on Machine Learning.



PODIS Client side:

  • Reports geolocation data to the Server side
  • Reads data from its sensors
  • Calculates its kinetic state
  • Uses a specialized algorithm to predict its next kinetic state
  • If the actual next kinetic state is above a 'threshold'it raises a provisional alarm (PA) to the Server side. The 'threshold' is produced on the Server side and it is unique for each Client


PODIS Server side receiving a PA:

  • The Client is put under supervision mode


PODIS Client side post a PA on a False Alarm:

  • If the Client keeps working and its measurements are within the defined threshold limits, it raises a False Alarm (FA) to the Server side


PODIS Server side receiving a FA:

  • The Client is put under 'Supervision Mode'.
  • The FA is recorded for further processing (feature input to an ML model). This is when the threshold values for the specific Client are re-calculated and pushed back to the Client


PODIS Server side receiving a PA without an FA:

  • If comms are lost a Verified Alarm is raised, visible to the Operators of the System
  • The System also handles the case where minor kinetic state changes and minimum short distance movement are detected to raised an Unverified Alarm


The system and the method are patented: USPTO patent No. 9,758,120




PODIS Field Trials:

Component Value
Geographies EU and AMEA
Number of Countries 8
Clients Interested parties (insurance and roadside assistance companies) deploying on their employees fleet
Server Side Public Cloud
Client Side iOS and Android apps developed by PODIS Ltd; all available iPhones on the local markets; a diverse set of Android phones
Time to raise a PA (all cases) 4 - 32 ms
mobile data consumed max 2.6MB/24hrs
Number of False Alarms 0
ML Time to Min PA Convergence for New User a few driving hours
Public Cloud Unit Cost low single US$ digit per user per year
Projected Public Cloud Unit Cost less than or equal to US$1.00 per user per year for a significant number of users
Power Consumption The Client is running on the background as a service, only when it is in a moving vehicle with limited battery consumption.