Module 43 - I261

I261: 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, the director of the U.S. Department of Transportation's Intelligent 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 that 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.pcb.its.dot.gov. 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.

Narrator: Throughout the presentation, this activity slide will appear, indicating there is a multiple choice pop quiz following this slide. You will use your computer mouse to select your answer. There is only one correct answer. Selecting the Submit button will record your answer, and the Clear button will remove your answer if you wish to select another answer. You will receive instant feedback on your answer choice.

This module is I261: Vehicle-to-Infrastructure ITS Standards for Project Managers.

Your instructor, Patrick Chan, has 23 years of ITS experience, including four years as an ITS project manager with a public agency. Specifically, he has applied the system engineering process to numerous NTCIP data dictionary standards, the ITE and AASHTO Traffic Management Data Dictionary, a center-to-center standard, and to SAE J3067, which is a comment to SAE 2735, the dedicated short-range communications message set dictionary, the data dictionary for connected vehicles with system engineering content.

Patrick Chan: First I'd like to acknowledge Jim Misener, who is the chair of the SAE DSRC technical committee, and Tom Kurihara, who is the chair of the IEEE 1609 working group, as coauthors to this module. They've contributed greatly to the development of this module and can be considered coauthors.

Although the course is available to all stakeholders and interested parties, the materials in this module are geared toward public sector managers who are interested in deploying a connected vehicle environment, to understand what transportation problems vehicle-to-infrastructure might address, and how to leverage connected vehicles and support a local policy and operational objectives, to procurement officials, who may include specification writers, who are responsible for specifying and implementing ITS systems. The course will help them understand what standards can help design an implementation that will address some of their transportation problems. Next, decision makers who are looking to better understand how V2I might address some of the transportation problems they are facing, how it may impact the transportation system, and how they do business. And finally, for public and private sector users who may benefit from a vehicle-to-infrastructure environment, and manufacturers who are interested in providing hardware and software systems that will enable V2I.

Module I101 is an introductory module that provides an overview of ITS standards, and it's highly recommended that participants who are not familiar with ITS standards take this module first, because this course builds on the concepts that we're taught in this I101 module. Note that this module is not intended to be an introduction to connected vehicles, although a brief overview is provided. USDOT has developed a CV101 and a CV102 module that provides a more complete introduction to connected vehicles, so it's recommended that participants who are not familiar with the connected vehicle environment take those modules first. These modules can be found on the same Professional Capacity Building website as this module.

The focus of this module is on the standards that support the connected vehicle environment, specifically for V2I environment. However, at the end of this module, and in the Student Supplement, we'll provide a list of some resources if the participant is interested in a more thorough introduction to connected vehicles and to the connected vehicle standards. This slide is just a graphical representation that is suggested that the participant view module I101 on ITS standards before completing this course.

Next, this is the learning objectives. Upon completing this course, the participants should be able to, one, describe the connected vehicle environment; two, discuss what the vehicle-to-infrastructure environment is; three, describe the roles of ITS standards in a connected vehicle environment; four, identify and address some high-level technical and institutional challenges to deploying a V2I environment; and five, describe the current status of the connected vehicle environment.

Learning objective number 1. The next several slides will briefly introduce what the connected vehicle environment is. We'll also list some of the benefits of a V2I connected vehicle environment. So, what are some of the transportation challenges that transportation agencies face today? Well, one is in the area of safety. There were over 33 thousand highway deaths in the year 2012, over 5.6 million crashes in 2012, and these crashes were the leading cause of death for people of ages 4, and 11 to 27. Another is mobility. There's over 5.5 billion hours of travel delay at an economic cost of 121 billion dollars of urban congestion every year. And finally, environment. Over 2.9 billion gallons of wasted fuel and 56 billion pounds of additional carbon dioxide is emitted by vehicles due to congestion.

So, let's talk a little bit more about the vehicles. A vehicle today is more than just a vehicle. It's a complex network with many sensors and processors. These sensors can help your vehicle adapt to an environment for a more safe and comfortable ride. For example, there are rain sensors to automatically adjust your windshield wipers based on how much rain it senses. There's slipper sensors for traction control, automatically turn on your traction control system if it determines that the vehicle is slipping, and lane departure warnings to warn the driver, "Hey, you're possibly leaving the lane, so you should straighten up your vehicle." The vehicle is also a navigation device, providing directions to your destination based on your current location. It's also a multimedia center, providing driver assistance and location services and providing media, such as radio entertainment, and connections for your smartphone.

In addition, millions of people around the world carry smartphones today that know where you are and can be used to access data. So based on these vehicles and your smartphones, what if vehicles can share this sensor information and the current position with other vehicles in the roadway? Also, what if that same vehicle can receive information from the roadway and other vehicles that provide information to the driver that might reduce the likelihood of incidents and can improve mobility by suggesting alternate routes, for example? What would such a scenario look like? It could improve roadway safety as vehicles are more aware of each other's position and where they are going. It also can provide warnings to drivers so that incidents can be avoided. This message can be sent. This vehicle data can be sent through some kind of wireless communications, or exchanged through wireless communications. Infrastructure can also provide information to the drivers about signal timing, when is a traffic signal going to turn yellow, for example; or broadcast advisory information or travel information. All this wireless exchange of transportation information can lead to improved safety, mobility, and an improved environment.

This is what the USDOT has termed a connected vehicle environment. It's really a research program led by USDOT to investigate how transportation connectivity can potentially enable applications so that we can improve the transportation system overall in the areas of safety, of mobility, and environment. Transportation connectivity can take place between vehicles to enable crash prevention, for example, between a vehicle and infrastructure, to enable additional safety and mobility and environmental benefits, and also among vehicles, infrastructure and wireless devices such as a smartphone to provide continuous, real-time connectivity. Right now the smartphone, we haven't tested it much, but it is being explored.

A visualization of all these components, between centers and devices and the roadway and the flows between these devices for the connected vehicle environment has been identified by USDOT and can be found in something called the Connected Vehicle Reference Implementation Architecture, and here's the link for that. We'll discuss a little bit more about the Connected Vehicle Reference Implementation Architecture, or CVRA, later in the module.

So, what's driving this connected vehicle environment? Back in August 2014, NHTSA, the National Highway Traffic Safety Administration, released an Advance Notice of Proposed Rulemaking, indicating their intent to create a new federal motor vehicle standard to require vehicle-to-vehicle communication capability for light vehicles; that is, passenger cars. This Advance Notice of Proposed Rulemaking also included a research report that concluded that a fully mature V2V system alone could potentially address 79 percent of all vehicle crashes, and that a vehicle-to-vehicle and vehicle-to-infrastructure capability concurrently can potentially address 81 percent of all crash types. So, the rulemaking for requiring vehicle-to-vehicle communications is expected to be released in the year 2016. So this would be for future vehicles that are manufactured.

In addition to the safety benefits; the ability to reduce crashes, for example, the connected vehicle environment has the potential to address mobility challenges, such as nonrecurring congestion, and also environmental challenges by increasing fuel efficiency and reducing recurrent congestion.

So what is it that transportation managers need to know more about the connected vehicle environment? Well, the connected vehicle environment, because of the rulemaking, is expected to become part of the transportation system which managers will have to face and understand. With transportation connectivity, a new class of vehicles will arrive on the highway and streets that the transportation managers own. Faster-moving, connected, and possibly autonomous. Transportation managers will need to adapt to these changes that may result because of the vehicle technology and transportation connectivity. This may impact our engineering analysis on the roadway geometry and how we manage traffic. So if the vehicle-to-vehicle connectivity is required, infrastructure owner-operators will have to realize that this environment will open the gates for other, what we term, V2X—V2-vehicle, vehicle-to-infrastructure, and vehicle-to-pedestrians via smartphones. So V2V is just the first and very important step.

