Module 51 - CV271

CV271: Using the ISO TS 19091 Standard to Implement V2I Intersection Applications Introduction

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 US Department of Transportation's Intelligence Transportation Systems 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. You can find information on additional modules and training programs on our website at www.its.dot.gov/pcb. Please help us make even more improvements to our training modules through the evaluation process. We look forward to hearing your comments and thank you again for participating and we hope you find this module helpful.

Patrick Chan: Hello, everybody. This is module CV271 called Using the ISO TS 19091 Standard to Implement V2I Intersection Applications Introduction. My name is Patrick Chan. I've been involved with the development of ITS standards since the year 2000, originally as part of a public agency before moving to the consultant side. I've previously been involved with-- as a systems engineer for development of numerous NTCIP ITS standards and TMMD and was a developer of SAE J3067 which is a comment report to SAE 2735, the dictionary for connected vehicles. Our learning objectives today are to identify the benefits of standardization for agencies, system developers, and suppliers. Describe the scope of the ISO TS 19091 Standard. Describe the use cases that are addressed by the ISO TS 19091 Standard. To explain the relationship between the ISO TS 19091 Standard and the SAE J2735 Standard. And finally, learning to apply ISO TS 19091 Standard content to your specific project.

Patrick Chan: So for learning objective one, we're going to identify the benefits of standardization for agencies, system developers, and suppliers. So this slide summarizes the overall benefits of standards and answers the question of why do we need standards at all? By now, the participants should be familiar with what standards are and the benefit of standards. However, we just want to reemphasize one of the key benefits, which is interoperability. The answer to the question why do we need standards at all is that standards promote interoperability. Standards allow systems made from different manufacturers to exchange information. This promotes competition, such as based on equality, price, and innovation. The system might be an application, as we'll see later in this module. And a example of interoperability is Wi-Fi. Due to use of different standards, Wi-Fi standards; Internet standards, such as HTTP, HTML, it doesn't matter who manufactured the laptop you're using or the device that you're using or where you're using the device, whether it's an airport or at home or at Starbucks, if you-- with these standards, you are allowed to connect to the interconnected Internet, browse websites, collect your e-mail, regardless of the laptop, where you are, and which program you're using to access Internet, whether it be Chrome or Firefox. This slide summarizes the overall benefits of standards. For agencies, regional integration is a key benefit. It helps facilitate communication between a system-- an agency system and other systems. The standards can also reduce costs-- implementation costs for all, for all those that are involved with the regional integration. For agency, system developers, and vendors at testing, is also a benefit of using standards. We can develop common tests for standardized features, allowing the agencies to implement just to focus on testing non-standardized optional innovative features. For agencies and vendors, market share is also a benefit. As we will demonstrate that, without standards, market share is limited as some equipment will work with some systems and others will not. By using standards, we have more competition for the agencies and for the buyers. Hopefully, reducing cost. Standards can also reduce costs for all parties, resulting in lower costs, such as lower integration cost, and increasing the speed of adoption because standardized features are known. Customized features, on the other hand, poses all types of risk, the unknown, the things that we don't know. Standards is still allowed for innovation. Many standards provide a path to extensions, which are features are not explicitly supported in the center. This allows the implementation to build to the base standard. So you have a base to work on while adding innovative features that are not expressed in the standard. But while we are focused on the benefits of the implementers, there are also benefits to the ultimate client, the general public. For connected vehicle standards, these benefits may include safety-- improved safety traveling through an intersection; improved mobility as these applications and-- these standards help to reduce delays at the intersection and in the environment, as these standards help decrease emissions and wasting less fuel consumption while idling at intersection. For travelers, there's also more consistent provision of services as their standards that the traveling public understand. For example, all drivers understand what a green, yellow, and red means on the traffic signal and that an octagon-shaped sign is a stop sign and blue and white signs are travel information signs.

Patrick Chan: So we reached our first activity. These activities are used just to reinforce what we've learned so far in the module. So the first question is, which of the following is not a benefit of standardization? Your answer choices are A, supports interoperability; B, reduces risks; C, prohibits proprietary solutions; and D, helps with design and procurement.

Patrick Chan: So the correct answer is C, prohibits proprietary solutions. Standards allow proprietary extensions to allow for innovations. Standards do support interoperability both within and without-- between systems. It does reduce risk by aiding testing, for example. It helps with procurement and design by helping system developers specify functions and communications.

Patrick Chan: For the next section, we're going to describe the scope of the ISO TS 19091 Standard.

Patrick Chan: But first, let's quickly go over what a connected vehicle environment is. By now, the participants should be familiar with what the connected vehicle environment is, but we'll summarize it quickly, just to be sure. Connected vehicle environment is a scenario where all vehicles can broadcast their current position; their current kinematics, such as speed, acceleration; and share/ broadcast the sensor information. By broadcasting this information, other vehicles, for example, will know, oh, there's another vehicle in my blind spot so maybe I shouldn't turn into that lane where my blind spot is. Or at an intersection, if a vehicle is entering an intersection, we may recognize, oh, there's another there's another vehicle that's entering the intersection and we may have a high opportunity for a collision. So let's do something. Vehicles can also receive information from other devices that will reduce the likelihood of incidents and also can improve mobility, such as provide information, oh, there's an incident at this location. So please avoid this location. Note that a connected device may also be a mobile device on a person, such as a smartphone on a pedestrian bicyclist. They also can provide information about their location and also receive information that might help with their travels, such transit connections.

