Module 57 - CV T160

CV T160: Connected Vehicle Certification Testing Introduction

HTML of the Course Transcript

(Note: This document has been converted from the transcript to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included.)

Ken Leonard: ITS Standards can make your life easier. Your procurements will go more smoothly and you’ll encourage competition, but only if you know how to write them into your specifications and test them. This module is one in a series that covers practical applications for acquiring and testing standards-based ITS systems.

Ken Leonard: I’m Ken Leonard, the director of the U.S. Department of Transportation’s (U.S. DOT'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 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 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, and thank you again for participating. We hope you find this module helpful.

Dave Miller: This module is CV T160: Connected Vehicle Certification Testing, and it is an introduction to the connected vehicle certification process. This module is about the Certification Testing process of Roadside Units—we’ll call those RSUs—and on-board units—that’s interchangeable with OBU. These are devices, and it’s to ensure that the communications between vehicles and Roadside Equipment is private, that it’s secure, and that it’s interoperable throughout North America. It is essential that agencies use standards certification tests in deploying connected vehicle technologies to maximize the benefits from the connected vehicle equipment. And by taking this module, participants will learn how to specify certification requirements in your contract terms and conditions when you procure this equipment. Deploying certified connected vehicle equipment will support interoperability, and it will also minimize future integration costs and make your procurements easier. It will also facilitate regional and national integration of the entire system as it rolls out over the next several years.

Dave Miller: My name is Dave Miller. I’m the principal systems engineer at Siemens Industry, Inc. in Austin, Texas.

Dave Miller: I’m going to take you through four learning objectives. The first learning objective is to identify connected vehicle equipment that is needed for a signalized intersection. Next, we’re going to review the U.S. Department of Transportation Requirement Specifications for Roadside Units, both for the hardware and the software that you’ll need to have when you procure this equipment. Next, we’re going to go through understanding the role of Certification Testing within the entire context of a system’s lifecycle. And then finally, we’re going to take you through the development of a certification plan.

Dave Miller: So let’s go ahead and get started with the first learning objective, which is to identify connected vehicle equipment that’s needed for a signalized intersection. And if you’re taking this module, we’re going to go ahead and assume that you’ve taken the prior modules. We’ll cover those in the slides, but just a brief review of the terminology from the previous modules. Roadside Unit is an RSU. There’s antennas and cabling to go with that. That’s the part that goes at the roadside. It has the power over Ethernet. That’s called POE. You’ll hear me talk about that. There’s a backhaul communication to your central, there’s an on-board unit that goes in the vehicle, and then there’s the security credential management system to make sure that all of the paid exchanges between all of the different elements of the system are secure.

Dave Miller: Okay, so what is a connected vehicle? The term connected vehicle is introduced as defined by U.S. DOT. This is a national policy and it’s a program-based foundation terminology that’s used to bring public and private sector efforts and ongoing research and development efforts together. And let’s emphasize here: there’s a lot of things that are called connected vehicle, but we’re talking about the U.S. Department of Transportation connected vehicle system and initiative. We’re talking about a connected vehicle as a safety system. So the connected vehicles enable safe, interoperable network wireless communications among vehicles, the infrastructure, and passengers’ personal communication devices like smartphones or tablets. So just to be clear, a connected vehicle is not an autopilot system. You’ll hear a lot about self-driving cars. An autopilot system is used by automated vehicles, or AV, to guide the vehicle. CV data can be used by an automated vehicle for advanced warning, such as future signal changes, potential conflicts with pedestrians that may be hidden behind a truck—they’re about to step out in traffic that the vehicle system can’t see—cyclists over horizon, things like that. So near term, in the next few years, drivers will use the CV warnings and alerts as input to avoid crashes. So the driver, if I’m driving the car, I’ll get the alert warning that says something is going to happen that I can’t see yet. Long term, the AV, or automated vehicles, will use this connected vehicle as inputs to predict unsafe conditions ahead. So the automated vehicle will guide itself with its cameras and its own radar system, that sort of thing. But people get messages from the connected vehicle system to know that there’s things ahead that you can’t see or signals that are about to change that you don’t know about yet.

Dave Miller: Connected vehicle is a focus on safety, is an enabling improvement over traditional vehicles traveling within the roadway. So if you think about it, this is the first time that a vehicle active safety system must rely on data received from other vehicles, and it’s the first time that an active vehicle must rely on data from Roadside Equipment instead of only data from within the vehicle itself from its own sensors. So a passive safety system—that would be like a seatbelt, an airbag or other devices to mitigate crashes that are already starting to happen. An active safety system of a vehicle is crash avoidance based on its own vehicle sensors. And then a connected vehicle system is crash avoidance based on vehicle sensors plus the sensors of other vehicles and Roadside Equipment. So for the first time, a vehicle will be picking up data and messages and crash avoidance alerts from other vehicles, so it has to be trusted, and that’s why certification is absolutely mandatory to make sure that you can really trust the messages that are coming in.

Dave Miller: This is an advanced training module, so we’re going to gloss over a lot of this content form the prior ones, and we assume that you’re already familiar with the basic vehicle-to-vehicle concepts. In connected vehicle Module I262 we covered vehicle-to-vehicle, so that’s the messages from one vehicle to another. As you can see in this diagram, the vehicles send their location heading and speed and their elevation. The vehicles nearby that vehicle receive the other vehicles location, heading, and speed 10 times a second, and elevation. And based on each vehicle transmitting location, direction, and speed, they can plot crash trajectories, and if something is going to happen in the future where two vehicles will collide, the driver will be warned. That’s kind of a summary of what we were doing in I262.

Dave Miller: I261 is a vehicle-to-infrastructure, or V2I. And, again, the module we’re going through now is an advanced module, so we’re assuming that you’re already familiar with these concepts. We’ll go over these very quickly, but we’re not going to go into them in any depth again. CV 262: the V2I vehicle infrastructure. This is where the infrastructure sends the signal phase and timing countdown. So in addition to a driver seeing what the signals are right now, the vehicle system receives a message to say what the signals are going to change to and when they’re going to change in the future so that the vehicle system can identify unsafe things. The infrastructure also sends lane-to-phase correlations, so if I’m driving towards two traffic signals and one’s a left turn arrow that’s red, and one is a green round signal—a green ball that says go ahead—I can see both of them. Which one do I obey? Do I stop or do I keep going? Well, I look down in the lane and I see this traffic signal is over the lane. It’s green. I can proceed. The vehicle has to get the same information, so what we broadcast is, in addition to the signal countdowns for all of the signals, we also broadcast a map to the car. The map shows where the lanes are placed, and it also says for each lane which signal goes with which lane—which phase goes with which lane—so that way the car can decide. The infrastructure also can sense speed advice. Drivers are warned of dangerous conditions, and there’s also a term called V2X, or vehicle to everything. That could be like a vehicle can send information to—in addition to roadside devices—a smartphone, or if I’m on a bicycle, or if I’m a pedestrian, I can participate in the vehicle-to-connected vehicle system or the safety aspects.

Dave Miller: So let’s move on. That’s just a basic recap of the first two. So, again, we’re going to go into more depth here, and we’ll assume that you know the basics already. So we’re going to be focusing on the certification process that involves these vehicle functions and connected vehicle implementations. Again, this is a graphic that shows a vehicle system. In the green here, where I’m pointing {top left box}, this would be all of the functions that are within an on-board unit. The on-board equipment is all of everything that’s shown here, and the on-board unit itself is what’s in green. The on-board unit consists of radio, the memory, a GPS receiver to get location services, location service, and safety applications. There’s one thing we need to point out here: that, as you know, GPS isn’t completely, totally accurate to down to the lane. It’s important to know that really what the vehicle is using for its location for crash avoidance is a location service. GPS location is one input that’s used as a strong suggestion as to where the vehicle is, but the vehicle uses that as well as its other vehicle sensors. It may be using dead reckoning; it may be using acceleration/deceleration; it may be using the steering wheel, angle changes—things like that. With all of the sensors, including GPS, that’s how the vehicle gets its exact location. What it does is it transmits a set of basic data to vehicles and roadside infrastructure. What it’s doing is it’s 10 times a second, all of the time when the key is turned on, it transmits the vehicle location, its speed, its elevation and direction of travel. It’s private. It doesn’t send any personal information. There’s no vehicle identification number, no driver’s license number, none of that in the message. I could be standing beside a car that drives by. I can see its license plate, of course, so if I wanted to know who that was I could find out just from the license plate, but there’s no license plate information, no anything like that in the messages themselves. What we’re doing is when the vehicle is traveling along, it’s a moving object. The other moving objects have to know about me so we don’t collide. It receives data from other vehicles in the infrastructure, and again, the vehicle that receives the speed, elevation, and direction and travel. It would receive what the signal colors are now, and it will also receive what the signal colors are going to change. So if it’s green, I’m the driver, I look ahead, I see a green signal. But the car—and we’ll go into this in a little bit more detailed later—the car system gets all of that information, but it also knows when the green is going to end, which the driver doesn’t. We get lane placement and lane-to-phased association like we talked about, and we can also receive traveler information messages. We’ll talk about those. That would be like instead of seeing something that the roadside variable message sign, you could get a travel information message that says there’s something going on ahead of you. But you also receive very, very important—you see the blue up here at the top—is a security service. The messages come with security credentials. That provides trust among vehicles and among infrastructure. All of the security credentials are generated at the right place. The car from the showroom, they come with the 10-year supply of security credentials, the Roadside Units get security credentials, and when they approach each other, they exchange security credentials with public and private keys—we’ll talk about that later—to make sure that it’s authentic information. It’s not somebody that’s just putting something out there because I want to see if I can get the driver to stop. So it provides trust between all of the participants. The whole idea behind this is to predict crashes and signal violations before they occur instead of citations afterwards, and instead of a red light violation camera where you go through and you get a citation in the mail that says “Here’s a picture of you violating the red light three days ago, you owe this much as a citation,” it will tell you about that before it happens. The whole idea behind connected vehicle is letting you know you’re going to do something before it happens. You’re going to violate the light in time to stop. You’re approaching a curve too fast before you do it, that sort of thing.

Dave Miller: So that was the vehicle. The second element is the Roadside Equipment, and what’s shown here is two parts. Two things are called Roadside Equipment. This is all of the equipment that would be at the intersection that participates in the connected vehicle system, all of the equipment, and then a subset of the Roadside Equipment—or RSE—is a Roadside Unit, which is the radio itself. The Roadside Unit would have a wireless radio, as shown here. It has a processing unit with a computer and application software. It has a location service just like the vehicle does, so it receives GPS time as an input. It has a memory for applications to store the security certificates and a map file of the lane locations like we talked about. The cars have to know where the lane placements are between intersections. And then off to the side here, other equipment is a traffic signal controller unit. That’s really optional. If you’re at a signalized intersection and you’re controlling traffic, there’ll obviously be a traffic controller unit there. If you’re at an infrastructure that’s not a signalized intersection—say it’s just a freeway exit ramp, and there’s a lot of issues around the country of drivers getting confused and going up the ramps the wrong way and having crashes—you might have a Roadside Unit out here that just looks for wrong way violations, no traffic controller. There might be reversible lanes. There may be a curved speed warning of a dangerous curve, that sort of thing. You may or may not have a controller unit, so that’s why the map is over here and the application is right here, the controller unit sends a signal countdown. We’ll talk about that in later slides. And then, again, there’s an optional backhaul. You can run a connected vehicle system without a backhaul to a central. You’ll see it used quite a bit because it’s good to manage your Roadside Units, to be able to collect data from them, to be able to push out software updates—that sort of thing—and we’ll talk about that in later slides, but this is a key concept for Roadside Unit. It’s a subset of the whole Roadside Equipment that sits out there and it consists of a traffic control cabinet and then the radio.

Dave Miller: What we’re going to focus on here is the certification process. What I’ve just gone over, you should be familiar with that from the other modules that we already went over, and we’re going to focus on the certification that involves over the air functions of connected vehicle. We’re going to start by talking about communications standards. To be interoperable, we follow standards. For the wireless band, it’s IEEE 802.11—that’s 5.9 gigahertz. The addressing is covered by IEEE 1609.3. The actual language—the messages that go back and forth like signal countdown, bus, signal request, that sort of thing—there’s a message set dictionary: that’s Society of Automotive Engineer standard SAE J2735. How to use those messages into dialogs is Society of Automotive Engineers SAE J2945. Capacities of the channel is IEEE 1609.4. Security and trust is the security certificates that’s IEEE 1609.2. Now, I’ve said a lot of standards here, but just be aware that if you buy a certified Roadside Unit or a certified on-board unit, this is in there and it’s been tested by an independent lab to verify and validate that it does work and it does conform to the standards.

Dave Miller: We’re going to spend a little time on this slide, and this is kind of the architecture, just to show that connected vehicle is built alongside existing traffic control systems. We’re not really disrupting traffic operations. This was all kind of planned out over the past 10 years or so. There’s the ATC 5201 standard that already contemplated separate Ethernet connection for Roadside Equipment. So we’ll show you how all of this goes together. What we start with is the shaded portion here that you see—shaded here at the top—is a typical traffic management center. A traffic management center typically has a wide area network, and you’re connecting to a wide area network of signal controllers. They might be ATC 5201s, model 2070 LX, NEMA TS2, ATC 5202 which is the 2070 style. All of those can participate in this if they all have an Ethernet port so they can get to the expanded outer over a local area network. We’ll show you how that goes. So the signal controller, what we would do first in the minimal form is we would add a Roadside Unit that’s added that sends and receives J2735 messages to and from OBUs, so that’s what we’re showing here. We’ve introduced this Roadside Unit, and it’s sending out the intersection maps, the lane locations, the correlation to phases, and the signal controller here you don’t necessarily have to change the controller. What we’re doing is updating the software. It has to be able to send out a controller broadcast message that speaks what the signal states are now, and then what the signal states are going to be, and what the countdown to this next change is. This is a controller broadcast message. That comes from USDOT V2I Hub Interface Control Document. That is available on the USDOT open source portal, and if you go into that it’s Table 3.4. That is the message that comes out of the signal controller that says what the colors are now, and how long it is until they end and go to the next phase. What we do here is this phase data that comes out is merged with the GPS time and the intersection map file, and then that creates the over the air J27 map and staff messages to the vehicle. So, again, colors now, when do the colors change next? The map is added. The timestamp is map added from GPS. That goes out as the messages. So that becomes the standard messages of the security certificate. Again, we talked about that a lot of CV applications don’t use a signal controller like secure speed warning, collecting agency data, speed enforcement, wrong way, and others, and some connected vehicle applications like wrong way warnings and lane closures may require stat and map without a signal controller. It might not even be in the signalized intersections. We’ll talk about that topic a little bit later, but I’m showing it here as if it were a signalized intersection. Again, a signal controller does not necessarily need to be replaced. You have to have an Ethernet port. If you’ve been following any of the standards in the past 10 years, you most likely have an Ethernet port, and you can update the signal control software so that you get the controller broadcast message. The next thing we’re going to do is we had added a master server. What we were showing before is we would call a solo operation. You can just add an RSU out on a curved speed or a wrong way ramp without a signal controller or without a backhaul. So let’s say we’re building up a downtown area, or we’re putting multiple Roadside Units at signalized intersections. We’re going to have a master server. What we’re going to do with the master server is to go ahead and manage these. This will be sort of the same thing as managing your traffic controllers. This would have ways to update the software in the Roadside Units. It would be able to aggregate messages received from vehicles. So say this vehicle is broadcasting its location heading and speed 10 times a second as it’s driving along. This would pick it up, and from that you could say “Oh, you can count the cars, so this could aggregate traffic volumes just by listening to the cars.” It would get an idea of speeds, average speeds. If five cars go through the coverage area of this Roadside Unit, we would say that’s a count of five or traffic volume of five and the average speed is, say, 36 miles an hour. That could be aggregated together, and then multiple RSUs at known distances apart, you can take the same data and get travel times. You can get traffic volumes, you can get average speeds, and you can get travel times based on just listening to the cars without special equipment. Then the next thing we’re going to do if we keep building this up, the next thing we could do is go ahead and integrate in connected to our transit server. There’s a Society of Automotive Engineers message that’s called “signal request message.” Buses and light rail have been doing these kinds of messages for a long time. We can request a signal, but this gives you a standardized way of doing it. This is a standard message. If the bus is behind schedule, it can say “signal request message.” It’s the same as basic safety, latitude, longitude, heading speed, but here we are adding the VIN number of the bus. This is a commercial vehicle or a public vehicle, so we want to know that it’s authentic, and it should be—it is out there and operating in that area. Then we can extend the green just as we do before. The nice thing about this is that now it’s on the car band. It’s using the same frequencies, so in the future you might be able to use, instead of a transit bus, you could have platoons of say ride shares or automated vehicles, if you want to do that in the future because we’re on the standard message set. Finally, this is the complete built-up architecture of the connected vehicle pilots like the one that’s going in Tampa, Florida. What we’re adding there is the research. If you have a research partner and you want to collect data on what were the incidences, if there were crashes what led up to it. What we’re doing there is collecting large records of basic safety messages from the car. We don’t know who they are, but we can follow the trajectory of the cars. We have a record of what happened. We have a record of alerts and warnings. So this would be a completely built out connected vehicle system. You can start by just adding a Roadside Unit by itself. You can add a master server if you want to manage multiple Roadside Units. You can include transit because there are messages for transit. And then you can go ahead and collect research data, but again, you can see here that this is very loosely coupled. If you took out any one of these systems, if there was a failure in any one of these, they would still run. If a traffic controller happened to go and flash, the Roadside Unit still runs. It still has its map. It can still generate SPaT and say we’re in flash and that sort of thing. If this happens to fail from the Roadside Unit, the traffic controller still runs. The same with the transit server over here. These are all loosely coupled. They’re complete systems. We’ll talk a little bit about how they cooperate in a little bit, but if you want to exchange data here, this is all working at the TMDD level. So this is the NTCIP center to center standards. They operate independently in real time. There’s no single point of failure, but if you want to share data, you can do it up at this level.

Dave Miller: So let’s go into more detail in Certification Testing. The question is why do we need Certification Testing process? Again, we talked about this: it’s the first time connected vehicle safety relies on data from other vehicles. For the first time, it relies on infrastructure equipment at the roadside. It relies on nomadic devices—those are like smartphones or tablets. It relies on detection—it can detect unequipped vehicles—and it relies on detection of pedestrian cyclists, so it must be certified because all of these are all cooperating in one system now. The data must be secure. If you have false positives, that’s a concept of “I keep giving this alert, but nothing happened,’ that can cause safety issues because I’m going to start ignoring it. You said somewhere there’s a bicyclist over the hill, you said that there was going to be a red light when I get there, and there wasn’t, so we tend to ignore them. False negatives are the opposite. That means there was a dangerous condition that the connected vehicle system didn’t detect. So it’s got to be secure. We can’t be putting out false positives and false negatives. The data must be immediate. I cannot emphasize this more. For crash avoidance, a data from vehicle-to-infrastructure and vehicle-to-vehicle must be less than 100 milliseconds old. We’re not at second-per-second, we’re at tenth second-per-tenth second, so the communication is direct. The car talks directly to other cars. The car talks directly to the roadside. The roadside talks directly to the cars within a tenth of a second all the time. It can’t be going off collected at some central, sent some place, and comes back three or four seconds old—the crash has already happened. The data must be interoperable because there’s going to be millions of vehicles over the next decades. There’s going to be millions of nomadic devices. For example, there’s more than 300,000 signalized intersections in the United States, more in Canada, and those all have to be interoperable. The cars go everywhere. And again, the data must be extensible. By extensible, that’s a term for being future proofed. You have to be certain that you’re going to purchase this equipment using your funding that is not going to be obsolete next week or next year. It has to be around for decades, so it has to have a future proofed roadmap. This is a good technology that is extensible because once it become mandated on cars, the cars are going to be on the roads for decades. It’s going to be future proof because that’s the technology that’s going to be in the cars forever. So the only way you can assure this is to have a baseline of standards, and you have to be certified as conforming to those standards. What we’re going to do is go off and develop a certification plan based on relevance, the connected vehicle environment. We’re going to talk about the Roadside Unit and we’re going to talk about the on-board unit, and then we’re going to use the IEEE 829 format. We’ve talked about that in other modules. That’s not really a standard of connected vehicle, but it’s a standard of what your plan looks like, your testing documents look like so that they’re all the same across all of the different ITS projects you’re doing.

Dave Miller: This is the Roadside Unit. This is sort of a layout, and it shows a Roadside Unit would be attached to antennas and it most likely has built in lightning suppression. We talked about a backhaul from the RSU. This has a single category six outdoor Ethernet cable, so there’s just one cable that goes up to the Roadside Unit. It has Power over Ethernet—also known as PoE; you’ll see me use that—and it has an injector in the cabinet. We’ll show you a picture of that. But what we’re doing is it’s a standard Ethernet cable that we’d see anywhere, but it injects 48 volts DC, so it runs the whole Roadside Unit with just Ethernet cable with power and data both. The protocol for the Ethernet interface from the controller to the RSU is described by the USDOT V2I hub Interface Control Document—we talked about that—and the data represents the current state of the signals, the countdown until change, and then maximum countdown until change. Again, that information is timestamped by the RSU and creates the SPaT message, and that goes to the vehicles with the lane correlations. Now, this is basic going you see here. This is the blue that’s shown, here and the blue radio waves that we’re showing that comes from this box.

Dave Miller: The next thing is a Roadside Unit can be integrated with the backhaul system, and we talked about that, to enable remote management of the Roadside Units and provide vehicles and mobile devices with applications delivered by backhaul service providers. Roadside Units can be incorporated with local traffic control systems to control traffic services and other mobile devices. Here, we’re going to go through a high-level diagram of the Roadside Unit, and this rule has a direct short-range communication interface between traffic management infrastructure and vehicles. This is one system that we all know about: traffic control equipment. That operates independently as a system. In-vehicle mobile equipment, that’s like vehicle systems. If you’re driving your car, you have your navigation system, you have your automated braking system or your analog breaking system, etc. That’s a system unto itself. We have a backhaul network, traffic management operations in a traffic management system or an entire city. And then lastly, what integrates all of these together? The connected vehicle direct short range communication Roadside Unit interfaces the three systems together. It creates a cooperative system, so this whole triangle that you’ll see here, this whole thing is what is known as a cooperative system. Each of the three systems runs by itself, but they all benefit from data from the other two systems. For example, the vehicle’s safety messages here can be used over the backhaul at the traffic management center, so then you know vehicle counts, you know vehicle speeds, you know travel times, that sort of thing. The same thing here so, for example, the traffic controller equipment can listen to the basic safety messages where the vehicles are, which direction they’re going, and the speeds. Now we can start controlling traffic by vehicle arrivals and that timing plan. Again, the whole idea here is there are three mature systems out there that work, but once we put the short-range communications between them they become aggregated together as a cooperative system.

Dave Miller: This is continuing from the previous slide. This is a picture of what you’re dealing with when you put in a Roadside Unit. This would be a typical installation. The layout is shown with an RSU and its attached antennas. There’s backhaul from the RSU. Again, we talked about this blue line here would be a category six cable. What we’re adding here is the power of the Ethernet injector. Again, if you have a modern traffic signal controller with an Ethernet, you’d hook that. Or if you have a traffic switch here, you would pick up the data here. The Ethernet injector is powered by 120 volts in the U.S., and then that has its own internal power supply. It has 48 volts under the CAT six cable, and you just install that upon the pole and it gets power and data. So this is pushing out the controller broadcast message with added power to the Roadside Unit, and again, this is showing a signalized intersection. If we were doing like a midblock crosswalk route doing their wrong way on a lane or a curve, we would not need the traffic controller. It would just be running by itself, just a power injector just putting power up to it.

Dave Miller: Again, this has shown an RSU with attached antennas. The protocol for these and the interface from the controller of the RSU is described by the V2I hub. The data represents the current state of the signals, but again, we’re showing here that the RSU is really a processing unit by itself. So what this is doing is once it gets the countdown of the signal, it adds the timestamp, it adds key positioning data, and it’s all enclosed in a NEMA 4-X outdoor rated enclosure, so we can just put it out in the weather up on a pole.

Dave Miller: This is just a quick mounting details just to show how they do—you just put it up on a pole or a gantry. What you want to have is line-of-sight down to the roadways. There’s a common question that comes up: if I have an intersection where I don’t have one particular place in the intersection where I can see all of the approaches, you can put up more than one if you want to do that—several, one or more. You can put two RSUs, so one can see down to the approach that you can’t see with the first one, and they can cooperate as one.

Dave Miller: Again, this comes from the connected vehicle requirements document. This just shows how it’s done. You can mount the antennas external, and we know in Florida and some other places there’s wind load in some places where they want to just put the antennas out there. They want to put the Roadside Unit in a more secure place on the pole, not the antennas on a cable. You can do go ahead and do that if you want to.

Dave Miller: You could possibly even put the Roadside Unit inside the cabinet if you wanted to, and run the cable farther out to the antennas. That’s possible. Keep in mind that the more antenna cable you use, the more loss there is. So just make sure that the decibels of loss in the cable, just be aware that it steals from the range. If you want to do that, you could.

Dave Miller: Again, we talked about this: the antennas have to be mounted for line-of-sight. There are a couple of methods for doing this. Here’s one that was put on the side of the pole with line-of-sight. This is one where you put it on the pole, so you would assume that the vehicles are traveling parallel to this so that the pole isn’t blocking the antennas. And this is one where they actually put it up if they wanted to mount it up on the top of the pole with its only little gantry post out there.

Dave Miller: Again, signal phase and timing. This is where traffic signals are sharing messages between all nearby vehicles, infrastructure, and even pedestrians. The cellphones are sending signal phase and timing in real time, so it matches the vehicles. We actually have pictures of what you see here where you have a video camera mounted in the backseat of a test vehicle. You can see the actual traffic signal in the field of view, and you can see the message for countdown on the navigation screen. You can see that within 50 milliseconds, they’re matched. Again, it’s very, very important that you’re using security certificates and this direct communication between vehicles and infrastructure because you have to get the data there within 50 to 100 milliseconds so that you can get the car stopped. Data that’s one or two or three seconds old is not used for crash avoidance.

Dave Miller: Number two, the on-board unit. Again, there’s three classes of these. If you buy a new car from the showroom that has V2V technology as part of the vehicle system, that would be a Class 1. There are aftermarket installers around the country that will add an aftermarket device to your car. You can bring your car in. You can add an on-board unit and a warning device. That would be called a Class 2. And then a Class 3 would be an application that goes on a nomadic device—smartphone, for example, tablet—and what that does is it participates in the system. Usually the way it’s done is smartphones and tablets have Wi-Fi, so our Roadside Unit would have a Wi-Fi separate radio in it that would pick up basic safety messages from the cars—where the car is, which direction, etc.—translate the Wi-Fi to the phone app and vice versa, where the vehicle is like, “If I’m riding my bicycle, I’m over the hill, or I’m jogging over the hill out in the traffic lane, my smartphone is broadcasting personal safety message on Wi-Fi.’ My Roadside Unit picks it up, translates it to DSRC, and that goes to the cars. The car can plot a crash course and warn the driver that there’s somebody over the hill that you can’t see yet.

Dave Miller: So that’s the three devices, Class 1 new vehicles, Class 2 existing vehicles with an aftermarket device added, and then Class 3 is existing personal advice such as smartphone powered by a rechargeable battery and has the app built into it so it can participate over the Wi-Fi. The car has a standard message that we talked about already called basic safety message, direction heading, location and speed of car and elevation. There’s one called personal safety message that is the same thing for a device, for a portable device, bicycle pedestrian. It broadcasts the same information. Its format is a personal safety message, but the car knows that it’s coming from a personal device, not another car.

Dave Miller: Another little piece here on Roadside Equipment typically includes the extended temperature network. You will see that we had the prior picture of adding a Roadside Unit, and then we put in a power over Ethernet injector. There are ruggedized network switches from a number of different companies that you can put in your cabinet that have power over Ethernet in them. So you can have a traditional switch, and then add a power over Ethernet injector, or if you want to you can just purchase a network switch that has power over Ethernet on one or two of its ports. You just have to look at the network switch, and if it’s compliant with IEEE 802.3at, you’re good; you don’t need to buy an injector. You can just use that.

Dave Miller: So we’re going to go through a little bit of how this operates, just to make sure it’s clear. Say we have a traffic controller sitting at an intersection that’s unpowered; the signals are unpowered. We have a Roadside Unit installed. We have a car sitting there in a parking space. It’s unpowered; the key is off. Let’s start with that. Everything is off. First thing, you turn the key on in the car. Whenever the key is turned on in the car, you broadcast basic safety message. Turn the key off, it doesn’t broadcast basic safety message. All of the time you buy a new car in the future, when the key is on, broadcast location, direction, speed, elevation, 10 times a second, securely, all of the time. The next thing is say now we’re going to turn on our traffic controller so the signal comes out of the flash, starts broadcasting the traffic signal controller broadcast message. Again, that’s on the USDOT open source portal. It’s Table 3-4 of Interface Control Document. Every time the signal is down, the colors are visible, it’s out of flash and running. All of the time it’s running at broadcast what the colors are now, and how long they’re going to be there before they change. So you’ll notice what we did down here is that’s picked up by the Roadside Unit, and then it turns it into the SPaT and the MAP message, just like we said. The car receives that, and I put it down here because what’s really seeing what the colors are now until phase changes, that’s really not visible to the driver. The vehicle system picks that up; the OBU knows about that. So the driver is going to see the colors up here. The cars are going to see the same colors from this broadcast message, but it’s also going to get a countdown to the signal change. So the car system is going to know a piece of information that the driver doesn’t know. If I’m driving towards a green light in the 45-miles-an-hour zone at 45 miles an hour, I’m not going to know that the signal is going to change. I’m going to be subject dilemma zone with the sudden change to yellow. The vehicle is already going to know about that. It’s going to know that there’s five, four, three, two, one, zero seconds left in green, and it can plot that I’m going towards that signal too fast to stop. The driver interface it will chirp and say, “Pay attention.” It’s going to say, “red light.” So that’s the essence of the safety part. It’s not putting a traffic signal in the car so the driver can see it. It’s putting a traffic signal information into the vehicle system, and the countdown to the signal change in the vehicle system so you can create a driver warning to avoid red light violations and T-bone accidents, that sort of thing. The vehicle always sees a digital representation of what the driver sees within a tenth of a second. So we’re not sending data; this is direct communications as shown in these lightning bolts. It’s not going to any server, anyplace elsewhere. It’s just directing indications. The infrastructure also sees this basic safety message coming back. We can see that the vehicles are approaching. You can see in the future the signals are going to be controlled by vehicle arrivals once there’s enough penetration of this technology. Again, this message is integrated vehicle infrastructure, IVP, hub Interface Control Document. You go into that document Table 3-4 and you download it from the U.S. DOT portal, and it will show you what’s in this message. That’s what you use in your traffic control device. There’s multiple traffic controller manufacturers now that have had that much software for a while now. So again, what we’re seeing here is if I didn’t slow down—if I’m still going 45—I still see the green light. If it’s going to change instantaneously and I’m pretty close to the intersection, you would get a driver alert. In this particular case, it’s a rearview mirror where the left side is also a mirror, but if there’s some sort of dangerous thing that I’m doing—I’m going towards a signal too fast, it’s going to be green when I get there—it would pop up a screen on a left side of the mirror through the one-way glass and say, “Pay attention, red light violation coming.” “Person in the intersection ahead” that sort of thing. So again, you’re not really seeing this. There’s no driver distraction from the countdown. You would notice nothing if you’re behaving safely, but if there’s a warning, it’s going to let you know about it. Say, for example, the signals go dark. The way we’re described here, the actual SPaT message is not coming from the controller; it’s coming from the RSU. So if this is in maintenance or it’s in flash for some reason, the RSU still has the MAP file, it still has the GPS time, it still broadcasts the SPaT and MAP message, so the car is going to know that, “Hey, there’s dark signals ahead,” or, “There’s an intersection in flash ahead.” It’s important that all the MAP file and all the message generation is done here. Again, if the traffic signal controller goes down completely, completely dark, this continues to run, so they’re available during controller unit failure, just as if it’s running by itself. That’s the idea behind the cooperative system. This system can cooperate and know that this one is up here, the traffic controller’s not functioning, it can cooperate and tell the driver about it. That’s part of the cooperative feature.

Dave Miller: Again, we talked about SPaT and MAP without a signal controller. Whenever the ignition key is on, SPaT and MAP come out, and again that comes out 10 times a second. The MAP indicates whether each lane can be revoked or closed, so the SPaT messages does the time of day for closure. This might be a reversible lane, or it’s an application that does something that relies on the time of day to change its behavior, but it’s not signal control. It’s not a time plan. What it would do is if the lane reverses twice per day, what it would do is it would broadcast a SPaT and a MAP. The car would receive that and it would say, “Oh, I’m going towards a lane that’s closed now because it’s this time of day,” or, “It’s open now,” so you would selectively get a warning or not a warning based on the time of day. Again, that’s covered in this Interface Control Document, because without a traffic signal controller, we can still broadcast a SPaT and MAP. SPaT would still have timing information that has nothing to do with the traffic controller, and again, the car computer would know about that. So if I’m confused, and I’m going towards a closed lane because of the time of day that it’s closed, it’s going to let me know in my mirror or whatever my warning device is, “Don’t do it,” before I do it.

Dave Miller: We’re going to talk about backhaul communication briefly. This is management from centralized data to and from the traffic data center. Again, this is not really required to make it work—like courtesy warning and some other things—but we use this. Security certificates can be loaded from the RSU manufacturer and use that for pushing out to vehicles if you wanted to do that. The backhaul communication can vary. Some of the Roadside Units have a built-in LTE; some of them just do terrestrial backhaul. But you would put in a separate server, and the reason we’re not really adding any software to the traffic management center, we really don’t want to disturb that; it’s all running. So what we’re going to do is—servers you can add very easily. You can manage Roadside Units. You can collect data from them, like traffic volume, speeds, that sort of thing. You can push out new software updates. You can look at their status, make sure they’re up or down, make sure they’re running correctly, without disturbing this, and we can send center-to-center data between them in the future if you want to.

Dave Miller: This is a little bit more of a complex slide, but again, if you’ve taken the prior modules—especially some of the other ones on this lifecycle—we’re developing a complete CV system. This follows the V model in the engineering process. From a procurement and agency standpoint, you want to do a procurement of your software and hardware objects. You’re probably not going to design those yourselves, so you want to procure ones that are already certified. You want to be able to test them when they come in the door to make sure they work as advertised. You want to integrate software modules into hardware objects; like you want to put your apps into Roadside Units and on-board units. You want to do an acceptance test to make sure it’s fulfilling your use cases. You want to validate the system installed in the Roadside Units. And then finally, you want to do an end-to-end system test. This is really nothing different than you would do in any other ITS project. You do a procurement, you have some software, you have some integration, and you have to do an acceptance test. The only difference here instead of doing the traffic controllers at the TMC are doing Roadside Units and a master server. So it still follows the same V model, and all the master test plans, level test plans we’re used to. We’re just using a different piece of hardware and different software applications now.

Dave Miller: This shows a little bit more of it. At the bottom of the V model, we’re not going to be developing hardware or software. You’re going to be procuring it, so you’re going to go out and find Roadside Units from multiple manufacturers. You’re going to be able to find smartphones from multiple manufacturers. You’re going to be able to find on-board units from multiple. So you put out a procurement specification as you would normally do, and at the device level, when they come in the door, you would have a test. It could be an independent lab certification test, but each individual piece is tested or comes with a test report. You’d put your software into the hardware like you would normally do. You’d put your applications into the Roadside Unit and the OBU to make sure they function individually. You ultimately end up with three subsystems: you have a Roadside Unit that sits at the intersection with its applications; you have an on-board unit over here that goes in the vehicle with its applications; and you would have maybe a smart device, like a phone, with its applications for your pedestrians. Then you’d go to your use cases. I’m putting this at a location with a signalized intersection. I’m putting it at a mid-block crosswalk. So you’d install it out on the street, and then you do your end-to-end test and turn it over to the owner-operators at the top.

Dave Miller: We’re going to talk about security management. So this is to prevent hacking and spoofing of messages, which is very important. If there’s a system out there that doesn’t have this, it’s really not a connected vehicle system. It really has to have the public and private key. It’s a PKI system, so it’s a system that’s known and it works, so it’s covered by the IEEE 1609.2 standards. It has a generation for public and private key pairs. We’re not going to go into the technology of this, but it’s pretty well known. The security credential management system stores and manages the keys and its secure storage of the crypto materials. So the certificates are generated and the private keys are stored in a secure process. It’s a minimum requirement, so it’s a FIPS 140 Level 2. So if you have an OBU—we talked about OBU Type 1 for a new vehicle. So say a vehicle, you bought it on the showroom, it would may come with a 10-year supply of credentials. If you needed more, it would be just like a service. “Change your oil.” Sometimes you’d have to resupply the security certificates. But say it comes with a 10-year supply. They’re consumed at a rate of one-tenth of that many per year. You may or may not have to have them reloaded, but it would be part of a system. It would be like a warning light comes on your car and says, “Resupply your security certificates during your next visit,” whatever. Okay, so Type 2—aftermarket—that would be delivered with a supply, and what we would do is we would reload those from a Roadside Unit. OBU, Type 3—the nomadic devices—those typically would not use SCMS or certificates but if you’re on a Wi-Fi system, we would use the security of the Wi-Fi connections. It would be a similar type of security, and this is typically delivered by the master server. So if you have a master server in place, we would have a secure way to receive the certificates, and then we would have a secure way of pushing them out into the Roadside Units into the vehicles for resupply.

Dave Miller: That was a lot of information. We’re going to do an activity now.

Dave Miller: The question here is: What is the relationship between the RSE and the RSU, between the Roadside Equipment and the Roadside Unit? The answer choices are: A) Roadside Equipment is the direct short-range communication radio to the nearby vehicles; B) Roadside Unit is included in the RSE; C) the Roadside Unit is the DSRC radio that is part of the Roadside Equipment; or D) the backhaul connects the Roadside Equipment with the RSU. I’ll give you a few minutes to think that over and come up with a response.