So, this module will focus on the standards that will support the V2I connected vehicle environment. There's a sister module, I262, that focuses on the V2V, vehicle-to-vehicle aspects of the connected vehicle environment. This module will introduce the standards that will support the V2I environment. By knowing what standards exist or are being developed, project managers can begin deploying projects that will support and take advantage of the V2I environment to realize its benefits. As the connected vehicle environment is an ongoing research program, the materials, future dates, and activities in this module are as of June 2015.

So, what are the safety benefits of a V2I environment? First, infrastructure can use information from a vehicle to determine potential hazards, provided that it's an infrastructure: ice patches, based on poor vehicle grip, poor visibility through vehicles turning on their headlights, or heavy rain due to fast windshield wipes. Incidents and obstacles are another possibly: Airbags being deployed, sudden braking or sudden swerves. In return, information is provided from the infrastructure back to the vehicle, increasing awareness of situations that may not be readily visible to the vehicle operator, such as roadway hazards, icy patches, vehicles stopped in the roadway ahead of them that the vehicle operator may not be able to see. With the increased situational awareness, software systems in the vehicle have the potential to reduce the severity of crashes or incidents, or possibly eliminate crashes, by enabling the vehicles to inform the drivers through driver advisories, driver warnings, or vehicle controls. So it's not limited to crashes either. It might also reduce incidents such as events that may take the vehicle off-road, or rollovers, for example.

The vehicle-to-infrastructure environment can also yield mobility benefits. So, for example, the infrastructure can use information from a vehicle to provide transportation agencies with dramatically improved real-time traffic, transit, and parking data, providing this information so managers can manage their transportation systems for maximum efficiency and to minimize congestion. It can improve incident response, such as when vehicles automatically just broadcasts when it is disabled. That broadcast can be picked up by other vehicles or by the infrastructure. The infrastructure can then use this information from vehicles to determine roadway demand: Where is the vehicle? Where is the vehicle going? Is traffic moving well, or is it stop and go? So this increased information allows managers to better manage their congestion by providing real-time information. In return, the infrastructure, the transportation agencies, can provide focused, relevant information to travelers, such as, "Here are alternate routes," or even modes of transportation in hopes of reducing delay and travel times, waystations or credentialing information for commercial vehicles, or transit information only to transit vehicles. By focusing we mean information specific to the vehicle based on perhaps the direction of travel the vehicle is moving, where the vehicle is, the type of vehicle, and its status.

The vehicle-to-infrastructure environment can also yield environmental benefits. Note that we're talking about there's two types of environments: environmental impacts for regional area and the vehicle-centric environment; that means around the vehicle itself. So tailpipe emissions from vehicles are the highest single human-made source of carbon dioxide, nitrogen oxide, and methane. So vehicles that are stationary, idling, and traveling in stop-and-go patterns due to congestion emit more greenhouse gases than those traveling in free-flow conditions. So by improving the mobility, we actually also end up improving the environment and mitigating the amount of emissions emitted by a vehicle. So infrastructure can also provide vehicle operators and system users with green transportation alternative options, thus reducing the environmental impacts of each trip. Drivers can receive suggested travel speeds so moving vehicles do not need to stop through signalized intersections, reducing delays, which reduce in braking, which leads to reduced emissions and improved gas mileage.

So we've reached our first activity. These activities, again, are just to reinforce what we've learned in the previous slides. Our first activity is a poll. Which of the following is not a method to reduce crashes in a vehicle-to-infrastructure environment? Through a website—that's A; b) through driver warnings; c) through infrastructure controls; or d) through vehicle controls. Which of the following is not a method to reduce crashes in a vehicle-to-infrastructure environment? So the correct answer is A. While information on a website may be safety related and maybe provide warnings about unsafe conditions, it does not do so for a driver's or vehicle's specific location and conditions, and doesn't do it in a timely manner. Driver warnings, on the other hand, are based on the current location and heading of the vehicle, are based on information from the infrastructure or from the vehicle's own sensors. Infrastructure controls is based on current location and the speed of the vehicle and can perform an action to prevent a crash. For example, extending a red signal indication until a vehicle clears the intersection, or triggering alarms in a work zone. Vehicle controls can also be based on the current location and speed of the vehicle, and possibly based on information from the infrastructure. For example, it may begin to apply a vehicle's brakes if it sees something ahead of it, or pre-arm the vehicle's airbags if a crash cannot be avoided.

So in summary, we've reviewed the connected vehicle environment is the use of communications to exchange transportation information between devices, such as a vehicle, the road infrastructure, or mobile devices. It involves vehicles and the roadway infrastructure and the mobile device exchanging transportation-related information. Through this connectivity, the V2I environment offers potential benefits to address the transportation challenges we discussed earlier in the areas of safety, mobility, and the environment.

So, over the next couple of slides, we're going to talk a little bit more about the vehicle-to-infrastructure environment. We're going to list out some of the components of a V2I environment, discuss some of the potential communication technologies that may be deployed in V2I, identify some of the V2I applications, and finally, describe the information that needs to be exchanged between components to support V2I applications.

This is a visualization of how V2I environment might work. It consists of onboard equipment in vehicles broadcasting basic data about the vehicle, such as its vehicle location, its current speed and its current direction of travel. It may also receive data from other devices, such as other vehicles, the roadside infrastructure, or other connected devices such as a smartphone. The "I" portion of the V2I consists of roadside equipment, and in this example the roadside equipment, or the RSE, is located in a different cabinet than the traffic signal controller and it can receive basic data that's being broadcast from the vehicle. In addition, it can also broadcast information such as information about the signalized traffic signal, the roadway geometry, and traveler information back to the vehicles or other connected devices. The RSE can be located in the same cabinet as the traffic signal controller or it could be in its own cabinet on the roadside or mounted on the light pole.

Looking more carefully at the components of the onboard equipment on the vehicle. The four components on the left within the teal box make up what we call the onboard equipment, or in-vehicle equipment. The components consist of a communication device, a device for communicating wirelessly with other connected devices. It could be a cellular telephone device or something called a DSRC radio, and we'll talk a little bit more about what DSRC is later. Note that sometimes we confuse onboard equipment and onboard unit. Onboard equipment consists of all these components within the teal box, and onboard unit is just a DSRC radio and antenna. We also have a GPS receiver which receives location and time information from the global navigation satellite system's satellites. A safety application electronic control unit, which is a processing unit that runs the software applications on the vehicle, and there's also memory which stores security certificates—we'll talk about security towards the end of this module and other application data, which may include sensor data from the vehicle's own sensors. Other components that might be involved with the V2I communications include the driver of vehicle interface, which displays information to the driver, and also the vehicle's internal communication network, sometimes called the CAN bus, which collects information from the vehicle's own sensors. Looking at the roadside equipment or the infrastructure, these components consist of a wireless communications device for communicating with other connected devices; again, it could be a DSRC radio, and RSU represents the DSRC radio and the antenna by itself. A GPS receiver, again, receiving location and time information; application processing unit, which is a processing unit that runs the applications, and a backhaul modem, which is a device for communicating with a traffic management center, for example. So it could be wired or wireless. There's also memory, which stores the security certificates and the application data. So note that this is only one possible scenario. There are other scenarios that are being researched and considered, including information exchanges from the vehicle directly back to a traffic management center, such as through cellular data. So the processing unit, as a note, could also be a field-hardened computer, or it could be an advanced traffic signal controller. So it could be a separate device or it could be part of the traffic signal controller.