Patrick Chan: This graphic on the right helps you visualize what connected vehicle environment may look like. So imagine a congested downtown area. The traffic agency is trying to maintain signal coordination, addressing signal priority while responding to unplanned events, such as emergency vehicles responding to an incident. Imagine that all the vehicles in this congested area are broadcasting their location to other vehicles and to the traffic signals and the traffic signal is broadcasting signal timing and MAP information, road way geometry information to vehicles and pedestrians in the area. An application, which is like a software, on the device or on a vehicle will receive the signal timings from the traffic signals and then can recommend a speed for the vehicle to travel through these traffic signals without having to stop. An application on a vehicle might also warn about-- a driver about potential conflicts, other vehicles traveling on other approaches going through intersections or a pedestrian or a bicyclist that might be crossing the crosswalk in front of its intended path. Meanwhile, an application in a traffic signal control might know the locations of the vehicles approaching the intersection and can adjust the signal timings to minimize overall delay at the intersection or to avoid conflict and possibly override preferential treatment for emergency vehicles or transit vehicles to decrease their travel time, improving the overall traffic for the region. All these applications can lead to improved safety, mobility, and to improved environment.

Patrick Chan: So how do we deploy this connected vehicle environment? So we consider the current situation. The roadway consists of vehicles of different types of vehicles and vehicles from different manufacturers and the infrastructure might be operated from different agencies. Could be a state agency or different local agencies, such as a city or a county. But for the required transportation and conductivity to happen, there is several questions that we need to answer for this environment to happen. For example, how do we communicate? Do we communicate on wirelessly on one frequency or different frequencies? Is it Wi-Fi or is it radio? What language are we using? We have to agree what words we're going to use to exchange information. If one person is speaking Spanish and another vehicle is speaking English, they won't be able to communicate and share information. How many people are talking in the room? If it's just two people, that communication is pretty easy. But if there's hundreds of people in the room, what do we do? How do we communicate to each other? What's the noise level? What if hundreds of people are trying to talk at the same time, how do we share the right information? How do we trust each other? How do I know you are who you are and that the information that you're providing me is correct and that you're not providing me with false information? So there are standards that have been developed to support to answer all these questions. Without these standards, we won't be able to share that information that are needed for the connected vehicle environment. So for this particular module, we're going to focus on what language are we using. We're going to talk about standard that defines the grammar and the data dictionary that we're going to use for connected vehicle applications at intersections. There are other standards that answers the other questions, such as IEEE 1609.

Patrick Chan: Looking at the ISO TS 19091 Standard, the title of it is intelligent transport systems cooperative ITS using V2I and I2V communications for applications related to signalized intersections. The standard is expected to be published in 2017. At this time, it is in ballot, but it has not been published yet. So this standard defines the dialogs, messages, data structures, and data elements to support exchanges between roadside equipment of the infrastructure and vehicles that are related to signalized applications. It defines the interface requirements between this roadside equipment and connected vehicles. These requirements will result in dialogs, messages, and data structures, and data elements to be exchanged. By using the standard-- by conforming to this standard, CV applications for signalized and non-signalized intersections are easier to procure, can be implemented in a clear and unambiguous manner, and can be tested in a consistent manner.

Patrick Chan: These are some of the applications that are supported by the ISO TS 19091. As we briefly mentioned, applications are pieces of software that run on a device. It may be a vehicle, may be a smart phone, or it might be in a roadside equipment by the roadside. This slide lists some of the priority and preemption use cases applications supported by TS 19091. That is, all these applications or use cases are related to traffic signal priority, which has transit signal preemption. The standard really describes three types of signal-- transit signal priority. For example, there's localized transit signal priority, meaning as signal intersection; transit signal priority with a near side transit stop; and transit signal priority along an arterial. Similarly, two other applications are related to freight signal priority for commercial vehicles, maybe near a commercial port, for example. There is localized freight signal priority, which is for a single intersection, or local signal priority with a platoon, which means a convoy of vehicles. And there's also a use case for arterial freight signal priority for a platoon along an arterial. Applications are also supported for emergency vehicles, whether it's single emergency vehicles responding to incident or multiple emergency vehicles responding to an incident. Finally, the last use case, PR6, talks about a scenario where mixed emergency vehicles and other priority eligible vehicles, such as transit vehicles, exist.

Patrick Chan: Some of the safety applications supported by TS 19091 include dilemma zone protection. What do we do when a vehicle approaching a yellow is finding it difficult to stop in time in front at an intersection or will it continue through an intersection? This application will warn surrounding vehicles that there is a vehicle in dilemma zone, meaning that, hey, there's a possibly that this vehicle may not stop in time before the light turns red. Red light as stop line-- stop sign violation warnings will notify drivers in real time of the need to stop to avoid a stop sign or a red light violation. Turning assistant applications warn drivers whether-- that wishes to make the turn, hey, is there a sufficient gap for you to make the turn or is there possibility that there's a pedestrian in the crosswalk in front of you as you're trying to make the turn? There's use case applications for crossing non-signalized intersections and also one for warning drivers about a potential pedestrian or bicyclist that's in the intersection for a non-signalized intersection.

