Module 43 - CV261
CV261: Vehicle-to-Infrastructure (V2I) ITS Standards for Project Managers
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, director of the ITS Joint Program Office for USDOT and I want to welcome you to our newly redesigned ITS standards training program of which this module is a part. We are pleased to be working with our partner, the Institute of Transportation Engineers, to deliver this new 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 that you will tell colleagues and customers about the latest ITS standards and encourage them to take advantage of the archived version of the 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 web site 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.
Raman Patel, PhD: This module is CV261: Vehicle-to-Infrastructure (V2I) ITS Standards for Project Managers. This is an upgraded module from previously done work on the same topic. Hi. I’m Raman Patel, your instructor for this module today. There are five learning objectives in this module. The first learning objective is to describe connected vehicle or CV environment. Learning objective two is to discuss Vehicle-to-Infrastructure or V2I communications. The third learning objective will deal with the role of standards, pertinent standards that we use for V2I in connected vehicle environment. Learning objective four, we will review certain challenges that has come up, both known and unknown aspects of them, and we will be discussing those for the V2I environment. And the last learning objective is to review current status of the connected vehicle deployments and lessons learned and some of the feedback that we have received from those deployments, and we’ll discuss that.
So the first learning objective is about connected vehicle environment, what it is and how it looks like. Basically, the connected vehicle environment discussion fits into the ARC architecture framework that you are looking at here in this module for CV261, is everything that you use red is—the linkage is in this architecture that we will be discussing. So what does a connected vehicle environment look like? Basically, it starts with the description of the users in a sense, the vehicle-to-everything or V2X. This is terminology that’s now widely known in the industry and we’ll be referring to imply that vehicle-to-infrastructure or V2I, vehicle-to-vehicle, V2V and also vehicle-to-pedestrian, V2P.
So these are the three parts that we will be dealing with in terms of how connected vehicle impacts the users. The second component here is the communications, a mixture of both the remote communication that we’ve been using in NTCIP. For example, connecting Traffic Management Center using different standards and devices in the field.
In today’s module, we will be discussing with local or short-range wireless direct communication, which has the nature of broadcasting in a short-range using wireless messages. And the third component is about CV safety and mobility applications. That’s where devices deploy the applications inside the software and make the processing and everything that’s needed for a CV environment. In terms of dynamic ad-hoc wireless connectivity, there are always—constantly participants are changing, communicate safety applications messages frequently under changing condition, the vehicle speeds are changing, higher speed, lower speed, mixed speeds, whatever the conditions, and there are Doppler shifts in the speeds environment.
And look at this diagram on the right side is a pedestrian walking and is trying to cross. Below that, there’s another diagram that says V2I, which now refers to the highway structure where the wireless connectivity is provided. So this vehicle’s environment, user’s environment, is patient and then that is where the wireless connectivity comes into play, in the city [?] 00:04:00 environment.
We begin our discussion with the Roadside Unit or RSU. It is a device, and here’s a definition provided by NTCIP standard. And basically, it starts with a field device. It is a field device, and it’s heavily used in V2I, so we’ll be focusing quite a bit on these things. This is the full definition that guides us, and basically, the RSU exchanges data among nearby connected devices using wireless connectivity.
What is the primary function of the RSU? Well, basically, it transmits and receives messages, data from the devices nearby. If you look at on the left side, you have OBU, Onboard Unit, which is a portable mobile environment inside the vehicle. And on the right side you have a Roadside Unit, which is a fixed unit. It’s RSU. In between, we see this diagram, little diagram that tells us how the exchanges of messages are occurring by radio operations. So the information is transferred from one device to another as shown here, and other devices as well, using over-the-air kind of broadcasting mechanism.
The other function of the RSU is to provide IPv6 Access to Remote Networks. For example, an OBU may want to contact RSU, connect to RSU, and RSU will allow the connection to Traffic Management Center, which is an external center. So moving vehicles can also access Internet through RSU, so that’s the second function RSU serves. Devices are always configured with a list of application[s]. Every device has something called PSID in its software. PSID stands for Provider Service Identifier. It’s the unique ID provided for each application. That’s how the device recognizes a particular application. And this application processes messages. The process messages in this case, RSU, to the other devices using 5.9 dedicated short-range communication or DSRC as we say it, right? So this kind of implies that the devices are certified to conform applications. So their job is to provide functionality in terms of transferring message from one device to another.
How do devices actually derive that input? Well, that are two inputs going into the applications, which is inside a device, right? First, the vehicle data that’s provided by the vehicle itself and that’s a local-based device—I’m sorry. The data is device-based locally. So latitude, longitude, speed, brake status, turn signal status, all of those data that relate to vehicle are becoming now number one input inside the applications. The second type of input that device actually uses in application process is the infrastructure, information available externally and that information plus the vehicle data and combination, the application then processes any issues or generally is warning for driver, which then driver is actually obliged to take action on.
So the challenges are plenty, and these are the three key challenges we been always concerned about in our business of transportation. These transportation challenges, for example, over 6.5 million crashes a year, a large number of fatalities. And the target—the benefits using connected vehicle application is to reduce the crashes by 20 percent to 80 percent. Similarly, we are also concerned about the mobility, the aspects of reducing congestion 50 percent to 42 percent in general, provide better mobility for disabilities, hampered or users that need some additional information. And then, of course, improve the environment by reducing 10 percent of so the pollutions.
So these are the challenges are being addressed by CV environment. In particular, we also have a technological benefit of vehicle connectivity, which is coming from AV or autonomous vehicle and CV, connect vehicle. The combination of these two types of infrastructure facilities actually allow us to create a wireless connectivity or vehicle connectivity using different infrastructure. And this is an additional benefit in terms of how connected autonomous vehicle environment will emerge and using CV and AV combinations infrastructure facilities.
So understanding the CV environment, it is dynamic. It includes V2X, V2X stands for V-to-everything, short-range communications. We are talking about 300 nominal range sort of, middle range, and then it’s a radio operation. It’s a single hop-short messages.
We build—in summary, let’s just say that we build our ad-hoc wireless network using four steps. First, we look at the ARC-IT framework to develop CV architecture, what it is that we are trying to do through that process. Second, we identify CV applications using systems engineering process, SEP. Third, we bring the combination of devices, which are compliant to standards. And then the last one here listed is the conduct testing and certification process. This is very important, because we want to our devices certified by after testing so that they actually deliver the functionalities required.
Let’s look at the general aspects of how and why it is important. Well, large number[s] of projects have now already been operational, planned 76 here in this slide, if you look at it, and operationally, 67, total 143 projects. And V2I infrastructure actually has over 12,000-plus devices out there in the field. And when you add V2V aspects of this CV environment, OBUs and aftermarket safety devices, ASD, you are now talking about 36,000-plus CV device across the country as of August 2020.
So let’s have our first activity for Learning Objective 1. The question here is, which of the following is not always a part of V2X communication services and not always used, a) Onboard unit, OBU, b) RSU, c) RSE, d) Center to field communications? The correct answer is D. Typically, NTCIP covers center-to-field with remote communications. A is incorrect, because OBU is part of the V2V communication. B is RSU is required for V2I communication and C is RSE is also the incorrect answer, but RSE is part of the V2I communication.
Let’s look at our Learning Objective 2 now. We’ll discuss here what the vehicle-to-infrastructure, or V2I communication looks like, what it is made of. So, communication network in general has three components, roadside equipment, RSE, roadside unit, RSU, and backhaul communication-to-TMC, which is always present. We’ve been using that for a number of years now, connecting TMC with the field devices. So these three components are a major part of the communication network for V2I. And broadcasting over the air is what is taking place between the two devices within normally about 300 meter nominal range. RSE has a similar component in it. The RSU is the radio portion of RSE. RSE has multiple functions, as you have seen this literature probably many times over, and it has communication aspects of it. It has a GPS receiver in it, provides the time, coordinated time, and also has other functionalities such as traffic controller, and they are located within the cabinet. And RSU is the radio portion of that functionality.
Typically, RSE is shown in a cabinet, as we just saw, and RSU is a component that’s generally mounted on the pole outside of the cabinet. So that’s the unit that actually conducts the message transfer between different devices. The backhaul communication is also going through the cabinet. Then you have power supplied to the RSU, which is sometimes—it could be DC, which is an Ethernet type of injector, bringing 48 volts, or it could also be AC in terms of direct electricity provided to the unit. RSU performs radio broadcasting operation. There are several factors. Here we are listing four factors, which are very important in terms of where an RSU should be installed. RSU generally install on available mounting infrastructures. It’s either a pole mounted or a mast/arm mounted or on gantry. These are all available infrastructure pieces out there in the field, and publications generally refers to use what is out the available rather than creating something totally new. Now, it requires line of sight, LOS, both from the pedestrian standpoint as well as the vehicle standpoint. Without the line of sight, RSU will not function properly. Also RSU provides omnidirectional coverage in all different directions, and then it derives its Ethernet—Power over Ethernet or POE cable at the 48 volt DC.
These images that you’re looking at here are actually real-world applications, installed, deployed. They are not theoretical, and height is paramount. Of all of the aspects of installation, perhaps the most important one that we noticed is the RSU, at what height it is installed, because it’s a broadcasting device. And as long as it’s clear and it’s free from interferences, the RSU will function as desired. So V2I communication requirements, the medium, DSRC, dedicated short-range communications. That has been used widely over the years. Also alternatively, LTE or CV2X. This is alternative technology that can also be used in the CV environment as a communication medium. There are standards, there are certain standards that we need to early on recognize that are required for the V2I communication.
Here IEEE 1609 family of standards called WAVE is required for connectivity and 802.11, IEEE 802.11 for DSRC radio operation is also required. So these are the key standards. Then you have devices, RSU and OBU, which are compliant to standards. And then applications, safety mobility type of applications, which are inside the device, which actually process the information and then alerts the driver and provides messages. And then, of course, the security. The security credential management system or SCMS is a major component in the aspects of requirements. So there are four medium standards, devices, messages, and of course the security that goes with it. Dedicated short-range communicate, DSRC, it has a 5.9 GHz spectrum, and this spectrum—and then you use IEEE 1609.x family of standards with 802.11 in combination and the spectrum is now using DSRC in the United States.
The current design, channel design or allocation of channels, is shown here in this slide. So channel SCH, service channel, SCH 172 is a safety channel. It’s reserved for safety operations. Channel 174 and 176 are used for downloading application software. Channel 178 is called CCH, control channel, and it only controls the aspects of how channels are used in this spectrum, so that’s why it’s called control channel. SCH 180 and 182 are two types of downloading/uploading kind of environment. Here, for example, 180 and 182 actually uses uploading facilities, mobility operations, performance logs.
So that kind of operational details can be shared using those two channels. Channel 181 is a combination of 180 and 182. Sometimes we combine two channels to get more bandwidth out of it, so that will be one channel called 181. Similarly, also channel, by the way, 175, SCH 175, is a combination of 174 and 176. The last channel here in this current design is SCH 180, which is reserved for emergency vehicle uses. It uses high-power, and it’s only used for emergency vehicles. The emerging technology LTE-V2X sometimes is also called CV2X and also uses 5.9 spectrum and it’s defined under the 3GPP, third generation partnership project, release 14. It enables independent communication using PC5 interface. Also it provides network services in licensed spectrum band. 1609 WAVE standards are currently being adjusted, and when I say “currently,” meaning that it’s in 2020 August timeframe. The standards are now being revised so that LTE-V2X can also benefit from a use of IEEE 1609 standards.
The most important aspects of methods transfer is the latency. Latency is end-to-end time delay experience in system. For example, 0.1 second. So this is very important, because if latency is not maintained or not properly adhered to by applications, then the messages will not get transferred swiftly and therefore, the driver may not benefit. So latency is an important aspect of how processing is occurring. Both DSRC technology as well as LTE-V2X meet these requirements. So we are okay in terms of latency requirements. Here’s a diagram that U.S. DOT has provided to us that lists all the applications in different categories, V2I safety, V2V safety, agency data, or weather, environment, mobility and other smart roadside devices. This diagram can be used by clicking on one of these blue titles, whichever preference you have. If you’re looking for information on V2I safety, you can click V2I at the top and then you will see all these different applications. Also when you click one of these detailed applications, you will get more detail about that particular application. So we can use this application.
These applications have been time tested. They have been conceptualized. They have been verified and in most cases, they have also been tested in the field so that we can actually use these applications. Let’s look at the example here. For example, SPaT, signal phasing and timing, application data enables more than one application. So if you use one type of data, data that can also find its way in multiple applications. For example, the three applications shown here in the red at the top of the diagram, red light violation warning, pedestrian signalized crosswalk, PSCW, intersection movement, those three applications can also use the data generated by the SPaT application or the SPaT data. And then also, similarly, traveler information and transit signal priority can also derive input through SPaT data and then provide the final service that they’re looking for.
Let’s look at one more example in terms of illustration, how curve speed warning is developed. The curve speed warning is like, okay, so we are approaching a highway segment. We are approaching a location, and we are not aware of what the current condition is and what is the climate or weather type of information is out there. For example, the curve is coming up and driver is not aware of it. So this application will deal with that in terms of where the curve is, and I will be informed ahead. Also the black ice condition. When we get there, it’s too late, when we found out that, “Oh, my God. Where am I,” you know and that reaction on part of the driver is too late. To avoid that situation, this application provides real-time information to driver ahead. So when driver sees this information, when receives this information, the driver will take proper action through two actions. First, it will negotiate. The vehicle is negotiating the curve now safely, right? And then also observe the recommended speed.
So this is the way you can actually use this application to safely navigate or negotiate the curve. In this application, RSZW, work zone-related activities—we have been suffering from this problem for many years now. When we got into the work zone, or we approach the work zone with a higher speed, it’s too late to stop. So the driver gets this warning ahead in terms of real-time alert and then the driver will slow down both in terms of time as well as in terms of distance. So there is appropriate action taken on the part of the driver. This application here about the application—both harmonization for safety and speed and the mobility.
When we have a number of issues at the bottleneck conditions, congestions, and we need to now harmonize the speed so that we can take advantage of the information available through this application ahead. So platooning, for example. When you have a correct speed and everyone is moving at the right speed, proper speed, then you have less chances of rear-end accidents. And this information is available under road condition and that information is transferred to the Traffic Management Center and then driver is now informed with the current conditions. So, for example, bottleneck is 30 percent of our problem in congestion management, so this application is a very effective way of looking at what the current conditions are. Railroad crossing violation is another issue, 281 fatalities in 2018, larger number of crashes. So the driver trying to cross the railroad crossing now is provided the information, proper information in times of arriving or approach train and the driver is now helped in terms of real time information, which then allows the driver to be patient and then let the train pass and that way, the crash can be avoided.
Here is example from Greater Cleveland Regional Transportation Authority, how the pedestrian fatalities can be impacted. The bus driver actually gets the information in real time about the pedestrian activities at the sidewalk and the crosswalk, and then the alerts are issued. Eighty-one percent of the alert issued here were correct alerts, 10 percent incorrect and only 9 percent were false. So with that information available to driver, the driver actually is very effectively taking action, which in this case is 16 percent increase in driving braking response. So that can be helped in trying to bring the number lower. So there are preparation steps that we need to take.
First step here is to make sure that the communication infrastructure is properly laid out, as we discussed earlier, the ad-hoc nature of it. Then we talk about the communication requirements, specifically DSRC 5.9 channel design. Currently, we have DSRC being deployed in the country. When we have alternative medium available such as LTE-V2X PC5, then we will also be able to migrate to the new technology, or collocate both technologies together. So that will be the communication requirement. Of course, there are standards that need to be adhered to for the devices, for both RSUs and the other type of devices for vehicles, OBUs as well, applications, security and testing certifications.
So these key steps are important in terms of realization of V2I communication. Let’s have our second activity. Which of the following is not a V2I application, a) CSW, b) transit signal priority, c) forward collision warning, FCW, and d) railroad crossing violation warning? Okay. The correct answer is C. FCW is a V2V, vehicle-to-vehicle application. It is not a V2I or infrastructure. A is incorrect, because CSW is a V2I application. Similarly, B is also incorrect because TSP is a V2I mobility application, and D also incorrect because it is a V2I application.
Let’s look at now Learning Objective 3. Here we will describe pertinent role played by pertinent standards. So if standard has specific role to perform—and so that’s the environment that requires V2I environment, requires that, that standards play a particular role, and let’s look at that now very closely. So why are standards considered essential? Well, standards support interoperability to maximize benefits. Interoperability is defined as the ability of two or more systems or components to exchange information and use that information that has been exchanged. So the other purpose of the standard to enable agencies to actually comply with V2X devices, which are large number of vendors or large number of devices that all need to work together. So this procurement process the agencies will conduct will also be helped with. So planning stage, system design and procurement are the key areas where standards will help agencies to move the projects in a proper fashion. Also, consistent messages can be constructed using standards.
Because there are multiple applications on devices and different devices have different messages, and a combination of all this mix will require the standardized processes. And short messages delivered. Short messages is the key element of the aspects of CV, connected vehicle, because these messages are single hop and they are delivered in a low latency environment. They are not lengthy messages, and they don’t take that long to deliver.
So let’s look at the types of standards required for V2I communication. The first type of standard that’s required is transmission standards. Transmission standards are required for message exchange. So wireless connectivity begins with transmission standards. That includes IEEE 802.11 DSRC radio operation, which conducts the over-the-air kind of operation. Also, IEEE 1609 family of standards for wireless access in vehicle environments or WAVE, W-A-V-E in short. These are version three 2016 standards, which requires project managers, transportation managers to make sure and sure that these standards are complied with. We are in version 3, and I will repeat that again, because we have been using experimental and trial standards, and now they are no longer in use. We will be using version 3 standards, which are released in 2016. Interface and dictionary standards, which allow us to create messages, and they guide us through the process of how to put the message together, and those standards are SAE J2945 family and SAE J2735 V2X communication message set dictionary. These new standards are also helping us to make sure that we are able to construct messages for all of our needs for V2X communication. The third type of standards we require are the NTCIP standards. There are field devices standards. There’s so many infrastructure-related devices out there, and we’ve been dealing with them through NTCIP process for many years now. And we also have added RSU specification version 4 in 2016. This specification is prepared by U.S. DOT to guide us through the process of putting the DSRC implementation together.
So there are three types of standards as we have discussed, transmission standards for wireless connectivity, interface and dictionary standards for creating messages and managing messages, and field devices and center-to-center communications, which are now required to connect TMC to the to the outside activities. Okay. Let’s look at the 802.11, 2016. It describes specification for wireless connectivity using DSRC services. Media access control or MAC, the messages actually are delivered at the low end of the processing, which is at the physical layer where the actual radio operation takes place. PHY in short is the physical layer, which actually deals with the radio chips and intervening environment in between.
802.11, IEEE 802.11 enables ad-hoc wireless communication using 1609 family of the standards. This combination is what has CV environment enabled. This is a detailed list of 1609 family of standards. 1609.0 is a guide. It has a general discussion in it. It allows us to read the entire platform and how the standards actually work together, and this is in 2019 release standard. 1609.2 deals with the security services. 1609.2.1 is going to add SCMS now. This amendment is available in terms of how and what the standards will allow in terms of security requirements through SCMS, which is the product that’s coming from outside into this family of standards. 1609.3 is the network and transport services. This is where actual protocols are residing, and there are two. Both we will be discussing shortly. 1609.4 is a multichannel operation. As we earlier said that the radio operation takes seven channels, and only one channel can actually be put on the air. So multichannel facilities are now managed through this standard, 1609.4. And the last one here, 1609.12 is identifier allocations. This is the framework for DSCR using all these different standards we just reviewed.
Here in this case, we have—on the right side, we are showing data plane, which actually processes the messages in ISO layers. There are two protocols. WSMP is customized low latency protocols, and it is called WAVE short message. It’s a single hop, WAVE short message protocol. The IPv6 protocol traditionally has been used for many other purposes, which is now being optimized for low latency. So both protocols, WSMP and IPv6, they are both side-by-side residing in the data plane. At the lower layers, you have 802.11, which is the DSRC type of operation, and then we will be also adding PC5 LTE-V2X also working at the lower layers. So that will allow us to process messages from the higher layer to the physical layer radio operation. To the left of this, we are showing management plane, which is outside of the data plane, which actually supports the data plane activities. And similarly, security services are also conducted through 1609.2, which is also part of the process, but it’s also outside of the data plane. So as I said earlier, 1609.3 is currently in revision, and when I say “currently,” it means August of 2020. And this revision is now being under progress, and it will add PC5 interface capability. So when this release is made, both LTE-V2X and DSRC protocols can work together at the lower layers.
The standards in terms of interface and dictionary standards has been revised. Also, they’re updated. J2945 provides engineering guidance. 2945/3 sets out the requirements for weather applications, and there are also practices issued as listed here, J2945/2 and J2945/9 for vulnerable road users. These are updated in 2017, and they are quite a detailed description of what they are providing for, that they provide for. J2945 family sets performance requirements. It actually guides us in terms of management, facilities, security, provides specific applications, and it defines use cases. Performance, what is to be done, where, what, how, how often a message has to take place, all these different details. For example, safety message, basic safety message, BSM, must be transferred ten times per second, right? Those kind of requirements are set by this particular standard.
Minimum quality requirements are also listed here, and then security requirements, dialogs and data, and then RTM, which is the requirements traceability matrix. These are part of the 2945 family of standards. 2735, J2735 is actually providing us message set dictionary specifies. Three different things in it, data elements, which are the basic primitive object such as speed. Several data elements coming together form a data frame. Then several data frames plus the data elements actually forms the data, together forms the message. So this combination of data elements, data frames and messages help us to create messages. BSM, for example, has two parts. In part one of BSM, the data elements or co-elements for safety applications, which are transferred frequently or broadcasted frequently are listed. For example, speed data is ten times per second. So that is part one.
Part two has additional data available, data elements, which will work with part one, but they are less frequently transferred. They are not transferred ten times per second, less frequently. For example, windshield wipers status you don’t need ten times per second, right, so that will be coming from part two of BSM. These examples here, J2735 messages for CV applications. They’re listed as 16 to 17 of them listed here, and they are part of that SPaT, for example, signal phase and timing message, we listed earlier. Also, we talked about before in terms of MAP, intersection collision, ICA. These are generally available for applications. There is another standard also in terms of field devices is NTCIP 1202. Here shown is the broader scope of what it contains, what it actually accomplishes.
So NTCIP 1202 version 3, which is now a traffic controller or ASC standard, actually connects to the roadside unit, RSU as is shown here in red. This connection allows the ASC to communicate to the roadside unit. And then at the bottom, on the right bottom, we are showing the CV environment, how RSU actually handles data processing, or message processing actually, within RSU and the other types of devices. The cabinet shown in the center is a signal cabinet. It is traditionally located in the field at the corner of the intersection or nearby, and this cabinet actually houses signal as well as other equipment that are supporting this whole interface. RSU specification version 4.1 issued in 2016 by the U.S. DOT lists actually several things, and it prepares us by providing requirements for power requirements, environmental, physical, functional, behavior, performance, and general interface. And it sets minimum requirements for RSU. This is a practice. It’s not a standard, but it is the specification guidance that DOT (Department of Transportation) prepared early so that we can begin to implement certain aspects of CV environment.
The CV environment or V2X communication, if you want to look at it that way, is through the air interface. The air interface is now used by RSU for V2I, OBU for V2V, and also OBU-to-OBU V2V communication. So both V2I communication and V2V communication is taking place through air interface using WAVE and IP protocols as shown in this diagram.
So let’s have our activity for this Learning Objective. Which of the following standard is not directly related to DSRC V2I communication, but can be used, can be used, a) 1609 family WAVE, b) J2735 V2X, c) NTCIP 1202 version 3 ASC and last one, d) IEEE 802.11? So the correct answer is C. It is part of NTCIP application. NTCIP 1202 version 3 is part of the NTCIP application standards, not a V2I wireless connectivity. A is incorrect answer because 1609 family is the standard that is required for connectivity. B is Basic Safety Messages are supported by V2X J2735 dictionary. And last one here is incorrect, D is also incorrect, because it supports the physical layer medium where the radio operation is taking place for DSRC.
Let’s look at Learning Objective 4. Here we have challenges out there in the V2I environment realization. So we will review some of these challenges that are known to us. Let’s begin our discussion with this case study from Ohio Statewide Architecture, CV Architecture. So how did they start this project? What is the project level activity that we need to first implement or start with? Well, project level requires us to set the goals and objectives identified for the concept of operations, right? We require to answer this early on and figure out whether it’s a regional project, it’s a 10 intersection, it’s going to be 15 intersections, it’s going to be ten kilometers or this or that, corridor. All of those things in terms of what the project entails is going to be sorted out. Then you have coverage area, as I just mentioned briefly, that the project level activities will also specifically now look at V2I location for RSU, where the RSUs are going to be located.
So, it’s highways, ramp metering is involved or is that transit signal priority, TSP, in that case, the outside involved. So, all of that coverage in terms of where RSUs will be located will be discussed at the second step, the first step as in this case. User need-based V2I applications. There are many, many applications that are out there, and we will have to actually prioritize them and check them and what are needed. And we have to use system engineering process to figure out that part, so that concept of operation will help us to do that. And then, of course, project specification, MPO regional planning issues, multiple stakeholders, all of those things will also come up at the project level. Let’s look at this example from Ohio Statewide Architecture case study, see what they’ve done. So this framework is adopted from the ARC-IT framework to begin with the guidance. And then you look at the connected vehicle equipment. This is a component that ha[s] to be dealt with in V2I environment. So V2I component includes those devices out there, as well as the short-range communication taking place between the devices, field equipment, and the vehicles and the infrastructure. All of those things are a combination of activities that entails how actually we start the CV project.
Applications are coming from the user needs, user needs, and where the applications are coming. We discussed earlier U.S. DOT has provided a long list of applications, time tested and conceptualized and everything. Here in terms of project, where do we begin? Our project level of work begins with identifying applications. There are so many of them. In this case of Ohio DOT, they have actually 109 applications. So they need to be sorted out in terms of what are the need-based, what are the project-based, what are the future requirements, and then prioritize them. Once you prioritize them, then it becomes part of the project, actual CV project, and then that will take shape in terms of deployment.
Data ownership and privacy is another challenge that has been identified in many ways. We need to limit our distribution of sensitive data. Every agency has a concern about where data is going, who is using it, how it’s being used. Is it going to land in the private sector hands? So all of those issues are early on discussion points and which needs to be answered in terms of what happens to the data and what happens to the privacy of the data as well. Anonymity, it’s my data, and then I only know how to use it properly, will other people adhere to, all of those things also become now a concern. And then you don’t want whose data is it also be known in terms of general usage in the network. So allow personal information when needed, but not in general sense. Data management requirements partnership. This is another channel that we look at. We have been used to dealing with this issue in the ITS deployment over now a number of years, so we know how TMC backhaul processing is taking place, where the data is coming from, who produces the data, how do we collect the data, how do we share the data, how do we interact with different agencies. So this example for data management activities, here is a bus, transit bus, which is owned and operated by Transit Authority. The traffic signal shown in the middle is now a traffic management function, another agency is involved. And then there may be a third or fourth jurisdiction that may be involved in terms of ownership.
So what happens to data and how the data is shared and what kind of management is required among partnership requirements and different uses? So for example, a transit bus has to make a request to receive SPaT data, right? The data is coming from traffic signal, which is another agency. Transit agency is requesting data from another agency. So that kind of management we’ll have to make up early in the project level. And then we begin to realize the benefits once the partnership is in place. So TSP, SRM, these are all the terminologies that we have discussed here, are very, very real and practical in terms of how data management is taking place. There are key areas and technical challenges listed here in one place. So WAVE and SAE standards are evolving. They are new. WAVE standards are in version 3. SAE standards have been revised also. So we have to know that the standards themselves are being updated and revised and modified to make sure that they are properly developed so that the deployment can be enabled in the proper way, right? So that’s one thing.
The second thing is the communication technology. We’ve been talking about DSRC primarily because DSRC is used in the United States, and we are also aware of it and multiple uses of it, but then there is also the LTE-V2X, another technology that’s coming up, right? These technologies: can I start my project with DSRC, and can I migrate to LTE-V2X, or vice versa, or can I have both? Can I have both on the same spectrum, 5.9 GHz? So that’s a kind of challenge, right? So that channel is out there, and we will have to deal with that. System integration issues, interoperability. We mentioned that interoperability is the ability of different devices working together, right, harmoniously. So that kind of requirement is very important in the integration process. Security, SCMS implementation. Luckily, there is a 1609.2.1 amendment, which will provide us the ability to import SCMS activities inside the standard, and it will be more prescriptive in nature. NTCIP 1202 version 3.0 will allow us to handle the intersection-related management. So that’s under aspects of challenge that we have. And then DSRC radio operation software updates.
We want to make updates to different software being released. Can we do that? Do we have to go to every different device, or can we remotely do it? That’s the challenge that we have to address. Testing and certification. Test, test, test. You cannot certify a device unless you test, right? And you will not know whether your device is compliant to standards unless you certify it, someone certifies it. And that kind of requirement is also a challenge. The area here, last one listed, V2I security challenges, RSU. RSU version 4 requires SNMP version 3, requires that 4.1 comply with SNMP standards version 3. Well, SNMP 1202.2, 1202 ASC actually uses SNMP version 1, which is old and in most cases, it’s outdated. So now how do we handle that? So this a work in progress. We need version three, but we don’t have it in 1202, in the NTCIP-ASC 1202. So that’s the challenge. We are working on it. The community is working on it, but we have to be aware of this channel—challenge actually and be aware of it and then be able to deal with it.
This technical challenge, for example, can we update applications using all over the air applications approach? Can we actually do this software update without having to go through the device locations? There are a large number of devices out there, as I mentioned earlier, some 36,000 devices. Do we have to go to each one of them, or can we just use the process of channel design and then make use of one of the channels? Here is the case. For example, we can use channel SCH 174 or SCH 176 or a combination of both, SCH 175, if we require a large data transfer, right? The idea is to use 175, because it gives you double the bandwidth. So in that case, we can transfer the software updates very quickly and lively and faster using channel 175. So, yes, this is a challenge, but it is and can be actually addressed in this manner.
Application and interactions between different applications is also an issue. As I mentioned, there are multiple applications out there in CV, and then different devices still have to deal with this issue. So these challenges need to be address[ed] in terms of software updates. Testing, testing, testing. Okay. If you test your device that you get from multiple vendors, and if they work properly with each other, then you’ve got a very good start. Here is an example from Florida DOT. They had ten vendors that participated in equipment, right? Now here’s the test set up that’s shown on the left. You have controller testings, and you have all kind of electronic equipment out there, and the traffic devices. Together, they’ve been tested. So if you test and answer these three questions: What will be tested, how it will be tested, and by who? When we answer these three questions in a basic way, we will be in a good starting point. We will be at a good starting point to make sure that our devices are interoperable. What will be tested, how it will be tested and by who?
So this case study has provided us a lot of good input. Certification requirements. You need to test, then certification will come. So certification is to conforming to the standards. It is dependent on conforming to the standard. Each standard should have conformance clause, and then standard should be also version, as I said, version 3 for WAVE is very important. So these aspects of current standards, meaning it is standards. We have to make sure that they comply, the devices comply and conform to in terms of that. So compliance is to the FCC regulations, legal requirements, whether the device is compliant to what the FCC’s expected regulations are and requires legal requirements. Performance testing. Did the device work? As simple as that. Did the device provide the data exchange function? Did the RSU actually allow us to make IPv6 connection to TMC, right? Those kind of examples help us—tell us actually that performance testing is very important, because the applications will have to be tested again and again and again. And the security certificate will be only issued if the device is certified. The security certificate will be required for the operational requirements and that will only come if the devices are tested and then certified.
There are several training modules that are helping us to understand what testing entails. CV-T160 actually is allowing us to understand what the basic connected vehicle testing process looks like. T101, general introduction. T201 has detailed information about how to write a test plan. So, actually, it’s hands-on type of activity is explained in that module. And T202 provides us the test cases, specifications and procedures. So these four testing modules will allow you to gain all the knowledge that you need and tools that you need to understand, to prepare a good testing scenario for a CV project. Let’s summarize now certain implementation issues and bring everything together in one place.
So stakeholders. Let’s begin with the stakeholders. CV, connected vehicle, public agencies. Who are the designers? Who are the OEM (original equipment manufacturers)? Aftermarket safety devices vendors, developers, application standards, testing engineers, certification group, academic researchers. Also, the vehicle fleet owners. These are all the stakeholders in CV environment, whether it’s V2I or V2V. These stakeholders have a prominent role to play, and the issues that come to the table includes data exchange support. You will require support for ITS information. You will require support for SPaT, MAP, BSM, basic safety messages, right? So that has to be ironed out. Also, the standards and interoperability. I’m listing the standards here again to make sure that we understand the nature of this interoperability. IEEE 802.11 is a radio operation. 1609.5 connectivity standards. J2735, data dictionary for messages. RSU version 4.1, specification, basic listing of requirements. And 1202, NTCIP 1202 has all the interface requirements that needs to be understood. So we have support for all those things. That has to be understood as implementation issues.
And then also we need support for WAVE protocol version 3 and then IPv4. And then both of these protocols are also working together in the sense of latency. Security, SCMS version 2.1, 2.0 sorry, also needed to be incorporated in the requirements.
Let’s have our third activity here. Which of the following is not a technical challenge, a) testing for conformance to standards, b) certification and interoperability testing of devices, c) over the air firmware or software upgrades for devices, and last one, d) data ownership? Okay. The correct answer is D. Generally, an institutional challenge addressed by the project management. Data ownership is an institutional challenge. A is incorrect. It’s a technical challenge, testing and conformance, because we have to ensure the conformance to the standards. So, it is a technical challenge. B is also a technical challenge, because interoperability and certification requirements. And C is also incorrect, because software updates are actually addressed. This is one technical challenge that has been easily addressed.
Let’s look [at] our Learning Objective 5, the last one. Here we will review the current status of what is happening and what we can learn from the deployments and lessons learned and help us in our projects. This map from Volpe here, U.S. DOT map, as of August 17, 2020, the number of applications that are out there for V2I, and I listed—we have seen them in here. I listed several of them earlier. And the SPaT, for example, in orange, are nearly everywhere. And these applications are helping us to understand the nature of V2I deployments. Several examples will make it clear to us.
For example, here, snowplow signal priority, SPSP application from Minnesota DOT. Let’s look at how the SPaT type of data is helping this application to provide good information that these snowplow operators require. In this case, it provides the ability to request extended green time. You go along this traffic corridor, a number of intersections out there on this map here shown on the left side, and you can actually understand that a snowplow machine, which is a very large size, very cumbersome big machine, not easy to maneuver, and it cannot be stopped at every intersection. It’s very hard. So one thing is that if you make the vehicle stop every intersection, the disruption will cause a problem more so than trying to solve the problem. In other words, the snowplow operation at signalized intersection will be not uniform. The chemical they disperse will not be uniform. So the snow removal process will be hampered in many ways.
To eliminate that issue and problem, we are now actually allowing the snowplow machine to make a request for a SPaT or TSP, signal-phasing change, or green time, additional green time, or extended green time as the machine arrives, the vehicle arrives at the location. So this application is really very helpful in terms of completing the snow removal in an even manner, okay? So it actually addresses a challenge, which is a real one.
Look at the Wyoming pilot, for example. Seventy-five RSUs are installed along I-80, right? Also, a large number of vehicles in general are targeted. So what do we learn from this application that they have under this CV pilot? Well, the noteworthy observation is that Wyoming DOT’s systems engineering process is now being leveraged by CDOT, Colorado DOT. They’re saying what worked in the environment? What not work? How did they handle issues? What was the problem, and how did they resolve it? All of that knowledge is built into systems engineering’s concept operation and all other things. These documents are available and Colorado DOT is making use of that, a neighboring state using information produced by another state nearby, so that’s a very noteworthy observation in terms of how deployments are helping us.
Here we go with the similar example from Tampa, Florida. In this case, also RSUs are 47, large number of RSUs are out there. What is a noteworthy observation here in Florida? The environment is different, right? We just looked at the snow operation in Minneapolis, and now we look at the different type of weather in Florida. Here we are learning from this deployment what the problem they had. The four of the RSUs of the 47 RSUs did not actually perform. And the pilots found that four of these 44 RSUs were not communicating. And when one RSU doesn’t communicate, you have a problem. So the next question is then, what really caused that problem, and how did they solve it? Well, the problem was that the RSUs were not properly grounded. So, in lightning conditions, the RSUs get damaged. And Florida is the environment where lightning is plentiful. In that situation, we learn how to ground properly the RSU. And as I mentioned earlier, RSU is not a high-powered device. It’s a very low-power RF energy and it is very easy to suppress. So that kind of environment is now being dealt with. So we learned that RSU must be properly grounded.
Turn to New York, large number of applications of RSU, 447 RSUs installed out of 450, 3,000 vehicles targeted, large size, urban environment, grid systems, how the RSUs are located, which direction. What about the condition of wind? Will the wind bring the RSU down, this and that, right? That’s one type of problem. The other type of problem is can we make the software upgrade? So that’s a noteworthy observation. Can we verify, or can we use over the air firmware updates using DSRC channel? The answer is yes. They have done that, and they have actually advised us that this can be done. So we learn from a large deployment that such facilities can be created while we design a CV project. U.S. DOT has also tested interoperability aspects of all these different vendors coming together with different devices. So all the CV pilots of Florida, Wyoming, New York City, all these pilots have been—they have different devices coming from different vendors, and these devices have been tested for harmonization, communication, data formats, coding, channel loading, messages, and protocols.
So this interoperability requirement was tested by U.S. DOT and we have learned from these applications that they work together through the devices procured from different vendors. And this report on the right side here is a test report that tells us what has happened and what we can learn. So the report says, what have we tested? Well, answers that question. So V2V communication, V2I communication has been tested and working. Interoperability tested, working. Over the air broadcast messages, BSM, SPaT, different messages going from one device to another in a proper way, is that being tested? The answer is yes. So this report is providing us valuable information, what has worked, what has not even been discussed yet, or there are certain aspects of different devices will also provide more insight into the operation as it relates to the interoperability.
What is not tested is the performance. If you’re interested in performance testing, then you need to contact each different device vendor, or each different project and then get more information from those people. But interoperability testing has not tested performance. Best practices. What worked? What didn’t work? Particularly for the V2I RSU, this report issued in May of 2020 outlines the number of issues, 32 case report, provides us very good information. It deals with procurement, installation, testing, and standards. For example, there two examples here cited. Let’s look at one.
Procurement 12: Reduce risk by selecting multiple suppliers. The report is advising us that if you want to make sure that—particularly for your large size operations and projects, you will better serve if you look for devices from different vendors or multiple vendors. At the design level, RSU, continue to broadcast through the minimum disruption and jamming activity. This caught my eyes as well because in a certain way, the RSU is a low-power device, and if another device passing by, nearby at that location can easily suppress and jam the RSU operation. How do we get over that? Well, this report is advising us to make sure that you tell your vendor that device must continue to work while it is under attack, okay, until the device is now free from attack. So that kind of requirement is good.
There are many, many other issues that are practical in nature, and this is a very good report that I recommend that you get hands on. Hold off on and the put your hands on it, and then study different issues. Also, RSU is for V2V, V2I, sorry, and there is OBU report as well at the same link. That is available for V2V operations. So you might as well download those two reports and study and see what worked and what didn’t work. Resources for training are located at this pcb.its.dot website. All of these modules are available for you to access and make use of them. CV261 module, CV262 V2V, 265 IEEE 1609 family of standards which has a WAVE discussion in it, and there are others listed here, includes Transit 11, for example, which is for transit managers. How do you deploy CV application for transit side of the business that we are in? How do we deploy transit signal priority? If this is one of your projects, then you will be also guided by certain knowledge that’s in that module. There are two reports that are worth looking at. The one on the left here is an overview of U.S. DOT, roadside unit research activities in general. The one on the right here, V2I safety applications, which has a concept of operation. I recommend that this particular report, that you can consult and get a lot of good information and both of these reports will help you to put you project together.
Our last activity. Which of the following is not a true statement, a) testing has shown that interoperability is achievable, b) V2I applications such as TSP are successfully deployed, c) DSRC is a reliable communication medium, and last one, d) performance testing is completed during CV pilots? Okay. Let’s look at the correct answer is D. Performance test was left to agencies, not performed by the CV pilots. A is incorrect, because devices and systems are tested and found to be interoperable. B is incorrect also because TSP application is widely implemented, as you saw on that map. And C is also incorrect, because DSRC has been successfully used in U.S. for both V2V and V2I communications. Also, if you use the up and coming or other aspects of LTE-V2X that will be also falling the similar case.
So let’s summarize the module. In Learning Objective 1, we described the connected vehicle environment. Learning Objective 2, we discussed what the communication, V2I environment entails. In Learning Objective 3, we discussed particular standards and the role they play in the V2I environment. In Learning Objective 4, we addressed challenges known and also we hint at certain unknown issues that may be coming in a V2I environment. And the last one, we reviewed what is working, what is not working, what are the lessons to be learned from deployments around the country in a CV environment.
We have now completed V2X curriculum. We completed CV261 here today, V2I; CV262, vehicle-to-vehicle, ITS standards for project managers; CV263, roadside RSU requirements; CV265, introduction to IEEE 1609 family of standards, and the last one here listed, T160, connected vehicle certification and testing and introduction. Thank you for attending.