The next several slides will talk about some of the wireless communications technology that might be used in a V2I environment. The focus in this case is the infrastructure between interface and mobile devices, such as the vehicle or possibly a smartphone, and not between the roadside equipment and the center. So a wireless communications network can be classified into two types: Wireless Local Area Network, and Wireless Wide Area Network. With a wireless local area network, that connects a connected vehicle with roadside equipment. The roadside equipment might be connected to the center, either through the cloud, wirelessly, or through a landline, but note that each of the communications technology listed are not equal and each have different characteristics, such as different latency, throughput, or maybe even operating distance. So one of them is the DSRC, and that's what we've been testing, but the other, using the Wi-Fi, is also a possibility. The last bullet talks about a 3GPP group, which consists of seven telecommunications standards development organizations covering cellular telephone, and that's dominated by the Sprint, AT&T, and Verizon Wireless, and they're currently performing a study to investigate the use of LTE mobile networks for V2X, and that study is expected to be completed at the end of 2015.

But we're going to focus a little bit on DSRC. DSRC sometimes is incorrectly synonymous with connected vehicles. DSRC is really just a communications technology—only one communications technology that may be used in a connected vehicle environment. There are several technical definitions of DSRC and this slide shows the definition as defined by FCC, the Federal Communications Commission. This definition is only applicable in North America. For example, the European Union has their own technical definition of DSRC, but they're very similar in that they use frequencies that are used solely for ITS applications. So these are radio frequencies used solely for ITS. Note that the use of the term DSRC came from an ASTM standard, ASTM 2213, which we'll talk a little bit more about later. But in general, DSRC is just a two-way, short-to-medium-range wireless communications capability that permits very high data transmission, which is critical for active safety applications, and describes the radio system and its use for traffic services for ITS. The full reference, by the way, to the FCC report and order can be found in the student supplement.

So, the actual frequencies that are used for DSRC vary in the U.S., Japan, and Europe. In the U.S., the FCC originally allocated the spectrum in the 5.9 gigahertz band and allocated about 75 megahertz, again, specifically for ITS vehicle safety and mobility applications. In Europe the frequencies are slightly different, as it is in Japan. But currently the 75 megahertz spectrum range for DSRC is divided into seven 10-megahertz channels, with one channel to be used specifically for safety and one channel specifically for safety data. There's also a higher-power channel, 184, that is used for public safety for emergency vehicles, for example.

Some of the advantages of DSRC. It has low latency that allows a high rate of transmission. The high rate of transmission for short messages is critical for a lot of the safety applications. So for example, if a vehicle wants to report its location and that's braking hard suddenly, you want to receive that whole message, the entire message, in a short period of time. I can't receive it two seconds later, because by then it's too late. So that's why the low latency is very important. So in the U.S., only 5.9 gigahertz, this DSRC is being considered for V2V safety applications because it has the needed bandwidth and low latency which is critical for V2V safety. So to learn more about that, I refer you back to I262, the module for vehicle-to-vehicle communications.

Another advantage of DSRC is its short to medium range. With DSRC, the range is about 300 meters on a consistent basis. It's been measured much longer, up to a kilometer. It's an advantage in that you only hear messages that are being broadcast by vehicles around you, within the 300 meters. You're not interested in the location and speed of vehicles that are over a kilometer away, for example. This could also be a disadvantage for some messages, for mayday messages, for example: If you're caught in a remote or if you get disabled in a remote area and there's no other vehicles or infrastructure within 300 meters, you're kind of out of luck. Another advantage is the DSRC is for the public good. It's allocated for the public and there's no over-the-year subscription required, so it makes it easier to align with public safety applications. Other advantages: We've been testing DSRC since 1999 and it's proven to be pretty reliable and the performance has been pretty good. So those advantages have been documented.

Wireless wide area network is another type of wireless communications network, and it includes high-speed cellular data and allows vehicles to connect directly to the cloud or to a management center, for example. So these standards are being developed by the 3GPP group; again, that's the Sprint, AT&T, and Verizon Wireless of the world; but because of latency and network reliability, WWAN can't be used for vehicle-to-vehicle safety applications, but it could be considered for use for mobility and environmental and non-time-sensitive safety applications where latency and time sensitivity is not an issue. Importantly, the use of WWAN does not increase congestion on the DSRC channel for safety-critical applications. So that's a concern right now, that the use of DSRC channels can get congested in urban environments; for example, where there's an incident and there's a dense amount of vehicles in a specific area.

So earlier in the module we talked about some of the V2I benefits, but how are those benefits realized? So, applications are software systems that take the inputs from other devices, such as vehicles and infrastructure, and uses it to provide relevant information to a traveler, a vehicle operator, or a transportation agency. These applications can be stored on the vehicle, on the RSE. So it is primarily through these applications how we gain the benefits of V2I environment.

So the next several slides will summarize some of the V2I applications that have been identified by USDOT to date and are being researched and prototyped. There could be more applications identified in the future. There will be others that are conceived and developed by others. Note that the applications will use information from other devices as an input in addition to its own sensor readings. So a vehicle will use, "Oh, these are my readings, and look, these are the readings from other vehicles." So together, the vehicle uses information from others and the infrastructure in addition to its own sensor readings. Note that an OBU or an RSE may have one or all of the applications we're about to introduce.

A vehicle could be a motorcycle, it could be a school bus that's stopped, loading or unloading, or it could be an emergency vehicle.

So all the following applications involve the infrastructure providing information to the vehicles. The first one is a curve speed warning. So if there's an RSE that broadcasts information to the surrounding devices that a curve on the roadway is coming, and provides information about that curve to the approaching vehicles. Note that the application can be set up so that the vehicle itself determines if a safety warning needs to be provided to the driver, based on the characteristics of the curve provided by the infrastructure, such as the type of road, the curvature, the current road conditions, whether it's icy or not, and the characteristics of the vehicle itself. Is it a truck or cargo that might overturn, or is it a low-height vehicle with performance tires? So it's up to the vehicle itself to determine, "Do I need to provide the driver a warning?" based on the characteristics of the vehicle itself.

Another one is a red light violation warning. So the infrastructure broadcasts information about the signal timing and geometry of the intersection. The vehicle can determine what part of the signal timing and geometry are applicable to the vehicle based on its current location, direction of travel, speed, acceleration profile, and then use that information to warn the driver, for example, that it's likely the vehicle will enter the intersection in violation of a traffic signal. For example, the signal phasing information might indicate when the light's going to turn yellow. By providing that information, we increase the dilemma zone distance for the driver so that they have more time to slow down or accelerate before reaching the intersection. A pedestrian and signalized crosswalk provides information from the infrastructure that indicates the possible presence of pedestrians in a crosswalk or at a signalized intersection. This indication could include outputs of pedestrian signals or simply be an indication that the pedestrian call button has been activated. So it's intended for transit vehicles making turns, but it's really applicable to all vehicles.

Finally, there's an oversize vehicle warning. It uses external measures taken by the roadside infrastructure and transmitted to the vehicle to support whether an alert or warning is necessary, or the infrastructure data equipment receives the approaching vehicle's height and width itself and activates the external alert. So the vehicle might say, "Hey, this is my height and this is my width," and the infrastructure reads that information and says, "Oh, wait a minute; you don't match the height, so let's issue you a warning back to the vehicle."

Other vehicle-to-infrastructure safety applications include stop sign gap assists to improve safety at non-signalized intersections where only the minor road has posted stop signs. So it helps drivers on the minor road stop at the intersection by providing a warning of unsafe gaps on the major road. A stop sign violation warning safety at unsignalized intersections with posted stop signs by providing warnings to drivers that they might violate an upcoming stop sign based on their speed and distance to a stop sign. These are some others: railroad crossing warnings, reduced speed zone warnings. In the interest of time, I'm not going to talk about them, but if you look at the notes they'll provide a little bit more description of each of these applications.

