From SignalGroups to Lanes to ConnectsTo

A common question is:

How does a Signal Phase or Movement get associated with a Lane, or a set of Lanes?

In this Article we walk over this process.

It uses the SignalGroupID found in the ConnectsTo  for this.  For the moment think of the SignalGroupID as being similar to the 8 phases found in many signal controllers, although J2735 allows up to 254 of them.

The SignalGroupID appears in both the SPaT and the signalized Lanes of the the MAP.

But this is not immediately evident when looking at the Generic Lane, as the ConnectsToList in each Generic Lane structure handles this.  This is the key part of the Generic lane structure:

connectsTo  ConnectsToList OPTIONAL,
-- a list of other lanes and their signal group IDs each connecting lane and its signal group ID

This entry is required to be present for any lane type that is signalized. It is not required for lanes that are not signalized, as well as some lane types (such as sidewalks, medians, striping) where it make no sense.  The information present may not in fact show connection lane data (perhaps because such lane were not modeled in the same map, or because they do not exist), and it may not in fact show a SignalGroupID (perhaps because the connection lane does not involve any signalization).  Other data elements (not shown) can be used to relate traffic flow details about the other lane.

And the LaneID of this connecting lane may refer to a lane found (described) in another nearby intersection, in which case the IntersectionReferenceID of that intersection is also present.

Note that each connected lane has its own entry with both required and optional details.

ConnectsToList ::= SEQUENCE (SIZE(1..16)) OF Connection

Here are is the key parts of the Connection entry for this discussion:

Connection ::= SEQUENCE {
   -- The subject lane connecting to this lane is:
   connectingLane     ConnectingLane,  <--- Note that this is required to be present, see note below.
                     -- The index of the connecting lane and also the maneuver from the current lane to it
   remoteIntersection IntersectionReferenceID OPTIONAL,
                     -- This entry is only used when the indicated connecting lane belongs
                     -- to another intersection layout. This provides a means to create meshes of lanes
   -- SPAT mapping details at the stop line are:
   signalGroup       SignalGroupID OPTIONAL,  
                     -- The matching signal group send by the SPAT message for this lane/maneuver.
                     -- Shall be present unless the connectingLane has no signal group (is un-signalized)

-- Rest removed, see J2735 for details. 

NOTE for above ASN.  This entry should have been made optional. In some signalized lanes (such as crosswalks) it has little value and it would have been better not to require it to be present in the ASN.  It was an oversight that made it into the published standard that would now cause backward compatibility issues to fix at this point.  Thankfully the trick of LaneID=0 (see the ASN comment in the LaneID definition found in the J2735 standard) can be used to overcome this defect.  If the DSRC TC allows, a remark added to the end of the entry to this affect will be added in the next revision.

NOTE to debate with others.  We might also solve the “reverse lane connection” issue by using a known value in the IntersectionReferenceID to indicate this for lanes in the SAME intersection.  Further note, this “connect to the reversed end” is in fact the PRESUMED meaning for lanes in other intersections.  It is a pity but this trick would cost us 16 bits for a simple flag to preserve compatibility.

Note to self – add a line like “when to use a LaneID of zero”
somewhere in the KB text and use this, and ped crossings as typical examples


The Connecting Lane entry

The Connecting Lane entry (shown below) provides the LaneID and the single type of maneuver required to connect to that lane from THIS one.  By design, and after long debate, all the supported maneuvers are considered single actions.  Unlike some driver navigation software, there is no concept of a compound maneuver in this body of work.

ConnectingLane ::= SEQUENCE {
   lane     LaneID,  -- Index of the connecting lane  
   maneuver AllowedManeuvers OPTIONAL
                     -- The Maneuver between the enclosing lane and this lane
                     -- at the stop line to connect them

Recall that many connections in a list are allowed and that each Connection allows THIS lane to connect to one other LaneID and one SignalGroupID (where the timing values are found in the SPaT entry that matches it).

Worked Examples

Motor Vehicle Type Lane

As an example, consider a motor vehicle type lane that allows both a protected left turn movement (a “left arrow”) and a admissive straight ahead movement.  This lane would have two entries.  One Connection entry for the left turn maneuver and another for the straight ahead maneuver. Each would have their own signalGroupId value.  [The some of these maneuvers (it is a bit field)  would also be (optionally) found in the GenericLane, but allowed non signalized maneuvers can also be present there (so it is not as duplicative as it might first appear).]

Add image using reference map details here

If vehicle in this lane was also allowed to use the admissive phase to make left turns (a “green ball”), then there would be another Connection entry for that as well. It would have the same signalGroupId used for the admissive movement, as well as the left turn as the allowed maneuver. In the absence of such an entry, the receiving devices can determine that the left turn would only be allowed during the protected movement. [Note that the LaneId used here would be the same value in each case]

Add image with this change, using reference map details here

Pedestrian Crosswalk Type Lane

As a further example, consider a simple pedestrian crosswalk type lane. Most pedestrian crosswalk geometry cases often do not connect to other crosswalks or have safe islands where the signal timing can vary. In fact many are simple 2-node point lanes with constant lane width. Such simple crosswalks also no not involve issues of allowed maneuvers, either for the lane itself or for individual signalized cases.

Add image using reference map details here

In this case, the contents of the ConnectsToList is a single Connection entry. The entry contains the SignalGroupId assigned for the correct pedestrian crossing phase. The LaneID is set to zero, indicating no further connection details. And the optional AllowedManeuvers entry is not present. Recall also the normative remarks in J2735 about when this type of lane can be occupied as well.

The AllowedManeuvers value of yieldAllwaysRequired
is not to be used with un-signalized pedestrian crossings.

To Recap

How does a signal Phase or Movement get associated with a lane, or a set of lanes?

By matching the SignalGroupId(s) sent in the SPaT message to the SignalGroupId(s) found within the ConnectsTo list with each Lane Type in the Intersection Map.


Still TODO

If we restate this from the OBU develops point of  view it might read
How how do I use my location and the SignalGroupId to tell when I have perission to cross the stop line…

That needs to be another article..


Was this article helpful?

Related Articles

Leave A Comment?

You must be logged in to post a comment.