Patrick Chan: There are also use cases, applications deployed for mobility sustainability. One is basic local traffic signal actuation, where it's single-- collects information from the connected vehicles approaching an intersection to optimize traffic operations in real time. There's one application for platoon detection for coordinated signals so that we can support a platoon going down an arterial. And there's an application for congested intersection adjustment, where it tries to optimize the traffic signals to mitigate congestion at an intersection. There are also applications to provide optimal speed advisory to vehicles, as shown in the graphic. This is the best vehicle to drive at as you approach the intersection and it is application support corridors, speed guidance, which is the best speed, what is the best speed for the vehicle to travel through the corridor? There is application for idling stop support, which means, oh, the light is not going to turn green for you for a little while so perhaps you can shut off your engine to try and save fuel. Start delay prevention to warn a driver that, oh, the intersection-- the signal, is going to turn green for you in about-- in a couple of seconds. So get ready to start moving the vehicle. Inductive charging at signals allows vehicles to-- equipped with inductive charging capability to charge their vehicle while stopped at an intersection and don't block the box with live vehicles with information to help drivers determine whether they can enter and clear the intersection and not block the middle of the intersection. So these are just some of the applications. These are the applications that are supported by the ISO TS 19091 Standard. We've reached another activity. So the question is, which of the following is not an application supported by ISO TS 19091? Your answer choices are A, localized public transport signal priority; B, signalized corridor eco-driving speed guidance; C, red light violation warning; and D, forward collision warning. Which of the following is not application supported by ISO TS 19091?

Patrick Chan: So the correct answer for this is D, forward collision warning. Forward collision warning is a vehicle-to-vehicle application and thus not within the scope of ISO TS 19091, which focuses on vehicle-to-infrastructure applications at intersections. So localized public transport signal priority is within the scope of ISO TS 19091, as is signalized corridor eco-driving speed guidance and red light violation warning.

Patrick Chan: The next learning objective is to describe the use cases addressed by ISO TS 19091 Standard. While we went through the list of the use cases and applications supported by the standard, what we want to do now is just talk a little bit about what type of details-- what's in the use cases in the ISO TS 19091 Standard? First, we're going to talk about what the different section is in the ISO TS 19091 Standard.

Patrick Chan: The first, the scope defines the purpose of the standard. 19091 describes hat messages and elements should be used to satisfy the data needs for applications related to signalized and un-signalized intersections. Normative references provide references to other standards that are used by the ISO TS 19091 standard, while terms and definitions provide a glossary of some of the terms-- of some of the words that are used within the standard. And then, there is also a section for symbols and abbreviation terms. The general description section describes the types of applications supported by the standard. For each application, the needs, the actors, and the data that must be exchanged, including the sequence of data exchanges needed for the application to function, are described. We'll also review the details of these use cases later in this module. The function description identifies the requirements based on the data exchanges described in the use case. This is a key part to the system engineering process used in creating the standard. It helps ensure that the application described in the use cases fulfill the needs described in the general description. The messages section lists the messages described by ISO TS 19091 Standard to fulfill the requirements in the function description. In other words, these are the messages passed between the vehicles and infrastructure that are the building blocks for the applications supported by the standard. Finally, the conformance statement are found on new conformance and describes the circumstances under which an implementation of ISO TS 19091 would be considered conformant with the standard.

Patrick Chan: Moving on, Annex A of the standard contains the 26 use cases supported by ISO TS 19091. The use cases are used to demonstrate the user needs that are addressed by the standard. Annex B chases those usage cases from in Annex A to the requirements contained in the function description. The requirements are directly derived from the use cases in Annex A. The use cases requirements matrix in Annex B lists the specific requirements that may be selected to satisfy the use cases supported by the standard. The purpose of Annex B is to show which requirements apply to which standardized application. If an agency and device manufacturer wants to implement an application, then those requirements that trace the use case may apply to the application. This module will demonstrate how to use Annex B later. Annex C contains the requirements traceability matrix, or the RTM. This matrix is another tool that ensures that each requirement defined by the standard is traced to a standardized message and/or data elements that are needed to fulfill the requirement. The messages themselves, including the data elements, are described in SAE J2735, as we will demonstrate later. This RTM, requirements traceability matrix, allows system developers to use the standard and specification. Annex D describes the procedures used to add additional functionality not described in 19091 was specified as a system that uses the ISO TS 19091 Standard. The module will also demonstrate how to use the RTM later.

Patrick Chan: Annex E, F, and G are different-- describe different profiles of J2735 and how they can be implemented using 19091. Each profile describes the contents of the standard that could be used in a geographic region. Annex E describes Profile A for J2735 generally used in North America, while Annex F describes Profile B, which is intended for Japan, while Annex G is intended for Europe. Only the North American implementation's Profile A will be discussed in this module.

Patrick Chan: The next several slides provides high overview of the use cases in this standard. So ISO TS 19091 describes what information needs to be exchanged to deploy applications. The description of these data exchanges are found in the use cases. The use cases are described at a high level in section five, general describe, but in detail in Annex A. The use cases define information needs for communications between actors, such as vehicles and infrastructure. The use cases are organized into three categories based on the type of application being described. PR represents priority preemption. SA represents those use cases associated with safety. And MS use cases are associated with mobility and sustainability.

Patrick Chan: So this slide shows what is included in each use case example. For this example, we're using the PR-- we're demonstrating PR1, which is localized public transport signal priority application. So for each use case, we have a category, mobility or safety, identifies if it's a safety issue, a mobility use case, or it's environmental use case. The infrastructure role that was the role of the infrastructure is just receiving data or is it transmitting data or is it controlling traffic? A short description in the use case. So this use case describes as basic priority control for connected public transport vehicles. The goal, what are we trying-- what goal are we trying to reach to satisfy with this particular use case? In this, improve public transport efficiency and reliability. What are the constraints? List the constraints that may affect the deployment of this application. The geographic scope indicates are focused on a specific intersection or a group of intersections? And the actors are the elements that are involved in this application. Sometimes the actors, we include alternate actors. So with the support, multiple types of scenarios.