Dave Miller: The answer is C, Roadside Unit is the radio that is part of the roadside information. That’s the actual radio that’s included with the rest of the equipment. A is incorrect. Roadside Equipment is all of the infrastructure equipment, which is signal controller, network, signal monitor, everything else that would be sitting there is the cabinet. RSU includes the RSE—incorrect. It’s the other way around. The RSU is part of the Roadside Equipment. And D is also incorrect. The backhaul is part of the communications network and not Roadside Equipment.

Dave Miller: Okay, we got through the first one. We’re going to go on now to review the Requirement Specifications for Roadside Equipment hardware and software for procurement.

Dave Miller: This is our Learning Objective 2.

Dave Miller: The DSRC Roadside Unit Specification document is shown here. The current version is 4.1. It’s from the USDOT Federal Highway Administration, and this includes all the requirements for the Roadside Unit. That includes power, environmental, physical, functional, behavioral, and interface. So if you read this, this is a complete collection of all the requirements.

Dave Miller: There are standards for security. That would be IEEE 1609.2: Security Services, and 1609.3 is the MAC address change at intervals, so they rotate. Standards for privacy: J2735; J2945-1, that one’s under development as of this writing; J2945-2, that covers safety and emergency vehicles; and finally, the ISO standard for signalized intersection apps. Then for interoperability, 1609.3 is networking services; 802.11p is wireless local area network; 1609.4 is multiple channel operation; 802.3at is power over Ethernet; and then, of course, NEMA Then NTCIP 1202 v2, plus the U.S. DOT V2I Hub ICD, that is the communications from traffic signal controller to Roadside Unit. And again, we’re just showing all the standards here, and if you buy it, your equipment certified to these standards; you’re okay. You don’t have to run these again.

