(Note: This document has been converted from the transcript to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included.)
Ken Leonard: ITS Standards can make your life easier. Your procurements will go more smoothly and you’ll encourage competition, but only if you know how to write them into your specifications and test them. This module is one in a series that covers practical applications for acquiring and testing standards-based ITS systems.
I am Ken Leonard, director of the ITS Joint Program Office for USDOT and I want to welcome you to our newly-redesigned ITS standards training program of which this module is a part. We are pleased to be working with our partner, the Institute of Transportation Engineers, to deliver this new approach to training that combines web-based modules with instructor interaction to bring the latest in ITS learning to busy professionals like yourself.
This combined approach allows interested professionals to schedule training at your convenience, without the need to travel. After you complete this training, we hope that you will tell colleagues and customers about the latest ITS standards and encourage them to take advantage of the archived version of the webinars.
ITS Standards training is one of the first offerings of our updated Professional Capacity Training Program. Through the PCB program we prepare professionals to adopt proven and emerging ITS technologies that will make surface transportation safer, smarter, and greener, which improves livability for us all. You can find information on additional modules and training programs on our website, ITS PCB Home.
Please help us make even more improvements to our training modules through the evaluation process. We look forward to hearing your comments. Thank you again for participating and we hope you find this module helpful.
Raman Patel: This is Transit Module 11, “Transit and the Connected Vehicle Environment in the Emerging Technologies, Applications and Future Platforms.” This module has been updated from the previous one and contains current information.
My name is Raman Patel. I’m your instructor for this module. There are five learning objectives in this module. The first one is to describe what the Connected Vehicle Environment is. The second one will identify potential communication technologies that may be used in a Connected Vehicle Environment. The third one will deal with the standards, what are the types of standards that we need for these applications. The fourth learning objective is about describing certain types of transit specific CV applications. And the last one, we will identify certain challenges and approaches to successful deployment of transit specific CV applications.
The first learning objective is the Connected Vehicle Environment and it consists of various things. The key one is the V2X, vehicle-to-everything. That means vehicle-to vehicle, V2V; vehicle-to-infrastructure, V2I; vehicle-to-pedestrian, V2P; and also the communication backbone which is the wireless medium that we use for Connected Vehicle applications. And it’s to make sure that both local short-range communications and also remote communications to devices in the field through traffic management center. And the third component and major one is the applications themselves. These are Connected Vehicle safety and mobility applications that we deploy.
There are three transportation challenges that are being addressed with the CV applications: safety, mobility, and environment. In terms of safety, we have over 6.5 million crashes a year; some 7,000 plus transit crashes alone. Fatality, 36,000 plus in 2018 and of which almost like 6,300 pedestrians or 17 percent are attributed to pedestrian casualties. Over 6 million wasted hours in 2018 and also the damage in the environmental aspects of carbon dioxides and all that.
So we have set certain objectives to deal with these challenges, reducing crashes by 20 to 80 percent. A certain type of treatment for reducing congestion leading into 15 to 40 percent range general improvement in mobility. Also, automated driving aspects of the mobility facilities that we are working with. And hopefully, the reduction in general aimed at about 10 percent.
Looking at the specific to transit vehicles, we come to realize that transit vehicles in the operating environment has certain different type of challenges to deal with. And if you look at the size, the frequent stops the bus has to make, for example, stopping at the bus stops, the pedestrian movements, and all those things present quite a bit of a challenge for vehicle-to-pedestrian safety challenges as we might say. The pedestrian fatalities since 2009 has increased at the growth rate of 40 percent. Currently, 6,283 fatalities.
There are certain applications that are aimed at transit-related improvements. Three of them are highlighted here. VTRW, vehicle turning right in front of a bus, and that’s a warning application. Pedestrian Crossing in the Crosswalk is the PCW applications. And then Transit Signal Priority, TSP, at the top. So these are key applications listed her in all aspects of Connected Vehicle objectives. Safety, mobility, and general improvement so that we can deal with certain specific issues that we are facing in transportation.
So what has changed? Well, the first internally stored used for in the past vehicles by sensor, for example. Data such as speed, position, they’re all internal data but they are within the vehicle itself to improve the safety, right. So now, we have no one is aware of one’s presence on the roadways, for example. So that has changed.
Now with the Connected Vehicle ability, we have brought the capabilities to provide this information about the presence of a particular vehicle to all other vehicles. In other words, sensor-based data that vehicles were internally storing now is also available to other vehicles in the mix. So for example, if you transfer the position of the vehicle in the vicinity, other vehicles will know about it. So that is the general change that has occurred on the roadside.
Also each of these drivers of the vehicles are not aware of each other’s presence. They don’t have formal contracts or their ability to interact with each other by exchanging information about themselves and their presence, we are now improving the ideas to the next level, which is generally known as Cooperative ITS—C in front of ITS, we first do C-ITS—it means cooperative ideas.
Ad-hoc roadside wireless connectivity has now arrived. That is what we want to say. In the sense that all vehicles are now becoming nodes that can contact each other and exchange and transfer information and say, “this is where I am position-wise.”
And so let’s look at some of these examples that might make it a little bit more relevant. And these are all contact-free applications. No kill nodes. They don’t know each other. The presence, there are no contracts between the vehicles. There are no MOUs (memorandums of understanding). So this is a contract-free operations. At the top, in the middle top, we have two vehicles are shown. These are the nodes. All of these vehicles actually become a dynamic node and behave as such within the network.
So there is a basic safety message that the application produces inside the vehicle and these application messages are very short data packets and they’re frequently—like 10 times per second—broadcasted and all of the vehicles are aware of these messages. And they create 360-degree awareness. Take a look at this photo. On the left, it’s getting collision alert and it is coming. The alert inside the vehicle is produced by the application shown here on the right photo and it’s called a Forward Collision Warning, FCW. So the front of the vehicle is trying to stop, or about to stop, the vehicles in the back. The red vehicle and the blue, they are not aware of it, but with this application they will be aware of it in general.
So that is the applications benefit. So basic safety messages conveys data and then application takes from there and it determines whether a collision is about to occur or not. And if there is a threat then it is communicated to the vehicles behind or in front. And all these vehicles are now aware of each other’s presence. So if this blue vehicle is here—I’m showing on the right side photograph—this vehicle will be now aware of the vehicle stopping in the front.
Let’s look at a couple of more examples. At the right—sorry—at the left, you will see the lane changing warning and the blind spot warning. In the top middle, you see do not pass warning, as vehicles are now aware of each other’s presence. And then, we will also see the emergency brake light being applied and other vehicles are now around in the middle of this image. The two on the right-most side of the slide, you can see the forward collision warning as we just saw previously and each vehicle is now aware of other vehicle’s presence and they are about to benefit from each other’s stopping and any other hazards that might develop.
Here in this demonstration we are looking at V2P, vehicle-to-pedestrian. So the driver inside the vehicle is now aware of pedestrians standing in the crosswalk and that’s the benefit that driver gets right here as shown inside the vehicle in the mirror. There are several devices that work within the Connected Vehicle Environment, operational devices. They are known as onboard unit. They are vehicle-based. All vehicle-based devices are called OBU, on-board unit.
And these devices, they transmit and receive messages from each other in the vicinity, right. And the applications on-board processes data and determine if there is a threat that exists and if so, then it issues warning and the drivers actually get that warning and take action. And that’s the benefit.
So this device is shown here, on the left, is actually also OBU but it’s a different name and sometimes referred to as aftermarket safety device, meaning that that device was installed after the vehicle actually was made or manufactured. The second device in the CV environment that operates is the RSU, roadside unit. This unit also transmits and receives messages from other OBUs in the area, in the vicinity, and it’s generally mounted on the mass arm or on the pole, and that covers that area around about 300 meters range.
Third device that works in this Connected Vehicle Environment is called RSE, roadside equipment. This is generally a roadside traffic controller type of device you see in a cabinet and it houses all other types of equipment in it, like GPS and connection to the internet and this traffic management central system and all those things. And they are also communicating within the roadside environment.
What the transit managers should know about Connected Vehicles. Well, let’s start talking about saying that these vehicles—there is a whole set of new type of vehicles now coming in and they are smarter and safer. So V2X is the term that we refer and V2V has now opened up. You begin—the whole process begins with the V2V, vehicle-to-vehicle and leads into V2X, meaning we do infrastructure, V to pedestrians, and all of the transit customers are now impacted. So that has brought a significant change in the transit Connected Vehicle Environment. Dealing with OEM, original equipment manufacturers, and also the after safety-devices. For example, buses are now being retrofitted with the ASD devices.
The other thing that transit managers should be aware of is that customer requirements have changed. Their needs have changed because their focus is now grouped around specific information that they are looking for. In these images we are showing, there are several things that are happening. Mobile ticketing. You have vehicle tracking application at the bottom. In the middle, you have trip planning and transit on demand.
All of these applications are new and they are widely now being used. So the customer’s needs have changed and now we have a new set of technologies making that possible. So as the transit system manager, we have to know what are the technologies that’s going to change? Like we are talking about fifth generation of telecommunication devices as well now with these smart phones? So we have to make sure that we understand the needs for standards. And how can I set up my Connected Vehicle standards so my future design will also work with what I’m doing now? So that is a main point to take away from this discussion here.
The example here is transit signal priority, TSP. Well, this example is from Chicago area and here they have 300 million bus trips made each year. And generally, with the TSP application, you are allowing buses to get time extended for their journey so they don’t have to make frequent stops. That improves, in general, the on-time arrival time. Also the dependency, like travel time dependability, it’s reduced travel times. And also overall, the fact is the increase in ridership. These are the benefits the Connected Vehicle program has brought to TSP application through to TSP application.
Another area where we have application potential benefits available is the transit CV environment that offers highway-rail grade crossings. V2V, vehicle-to-vehicle and V2I, infrastructure. In 2018, we had over 685 crashes then and 281 fatalities at the grade-crossings with the railroad and that is the application that we are looking at in terms of how we can reduce this crisis by providing warning.
So if the train is approaching at a certain speed and the vehicle is trying to cross the crossing, that is going to be a warning issued and the driver will stop and hopefully everything will be smoothly conducted in the timeframe. So this is a potential application that is being available for the Connected Vehicle.
Let’s have our first activity. Which of the following is an incorrect statement related to CV applications? A) Onboard unit, OBU, is required for V2V communication; B) roadside unit, RSU, is required for V2I communication; C) only ASD broadcasts basic safety messages, BSM; and D) V2X includes all forms of communication services.
Okay. Let’s look at the answers now. The correct answer is C because the statement is false.
Functionality of both OBU and ASD are the same. ASD is after-market safety device but its functionality is the same as OBU. Answer A is incorrect because it is true, OBU does transmit and gives you vehicle information and it is required. RSU is also—in answer B—is also required for V2I communication. And D, V2X, includes all forms of communication. V2X includes V2V, V2I, and V2P. And it applies to both DSRC and any of the type of approaches we might have in communications such as C-V2X.
Our second learning objective is to identify potential communication technology that may be used in a connected and transit CV environment. So Wi-Fi, for example, Wi-Fi stands for wireless fidelity. That is a short-range radio operation; small devices we have in the offices or house environment. The data is very small; 6-54 Mps. Bandwidth is also small and it is based on IEEE 802.11. Wi-Max on the other hand is for long distance and it is about networking. So this is widely used and the data rate is also very good in terms of all the things that we are trying to do in using the internet. And it uses IEEE standard 802.16c.
The long-term evolution or LTE is another form of communication technology that has now emerged, beginning with 1G in 1979 through 2G through 3G in 1998 and since then, we have 4G. 4G also has Cloud, IP and Truly Mobile Broadband Replications available. And also it introduced C-V2X with Release 14 which is itself is now, 4G itself is now going into 5G transition and sometime in the near future this will occur through the Release 17 which is called New Radio or NR. And this is a form of 5G application that will enter in coming years.
3GPP, Third Generation Partnership Project, is bringing the general concept of cellular C data, which is the 3GPP specifications and C V2X or cellular data approach is now also including infotainment, large file transfers, vehicle-to-center communications. And it has now sort of come out with this concept, which is a communication technology as a proposed—as a replacement for some or all forms of 5.9 GHz spectrum assigned to WAVE (Wireless Access Vehicle Environment). But it’s still used for ITS. So that is our second approach to providing communication technology. C-V2X also enables network independent communication through PC5 interface and also it enables network services through another type of V2N-UU interface in a license band. So it’s pretty up-to-date in terms of what the telecommunication industry has evolved into current environment.
Competing CV alternatives, we have to keep in mind the DSRC as it is known, dedicated short-range communication in the U.S. And it’s defined by IEEE standards (WAVE), a physical layer 802.11, p standard which is now 802.11. Dedicated radio spectrum that FCC (Federal Communications Commission) has granted. So the first alternative is DSRC, as shown here, which is now being deployed in the U.S.
A second alternative is emerging and it’s a new technology and it’s defined, as we just discussed, by 3GPP Release 14. It is dedicated radio in 5.9 GHz spectrum and additional radio in the licensed cellular band as well. So this is the second alternative that’s in front of us available for Connected Vehicle application.
A potential third alternative that may emerge is the combination of both DSRC and C-V2X. FCC has now taken under consideration to reallocate the 5.9 MHz—sorry, GHz band into combination of both DSRC and C-V2X. And what they’re proposing might be helpful in terms of accommodating C-V2X towards the far end of the spectrum shown here. In the middle, you have C-V2X and DSRC combination available. And then in the context of how these technologies can work, the key factor is the latency.
Latency is a measure of time delay experienced in a system. For example, we discussed earlier the FCW’s application has a limit of 0.1 second. That means it’s a fraction of a second the message or the warning has to reach to the driver inside the vehicle. All of these technologies that we discuss are capable of providing latency, low latency environment so that CV applications can be broadcasted and DSRC has slight advantage compared to other technologies.
So what are the requirements for—communication requirements for DSRC? In general, there are five requirements that we have here listed. 5.9 GHz spectrum is dedicated for this purpose. 1609, IEEE 1609 wireless access standards or WAVE standards as they are called, that are required. Security Credential Management System, SCMS, is required. RSU and OBU which are the devices that operate in the CV environment will be required. And finally, 802.11 standard to conduct the radio operation at the physical layer is required. So, these are five key requirements that play within the CV environment.
Current channel assignments in the U.S. given by FCC begins with the service channel SCH 172. This channel is dedicated for public safety application, for example, collision warning we discuss earlier. Then you have downloading application software are conducted on channel 174 and 176. In the middle, we have CCH 178 which is the reserve channel only for control purposes. It doesn’t contain any other than control messages. So the information is very restricted on this channel.
Channel 1, SCH channel 180 and 182 are for uploading purpose, such as mobility information, performance logs, all those things can be uploaded using these channels. The last channel, SCH 184, is again reserved for emergency vehicles for high-power long-distance kind of applications. Channel switching is an issue because DSRC radio broadcasts on one channel at a time. This is a constraint in the technology that IEEE do appoint 11 level. So we have a dual radio configuration solution here proposed and being used as OBU.
Now OBU contains two radios, capabilities inside, and radio one is always on safety channel 172. This channel only transmits and receives messages for listening purpose for basic safety messages, okay. So the capabilities are very good but they are restricted to basic safety messages.
Radio 2, which is now open to other channels: 174, 176, 178, 180, 182, 184. These channels can be operated on this radio 2 and they are listening for other type of messages such as traveler information, traffic information, and any other most messages that you might have or information might be available. So this is a dual radio solution is required through channel switching.
There are advantages for DSRC, there are certain advantages. One of them is that it is a proven established technology. We have been testing it and sustainability is pretty good. It’s no subscription. It requires no data plan, no subscription in terms of fees. And also low latency and higher data rate, 3-27 Mbps.
Certain disadvantages are also worth noting. It requires government support. Limited spectrum so therefore the channel congestion; as we just discussed there are only 7 channels. And potential impact on channel 172. 172 is a safety channel reserve and if all safety messages and if everybody’s trying to access that channel at the same time, then you have an issue on missing out on 172.
Other potential issues are retrofitting vehicles. There are limited RSUs out there deployed today. Spacing, 300-meter distance requirement, and that is an issue as well and challenged for example in maintaining all of these things. And it’s a long-term burden. So such issues needs to be identified and understood in the proper way.
The activity now we have for this learning objective 2: which of the following is not a current attribute of DSRC? Low latency, A; B) no subscription required; C) widely deployed in vehicles; and D) short to medium range. Let’s look at the answers.
The correct answer is: C) widely deployed in vehicles. It’s correct because at this time there are relatively few vehicles equipped with DSRC. As time moves along and now DSRC’s engaging and testing these deployments, so this situation will change. Answer A is incorrect because low latency is the benefit of DSRC. B is also incorrect because DSRC does not require subscription which makes it more accessible. And D was also incorrect because short to medium range is the core characteristics of DSRC.
Learning Objective 3. Let’s review some of the standards that have been used in that and what are the requirements at minimum to provide the best support in a Connected Vehicle Environment? There are three types of standards. Transmission standards for wireless connectivity. That includes IEEE 802.11, radio operation, IEEE 1609, WAVE operation for wireless connectivity. Second type of standards is interface and dictionary standards. These are developed by SAE J2945.xfamily, that’s for interface standards and SAE J2735, that’s DSRC messages are set according to this dictionary provided by SAE (Society of Automotive Engineers) standards. The third type of application standards that we have been using in transit environment are also useful in the overall concept of operations.
So TCIP, for example, SIRI, Service Interface for Real Time Information, GTFS Real Time. These standards have been developed and also because there are certain modules, training modules available in the PCB (Professional Capacity Building) program so I recommend that you look at them closely and I’ll see if that helped you in understanding where these applications might be useful.
Let’s look closely at IEEE 802.11. This standard has been revised in 2016 and it describes specification for wireless connectivity using DSRC services. ASTM 2213 is now part of this. This standard has been withdrawn and ASTM standard now is part of the 802.11 2016 version. Media Access Control or MAC, the message protocols that allow application to connect directly to the physical layer for radio operations before it goes all there.
So PHY stands for physical layer and it’s the radio chips and all the physical environment that we are talking about. 802.11 enables ad hoc wireless communication with 1609 family of standards. Without these two combination of 802.11 plus 1609X, we cannot have CV environment that will be wireless in general. The set of standards in 1609 family are listed here. The first one, 1609.0, is the guide or the architecture. It was revised recently in 2019 and 1609.2 has a security service application as well as management messages. And it also adds the SCMS for the security purposes and the work is in progress. 1609.3 deals with the network and transport of layer services. 1609.4 deals with multi-channel operation.
As I just mentioned earlier, that channel switching is a key part of the Connected Vehicle operations and this standard, 1609.4, is the core standard that’s being used for that purpose. 1609.12 is identifier. It allocates the IDs and all the other general management and operational requirements that this family of standards had. There is a module going to be CV 265 that deals with 1609 WAVE standards. It’s under preparation and I recommend that you keep an eye on that and look at that as when that thing is available.
SAE J2945.x is a set of performance standards. It sets all the requirements, how to use management facilities, security, implement specific application, identifies use cases, and it also sets the performance and functional requirements. Using system engineering process, for example, what, when, how often a message is supposed to be sent, what are the limitations, minimum, maximum, what are the quality requirements, security requirements, dialogs and data and also the traceability requirements and traceability metrics. These are key components that have been provided by this series of standards based on the systems engineering process that we have used. These standards are pretty much completed and they provide all sorts of information that we need to put the system engineering process together.
SAE J2735 is the DSRC Message Set Dictionary. It defines data structures. Data elements are primitive objects. For example, speed, longitude, latitude, three-dimension position that can be created, acceleration—these are all the objects that are contained in these standards in the standard formats. Part 1 is the core data elements. It contains basic safety messages related. These data elements are very frequently 10 times per second are broadcasted so that other vehicles are aware of it.
Part II, type of data elements, are added to part 1, such as break status which are not frequently broadcasted as—and when it’s required—and then a combination of part 1 and part 2 makes up all the data elements used in Connected Vehicle applications. Data frames is a collection of data frames. And messages are a collection of data frames and data elements. Certain messages that have been produced by the J2735 standard for CV applications are listed here.
For example, basic safety messages are here that deal with the SPaT, the signal timing and paging information, FCW we mentioned earlier and there are other general applications that are being used listed here including, for example, signal request message, SRM and also ability to test the messages. The format of the basic safety message is also provided by this dictionary and the J2735 CV standards that includes all the different elements that we have just mentioned like, for example, position and velocity and everything about the vehicles’ data.
The summary of standards can be best explained by saying that OBU, the on-board unit shown on the left and the one shown on the right are communicating through DSRC radio operation using air interface. So that’s an interesting way of saying that two vehicles are now communicating using air interface, which is now radio operation. And also RSU, the roadside unit which also communicates to the same air interface and thereby communicating to the OBUs in the vicinity.
The WAVE protocol stack is discussed and provided detail about that protocol in the supplement, but here I think two things needs to be pointed out, that critical application messages are processed by WSMP. WSMP is a short WAVE—short message protocol—and that contains, for example, BSM. BSM is now transmitted using WSMP. There is also IP, the traditional internet IP 4, IP 4 and IP 6 protocols are also present and they can be also used, the stack can be used also part of this process. So you have ability to not only create messages through OBU and RSU but also the ability to transfer messages to each other in the mix in a Connected Vehicle Environment.
Our activity here for this learning objective is: which of the following is not a wireless connectivity standard? A) IEEE 1609 family; B) SAE J2735 data dictionary; C) APTA TCIP; and D) IEEE 802.11.
Okay, let’s look at the correct answer. Well, first and then the others. The correct answer is C. It’s correct because TCIP is an application-oriented standard for transit and it’s not required for wireless functionality. A is Incorrect, because statement is true. Actually, we do need 1609 family, without which we cannot have wireless connectivity. Similarly, B is also incorrect because J2735 is a dictionary standard that actually provides the range of messages including the BSM message. And D is incorrect because the standard 802.11 is the baseline standard for radio operation at the lower layers. At the physical layer, medium. So that’s important.
So learning objective 4 now is to describe the application being developed in a transit CV environment. Let’s start the discussion with the case study. At this intersection, go ahead and familiarize yourself and look at it. This is a typical urban intersection where you have pedestrian activities, you have transit buses making turns, going straight and you have people standing in the crosswalk. So even after making transportation improvement at this location—for example, in this case study, we have some that a person actually had lost her life at this location.
Now look at this example here. As it shows that Mr. Torres was working at 6:00 AM and he seems like he’s familiar with this intersection and he’s frequently using it and even after making the intersection improvements according to this case study example here, the second person lost his life in the crosswalk. So [the] question we are asking even after making traditional traffic engineering improvements, can something else be done to avoid or to create condition in which bus drivers, for example, can be warned about pedestrian crossing in the crosswalk?
Keeping that in mind, there are two applications that—Connected Vehicle program application safety applications—offer VTRW, vehicle turning right in front of a bus. And second one is PCW, pedestrian in crosswalk warnings. Both of these applications, as you saw in this case study that we discussed, can be helpful and we can potentially avoid future hazard and as well as issuing warning and thereby eliminating collisions as well as pedestrian conflicts. Keeping that in mind, New York City case study for example is showing here that the 1500 MTA transit buses are now being equipped with these applications on heavily traveled routes.
Here’s a second example from Cleveland Regional Transit Authority. They have Enhanced Transit Safety Retrofit Package Project which includes 24 transit vehicles, which deploys E-VTRW, E, stands for Enhanced VTRW. And it is a V2V kind of conflict removal application.
On the right here, you have pedestrian crossing warning, E-PCW, which allows the driver to see the pedestrian movement at the curb or in the crosswalk and this is an expanded view of the same location and you can see the driver is able to see what is happening outside of the vehicle in the crosswalks and be aware of it. So both these applications are potentially very beneficial as it is suggested here by the evolution of this project. So the warning issued by the applications alerts were 80 percent correct, 10 percent were incorrect, and only 9 percent were false alerts. And 16 percent increase in drivers braking response.
So the last one here, 16 percent shown, is actually a good benefit because now driver is able to intervene and avoid the pedestrian to bus conflict by breaking in time. And that warning has been issued by the application to the drivers. So the V2I transit safety application, TSP as we have earlier discussed—this is another example in New York City, for example, this is a large site TSP application. You have significant area-wide coverage provided by this and the benefits coming from this are again on time arrival, a reduction in travel time, reduction in number of stops, and general improvement in bus ridership. So these are the benefits being brought to urban areas in the dense-populated areas where you can apply this bus moment type of activities through TSP applications.
For activity for this learning objective is to answer the following: Which of the following is not a transit CV safety application? A) pedestrian turning in front of a bus warning, VTRW; B) Enhanced Forward collision warning, E-FCW; C) highway-rail grade crossing; and D) transit signal priority, TSP.
Let’s look at the answers. The correct answer is: D) transit signal priority. It’s correct. If a TSP is a V2V, vehicle-to-vehicle, and V to Infrastructure, V2I, mobility improvement application. A is incorrect because VTRW avoids potential conflict with pedestrian movement. B was also incorrect because EFCW issues a warning alert avoiding potential V2V collision. And C, highway grade crossing answer, is also incorrect because it is a potential use for this application having impact on collisions.
Let’s look at our last objectives now. Learning objective 5 is to identify certain challenges and approaches to successful deployment of transit CV environment. The types of challenges in the key areas are now reviewed in the sense that certain user groups are affected by certain type of challenges but here collectively you can identify role played by transit agencies, managers, road engineers, maintenance staff and so on and all of these regional groups of participants are now should be aware of certain issues.
For example, institutional framework, technology, system integration issues, procurement and deployment issues and the last one is security. Security is very important but it’s listed here as a project requirement in terms of how technically is being handled. But the other four on the top needs to be put in a proper context early on in the project when the project begins because these are preparation type of requirements that we have.
Institutional framework requirements. There are jurisdictional partnerships. There’s a transit and traffic interface, for example. Buses are transit operations. Signals are traffic operations. Data moment between these two jurisdictions are also important. Maintenance issues. So we need a very good level of partnership between these different agencies in terms of managing data as well as keeping control on the operations there as intended. So TMC (Traffic Management Center) backhaul data processing, coordination of infrastructure deployment, collection of data, sharing data and reviewing what is working, what is not working, all of these things goes right back to the jurisdiction partnership.
Technology challenges. DSRC is the foundation work. NHTSA (National Highway Transportation Safety Administration) rules applies only to V2V, it does not apply to V2I. And we need to understand that mandate for V2V is very specific. Also the devices used in Connected Vehicle Environment must speak the same language.
Roadside unit and onboard unit must be properly coordinated in terms of data elements used. There are messages conveyed to each other and standards used in all of these things. So these requirements are related to DSRC technologies but, in general, they also apply in any of the other applications that we may be using in the Connected Vehicle Environment.
Expertise and training needed to resolve implementation issues. This is a key issue at the level of staffing as well as the training and testing. So the survey conducted in this Cleveland project, for example, was what challenges did you face during implementation of the system? It’s a typical question that we normally get to ask.
The answer is in this case Controller Area Network (C-A-N or CAN) information addresses very—or across the same model of buses that require more coordination with bus manufacturers than anticipated. A typical answer, for example, in system engineering context because you have several technical activities going on and this issue is very important to understand upfront. Engineering challenges are typical of integration work.
System integration challenges, there are multiple vendors involved in this process, so we have shown here for example Vendor A on the right interfacing RSU. This is a device that’s procured and it could be a solid state traffic controller, electronic base and it has different kinds of port mechanisms. For example, it has internet ports available as well. Then you have roadside unit, RSU. It’s probably furnished and installed by Vendor B and that is out in the field. And then on the left side, you have a bunch of activities that relate to different types of vehicles in the mix: taxi, on the top, bus in the middle and you have large trucks shown here at the bottom.
So all of these different devices call say, after market safety devices. They come from different types of vendors. So if you look at it in terms of A, B, C, three different types of vendors, the coordination between these vendors is real important issues and that requires very careful attention during the project as well as when you prepare—make the preparation for the project.
Other deployment challenge that we have is the procurement in terms of what is needed. And if you look at that in the way of staying outside of the vehicle, what are the issues or challenges that we may have to identify? Well, the bus stops X infrastructure-wise, the cabinet space available, power supplies 24/7 requirements. Not just certain time but the power supply should be available so the electronics can continue to work. And of course, the link to communication, link to central traffic management center or transit dispatching center, such issues are outside of the bus and they should be addressed during the procurement process.
Inside the bus or inside the vehicle there are several electronic pieces sitting there as interface. Traditionally you have 802.11 radio, DSRC radio. You have a cellular radio that works with the outside connectivity. You have also the mobile MGR, mobile gateway router, that connects to the CAD and AVL, the traditional electronics inside the bus. So we have at least four different types of interfaces present.
And the one not shown here but it’s coming our way is also the new generation of CV redirects, a new radio. So you have several types of interfaces that we need to be aware of it and as we discussed earlier what the transit manager should do, should prepare for this kind of activity and understand that the design now will affect design in the future. So, making your approach future base consideration or future proof is a takeaway from this discussion, that these challenges are there and we need to address them now and be ready for the future as well.
Another example that’s worth talking about is the transit bus retrofitting in terms of a challenge. Trying to bring all these different components together and test them and make them work together, operate them as intended and within the radio frequency environment. Antennas which cannot be drilled through the roof, not allowed. And somehow we work with all these different issues and create an installation template, meaning that all issues have been ironed out and now we are ready to use one template everywhere else. So this is a good challenge to deal with in the sense that we don’t want to make a mistake ten times and then find out that we can find out the first time. So the template allows us to take that process forward in a very successful way.
Standard weight specification. Everything about CV environment is that it requires conformance to the standards. These standards and security requirements, all of these things are part of the specifications. So they should be within the specifications. Conformance requirements. Then also test plans. We just discussed a little bit about the maintenance template that also has testing features which needs to be also put in the specification that what needs to be tested, how the testing is going to be created, a process going to be created and how it’s going to be done, who will do it, what are the responsibilities.
So we have the standard testing modules in this program, T101, T202, and they are available for your preparation. So I recommend that you look at those modules as well and put the testing plans and the conformance requirements in the specifications.
Privacy challenge. Privacy between users and the third parties. Where is the data coming from? Can’t track a vehicle to its sources and destination without appropriate authorization. So IEEE 1609.3 describes the user changing MAC addresses very often, so people are not aware of it or the vehicles are not aware of the privacy of the original senders. Also J2945 standards is addressing this by assigning the identifier inside on a very frequent basis. So if we still had some of the things that we will—we require to deal with the privacy issues and meet the challenges in terms of preserving the integrity of the data.
Security challenges are also very real and very important in the CV environment because of large quantities and a transfer of messages. So but while important issue is to realize that Security Credential Management System, SCMS, being developed will provide us with the security infrastructure to issue and manage security certificates. Security certificate is a key concept of the standards that’s coming. Safety messages, SCMS, support trusted safer authentications, whether the message is real, who sent it, all of those issues are now ironed out in that fashion.
CV devices enroll into SCMS. They obtain the certificate so everyone has a vested interest and with the certificate process every vehicle will be aware of other versions in a proper way. So it deals with the trusting from trust from each other. So we mentioned about privacy. Privacy deals with the data and security deals with the exchange of messages. Cybersecurity is also addressed in addition to the overall security which is because with the environment is also in a Connected Vehicle requires that so there will be another module dealing with cybersecurity that impacts such issues and it’s called CSE module 202.
In terms of what has been developed as well as deployed, so if we look at it all the three Connected Vehicle pilots, CV pilots that are going on in the U.S.—one in Wyoming, one in Tampa, Florida area, and New York City—all these pilots have made substantial progress in terms of deploying OBU and RSUs. For example, in New York the MTA already has—MTA buses have been equipped with—700 buses have been equipped with ASD for OBUs use. And in total area, a large number of public transit agency, their vehicles have also been dealt with. I also recommend that you look at the updates available at the websites, at the US DOT Connected Vehicle websites that is listed in the supplement as well.
Another important issue about CV pilot project deployment is the relationship as well as the ability of devices to work with each other in the Connected Vehicle Environment. So interoperability means different types of devices can work within the same environment and produce the same results and in this case, exchanging information among vehicles. So there have been testing done and it looks pretty good that these devices are intent, are working as intended, and interoperability has been known to have occurred.
Resources for further reading. Where you get more information. The supplement, the student supplement that we have also provides you more references in it but there are certain modules that we have prepared in the PCB program that deals with Connected Vehicles. CV 261 deals with V2I, which is in progress, updated one, and we already have updated CV 262, V2V. It is completed and available. CV 273 SPaT is also completed and transit module 24, TSP is in progress. CV 265 IEEE WAVE, which is a technical discussion, is in progress. And CSE 202, Introduction to cybersecurity, is also in progress.
So all of these modules will be made available as soon as they are completed and they will be posted at the site that’s listed here.
Our activity here: which of the following is or are the potential barriers to implementation of transit Connected Vehicles? A) security; B) privacy; C) evolving standards; D) all of the above.
Let’s look at the answers. The correct answer is: D) all of the above are potential barriers issues. But know that we are currently testing CV and will soon find out. Security—A, answer A—security is not the only one but security concerns are potentially barriers because transit agencies must trust and authenticate the information. B is also incorrect. Privacy concerns are potential barriers to protect transit passengers’ data from other than their intended use. And C, standards are evolving, they are new and they are updated as and when they are needed. So all of these things are issues that will be ironed out as we move along.
So what have we learned from this module? Well, in learning objective 1, we described the Connected Vehicle Environment components. In learning objective 2, we identified potential communication technologies, DSRC, CV2X, and the combination. In learning objective 3, we mentioned three types of standards, interface standards, application standards, and connectivity wireless standards. We also learned in learning objective 4 that the transit applications are real and they are beneficial and they can bring benefits in terms of avoiding vehicle pedestrian conflicts and V2V conflicts. And then last on the learning objective, we identified certain challenges—and there are many—and then we have got to deal with those challenges as well.