Patrick Chan: Each use case also includes a diagram. Use cases demonstrate the actors, the location of the actors, and also the flow of communications required for this application to work. So in this example, we show flow one. The first step of this scenario is that a transit vehicle sends some type of information onto the DSRC roadside equipment, which, in turn, will send information to the traffic controller equipment, the traffic signal controller. The DSRC roadside equipment may also send information to the traffic management central system. And next, the traffic signal controller equipment might send information to the traffic management central system also. And then, finally, there is some exchange of information between the traffic management center and the transit vehicle itself.

Patrick Chan: Other portions of a use case might include preconditions, with similar constraints, but describes the preconditions needed before the application is executed. The main flow provides the most common flow of communications to execute the application. In this case, these are the numbers that we showed in the previous diagram. What are the steps? There is communications expected between the transport vehicle-- public transport vehicle and the DSRC. What flows between the DSRC roadside equipment and the traffic signal controller? Et cetera, et cetera. Note this is just a partial snapshot of what the main flow may look like. Sometimes, the use cases also include alternate flows, alternate scenarios of communications. In this particular case, what's shown here is a back office processing center of a TMC. Uses some kind of communications to communicate directly with the transport-- public transport vehicle.

Patrick Chan: Other types of information that might be included in a use case includes post-conditions, describes the post-conditions required to return the system back to the original operating conditions. Information requirements. What type of data is being shared between the actors in this particular use case? Issues. Addresses any additional issues needed to deploy the application. In this case, the issues include additional assumptions and functionalities of the actors or the appointment that are part of this particular use case. And finally, the source documents and references. List the sources used to develop this particular use case.

Patrick Chan: Based on the use cases, ISO 19091 then defines the requirements to satisfy the information needs for each use case supported by ISO TS 19091. The information needs are described in the information flows of each use case, as we have seen before, but the use case-- and the use case defines what data is needed to support an application and why. The requirements on the other hand provides the details of that data, what functions are supported by the application use case, and what data needs need to be exchanged to support that function. Based on the list of requirements, implementations that build to the requirements will be interoperable. That is, they solve the same problem the same way.

Patrick Chan: There are two different types of requirements included in the ISO TS 19091 Standard. Functional requirements prescribe the functions that the system should perform. So for example, one requirement is each public vehicle shall broadcast information about its location to other connected devices. All the functional requirements are categorized by the device and message. Performance requirements, on the other hand, show how well we have to perform the functional requirements. These are separate requirements from the use cases and not tied to a single application. In addition, each use case includes the collection of performance measures with the intent to provide a tool for analysis to improve operations. Examples of performance requirements include transmissions rate, how often should a message or data be transmitted, what are the response times? So note that some of these performance requirements might depend on the communications media, whether it's wireless, whether it uses DSRC, or whether it uses cellular phone that is used to exchange information

Patrick Chan: So again, requirements in ISO TS 19091 grouped by the devices that the applications support that-- oh, that the applications should be supported are running on. Devices might include special types of vehicles or roadside equipment, such as public safety or public transit vehicles. The requirements of further group by the type of information required by the application. The grouping includes signal phasing and timing information, which might be provided by a traffic signal; signal preemption priority that might be requested by the special type of vehicle, such as an emergency vehicle, transit or commercial vehicles; the status of the signal preemption of priority request; the roadway geometrics, where are the lanes, what's the geometry of the intersection; and GNSS augmentation details, which are based-- used to improve the accuracy of GNSS devices, such as GPS devices. GPS is a North American implementation of GNSS, which is global navigation satellite system.

Patrick Chan: So we reached our current activity. Which of the following is not a category of use cases in ISO TS 19091? Your answer choices are A, safety; B, electronic payment; C, mobility sustainability; and D, signal priority/preemption?

Patrick Chan: And the correct answer is electronic payment. Electronic payment is not covered in ISO TS 19091, though it is considered a category of application. Safety use cases are included in ISO TS19091, as are mobility and sustainability and single priority/preemption.

Patrick Chan: So in the learning objective, we're going to explain the relationship between ISO TS 19091 and SAE J2735. Let's see. So in the next learning objective, we're going to explain the relationship between ISO TS 19091 and SAE J2735. The next slide slides describe this relationship, how the ISO TS 19091 is used in concert with SAE J2735. Up to now, we've discussed the applications that are supported by the ISO TS 19091 Standard and the requirements that trace those use cases' application. We also mentioned functional requirements in the ISO TS 19091 Standard, identified the data to be exchanged between two actors to support a function of the application. We're now going to explain how the SAE J2735 standard describes the data to be exchanged and the relationship between ISO TS 19091 and SAE J2735. First, the SAE J2735 is a message dictionary. It defines messages and words called data elements that we use to communicate in the connected vehicle environment to support both V2V and V2I applications. To describe the relationship between ISO TS 19091 and SAE J2735, we're going to use an analogy, specifically the English language. In the English language, we have grammar that defines the rules on how we communicate and we also have a dictionary that contains the words that we use to create the sentences to communicate. In our analogy, the SAE J735 describes the words or data frames that-- data elements, data frames, which are analogous to words that we use to communicate. It also describes the message sets or the sentences that we will use to provide a piece of information. So the SAE J2735 defines the messages and words that we would use for communications to actually do things to fulfill a particular requirement. Meanwhile, the ISO TS 19091 analogy is the grammar. It references SAE J2735 for the messages, the data, structures of data elements for the applications, but ISO 19091 adds the rules for the use of these messages, data structures, and it defines, hey, if there's a piece-- there's something that we want to exchange, what are the rules? What sentences should we use? What words are we going to exchange that information? So ISO 19091 works together with SAE J2735 to define design to fulfill the functional requirements in ISO TS 19091. It does that by providing a tool, a requirements traceability matrix, that defines the SAE J2735 design, those words, those messages that should be used to fulfill each requirement. The design may be in the form of a message, a data frame, or a data element.