Dave Miller: So these are the elements we call it the wireless stack. This is the software that goes in the Roadside Unit. We’re not going to go into any detail, but if you read this standard, it describes these; if you read the Requirement Specifications. That’s data security, IPv6. That’s the unique number of addresses per device. Again, we’re not going to go over all of these, but just be aware that what’s shown in these boxes here are everything. It’s a collection of standards that goes into interoperability and certification of the equipment.

Dave Miller: So again, for application that’s traffic to controller—we talked about this.

Dave Miller: A V2I Hub ICD pushes out what the colors are now and the time until change. The Roadside Unit has the MAP, puts out signal phase and timing over 5.9 DSRC.

Dave Miller: Then that puts out MAP messages to car, signal phase and timing to the car. The car pushes back basic safety message. Basic safety messages go to nearby cars, so if one is overtaking from the rear, that would be like a forward collision warning. If there’s a car coming perpendicularly towards it on a crash trajectory from the side, that could be an intersection movement assist.

Dave Miller: And then going on, same thing, coming back the other way.

Dave Miller: In emergency vehicles, there are other messages called signal request message. “I want the green. I’m an emergency vehicle.” Emergency vehicle alert (EVA): if it’s in lights and siren, if the emergency vehicle is in code, it puts out an EVA message, so the car would see it. So it would say, “Emergency vehicle approaching from your rear,” that sort of thing.