The following are examples of V2I mobility applications. So one is the advanced automatic crash notification relay—provides capability for a vehicle to automatically transmit an emergency message when the vehicle has been involved in a crash or a distress situation. This crash notification provides key data on the crash recorded by the sensors in the vehicle; for example, the airbags have been deployed without the need for an involvement of the driver. So this emergency information can be broadcast to passing connected vehicles who can then relay the message to other connected vehicles or to roadside equipment. So this might be important in somewhere very remote where there's no infrastructure or very few vehicles traveling for miles. So for example, like in Alaska, where you can go a couple of hours before another vehicle passes you. Another is vehicle data for transportation operations. So it's used to determine locations of potential incidents, such as changes from vehicle speeds, indicating a disruption of traffic flow, or when a vehicle's safety systems have been activated, such as traction control system has been activated, or maybe an obstacle has been detected by a vehicle.

And intelligent traffic signal systems utilizes the vehicle information to adjust signal timing for an intersection or group of intersections to improve traffic flow, allowing a platoon to flow through an intersection, for example. These are a list of some other potential mobility applications for V2I and, again, in the interest of time I'm not going to read through them, but this information is provided for your reference.

V2I environmental applications—just read one or two. The first one is enhancement maintenance decision support systems incorporate road weather data collected from connected vehicles and they use that as inputs into an existing maintenance decision support system capability. So for example, it may read, "Oh, in this area everyone's windshield wipers are on," or "Traction control has been activated in this particular area," indicating rain or icy conditions in this specific area. Again, I'm not going to read the remaining applications, but they are included just for your reference. So these are just some of the applications that have been identified for V2I. A more complete list of applications can be found in the CVRA, the Connected Vehicle Reference Implementation Arrangement website.

So this slide identifies some of the data that might be exchanged to support the applications that we've just listed. Similar information is needed for all vehicle-to-infrastructure applications. So from the vehicle, things that we're interested in is the location, the speed and direction of travel for the vehicle, sudden vehicle movements, sudden acceleration or braking or traction control; weather data from the vehicle, such as temperature, the windshield wiper status, if the vehicle lights are on. And in return, infrastructure might provide information such as signal phasing and timing information, intersection geometry, where's a left turn, where on the roadway, or where are the lanes? And traveler information such as incident information or travel suggestions, alternative routes.

So we've reached another activity. This time: Which of the following is not a vehicle-to-infrastructure safety application? So we've talked about safety applications and mobility applications and environmental applications. Which of the following is not a V2I safety application? Red light violation warning; forward collision warning; curve speed warning; and stop sign gap assist. Which of the following is not a V2I safety application? So the correct answer is B, forward collision warning, which is really a vehicle-to-vehicle safety application. We hadn't talked about it, but V2V—forward collision warning is an application where it's only between vehicles, but it warns a vehicle if another vehicle ahead of it in the same lane traveling in the same direction suddenly stops and there's a possibility of a rear-end collision. So that's a V2V safety application. Red light violation warning involves a vehicle receiving signal timing and geometry information from the infrastructure and warns a vehicle if it might violate a red light. Curve speed warning involves a vehicle receiving curve geometry and current environmental conditions from the infrastructure; and stop sign and gap assist assists a vehicle about vehicle movement gaps, gaps in the roadway, so that a vehicle can safely pass through a major arterial, for example. So those were the incorrect answers.

So in the last couple of slides, we've talked about the components of the vehicle-to-infrastructure environment and it includes onboard equipment and roadside equipment, each consisting of wireless communications devices, an antenna, a GPS receiver, memory, and an application control unit. Each OBE, onboard equipment, or roadside equipment, can provide a number of different safety, mobility or environmental services. There are a variety of wireless communications technologies that can be used for V2I. DSRC is only one of them, but it is expected that we will be using DSRC for vehicle-to-vehicle safety applications because of its low latency. Applications are software on the vehicle or roadside equipment that uses information it is receiving from other connected devices in addition to its own sensor readings, and they can be used—and that's how—through these applications—how we obtain the benefits in the areas of safety, mobility and environment. And finally, we've summarized some of the information that needs to be exchanged between components from the roadway infrastructure and from the vehicle that are needed to support the applications.

So, the next several slides, we're going to describe the role of standards in a connected vehicle environment. We're going to summarize the benefits of standards to start off with, and then we'll identify some of the specific ITS standards that are needed to support communications between components. Next, we'll identify some of the information and performance standards requirements that are supported by the ITS standards, and then finally we're going to review some of the hardware specifications that have been created by USDOT for its test pilots.

So, note that now that the V2I environment and its benefits have been introduced, what is it that's needed for the V2I environment to be realized? Well, the current situation that we face right now consists of different vehicles on the roadway from different manufacturers, and the infrastructure is operated by different state or local transportation agencies. For the connected transportation connectivity to happen, there are several questions that we need to answer. They are: How do we communicate? We agree that it's wireless, but is it wireless on the same frequency? So which frequency? What language are we using? So we have to agree on the grammar and the dictionary that we're going to use to exchange this information. How many people are talking in the room? So if there are a lot of people that are in the room that are on the roadway, how do we talk to each other? Should we talk louder, softer? Should we switch rooms, or a different channel? And finally, how do we trust each other? How do I know you are who you say you are and what you're telling me is true or not true? So, the standards are essential so that we can answer the previous question. It is with standards that we can support interoperability, which is the ability of two or more systems or components to exchange information and use the information that has been exchanged regardless of who the manufacturers are. So imagine a scenario where standards don't exist. So we have a vehicle model from Manufacturer A that's broadcasting on Frequency A and using its own proprietary data dictionary; it's using its own words. And then we have a vehicle that's manufactured by Manufacturer B that's listening on Frequency B and that only knows their proprietary dictionary. That wouldn't be very useful because one's talking A, one's talking B. So we wouldn't be able to exchange data between those models. So that's why interoperability is important. An example of interoperability is the use of AM/FM radio broadcasts. Because of the radio frequency standards, it doesn't matter who made the radio receiver, the antenna—excuse me—the radio receiver or the transmitter, such as the antenna. The radio receiver is able to listen to broadcasts that are on different radio channels. So that's why the standards are important regardless of who developed them. To maximize the potential benefits of the V2I environment, it's important that all the vehicles and roadside equipment speak the same language, speak the same way, use the same grammar, and use the same vocabulary. Other benefit of the standard is that it makes testing for conformance and interoperability easier. It helps with the design and procurement of a system.

So what kind of communication standards are needed? There are transmission standards that define how information is exchanged. Since the focus is on V2I, these are radio system standards and involve the capability for over-the-air transmission. IEEE 802.11 standards define the physical and medium access control communications protocols that can be used for ITS. IEEE 802.11 is one. To give a better example, another analogy, let's use Wi-Fi. I have a computer that's from Dell, and you may have a computer that's using ThinkPad. Regardless of where we are, whether we're at the airport or Starbucks, when we use Wi-Fi, because it's using a group of standards and it doesn't matter if I'm using Apple or if you're using Windows, if you're using Chrome web browser, Firefox, or Internet Explorer, we're all able to connect to the Internet because of the Wi-Fi standard. It doesn't matter who manufactured it, it doesn't matter where we are, it doesn't matter whose browser we use; because of the standards we can connect to the internet and get our mail. So that's just another analogy.

In addition, the IEEE 1609 defines the rules and procedures on how data can be exchanged between two devices. So for example, an analogy would be the English language. English consists of a grammar defined in rules and procedures on how we exchange information. There are also interface standards that define the characteristics to allow the exchange of information between two devices. So SAE J2945 and ISO 19091 are interface standards that define the operations, performance, and functional requirements for one or more applications. So for example, SAE and ISO, ISO 19091 are interface standards that define the operation, performance, and functional requirements for one or more applications. So, for example, SAE J2945 is proposed to define how data must be broadcasted so safety applications can make the decisions, or provide the data to drive risk for crash avoidance at intersections. There are also data standards that define the data to be exchanged. So, SAE J2735 defines the messages and data dictionary, the words and sentences that are used to exchange information between two devices. An analogy is that the messages or sentences for the data elements are individual words.