Patrick Chan: So for example-- this is an example of functional requirement in SAE-- sorry, in ISO TS 19091, in this case, the broadcast signal phase and timing information. Each requirement has a unique identifier, in this case 6.7.1, and a unique requirement name, in this case broadcast signal phase and timing information. It's followed by a description about what we're trying to accomplish, what are the requirements we're trying to accomplish. So an RSE shall broadcast a message with signal phasing and timing information. In the requirements traceability matrix, which we will go through later in this module, ISO TS 19091 defines the SAE J2735 signal phase and timing message, the SPaT message, to fulfill this requirement. The SPaT message is only one of the messages defined in SAE J2735 that are used to fulfill a requirement in ISO TS 19091. Other SAE J2735 messages that are used to fulfill requirement include the basic safety message, which provides information about the location of a vehicle and its kinematics. Where is it right now in the roadway? Which direction is going? How fast is that vehicle going? A signal request message, which is a request for signal priority or preemption at a signalized intersection. A MAP data message, which describes the geometry of the roadway at the intersection. So where are the lanes? Where are the sidewalks? How wide is the lane? Where is it approaching the middle of the intersection from? There are also two messages called the National Marine Electronic Association and the Radio Transmission Correction Message, which are used to provide corrections, too, so that we can get better accuracy from our GNSS devices, also known as GPS in the North America. So these messages allow-- improve the accuracy of GPS devices, whether it's in the vehicle or even in smartphone. And then, finally, this is signal status message, which is broadcasted by the signalized intersections to indicate, hey, these are the requests for signal priority preemption that we've received and this is the status of those request messages, signal priority request messages. Here's another example of-- another example requirement. We have a different requirement, 6.7.2, which is called broadcast signal phase and timing message identifier. For this requirement, each RSE shall include a message identifier as part of the signal phase and timing message broadcast. A change in the message identifier indicates a change in the message content. This requirement allows a connected device to ignore or not process messages from an RSE when the content has not changed. So looking at ISO TS 19091, the requirements traceability matrix, again, which we will show later, it defines the SAE J2735 data element message count within the SPaT message to fulfill this requirement. So there is a specific data element within the SPaT message, which will provide a message identifier. Now, if we look directly at the SAE J2735 data element, the message count, it defines the data element as it can be incremented, meaning the message count can be incremented every time a message is broadcasted or when the content of the message change. So the J2735 standard allows that data element to be incremented in either case, whether it's broadcast when-- any time a new message is broadcast or only when the contents in the message change. Both of them are valid, but according to SAE J2735, ISO TS 19091 standardizes that use of the message count for the SPaT automatic messages so it only increment only when the contents change. So now, as a connected device approaches an intersection and it sees a SPaT in that message, if it's conformant to ISO 19091 and it sees the message count increment by one, it knows, oh, guess what? The contents of the SPaT or MAP message has changed. It's not a count of the messages, like, oh, it's incremented every time it gets-- the message gets broadcasted. It's only being incremented when the contents change. So if the message counter hasn't incremented, I know, oh, I received it once, the contents haven't changed, I can ignore it. But if it increments at one, I know, oh, it's because the content's changed. So this is very important because if a vehicle or the device interprets the standard, the SAE J2735 standard, differently, it decreases the risk of misinterpretation, which actually may compromise safety because we were expecting one event when a different event actually occurred.

Patrick Chan: So we've reached another activity. So the question is, how does ISO TS 19091 use SAE J2735 to specify message contents? Your answer choices are A, fulfill requirements based on the ISO 19091 use cases; B, fulfill requirements found in the SAE J2735 standard; C, directly satisfy the user needs derived from the ISO 19091 use cases; and D, directly satisfy user needs in the SAE J2735 standard. The question again is how does ISO TS 19091 use SAE J2735 to specify the message contents?

Patrick Chan: So the correct answer is A, fulfill requirements based on ISO 19091 use cases. So say we use ISO TS 19091 uses SAE J735 to define the messages-- the message content to fulfill the requirements that are in the use cases-- that are derived from the use cases in ISO TS 19091. It is not B because the intent of-- we're focusing on the 19091 use cases and also SAE J2735 does not include requirements. There are no user needs in ISO TS 19091 or SAE J2735. And it is not D because SAE J2735 defines a message set, a data dictionary, but that does not identify user needs.