Dave Miller: This could be like one that doesn’t have a signal controller. So say this is a wrong-way warning, so the RSU sends the MAP message. The MAP message includes the bit indicating if the lanes may be revocable. If a lane is revocable—say it’s closed by time of day or there’s a construction zone that’s only put out during the night for work and then taken back and put back into traffic during the day—the SPaT message indicates the time of closure as if there’s a red light. So if a vehicle is traveling towards a closed lane or reversed lane or anything that’s wrong-way on the MAP, the driver gets a warning. So I might be driving towards the intersection the wrong way, or driving towards a closed lane. It’ll say, “Wrong way.” So it’ll pop up on my driver warning, “Wrong way.” Or if I’m driving towards an uncontrolled crosswalk, it just has a Roadside Unit there and a pedestrian is walking—maybe not even in the crosswalk yet but just walking towards the crosswalk—it’s going to be telling the driver where that person is all the time, and if the pedestrian and the car are such that they’re going to collide, that would give a warning that way. So again, these are examples of where we would use MAP and SPaT without signal control.

Dave Miller: And again, this would be more like major safety aspects. All of this needs to be certified. That’s what we’re trying to show here is the message coming here, the message is over the air. It’s pretty clear that if I’m driving my car all over the country, all the infrastructure would have to be identical. They have to be certified identically so that it all works as a cooperative system throughout North America.

