|
(11) | EP 3 411 867 B1 |
| (12) | EUROPEAN PATENT SPECIFICATION |
|
|
| (54) |
RED LIGHT WARNING SYSTEM BASED ON PREDICTIVE TRAFFIC SIGNAL STATE DATA ROTES LICHTWARNSYSTEM BASIERT AUF VORAUSGESAGTEN DATEN ÜBER EINEN VERKEHRSSIGNALZUSTAND SYSTÈME D'AVERTISSEMENT POUR FEU ROUGE BASÉ SUR LES DONNÉES PRÉDICTIVES DE L'ÉTAT D'UN SIGNAL DE CIRCULATION |
|
|
|||||||||||||||||||||||||||||||
| Note: Within nine months from the publication of the mention of the grant of the European patent, any person may give notice to the European Patent Office of opposition to the European patent granted. Notice of opposition shall be filed in a written reasoned statement. It shall not be deemed to have been filed until the opposition fee has been paid. (Art. 99(1) European Patent Convention). |
Technical Field
[0001] This disclosure pertains to electric traffic control signals of the sort commonly found at street intersections, freeway ramps, and the like, for directing traffic, which may include without limitation pedestrians, bicycles, cars, buses, mass transit vehicles, etc.
Background
[0002] US 2013/0166109 A1 discloses predicting a likely remaining duration of a traffic signal in a particular state. The need remains, however, for practical and effective solutions for red light running warning message generation from predictive traffic signal state data and communication of such messages in near real-time to vehicle systems and or operators.
[0003] The Connected Vehicle Reference Implementation Architecture (CVRIA, http://www.iteris.com/cvria html/applications/app57.html), takes the signal phase and timing (SPaT) data and begins broadcasting to vehicles approaching or near the intersection. The red light running warning applications focus on field communications between different entities within the local intersection context. They assume the SPaT will cover the red light message that has already been generated.
[0004] Other prior art, such as US 2005/0156757 A1, only implied that they will focus on the known state or sequence of state to prepare the red light running warning. For example, it implied that the yellow signal will lead to the red signal and thus at yellow light the warning can be already generated for concerned vehicles [Paragraph 0019]. The need remains for effective red light running warning message generation from predictive traffic signal state data and communication of such messages in near real-time to vehicle systems and or operators. Vehicle systems may include autonomous or semi-autonomous control systems.
Summary
[0005] The present invention is defined by the independent claims, taking due account of any element which is equivalent to an element specified in the claims. The dependent claims concern optional elements of some embodiments of the present invention.
Brief Description of the Drawings
[0006]
Figure 1 is a simplified conceptual diagram of a traffic control prediction system.
Figure 2A is a simplified timing diagram illustrating synchronization of a controller emulator process to a field signal controller.
Figure 2B is an augmented version of Figure 2A illustrating a series of staged future predictions.
Figure 3 is a simplified flow diagram illustrating a process for short-term signal status prediction based on a control emulation process.
Figure 4 is a simplified flow diagram of an alternative process for short-term signal status prediction based on using a plurality of control emulation processes.
Figure 5 is a simplified high-level diagram showing information flow in some embodiments and applications of the present disclosure.
Figure 6 is a simplified communications diagram of a traffic control prediction system.
Figure 7 is a simplified flow diagram illustrating a process for traffic signal predictions utilizing a combination of statistical analysis of historical signal call data, combined with emulation process results.
Figure 8 is a simplified flow diagram of an alternative emulation process that utilizes a plurality of emulator instances, all advancing from a common synchronization state.
Figure 9 shows an example of a traffic signal prediction display in a vehicle dashboard.
Figure 10 is a simplified flow diagram illustrating a process for generating a red light warning message based on predictive traffic signal state data.
Figure 11 is a simplified communication diagram illustrating some examples for distributing a red light warning message to one or more vehicles or other users.
Figure 12 is a simplified block diagram of a system that realizes features of the present disclosure.
Figure 13 is simplified block diagram of some examples of vehicle on-board systems that may receive inputs or take actions responsive to receiving a red light warning message.
Detailed Description
[0007] Glossary: Some of the terms used herein may be defined as follows.
- Traffic Signal or simply "Signal". Refers to a set of traffic control devices generally deployed at a single street intersection, highway ramp or other field location. A traffic signal is controlled by an associated Field Signal Controller ("FSC").
- Field Signal Controller ("FSC"). Refers to a controller, generally comprising electronics and/ or software, arranged to control a Traffic Signal. The Field Signal Controller may be located at or near the corresponding Traffic Signal location, such as a street intersection, or at a central traffic management center, or some combination of the two. An FSC may operate according to various rules, algorithms, and inputs, depending on the location and circumstances of the signal it controls. For example, raw inputs may be provided to the FSC by a Detector.
- Field Signal Controller State. Refers to the state of an FSC, for example, the status of one or more internal timers, and the state or status of one more Indicators controlled by the FSC. The FSC has a given state at a specific time.
- Cycle Time. An FSC may change state according to a Cycle Time, although the cycle time may not always be constant. For example, a weekday cycle time may differ from a weekend cycle time for a given FSC.
- Detector. Refers to an electrical, magnetic, optical, video or any other sensor arranged to provide raw input signals to an FSC in response to detection of an entity such as a motor vehicle, transit vehicle, bicycle or pedestrian. The input signal may correspond to the arrival, presence, or departure of the vehicle. A detector also may be activated manually, for example, by a pedestrian or a driver pressing a button. Of course, a detector also may be initiated remotely or wirelessly, similar to a garage or gate opener. In general, Detectors provide raw inputs or stimuli to an FSC.
- Controller Emulator. Is discussed in more detail below, but in general may comprise computer hardware or other electronics, and/or software, wherever located, that is arranged to mimic or emulate the operation of an FSC.
- Indicator. Refers to one or more signal lights or other visible and/or audible indicators arranged to direct or inform a user such as a motor vehicle driver, bicyclist, pedestrian, or transit vehicle operator at or near a given traffic signal location. A common Indicator for motor vehicles is the ubiquitous Green - Yellow - Red arrangement of lights. Typically an Indicator is triggered or otherwise controlled by the FSC associated with the signal location.
- Prediction. Discussed in more detail below; in general, a Controller Emulator may be implemented as part of a system to predict the future behavior of a Field Signal Controller, and more specifically, to predict the specific types and timing of a field signal controller future state change.
- Phase. In a signal timing plan, for example, a Phase is "A controller timing unit associated with the control of one or more movements. The MUTCD defines a phase as the right-of-way, yellow change, and red clearance intervals in a cycle that are assigned to an independent traffic movement." So it refers to one or multiple movements that are allowed to go together under the signal control, for example, a northbound left turn can have its own (protected) phase. Or the northbound left turn can also be coupled with the northbound through (and right turn in that matter) and thus the entire northbound movements become one phase (in this case northbound left turn vehicles may have to find gaps between opposing southbound through traffic to cross the street).
[0008] Some traffic signals operate on a fixed schedule, while some others are "actuated" or may be adaptive to various conditions. Embodiments of the present invention may be used with all types of non-fixed time signals. Connecting vehicles to the traffic signal infrastructure is a new concept that promises to reduce fuel consumption and save time. We described herein various methods and apparatus to accomplish this functionality. The embodiments described below are not intended to limit the broader inventive concept, but merely to illustrate it with some practical implementations. The ongoing improvements in related technologies, such as cloud computing, wireless data communications, vehicle head units, video, etc. will enable further embodiments in the future that may not be apparent today, but nonetheless will be equivalent variations on our disclosure, perhaps leveraging newer technologies to improve speed, lower cost, etc. without departing from our essential inventive concept.
[0009] Some communication infrastructure is necessary to deliver various "signal data" (for example, states, timers or predictions) into a (potentially moving) vehicle in real-time. Preferably, the vehicle (or its operator) not only is informed about the current status of the signal, but also what the signal is going to do in the near-term future. Predictions of traffic control signal status and or changes can be utilized to advantage by a vehicle control system, either autonomously or with driver participation. Predictions of traffic control signal status and or changes can be utilized by a vehicle operator independently of a vehicle control system. One important aspect of the following discussion is to describe how to create traffic signal predictions and deliver them to a vehicle/ driver in a timely and useful manner.
[0010] Predictions of traffic control signal status and or changes may be delivered to a vehicle in various ways, for example, using the wireless telecom network, Wi-Fi, Bluetooth or any other wireless system for data transfer. Any of the above communication means can be used for communication to a vehicle, for example, to a "head unit" or other in-vehicle system, or to a user's portable wireless device, such as a tablet computer, handheld, smart phone or the like. A user's portable device may or may not be communicatively coupled to the vehicle. for example, it is known to couple a mobile phone to a vehicle head unit for various reasons, utilizing wired or wireless connections.
[0011] Predictions of traffic control signal status and or changes may be displayed for a user on a vehicle dashboard, head unit display screen, auxiliary display unit, or the display screen of the user's portable wireless device, such as a tablet computer, handheld, smart phone or the like. As an example, a prediction that a yellow light is going to turn red in two seconds may be provided to a driver and/or to a vehicle that is approaching the subject intersection. One aspect of this disclosure is directed to the use of control emulation to generate this type of short-term prediction.
[0012] Figure 5 is a simplified introductory diagram showing information flow 500 in some embodiments and applications of the present disclosure. Here, a traffic management center 510 may be deployed, for example, in a city, to provide centralized traffic management functions. In some cases, the traffic management center may communicate data or instructions electronically to individual signal controllers. Conversely, the traffic management center may be arranged to receive information from signal controllers around the city. The individual controllers may provide state data, which may include vehicle call data responsive to detector inputs signals. A server 512 may be configured to store and analyze data received at or provided by the TMC. The server 512 may be arranged to receive and store longer term controller data (defined later), such as vehicle call data, and to generate statistical analyses of such data, as further explained below.
[0013] Again referring to Figure 5, the server may provide data as further described below to be used in a signal prediction feature 514. The signal prediction process in turn generates signal prediction data into a database 516. That database 516 may be made accessible to selected customers 520. For example, such customers may include automobile manufacturers, after-market automotive suppliers, etc. The prediction data in the database may then be communicated electronically to motor vehicles or their operators, also referred to as consumers 522.
[0014] Figure 6 shows an alternative system in more detail. One or more detectors, referenced generally at 146, provide raw data or input signals to an FSC 150. Details of these connections are known. The FSC 150 is often coupled to a communication system 152 operated by local traffic management authorities. The authorities may operate a central traffic management center 154, although some FSC's may operate autonomously. In some embodiments, a prediction system as disclosed herein may obtain data from the central management center, as indicated in Figure 5. In other embodiments, the prediction system may obtain data solely from the FSC. The FSC 150 receives raw data from the detectors 146 and processes that raw data to generate vehicle call data or "calls." A call may result from, for example, the detected arrival of a car 50 feet behind an intersection limit line, in a particular lane. However, we will use the terms "vehicle call" or "vehicle call data" herein in a broad, generic sense in that any given call may be responsive to any type of vehicle, pedestrian, bicycle or other input stimulus.
[0015] The vehicle call data is provided to the prediction system 156. It may be communicated via the communication system 152. Preferably, the same vehicle call data generated by the FSC is provided both to the prediction system 156 and to the central management center 154. In some embodiments, the FSC may have a wireless modem 151 installed to communicate call data wirelessly. It may receive detector data wirelessly as well. The prediction system 156, responsive to received vehicle call data and other parameters, generates predictions of FSC state changes, which may include indicator state changes. The predictions may be communicated to a client or customer 160. For example, the client may be an automobile manufacturer, or an aftermarket product or service vendor. The predictions may be conveyed to the client 160 using a push protocol, a pull protocol, regularly scheduled updates or other variations which, in general, should be arranged to be reasonably timely. In a presently preferred embodiment, a push message is executed once per second. In some embodiments, the client 160 may communicate predictions, or information based on the predictions, via a wireless communication system or network 170, to its customers or consumers 180, typically in a motor vehicle. The prediction system 156 in some embodiments may correspond to the prediction system 100 explained in more detail with regard to Figure 1.
[0016] Figure 1 is a simplified conceptual diagram of an example of a traffic control prediction system 100. The system comprises a control emulation component or system 102, which may include control logic 110 and local control parameters 112. The local control parameters match those of the actual FSC of interest. The local control parameters may include, for example, timing parameters, cycle time, etc.
[0017] In this illustration, the prediction system 100 receives current signal status (observed) as input data 120. The current signal status (real time) may be communicated from the FSC using known protocols. The signal status preferably includes state information and current vehicle call data. The prediction system also receives past signal status (collected) as input data 122. Past signal status data may be collected and processed off-line. For example, such data may be accumulated over several days or weeks. This data may be stored in a database for statistical analysis as further described below.
[0018] The prediction system 100 also receives future vehicle call data (Predicted) as input data 140. The future (predicted) detection data 140 is used to advance the control emulator, while applying the local control parameters, to a new state that reflects what the actual controller state is likely to become in the near future. As discussed below, the emulator can be clocked at a rate faster than real-world time, so that it "gets ahead" of the current state of the actual FSC being emulated. The results of the emulation may comprise a future signal status (predicted signal status), indicated as output data 130. The predicted signal status may be communicated to a vehicle or a vehicle operator, or other user, as further described below.
[0019] Figure 2A is a simplified timing diagram illustrating the pertinent timing relationships in greater detail. In the timeline, time is indicated along the bottom axis 200, moving from the past on the left to the future on the right. The actual (real world) current time =t is indicated at vertical line 208. A first bar 202 represents time in the field signal controller, as for example, may be maintained by a local system clock. A second bar 230 represents "time" in the controller emulator (or emulation process).
[0020] One challenge presented is to synchronize a state of the controller emulator to the current state of the actual FSC. The difficulty arises because the FSC continues to run, and change state, continuously. It is not practical, and potentially even dangerous, to stop the FSC in order and capture a current state. In order to synchronize state to this "moving target," a process may proceed as follows. First, actual FSC data is collected during a period 203 that is before the point in time marked "Sync Point" 204. An emulator process is initialized to that "old" FSC status to begin. Then, at the sync point in time 204, at least one emulator process is started, and it runs forward from the sync point, up to the current time t and beyond. The emulator "catches up" to the current real-world time t by clocking it at a faster rate. During this time period 207, the emulator process receives call data provided by the FSC responsive to detector inputs or the like. Consequently, the emulator will clock through the same state changes as the actual FSC during this period, up to the current time (t) at 208. Thus the emulator is now fully synchronized to the FSC, at the actual current time.
[0021] Starting from the current time t, it remains to predict what the FSC will do in the future. The units are not critical, but intervals of one second are convenient in a presently preferred embodiment. In order to drive the emulator to an expected future state, say a time t+1 or t+3 in Figure 2, the emulator receives "future detection data" indicated as 140 in Figure 1. The future detection data may be generated, for example, by a statistical or probability analysis of actual detection data received at the subject FSC in the past. Again, the controller emulator is running in "fast forward" mode.
[0022] To simplify, here we discuss only a single detector for illustration. For example, one detector might be an in-ground induction loop that detects the presence of a car. Or, it might be a pedestrian push-button. The raw input signals from the detector are received by the FSC and converted into vehicle call data as noted. That call data may be collected and stored over a data collection period, say two weeks, and analyzed using known statistical analyses. The goal is to analyze past behavior of the FSC to help predict its likely future behavior. The data collection period may vary depending on circumstances, and may be changed to optimize it for a given application. The analysis may show, for example, that there is a 40% likelihood of a given call after 2 seconds; and a 60% likelihood of receiving that call after 3 seconds; and perhaps a 90% likelihood or receiving that call after 4 seconds. Each emulator may be calibrated as to how best use this data. For example, the 60% likelihood may be deemed sufficient to trigger a predicted call at t+3. In another application, it may wait until t+4 when the likelihood is greater. Assuming the predicted (and simulated) call is input to the emulator at time t+3, it will change state accordingly. Assuming no other inputs for simplicity of illustration, the emulator now reflects a state that the real FSC is likely to reflect in the future, namely at time t+3. Thus a prediction at 210 is completed. The prediction is captured and the emulator instance may be terminated.
[0023] Figure 2B is an augmented version of Figure 2A illustrating a series of staged future predictions. In this embodiment, after completing a prediction, the results are stored in a buffer or queue to be available for communication to the client. Obtaining the live statuses from an FSC takes time, as does running the emulator. In order to deliver predictions with minimal lag attributed to such tasks, multiple predictions can be made in each emulation step. For example, assume a prediction is made that an indicator light will change from red to green 3 seconds into the future, as indicated at mark 210. In the same emulation step, we would find that barring unforeseen changes to the live system, 1 second into the future, the emulator would predict a change to occur in 2s. In 2 seconds into the future, the emulator would predict a change in Is. Delivering all three of these predictions to the buffer or queue will result in multiple predictions with respect to the same time, t, even before we reach that time, t, by the emulator. Thus, if there is lag when obtaining the signal statuses and/or performing the emulation, it can be absorbed by the most recent prediction along one of the future tracks (203(b), 203(c), etc) which pertains to the same base time, t. These results may be more reliable than alternatives, such as automatic time corrections, because the corrections can be derived using the same emulator as the predictions themselves.
[0024] Figure 3 is a simplified flow diagram illustrating one emulation method 300 of the type described above, utilizing a single emulator process. Here, we use the term "process" to refer to a computer software process, thread, or the like. In a preferred embodiment, the following process steps may be executed once per second. At block 302, the method calls for finding signal status at a last sync point in a database. At block 304, a controller emulator is initialized and advanced to that last sync point. And at block 306, the method calls for feeding past call data into the emulation, from the last sync point, until the current time t. As noted with regard to Figure 2, at this time t the emulator is synchronized to the subject FSC, as noted in block 308.
[0025] At block 310, the likely future FSC behavior is predicted by fast forwarding the controller emulator, using predicted (future) detection data. The predicted state change may be saved and/or exported, as noted above. At block 312, we terminate the controller emulator process. In some embodiments, the same emulator process may then be re-initialized and run again, in the same fashion as above. Or a new instance may be spawned. On the next operation, and each subsequent run, the process is re-initialized to a more recent sync point.
[0026] Figure 7 is another simplified flow diagram illustrating a process for traffic signal predictions utilizing a combination of statistical analysis of historical signal call data, combined with emulation process results. On the left side of diagram indicated at 700, block 720, we acquire and store longer term signal call data. "Longer term" here refers to multiple days, typically, or even several weeks. These magnitudes of time, and preferably two weeks, have been found suitable for some applications. Next, block 722, the historical data is analyzed for selected time intervals. The time intervals may be for example, 15 minutes, or an hour or two, or a day, or a number of cycle times. The statistical analyses may also includes variables for time of day, calendar date, time of year, holidays, etc. The process may determine, at block 724, a probability of a specific signal phase being called or extended. In some embodiments, historical analysis may be done offline, or in a process or processor separate from the controller emulator process.
[0027] An emulator process may be initialized and synchronized, block 752. For example, an emulator process may be synchronized to a sync point as discussed. Next, current vehicle call data may be input to the emulator process, block 754. For example, "short-term past" may correspond to the time period 207 in Figure 2A, between a sync point and the current time t. The emulator is run "fast forward" block 756 and during that time it receives and processes both the actual call data 754 and the predicted call data via path 727 from process block 724. The emulator creates 760 a prediction of what state change will occur in a corresponding field signal controller, and when.
[0028] In some embodiments, a method may include repeating the foregoing steps at a rate of once per second, so as to enable updating the predicted signal status once per second. In some embodiments, field detection data may be received as signal phase data for input to the emulator. In some embodiments, the current state of the emulator includes indicator phase displays (e.g., red, yellow, green, walk, flashing don't walk), and active timers (e.g., minimum green, yellow clearance, red clearance, pedestrian walk, pedestrian clearance, etc.)
[0029] The predicted signal status may be forwarded or communicated to a vehicle/ driver who may be approaching the subject traffic signal. In an embodiment, a motor vehicle may be equipped with suitable equipment to receive that prediction data, and convey it to a control system and/ or a passenger or driver of the vehicle. In one embodiment, prediction data may be displayed on the dashboard; in another embodiment it may be displayed on a head unit or navigation unit display screen. The "navigation unit" may be standalone, or implemented as an "app" on a mobile device.
[0030] Figure 9 shows an example of a traffic signal prediction display (930) in a vehicle dashboard. In Figure 9, a vehicle dashboard is indicated generally at 900. Dashboard 900 may include an instrument panel 902, comprising various gauges or instruments 912, and typically a speedometer 920. A steering wheel 910 is shown (in part) for context. A traffic signal prediction display 930 in this example may comprise a time display 932 ("3 SECS") and a signal display 934. For example, the signal display 934 may comprise three light indicators. They may be red, yellow and green, and they may be arranged like the signal lights in a typical intersection traffic control signal.
[0031] It is not critical, however, that the light indicators be arranged in that manner, or that colored lights are used at all. Various visual display arrangements other than this example may be used; and indeed, audible signaling (not shown) may be used as an alternative, or in addition to, a visual display. The essential feature is to convey some traffic signal prediction information to a user. For example, in Figure 9, the time display 932 may indicate a number of seconds remaining until the traffic signal that the vehicle is approaching is expected to change state, say from yellow to red. In some embodiments, the traffic signal prediction display 930 may include a speed indicator 938 ("28 MPH"). This may be used to indicate a speed calculated for the vehicle to reach the next signal while it is in the green state.
[0032] Having knowledge of what an upcoming traffic signal is going to do in the near future can be used to save gas, save time, and reduce driver stress. For example, when the wait at a red light is going to be relatively long, the driver or an on-board control system may turn off the engine to save fuel. And the prediction system will alert the driver in advance of the light changing to green, to enable a timely restart of the engine. Or, a driver or control system may adjust speed to arrive at a green light. Travel time may be saved by routing optimizations that are responsive to anticipated traffic signal delays. Toward that end, the database prediction data may be provided to a mapping application. Stress is reduced as a driver need not continuously stare at a red signal light, waiting for it to change. In fact, if the wait is known to be long, the driver may want to check her email or safely send a message.
Alternative Emulation Embodiments
[0033] Instead of using only one emulation process to do the prediction, in another embodiment we use one separate process for each cycle second. That way, we don't have to go back in time to the sync point to resynchronize the emulator before being able to play forward every time step. Instead, in one embodiment, we start up as many emulation processes as there are cycle seconds at the synch point. We keep them all synchronized every time step, and then use one of them to play forward and predict for every time step as we move through the cycle second (after which we discard the process). This approach significantly reduces the computation and real-time data storage burdens as we no longer have to keep track of vehicle call data in real-time between sync point and current time. Instead, we have many more, but less computing-intense processes, which is preferable for a cloud computing environment.
[0034] Figure 4 is a simplified flow diagram of an alternative process 400 for short-term signal status prediction, utilizing a plurality of control emulation processes. Process steps may be executed periodically, for example, once per second, although this interval is not critical. A first controller emulator (or controller emulator process) 420-1 is synchronized to the field controller, block 410, thereby establishing an initial "Current Time." Similarly, a second controller emulator 420-2 also is synchronized to the field controller, so that the second emulator also is synchronized to the "Current Time." In like manner, additional controller emulator processes may be synchronized to the same Current Time, as indicated by 420-N. After all relevant emulator processes have been initialized and synchronized, all of them commence execution responsive a common clock signal, and thereby remain synchronized.
[0035] Subsequently, at block 432, we "fast forward" all of the controller emulator instances to predict future control signal state changes, using predicted (future) call data. Each emulator instance may be terminated at a selected time "in the future." For example, in Figure 2A, a prediction is concluded at a future time "t+3" indicated at 210. That emulator instance is then terminated, block 440. However, the remaining instances continue to run, as explained with regard to Figure 8.
[0036] Figure 8 provides a simplified flow diagram 800 of a multiple-emulator embodiment. Preferably each emulator may be an instance of suitable code. At block 802 we provision N instances of an emulator process, where N is an integer on the order of approximately 10-40, although this number is not critical. At block 804, all N instances are synchronized to the same field signal controller at a current time. Methods for doing so are described above. Next, at block 806, we clock all N instances in real time, so that all of them remain actually synchronized to the field signal controller. To remain fully synchronized, the instances also receive real-time detector calls; the same inputs as provided to the FSC.
[0037] Next, at block 808, the system selects one of the running emulator instances, and then, block 810, "fast forwards" only the one selected instance, typically by applying a faster clock than the real-time clock. During the fast forward process, predicted future detection data is input to the instance, as discussed above. In one embodiment, the selected instance performs this prediction over a one-second interval.
[0038] At the end of that prediction, block 812, the system saves the selected emulator prediction results. For a first selected emulator, this would provide t+1 second prediction results. Then the selected emulator process (only one) is terminated, block 814. Note that meanwhile the other N-1 instances have continued, under real-time clocking, to remain synchronized to the field signal controller, so they are ready to go "fast forward" from their current state. Decision 816 determines whether all N instances have terminated. If not, the process continues via path 820 back to block 808, and selects a second one of the remaining emulators. The second selected emulator instance, only, is then "fast forwarded" as described above with regard to block 810 and the process continues as before using the second selected emulator instance to perform a second prediction. The second prediction may be for time t+2. This same loop 820 is then repeated again for each of the remaining N-2 instances, so that each instance provides a prediction at a time in the future. So, for example, 50 instances might be provisioned to predict signal changes 50 seconds into the future.
[0039] Decision 816 detects when all N instances have terminated. The process then loops via path 830 back to block 804 whereupon all N instances are synchronized anew to the new current time t. The process continues to repeat as described so as to continually provide predictions of field controller state. It should be noted that emulation is merely one approach to prediction of signal state changes. Other methods, for example, purely statistical methods, can be used for prediction of traffic control signal operations.
RED LIGHT WARNINGS
[0040] In the description above, we disclosed an emulation mechanism to predict traffic signal state changes. As noted, other prediction methods may be used such as statistics-based predictions. In both cases, there is uncertainty in the predictions; what will happen when is not exactly deterministic. In some embodiments, a prediction system may compute two main signal switches for any phase under control, namely red to green, or green to red. Utilizing statistical support, as explained earlier, the emulation mechanism can assign probabilities to different predictions when the prediction is not certain.
[0041] There are many potential uses and advantages to be gained with an accurate prediction or warning ahead of a traffic control signal state change to a red light. One obvious use is to alert a driver of a vehicle that is approaching a signal that it is going to turn red soon. Given an accurate warning, say for example, 10 seconds remain until a change to the red state, the driver can make an informed judgment as to whether to proceed through the intersection or slow to a stop. Autonomous or semi-autonomous vehicles can take the warning message into account in their operational logic to improve safety. Another advantage is savings in fuel (for example, fossil fuels, electrical charge, etc.) by slowing a vehicle ahead of an intersection, given an accurate warning in advance about when it will change to red. Improved fuel efficiency can be gained in human operated as well as automated vehicles.
[0042] The stumbling block with known technologies is the technological problem of achieving an accurate warning in advance of a red light change. Specifically, the technological problem involves two dimensions. First, the problem is that predictions are not entirely accurate. Some predictions are based on statistics, and they are imprecise for that reason. Often, for traffic control signals, even though a prediction was "correct" when made, a new input in the traffic control system can cause it to be wrong. For example, in some left-turn lane phases, a number of cars waiting or in the queue to turn left can cause the controller to extend the usual or default left-turn green state duration. And the duration may be variable, in response to a number of cars in the queue, or other factors, up to a predetermined limit or maximum green time. Upon reaching the limit, the signal will change state, typically to yellow, no matter how many cars are waiting to turn left. The point is that the state change to yellow actually is indeterminate.
[0043] The other problem is time, i.e. delay or latency. Traffic signal state data, in many applications, must travel from the traffic signal controller at a given intersection to a central traffic management center, and thence to another system where predictions are created. Ergo, the state data input to the prediction equipment is delayed, and the exact amount of this latency is variable, so it is hard to correct for it. This combination of latency and sometimes unreliable predictions make it challenging to programmatically generate a timely and reliable warning in advance of a red light change; and "false positives" should be avoided. That is, a red light warning message should not be sent out if it is wrong or may turn out to be wrong.
[0044] Below, we describe additional aspects and features more specific to the red signal phase change. Here, in preferred embodiments, uncertain predictions may be discarded, and only certain predictions that are certain to occur will be relayed, as explained in more detail below. This feature can be utilized to enable an event-based red light warning service that will be initiated only when the system "knows" the relevant signal switch times.
[0045] For example, for an actuated phase that is reaching the last vehicle extension before reaching maximum green, the emulation cannot predict exactly when the phase will change from green to yellow, but once yellow, it can predict exactly when, or how long until, it will turn red. That is, typically the yellow signal phase has a fixed, predetermined duration. That yellow time is one of several fixed-interval control events that may be provided in a traffic control timing plan. This prediction can be used to automatically form a red light warning message before the signal device is predicted to change state to a red signal phase. The warning message can be distributed as further described below, before the red signal change actually occurs.
[0046] It should be noted that computer implementation of this aspect of the invention is critical because time is of the essence. These red-light warning processes cannot be carried out mentally, or with paper and pencil, because the various steps must be completed, and determinations made, with a period on the order of approximately one second. Even a few seconds of delay will substantially degrade the utility of these processes, i.e. the value of the red light warning messages. In a preferred embodiment, new input data (output data from the prediction process) is received once per second. Calculations should be completed before the new updated data arrives. In short, the process should be carried out substantially in real-time, excepting communication latencies.
[0047] Various application services may use or "consume" red light warning messages. The application services, typically implemented in software or firmware, may be on board a vehicle and configured for warning a driver-user of the vehicle. In some embodiments, on board systems may comprise or be coupled to on-board autonomous or semi-autonomous vehicle control systems. Such systems may take the warning message into account in their operations. Some examples of such on-board systems are described below with regard to Figure 13. Some application services may be in fixed locations, in or adjacent to the traffic signal. Application services may broadcast warning messages, using lights, sound, and electronic messaging, or any combination of these or other methods to warn other drivers, cyclists, pedestrians and other users of the subject location.
[0048] Importantly, this feature does not rely on the traffic signal controller (FSC) to tell the signal state, nor does it rely solely on a known state (e.g., currently yellow). Instead, it is a generalized method that is all inclusive of any deterministic event from the traffic controller, and determines all potential red light phase change events ahead of time. This prediction based approach will provide additional safety benefits over current technologies. As just one example, on a slippery road, several seconds of prior warning can make the difference in avoiding a possible collision likely to occur if it was not in place. However, as explained above, predictions do not always turn out to be true. Therefore, additional logic is needed.
[0049] Referring now to Figure 10 as one example, the "PREDICTION output" 1002 may be a software component that comprises, or that receives output data from, a prediction system or service that predicts operations of a given traffic signal. In some cases, the prediction system or service may implement an emulator of the corresponding field traffic signal controller (FTSC), also called a field signal controller (FSC), such as those discussed above. That is, the emulator emulates or mimics, for example by executing suitable stored software in a digital processor, the operation of an FSC. In other cases, a prediction system or service may use statistical methods rather than emulation to predict signal operation.
[0050] The prediction component for a given traffic signal generates predicted traffic signal state data; this data may include, for example, second by second signal status predictions for the next two main switches: red to green, and green to (yellow then to) red. In other words, the prediction component may generate updated data periodically, for example, once per second, although this interval is not critical. It should be no longer than a few seconds. The prediction component may be implemented in a server, for example, in the cloud, or on-board a vehicle, or in a hybrid combination of on-board and remote resources. A hybrid prediction system is described US 2016/0284215 A1, published on 29/09/2016.
[0051] Again referring to Figure 10, at decision 1004, the process determines whether the prediction is certain; that is, is the predicted state change certain to occur. It may not be. For example, a predicted change from green to yellow, based on a default green time period, could be delayed by an extension of the green time, responsive to traffic conditions. Other predictions are more certain. So this step filters out predicted state changes that are not certain. This information may take the form of "derived rules" further discussed with regard to Figure 12. That is, these rules are derived from the signal timing plan of the traffic signal of interest. If the prediction is not certain, the process loops via 1005 to await the next updated prediction.
[0052] Continuing via path 1006, the process next determines whether the (certain) predicted state change will begin a fixed-time traffic control event, decision 1010. In more detail, the predictions from emulator output 1002 may not always be 100% accurate; many modern controllers can change signal timing based on traffic detection inputs (vehicle/bike detection, public transit check-in, and pedestrian push buttons are common examples). The emulation is based on the input of predicted traffic demand; for example, see FIG. 7 and associated text. However, predicting the signal phase calls (based on traffic detection inputs) inherently has errors as traffic demand is highly volatile and varying during any time of the day. Therefore, the emulation output also has uncertainties, and usually the data is assigned a confidence level to indicate the prediction accuracy.
[0053] Fixed-time events can be scheduled or fixed in the sequence of signal control logic. In general, they can be discerned from the traffic signal timing plan. Analysis of the signal timing plan is discussed further with regard to Figure 12. One example is the generally fixed yellow times; although they can vary among different phases even for the same intersection, the yellow time durations are usually fixed for the same phase. The same applies to a so-called "all-red" phase during which signal heads of all phases remain red for short period to allow traffic to clear the intersections.
[0054] There are other signal control events that also have a fixed timer associated, for example, the typical fixed-time control, where the phase sequence and splits (green plus yellow plus all-red times) remain the same. These fixed events may include various signal switch times such as red to green as well. At the next decision step, block 1010, each of these fixed events is considered. Again, these fixed-time events may be extracted from the signal timing plan for the FSC of interest. Note that in a presently preferred embodiment, this selection process 1004-1010-1020 is completed at each prediction for each output; only a subset of the predicted signal state changes will make its way here.
[0055] At decision 1020, another filtering step, the illustrated process compares the current prediction (and current state) to those signal sequences in the timing plan that necessarily lead to a state change to a red light. For example, some events may be fixed and known, but not necessarily lead the switch from yellow to red. The most obvious is the prediction of red to green switch times; while the vehicle controlled by the concerned phase is approaching the intersection while the light is still red. When it reaches the stop line, the light could be green by prediction. Then this is not considered a red light violation (or potential violation) for at least this phase, as the vehicle is not about to enter the intersection (or cross the limit line) while the signal is red. However, this may be a true red light running possible occurrence for phases on conflicting approaches or movements; those will be recorded as the red light running warning event (RLRW). Above, for simplicity, we referred in some cases to green to red as one switch or state change; however, in practice usually controllers for urban intersections have the normal sequence of green-yellow-red. This sequence can vary, however; some countries may have additional intervals. For example, Canada has a flashing green interval and Germany has a combined red and yellow interval. All such variations can be accommodated in view of the present disclosure. Continuing with the illustrated embodiments, after the filtering step 1020, the filtered (fixed) events have been identified for vehicles controlled by at least one phase; some could have impact on vehicles controlled by multiple phases.
[0056] A timestamp is received from a source 1030, for example, a UTC timestamp. The latest timestamp is added to the incoming prediction data when it is received at block 1002. In the event that a warning message is generated, the same timestamp 1026 is added to the warning message 1050. That is, the same timestamp value as that associated to the prediction instance that led to the warning message is added to the warning message. In this way, downstream consumers of the message will know the time of the prediction. By comparing to a current time downstream, an adjustment may be made to correct for latency in delivery of the message. In an embodiment, a system may have an embedded time synchronization module that gets the Universal Coordinated Time (UTC) time. This can be polled from multiple Network Time Protocol (NTP) servers and the best estimate, or it can use a time server itself to get the time reference. Getting the timestamp is a critical component in some embodiments, as the prediction does not depend on field communications such as the dedicated short range communication (DSRC) as described in (http://www.iteris.com/cvria/html/applications/app57.html). In the case of DSRC, when such messages are broadcast, it is broadcast with no timestamps as it is required to have the latency of under 0.1 seconds. Referring to Figure 11, some examples are illustrated for distributing a RLRW message. For example, the message can be packaged as a web service to be polled by in-vehicle computers that have wireless internet access.
[0057] Figure 12 is a simplified block diagram of an example of a system consistent with the present disclosure for generating a red light warning message. A red light warning server (RLWS) 1210 does most of the work. The RLWS 1210 includes an operating system 1222 software that controls a processor (not shown) and may access other hardware and software resources. One such resource may be a communication interface 1206 arranged to enable the RLWS to communicate with other entities, local or remote, using various known methods and protocols. The communication interface 1206 may be configured for communication with a central traffic management center 1202. See 510 in Figure 5. In some cases, the central management center may oversee traffic operations for an entire city or part of a city. The central management system 1202 is coupled to a plurality of individual field signal controllers (FSC) indicated generally at 1204. Each FSC controls a corresponding location such as found at street intersections, freeway ramps, and the like, for directing traffic, which may include without limitation pedestrians, bicycles, cars, buses, mass transit vehicles, etc. Typically, the FSC controls a plurality of individual signal "heads" indicated at 1205. The communication interface 1206 also may be used to access a timestamp source such as a UTC clock site 1208.
[0058] The red light warning server (RLWS) 1210 also includes analysis software 1220 which is executable on the processor, again under control of the OS 1222. Operation of the analysis software 1220 was described above with regard to the flow diagram of Figure 10. Here, the diagram of Figure 12 illustrates connection 1225 of the RLWS 1210 via the communication interface 1206 to the central management center 1202. Using this link 1225, or other means, the RLWS is able to download a traffic signal timing plan for a given traffic signal. That is, the timing plan executed by the FSC 1204 at the corresponding field location. In some embodiments, the RLWS may store the signal timing plan in a datastore 1230. The signal timing plan may be downloaded and analyzed in advance of processing actual (real time) prediction input data. The signal timing plan may include, in some embodiments, signal changes sequences, variable intervals and fixed interval control events. The signal timing plan may be analyzed by the software 1220 to identify or derive certain rules based on the signal timing plan. The resulting derived rules may be stored in a datastore 1240, which may be the same as the datastore 1230 but in a different file or table. The derived rules may be utilized by the RLWS as described earlier to generate a red light warning message responsive to input data. The derived rules may include, for example, what predicted changes are certain, what changes begin a fixed-time interval event, and what predicted changes lead to a sequence that ends with a red light. The input data, such as signal states, state changes, detector calls, etc. may be provided to the RLWS by the Central Traffic Management Center 1202, for example, via link 1225, which in turn acquires them from the FSC as noted above. Finally, a red light warning message generated by the server 1210 may be distributed via the communication interface 1206 or via other downstream distribution means 1250 such as described above with regard to Figure 11.
[0059] Figure 13 is a simplified block diagram illustrating some examples of on-board systems that may be found in a vehicle 1300. Various vehicles may have various subsets of these examples, and some vehicles may have other systems not shown that utilize or "consume" red light warning messages, all considered within the scope of this disclosure. In a vehicle 1300 a wireless communication module 1350 may be deployed, details of which are known. For example, in some embodiments, a wireless telecommunication link may be used. A data channel or service of a telecom link may be used. In other cases, data communications may utilize a voice channel or "in-band" signaling (again over telecom) to receive small amounts of data, such as a red light warning message. Whatever the communications means may be, the message is delivered to a wireless warning message receiver, block 1360, which may be implemented in hardware, software, or a combination of the two. The receiver 1360 in turn may be coupled to various on-board systems or components, generally indicated at 1304. Such on-board systems may be coupled to a local network 1306, for example, a CAN network, Ethernet, etc.
[0060] Some of the on-board systems may include emergency braking 1320; collision avoidance 1314; human interfaces 1316 (for example, dashboard displays, audio announcements, "head unit" or navigation screen, etc.); airbags 1320. Airbag logic may take a red light warning into account, along with other input variables. Finally, other components may include vehicle-to-vehicle ("V2V") communications. For example, warnings may relayed to other vehicles that may be closely following the vehicle 1300. In another example, warning messages may be sent to crossing vehicles - for example, a first vehicle entering an intersection crossing the path of a second vehicle that is subject to an upcoming red light state change.
[0061] One of skill in the art will recognize that the concepts taught herein can be tailored to a particular application in many other ways. In particular, those skilled in the art will recognize that the illustrated examples are but one of many alternative implementations that will become apparent upon reading this disclosure. It will be obvious to those having skill in the art that many changes may be made to the details of the above-described embodiments without departing from the underlying principles of the invention.
a red light warning server system (1210) including an operating system program (1222) and a processor operable under control of the operating system, and further including an analysis program (1220) executable by the processor;
a communications interface (1206) coupled to the server system (1210) and specially configured for communications with a central traffic management center (1202) to download a signal timing plan (1230) for a given traffic signal (1205) to the server system (1210), and to download current signal state data to the server system (1210), wherein the current signal state data includes a current signal state for each phase of said given traffic signal (1205);
the communications interface (1206) further arranged to receive prediction data (760, 1002) of the signal state of said given traffic signal (1205);
the communications interface (1206) further coupled to the server system (1210) to enable transmitting a red light warning message (1050) to a downstream system (1250);
the analysis program (1220) stored in machine-readable memory accessible to the server system (1210) for execution in the processor and configured to analyze the stored signal timing plan (1230) thus forming derived rules per signal (1240) that include (a) identification of predicted state changes that are certain to occur; (b) identification of state changes that begin a fixed-time interval signal control event; and (c) identification of state changes; and
a warning message component also stored in machine-readable memory accessible to the server system (1210) for execution in the processor to process the incoming prediction data (1225) using said derived rules (1240) and the current signal state data to generate the red light warning message (1050) for transmission to the downstream system.
an input to receive a current timestamp (1026, 1030); and
wherein the warning message component is further configured to attach the current timestamp (1026, 1030) to the received prediction data and, in the event that a red light warning message is generated based on the received prediction data, to attach the same timestamp (1026, 1030) to the generated red light warning message before the message is transmitted.
a first datastore operatively coupled to the server system (1210) to store the signal timing plan (1230);
a second datastore operatively coupled to the server system (1210) to store the derived rules.
receiving a set of output data from a traffic signal prediction process, wherein the output data indicates, for each phase of a given traffic signal (1205), a current signal state, and a predicted signal state change to a next signal state;
wherein the output data further includes, for each phase of said given traffic signal (1205), a predicted time interval remaining until said predicted signal state change;
applying a timestamp to the output data received from the prediction process,
accessing a signal timing plan (1230) of said given traffic signal (1205);
using the signal timing plan (1230), selecting from the received output data a predicted state change that is certain to occur;
using the signal timing plan (1230), determining whether the selected predicted state change that is certain to occur is one that will trigger a start of a fixed-time signal control event;
using a determination that the predicted state change will trigger the start of a fixed-time signal control event, and using the signal timing plan (1230), determining whether at a conclusion of the fixed-time signal control event, said given traffic signal (1205) will change state to a red signal state;
using a determination that the fixed-time signal control event will conclude with said given traffic signal (1205) changing state to a red signal state:
generating a red light warning message for said given traffic signal (1205);
applying the timestamp to the red light warning message; and
transmitting the time-stamped red light warning message to a downstream system.
wherein the output data from the prediction process is updated approximately once per second, and the foregoing method is repeated for each update of the output data; and/or
wherein the method includes providing in the red light warning message an estimated time interval remaining until the signal state is expected to change state to the red state.
wherein the fixed-time signal control events comprise a fixed yellow time for a given phase of the traffic signal (1205); or
wherein the fixed-time signal control events include an all-red period during which the signal heads of all phases of the traffic signal (1205) remain red for a predetermined period to allow traffic to clear the intersection.
wherein the fixed-time signal control events include a fixed timer wherein the phase sequence and splits, being green plus yellow plus all-red times, remain the same; or
wherein the fixed-time signal control events include a predetermined signal switch time being an interstage interval.
wherein transmitting the message utilizes a web service to be polled by in-vehicle computers that have wireless internet access; or
wherein the warning message is packaged as a separate add-on to a DSRC broadcast radio in a roadside unit, RSU.
wherein the signal timing plan (1230) is associated with an electronic field signal controller, FSC, system (1204) and includes a yellow to red state change interval;
wherein the set of output data indicates that a present state of a traffic signal (1205) at the field location is a yellow light state;
wherein generating the red light warning message further comprises predicting a time interval until the signal is predicted to change state to the red signal state; and
wherein the warning message is transmitted to said downstream system for distribution by a wireless connection to at least one vehicle located in a vicinity of the traffic signal (1205).
appending an UTC timestamp to the current state data; and
appending the same UTC timestamp to the red light warning message.
providing in the red light warning message an indication of the predicted time interval until the traffic signal (1205) is predicted to change to the red signal phase; and/or
receiving the red light warning message based on the message, displaying the indication of the predicted time interval on a display a vehicle.
ein Rotlichtwarn-Serversystem (1210) mit einem Betriebssystemprogramm (1222) und einem Prozessor, der unter Steuerung des Betriebssystems betreibbar ist, und ferner mit einem durch den Prozessor ausführbaren Analyseprogramm (1220);
eine Kommunikationsschnittstelle (1206), die mit dem Serversystem (1210) gekoppelt ist und besonders zur Kommunikation mit einer zentralen Verkehrsmanagementzentrale (1202) konfiguriert ist, um einen Signalzeitenplan (1230) für einen gegebenen Verkehrssignalgeber (1205) zu dem Serversystem (1210) herunterzuladen, und um aktuelle Signalzustandsdaten zu dem Serversystem (1210) herunterzuladen, wobei die aktuellen Signalzustandsdaten für jede Phase des gegebenen Verkehrssignalgebers (1205) einen aktuellen Signalzustand angeben;
wobei die Kommunikationsschnittstelle (1206) ferner angeordnet ist, um Vorhersagedaten (760, 1002) des Signalzustands des gegebenen Verkehrssignalgebers (1205) zu empfangen;
wobei die Kommunikationsschnittstelle (1206) ferner mit dem Serversystem (1210) gekoppelt ist, um ein Senden einer Rotlicht-Warnmeldung (1050) an ein nachgeschaltetes System (1250) zu ermöglichen;
wobei das Analyseprogramm (1220) in maschinenlesbarem Speicher, auf den das Serversystem (1210) zuzugreifen vermag, zur Ausführung in dem Prozessor gespeichert ist, und es dazu konfiguriert ist, den gespeicherten Signalzeitenplan (1230) zu analysieren, wodurch abgeleitete Regeln pro Signalgeber (1240) gebildet werden, die Folgendes aufweisen: (a) Angaben über vorhergesagte Zustandsänderungen, die sicher auftreten werden; (b) Angaben über Zustandsänderungen, die ein Festzeit-Signalsteuerereignis beginnen; und (c) Angaben über Zustandsänderungen; und
eine Warnmeldungskomponente, die auch in maschinenlesbarem Speicher, auf den das Serversystem (1210) zuzugreifen vermag, zur Ausführung in dem Prozessor gespeichert ist, um die eingehenden Vorhersagedaten (1225) unter Verwendung der abgeleiteten Regeln (1240) und der aktuellen Signalzustandsdaten zu verarbeiten, um die Rotlicht-Warnmeldung (1050) zur Übermittlung an das nachgeschaltete System zu erzeugen.
einen Eingang zum Empfangen eines aktuellen Zeitstempels (1026, 1030); und
wobei die Warnmeldungskomponente ferner konfiguriert ist, die empfangenen Vorhersagedaten mit dem aktuellen Zeitstempel (1026, 1030) zu versehen und für den Fall, dass eine Rotlicht-Warnmeldung beruhend auf den empfangenen Vorhersagedaten erzeugt wird, die erzeugte Rotlicht-Warnmeldung mit dem gleichen Zeitstempel (1026, 1030) zu versehen, bevor die Nachricht übertragen wird.
einen ersten Datenspeicher, der betriebsmäßig mit dem Serversystem (1210) gekoppelt ist, um den Signalzeitenplan (1230) zu speichern;
einen zweiten Datenspeicher, der betriebsmäßig mit dem Serversystem (1210) gekoppelt ist, um die abgeleiteten Regeln zu speichern.
Empfangen eines Satzes von Ausgabedaten von einem Verkehrssignalgeber-Vorhersageprozess, wobei die Ausgabedaten für jede Phase eines gegebenen Verkehrssignalgebers (1205) einen aktuellen Signalzustand und eine vorhergesagte Signalzustandsänderung zu einem nächsten Signalzustand angeben;
wobei die Ausgabedaten ferner für jede Phase des gegebenen Verkehrssignalgebers (1205) ein vorhergesagtes Zeitintervall angeben, das bis zu der vorhergesagten Signalzustandsänderung verbleibt;
Versehen der von dem Vorhersageprozess empfangenen Ausgabedaten mit einem Zeitstempel;
Zugreifen auf einen Signalzeitenplan (1230) des gegebenen Verkehrssignalgebers (1205);
unter Verwendung des Signalzeitenplans (1230) erfolgendes Auswählen einer vorhergesagten Zustandsänderung, die sicher auftreten wird, aus den empfangenen Ausgabedaten;
unter Verwendung des Signalzeitenplans (1230) erfolgendes Bestimmen, ob die ausgewählte vorhergesagte Zustandsänderung, die sicher auftreten wird, eine solche ist, die einen Anfang eines Festzeit-Signalsteuerereignisses auslöst;
unter Verwendung einer Bestimmung, dass die vorhergesagte Zustandsänderung den Anfang eines Festzeit-Signalsteuerereignisses auslösen wird, und unter Verwendung des Signalzeitenplans (1230) erfolgende Bestimmung, ob der Zustand des gegebenen Verkehrssignalgebers (1205) bei Abschluss des Festzeit-Signalsteuerereignisses in einen roten Signalzustand wechseln wird;
unter Verwendung einer Bestimmung, dass der Zustand des gegebenen Verkehrssignalgebers (1205) bei Abschluss des Festzeit-Signalsteuerereignisses in einen roten Signalzustand wechseln wird, erfolgendes:
Erzeugen einer Rotlicht-Warnmeldung für den gegebenen Verkehrssignalgeber (1205);
Versehen der Rotlicht-Warnmeldung mit dem Zeitstempel; und
Übertragen der zeitgestempelten Rotlicht-Warnmeldung an ein nachgeschaltetes System.
wobei die Ausgabedaten des Vorhersageprozesses ungefähr einmal pro Sekunde aktualisiert werden, und wobei das vorstehende Verfahren für jede Aktualisierung der Ausgabedaten wiederholt wird; und/oder
wobei das Verfahren umfasst, dass in der Rotlicht-Warnmeldung ein geschätztes Zeitintervall angegeben wird, das verbleibt, bis eine Änderung des Signalzustands in den roten Zustand erwartet wird.
wobei die Festzeit-Signalsteuerereignisse eine feste gelbe Zeit für eine gegebene Phase des Verkehrssignalgebers (1205) umfassen; oder
wobei die Festzeit-Signalsteuerereignisse eine Rundum-Rot-Zeitdauer umfassen, während der die Signalköpfe aller Phasen des Verkehrssignalgebers (1205) für eine vorbestimmte Zeitdauer rot anzeigen, um zu ermöglichen, dass der Verkehr die Kreuzung freigibt.
wobei die Festzeit-Signalsteuerereignisse einen festen Zeitgeber umfassen, wobei die Phasenfolge und die Teilungen, die Grün- plus Gelb- plus Rundum-Rot-Zeiten sind, gleich bleiben; oder
wobei die Festzeit-Signalsteuerereignisse eine vorbestimmte Signalumschaltzeit, die ein Zwischenintervall ist, umfassen.
wobei beim Senden der Meldung ein Webdienst verwendet wird, der von fahrzeuginternen Computern mit drahtlosem Internetzugang abgefragt werden soll; oder
wobei die Warnmeldung in einer lokalen Kommunikationseinheit RSU (RSU = roadside unit = Straßenrandeinheit) als separater Zusatz an eine DSRC-Rundfunkeinheit (DSRC = dedicated short range communication = zweckbestimmte Nahbereichskommunikation) verpackt wird.
wobei der Signalzeitsteuerplan (1230) einem elektronischen Vor-Ort-Signalsteuersystem, FSC-System (FSC = field signal controller) (1204) zugeordnet ist und ein Gelb-Rot-Zustandsänderungsintervall aufweist;
wobei der Satz von Ausgabedaten angibt, dass ein gegenwärtiger Zustand eines Verkehrssignalgebers (1205) vor Ort ein gelber Lichtzustand ist;
wobei das Erzeugen der Rotlicht-Warnmeldung ferner das Vorhersagen eines Zeitintervalls umfasst, bis eine Änderung des Zustands des Signals in den roten Signalzustand vorhergesagt wird; und
wobei die Warnmeldung zur Verteilung durch eine drahtlose Verbindung zu mindestens einem Fahrzeug, das sich in der Nähe des Verkehrssignalgebers (1205) befindet, an das nachgeschaltete System übertragen wird.
Versehen der aktuellen Zustandsdaten mit einem UTC-Zeitstempel; und
Versehen der Rotlicht-Warnmeldung mit dem gleichen UTC-Zeitstempel.
Bereitstellen einer Angabe des vorhergesagten Zeitintervalls, bis eine Änderung des Verkehrssignalgebers (1205) in die Rot-Signalphase vorhergesagt wird, in der Rotlicht-Warnmeldung; und/oder
Empfangen der Rotlicht-Warnmeldung und auf der Meldung beruhendes Anzeigen der Angabe des vorhergesagten Zeitintervalls auf einer Anzeige eines Fahrzeugs.
un système serveur d'avertissement de feu rouge (1210) incluant un programme formant système d'exploitation (1222) et un processeur pouvant être mis en œuvre sous le contrôle du système d'exploitation, et incluant en outre un programme d'analyse (1220) exécutable par le processeur,
une interface de communication (1206) couplée au système serveur (1210) et configurée en particulier pour des communications avec un centre de gestion centrale de la circulation (1202) afin de télécharger vers le système serveur (1210) un plan de séquencement de signal (1230) destiné à un signal de trafic donné (1205), ainsi que pour télécharger vers le système serveur (1210) des données sur l'état courant du signal, les données sur l'état courant du signal incluant l'état courant du signal pour chaque phase dudit signal de trafic donné (1205),
l'interface de communication (1206) étant en outre agencée pour recevoir des données de prédiction (760, 1002) de l'état dudit signal de trafic donné (1205),
l'interface de communication (1206) étant en outre couplée au système serveur (1210) pour autoriser la transmission d'un signal d'avertissement de feu rouge (1050) à un système aval (1250),
le programme d'analyse (1220) étant stocké dans une mémoire pouvant être lue par une machine accessible au système serveur (1210) en vue d'une exécution dans le processeur et configuré pour analyser le plan de séquencement de signal (1230) stocké, ce qui forme ainsi des règles déduites par signal (1240), lesquelles incluent (a) l'identification des changements d'état prédits certains de se produire, (b) l'identification de changements d'état qui débutent un événement de commande de signal à intervalles de temps fixes, et (c) l'identification de changements d'état, et
un composant de message d'avertissement également stocké dans une mémoire pouvant être lue par une machine accessible au système serveur (1210) en vue d'une exécution dans le processeur pour traiter les données entrantes de prédiction (1225) en utilisant lesdites règles déduites (1240) et les données sur l'état courant du signal afin de générer le message d'avertissement de feu rouge (1050) en vue d'une transmission vers le système aval.
une entrée permettant de recevoir un marqueur horaire courant (1026, 1030), et
dans lequel le composant de message d'avertissement est en outre configuré pour attacher le marqueur horaire courant (1026, 1030) aux données de prédiction reçues et, dans le cas où un message d'avertissement de feu rouge est généré sur la base des données de prédiction reçues, pour attacher le même marqueur horaire (1026, 1030) au message d'avertissement de feu rouge généré avant que le message soit transmis.
une première mémoire de données couplée fonctionnellement au système serveur (1210) pour stocker le plan de séquencement de signal (1230),
une seconde mémoire de données couplée fonctionnellement au système serveur (1210) pour stocker les règles déduites.
la réception d'un jeu de données de sortie provenant d'un procédé de prédiction de signal de trafic, les données de sortie indiquant, pour chaque phase d'un signal de trafic donné (1205), l'état courant du signal et un changement d'état prédit du signal pour l'état suivant du signal,
dans lequel les données de sortie incluent en outre, pour chaque phase dudit signal de trafic donné (1205), un intervalle de temps prédit restant jusqu'au dit changement d'état de signal prédit,
l'application d'un marqueur horaire aux données de sortie reçues en provenance du procédé de prédiction,
l'accession à un plan de séquencement de signal (1230) dudit signal de trafic donné (1205),
en utilisant le plan de séquencement de signal (1230), la sélection d'un changement certain de se produire à partir des données de sortie reçues,
en utilisant le plan de séquencement de signal (1230) la détermination de ce que le changement d'état prédit sélectionné qui est certain de se produire est un changement qui déclenchera le démarrage d'un événement de commande de signal à durée fixe,
en utilisant la détermination de ce que le changement d'état prédit déclenchera le démarrage d'un événement de commande de signal à durée fixe, et en utilisant le plan de séquencement de signal (1230), la détermination de ce que ledit signal de trafic donné (1205) changera d'état pour prendre l'état de signal de feu rouge à la conclusion de l'événement de commande de signal à durée fixe,
en utilisant la détermination de ce que l'événement de commande de signal à durée fixe se conclura avec la modification de l'état du signal de trafic donné (1205) pour prendre l'état de signal de feu rouge :
la génération d'un message d'avertissement de feu rouge pour ledit signal de trafic donné (1205),
l'application du marqueur horaire au message d'avertissement, et
la transmission à un système aval du message d'avertissement de feu rouge marqué temporellement.
dans lequel les données de sortie provenant du procédé de prédiction sont mises à jour approximativement une fois par seconde, et le procédé précédent est répété pour chaque mise à jour des données de sortie, et/ou
dans lequel le procédé inclut la fourniture d'un intervalle de temps estimé restant dans le message d'avertissement de feu rouge jusqu'à ce que l'état du signal soit prévu changer d'état pour prendre l'état de feu rouge.
dans lequel les événements de commande signal à durée fixe comprennent une durée de feu orange fixe pour une phase donnée du signal de trafic (1205), ou
dans lequel les événements de commande de signal à durée fixe incluent une période tout feu rouge pendant laquelle les têtes de feu de toutes les phases du signal de trafic (1205) restent rouges pendant un intervalle de temps prédéterminé pour permettre au trafic de libérer l'intersection.
dans lequel les événements de commande de signal à durée fixe incluent une horloge fixe dans laquelle les séquences de phase et les fractionnements, qui représentent la durée en feu vert plus la durée en feu orange plus la durée tout en rouge, restent identiques, ou
dans lequel les événements de commande de signal à durée fixe incluent un temps de basculement de signal prédéterminé qui représente un intervalle entre états.
dans lequel la transmission du message utilise un service Web faisant l'objet d'une interrogation par des ordinateurs à bord des véhicules qui possèdent un accès Internet sans fil, ou
dans lequel le message d'avertissement est conditionné sous forme d'un additif séparé à une station de radiodiffusion pour communications spécialisées à courte portée (DSRC) située dans une unité de bord de route (RSU).
dans lequel le plan de séquencement de signal (1230) est associé à un système de contrôleur de signal électronique de terrain, FSC, (1204) et il inclut un intervalle de changement d'état de jaune à rouge,
dans lequel le jeu de données de sortie indique que l'état courant d'un signal de trafic (1205) à l'emplacement sur le terrain est un état de feu orange,
dans lequel la génération du message d'avertissement de feu rouge comprend en outre la prédiction d'un intervalle de temps jusqu'à ce que le signal soit prévu changer d'état pour prendre l'état de signal de feu rouge, et
dans lequel le message d'avertissement est transmis au dit système aval en vue d'une répartition grâce à une connexion sans fil à au moins un véhicule situé au voisinage du signal de trafic (1205).
l'adjonction d'un marqueur horaire de temps universel UTC aux données sur l'état courant, et
l'adjonction du même marqueur horaire de temps universel UTC au message d'avertissement de feu rouge.
la délivrance, dans le message d'avertissement de feu rouge, d'une indication concernant l'intervalle de temps prédit jusqu'à ce que le signal de trafic (1205) soit prévu changer pour passer à la phase de signal de feu rouge, et/ou
la réception du message d'avertissement de feu rouge sur la base du message, en affichant l'indication de l'intervalle de temps prédit sur un afficheur de véhicule.
REFERENCES CITED IN THE DESCRIPTION
This list of references cited by the applicant is for the reader's convenience only. It does not form part of the European patent document. Even though great care has been taken in compiling the references, errors or omissions cannot be excluded and the EPO disclaims all liability in this regard.
Patent documents cited in the description