Patrick Chan: So the next couple of slides, we're going to discuss how to apply ISO TS 19091 standard content to your project. We're going to go in detail how to use the use case to requirements traceability matrix in Annex B and also how to use the requirements traceability matrix in Annex C and what it means to conform to ISO TS 19091. Finally, we will walk through an example of an implementation and show-- demonstrate how to use the two matrices, these two tools, the use case to traceability matrix and the requirements traceability matrix, for your specific implementation. So again, the use case requirements matrix provides traceability from the use cases to the requirements. This is a tool in ISO 19091 to help implementer use the standard. Located in Annex B, the matrix possesses those requirements supported by the standard that may be applicable to satisfy the use cases that an implementation may want to support-- may wish to support. This matrix is important because it helps to ensure that the standard satisfies the information needs described in the use cases. To use the matrix, which we'll show in the next slide, system design must choose the use cases that they wish to support for its implementation of the intersection application and then indicate for each use case if a requirement is mandatory, that means it has to be supported to conform to the standard; optional, meaning it's use is selectable by the implementer to determine if they want to implement that requirement or not; conditional, means that's based on a set of conditions that are defined; not applicable, meaning that that's not applicable for that particular use case; excluded or prohibited, that means it is prohibited for that use case. A regional selection means it applies only for specific regions. Recall that we have profiles for North America, Europe, and Japan. Depending on which region your implementation will be located in, there are additional requirements that might be applicable. And finally, there are some requirements that are internal to the-- if the RSE, roadside equipment, and traffic signal controller are one physical device. This is just to help out. It doesn't involve a data exchange, but it's just to assist the implementer in implementing an application. So this is an example of what the use case to requirements traceability matrix looks like. We show here three use cases, SA2, SA3, and SA4, and by row, we have all the requirements that these use cases may trace to. So for example, for use case SA2, which is red light violation warning, the use case requirements matrix indicates that for the applications or implementations that support this use case, requirement 6.5.1 to 6.5.5, and requirement 6.5.7 to 6.5.10 are mandatory. That means those requirements should be included in your implementation. 6.5.1, being broadcast area geometrics, which mean broadcast the message about the roadway geometry. The next four, be able to broadcast a message identifier. Hey, did the contents of my message change? An identifier for the intersection, a reference point for an intersection, and a default with up the lane or approach to an intersection. Also mandatory are a definition of the approach lanes. What lanes are approaching the intersection? What are the numbers? The center line coordinates, meaning show me where the center line of the lane is and the maneuvers for each lane, what maneuvers are allowed at the intersection for that-- for vehicles in that lane? So for example, is that vehicle in lane-- in a specific lane allowed to go through or is it allowed to make a left turn or is it allowed to make a right turn or even a U-turn? So these requirements are mandatory for the use case SA2, a red light violation. There's also some optional. So 6.5.13 is version identifier. This is the identifier of a road-- the roadway map. So you may have different configurations, different identifiers with different configuration. So let's say if by time of day there's a reverse of a lane, you would assign it a different-- you would assign it a different identifier if that reversible lane is activated. Also optional is the width of each lane in case you want to define a width other than the default width or a null lane, which provides a little bit more detail about widths of a-- for lane widths that are variable. So those are optional. Notice that in green, we also have access. That means for this particular use case, these requirements are not applicable. They are prohibited.

Patrick Chan: The next tool that is provided in the ISO 19091 Standard is the requirements traceability matrix. It provides traceability between the requirements that we've just selected in the use case requirements traceability matrix and the design. It defines the dialog, the sequence of events, sequence of message exchanges, the messages, the data frames, the data elements that are to be exchanged. This traceability-- requirements traceability matrix is used to determine the design of the communications for the system. It also can be used by a tester to determine what requirements need to be verified and to help design those test cases. So looking-- talking a little bit more in detail about the dialogs, for ISO TS 19091, the dialog consists of only broadcast messages, meaning a device broadcast the message content, may be a SPaT message, may be a basic safety message, may be a signal request message, to all entities within the range. So think of a radio broadcast, for example. We send out the message and if you happen to be listening, you get it, you can hear it, but if your radio is turned off, you won't be able to hear it. That's what we mean by a broadcast message. It's sent out to everyone and as long as you're listening at the right channel and you're within range, you're going to get that information. The sequences that messages are to be broadcasted can be found in the use cases. So there might a sequence that messages should be broadcasted. Dialogs are mostly handled by the DSRC communications stack, but might be other wireless communications-- technologies. So for the-- we try in ISO TS 19091. So the focus is on DSRC. It is communications media and neutral. Meanwhile, the message sets, the data frames, and the data elements are defined in the SAE J2735 standard. So this is an example of a requirements traceability matrix. In the RTM, the message column shows which message is being referenced and the following columns after that reference the data elements in-- that are defined in the SAE J2735 to fulfill a requirement. So in this example, requirement 6.5.4, we have a broadcast intersection reference point. So this provides a reference point for every intersection. However, notice that 6.5.4 appears three times. That's because there are three pieces of data that we may want to include because we want to prove the reference point is a three-dimensional position. We may want to include latitude, longitude, and/or elevation. That's why it does appear once-- three times, excuse me. Once for latitude, once for longitude, once for elevation. Moving a little further to the right, because that was just a partial snapshot, we see that providing latitude and longitude is mandatory for this requirement. So if you have a requirement that says we need to broadcast intersection reference point, latitude and longitude are both mandatory. It is, on the other hand, optional to send elevation. So if you're in a flat part of-- in a flat region where there are no overpasses or underpasses or bridges or elevated roadways, then you probably do not need this to support elevation. However, if you are in an area where there are overpasses, then the elevation becomes important and then you may wish to include support for the elevation in your implementation. But for the purposes of this exercise, we're just going to select no, that we do not want to support elevation in our implementation.

Patrick Chan: Skipping some requirements, we also want to show what the performance requirements look like in the RTM. So what's shown here in this slide are some performance requirements in the standard. These performance requirements will-- excuse me. Performance requirements include minimum transmission rate, broadcast roadway geometrics, meaning what's the minimum transmission rate that we're going to broadcast a MAP message at this intersection? So it's-- the conformance is optional and that means it's up to you if you want to define this performance requirement or not. For this exercise, we're going to select yes and then we're going to indicate what-- how well we want to-- how often we-- what the minimum transmission rate will be for broadcasting the MAP message, which in this case, we put down one hertz. That means that we have-- now have a requirement that the MAP message containing the roadway geometrics information will be broadcast at a minimum of one hertz, or once per second. We may also wish to define the maximum transmission rate for broadcasting the MAP message. So we'll select yes and say that the MAP message will not be broadcasted no more than 10 times a second, or 10 hertz. We may also may want to specify a default transmission rate. So for this exercise, we're going to select no and we may also have another-- may also want to define what the minimum transmission rate for GNSS augmentation details, meaning this is the GPS correction details. So we'll select yes, that we want to include the GNSS augmentation detail broadcast and the minimum transmission rate is once per second, or one hertz. So that's how you would complete a requirements traceability matrix. So you could define what requirements for each requirement-- for each functional requirements, how we're going to fulfill that functional requirement and if we also specify performance requirements, how do we want to fulfill those performance requirements?