Dave Miller: We’re going to do another activity.

Dave Miller: Again, we talked about the wireless stack, which is the software that goes in the Roadside Unit. So the question we’re asking here is: Which is not part of the wireless stack? I think we showed that. Is the IPv6 device address part of the stack? Is a basic safety message part of the stack, which shows the vehicle location, direction, and speed? Is the 5.9 GHz wireless frequency band part of the stack? Or is the IEEE 1609.2 security certificates part of the stack? So again, this would be—you’re procuring a Roadside Unit. What has to be certified as part of the stack so that it works, and what doesn’t?

Dave Miller: We’ll go ahead and do the answers. The correct answer is basic safety message. The basic safety message is a J2735 standard over-the-air message, so that’s part of the application. That’s one of the messages that make up dialogs to perform crash avoidance, so that is a message, not part of the stack. IPv6 is the internet protocol address, and it’s included in the Requirements Specification. That needs to be certified. 5.9 GHz wireless frequency band is included in the RSU specification. That’s part of the stack, part of the certification process for an RSU. And again, an IEEE 1609.2 security certificates—use of security certificates is mandatory. They must conform to IEEE 1609.2. It’s part of the RSU Requirements Specification. It’s part of the stack, and therefore must be certified.

Dave Miller: We’ve gone through the first two learning objectives. Now we’re off to the third Learning Objective, which is to understand the role of Certification Testing within the context of a system’s lifecycle.