So, over the next several slides, we'll discuss a little bit more of each of these standards in a little bit more detail. Although the slides will contain detailed descriptions, we'll only highlight and only review the highlights of each of the standards. So, it's important, again, to recall that DSRC is only one possible communications medium technology for V2I communications. But again, because of its low latency, it's likely to be used at least for V2V. As mentioned earlier, ASTM 2213 introduced the term DRSC, and was the source for the FCC rule that led to the reporting order for the 5.9 GHz ITS radio plan. It's really not being used anymore. It's been superceded, and IEEE 802.11p amendment, which is now part of 802.11, has taken over it. But, we included this. We mention ASTM 2213 as reference. So, IEEE 802.11 has taken over, replaced ASTM 2213, but this family of standards provides the wireless connectivity between different devices within a local area. So, for example, 802.11 defines part of the Wi-Fi standard. There's 802.11b. There's 802.11g, and 802.11n that are used for the Wi-Fi standard. There is 802.11p amendment that defines wireless connectivity in a vehicular environment. So, it specifies the channel bandwidth, the operating classes, the power classification, and channel requirements within the 5.9 GHz spectrum for the use of ITS services.

The IEEE 1909 family defines the rules and procedures on how data will be exchanged between two devices. So, there's the IEEE 1609.0, which is the guide describing the architecture and the services necessary for WAVE or Wireless Access in a Vehicular Environment, devices to communicate in a connected vehicle environment. There is also IEEE 1609.2, which defines a secure message format and processing for used by WAVE devices, including how to secure the management messages, application messages. Also, it describes the administrative functions necessary to support the core security functions. So, IEEE 1609.2 is only intended for ITS, although it can be applied elsewhere; so, outside the ITS realm. IEEE 1609.3 defines the services operating in the network and transport layers. It manages how communications are initiated, how they're ended, and how messages are exchanged. 1609.4 talks about multichannel operations. Recalling that there are seven channels seven 10 MHz channels available for DSRC. 1609.4 talks about multichannel wireless, radio operations, and supports channel switching and routing so that if one channel is congested, information can be switched; the messages, the data exchange can be switched to a different channel.

IEEE 1609.11 specifies how over-the-air electronic payment transactions between a mobile device and a roadside unit occur. So, it includes support for authentication and payment data transfers. And there is IEEE 1609.12, which specifies WAVE identifiers. So, there are services that can be offered by a roadside unit and each of those services are assigned an identifier. This standard identifies and specifies those values.

So, the previous slides represented the communication protocol standards that will support DSRC. So now, let's talk about the data SANs or the dictionary that we'll use regardless of which communication system is used, and that dictionary is called SAE J2735 standard, Dedicated Short Range Communication Message Set Dictionary. While it says DSRC in its title, it doesn't necessarily have to be transmitted, used only with DSRC. The key message that's defined in SAE J2735 is the Basic Safety Message. That's going speed primarily used for V2V communications and broadcasted by vehicles. So, the Basic Safety Message, or the BSM, this is the two parts, Part I and Part II. Part I data elements are considered basic information needed for safety applications and thus are considered mandatory. That means they have to be supported. They are expected to be broadcasted by a vehicle on a frequent basis. SAE J2735 does not define how frequently, or when a message should be transmitted, but that's actually handled by a different standard, which we'll talk about next. Part II data elements on the other hand are optional. They may be broadcasted along with the part one data elements as needed, or as requested. So, for example, BSM Part II, has a flag to indicate if a vehicle is braking hard. And so, if it is braking hard, it can be broadcasted along with the Part I. It is important to note that another device could request a Part II data element from a vehicle, but there's currently no requirement or rule that the receiving vehicle has to provide it. Regardless, BSMs are expected to be broadcasted frequently using DRSC for V2V safety. But, while it's intended for other vehicles, those BSMs can be read by a roadside unit.

This slide summarizes the information provided for the BSM Part I. It includes the location; positional accuracy, meaning how accurate, how confident we are on the position of the vehicle. This will depend on how well it can read its GPS signals. For example, if the GPS has a full view of the sky, the accuracy is likely to be high. But, if it's in a canyon, whether artificial or natural, the accuracy is going to be lower.

Transmission out to other vehicles: Know the vehicle is in neutral, park, forward, or reverse. The steering wheel angle lets other users know the vehicle is turning or not. Acceleration is along all three axes, plus the yaw rate. So, vertical acceleration might indicate there's a pothole in the roadway while the yaw rate might be used to determine is a vehicle is in danger of overturning. Brake system status indicates the brakes are being used, including antilock brakes, traction control, stability control, or the parking brakes are being applied. So, this information, though it's, again, intended for other vehicles, can be read by the roadside equipment, and can be used by infrastructure managers to determine safety; mobility, how well vehicles are moving; safety in case vehicles are braking hard, and again it can be used to determine the incident or the potential of an incident. For mobility, it can be used to determine demand, improve single operation, and for environmental applications, the BSMs can be used to optimize the transportation network to reduce overall delay and emissions, and suggest optimal speeds and/or routes.

So, this slide summarizes some of the data elements that are contained in Part II that may be of interest for V2I communications. It's not a complete list. Again, these elements are all optional, and the manufacturer right now is under no obligation to go broadcast any of this information. So, the Part II does include event flags. So, these are little flags that say, "Hey, something important might be happening such as my antilock brake system is activated. So, please pay attention." There's also an event flag for if the emergency is an emergency vehicle on an emergency call, or a vehicle is placarded in and carrying hazardous materials. Other information that is included in the Part II is location obstacles based on vehicle sensors, or sudden vehicle movements that an operator may take to avoid a potential obstacle. Other parts, other information in Part II, vehicle weight and height, exterior lights, whether the exterior lights are on such as the hazardous lights or indicating a left turn signal; the rate of wipes, the windshield wipers, and environmental data such as air temperature, sun sensor, air pressure, or rain sensor.

So, that's the key message that is being broadcasted by vehicles. J2735 also defines some messages that might be broadcasted from an infrastructure to other connected devices. One is the MAP data, which is used to broadcast roadway geometric information such as the intersection geometry or roadway segments. That can be used to be help drivers determine where they are in relation to the intersection, allow them to avoid wrong way lanes, notified of roadway closures, or drifting off the roadway pavement. It can also be used by pedestrians with smart devices to indicate where the crosswalks are.

Another message is the Traveler Information Message. It helps provide focused traveler information. By "focused" we mean that in the header the message indicates, oh, this is intended for all travelers that can hear this message, or it might be for vehicles traveling of a specific type, or moving in a specific direction. The Signal Phasing and Timing information provides information about signal operations of a controller. So, it gives general status of the controller. Is it in flash? Is it operating properly? For specific lanes or crosswalks, it indicates, or for specific movements actually, does the vehicle get a green light, is it a yellow, or is it red, and if it's green, when is the green expected to change? So, at five seconds after midnight, this green movement is going to turn to yellow movement. So, you'll see the yellow indication. The SPaT message is intended to be used along with the MAP data message. There's also a Signal Request and Signal Status Message. This is used to provide, to request signal priority and return the status of the signal request back to fleet vehicles such as emergency vehicles or transit vehicles, or freight vehicles around ports. These are some of the other messages that might be available. Again, for the interest of time, I'm not going to read through them, but they're included for your reference. The next family of standards we want to introduce is the SAE J2945 family standards. It's currently still under development, so it doesn't exist yet, but it's expected to define the operational and performance requirements for connected vehicles; that is how information is expected to be exchanged between two devices or two systems. An analogy: The English dictionary, for example, contains the words to be used. That was defined in J2735, but it does not describe how those words are to be used to communicate. So, the J2945 is expected to define what messages and when a message should be exchanged to support an application. In addition to specifying the transmission standards to use and how to use it, the family is expected to define the performance requirements for specific messages. So, how often is the message sent, what data elements must be sent, and the quality requirements necessary before a data element is sent. So, for example, if the position of the vehicle, if it's of poor quality maybe because the GPS receiver is not working well, or because it's deep in a canyon, the performance requirements in J2945 will say, well, if it's a poor quality, don't send that data. It's better for you not to send your position than to send a position of questionable accuracy or quality.

