 |
 |
 |
 |
|
 |
 |
SAE J2735-Draft-Rev29 [issued: 12-11-08]
-
278 -
This is an SAE Motor Vehicle Council draft document of the DSRC committee, subject to change.
1.
Vehicle “A”, a PSOBU equipped vehicle is operating in a non-emergency condition. It is acting
similarly to any OBU equipped vehicle and it sends typical vehicle Basic Safety Messages (BSM). It
also receives MAP and SPAT messages about the local signalized intersections, from which it can
extract the preemption or priority zones data when needed. The MAP and PSAT message are being
sent out by the RSU for the target intersection on a periodic basis.
2.
Vehicle "A" determines that activation of an Signal Request message is needed. This could occur
through various determinants, but is likely to be combined with the next use case at the same time.
3.
This activates a PSOBU broadcast of Signal Request message (SRM), which contains the preemption
or priory requested as well as the optional “BSM blob” with current location information, speed, and
direction of travel in it. See GG note about need for destination here, unresolved issue. Current codes
support “at destination” but not where it is.
4.
The intersection RSU, receives the of Signal Request message (SRM) and hands it to the ASC for
further processing. The ASC looks that the data, its own current state, and any required validity
credentials and makes a determination regarding how to respond to the request.
5.
The ASC sends to the RSU (for broadcast) the Signal Status message (SSM) which contains a
summary of the new state of the control with respect to preemptions and priority requests. The
updated SPAT message (which may now reflect a transition to a preemption or priority condition) is
also sent from the ASC to the RSU. The RSU broadcasts these in the normal way.
6.
Vehicle "A" receiving the SSM and can determine if and when the request will become the current
state of the signal. It also will be receiving the SPAT message where this can be further confirmed.
7.
This process repeats (steps 4 to 7) until the vehicle has past the intersection and the intersection is then
released to either resume normal operations or to process the next ranking preemption or priority
request that it has received. A timeout event will occur in the ASC if the requesting SRM is missing
for more than 3 seconds.
8.
Vehicle "A" determines that it has past the intersection, and sends a new Signal Request message
(SRM) with the cancel bit set in the signal request type field for a period of time.
9.
The intersection RSU, receives the of Signal Request message (SRM) with the cancel bit set and hands
it to the ASC for further processing. The ASC looks that the data, its own current state, and any
required validity credentials and makes a determination regarding how to respond to the request. It
may allow another pending request to become the active one (in which case we again cycle over steps
4 to 7) or it may resume normal operations (returning to step one).
10.
Vehicle "A" may note that the received SSM has removed its request from those active and pending,
and therefore ceases sending the Signal Request message (SRM) with the cancel bit set, or after a
duration of 3 seconds may simply cease sending.
Flow of events, Typical EVA use
1.
Vehicle “A”, a PSOBU equipped vehicle is operating in a non-emergency condition. It is acting
similarly to any OBU equipped vehicle and it sends typical vehicle Basic Safety Message (BSM).
2.
Vehicle "A" determines that activation of an Emergency Vehicle Approaching Warning is needed.
This could occur through various determinants such as activation of its siren and emergency lights, or
other inputs to be determined by application developers.