Navigation bar
  Print document Start Previous page
 304 of 321 
Next page End  

SAE J2735-Draft-Rev28 [issued: 11-10-08] 
-
304 -
This is an SAE Motor Vehicle Council draft document of the DSRC committee, subject to change.
Annex H   Map and SPAT Message Use and Operation
1.
Introduction
Words about this application (SPAT and MAP use) to go here.    This draft came from Rev 26, now slightly
out of date by rev 28 changes to “tighten” the message a bit and move the preempt-priority data sets to its
own message.  As a group this section should discuss the MAP, the SPAT and the SRM and SSM. 
Words about the shared vision for such a need and its various applications (as mentioned by VII etc). 
1.1
Intended Audience
This document is written primarily for application and system programmers who write compliant software;
system architects who drive the DSRC message creation, distribution and consumption processes; and
content designers and managers such as city managers and their staff.
1.2
Philosophy of SPAT and MAPs
Words about the shared use of the two messages to reflect the roadway geometry and the current state the
signal system for various user applications to go here.   Please don’t bother with details of encoding and the
benefits therefore, this is already a known factor in the standard. 
Words relating that these message are sourced out by the local RSU at an intersection, and that MAP
message may be packed up and sent in other ways etc...   [Extra credit:  add words on how a non-signalized
intersections (basic 4-ways stops) are modeled with the same message with the MAP and also sent out
(typical in clumps for limited areas). ]
2.
The overall framework of the SPAT
The Signal Phase and Timing message (SPAT) uses a simple framework to provide a basic summary of the
signal state at any given time.  The many optional elements defined in this message allow for both simple
and complex signalized intersection to be modeled without additional overhead in the message unless that
overhead is needed (say to relate pedestrian lanes states or other events that may not be present in every
intersection).  Consult the standard for specific details, but here is a general overview of the structures
defined in the SPAT message
The overall use of the SPAT message is to reflect the current state of all lanes in all approaches in single
intersection.  Any preemption or priority then follows in a structure for the whole intersection.  [And Yes,
intersections can be nested as well]  Lanes that are at the same state (with the same end time) are combined. 
Thus the simplest SPAT message consists on two such states, one for the then active lanes/approach, and
another for all the other lanes that at that time share the state being stopped (a red state).   The stopped (red)
lanes are optionally not sent at others time (the presumption being that any lane not enumerated in the
SPAT is in fact set red).  
Here is an message fragment for that:   
SPAT Message
Msg id =  0x0c  
(indicates a SPAT message)
SPAT id = TBD
(indicates a unique value for this intersection)
States
State #1
Lane Set
(list of lanes this applies to)
1, 2
Movement State(signal state or pedestrian state)
SignalState  = Green light