Dave Miller: If you’ve taken a lot of these other modules, we’re showing how this fits into the overall systems lifecycle. So a traffic controller would have a systems lifecycle, a ramp meter would be. The Roadside Unit and connected vehicle equipment does also. So what exactly are we certifying? We’re certifying conformance of the RSU for this requirements document that’s shown. So the requirements specify—again, we have to do this to make sure that all the vehicles work everywhere within the connected vehicle system, and without certification, you may have a vehicle that’s not going to be able to receive security certificates. If you can’t receive security certificates, you can’t participate within the system. And then the Roadside Unit specification includes environmental references to relevant standards and minimum security requirements.

Dave Miller: So this is a Requirements to Test Case Traceability Matrix. If you’ve taken the other modules, this should look familiar. You may have seen these for ramp meters, you may have seen them for ATCs, but now we’re doing it for Roadside Units. So it still fits into the system’s lifecycle and the V model as if another piece of equipment for roadside, but now we’re doing connected vehicle. Roadside Unit version 4.1 as of this recording is the current standard. Each requirement, as you can see, includes a requirement ID number, requirement statement, reference to the relevant standard, and a verification method. This should all look familiar. This blue bar across the top, and we’re just doing it for Roadside Equipment. It’s important to verify each requirement using the verification method shown. No requirements are listed here within this specification for on-board units. You may mirror requirements for RSU DSRC, so there really isn’t a requirements document issued by USDOT for an on-board unit, but there are Requirement Specifications that were developed during the pilots that mirror what you’ll see in the Roadside Unit but for on-board units. Really the only difference is for an on-board unit we were eliminating the RSU power requirements because it’s powered from a car, and also has 120-volts service voltage. It has automotive power requirements from usually a 12-volt automotive system. It eliminates the RSU outdoor environment requirements and it adds the automotive environment requirements. The rest of the wireless stack and the software requirements are absolutely identical, but there’s differences because now you’re in a vehicle and you’re powered from a vehicle.

