Abstract:
The present disclosure relates to a system and method for locating slow or stopped vehicles on a roadway and alerting drivers approaching the back of a queue, and in particular to intelligent transportation systems and traffic management.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     The present U.S. patent application is related to and claims the priority benefit of U.S. Provisional Patent Application Ser. No. 62/046,656, filed Sep. 5, 2014, the contents of which is hereby incorporated by reference in its entirety into this disclosure. 
    
    
     TECHNICAL FIELD 
     The present disclosure generally relates to a system and method for locating slow or stopped vehicles on a roadway and alerting drivers approaching the back of a queue, and in particular to intelligent transportation systems and traffic management. 
     BACKGROUND 
     This section introduces aspects that may help facilitate a better understanding of the disclosure. Accordingly, these statements are to be read in this light and are not to be understood as admissions about what is or is not prior art. 
     Currently in the practice of traffic congestion management there are typically humans in the loop that identify traffic problems using cameras or driver phone calls. The information is disseminated via means that include Traffic Message Signs, radio broadcasts, and TWITTER® feeds. This approach is time consuming and is limited to areas of the road network accessible by a costly Intelligent Transportation Systems infrastructure. A significant national concern is the frequency of fatal crashes due to distracted and inattentive drivers colliding into the back of a slowed or stopped queue. In recent years, crowd-sourced probe vehicle data has become commercially available, allowing for engineers and planners to assess traffic conditions on their road networks in real time. The data are provided as an average speed during a one minute interval over a predefined geometric segment of roadway. Using simple arithmetic, the difference in speed from one segment to the next, or delta speed, can then be calculated. This delta speed of average segment speeds is a good indicator if there is traffic congestion within a geometric segment. Using real time data to assess the road conditions and alert drivers will provide a quick and efficient way of preventing back of queue crashes. In the modern era of distracted driving new approaches are necessary to alert drivers before the critical decision point. 
     There is therefore an unmet need to use real-time data to identify locations with stopped or slowing traffic and alert drivers upstream using flashing lights, audible sirens, or display boards. 
     SUMMARY 
     In one aspect, a method for using a geo-referenced field device to query cloud-based traffic data to notify drivers of impending congestion is disclosed. In another aspect, a system for using a geo-referenced field device to query cloud-based traffic data to notify drivers of impending congestion is disclosed. In yet another aspect, a device for using a geo-referenced field device to query cloud-based traffic data to notify drivers of impending congestion is disclosed. 
     In yet another aspect, a method for using a geo-referenced field device to query cloud-based traffic data to notify drivers of impending congestion is disclosed. The method includes the steps of placing a geo-referenced field device in a field, the geo-referenced field device is communicatively coupled to a server and the geo-referenced field device is configured to obtain a speed data from a cloud source and perform calculations therefrom, contacting the server, the server is in a location where the calculations have been performed, transmitting a message to the geo-referenced field device at a pre-defined interval and at a change of traffic condition, polling calculations from the server via a message from the server configured to monitor traffic conditions, and activating an audio and visual notification by the geo-referenced field device using commands from a message from the server. 
     In yet another aspect, the geo-referenced field device is configured to have global positioning system (GPS) orientation specified. In yet another aspect, the geo-referenced field device is configured to automatically acquire a location from GPS. 
     In another aspect, the geo-referenced field device is configured to use an electronic compass to determine orientation. In yet another aspect, the geo-referenced field device is configured to have location specified by an operator. In yet another aspect, the geo-referenced field device is configured to have location adjusted by the operator. In yet another aspect, the cloud based traffic data is centrally-collected point data such as information transportation systems (ITS) between roadway interchanges and intersections. In yet another aspect, the cloud based traffic data is comprised of wireless technology-based segments, such as Bluetooth or WiFi. In yet another aspect, the cloud based traffic data is comprised of commercial probe data, such as INRIX®, NOKIA®, GOOGLE®, and HERE® probe data. In yet another aspect, the audio and visual notification is at least one of a siren, a portable message sign, a fixed message sign, at least one strobe on at least one fixed sign with messages determined by a reporting agency, or at least one strobe on at least one guardrail with at least one advance sign, the at least one advance sign is configured to indicate how to interpret the at least one strobe. In yet another aspect, the geo-referenced field device is powered by at least one of an alternating current power source, a battery power source, or a battery source with solar augmentation. 
     In another aspect, a system for using a geo-referenced field device to query cloud-based traffic data to notify drivers of impending congestion is disclosed. The system includes a computer, a global positioning system (GPS) device, communicatively coupled to the computer, a cloud data source, a radio communication, and a device configured to deliver messages between the computer and the cloud data source. The radio communication can be a commercial cellular communication. The radio communication can also be an RF device. 
    
    
     
       BRIEF DESCRIPTION OF THE FIGURES 
         FIGS. 1 a -1 b    are illustrations of end of queue fatal crash examples in Indiana. 
         FIGS. 2 a -2 e    illustrate methods of delivering end of queue information to drivers. 
         FIG. 3  depicts an embodiment of the herein disclosed incident detection application. 
         FIG. 4  depicts the over 2,500 interstate segments using crowd sourced probe vehicle data. 
         FIG. 5  depicts an example of an incident alert system. 
         FIGS. 6 a -6 b    depict examples of permanent and temporary alert systems. 
         FIG. 7  illustrates the basic overview of the herein disclosed device&#39;s function. 
         FIG. 8  is a schematic depicting the device&#39;s process flow operation. 
         FIG. 9  depicts an explanation of delta speed data using segment speeds. 
         FIG. 10  depicts an explanation of delta speed data using point speeds. 
         FIG. 11  illustrates the device methodology with server side calculations. 
         FIG. 12  illustrates the device methodology with device side calculations. 
         FIG. 13  illustrates a device logic flow chart. 
         FIG. 14  depicts the data description with archived time data. 
         FIG. 15  illustrates the human-in-the-loop override alternative of the device. 
     
    
    
     DETAILED DESCRIPTION 
     For the purposes of promoting an understanding of the principles of the present disclosure, reference will now be made to the embodiments illustrated in the drawings, and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of this disclosure is thereby intended. 
     In response to the need for a method and system that uses real-time data to identify locations with stopped or slowing traffic and alert drivers upstream using message relay means such as flashing lights, audible sirens, or display boards, such a system and method is disclosed herein. These messages will have various mounting techniques and specifications, which will be discussed in further detail herein. 
     The purpose of the herein disclosed device, method, and system is to take real-time traffic data and its current geographic location and then output an alert to motorists. The herein described device and system include computer, a global positioning system (GPS) device, a radio communication (commercial cellular or licensed RF device), and a method for delivering messages between the computer and a cloud data source. The device is powered by one of three options: AC, battery, or battery with a solar augmentation. The device either polls or receives automated messages from a server and emits a signal if there is congestion ahead of the device on the roadway. There are variations for how the message is transmitted to the device and how the device displays an alert signal. 
     In one embodiment, the system and method of the present disclosure provide the means for alerting drivers of upcoming queues by leveraging real-time traffic data. This will be accomplished by displaying a warning signal in advance of stopped or slow moving traffic. This reduces the risk for a back-of-queue crash by alerting any potentially distracted or inattentive drivers of a potential need to slow down. This warning sign can be triggered in a plurality of ways, including with or without a human approval in the loop. In addition, in another embodiment, the installation of this device can be temporary for addressing non-recurring congestion near work zones or maintenance areas. This will involve a temporary setup where the device and warning flashers are mounted to a moveable post or an existing permanent structure. 
     As a demonstration of the need and use of the herein described method, system, and device, a summary of need and use cases is provided below. 
     In July and August of 2013 Indiana experienced the loss of 8 passengers in vehicles traveling on Interstate 65 due to crashes ( FIGS. 1 a  and 1 b   , which show pictures of end of queue fatal crash examples in Indiana).  FIG. 1 a    shows an example occurring on Aug. 15, 2013 on 1-65 at mile marker 231 Northbound, which resulted in seven fatalities (photo courtesy of RTV6).  FIG. 1 b    shows an example occurring on Jul. 31, 2013 between IND 10 and IND 2 Northbound, which resulted in one fatality (photo courtesy of nwi.com). The cause of both crashes depicted in  FIGS. 1 a  and 1 b    were queues due to a workzone in the northbound direction of 1-65. In both cases a truck driven by a distracted driver was unable to stop upon arriving at the end of the queue. The truck struck the vehicle at the end of the queue causing a tragic and fatal result. The Indiana Department of Transportation has begun to research and invest in preventative measures to avoid similar crashes in the future. The existing methods of preventing back of queue crashes are illustrated in  FIGS. 2 a -2 e   .  FIG. 2 a    shows a typical incident that caused a significant queue on 1-94 near Chicago in Indiana. The typical options or means of alerting traffic upstream of a crash include: visually seeing the brake lights of stopped vehicles at the back of a queue ( FIG. 2 b   ); audibly hearing traffic updates from an emergency or local radio station ( FIG. 2 c   ); visually or audibly being alerted by GPS devices or smartphone-type device applications ( FIG. 2 d   ); and visually seeing Traffic Message signs that display the warning ( FIG. 2 e   ). These options all have major shortcomings when looking at their cost or effectiveness. Brake lights of vehicles ahead often will not alert a distracted driver soon enough to stop. Traffic updates on the radio are not readily available, involve a human-in-the-loop, and require a driver to tune in to the proper radio network. GPS or smartphone-type device applications often are a distraction to the driver and are limited to tech-savvy users. Traffic Message signs are the best alternative, but are extremely expensive to install and maintain and require extensive infrastructure investments. Additionally, Traffic Message signs typically involve a human-in-the-loop to program the alert on the sign, which is both a costly and inefficient means to quickly identify queues. 
     In 2014, INDOT-funded research developed an incident detection application using crowd sourced probe vehicle data ( FIG. 3 ). Crowd sourced probe vehicle data is collected using a smartphone-type device and GPS from application users. Third party commercial companies collect the information and calculate average speeds over one minute time periods. This information is then disseminated in near real-time to their clients. Using this cloud data source, the herein disclosed application pinpoints geographic locations where the vehicles have shifted from free-flowing speeds to congested speeds. This performance measure that looks at adjacent segments defined by the crowd sourced probe data providers is known as the “delta speed” between two segments. The benefit of using this crowd sourced probe vehicle data is the coverage across the state and the country. As an example, in the state of Indiana, there are over 2,500 segments ( FIG. 4 ), which results in a delta speed value nearly every two miles on the interstate system in Indiana. These data analyses allow for a scalable approach for locating congestion problems statewide, reducing the dependency of the human-in-the-loop and the cost of traffic detection infrastructure that can be millions of dollars per mile. 
     The herein disclosed device will leverage this incident detection system and use it to automate alerts in the field in real time. These alerts will avoid the high infrastructure costs and also will be available for all drivers, and not only to those who use smartphone-type devices or GPS devices while driving. Referring to  FIG. 5 , an example of such an alert system is shown. This alert is triggered by the device to alert drivers of upcoming congestion. The strobe light on this sign flashes at different frequencies to signify the proximity of the driver to the queue. This significantly reduces the risk of back of queue crashes by giving drivers an additional opportunity to see upcoming congestion. It shall be noted that the alert system is not limited to a flashing strobe light mounted on a sign. The device can also be attached to temporary message signs, permanent message signs, or strobes mounted temporarily on permanent infrastructure. 
     Although not exhaustive, the implementation of the herein disclosed method, device, and system has two main uses: temporary installation and permanent installation. The temporary installation can be used in work zones that are expecting queues or in areas where non-recurring congestion is anticipated. An installation technique can be similar to that of a temporary work zone sign, as shown in  FIG. 6 a   . The permanent installations can be used in urban areas and where there are regular instances of recurring and non-recurring congestion. A permanent installation can be mounted to a permanent sign fixture similar to that shown in  FIG. 6 b   . This device has numerous applications and, because the data sources that it uses are a rapidly emerging global technology, the device has unlimited growth potential. 
     An embodiment of the disclosed device application is shown in  FIG. 7 . The device sends a GPS location to a server and the server sends back the traffic data required nearest to the device. The device then uses built-in logic statements to determine if or which alert to send to the attached alert system. The foregoing is a simpler representation of the herein disclosed device, following a simple path from data server to device to alert system. 
     The process in which the device retrieves the information and outputs the alert is depicted in  FIG. 8 .  FIG. 8  elaborates on the data required to process the crowd sourced probe vehicle data and calculate delta speeds. It also elaborates on the server process to distribute the required speed data. It is important to note that the herein disclosed process can be completed with one server, which is configured to collect the raw speed data and outputs the delta speeds or with two servers, one being a third-party cloud data source collecting the raw speed data and another being the storage server where the speeds are stored after purchasing from the third-party supplier. 
     It should also be noted that the device does not require a specific data type. Numerous methods of collecting speed data on roadways exist, any one of which can be inputted into the device. Two primary methods are segment speed and point speed. The segment speed methodology is depicted in  FIG. 9 . There are three segments where in an average speed is calculated. Using these segment speeds, a delta speed is determined at the points between the segments. The delta speed is defined as the difference between the average speeds of each segment. The segment speed methodology is primarily used by the third-party crowd sourced probe data providers. The other speed methodology that can be used is point speeds. Point speeds are generally used by departments of transportation with side-fire radar, loop detection, magnetometer detection, or other speed measurement devices. Point speeds can also be used by this device to determine delta speeds, where the delta speed would be assumed to be between two adjacent point speeds ( FIG. 10 ). 
     In addition, there are two methods in which the delta speeds can be calculated. Using the first method ( FIG. 11 ), the delta speeds are calculated by the server and the device collects a number of delta speeds downstream based on its location. The second method ( FIG. 12 ) involves the device collecting the speed information for a pre-determined number of segments or points downstream and calculates the delta speeds. 
     The methodology in which the device triggers an alert is shown in  FIG. 13 . There are numerous variables that need to be defined by an operator (such as an engineer). These variables are used to provide flexibility for thresholds and data collection that will be flexible to scale spatially. These values include the number of minutes of data to retrieve (M), the number of downstream locations (L), the delta speed alert threshold value (D), the number of minutes this threshold can be exceeded (N), and the alert signal intensity for each delta representation (Z). The variables allows for a customization that can be adjusted for numerous use cases. 
     The delta speed collection is explained in  FIG. 14 . The delta speed calculation can be performed for a number of downstream segments (L). This feature allows the user to select the length of roadway ahead of the device where a warranted alert is displayed. The user can also determine how long the delta speed has to be above a certain threshold, allowing the device to be more customizable. These parameters can also affect the cost of both the data source, the server specifications, and the cellular requirements of the device. 
     In yet another embodiment, the device includes a manual override, where dispatch can bypass the device logic and manually turn on the alert system (defined in  FIG. 15 ). In yet another embodiment, the device includes a peer-to-peer communication protocol. 
     Those skilled in the art will recognize that numerous modifications can be made to the specific implementations described above. The implementations should not be limited to the particular limitations described. Other implementations may be possible. 
     REFERENCES 
     
         
         1. Remias, S., T. Brennan, C. Day, H. Summers, E. Cox, D. Horton, and D. Bullock. 2012  Indiana Mobility Report: Full Version.  2013 doi: 10.5703/1288284315190, ISBN 978-1-62260-257-5. 
         2. Remias, S., T. Brennan, G. Grimmer, E. Cox, D. Horton, and D. Bullock. 2011  Indiana Interstate Mobility Report—Full Version. Indiana Mobility Reports.  2012 doi: 10.5703/1288284314680. 
         3. iCone: The instant I.T.S. System. http://iconeproducts.com/. 
         4. Li, H., S. M. Remias, C. M. Day, M. M. Mekker, J. R. Sturdevant, D. M. Bullock,  Incident Detection Using Cloud - Based Probe Data . Transportation Research board, Paper No. 15-0714. 2015.