So, the J2945 family; J2945/0 has loopholes, and that will provide generic content requirements that are applicable to all applications. Of interest to V2I, /3, /4, /5 are placeholders for V2I applications. /3 is supposed to talk about V2I infrastructure-centric applications; /4 is expected to handle MAP and SPaT applications and /5 is intended to address travel information messages. So, the DSRC Technical Committee responsible for the development of the J2945 family standards is still debating. This is the full scope of each of these proposed standards, and it's really also focused right now on the V2V standards. But, each of these standards is expected to include systems engineering content and minimum performance requirements. By systems engineering content, we're talking about the concept of operations requirements and the design.

/6 has actually started, and it will define the data exchange for coordinating maneuvers for platooning and cooperative adaptive cruise control. It will determine the message sets and the performance to support cooperative vehicles. There's also a J2945/9 for vulnerable road users, V2P, vehicle-to-pedestrians, or mobile devices, or bicyclists for example. So, it's expected to provide recommendations for performance levels, links to existing standards, and new standards development if necessary. Again, right now, there's also a /1 and /2 that's being developed right now, and that focuses on vehicle-to-vehicle.

This slide summarizes something called SAE J3067 informational report. There was a comment submitted by USDOT, and it expanded on the 2009 version of SAE 2735. The most current version is 2015. It added systems engineering process content, including tools for selecting and deploying the standard, and expanded the support for using each lane to the USDOT's Road Weather program, AERIS program, transit and freight. It included the concept of operations, requirement specifications, including performance requirements, design specification, and traceability matrices. We included it, it's not an ITS standard, but it's really an informational report that provides insight on how the SAE J2735 and the SAE J2945 standards will be structured and can be used for implementation by users such as transportation managers. So, it's there more for reference.

In addition to US efforts, there have been international efforts to define standards and support a connected vehicle environment, which is called Cooperative Systems in Europe. ISO, International Standards Organization, ISO, Technical Committee 204 is responsible for the standardization of information, communications, and control systems in an intelligent transport systems field. Working Group 18 has been tasked with developing standards for Cooperative Systems. One standard that is under development is the Technical Standard 19091, which is defining operational and performance requirements for V21 and I2V, communications at signalized intersections. So, using a systems engineering process, the proposed standard is expected to define the operational needs and requirements for V2I communications at signalized intersections. Specifically, the standard is expected to define when and what portion of the SPaT, MAP, Signal Request Message, and Signal Status Message are expected to be transmitted to interoperability can be achieved. Some country specific extensions may be developed as part of this effort based on a country's specific needs. So, for example, there are extensions and visions specifically for the United States, for The European Union and Japan. So, a note that ISO 19091 is an international standard, and it's not known at this time whether the U.S. will adopt this standard. However, since the DSRC Technical Committee has not yet begun work on SAE J2945/4, which is expected to define the minimum operational performance requirements for MAP/SPaT, ISO 19091, because of its systems engineering content, is a suggested resource for defining the requirements for MAP and SPaT messages. Again, be aware the U.S. may not adopt the standard and might adopt SAE J2945/4 when that standard is developed and approved.

So, revisiting an earlier slide, I was asked the question, "What is needed for the vehicle-to-I environment to be realized?" We now have our answers, at least with DSRC. This slide depicts the standards that answers the different questions that we had and are needed for interoperable V2I environment regardless of the make and model of the vehicle or DSRC. There may be different standards, that we use cellular communications, or other wireless communications, but they're still being tested and prototyped, and it's not the current focus of this ITS standard. So, how do we communicate? IEEE 802.11 and IEEE 1609.3 defines that. What language are we using? SAE J2735 and SAE J2945 defines that. One's a data element. One defines how we use those data elements and messages. How many people are talking in the room? IEEE 1609.4 supports multichannel operations. So, in case one channel gets congested, it can talk about how we can use other channels. How do we trust each other? So, IEEE 1609.2 enables it.

So, the hardware specifications supported by USDOT. So, USDOT through the ITS Joint Program Office has established several test beds in the U.S. for testing applications in an environment using the latest standards. Note that not all test beds are supporting V2I applications. As part of the testing, USDOT has developed several device specifications to be used in testing on the test bed. The slides list the device specifications that are on the research qualified products list for the Onboard units. So, these are the current specifications being used in the Southeast Michigan test bed. There is a USDOT vehicle awareness device specification, and a USDOT aftermarket safety device specification. Each specification is based on the standards already discussed in this module.

This is the same, similar, but for the roadside equipment. So, there is roadside equipment and roadside unit specification. The specification is based on the standards already discussed in the module. Some of them may have adjustments; again, some adjustments because sometimes a standard doesn't work as we had planned, and we're going to discuss that in the next several slides.

So, we've reached another poll activity. "Which of the following is a data standard?" So, which of the following is an information data standard? Your answer choices are a) IEEE 802.11-2012; b) IEEE 1609 Family of Standards; c) SAE J2735; or d) USDOT FHWA Vehicle Awareness Device Specification. Which of the following is a data standard?

So, the correct answer is c) SAE J2735 is the data standard that describes both the message and the data dictionary to be used by the messages. A) IEEE 802.11 is actually a communications and transmissions standard. IEEE 1609 are also communications and transmissions standard, and d) is actually a specification and not a standard.

So, in the last couple of slides, we've talked about how standards support interoperability, and with interoperability that systems are able to maximize the benefits. So, the V2I environment is a standards-based environment to support the goal of interoperability. There are several standards that have been developed, or are being developed to support communications in a V2I environment. They include IEEE 802.11, which defines the communications protocol; IEEE 1609. That defines the security and network services and defines the rules on how we're going to communicate using DSRC. The data standard that's being used for V2I is primarily SAE J2735 while SAE J2945 standards define the performance requirements for specific J2735 messages. And USDOT has developed hardware specifications for its test beds based on these ITS standards.

So now that we've introduced the standards that are being developed, or are in development to support communications in a V2I environment, the next several slides will introduce some of the existing barriers, both technical and institutional to deploying a V2I environment from the perspective of the employer. One of our challenges that we face is that although the proposed NHTSA, Advanced Notice Proposed Rulemaking is expected to equip vehicles, that is make them connected, V2I is not mandated. This means that vehicles are expected to support vehicle-to-vehicle communications, such as broadcasting and receiving basic safety messages. However, there's no rulemaking that is expected to require light vehicles to support other messages. For example, receiving MAP, SPaT, or travel information messages. So, why should infrastructure managers care about V2I then? Because connected vehicles or transportation connectivity, even limited to V2V, is another technology, or tool that is available to transportation managers to address their transportation problems. The V2V and V2I environment is standards-based and does envision to be highly interoperable. These standards will make the deployment and design of future systems much easier. With national interoperability, all equipped vehicles will someday be connected in a standardized way, providing data in a standardized format. So, by listening to the basic safety messages that are being broadcasted for V2V safety, it provides an incredible source of data that transportation agencies can take advantage of with roadside equipment that can listen to the standardized formats, thus providing real-time traffic information and pro-dated information. Similarly, the same roadside equipment can be deployed to provide focused travel information, including regulatory information and signal phasing information to vehicles also in a standardized format in hopes that the vehicles will have the capability of hearing these messages. Because the data interfaces are standardized, it creates competition for roadside equipment, and may result in better value.