Dave Miller: Again, this should look familiar if you’ve taken the other modules. It’s based on the IEEE 829-2008 standard. We would have a master test plan that describes all of the level test plans. You’d have level test plans for the hardware requirements, level test plans for the RSU software requirements, and RSU level test plans for system integration requirements. This should look familiar. You’d have all of these different level test plans at the subsystem level, the unit level, and you’d have the test cases.

Dave Miller: Again, this should look familiar if you’ve taken the other modules. This is the detailed workflow level test plan for unit test plans. The workflow shown here, you would start with a unit test plan. This is the scope of the test, the resources, and the methods would be written down. The detailed updates for test methods are in this one, at the unit test. You have multiple test cases. Again, this conforms to the V model that we did before. In the pilot, our document is called the Comprehensive Deployment Plan that details all this, but again, this would be the same as like we talked about for ATCs; for traffic control; this is for a Roadside Unit. And again, you’d have these different test cases. You could have more than one test case and one test procedure. For my Roadside Unit, I might want to be testing the power of the transmitter and the distance. Let’s say Test Case 1 is what power is it emitting; Test Case 2 is what’s the distance I got from running a field test. You might have one test procedure that tests both of those within one description.

Dave Miller: Again, agencies do not need to create RSU certification test procedures. So FHWA is preparing certification test procedure documents for Roadside Units, and certification is conducted by independent laboratories—we’ll have a separate slide on that here in a little bit on how to do that. As a procurement agency procuring this equipment, we wouldn’t expect you to have to certify this. You would expect that to be done by the manufacturers, and the manufacturers supply the documentation that it’s been done correctly.

Dave Miller: This is like any other ITS project. You would take all the mandatory requirements that are outlined in the Requirements Specification for an RSU or the specification for an on-board unit, but you may have some local needs. You would always require certification to the Requirements Specifications, and you could add your own local needs. In this case, if you went into the RSU Requirements Specification, it says nothing about having a Wi-Fi channel to pick up pedestrians or bicyclists. If you could add that to your local needs it’d say, “I want to procure in my procurements specification a Roadside Unit that conforms to the Requirements Specification of the RSU and, in addition, I want a Wi-Fi channel to be able to receive personal safety messages from smartphones.” So you could do that. It’s the same thing as if you’re doing an ITS project or traffic control, you might ask, “ATC 5201 with these following local requirements.”

Dave Miller: What you would do in that situation is just like any other ITS project. You would identify your stakeholders, collect their needs. What we’re showing here is there’s a need to know where the pedestrians are, so you’d create requirements traceable to the needs. You’d create the design from the requirements, so here we’re saying that we’re required to transmit pedestrian location to an OBU. The pedestrian must receive a location by an OBU. We want the OBU to warn the driver of a crash with a pedestrian that’s maybe not walked out into traffic, or maybe is hidden behind a parked car and walking out into traffic on a crash trajectory. The design would be a dialog of basic safety messages and personal safety message between the car and the pedestrian. The on-board unit would calculate a crash trajectory. The person that’s walking towards the street has stopped, so I’m not going to warn the driver; or the person walking towards the street is still walking towards the street, and by the time my car gets there the pedestrian will be there; tell the driver about it. Then you’d have a master test plan and level test plans. This would be like if you had a local need for pedestrian safety, you could just add this and you could do it as you would do any other ITS project where you review your needs requirements, design and test.

Dave Miller: We’re going to do another activity here.

Dave Miller: The question here is: Which of the following applies to agencies requiring a Roadside Unit certification process? So the potential choices are: A) Develop Roadside Unit test cases per each agency. Does each agency have to develop test cases? B) Specify independent certification test report per the test specifications and list your special provisions for local needs; C) Purchase Roadside Units without any contract requirements; or D) None of the above. We’ll take some time to select an answer.

Dave Miller: The answer is B. You specify an independent certification test with special provisions for local needs. So in your procurement document you’d say, “I want to buy some Roadside Units.” My procurement document said they will be submitted to me with a certification test report per the specification, and I’ve added the following special provisions. For example, what we just talked about for pedestrian safety. Wrong answer would be A. RSU test cases should be uniform throughout, so you don’t want to develop an RSU test case for every agency in the country because then the cars would be different operation and would not be able to work in all the different agencies with different test cases. C is incorrect. We wouldn’t want to purchase RSUs without contract requirements. You can buy them on the market now. Some of them are out there still that were designed to Version 3 of the standard and not Version 4.1, so you want to make sure that you’re looking on the U.S. DOT website for the Requirements Specification and make sure you’re buying it to that document. And of course, “None of the Above” is correct because there’s exceptions in the other three up there.

Dave Miller: We’re going to finally finish up here with our final learning objective which is to develop a Certification Test Plan.

Dave Miller: Certification Test Plan—right now there are three accredited test laboratories which are: Southwest Research, in the lower left; Danlaw, shown in the center; and 7Layers. They have a long history of working with certification of connected vehicle devices. There is a consortium called OmniAir that lists the accredited laboratories, so OmniAir is the consortium. Anyone that has an interest in joining the consortium, where you can get data from the consortium—but they accredit the test houses. Right now, there are three of them.

Dave Miller: Again, this is certification scope. Within our certification, we want to certify environmental ruggedness such as temperature and vibration; we want to certify the communication protocols to ensure interoperability among manufacturers; we want to certify interface abilities to validate the correct interpretation of payloads within the standard protocols; and overall application abilities for interoperability, such as the V2I software object. The software objects have to be certified. The software stack that makes the frequencies and does the communication needs to be certified, and the hardware device itself has to be certified for ruggedness.

Dave Miller: This is a lot, so you don’t really have to know all this stuff, but this just gives you a flavor for how much is being certified. These are all the technical standards and how they go together. All of these layers and all these standards become a baseline of standards that are interoperable. Every one of these standards shown here, there’s a standards committee and there’s a version of the standard, and each individual piece has been changing, but as of what we’re using right now is the ‘16 IEEE standards and the SAE standards of the 2016 as of this recording that we’re doing now, and all of these go together and they make up a baseline. You would specify what is shown here. It’s up to the SDOs—the standards development organizations—to consider backwards compatibility when we’re recommending a standards change. So each one of these standards typically—if you’ve been following the ATC standards—after five years they can be reaffirmed or updated. It’s up to the standards committee to make sure that they’re not breaking any backwards compatibility. They can add some improvements, and if you have something that’s installed today and five years from now the standard changes, that doesn’t mean you have to go out and update your equipment to the new standards. What you have is fine. The new standards should not break interoperability. You can specify the new one. Interoperability is preserved.

Dave Miller: This is a little flavor if you went to a test house and you watched the test being conducted. The test system architecture includes the system under test, and is subjected to automated test scripts from the test system and using the test management software. I know the number and complexity of the tests can be overwhelming. You’ve seen the prior slide of all these different layers and all these different tests; it can be overwhelming. Rest assured, most of the very technical tests have been automated with test scripts and test equipment. So if you went and subjected a unit under test—say like a Roadside Unit—on a benchtop that we put down, there’d be a test system, test management software, there’d be test interfaces that go here, and it automatically runs a number of tests automatically and gives the test results. It’s just a matter, from a procurement standpoint, to make sure you specify that it’s tested with a test report, but a lot of it’s built for automated, and really can be done in a reasonable timeframe.