Patrick Chan: Talking a little bit about regional extensions, as we mentioned, Annexes E, F, G describe different profiles for using SAE J2735 depending on where this standard, ISO TS 19091, is implemented, and actually is Profile A for North America, Annex F for Japan, Annex G is for Europe. So in each of these annexes, we include-- it defines specific requirements for that region so that when you implement it, look at that region. There might be some additional requirements that you may wish to consider for your implementation. As a side note, Annex D includes-- it describes the extension mechanism for SAE J2735, meaning if you have a particular requirement for ISO TS 19091 for your intersection application, but it's not defined in 19091, Annex D describes how you could extend that, what the procedure is for adding or supporting additional features. And again, focusing only on Annex E for North America, Annex E describes some additional use cases requirements and traceability matrix only for the North American implementation. But we look at Annex E, there are no additional requirements defined for the MAP signal request message or status message, but there are two additional requirements specific to the broadcasting, signal phase, and timing message for the SPaT message. It defines two additional optional data elements, data frames and data elements. One is a data element/data frame that indicates if a pedestrian or bicycle call has been requested for a movement at the intersection and, B, there is a requirement that provides support for the current signal state of a special lane, such as a track lane, a trolley lane, or a light rail, for example, at the intersection.

Patrick Chan: Conformance statement. So we're going to talk about what it means to conform with ISO TS 19091. An implementation is considered conformant with ISO TS 19091 when implementation's data content fulfills the mandatory and selected optional requirements as identified in the requirements traceability matrix Annex C or as defined in the selected Annexes. So that means that the data that is exchanged or can be exchanged by your implementation fulfills the mandatory requirements as defined by the standard and the selected optional requirements as defined by your implementation. So you selected several optional requirements for your implementation. That means that data content has to fulfill those optional selected requirements also. Conformance also means it also the message structure must fulfill the requirements of the Annex-- selected annex. So that means if you-- based on the requirements that were mandatory and selected, the message has to fulfill-- all the messages that have been selected and the data frames data elements that were selected has to be consistent with the message structure as defined in SAE J2735, meaning, A, if the message is supposed to contain the elements A, B,C, D, E in that order, then your implementation has to support that message and data elements A, B, C, D, E in that order. And to conform to requirement of this technical specification, a system or device interface shall implement all data elements facing that requirement. So again, whatever data elements are-- or data frames or messages that are expressed in the requirements traceability matrix for the requirements that were selected, you have to implement all those data elements. To be consistent with the requirement, a system or device interface shall be able to fulfill the requirements only using the messages, data frames or data elements that the conforming system or device interface is required to support. So that means if the requirement is to perform function A and the requirement traceability matrix says, A, you shall use data elements 1, 2, 3, and 4, that means your implementation better use data elements 1, 2, 3, and 4 and shall only use data elements 1, 2, 3, and 4 to fulfill that requirement. It can't send a different additional data element to fulfill that requirement.

Patrick Chan: It has to be used-- it can only use those data elements that are specified by the standard.

Patrick Chan: So finally, we're going next, to go through an example of a transit-- of using the use case traceability matrix and requirements traceability matrix. In our example, we're going to use-- assume a transit signal priority application, meaning you want to install a transit signal priority application for your intersection. So first, we're going to go to Annex A and examine the use case table. Again, the use case table in Annex A provides a complete list of all the use cases or applications supported by ISO TS 19091. And we're going to go through the list and select the appropriate use cases that we want to deploy. Focusing on the transitioning of priority use case, we're minimally going to select PR1, priority 1, which is a localized public transport signal priority. There are others that we may also want to select as part of our implementation, for example PR1-a supports a scenario where there is a near stop transit stop, and that means the transit stop is right before the transit-- before the signalized intersection. We may also want to select the next one, which is public transport signal priority, along arterial in case we want to provide arterial progression signal along that transit corridor. But for the purposes of the example, we're just going to focus on PR1-- use case PR1, localized public transport signal priority.

Patrick Chan: So looking at this slide, the key point of this slide is that we should-- when-- once before it's-- selecting it, we should review the use case to make sure that all the conditions are satisfied and that this use case does support what we're looking for. So one of the areas that are things we want to look at is the constraints, make sure that we satisfy all the constraints that are applicable for this use case, and the actors, make sure that we have the correct actors for this particular use case. If it doesn't match up, then we may have to implement it slightly differently, but we at least want to make sure before you use a standard that we satisfy the constraints and/or actors that are detailed in the use case.

Patrick Chan: So once we select the proper use case or use cases, the system developers should go to Annex B, the use case requirements traceability, to determine, okay, for my use case that I have selected, what are the requirements for my application? So this, again, is a partial snapshot, but what's mandatory is 6.1.1. We have to support this requirement to broadcast public safety vehicle information.

Patrick Chan: Then, we look at-- going down, we look at some of the other optional requirements. 6.2 is broadcast emergency response indication, but that one's not-- is prohibited for this use case. But then, we look at 6.2.1, it's optional. Do we want the vehicle to be able to transmit a request, say, hey, I want to be able to transmit a preempt request?