Again, the vehicle-to-infrastructure environment is envisioned to be interoperable, which will provide the ability to broadcast standards-based messages and reliably exchange data regardless of the service provider, or the main patch rep. However, these standards are still evolving. Requirements are still being added or tweaked as we learn more from the prototypes and field tests that are currently being conducted. NHTSA has recognized this, and has sent letters to standards development organizations encouraging that the standards be stable by September 2015, before the rulemaking. Some standards may also have to be updated at a future date to align with the final NHTSA rule, which is expected to be released in 2016. There are also other efforts to harmonize standards with each other, whether it's within North America, or with international efforts. Thus, early adopters of initial standards should be aware of the potential for changes, and build any means to cope with the changes, both planned and unforeseen—plan for changes with contingency planning, do any risk assessment, and avoid complacency when all is sailing smoothly.

Other implementation issues that project managers should be aware of; vehicles have to be equipped to gain the benefits. So, you would have to have at least one vehicle that must be able to broadcast to the infrastructure, and the other, the vehicle must be able to receive the broadcast. So, we have to be aware of the challenges during the rollout as some vehicles are equipped and some are not. There may be adjustments to driver behavior as the rollout occurs over a period of time.

Basic safety message is unencrypted. So, near-field tracking is possible. So, the vehicle IDs and MAC addresses are expected to be randomized, and we'll talk about that briefly, but we can still really track a vehicle for a short distance and for short periods of time. However, note that the V2I, or connecting equipment, is just another technology and tool. It's not a substitute for sound transportation engineering principles.

Testing and certification is also another technical challenge. Not all conformance testing is the same. We have to describe what test and by whom and for what purpose. So, there are different types of conformance testing. There are different types of compliance testing. So, interoperability can be viewed as connected devices to a network of other devices made by different manufacturers in attempt to exchange basic safety messages. So, compliance testing is another set of tests to determine if a product is in compliance with the applicable regulations, such as FCC regulations, or your transportation agency's specific requirements. Note that procurement spec is a legal requirement. Other things we have to be concerned about; there might be different versions of a standard. Recall that there are aftermarket devices that are being considered. So, for example, there might be devices that you can purchase at Best Buy for example that you can install into your vehicle. So, who will certify that the device is mounted properly so that the vehicle location is correctly broadcasted, for example. So, that's another challenge that we are facing.

This is not really a standard issue, but we just need to be aware. This is a regulatory issue. In February 2013, the FCC released a Notice of Proposed Rulemaking for changes to several frequencies in the 5 GHz band. So, this proposed change will now allow other users to be secondary users, but to use the 5.9 GHz band for exchange of information not related to ITS. The secondary users as they're known as are supposed to be secondary users and when they recognize that, oh, someone else is using it that's a primary user, such as for ITS, they are not allowed to use it anymore. But that's still being worked out, but we just wanted you to be aware of it.

There are also licenses that may need to be obtained for the FCC for DSRC radios. More information about obtaining licenses is outside of the scope of this module, but should be addressed in a V2I guidance document that is expected to be available in the summer or fall of 2015.

In addition to the technical challenges that we've just reviewed, that are also institutional challenges. Privacy is a key challenge. The issue is privacy with respect to user data and respect to the communications stack. We know right now in the public there's sensitivity to data collection, data use, data distribution, and the relationship to data sources needs to be addressed. Note that the situation for data about vehicles differs from the authorization needed to access that data to create information about the vehicle, such as for commercial vehicle credentialing. The standards do address privacy in two different ways. IEEE 1609.3 describes the use of changing the MAC addresses at random intervals, while SAE J2945 standards will address this by assigning and changing the identifier that's broadcasted with the messages on a frequent basis. So, this will provide some assurance of privacy because the agency can track a vehicle to a source and destination without appropriate authorization.

Another institutional challenge is security. The difference between privacy and security, privacy is the use of data to identify something. Security is the exchange of trusted and authenticated data. So, the concept and context of data integrity of what is trusted is not likely to be found in standards, but with the systems that are being developed for our security management system. The current plan is for USDOT is to develop a security certificate system where certificates from a trusted source is broadcasted along with the messages. But, the standards will support the security system. For example, IEEE 1609.2 defines how to use, revoke, and refresh certificates in the certificate management system, and we'll talk a little bit more about the security management system shortly.

So, what can V2I managers, transportation managers do to take advantage of the equipped vehicles that are expected on the roadway? Well, one is to start considering V2I communication standards when purchasing new ITS equipment, or upgrading their ITS equipment such as signal controllers. We need a reliable power supply. We need a secure and wide backhaul communications link from the field devices back to the traffic management center, and you need to put leave some roadside spec admin space to how the DSRC equipment, or the RSU equipment. So, as we design, as we upgrade our infrastructure, we need to consider how we're going to support the V2I equipment. The module to introduce the concept of V2I environment has to be a standards-based environment so interoperability can be achieved. So, to support this in our environment, the components of the environment have to use standards-based specification. That means each specification should conform to the appropriate standards requirement for implementation, should indicate the communications needed to be supported, the communications protocol standards to be supported, and the information and performance standards to be supported, and support the security infrastructure. Certified devices should be used during the conduct of the test plan. So, we have to consider how are we going to develop the test plans. So, verify how we conform to the reference standards and identify the requirements that your agency may have for the applications.

A little bit more about conformance. The standard should contain—each standard should contain a conformance clause, a statement. So, procurement, the project manager should understand what the conformance clause means, when the conformance clause applies, and how to test for conformance to the standards. So, as a reference, there are other PCP modules on ITS standards testing. T101 is an introduction to ITS standards testing.

So, we reached another activity. "What is a challenge to deploying connected vehicles during the initial rollout?" So, the answer choices are, each vehicle, each automobile vendor uses its own protocol; b) that there has been no field tests of connected equipment; c) no expected rule requiring vehicles to be equipped, and d) very few vehicles are equipped. So, which is a challenge to deploying connected vehicles during the initial rollout of the V2I environment?

So, the correct answer is d) very few vehicles are equipped. So, during the rollout, very few vehicles are expected to be equipped with V2V communications capability, or even V2I. The standards have been developed, and automobile vendors are expected to use the standards. Numerous field tests have been conducted using the connected equipment, and NHTSA has proposed rulemaking requiring light vehicles to be equipped for V2V communications, and this hopefully will lead to V2I communications.

So, over the last couple of slides, we've talked about some of the technical challenges to deploying V2I. The standards are still evolving. They're being updated based on the evaluation of power test and field tests and due to harmonization of each other. Some potential implementation issues have been resolved as we transition from several vehicles that are equipped to most vehicles being equipped. So, there are some potential implementation issues there. There are also regulatory issues with FCC for band sharing. Some institutional issues that we've talked about include privacy and security. The deployment of the connected vehicle infrastructure really can be treated as another ITS system. The standards for V2I will help with developing specifications that each agency develops, but each agency will also have to consider how they perform certification and compliance testing.

So, the next several slides we're going to introduce some of the challenges to deployment. In this section, the module gives the stats of each of the standards activities and research, activities that are underway that will address some of these challenges. And, finally, we'll provide some additional resources for further reading and information about these standards, the activities, and deployment. Again, note that these statements about the current activities are as of around June 2015.

For DSRC communications, recall that there are other communications media such as cellular data that are possible for V2I communications, but the standards activities for those communications are outside of this scope, of this module, which only focuses on TS standards. So, we're just going to review those. A revision of IEEE 802.11 is being considered to harmonize with the lessons learned from the safety pilot, and to align with the proposed rulemaking. So, it's scheduled for comment in March 2016. For IEEE 1609, there are research studies that are being done by CAMP, which is the Crash Avoidance Metrics Partnership, which is a consortium of vehicle manufacturers that are jointly testing V2V safety applications. Based on those research projects, IEEE 1609 Working Group is getting recommended changes from CAMP. There has been also attempts to harmonize the international standards body. So, work items that are deemed critical to NHTSA decisions are being given priority. A revision for the whole IEEE 1609 family is being planned for September 2015 with or without harmonization results.