Dave Miller: This is a list of certification in all the stack elements. If you ran an automated test, it would run a test interface; it would run this suite of tests for J2945-1. I’m not going to read all of these, but there’s a test suite for each one of these. Automated test equipment by and large for most of it, and in the security part, same thing. We would put out a messaging; do positive and negative tests with the security certificates. But this just gives you a flavor of all the test specifications that would be part of it. But again, if you say that you want to be certified to the Roadside Unit specification, it runs through a suite of tests from one of the three test houses. It will come back with a report that shows certification.

Dave Miller: This is complicated, but again, if you’ve been following the other test modules in this series from the ATC and some of the others, you would have an example test. This would be like a test procedure, so it would have a purpose ID, a summary. In this case, it’s broadcasting in continuous channel mode, non-switching. You want to verify the device receives the transmitted message. So test case number one shows a Reference to the sections of the specification; the selection of the M2, M3, and M3.1; and then it shows an initial state, un-power, then repower it, and then it goes through the test steps. This could be completely automated, but this is what an example test procedure would look like.

Dave Miller: Since certification involves independent laboratory tests, devices must be procured. The workflow would be you would contact a certification organization or a certification proposal—and I’m talking about this from the perspective of a manufacturer. Say I design and build and manufacturer Roadside Units. If I want to get my device certified for sale to an agency, I would contact the three organizations; I would get an RFP—request for proposal—how much time, what’s the material, what’s the effort? I would pick one of the test houses. The device would be tested and authorized by the test laboratory. The laboratory test report is submitted to the certification organization and the device is listed as certified. That’s what I would do if I was a manufacturer and getting my device certified, so that if you’re an agency, you could say, “I want to see your certification report,” you would be able to get a hold of it.

Dave Miller: Very important. Since this is new technology, during 2016 and 2017, it’s called the pre-commercial phase. During that phase, through the end of 2017, U.S. Department of Transportation projects are tested to the specifications and checked for interoperability at PlugFest. So PlugFest is what all the manufacturers—if I manufacture Roadside Units, somebody else manufactures an on-board unit. They all get together in a room and we test for interoperability, multiple manufacturers, and uncover differences. So once the CV pilots are established, commercial certification begins after 2017. At that time, the OmniAir trade organization takes over the available test laboratories. So before, during this pre-commercial phase, if you went to a device manufacturer and said, “Show me your certification,” there probably isn’t one because we’re in pre-commercial phase. What you would expect from a manufacturer—an RSU manufacturer—is we would do a Statement of Conformance. We would say, “Here is our written Statement of Conformance. This is the test we’ve run for environmental; here’s a report. This is the test that was run by one of the three laboratories; here’s their report.” Maybe there’s some things that can’t be tested yet, but maybe they were tested by another lab or I did them internally, but there would be a statement of conformance during the pre-commercial phase from the manufacturer to say, “These are all the reports that I did on it. This is my statement of how I conformed to the standards.” Once we’re into the commercial phase after 2017, all the laboratories have their complete coverage of testing. OmniAir, the trade organization, has them certified as being, “Yes, you can conduct all of them.” Then you would have a certification report. Very important during the pre-commercial phase that the manufacturers will give a conformance statement and test report showing what they’ve done, that they’ve covered everything. In the commercial phase later, when OmniAir takes it over, then you’ll have certification reports.

Dave Miller: Very small text here. We don’t expect to read all these. I just put this in. So J2735 describes a protocol of messages, not the application. So if you want to see all of these applications we’ve been describing—we’re not going to go into a lot of the applications; this is a certification module—but if you go to the USDOT Connected Vehicle website, you can find this screen and these blue items shown here, these are all buttons. You can go in with your mouse and click the buttons and, say, for V2I safety, you click that. It’ll do a description; it’ll tell you what red light violation warning is, what curve speed warning is. There’s a menu of all the different things that you can do with connected vehicle equipment. Once it’s certified and you start adding these messages and dialogs of messages, you can do all of these safety, mobility, and agency data and weather applications. So again, I would encourage you just to go onto the website, and if you’re not familiar with these, push the blue buttons and go down into it, drill down, and look at all these different applications and see which ones are applicable to you.

Dave Miller: We’re going to do one final activity here before we wrap up.

Dave Miller: From the previous slide, which of the following is not a connected vehicle application group? Is V2V Safety an application group? Is V2I Mobility an application group? Is Road and Weather an application group? And is Autopilot for Self-Driving Vehicle an application group? I’ll give you a little time to think about that one and select an answer.

Dave Miller: The correct answer is D, and this is kind of wrapping up here where we started. Again, we hear a lot about autopilot vehicles—they’re the thing of the future—but again, self-driving vehicles is an autopilot, is not part of the connected vehicle applications. Connected vehicle applications consist of V2V safety. I’m driving, I’m distracted, and I’m not paying attention. You’re driving. We’re on a crash course. Your driver interface is going to alert you to watch out; mine’s going to alert me to pay attention. V2V. V2I mobility—that’s an application group. In the future, we’re going to control traffic by listening to their basic safety messages. We’re going to control traffic on when the cars get there and not signal timing plans, for example. And again, road and weather. Road and weather is an application group. The connected vehicle pilot in Wyoming across the heavy truck corridor is very heavily involved in the road and weather, so that’s a very important part of the connected vehicle initiative.

Dave Miller: We’re going to wrap up here and summarize. Our first learning objective is we did identify connected vehicle equipment needed for signalized intersection. We showed you pictures of what goes in the cabinet—the power, Ethernet injector, etc., Roadside Unit that goes up on the pole. We reviewed the U.S. DOT Requirements Specifications for hardware and software. Again, that is available on the U.S. DOT website. That’s a requirement for an RSU, and we described to you that for an OBU, there is not really one you can download from U.S. DOT, but there are Requirements Specifications coming out of the pilots from the manufacturers. All the parts that communicate from Roadside Unit to on-board units are identical, but there’s differences in power. Instead of 120 volts or 40 volts, the vehicle system. So there’s differences in power and environmental because environmental for a car and environmental for Roadside Unit are different, but the actual interoperability part is identical for both the on-board unit and Roadside Unit; they just differ in power and environmental requirements. You now understand the role of Certification Testing within the context of a system’s lifecycle. It’s very similar to what we went through in the other modules for the lifecycle of a traffic controller, ATC 5201, and now we have Roadside Units and on-board units. We go through the same Certification Testing. We have needs requirements, procuring of equipment, testing of each module, testing of subassemblies, and then finally putting them on the street doing dialogs of messages for the safety and mobility systems. And then finally, we showed you how you’d develop a Certification Test Plan, which is, during the pre-commercial phase, the three test laboratories are developing all of the 100-percent coverage to the requirements, and that the manufacturers, in the meantime, will issue a conformance statement showing all of the tests and their test reports that they have. Once we go into the commercial phase long-term, the OmniAir trade association takes over and laboratories take over for all certification and certification reports.

Dave Miller: Now you’ve completed the connected vehicle curriculum. Again, module CV I261 was V2V. That’s the on-board unit for project managers. You’ve completed I262, which was V2I, so that’s the on-board unit to the Roadside Units; that’s the standards for project managers. And now we’ve completed CV T160. That’s connected vehicle certification and testing introduction.

Dave Miller: We’d like to thank you for completing this module, and we have the feedback link below. You can apprise us of your thoughts and comments, and thank you for attending.