Patrick Chan: And then, we also look at the others to see-- the other requirements. Again, we have to make a selection. Do we want to support these particular requirements also? So we may select yes, let's go ahead and do that. We want to be able to send a message identifier and we also want to be able to send intersection identifier. This is the intersection where I would like to have priority request. Again, 6.1.2 is not applicable for our use case. So we're going to click next. Once we select our requirements, we go to the requirements traceability matrix. Looking at 6.1.1, we see that there are actually two lines for 6.1.1, which is to broadcast public safety vehicle information and we can broadcast the basic safety message or what's known as the cooperative awareness message. The basic safety message is the vehicle information that is used for North America, while the cooperative awareness message is what's used to provide the location of the vehicles in Europe. So since we're focusing on a North American implementation, we'll probably only select the basic safety message. Now, looking at the conformance column, it says that, hey, for this conformance group number four, it is mandatory to select one. That's what the one, the parentheses (1), indicate. We can only select one of these options-- we can only select one of the options to fulfill requirement 6.1.1. So which one do we want to select, either the basic safety message or the cooperative awareness message? Since we're focusing on North America, we're going to select the basic safety message and select yes for this requirement. Because we're only allowed to select one of them, we're going to select-- go ahead and select no for the cooperative awareness message.

Patrick Chan: Filling out the other ones, 6.1.2, which was broadcasting emergency response, which was not a selectable requirement for a particular use case, but let's say for-- there may have been another use case that we want to select where this is allowable. So we can select yes or no. But since we're only focusing on PR1 and this is 6.1.2, requirement 6.1.2 is prohibited, we're just going to go ahead and select no for those two requirements. Continuing down the RTM and skipping a few requirements, we're going to go ahead and select yes for requirement 6.2.5 and 6.2.6, which is to indicate, hey, I want signal priority or signal preempt and are approaching on this lane. This is the lane that I'm approaching the intersection on and we may also want to say-- be able to support this is the lane that I want to exit out the intersection on. So we'll go ahead and select yes to that. We also may want to select yes for the basic vehicle row.

Patrick Chan: If you look at the next two requirements, 6.2.7, we have three rows to support that, which indicates what type of vehicle it is, what kind of vehicle class it is. So we can select all three or we can select only one. We can select none of them. But for our implementation case, we'll assume, hey, yeah. We want to just provide a basic vehicle row, but we're not interested in providing this request sub-row or the importance level. So we'll select no for those two options.

Patrick Chan: And finally, we've reached the performance requirements. So we have 6.14.1 as the maximum transmission rate for sending a signal request message. So we may be interested in that so we'll go ahead and select a value of one hertz (1 Hz) for the maximum transmission rate.

Patrick Chan: We may also want to select a maximum response time, meaning how quickly should the intersection start forming a signal status message back to the vehicle? So we'll put in a value of 100 milliseconds. We may also want to select the minimum transmission rate for the signal status message. So we'll select the value of one hertz. So this is the message that the intersection broadcasts, like, hey, here's the status of all the signal request messages that we receive. And we also may send a minimal transmission period for a signal status message. That means if we receive a signal request message, we'll continue broadcasting the status for a minimum of 10 seconds after we receive the first request.

Patrick Chan: So we reached our final activity. The question is, which matrices allow a system designer to select system requirements based on use cases?

Patrick Chan: Your answer choices are A-- oops.

Patrick Chan: Your answer choices are A, needs to requirements traceability matrix; B, requirements traceability matrix; C, use case to requirements traceability matrix; and D, test case to requirements traceability matrix. So which matrices allow a systems designer to select system requirements based on use cases?

Patrick Chan: The correct answer is the use case to requirements traceability. So the use case requirements traceability-- traces requirements to use cases allows system designers to select the requirements for a particular deployment. The needs to requirements traceability matrices is incorrect because there are really no needs in ISO TS 19091. There are no expressed needs. The requirements traceability matrix only traces requirements to design while the test case to requirements traceability matrix would trace between the requirements and the test case, but there is no such matrix in ISO TS 19091.

Patrick Chan: So we've reached the end of our module. Just to summarize what we've learned in these particular modules, standards are needed to fulfill the communication requirements in a connected vehicle environment, ISO TS 19091 described use cases to demonstrate scenarios addressed by the standard, and the use cases addressed by the ISO TS 19091 standard include signal preemption, signal priority, safety, and mobility sustainability use cases.

Patrick Chan: ISO TS 19091 provides a use case to requirements matrix to assist implementers in selecting the requirements for the desired applications. And finally, ISO TS 19091 describes how connected vehicle applications related to signalized intersections can use messages in SAE J2735 to support the applications. And finally, to achieve interoperability, ISO TS 19091 includes a requirements traceability matrix to show how to implement specific requirements to support desired applications.

Patrick Chan: So we are now completed the connected vehicle curriculum. The first module in this curriculum is the Vehicle-to-Infrastructure ITS Standards for Project Managers, which is module I261. Module I262 talks about Vehicle-to-Vehicle ITS standards for project managers, while this module, CV271, using the ISO TS 19091 Standard to Implement V2I Intersection Applications Introduction.

Patrick Chan: The next course-- the next module in this course is module CV-T160, Connected Vehicles Certification Testing Introduction. Some concepts taught in this module include identifying key elements of the ATC 5201 standard equipment for testing documentation; describing within the context of a system engineering life cycle the role of a test plan and the testing to be undertaken; describing the application of good test documentation for transportation controller equipment based on the ATC 5201 version six standard; and finally, describing the testing of ATC using a sample test documentation.

Patrick Chan: So we'd like to thank you for completing this module. Please use the feedback link below to provide us with your thoughts and comments about the value of this training. So thank you very much for joining us today and have a good day. Okay.

Patrick Chan: Thank you.