The DSRC Technical Committee is responsible for SAE J2735 and SAE J2945. As this is the data standard that includes the performance requirement, NHTSA has asked that the DSRC Technical Committee accelerate their efforts. So, for SAE J2735, improvements are being considered to support—better support emergency vehicles and trucks, and to better support the signal request and signal status messages, which are used to support traffic signal priority. For J2945, placeholders have also been identified for several V2I applications, and there is also work being considered for V2P, or mobile devices such as smartphones. These standards may use what is in J3067 or ISO 1909.1 as a basis for the appropriate standard. Work is continuing. A new revision is expected to come out about September 2015 primarily to support V2V safety and to support the NHTSA proposed rulemaking.

Security. As we mentioned, USDOT is researching a security credential management system. What is being looked at is developing a security management system that fits the requirements of how certificates are to be used, revoked, and refreshed as defined in IEEE 1609.2. They have a pilot that's being tested and designed as part of the test beds. Note though that there are two separate efforts, one by USDOT in the test bed and one being led by CAMP. So, we are still waiting to see how the security credential management system will work out.

Certification testing describes what test and by whom and for what. Again, note that not all conformance—product performance testing is the same. Some of our product conformance to standards. Other tests are to determine if there are any internal inconsistencies within each standard. Acceptance testing is yet to begin. Basic device should be certified for environmental capabilities and for communication protocol capabilities, for example. If we can use DSRC as specified in a standard. Application should also be certified for interfaceability and for the overall application abilities. USDOT has recently worked with three organizations to do the certification. They are OCS, Several Layers and Danlaw.

Next, FHWA is planning to issue a V2I deployment guidelines document. It's a guidance document, not regulation, and it's expected to provide information to transportation agencies on how to deploy the infrastructure to support the V2I infrastructure. So, it's supposed to include guidelines, best practices, and toolkits. The earlier draft of the V2I deployment guidelines can be found at this link [http//stsmo.transportation.org/Documents/V2I_DeploymentGuidanceDraftv9.pdf]. The final guidance document is expected to be issued in summer 2015.

There's also been a V2I deployment coalition. So, this is a deployment coalition to support implementation of the V2I infrastructure. Members include AASHTO, the Institute of Transportation Engineers, and ITS America. So, the purpose of this coalition is to represent and address stakeholder needs. It's a forum to offer assistance in deployment V2I. It can include, and may include a dissemination of tools, reference materials, and provide other technical assistance.

Connected vehicle research. So, this slide contains examples on the test beds and research that is being performed right now by USDOT. Each of these test beds and research are using the latest standards at the time of their implementation with the intent to verify that the standards are complete and effective, and to look for any ambiguity or holes in the standard, both in the real world environment, or in the case of the Southeast Michigan test beds or the CAMP research, or in a controlled environment such as the Connected Vehicle PlugFests where developers can bring in their devices to be tested for interoperability in a laboratory. Again, I mentioned earlier, know that sometimes modifications are made in the test bed though to address known issues with the standards.

The Dynamic Mobility Applications, there have been some prototypes of some of the mobility applications that have been developed and are being examined. There's a data capture and management program that's being used for the collection of—that's investigating the collection of real-time data from a variety of sources and modes in the integration of that data. There's also the AERIS, Applications for Environment: Real-Time Information Synthesis, which is looking at the environmental impacts of the connected vehicles and the Road Weather Connected Vehicle Applications, which is looking at applications that take advantage of the connected vehicle information for the maintenance of the roadways based on road weather.

Finally, this is the schedule of milestones for NHTSA. Again, in February 3, 2014, NHTSA made the decision to move forward with the vehicle communications for light vehicles and August 18, 2014, issued an Advanced Notice of Proposed Rulemaking to begin implementation of vehicle-to-vehicle communications technology in light vehicles. There were expected to be a decision on heavy vehicles, whether to require vehicle-to-vehicle communication capability in heavy vehicles back in 2014, but that has not occurred yet. Just to reiterate, there is no rule expected to mandate V2I or I2V, but the V2V ruling, proposed rulemaking is expected to open the doors for V2x applications.

So, we reached our last poll. "What is the current status of connected vehicle standards?" Your answer choices are a) the standards are stable so no revisions are needed; b) being revised based only on lessons learned from pilot deployments and field tests; c) being revised based only on existing USDOT regulations; d) being revised based on lessons learned and harmonization with each other. So, what is the current status of connected vehicle standards?

So, the correct answer was d) the standards are being revised based on lessons learned and harmonization with each other. A is incorrect because the standards are not stable and they are current—we recognize this and they are currently being revised. It is not only being revised only based on lessons learned. We also consider harmonization efforts, and there is no current U.S. regulations regarding the connected vehicle environment in this proposed rulemaking.

So, some additional resources for further reading and information. We mentioned the Connected Vehicle Reference Implementation Architecture earlier. It's a reference implementation that reference framework that spans all the activities, and it's a means of detecting gaps, overlaps, and inconsistencies between the standards. It can be used as a resource by transportation managers for planning or deploying their connected vehicle infrastructure. It contains a list of all the applications which are being considered by USDOT, and it also includes a tool that will help infrastructure, transportation managers figure out—develop an architecture for how they want to implement connected vehicle environments for their agency.

As a note, CVRIA will be migrated to the next major revision of the US National ITS Architecture. That's expected in 2016. And again, here is the link for finding the CVRIA. USDOT asked AASHTO about a year or two ago to create a vision of a national connected vehicle infrastructure. So, this footprint analysis provides descriptions of typical deployments of connected vehicles at signalized intersections, urban freeways, rural roadways, international border crossings, and other locations, and discusses some of the operations and maintenance issues that are expected, and provides some rough cost estimates for deploying a connected vehicle infrastructure.

This and the next slide or two, next slide, provides links if you're interested in finding more information, or participating in the development of any of these ITS standards. Again, ASTM E2213 is included only for reference, and has been overtaken by IEEE 802.11. Here's the link to IEEE 1609. These links can also be found in the student supplement, and a more complete list actually of resources can also be found in the student supplement. That should have come with this module.

This slide contains the links to SAE standards. There's SAE J2735, SAE 2945, and SAE J3067. Some more additional resources for further reading. This is a link that points to the ISO 1909.1 that we described earlier, and here's the USDOT website that introduces the connected vehicle. Again, go to the student supplement for additional resources if you're interested.

So, just to summarize what we've learned in the last couple of slides; standards development and maintenance is ongoing as research activities continue. NHTSA will being working on a regulatory proposal to require V2V communications capability in new light vehicles. NHTSA's decision on heavy vehicles was expected in 2014, but hasn't been issued yet as of this date. Work is ongoing to develop a security system and certification process. The slides included where more information can be found in the standards, on the CVRIA and other connected vehicle activities.

So, just to recap what we have learned in this module; the connected vehicle environment is about transportation connectivity. The V2I environment consists of onboard units and roadside units broadcasting information to support safety applications, mobility applications, and environmental applications. Connected vehicle standards are critical to support interoperability in the connected vehicle environment. Some of the institutional issues that we are still facing are in the areas of security, privacy, and data ownership, and standards maintenance is continuing to include new requirements and to incorporate lessons learned.

So, thank you very much for joining us for this module. We hope this has been very helpful. We realize some of the content is very technical in nature, but we've gone through some of the highlights of some of the ITS standards that are being developed for the connected vehicles, and we've provided additional references and resources for you to follow-up on in case you're interested in finding out more information. So, thank you, again, for joining us, and this concludes the module.

#### End of I261_Final.m4V ####