HTML of the Course Transcript
(Note: This document has been converted from the transcript to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included.)
Ken Leonard: ITS Standards can make your life easier. Your procurements will go more smoothly and you’ll encourage competition, but only if you know how to write them into your specifications and test them. This module is one in a series that covers practical applications for acquiring and testing standards-based ITS systems. I am Ken Leonard, the director of the U.S. Department of Transportation’s Intelligent Transportation System’s Joint Program Office.
Welcome to our ITS standards training program. We’re pleased to be working with our partner, the Institute of Transportation Engineers, to deliver this approach to training that combines web-based modules with instructor interaction to bring the latest in ITS learning to busy professionals like yourself. This combined approach allows interested professionals to schedule training at your convenience without the need to travel.
After you complete this training, we hope you’ll tell your colleagues and customers about the latest ITS standards and encourage them to take advantage of these training modules as well as archived webinars.
ITS Standards training is one of the first offerings of our updated Professional Capacity Training Program. Through the PCB program we prepare professionals to adopt proven and emerging ITS technologies that will make surface transportation safer, smarter, and greener, which improves livability for us all. You can find information on additional modules and training programs on our website, ITS PCB Home. Please help us make even more improvements to our training modules through the evaluation process. We look forward to hearing your comments. Thank you again for participating and we hope you find this module helpful.
Patrick Chan: Good day. This is Module CV-273, Introduction to SPaT/MAP Messages. My name is Patrick Chan. I’ve been involved in developing ITS standards since the year 2000, particularly with several NTCIP device standards in the Traffic Management Dictionary, which is a center-to-center standard. I’m a member of numerous ITS standards committees, including NTCIP Joint Committee and the SAE Technical Committee that was responsible for developing and currently maintaining SAE J2735. I’ve got over 29 years of ITS experience, including four years as an IT project manager with a public agency. So, for this particular module, we have four different learning objectives.
So, with this module, we’ll describe the scope of the SAE J2735 standard. We’ll describe what the SPaT message is; we’ll talk about what the MAP data message is; and then finally, we’ll talk about some of the implementation considerations when trying to implement SPaT and MAP messages. We’ll first start off by describing the scope of the SAE J2735 standard. We’ll start by first describing what is the connected vehicle environment, in particular a V2I, or vehicle-to-infrastructure, environment. We’ll talk about what the needs are for SPaT data and MAP information, and finally, we’ll talk about what is the scope and the purpose of the SAE J2735 standard.
Let’s start off with reviewing the major transportation challenges that transportation agencies face today. First is safety. In 2017, over 37 thousand motor vehicle deaths were recorded as part of over 6.4 million crashes on the U.S. roadways. It is also estimated that 8.8 billion hours was wasted in 2017 on the nation’s highways waiting in congestion, which has an estimated economic productively cost of 166 billion dollars. The same congestion has an impact on the environment resulting in approximately 3.3 billion gallons of wasted fuel. USDOT believes that the deployment of a connected vehicle environment can help transportation agencies address these challenges. For example, USDOT believes that the deployment of a CV can have eliminated 80 percent of the crashes that occurred in 2017.
But what exactly is the CV environment? In broad terms, a connected vehicle environment consists of vehicles, individuals such as pedestrians or bicyclists equipped with smart devices, and infrastructure that can wirelessly communicate amongst each other to provide valuable information and services that may address the transportation challenges presented in the previous slide. These services enabled by software applications can help to reduce crashes, improve mobility, and improve the environment.
This connectivity is provided through a range of wireless technologies, but primarily in two categories: One, short-range communications, which provide an open network over hundreds of meters so vehicles approaching each other can communicate and inform each other of their presence and movement. That’s known as V2V, or vehicle-to-vehicle communications. These vehicles may also exchange information with the infrastructure or the roadway infrastructure, that’s V2I, or vehicle-to-infrastructure, and individual travelers through smart devices. That’s known as V2P, or vehicle-to-pedestrians. Second, remote communicate which allow these connected vehicles and travelers to access centralized services such as fleet management capabilities, regional traffic management, and personalize trip information, etcetera. Collectively, all this wireless connectivity is referred to as vehicle-to-everything, or V2X.
So, what data might be exchanged in such a connected vehicle environment? What data can be exchanged amongst the different components so that we can address the transportation challenges previously mentioned? For connected vehicles, vehicles can share their current position and sensor data with other vehicles, travelers, and infrastructure, while simultaneously we see data from the infrastructure that can reduce the likelihood of incidents and improve mobility, such as reducing travel delay.
For connected individuals, using their smartphones or smart devices, they can share their current position with other vehicles and also with the infrastructure, and in return they can return information about their current surrounding—for example, where are the crosswalks, and is there a walk signal available right now so that they can cross the street safely. For connected infrastructure, it can provide geographic and traffic information about the intersection and the roadway, including signal time and data, to the travelers.
In return, the infrastructure can receive information about the vehicles and travelers so that they can better manage the traffic/travel on the roadway, such as, “Hey, is there a vehicle approaching the signalized intersection, or is there a pedestrian in the crosswalk?” So, how is this data useful in addressing safety and mobility and environmental challenges that were first presented?
The answer is by developing applications or software that can use the data that has been exchanged to, A, warn travelers about avoiding a right-of-way and signalized intersections; maybe warn travelers about other vehicles so that they avoid crashes with each other; and to provide advisories to travelers to improve flow through the signalized intersection. So, this module focuses on two types of data that are provided by the connected infrastructure to connected vehicles and individuals.
The first is signalized phase and timing data, or SPaT, which originates from the traffic signal controller. The second messages or pieces of information is the roadway geometry or MAP data, which generally originates from a traffic management center. Both these pieces of data are broadcasted by a device known as the roadside unit to travelers to support applications for signalized intersections. There are other modules in this professional capacity building series that present other types of data that may be exchanged in a connected vehicle environment to support other types of applications, such as vehicle-to-vehicle applications.
But focusing on the signal phase and timing data, or SPaT, the SPaT data can be used by applications in pedestrian devices such as a smartphone to provide warnings to pedestrians. “Hey, I’m at a signalized intersection. Do I currently have the walk signal, or is it flashing Don’t Walk, or do I have a Don’t Walk signal right now?” It can also be used to provide warnings to drivers such as, “Hey, you’re driving, and there’s a red light, so there might be a right light violation,” or “There’s a pedestrian in the crosswalk, so please be careful turning,” or what vehicle movements are currently allowed. Am I allowed to make a left turn, or does the signal indicate that I’m not allowed to make that left turn right now? We can also provide driver advisory, for example, suggested travel speeds.
“Hey, this is the best speed to cross through the intersection, because, for mobility purposes or for environmental purposes, this is the most efficient speed to go through the intersection.” The other piece of information is the MAP data, or roadway geometry data. It can be provided by the infrastructure and used by applications to determine the lane or pedestrian path locations and any restrictions that might be currently in effect. They’re used by applications to provide warnings or advisories to travelers—“No left turns allowed at the intersection,” for example, or “The lane curve is too sharp, so slow down,” or “The sidewalk is closed.”
MAP messages also are required to properly interpret the SPaT data. While SPaT data includes what movement is currently allowed, the MAP data provides the context: “Where are the lanes? Where am I? If I wanted to make a left turn from the lane I’m currently in, which lane do I turn into?” Examples of applications that can use SPaT and MAP data are: a common is the red light violation warning. It provides warnings to travelers about impending red light violations. If you’re traveling at a speed, the light is red or is about to turn red, “Please slow down.”
So, that’s an example of a safety application for vehicle. For pedestrians, they can give warnings to transit operators. A big concern is on transit buses that are trying to make a right turn, and that way they can be warned, “Oh, there’s a pedestrian in my path while I’m trying to make that right turn.” So, both these are examples of safety applications that use the MAP and SPaT. For mobility, an example application is the Mobile Accessible Pedestrian signal system. This is particularly for visually impaired pedestrians that can automatically make a call to a traffic signal. “Hey, I’m a visually impaired pedestrian that wants to cross the intersection,” so it’ll automatically make a call as the pedestrian approaches the intersection, as well as audio cues to the pedestrian that says, “Hey, I know you want to cross the crosswalk right now and you have the Walk signal. So, go ahead, you may safety cross.”
An example of an environmental application is an eco-approach and departure at signalized intersections. This is an in-vehicle application that receives the current state and then time remaining for a signal indication when it’s red, yellow or green at a signalized intersection so we can support speed trajectories, eco-friendly speed trajectories as vehicles approach and depart from a signalized intersection, meaning, “You’ve got time. The recommended speed is 25 miles per hour because that’s the most efficient speed for your vehicle, and you’ll still be able to clear the intersection.”
So, it is through these applications that we can address the transportation challenges that we presented at the beginning of this module. So, what SAE J2735? So, the module at this point has described the data to be exchanged to support signalized intersection applications, but it hasn’t talked about how that data is defined. So, there is a standard called SAE J2735, Dedicated Short-Range Communications Message Set Dictionary, that’s been developed and defines a set of messages and data elements for the connected vehicle environment. It also defines a message framework for new messages and new user needs are defined. So, one of the messages defined in SAE J2735 is the SPaT message. The SPaT message was developed to provide dynamic, or time-dependent, signal timing information at signalized intersection.
It can provide information such as: What is the general controller status? Is it operating normally, or is it in a preempt mode? It also indicates what movements by lane are currently allowed and when that movement state is likely to end. So, for example, “Hey, if I want to go through going in the northbound direction, I’ve currently got the green and we expect it to remain green for at least five additional seconds.” Or, if I’m waiting for a red left, it’d be maybe about 80 seconds at least before I get the left turn green. The SPaT message is also tied to the MAP data message.
As we discussed earlier, the MAP data message provides the context for the SPaT information. The MAP data message, on the other hand, provides static roadway geometric information. By static, we mean that it’s not expected to change very frequently. There is content in a MAP data message that link it to the SPaT information to provide complete information for the signalized intersection applications. An example of static data might include the lane widths, where are the lanes, what type of lane is it, how wide is it, where’s the path, where’s the center line. It also provides lane attributes such as what are allowable movements, what movements are currently allowed for that lane. Am I allowed to make a left turn only? May I make a U-turn?
Is there a right turn on red? And, as we mentioned, it indicates what part of the SPaT message applies to the traveler’s intended movement. There are also other messages that are defined in SAE J2735 that may be of interest to signalized intersection applications but they’re not addressed in this module, but we’ll present it and give a quick overview of what those messages are. One of them is the signal request and signal status messages, which are used to request signal priority and signal preempt for a signalized intersection and also to check the status of those requests respectively.
The signal request message allows a traveler to request signal preemption or priority based on the lane that it expects to enter the intersection and its desired egress lane—is it a through movement, or is it a left-turn movement?—and the estimated time of arrival at the intersection. Note that the system must be configured to work reliability with security protections, so priority and preemption is provided only for authorized vehicles.
So, there’s a separate professional capacity building module on transit signal priority in a connected vehicle environment that is currently being developed. Other messages that are defined in SAE J2735 that might be of interest include the basic safety message, which I’m sure many of you have heard about. It’s broadcasted by vehicles about their current movement, their speed, where they are, are they accelerating or not, and information that can be provided by the vehicle, collected by the vehicle, and that can be shared with other vehicles.
Another message is the traveler information message, which provides general traveler information broadcasted from the infrastructure to travelers. And finally, there’s also an NMEA, which is the acronym for National Marine Electronics Association, and RTCM, Radio Technical Commission for Maritime Services. These provide corrections information in standardized format so vehicles can accurately calculate its GNSS or location to increase the absolute and relative location accuracy. So, an example of GNSS is GPS, as it’s known in North America. By itself, without these corrections, the accuracy of the GPS can be up to maybe about 10 feet for a smartphone and perhaps one feet in a vehicle. So, these corrections messages are broadcasted so that we can improve the accuracy of the GPS on a vehicle or a smartphone.
So, we reached our first activity. The purpose of these activities are just to review what we’ve learned for each of the different learning objectives. So, the question for the first activity is: Which of the following user needs for a signalized intersection is not addressed with the SPaT data or signal phase and timing data? Your answer choices are, A, receive currently allowed vehicle movements; B, receive lane location descriptions; C, receive suggested vehicle speeds; and D, receive estimated times when signal indications will change. So, which of the following user needs for a signalized intersection is not addressed with the SPaT data?
So, the correct answer is B, receive lane location descriptions. Lane location descriptions are actually provided by the MAP message data and not by the SPaT data message. The SPaT data message does provide currently allowed vehicle movements at an intersection. It does provide suggested vehicle speeds, and it does provide estimated times when the signal indications are expected to change at the signalized intersection.
The next learning objective is to describe the SPaT message. We’ll start by describing what is the structure of the SPaT message, what are the mandatory elements of the SPaT message, and what are optional elements of a SPaT message.
So, previously we described why SPaT data is needed, and it’s really to support in-vehicle and individual applications so that they have information about the signalized intersection so we can address safety concerns, mobility concerns and environmental concerns. The next several slides in this learning objective will describe what data is provided in the SPaT message in SAE J2735. The purpose of this slide is so participants can understand what must be provided and what can be provided and why in the SPaT message.
But before we start that, talking about SPaT message, we need to introduce the structure of the messages in the SAE J2735. The standard contains definitions of data elements, data frames, and messages. This slide is a graphical depiction of the relationship between a message, data frames, and data elements. A message on top is a sequence of data frames and data elements providing information for a predefined application that collectively support a function. An analogy to the English language is that a message is analogous to a sentence. Data frames, below that, are sequences or related data elements that provide information on a very specific topic. An example is location. Individually, location consists of longitude, latitude, and elevation, for example. Individually it may be interesting but it doesn’t really provide a complete picture. That’s why we have a data frame talking about position because together latitude, longitude and elevation do mean something.
Another example is date and time. By itself, hours, minutes and seconds are interesting, but together these three data elements, again, meet as something meaningful. So, that’s an example of a data frame, which data elements are the individual words, and they’re the smallest entity of data, but it’s these words that creates the phrases or the sentence.
So, this is the structure of a message in SAE J2735. With the SPaT message, it’s just one example. So, this is a graphical depiction of a SPaT message and introduces the data concepts that make up the SPaT message. Each data concept consists of a type, a type of data element or a type of data frame, and a name or instance name. So, each box contains the instance name of the data concept. Boxes that are in green are mandatory, which means that they must be provided as part of a SPaT message, in this case, in this example, while the concepts in the yellow are optional, meaning that it can be provided if it makes sense in the SPaT message.
So, starting with the first one is the “messageId.” All messages in SAE J2735 has a message ID. In this case, the SPaT message is—the ID is number 19, which is the SPaT message in the 2016 version of the SAE J2735, which is the most recent version. The next concept is the “timestamp,” which is optional, but indicates the number of elapsed minutes in the year. This timestamp indicates when the SPaT message was created and then broadcast.
Optionally, we can also include the “name,” which is just a text description for the SPaT message, but it’s intended really for the testing environment, it’s not really intended to be broadcast in a production environment. So, it’s a data element that you don’t need to include in your SPaT message. And then finally there’s a data frame called “intersections,” and inside each of these data frames contains information about every intersection. So, looking at this, you can see that for a SPaT message we can broadcast information or SPaT information for up to 32 intersections in a single message.
And then finally, there’s a “regional,” which allows regional extensions. We call that SAE J2735 may be used internationally, so this may be extensions that are specific to a country or perhaps your region or your state may have some special need, so this is where those extensions or special needs that are not addressed by the standard—so this is where you can add those extensions. Within this structure, the SPaT message can support several pieces of information for each intersection. As we talked about, each SPaT message can contain up to 32 intersections. This is useful in dense urban areas where there might be several intersections that are very close to each other, and instead of broadcasting a message for every single intersection, we can broadcast a single message containing the signal information for those intersections. DuPont Circle, for example, in Washington, D.C., it really consists of about four signal controllers and since they’re close together and they’re related, we might be able to send a single message with the SPaT information for all four intersections in a single message.
Taking a more detailed look at what data is mandatory to provide for each intersection, we can see that first—skipping the name, because that’s optional—the first thing is an ID. This is a regional-unique intersection identifier for that intersection. It actually consists of two parts. One is the region, which is optional, but is an ID for the responsible agency. The State DOT, for example, would have its own ID. A city would have its own regional ID. But the ID should be regionally unique. So, within that region—let’s say within that State—it should have its own unique ID. That’s mandatory.
So, the next data element is “revision.” Revision is actually a message counter, but this is a source of implementation ambiguity. By definition, SAE J2735, the message counter can increment, A, every time the message is transmitted, or when the contents of the message changes. So, for example, if the SPaT message is broadcast every tenth of a second, every tenth of a second the revision number is expected to increment; or it can be incremented whenever the contents of the SPaT message changes.
For example, if the revision ID is number five and then you send another message and the revision number is still five, you the vehicle can interpret that as, “Oh, the contents of the SPaT message has not changed, so I don’t need to process it.” However, if the revision number count has changed to six, it tells the vehicle that, “Hey, something in the SPaT message for this intersection has changed, so I should go ahead and download and listen to and process the rest of this message because some value has changed.” So, it needs clarification, but traditionally we’ve used revision number for SPaT messages as only when—we only increment it when the message content changes.
The next data element is "status." It’s a data element that’s used to describe the general status of the signal controller. So, examples of the general status is, "Hey, is it operating properly? Is it in a preempt mode? Is it fixed time? Is it currently in failure flash? Is it currently providing signal priority?"
These are examples of statuses that can be broadcasted for each intersection or each signal controller. However, that’s another source of potential implementation issue. For example, what is the definition of providing signal priority? Is it to indicate that I’m doing signal priority as soon as the request is received from a vehicle? Should I still be indicating signal priority if I process the request and say, “Hey, they’re going to hit it right on the green wave. That bus is going to hit right in the green wave. We don’t have to change anything, so no modifications are necessary to the timing?,” should it still be indicating that it’s providing signal priority in that particular case, even though I don’t plan to change the timing? Definition of preempt mode—does it start as soon as the preempt request is received? Does it continue until the preempt completes its exit phases, or does it stop indicating preempt mode as soon as the train has left the railroad crossing, for example?
There’s a definition, a bit to indicate that the MAP was recently updated, but what does that mean? Is it within the last week, or is it the last month? Some of these status values may be defined in other standards such as NTCIP 1202 version 3, which we’ll discuss about later, but these are implementation issues that we need to address in the standard before we implement it nationwide in an interoperable manner. The next group of mandatory information in the SPaT message is something called “states.” Each State provides information for each movement at the intersection.
So, for example, a northbound left is a movement. And then each state also contains additional information such as a “signalGroup” ID. The signal group ID is an identifier which we assign to each movement tying SPaT data to specific lane-to-lane movement and MAP message. It’s through this ID—and there will be a corresponding ID in the MAP message. This is how we tie the SPaT and MAP message together, and we’ll talk about that a little bit down in this module.
For each state or for each movement, we include a data element called the “eventState,” which means for this movement, what is the vehicle or the traveler allowed to do. So, the possible status are it’s dark, the signal indication is dark; stop and proceed—for example, a flashing red or a red turn on red—so that’s a possible event state. There’s stop and remain, so that would be a solid red or a red arrow—a steady red; permissive movement; protected movement; permissive clearance; protected clearance; proceed with caution. These are some of the example states for each movement at an intersection. So, that’s required.
So, as an example, this is an example of movement identifiers assigned to each movement and intersection. Next to each movement is the current state of that movement, and this current state distinguishes between permission and protected movements. So, for example, for movement number two, we may indicate that the event state is currently permissive, while for movement number five, it’s a protected left turn.
And then we can—for movements four, six, and eight, we can indicate that currently the signal—the indication is stop and remain for each of those specific movements. So, in summary, these are the mandatory elements of the SPaT message. A SPaT message as identified by the message ID must contain at least one intersection. Each intersection contains the ID at the intersection, a revision or calendar to indicate has the content changed from the previously broadcast SPaT message, the status of an intersection or specifically the controller, and the signal state of each movement. Is it red, permissive, protected, or is it clearance? So, again, these are the mandatory elements that must be included in the SPaT message. The next several slides, we’ll present some of the optional elements in the SPaT message. This is not an exhaustive list; not all elements are presented in this module, but we do want to at least present some of those optional elements that may be commonly used to address common situations.
The first one is a concept of enabled lanes. It indicates if a lane defined in the message—a revocable lane in the MAP message is active or not. So, the MAP data message is intended to be static and potentially remembered by a traveler device, meaning a vehicle may say, “Hey, I’ve seen this MAP message. I know this intersection. I remember the contents of this MAP data message.” The MAP message should include all the lanes that may be used by the travelers even if they’re not always in effect. So, lanes that are not always in effect are what we call revocable lanes. So, for example, a physical lane may be only in effect during rush hour, but it is a parking lane at all other times. A shoulder lane along the highway, follow, may be used only during peak hours but not used except for emergencies during all other times.
Reversible lanes and HOV lanes during peak hours are other examples of a revocable lane. So, graphically we can see here that lanes 201, 203, 211, and 205 are revocable lanes. Revocable lanes may be mutually exclusive, meaning that they can only be—only one of them can be active at any one time. For example, 201 is the northbound direction and lane 211 is the southbound direction all the way on the left, and both are defined in the MAP data message as revocable lanes. They’re physically the same lane, but legally only one lane can be active at any one time. Same thing on the right, lane 203. When lane 203 is considered active, it means that it can be used for traveling vehicles, let’s say, during the peak hours, but at all other times, lane 205 is active because it’s used as a parking lane at all other times.
Another optional element is “timing,” meaning how long is an event state expected to be active for, or remain active for. It’s measured in tenths of a second in the current hour or the next hour, and it is time of change, meaning when is something expected to change within the hour. It’s not time to. So, it’s like, “Five seconds after the top of the hour this event status is expected to change,” not, “Oh, in five seconds it’s going to change.”
As an implementation issue, note that the timing values are not valid if the intersection is in the preempt mode because, as traffic engineers know, preempt mode is something different. So, for timing, if the timing information is provided, minimum end time is mandatory, and indicates the earliest time that the event state may change—meaning if I’m currently in green, when’s the earliest time that my green is expected to end? This is an implementation issue, actually, for actuated signals.
So, how is a vehicle supposed to interpret if the “minEndTime” has already passed? The minEndTime might have been five seconds after the top of the hour but now I’m ten seconds after the top of the hour. How is a vehicle supposed to interpret that? But minEndTime is mandatory; if you’re going to provide timing information, which is optional, then it must include minimally the minimum end time that the event state is expected to change. There’s also a concept called "startTime," but that’s ambiguous.
There’s been some disagreements about the interpretation of start time. Some believe that this is when the green, for example, first started; some believe that this is when the green will come up again. Other information that may be included with timing data is “maxEndTime,” which is the latest time that the event state may change. Think of it as a maximum green, for example. “LikelyTime”—the most likely time the event time will change.
“Confidence”—the statistical probability of the likely time being true; and “nextTime,” when the current event state will likely occur again. This is really intended for eco-applications. “Hey, I know if the green is about to end, when do I expect the green to come up again?” The green state. There are some implementation issues with some of these, timing data that we need to consider. For example, how do you calculate the likely time? That might be different from vendor to vendor, and same thing with confidence.
How confidence is calculated may vary between the different vendors. This is an example of what timing might look like for a basic intersection for a cycle. The same figure can be found in the Student Supplement that should be with this PowerPoint presentation. Timestamps here are in tenths of a second within the current hour, while the event state is an enumerated value of the current state of the movement, so you’ll have to look at the SAE J2735 to interpret this.
Other optional elements that might be included in a SPaT message are advisory speeds for a movement. Examples of why advisory speed may be broadcasted includes to maintain a platoon through the intersection or for eco-driving purposes. Up to 16 advisory speeds can be provided in a SPaT message, and advisory speeds can be provided by the class of vehicle.
So, for example, “Hey, I have an advisory speed for trucks,” might have a different advisory speed for all other general-purpose vehicles. We can also provide information for specific lane movements. For example, in the drawing we show a left turn lane. For that left-turn lane, we can show what the current key length is at this movement from the stop bar. The distance from the stop bar from within vehicles can expect to clear the intersection—meaning, “Hey, you’re within 100 feet of the stop bar. You’ll likely be able to make it through the intersection before the light turns yellow or red.”
There’s a bit that indicates if a vehicle should indicate a stop at the stop bar because there might be a queue further ahead beyond the intersection, so the vehicle should stop before it’s stuck in the middle of the intersection and blocks other vehicles. There’s a bit that indicates, “Hey, a pedestrian or bicycle in the conflicting crosswalk has been found.” All this information for specific lane messages requires that a MAP message also be broadcasted because if provides the context—where are the roadways, where are the lanes that we’re talking about.
So, when should an optional element of a SPaT message be broadcasted? Elements are defined in SAE J2735 as optional based on the collective experience of the standards development committee. What has been defined as mandatory elements were determined by the committee to be something that’s minimally needs to be included to provide some sort of information—in this case, the SPaT information. However, optional elements should be broadcasted if it’s required by regulations, some regulatory agency.
So, down the road, the State DOT or the USDOT may say, “You need to provide in your SPaT message.” Even though the SAE J2735 says it’s optional, they may say, “Hey, you’re required to send it, to include that optional element.” It also may be required by another standard or specification. So, for example, there’s currently a connected signalized intersection project that’s looking at what data elements—among other things—what data elements should we include in a SPaT message in the United States to support interoperability? Optional elements should also be broadcast if it’s needed to support a design application.
So, for example, the red light violation application, all the mandatory elements that we defined are probably sufficient, but if I want to support eco-approach and departure at signalized intersection application, then we need advisory speeds, because that’s part of it, to provide recommended speeds through an intersection. So, you may want—if you’re going to support the application, then in your SPaT message you want to provide advisory speeds in your SPaT message. It may be optional according to SAE J2735, but if you want to support the application, you need to provide that.
Support phase time remaining in an in-vehicle application—if you want to tell the vehicles, “Hey, this is how much time is remaining for your yellow light or before the light turns green,” then you have to include that timing data. It’s optional by SAE J2735 but if you want to support that application in the vehicle, let them know, “This is how long it’s going to remain green,” you need to provide that information in your SPaT message when you write your specification.
So, we reached our activity for this learning objective. The question is: Signal timing information for how many intersections can be included in a single SPaT message? Your answer choices are: [A] only one signalized intersection; B, only one signalized intersection and one non-signalized intersection; C, up to two signalized intersections along the arterial; or D, up to 32 signalized intersections.
So, the correct answer is actually up to 32 signalized intersections. So, a SPaT message can provide signal timing information for up to 32 signalized intersections. The other three are actually incorrect, but note that realistically a SPaT message will not contain 32 signalized intersections due to other restrictions imposed by communications that you use, and the communications range, meaning how far away from the infrastructure antenna. So, there are other standards, there are other considerations that will prevent us actually sending a message up to 32 signalized intersections, and we’ll talk about that later in this module.
So, next on our objective is: Describe the MAP message. We’ll start by describing what is the structure of this MAP message; we’ll talk about what are the mandatory elements of a MAP message; and finally, we’ll discuss a few of the optional elements in the MAP message.
So, unlike the SPaT data, which provides dynamic information, the MAP message provides static geographical information. By static we mean that the data is not expected to change unless the road geometry in this case is physically changed or restriped. Each MAP message can contain roadway geometry data information for up to 32 intersections and up to 32 road segments. Again, this allows us to send a signal message in case intersections—we’ll focus on intersections—are really closed spaced together.
This is a graphical depiction of the MAP message. Again, boxes in green are mandatory data elements according to the SAE J2735 and the yellow data elements or data frames are optional. The first is the “messageId.” So, the message ID for a MAP message is 18, and that would be the 2016 version of the J2735. “Timestamp” is optional but it indicates the number of elapsed minutes within the current year that this MAP data message was generated and broadcasted. The next data concept is the “msgIssueRevision.” This is the message counter indicating that the contents of the message has changed. Again, this is not expected to change frequently, maybe on the order of once every several months or years, because the road geometries are not expected to change very frequently. Then there’s some optional other information that may be of interest—“layerType,” what type of MAP information is provided in this MAP message.
“LayerId.” So, there’s several layers that can be included in the MAP message; this is the identifier for that. Optionally it can include “intersections,” so MAP data for intersections, MAP data for “roadSegments.” There’s some metadata about the MAP contents that can be provided; for example, how is this MAP message—or what’s the source of the contents of the MAP data. And something called “restrictionList,” which is a list of potential user class restrictions for intersections or roadways—for example, “This lane is only for transit vehicles or overweight vehicles, or low-emissions vehicles,” so if there’s any restrictions on a segment or intersection. So, although intersections or road segments are both optional, it’s probably expected that at least one intersection or one roadway segment is included in the MAP data message.
Since this is about SPaT and MAP messages, we’re really only going to focus on intersections, so we’ll talk about the MAP data for intersections. The next several slides define the mandatory elements for an intersection. Again, that’s technically optional, but we’ll go over what’s included if an intersection is included.
The first one is ID. Similar to what’s in a SPaT message, it really consists of two data elements. One is the identified responsible agency for that intersection, and that’s technically optional, and a regionally unique identifier for the intersection. Revision number—so this is a message counter to indicate the road geometry for the intersection has changed. This is a little different from the previous identifier for the MAP message. This is the counter for the intersection; the previous was the counter for the MAP message.
A MAP message, remember, can consist of multiple intersections and if any of the intersections change then the counter for that MAP message will have changed. Next is the “refPoint.” The reference point is an anchor point for the intersection. It’s normally the center of the intersection, or the center point of the intersection. This is important because later we’re going to describe the location of the lanes, meaning the lane path, the path of the lanes or the crosswalks, and they need a reference point to—because all the nodes that define the lanes are offset from this reference point for the intersection. And finally the “laneSet.” So, the lane set is a data frame that contains data describing the attributes of every lane that’s defined for the intersection.
So, looking at the lane set, it contains several mandatory pieces of information. The first one is lane identifier, which is a number from 1 to 255 and it’s a lane identifier for that lane unique within that intersection, meaning for that intersection, “Here’s my Lane 1.” Then we have a data frame containing data about the attributes of a particular lane, and we’ll break that down later in this module.
Actually, we’ll break it down right now. So, the “laneAttributes” contains three pieces of information. One is “directionalUse,” direction of travel in the lane. Is it a two-way—which direction is traffic traveling? Is it toward the stop bar or away from the stop bar? If it’s a pedestrian lane, it would be two-way, meaning, “Hey, pedestrians are allowed to move in both directions.” “ShareWith” indicates the presence of a different lane that has equal rights to use the lane. So, an example of a shared lane might be a shared bicycle lane or a tracked vehicle, so let’s say a trolley on a track. So, this data element indicates that, “Hey, I’ve defined this lane, but it can also be shared with other types of lanes or other types of traffic.” And then next is the “laneType” which defines the type of lane it is. Valid values are: Is it intended for vehicles? Is it a crosswalk? Is it a bicycle lane? Is it a sidewalk? Is it a striped lane? Is a physical barrier her[e]? Is it a tracked vehicle or is it a parking lane? It can also be used to indicate it is a revocable lane. So, remember, we talked about revocable lane earlier when we talked about the SPaT message. So, if it is a revocable lane, the SPaT message will indicate, “Hey, this lane is currently in effect and we should check the contents of the MAP data for this particular lane.” So, if it’s a parking lane that’s active, you want to look—this MAP data message indicates the attributes of this parking lane.
Also included in laneSet is the “nodeList.” So, this is a sequence of offset nodes representing the center line of the lane. There is a choice for each lane of how that lane can be represented. It can be a series of nodes, sequence of nodes, defining the center line of the lane, or it can be a computed lane, meaning, “Hey, I’ve already got a lane that’s defined. This is just a copy of the lane.”
The purpose of that is to try and decrease the bandwidth, how much data needs to be broadcasted in the data message.
So, looking at the nodes, each node is an XY offset from the previous node in units of a centimeter. Optionally, it can be a lat-long geographic coordinate, but we usually don’t do that because it just takes up more bandwidth. So, it’s a sequence from the previous node.
The first node point is the offset from the reference point of the intersection that we talked about earlier, and it’s usually typically at the stop line at the intersection. If you accrued the delta with the lane width, it kind of represents the lane as a polygon. This photo is a picture of the definition of some lanes at an intersection that’s overlaid on top of the actual MAP. The blue bubble in the middle of the intersection is the location of the geographic reference point for the intersection, and the nodes represent the lane numbers.
Note that for this particular example, only two nodes are shown for each lane. Also, note that their lanes were drawn for each of the crosswalks around the intersection. In red are the stop bars, which is not included in the MAP data message, but we drew them in just to show where the stop bars are. Notice that in the upper right corner of the intersection is a blue pin. It’s not actually a MAP data element but we used it—or in this example, New York City used it as a starting point to help determine the geographic coordinate of this particular intersection. We’ll discuss some tools later for creating, generating MAP data messages, but it is recommended that once you create the MAP data message that you overlay it over a base MAP so that they can check for accuracy and completeness.
As I mentioned, for each lane you have a choice. You can indicate the individual nodes for that lane, or you can call it a computed. A computed lane generally requires a small payload. It can be used at intersections with two or more adjacent lanes with the same characteristics. It can be scales or rotated, but the purpose of this is really just to decrease the payload of the MAP data message. The “referenceLaneId” is a required piece of information. It identifies the lane ID that the computed lane is based on.
We can do offsets of—to indicate where the computed lane is offset from the reference lane. So, you also have the first load of the computed lane from the referenced intersection along the X and Y axis.
This diagram shows an example of computed lanes. The light blue lanes are the computed ingress lanes, meaning entering this particular intersection; the dark blue lanes are the coded ingress lanes, meaning we actually had nodes describing that lane, the XY node offsets. In the pink, we also show pedestrian crosswalks for completeness, and the gray lanes are the egress lanes exiting this particular intersection. So, you’ll notice that we have—along this avenue we have one lane where we define the lane using those, but the next six lanes are actually computed lanes.
So, to summarize, the message identifier, the message versions are mandatory elements for our MAP data message, and also intersection is operational for a MAP data message. If the intersection is included, the mandatory MAP data elements include the identifier of the intersection and its reference point, the revision number for that intersection. We also, for each lane that are defined in the MAP data message, we have a lane ID. We describe some of the lane attributes, and then we want to include the nodes for at least—or the sequence of node assets—for at least one lane. All the other lanes could be a computed lane but you have to include the node offsets for at least one lane at the intersection.
Now we’ll quickly review some of the optional elements of a MAP message. In the interest of time and space, this module is not going to present every optional element in the MAP message, but the first piece of information that might be of interest in speed limits. This is regulatory information. This, again, doesn’t change very often, but we can include speed limits. It includes the type of regulatory speed limit. Usually it’s a maximum speed limit but it could be minimum speeds or, “This speed limit applies only for trucks,” or trucks with trailers, or it’s a school zone or a construction zone speed limit, and the speed is provided in two-hundredths of a meter of a second. That’s an implementation issue because it’s in the metric system not in the English system. So, that’s a regulatory concern because the translation is not direct.
We can also including metadata about the MAP contents. That’s an optional element. And user class restrictions, which means that, “Hey, there’s certain lanes in the intersection that might be for specific types of vehicles,” transit vehicles, high-compliant vehicles, overweight, emissions-compliant. So, that is something that’s optional that can be included in a MAP data message.
For maneuvers, we can include in the MAP data message what allowed maneuvers are permitted in the intersection. So, when we provide maneuvers, we want to indicate the source of the lane, meaning where does the movement enter the intersection, and where does the lane exit out of the intersection. Sometimes it may be—that lane might be defined by another intersection, so that’s the purpose of the “remoteIntersection.”
Each of these movements include a “signalGroup” identifier—so it’s the identifier of the movement. There’s a corresponding signal group ID in the SPaT message. It’s through this identifier that a vehicle or traveler can interpret the SPaT message and tie it to the MAP message. And sometimes maneuvers are specific to a type of vehicle, such as an HOV. So, this is the user class restriction that we described previously. “Hey, this is a left turn movement but it’s only for transit vehicles,” for example.
Node information. So, we’ve talked about node offsets, but we can also provide in a MAP data message about attributes at a node. So, for example, there is a fire hydrant. We may have a node there to indicate, “Hey, there’s a fire hydrant here.” Or for crosswalks, we may want to indicate where’s the safety zone for travelers, pedestrians, as they cross the crosswalk, where they can wait in case the light turns green, or, excuse me, the Don’t Walk comes on. We can also define zones for a lane, or for a segment of a lane.
For example, next to the sidewalk, we can indicate, “Hey, this particular lane, this is a transit stop.” Or it’s a parking zone, or there’s a bike zone, but there’s a rumble strip available. So, we can now define some of the attributes of a lane as part of the MAP data message. We can also indicate tapers, meaning the lane widths are not always constant. So, we can indicate, “Hey, at this node the lane starts increasing in width until the next node.” So, with that, we can indicate the taper in the lane widths for that particular lane, and same thing for elevation.
In case you’re along the hills, at a hill, we can indicate the changes in elevation more specifically. Talking about computed lanes, in addition to the referenced intersection, we can rotate a computed lane, meaning, “Hey, this is—instead of being a northbound, this is the same lane, same lane attributes, but in an eastbound direction.” We can also scale the size of a computed lane.
So, when are optional elements of a MAP message—when should they be included in a MAP message? Again, it’s the same thing as the SPaT message when it’s required by regulation or by another standard, or if it’s needed to support an application. If you’re providing SPaT information, you need to include them in maneuver information so that there’s a context for the travelers receiving that information so they know, “Oh, this SPaT message is tied to this specific movement in a northbound direction, making a left turn,” for example. Location and safety zones. If I’m a pedestrian safety application, I need to know where the traffic elements are so that I can safety wait. That’s included. And even though it’s optional on a MAP data message, you may want to include that data in there to support that pedestrian safety application. So, we’ve reached our activity for the MAP message discussion, learning objective. So, the question is: Which of the following attributes for a lane is included in a MAP message? Your answer choices are: A, the centerline locations of a lane; B, the permitted direction of travel of the lane; C, the permitted vehicle types that may use the lane; and D, all of the above.
So, the correct answer is D, all of the above. All of the above are true. The MAP data message does include the centerline locations of a lane. It does provide the permitted direction of travel for the lane, and it can indicate any vehicle or user or class restriction type for a specific lane. So, we’ve reached our Learning Objective 4, which is to describe some of the implementation considerations to providing SPaT and MAP data. We’ll start by first introducing several standards that may help define minimum requirements for specific applications that uses the MAP and/or SPaT data, and then we’ll discuss some of the implementation considerations of how to specify SPaT or MAP messages for your agency, or your implementation.
So, up to this point, we’ve described why the SPaT and MAP data is needed, and it’s really to support safety and mobility and environmental applications. We’ve also previously described what data is provided by the SPaT and MAP messages. The next couple of slides, we’re going to talk about when, where, and how the data is provided to support interoperability. Our other standards will help answer some of these questions, but what data, and when, where, and how data is provided to support interoperability may depend on the application.
The first standard we want to introduce is ISO TS 19091. It’s a standard that’s been developed in the international arena led by United States subject matter experts to support the connected vehicle environment. So, again, so far we’ve talked about the MAP and SPaT messages in SAE J2735, but all SAE J2735 does is define the messages and data elements. It doesn’t define what messages or when a message should be exchanged to support an application. It’s kind of analogous, again, to the English dictionary.
It can take the words in the dictionary to be used but it does not describe how those words are to be used to communicate. This is what the English grammar kind of does. It defines how English words are to be used to communicate in an interoperable manner, meaning so that we each understand what we’re—how we communicate with each other and understand what we’re trying to communicate. So, ISO TS 19091 is like the English language. It defines what messages are to be used to support a signalized intersection application and based on use cases, agencies’ desires to support, it derives operational and performance requirements, defines the sequence of information exchanges, also called dialogs, defines what messages to be used, what data elements, data structures should be exchanged to fulfill the requirements in a standardized way.
By defining the standardized way, the standard allows agencies to produce, element, and test signalized intersection applications in a consistent manner. So, ISO TS 19091 has been adopted in Europe to support interoperability in Europe and for now it’s probably recommended that we use it as guidance on how we support interoperability in North America until some other standard or reference guidance is provided.
Just to provide a quick overview, a high-level overview of ISO TS 19091, the V2I application addressed in this standard are described by use cases. Each use case describes the operations between the different actors, defines the information needs for communications between the travelers and the infrastructure, and identifies what information the application needs to support that particular use case.
The use cases in ISO TS 19091 can be categorized into three categories. One is priority and preemption applications; two is safety applications; and three is mobility and sustainability applications. Based on the use cases that an agency wants to support, it lists requirements to describe the details of that data. Deployments that conform to ISO 19091 will end up building to the same requirement and this helps ensure interoperability, and there are two types of requirements that 19091 supports: functional requirements—what is it that something has to do—and performance requirements—how well does it have to do it; how often do I need to broadcast the message, for example.
Based on those requirements, 19091 will specify which messages, which data elements, and which data frames should be exchanged to fulfill each requirement in ISO TS 19091. Sometimes it’s a SPaT message, sometimes it’s a MAP message. There’s a handful that requires that we exchange Basic Safety Message, the NMEA/RTCM correction messages, or the SRM signal request, signal status messages that we discussed earlier in this module. If you’d like to find out more information about using ISO TS 19091, there is a module called CV271 using the ISO TS 19091 standard to implement V2I intersection application functions.
A more North American version of that, centric, but similar to the ISO TS 19091, is the SAE J2945/x family of standards. All the standards in this family identify information and performance requirements for applications using SAE J2735. So, it also indicates how often a message is sent and minimum quality requirements for sending messages to support specific applications. So, each document identifies the minimum requirements or recommended practices for specific applications.
Going over some of the relevant standards documents in this series, one is the SAE J2945_20171012 Dedicated Short-Range Communications Systems Engineering Process Guidance for SAE J2735 document. This is also known as SAE J2945/0. It provides common requirements for all connected vehicle applications. It includes systems engineering contents, some concept of operation requirements for the family of standards. So, it provides generic content and requirements and documents for the rest of the standards documents in this family.
Two of particular interest is SAE J2945/A, previously called SAE J2945/10. It was intended to provide recommended best practices using the SPaT and MAP messages to meet operational needs. This document is currently on hold because the committee realized that there’s similar projects, work, that’s been going on. So, they decided to put this on pause. There’s two other documents that talk about this similar topic, and USDOT has started a new project called Connected Signalized Intersection project, which will address most if not everything that was intended to be in the J2945/A.
Also related to this module is the SAE J2945/B, which is recommended practices for signal preemption message development. It was previously called J2945/11, but this is currently under development, and it’s going to provide reference implementation on how to provide signal priority and signal preemption at signalized intersections. So, it’s based on implementations that are currently under development or that have been implemented.
Another standard that might be of interest is NTCIP 1202 v03, and this standard has content that will help define what to implement in SPaT messages. So, recalling that the source of SPaT data is from traffic signal controllers, NTCIP 1202 v03 standardizes data exchanges between a signal controller and the center beginning with v03. It also standardizes data exchanges to a roadside unit process so that it can generate SPaT messages. Version 3 was released in 2019. It’s an update of Version 2, which was published in 2005, and adds system engineering content in addition to support new user needs in the connected vehicle environment.
This is a context diagram, the scope of the NTCIP 1202. Notice that in addition to the interface between the controlling unit in the middle and a traffic management center or a maintenance laptop on top, we’ve also now addressed the interface between the controlling unit and a roadside unit.
So, some of the connected vehicle user needs addressed by the standard. It focuses on the interface between the roadside unit and the controller, and one of the user needs is to provide SPaT data to the roadside unit so it can generate the SPaT message. One of the new uses that we also included is it provides a check that the SPaT data matches the MAP data. So, there’s a checksum that we included there so that we make sure that the contents of the MAP message has not changed. It could be a bad thing if the SPaT data that we’re generating does not correspond to the MAP messages that we’re also broadcasting. So, there’s a check that we included in NTCIP 1202 to make sure that they are in sync.
There’s a note that NTCIP 1202 has user needs and requirements that support all the MAP, SPaT messages in the current version, which is March of 2016, except for regional extensions, and start time. Start time was because it was ambiguous. There was not agreement on what the definition of start time was, and regional extensions because no religion extensions had been defined at this particular time. So, the implementation issues that we have to consider when implementing NTCIP 1202 is: Does the controller push or pull the data with the RSU? There have been disagreements and arguments on both sides on which is the better way to do it, whether the controller pushes to the data to the RSU or whether it pulls the data from the RSU.
Factors to consider includes the performance, bandwidth concerns, processing requirements, and security. So, that might be—this is a decision that your implementation has to consider. The data elements are the same. Whether it’s push or pull, the difference is which device initiates the exchange. Even if the controller pulls the data from the RSU, the controller should still push the data up periodically. That’s the recommendation.
Another implementation issue is the clock differential. Signal controllers often, especially the older ones, may use a different clock source that the roadside units. The roadside units are based on GPS. They use the GPS as a clock. Not all signal controllers do that. Some might be based on the electrical grid; some of them might be based on WWV. So, there’s going to be a clock difference between the two devices, so how do we address that clock difference? So, the controller provides its time with SPaT data based on ticks, and then there’s the expectation that the roadside unit will make the conversion, adjust the number of ticks and convert it to number of milliseconds based on GPS time.
So, for additional information about the NTCIP 1202 v03, there are some modules—professional capacity building modules that are being updated to talk about the Version 3, so that’s the reason it’s called the A315 modules. There’s the A315a for user needs, A315b for requirements, and eventually there’ll be a T315 for testing NTCIP 1202 v03. So, we’ve talked about some of the standards that might help you specify SPaT and MAP messages.
We now want to talk about how do we do that, and determine which operational data elements to include in your specification. One recommendation is look at ISO TS 19091 as a guideline. It lists out the most common use cases for signalized intersections. Take a look at which use cases you want to support, and then 19091 will indicate, “Hey, if you want to support this use case, these requirements, and thus these data elements, should be included in your specification.” If you’re using NTCIP 1202 for your controllers, to communicate with your controllers, we suggesting completing the PRL or the Protocol Requirements List, which is in a table in NTCIP 1202. What it does is once you complete the Protocol Requirements List, it makes some of the optional data elements in SAE J2735 to be mandatory.
And finally, right now USDOT has started—we mentioned this—USDOT has started a new project called the Connected Signalized Intersections Project. It started in November 2019, and the purpose of this project is to either develop a standard or a specification to define key capabilities to support interoperability for state and local infrastructure owner/operators.
Another consideration for both SPaT and MAP messages is to consider communications media. So, this could be, for example, DSRC, dedicated short-range communications, or C-V2X. For example, if you’re using the DSRC, it implies the use of other standards which may impose constraints on the messages. IEEE 1609.x, for example is used with DSRC, and one of the standards in IEEE SPaT, latency can be a consideration for how the message is broadcast.
Inspected the contents of the SPaT or MAP message, we do need to consider how security is provided and then from where, when, generating the SPaT or MAP messages. It could be signed, signed to indicate that it’s an authentic message. It could be signed at the roadside unit. It could be signed at the center. That’s a security decision that has to be made for your specific implementation. There are other PCB modules currently being developed that address security, so I refer you to those modules to see what other modules may be currently available.
Specific to MAP messages, MAP messages must be included with the SPaT messages. If you’re broadcasting a SPaT message, there should be an accompanying MAP message that also gets sent. Both messages have something called Signal Group ID, which are technically operational, but they really are required if you’re broadcasting both so it provides a linkage between the different movements at the intersection.
The SPaT indicates what’s happening, what’s being allowed, what movements are being allowed at the intersection, but the MAP message indicates where the lane is and where the movements are. The level of detail of the MAP messages is going to vary based on your implementation. It depends on which applications you intend to support. Some applications don’t require a high level of detail. Some of them may require more. So, the level of resolution may vary.
The geographic extent needed may vary depending on what applications. If it’s a low-speed environment, a low-vehicle-speed environment, you may not need a big geographic extent. If it’s a higher speed, then you may need to consider a longer roadway to be included in your MAP data message. What information is needed? You can report on messages, but if you’re not expecting to support pedestrian applications, for example, don’t include the crosswalks.
There’s communications limitations, the message sizes that might be imposed based on what communication you are using. So, even though we said, again, like the SPaT messages, you can include up to 32. Typically, you only include one, maybe three intersections per MAP message. Look at SAE J2735. It does include recommendations on transmission rates for both MAP and SPaT messages. For the MAP message, it’s recommended once every 200 seconds. The SPaT messages, we usually broadcast every tenth of a second. The SAE J2735/0 also includes what DSRC channels to the message should be broadcasted at and recommends transmission and power levels.
Other implementation issues for our MAP include—it’s based on the WGS84 coordinate system, but that coordinate system doesn’t recognize that—well, North America is moving from the Prime Meridian almost 10 centimeters per year, so that needs to be considered. Intersection and ID numbering—we need to probably come up with a consistent scheme for uniquely identifying intersection IDs within the United States, or at least within the states. So, that’s something that each state DOT may want to try and work out. “How do we number the intersections so every intersection within the state has its own unique ID number?”
We still need to define how we implement or define lanes. For example, how crosswalks are reproduced on a MAP data message—we provide the format but we don’t talk about how we represent crosswalks, and there has been six, seven different ways that crosswalks are represented around the world. So, that’s something we need to work on. As of this recording of this module, the Connected Vehicle Pool Fund Study recently released a request for letters of interest to create a guidance document for MAP preparation, or how to create MAP messages. This is expected to be a one-year project that’s expected to start in March 2020. So, that’s something we should be watching.
There are tools for developing MAP messages. USDOT has created a J2735 MAP tool. What it does, it can help automate MAP data validation and visualize data to reduce errors. It takes the MAP message that’s been created and overlays it over a base MAP. That way you can visualize is the overlay accurate and does it match the base MAP. We can match lane widths and the allowable maneuvers of the MAP message contains those optional data elements.
Some additional references that are available in the Student Supplement. So, look at the reference section. I’ll point out three of them here. As we’ve mentioned throughout this module, there are other PCB modules available that talk about different variety of topics. Security is one of them; some of the other standards that were mentioned, some of the other messages that are supported in J2735. The National Operations Center of Excellence, as part of the SPaT Challenge, has a webpage that contains a lot of excellent resources and guidance for implementing applications at signalized intersections. In addition, we suggest reviewing how the CV pilots have been implementing those pilots. Some of the information that may be useful is how the CV sites work together so that the different pilots are interoperable.
So, to talk about a case study: What reasons we developed these standards is for interoperability, so that no matter which vendor we use and no matter how we support applications, that they’re interoperable. The city of Anaheim decided to test their interoperability—so this is the case study. What they did was they deployed onboard units and roadside units from three different vendors. Onboard units belong in the vehicle. In addition to the radios, they include the applications for collecting data from the infrastructure. So, they deployed OBUs and RSUs from three different vendors on their roadway network.
Obviously, not unexpectedly, OBUs and roadside units from the same vendor worked, but when they compared it with different vendors—meaning Vendor A, OBU talking with Vendor B’s RSU—it showed different results. There was real inconsistencies, or there was no interoperability between the different vendors. Times to change showed up differently on the vehicle applications. Applications did not always work. They did a little study of it and realized that the MAP configuration affected the applications on the onboard unit or in the vehicle.
Sometimes applications were expected optional data elements and if it didn’t get it, it didn’t know how to handle that situation, so it didn’t properly display the correct data to the driver. The reverse was true. The applications were not expecting some of the optional data that was being broadcasted and it was like, “Oh, I wasn’t expecting this.” It didn’t know what to do, so it didn’t handle that particular situation properly. So, the lessons learned from it is specify which optional elements are mandatory for your specific implementation, meaning included in your specification. Test the applications that are being implemented to make sure that they handle unexpected or nonconforming data packets. “I wasn’t expecting this data element but I received it. How do I handle it?”
So, we reached our final activity. So, the final question is: When broadcasting SPaT and MAP messages, which of the following issues must be considered? Your answer choices are: A, only one intersection is contained in each SPaT and MAP message; B, all MAP messages must be accompanied by a SPaT message; C, other standards may limit the number of bytes in a message; and D, SPaT and MAP messages must use the same broadcast rate. When broadcasting SPaT and MAP messages, which of the following issues must be considered?
The correct answer is actually C: Other standards may impose message size limitations. A was incorrect because each MAP and SPaT message may describe up to 32 intersections. This is incorrect between SPaT messages must be accompanied by a MAP message. The MAP message does not have to be accompanied by a SPaT message. The MAP message may be for a roadway segment and there are no signalized intersection at roadway segments, so answer number B is incorrect. And answer number D is incorrect because SPaT messages are dynamic. They may need to be broadcasted more frequently.
So, in summary, this is what we have learned. For the first learning objective, describe the scope of the SAE J2735, we learned that SAE J2735 is a data dictionary for the connected vehicle environment. It defines messages and data elements fort transportation connectivity.
We’ve also learned that the SPaT message provides dynamic information for a signalized intersection, including the general status of the traffic signal controller, the signal timing information, and what lanes might be currently in effect.
We learned that the MAP message contains static information for an intersection. It describes the roadway geometry and the allowable uses of different lanes at an intersection, including the allowable movements through the intersection.
And finally, we talked about some implementation issues for deploying these messages, including some standards that may help define what operational elements should be included when broadcasting these messages.
But probably the most important lesson we hope you learned today was that providing MAP and SPaT messages at signalized intersections can help us address some of the transportation challenges that agencies face today with safety, mobility, and improving the environment.
So, thank you for completing this module. Please take the time to complete the survey that accompanies this module so that we can improve these modules moving forward. Thank you again.