ITS Transit Standards Professional Capacity Building Program

Module 11: Transit and the Connected Vehicle Environment/Emerging Technologies, Applications, and Future Platforms

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.)

Mac Lister: ITS Standards can facilitate the deployment of interoperable ITS systems, and make it easier to develop and deploy regionally integrated transportation systems. However, these benefits can only be realized 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 promoting multimodalism and interoperability in acquiring and testing standards-based ITS transit systems for public transportation providers.

I am Mac Lister, Program Manager, Knowledge and Technology Transfer in the ITS Joint Program Office of the USDOT and I want to welcome you to our newly redesigned ITS Transit Standards Training Program of which this module is a part. We have worked closely with the Federal Transit Administration and the American Public Transportation Association to develop this material. We are also 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 you.

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 these webinars.

ITS Transit Standards Training Program is one of the offerings of our updated Professional Capacity Building (PCB) Training Program specific to transit industry domain to promote the use of ITS Transit standards such as TCIP, Automated Fare Collection, and Transit Management, to name a few. Through the PCB program we prepare professionals to adopt proven and emerging ITS technologies that will make surface public transportation systems safer, smarter, and greener, which improves the livability for us all. This series of online courses based on ITS Transit standards is in addition to a 35-module series available for free on ITS Standards for practitioners in State and local highway agencies and transit agencies. You can find information on additional modules and training programs on the USDOT website at www.pcb.its.dot.gov.

Please help us to continue to make 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.

Jeffrey Spencer: ITS Transit Standards help simplify the complexities, overcome procurement challenges, and reduce costs of acquiring ITS systems. I would like to use a simple example to explain how this approach to ITS Transit Standards is analogous to our day-to-day life. Imagine that when buying a computer—and you want to buy an upgrade, a printer, or anything else—that you must always buy that same brand at an exorbitant price. Of course, this is not the case because standards have been successfully implemented to allow interoperability. Similarly, transit standards have been developed by transit professionals like you at a national level to encourage competition and limit costs within our industry.

I am Jeffrey Spencer, ITS Team Leader in the Office of Research, Demonstration, and Innovation of FTA within the USDOT and I would also like to welcome you to this ITS Transit Standards training. FTA actively supports the development and implementation of transit standards and we hope that you find this series of online courses a useful tool in promoting standardization. We look forward to your participation and input.

This is Module 11: Transit and the Connected Vehicle Environment—Emerging Technologies, Applications, and Future Platforms. Throughout the presentation this activity slide will appear indicating there's a multiple-choice pop quiz following this slide. You will use your computer mouse to select your answer. There is only one correct answer. Selecting the "Submit" button will record your answer and the "Clear" button will remove your answer if you wish to select another answer. You will receive instant feedback on your answer choice.

My name is Patrick Chan. I'm a senior technical staff with Consensus Systems Technologies in New York and I will be your instructor for this module. I have been involved with systems, applying systems engineering process to numerous NTCIP standards, including some of the center-to-center standards, and to SAE J3067, which is a systems engineer comment to SAE 2735 Dedicated Short Range Communications Message Set Dictionary, the data dictionary for connected vehicles. I've been working on ITS for over 23 years, including more than four years as an ITS project manager with a public agency.

Although the course is available to all stakeholders and interested parties, the materials in this module are geared towards managers and operators of transit systems who are interested in understanding what transportation problems like connected vehicles environment and emerging technologies might address, how it may impact your transportation system and how to leverage connected vehicles in support of local policy and operational objectives. It is also intended for NPLs and transit planners who are looking to better understand how a connected vehicle environment and other emerging technologies might address some of the transportation problems they are facing and how they do business. Private and public sector users who may benefit from a connected vehicle environment are another target audience and manufacturers who are interested in providing the hardware and software systems that will enable connected vehicles and other emerging technologies. Modules 1, 2, and 3 are recommended for all participants. Module 4 and 5 are also recommended for project managers and project engineers. It is assumed that all participants have general knowledge of transit functions and a knowledge of basic concepts of transit management standards. All these prior modules provide the building blocks for a number of the connected vehicle applications, which we will review today in this module. This slide shows the recommended modules in the sequence for a project manager. Modules 4, 5, 6, and 8 are also recommended for project managers. Module 11 is an optional module for project managers. This slide shows the recommended modules in the sequence for project engineers. Modules 1 to 9 are recommended for project engineers while Modules 10 and 11 are optional modules for project engineers.

Upon completing this course the participants should be able to, 1. describe the connected vehicle environment; identify and evaluate potential communication technologies that may be used in a transit connected vehicle environment; identity the ITS standards that support the transit connected vehicle environment; describe the applications being developed in a transit connected vehicle environment; identify the challenges to the successful deployment of a transit connected vehicle environment; and, finally, describe strategies and approaches to deploying a transit connected vehicle environment.

First, we're going to describe the connected vehicle environment. We're going to identify the features of a connected vehicle environment and identify the benefits of a transit connected vehicle environment.

USDOT has identified three major transportation challenges faced by transit managers today. In the area of safety, USDOT has reported that there are more than 4,000 transit crashes in 2009 resulting in over 200 fatalities and more than 2,500 injuries. While transit is already one of the safest modes of travel, connected vehicle technologies will further empower transit vehicle operators with the tools they need to anticipate and avoid potential crashes and significantly reduce transit-related serious injuries and fatalities each year. In the area of mobility, according to the Texas Transportation Institute, U.S. highway users waste over 4.8 billion hours in 2010 stuck in traffic, nearly one full workweek or vacation week for every traveler. Connected vehicle mobility applications will enable system operators and travelers to make informed decisions that reduce travel delay. Travel information will also give the traveler greater ability to make real-time modal comparisons and modal choice. In the area of environment, according to the American Public Transportation Association, APTA, each year transit managers, transit systems collectively reduce carbon dioxide emissions by 16.2 million metric tons. Connected vehicle environment applications will give all the travelers the real-time information they need to make more greener choices.

So let's look at a vehicle. A vehicle today is more than just a vehicle. It contains many sensors and processes that work cooperatively to adapt to an environment to provide a more safe and comfortable ride. For example, there are rain sensors that might control the wiper rates on your windshield wipers. There are slippage sensors on the vehicle for traction control. There are lane departure warnings that'll warn the driver that they have wandered outside the lane. There are also navigation devices and multimedia devices on board the vehicles. Together the navigation and multimedia devices know where you are, identify you in route—origin or destination locations, and access data providing directions to your final destination, provide driver assistance, and providing entertainment and connections for your phone. In addition, millions of people today around the world carry smartphones that know where you are and can easily access data.

Well, with these capabilities today of a vehicle and a smartphone, let's imagine a world where vehicles can share their current position and sensor information while the vehicle's on the roadway and, in return, the vehicle can receive information from other vehicles and the roadway to reduce the likelihood it crashes or improve mobility, such as suggesting alternative routes. This scenario is what USDOT has termed a "connected vehicle environment". The connected vehicle environment is a research program led by USDOT's ITS Joint Programs Office to investigate how transportation connectivity, the wireless exchange of transportation information, can potentially enable applications to improve U.S. transportation in the areas of safety, mobility, and environment, the challenges that we just spoke about. Transportation connectivity can take place between vehicles to enable crash prevention between vehicles and infrastructure; to enable safety, mobility and environmental benefits and among vehicles' infrastructure and wireless devices to provide continuous real-time connectivity. Wireless devices might include smartphones, which a person can carry, which a pedestrian, a bicyclist, can carry. Visualization of all these components, the centers the devices and information that gets exchanged among these devices in a connected vehicle environment has been identified and can be found in the Connected Vehicles Reference Implementation Architecture, or CVRIA, which we'll discuss a little bit more in detail at the end of this module. But there's a training module also that can be found in CVRIA on the website and here it is below.

Pushing the connected vehicle environment is an Advance Notice of Proposed Rulemaking that was issued by NHTSA, the National Highway Traffic Safety Administration, back in August 2014 that announced NHTSA's intent to create a new federal motor vehicle standard to require vehicle-to-vehicle, or V2V, connectivity for light vehicles or passenger cars. The proposed rulemaking included a research report that concluded a fully mature V2V system alone can potentially address 79 percent of all vehicle crashes and a V2V, and a vehicle-to-infrastructure, V2I, together, can potentially address 81 percent of all crash types. A link to the Advance Notice of Proposed Rulemaking can be found in the student supplement. A rulemaking on the V2V requirements for light vehicles is expected in 2016.

So the rulemaking, what does this mean to transit operators? Due to the unique characteristics and behavior, such a vehicle size and frequent stops and starts, transit vehicles often face different safety and operational challenges other than other vehicles. For example, a bus stop on the near side of an intersection often requires buses to stop to pick up passengers, but as a non-transit vehicle needs to make a right turn, it may cut in front of that stopped transit vehicle. In the connected vehicle environment an alert can be generated to the bus operator not to leave the bus stop until the other vehicle has made the right turn in front of the vehicle. The connected vehicle environment can also address transit mobility challenges by providing transit agencies and travelers with better transportation information. This information can be used by transit agencies to increase transit productivity, efficiency, accessibility and services. For transit users, the connected vehicle environment provides travelers of an information rich environment to meet their travel needs across all modes and may result in a more convenient and quality travel experience for the transit users. Expected improvement in mobility will also mitigate the impacts of transit vehicles on the environment because transit vehicles have a unique vehicular operational profile such as higher idle times and frequent mile acceleration and deceleration. Transit vehicles impact the environment differently than other types of vehicles. However, the transit vehicles can also be a source of data to measure and mitigate environmental impacts of a connected vehicle.

So what is it that transit managers need to learn about the connected vehicle environment? The connected vehicle environment will be part of transportation systems that the transit managers will have face and understand. With transportation connectivity a new class of vehicles will arrive on the highways and streets that the transportation managers own. It's fast moving and possibly autonomous. Additionally, emergent technologies and the proposed rulemaking will lead to developments that open the door to new types of connected vehicle technologies, including sharing information between the vehicle and the infrastructure and, possibly, vehicle to the pedestrians via the smartphone. So this module may provide answers to the following questions that transit managers may have: What is it that the transit manager can do now to prepare for this new environment; what is it that the ITS standards permit the transit manager to do; or, in different words, what can ITS standards do to help the transit manager designer set up a design for forward-looking ITS capability; what concerns might a transit manager have that they have to know about the connected vehicles? This may impact investments in technologies and transit services that they wish to provide to the transit customers. So the remainder of this module hopes to provide answers to these and other questions.

Now we've reached our first activity. So the question is, "Which of the following can be improved by connected vehicles and public transportation?" So the answer choices are: a) Roadway congestion, b) Crash rates, c) Fuel efficiency, or d) All of the above.

Again, which of the following can be improved by connected vehicles and public transportation?

All of the above answers are actually correct and the answer, the correct answer for this is "d) All of the above" are true. The implementation of connected vehicles in transit can reduce roadway congestion, so it can become more efficient and encourage more ridership. Crash rates may also decrease by helping transit vehicle operators avoid crashes due to operator advisories or warnings or operator assistance, such as when the non-transit vehicles make right turns in front of transit vehicles. And fuel efficiency will increase with connected vehicle technologies, such as transit signal priority, which can help transit vehicles operate more efficiently and reduce fuel consumption.

So, in summary, the connected vehicle environment, the use of communications—wireless communications to broadcast transportation information among devices, such as a vehicle, the roadway infrastructure, and mobile devices and this includes transit vehicles. Due to this connectivity, the connected vehicle environment offers potential benefits in three transportation challenge areas: safety, mobility, and the environment.

So connected vehicles and transportation connectivity between devices, over the next couple of slides we're going into some of the communications technologies that will enable this transportation connectivity in a connected vehicle environment and some of the standards that will support these communications technologies. The first technology we're going to talk about is something called Dedicated Short Range Communications, or DSRC. "Connected vehicles" is sometimes incorrectly used synonymously with DSRC. DSRC is actually just the communication technology and only one communication technology that might be used in a connected vehicle environment. What this slide shows is the definition of DSRC as defined by the FCC, the Federal Communications Commission. Note that this definition is only applicable in North America, Europe, for example, has its own technical definition of DSRC, but they're very similar in that they use frequencies, radio frequencies solely for ITS or ITS applications. Note that the term DSRC came from an ASTM standard, ASTM 2213-02, which we'll discuss a little bit more later. But the reference to the ASTM 2213-02 can be found in the student supplement as can the full reference to the FCC report and order. Again, that can be found in the student supplement. But, in general, DSRC is a two-way short- to medium-range wireless communication that permits very high data transmission, which is needed for safety applications. So DSRC actually describes the radio system and its use for traffic services for ITS services. The actual frequencies for DSRC vary in the United States, in Japan, and in Europe. In the United States the FCC originally allocated 75MHz of spectrum in the 5.9 GHz band for use for ITS vehicle safety and mobility applications back in 1999. It also defined the service rules and licensing rules and channel assignments. These rules were recently revised and clarified in 2004, 2006. Currently, the 76MHz spectrum for DSRC is divided into seven 10 MHz channels with one channel to be used for control and one channel for safety data and one higher power channel for public safety vehicles. Since 1999 there have been several demonstrations using the 5.9 GHz radio frequencies, platooning was tested in the San Diego area. There were safety pilots, commercial vehicle uses, New York City World Congress back in 2008, and the Ann Arbor and Southeast Michigan safety test. So the 5.9 GHz have been tested in the United States.

What are some of the benefits of DSRC? Low latency allows a high rate of transmission. In the connected vehicle environment a high rate of transmission for short messages is critical for safety. For example, some of the messages might be 100 bytes, but it's important that the 100 bytes be received by the other vehicle in a short period of time. So if I'm sending, "Hey, here I am. We're about to have an accident, 'cause we're on a collision course," and the other vehicle doesn't receive it in less than a second, that could be a problem. If it's received in two seconds, by then the crash has already occurred. So that's why we need a low latency and high data transmission; for safety applications. Another benefit is short to medium range. With DSRC, 300-meter range can be reached on a consistent basis, though it's been measured for longer distances, up to a kilometer. This is an advantage, because you only hear messages that are nearby. You don't want to hear where messages from a vehicle that might be a mile away, example. It could be a disadvantage for some messages. For example, if a vehicle is disabled and it's transmitting data, it's like, "Oh, help me out. I'm disabled. I've been in an accident," and there's no other vehicles for several miles away or then that could be a disadvantage. And, finally, the DSRC's intended for the public good with no over-the-air subscription. So anyone can use it for public safety operations, for ITS applications. There's other advantages. The DSRC has proven to be pretty reliable and the performance is pretty good.

There are some disadvantages of using DSRC for certain applications. The limited range might not be suitable for the exchange of transit operations between transit vehicle and dispatch center, such as the transit vehicle status or transit locations. Because of its 300-meter range to send that information on a DSRC you need a RoadSide Equipment, roadside unit, every 600 meters for continuous connectivity. Plus, each transit vehicle would also have to be re-equipped with DSRC radios. There's also some issues related to data security and privacy. What we have here in the slide is a visualization: how the connected vehicle environment using DSRC might work. It consists of 5.9 GHz radios called an "onboard unit" in vehicles, broadcasting basic data about the vehicles, such as the vehicle locations, the vehicle speed and direction of travel. It can also receive data from other devices, such as other vehicles, the roadside structure, or other connected devices. Near the bottom, next to the roadway we have the roadside infrastructure might have 5.9 GHz radios, called the RoadSide Unit. The RoadSide Unit can be located in the same cabin as the traffic signal controller or it can be mounted separately on its own light pole, for example. In this example, it's located in a different cabin than the transit signal controller and it's listening to basic data that the vehicles are broadcasting. But the RSE, the RSU, can also broadcast information, such as signal information, "Oh, this light's about to turn yellow," roadway geometry, and other travel information.

Here in this slide we show the architecture for the onboard equipment, or the OBE, which the equipment on the vehicle uses for transportation connectivity. The first grouping of equipment in the red box is the wireless safety unit, or the WSU. The wireless safety unit along with the DSRC antennae and GPS antennae makes up what we call the "onboard equipment." It includes a communication device for communicating with other connected devices; could be a cellular data, telephone data, or DSRC radio or some other wireless radio. Note that what we call "onboard unit", OBU, is the DSRC radio, includes the GPS receiver for receiving location and time information from the global navigation satellite systems. There's something called a basic safety application that represents the processing unit, that runs a software application on the vehicle, such as safety applications, but it could also include mobility and environmental applications. And the vehicle data represents the memory to store security certificates and other vehicle data, including sensor data.

The next major grouping of equipment in the light blue box in the upper, left hand corner is the in-vehicle display. These components including a driver interface are necessary to provide vehicle operator with information, such as warnings or a device. Finally, the data acquisitions system in the light orange box, which consists of equipment to collect information as part of the connected vehicle system. It includes interface with the CAN- bus, or the vehicle bus, which collects information on the vehicle's internal sensors.

Next, we'll review the components that make up the RSE, or the RoadSide Equipment. These components include the wireless communications device; again, it might be DSRC radio, which is, in this case is called a RoadSide Unit; includes the GPS receiver; again, receiving location information and time information; application processing unit that runs the application; a backhaul modem for communicating with a management center could be wired or it could be a wireless; and memory for storing security certificates and application data. A note, again, this is only one possible scenario. There are other possible scenarios that are being researched and exchanged, including exchanging information from the vehicle directly back to the management center via cellular telephone. This only shows the DSRC scenario using DSRC radios.

But now that we have a general idea of what the connected vehicle environment is and what the benefits are, what is it that we need for a connected vehicle environment to be realized?

The current situation consists of different vehicles on the roadway from different manufacturers and the infrastructure is being operated by different agencies. So for the required transportation connectivity to happen there are several questions that we need to answer. First, how do we communicate? We know it's got to be wireless, but what technology should we be using? Should it be cellular communication? Or should it be some type of radio? If it's a radio, what frequency should we be communicating on? What language are we using? What are the rules for that language, the grammar, and what are the words, the dictionary, that we should be using? For example, we're speaking English right now, but maybe we want it to speak a different language. How many people can talk to each other so we can listen to each other? Should I talk louder if there's a lot of other people talking, or should I move to a different room or a different channel? Now how do I know what you are saying is correct and who you say you are is actually who you are? Well, these are questions that we can answer using standards. So standards are essential to interoperability, which is the ability of two or more systems or components, regardless of the manufacturer to exchange information and use the information that's been exchanged. Imagine a scenario where the standards don't exist. We have our Model T that's broadcasting on Frequency A using its proprietary data dictionary, while we have another vehicle that's Model X that's listening on Frequency B and only knows its own proprietary dictionary. Different manufacturers, different data dictionaries—you won't be able to communicate with each other. So that wouldn't be very useful. So we need an interoperable environment so that vehicles from different manufacturers can speak to each other. An example of interoperability is the use of AM-FM radio broadcasts. Because of radio standards it doesn't matter who made a radio receiver or the transmitter, the radio receiver is able to listen to broadcasts on different radio channels. Another example is Wi-Fi—it doesn't matter who created—whose laptop I'm using or whether I'm at Starbucks or McDonald's or at the airport; it doesn't matter which browser I'm using; whether it's Firefox or Chrome, I'm able to use the Wi-Fi to get onto the Internet to find information, to get my email, again, no matter where I am, no matter whose laptop or whose Wi-Fi router I use. So this is why standards are important regardless of who developed them. To maximize the potential benefits of the connected vehicle environment it's important that all connected devices, whether it's a vehicle to RoadSide Equipment or multiple devices, speak the same language, speak the same way, use the same grammar, and use the same vocabulary. Other benefits of using—of creating the standards and using the standards that it makes testing for performance and interoperability easier and it helps with the design and procurement of connected vehicle system.

So what kind of communication standards are needed? Well, there are transmission standards that define how information exchanges. Since the focus is on wireless communication, these are radio system standards and involves the capability for over-the-air transmission. ASTM 2213 and its replacement, the IEEE 802.11 standards, define how to implement high-speed data exchanges between devices in the 5.9 GHz band for ITS. An analogy might be that it defines how two people communicate with—by speaking instead of using a written language. The IEEE 1609 family defines the rules and procedures on how data will be exchanged between two devices. A similar analogy might be the English language; the English consists of grammar defining the rules and procedures on how to exchange or how to talk to each other or write. There are also interface standards that define the characteristics necessary to allow the exchange of information between two systems or two devices. SAE J2945 is the interface standards that define the operations, performance and functional requirements for one or more applications. For example, J2945 is supposed to define how often data must be broadcasted so safety applications can make the decisions or provide the data to drivers for crash avoidance. There are also two standards that define the data that's to be exchanged: SAE J2735, for example, defines the message format's data content and data dictionary, the words that will be used to exchange data between two devices. An analogy is that message formats are sentences, while data elements are individual words. There are other data standards that may be applicable to the connected vehicle environment and we'll discuss those standards in later slides.

Again, it is important to remember that DSRC is only one possible communications medium for transportation connectivity, but it's likely to be used because of its low latency. As mentioned earlier, ASTM 2213 introduced the term DSRC and was a source for the FCC rule that allocated 5.9 GHz for ITS applications. Note that 2213 is no longer used, but it was the basis for the IEEE 802.11p amendment, which is now part of IEEE 802.11 2012. But since ASTM 2213 was mentioned in the FCC rule we included the standard for reference.

IEEE 802.11 family of standards defines how wireless connectivity between different devices within a local area exists. So, for example, there are parts of 802.11 that make up what we call the Wi-Fi standard. So 802.11d or 802.11g or "n." But there is a section called 802.11p, which is now part of the overall family that defines wireless connectivity in a vehicular environment. It specifies the channel bandwidth, the operating classes, the power and other channel requirements in the 5.9 GHz spectrum for ITS.

The IEEE 1609 family defines the rules and procedures on how data will be exchanged between two devices in a vehicular environment. Specifically, we call it the Wireless Access in Vehicle Environment, or WAVE. It consists of several standards. One is IEEE 1609.0, which is a guide describing the architecture and services necessary for WAVE devices to communicate in a connected vehicle environment. There is IEEE 1609.2, which defines secure message formats and processing for use by WAVE devices, including how to secure WAVE management messages, application messages, and the use of certificates, which we will see is very important. Also, it describes the administrative functions necessary to support the core security features. IEEE 1609.3 defines the services operating at the network and transport layers, it manages how communications are initiated and ended and how messages are exchanged. Recall that there are seven channels available for DSRC communication; IEEE 1609.4 describes the radio operations and how to switch between different channels, how to route different channels and the management services for multi-channel operations. For example, it allows information to be exchanged on different channels in case one channel is congested.

IEEE 1609.11 specifies how electronic payment transactions between a mobile device and a RoadSide Unit occurs, includes support for authentication and payment data transfers.

IEEE 1609.12 specifies allocations of WAVE identifiers, services that are offered by RoadSide Unit or assigns an identifier. This document identifies and specifies those values.

Although we focused on DSRC communication because of its low latency and expected use for vehicle safety, there are other wireless communications technologies that can be used. These wireless communications technologies can be classified into two types: wireless local area network and wireless wide area network. Starting with the wireless local area network, it can be—wireless local area network, or WLAN, can be defined as short- to medium-broadcast communications up to approximately 300 meters or 1,000 feet. Some examples of WLAN technologies are listed. Notice that each communications' technology are not equal and each have different characteristics, such as different latency, throughput, or range. DSRC, again, has been tested in pilots, but the others are still possibilities. I just wanted to point out though that 3GPP, the last one, is actually a standards group, consisting of seven telecommunications standards development organizations covering cellular technologies and it's dominated by the wireless carriers—Sprint, AT&T, and Verizon. But they're currently performing a study to investigate the use of LTE mobile network for V2X, such as V2V, V2P, or V2I; and that study's expected to be completed at the end of 2015.

The other type of wireless communications technology is WWAN, or the wireless wide area network. So these technologies include high-speed cellular data. It allows vehicles to connect directly to the cloud or to a traffic management center and most of these standards are developed by the 3GPP group. Because of their latency and their work reliability, WWAN can't be used for time-critical safety applications, but it could be considered for a mobility or non-time-sensitive applications where latency and time sensitivity's not an issue. Just as importantly the use of WWAN does not increase congestion on DSRC channels, so we can reserve DSRC for safety-critical applications and messages.

We've reached our second activity. So which of the following is not a current attribute of DRSC? Your answer choices are: a) low latency, b) no subscription required, c) widely deployed in vehicles, and d) short to medium range. Which of the following is not a current attribute of DRSC? So c is the correct answer. As we have discussed a few vehicles today are equipped with DSRC. Low latency is incorrect, because low latency is a benefit of DSRC. DSRC does not require subscription, so no subscription makes the technology more accessible. And DSRC is a short to medium range, which is a core characteristic of DSRC.

So now we've re-introduced some of the communications technologies and standards that can be used in a connected vehicle environment, but we haven't yet introduced a data interface standard. For the next several slides, we'll introduce those standards that will help project managers implement and deploy in a connected vehicle environment. Many standards exist that have applicability to connected vehicle environments, but it should be noted that many of these standards also in its current form do not support all the transit applications that appear in the CVRIA which is the Connected Vehicle Reference Implementation Architecture.

So the first thing in the standard that we want to review is TCIP. TCIP, or the Transit Communication Interface Protocol, is a standard published by APTA, the American Public Transportation Association. It's a data center for exchanging data among transit business systems, subsystems, components and devices. It has a very broad scope covering areas such as transit vehicle location, estimated time of arrival, vehicle information, etcetera. However, it doesn't support all the potential needs for a transit agency. So, for example, while fare collection is accounted for, it's not yet an adopted part of the standard. TCIP also does not directly support demand responsive trips. However, it does contain some objects that are related to the transit-connected vehicle, applications defined in the CVRIA, such as connection protection. But, in general, also TCIP has yet to come into widespread usage in the United States. So, but for more information about TCIP please consult modules 3 and 5, which will cover this standard in much more detail.

Another data standard is the Service Interface for Real-Time Information, or SIRI. SIRI is a standard that was developed by the European committee for standardization in Europe. However, it's becoming commonly used in the United States, such as by the New York City Transit Bus and by Houston Metro. It contains messages necessary to disseminate real-time transit information. Note that there are parts of the standard that have yet to be formally standardized, such as facility monitoring service and situation exchange service.

GTFS, or the General Transit Feed Specification, has become a popular way to disseminate static transit information. GTFS was written with passenger-facing applications in mind, but nonetheless has become a common way to share schedule data between transit agencies and transit users and also between transit agencies. GTFS also has a real-time component known as GTFS-Realtime, which expands upon GTFS to disseminate real-time messages for stop arrivals, vehicle location, and service alerts. GTFS-Realtime is slowly becoming popular but has not quite yet taken off yet. Note that GTFS is not a standard. It does not go through a standardization process. Updates are made on an ad hoc basis and the approval process takes place on an online forum consisting primarily of web and application developers. So, GTFS is a specification, but not a standard.

There's also another standard we'd like to talk about, which is the Traffic Management Data Dictionary. TMDD, which is as it's more commonly known, is used for center-to-center communications for traffic management. So—but this is related to transit managers because buses operate on the—using the same roadways and depend on real-time information about the roadway network. So TMDD could be used to exchange real-time information about the roadway network between traffic management centers and transit management centers.

So far we've talked about the data standards and specifications that are used in/for transit and transportation industry in general. However, there is a data standard that was developed specifically for exchanging information among connected devices, such as vehicles, infrastructure, and devices. And that data standard is the SAE—Society of Automotive Engineers' J2735 Standard, also called a Dedicated Short Range Communications Message Set Dictionary. This standard defines messages and data elements and the most current approved version was published on April 30, 2015. One of the key messages of interest in the SAE J2735 is something called a "Basic Safety Message", or BSM. This is the primary message that is expected to be broadcasted from a vehicle to other devices. It consists of two parts, Part I and Part II. Part I data elements are considered basic information needed for safety applications and thus are considered mandatory. That means that they are expected to be broadcasted all the time. Part I data elements are expected to be broadcasted by the vehicle on a frequent basis although SAE 2735 does not define how frequently or when the message should be transmitted; that's defined actually by a different standard. Part II data elements, on the other hand, are optional. They may be broadcasted along with the Part I data as needed or as requested. So, for example, the Basic Safety Message has a flag to indicate a vehicle is braking hard. That flag is a Part II data element and it could be broadcasted with Part I, but it is expected to be broadcasted to warn other vehicles receiving that, say, "Hey, I'm braking hard, please be aware." So, regardless, Basic Safety Messages are expected to be broadcasted frequently using DSRC for vehicle-to-vehicle safety applications. And those Basic Safety Messages, by the way, can also be read by an RSU, or a RoadSide Unit.

This slide summarizes some of the information that is provided in Basic Safety Message Part I, provides critical information needed for the movement of the vehicle, such as where it is, where the vehicle is headed, and at what speed. Just some notes: Positional accuracy is the quality of the accuracy of the location. If the GPS receiver on the vehicle has full sky to view, the accuracy is likely to be high. But if it's in a canyon, let's say, it could be a natural or it could be within the city where lots of high buildings—the accuracy will be lower. Transmission lets other vehicles know if the vehicle is in neutral, park, forward, or reverse. The steering wheel angle lets another user know if the vehicle is turning or not. Acceleration is along all three axes, plus yaw rate. Vertical acceleration might be used to determine if there's a pothole in the road and the yaw rate might be used to determine if the car is going to overturn. Brake status indicates if the brakes is being applied, including anti-lock brakes, traction control, stability control, or if the parking brakes are engaged.

This slide summarizes some of the data elements that are contained in Part II that might be of interest. It's not a complete list. All these elements are optional and a manufacturer is under no obligation to broadcast any of this information. Part II data elements include the event flags. As we talked about earlier, event flags are data elements that are broadcasted when some condition is met. They generally have something to do with safety that might be of interest to other vehicles. Although all event flags are optional it's expected that the event flags will be required to be supported by standard or rule for V2V communications.

Obstacles: Some vehicles are equipped with radar detectors to detect objects in the roadway. So this data element would provide a location of the potential obstacle. Other optional information includes vehicle weight and height, exterior lights, such as if the headlight's on, which might be of interest for environmental purposes. The vehicle bus, information from a vehicle bus. Vehicle identification includes—it could be a VIN number and a vehicle type, which a bus is an enumeration. The VIN number might be used more for like commercial vehicles, for example. Or it could also—might be used to identify the bus that's requesting signal priority.

So far we talked about the Basic Safety Messages, which are broadcasted by a vehicle that might be heard by the infrastructure using RSUs. Let's now talk about the messages being broadcasted by the infrastructure to the vehicles. So it's intended for vehicles to hear. The first message is something called a MAP Data Message. It's used to broadcast roadway geometric information, including intersection geometry or roadway segments. So this message can help drivers avoid wrong way lanes or road closures or drifting off the roadway pavement. It can also help pedestrians if their smartphones can listen—hear the message, so that they can know where the cross walks are, for example. There's also a Travel Information Message which can be used to provide travel information to the public. By focusing means that multiple Travel Information Messages might be broadcasted, but you will only hear those messages that are intended for vehicles in a specific area, or direction of travel, or if you're a certain type of vehicle. So, for example, a Travel Information Message might contain a header that states, "This message is only intended for vehicles on the highway traveling in the northbound direction," while a second travel information message might contain a header that says, "This message is only intended for commercial vehicles in a weigh station traveling in a southbound direction."

SPaT: Signal phasing and timing message provides signal phasing and timing message for signalized intersections. Among the information provided in this message, whether the general status of the controller—is priority service being provided, for example? It also tells you for specific lane or specific direction of travel whether the light is currently green, yellow, or red, or flashing and also provides when the current green time might end. So, for example, it's expected to turn yellow at five seconds after midnight. So it can be used to determine the optimal speed for traveling through a signalized intersection, to warn "Hey, this light's about to turn red, so please either—well, it's about to turn red so do something." As a note, the SPaT message's usually tied to the MAP Data Message, which provided the roadway geometry information.

Two other messages that might be of interest for a transit, is a Signal Request Message and a Signal Status Message. These messages are used to provide signal priority requests and status for fleet vehicles, such as a transit vehicle. So this message can be used for a transit vehicle: "Please extend the green time or make the green time—make the green light come up earlier for me, because my vehicle is running behind schedule." So based on the estimated time of arrival and departure, where you are and where you wish to be, these messages will provide priority for transit vehicles. Note that the status might include the transit vehicle is relatively empty or relatively full, if the vehicle door is empty—excuse me: Is the vehicle door open? Or the bicycle rack is occupied. Other messages, this slide lists some of the other messages. We're going to leave it here for reference only, but in the interest of time I'm not going to review it, the other messages. It might define the minimum accuracy requirements for the vehicle position before it broadcasts it. If the vehicle position is of poor quality, possibly because the receiver is damaged, the performance requirement will say that the vehicle not broadcast the position; it's better not to provide the vehicle position than to provide one that's of questionable quality or accuracy. So the families consist of J2945-slash-zero, which provides the generic content and requirements that are applicable to all applications. By the J2945 will also contain systems engineering content, which means they will provide concept of operations requirement and the design. The next two standards of the J2945 family, slash-one and slash-two, are expected to define minimum performance requirements for V2V safety applications. This includes how often the Basic Safety Message Part I message is expected to broadcasted, how often Part II portions of the Basic Safety Message will be broadcasted and the conditions on when and how often the temporary ID of the vehicle will change and the minimum accuracy required before a value is broadcasted. So, for example, what's the quality requirements for vehicle speed before it's broadcasted to other vehicles? J2945 may also point to how other standards are to be used to implement this, such as IEEE 802.11 or IEEE 1609, so interoperability can be achieved.

Slash-three, slash-four, slash-five are placeholders for V2I applications. The DSRC technical committee's still debating the scope of each of these proposed standards, but each is expected to include system engineering content and minimum performance requirements.

Slash-six defines the data exchanges necessary for coordinated maneuvers such as platooning and cooperative adaptive cruise control. Another one that might be of interest is J2945/9, vulnerable road users, or V2P, or mobile devices, such as smart phones that pedestrians or bicyclists might be carrying. Recommendations for performance levels, links to existing standards, and new standards development, if necessary, will be provided in the J2945/9.

So re-visiting an earlier slide that asked the question, "What is needed for the transit connected vehicle environment to be realized?" We now have our answers. So this slide depicts the standards that answer the different questions that we have and are needed for an interoperable safety environment using DSRC regardless of the vehicle make or model. Again, different communication standards might be used for different communications technologies other than DSRC. So how do we communicate? We're using IEEE 802.11, IEEE 1609.3 defines how we communicate. What language are we using? SAE J2735 and SAE J2945, for example, defines the data elements of the synthesis, the messages, the data element and how we're supposed to talk to each other. How many people are talking in a room? IEEE 1609.4 talks about what do we do in case there's a lot of people talking in the same room and how do we trust each other. IEEE 1609.2 certificates help us authenticate and trust each other, provide some sort of security. So it's with all these different standards working together that we provide interoperable environment that a connected vehicle environment can exist.

So current transit standards operate in a vehicle-to-center, center-to-center fashion, however connected vehicle applications for transit may require more vehicle-to-vehicle and vehicle-to-infrastructure opposed to communications. So most current transit standards cover some basic information, including vehicle location and estimated time of arrival. However, connected vehicles require more interactive and more precise information particularly for safety applications and may have user needs and requirements that are not currently addressed by the current transit standards.

So we've reached another activity, so "Which of the following is not a formal standard?" Your choices are Google GTFS—General Transit Feed Specification, APTA TCIP—Transit Communications Interface Protocol, CEN SIRI, or SAE J2735? Which of the following is not a formal standard? So the current answer is a, Google GTFS. While GTFS is considered a de facto standard for transit it is not a formal standard because it has not gone through a formal standardization process. APTA TCIP has gone through a formal standardization process led by APTA; CEN SIRI has gone through a similar process following the rules in Europe; and SAE J2735 is also considered a formal standard, having gone through the formal standard process for Society of Automotive Engineers.

So what have we learned in the last couple of slides? Well, there exists several data standards that are available for transit agencies that can be used in the connected vehicle environment. However, SAE J2735 is the primary data standard and SAE J2945 is the interface standard that were developed specifically for a connected vehicle environment.

So over the next several slides we're going to describe some of the applications that are currently being developed in the transit connected vehicle environment. Then we're going to identify some transit-specific safety applications and we're also going to identify some transit-specific mobility applications.

But, first, let's start off with what's an application? We talked about the benefits of connected vehicle environment, but how are those benefits realized. So applications are software systems that take inputs from other vehicles and uses it to provide relative information to the vehicle operator or other processes or software in the vehicle. So these applications are stored in the vehicle and it is primarily through these applications that we gain the safety, mobility, and environmental benefits that we talked about earlier.

So in the next several slides we'll summarize some of the transit applications that have been identified by USDOT to date and are being researched and prototyped. There could be more applications identified in the future. There will be other applications that will be conceived and developed by others, but note that recall that when we talked about applications we talked about using information from other devices as an input in addition to a vehicle's own sensor readings. So, as a final note, an onboard equipment may have one or all of these applications that we're going to discuss. So, for example, a transit vehicle must support the generic safety application in addition to several transit-specific mobility applications.

So, first, we just want to review some of the V2V safety applications that are being considered for immediate implementation. So these are safety applications that are being tested and prototyped that we expect to be implemented relatively in a short period of time, regardless of what type of vehicle it is. It doesn't have to be a transit vehicle. So the first application we want to talk about is something called the Lane Changing Warning or Blind Spot Warning application. So it's intended to warn a driver, let's say this driver on the right. If the vehicle is occupying or will soon be occupying the space in which the vehicle intends to switch to. So, for example, if this vehicle wants to move to the left lane, he'll get a warning in case that there's another vehicle that's in his blind spot and that might—because it's driving at a faster speed—might be in that same space in a short period of time. So the driver of the first vehicle will get a warning, "Hey, someone's going to be there soon, so maybe you don't want to change to that left lane." Another application is something called a Forward Collision Warning. So it warns the driver, let's say the driver of the second vehicle, if there's a possibility of rear-end collision with the vehicle ahead of it that's in the same lane in the same direction of travel. However, sometimes a vehicle might be driving behind a truck and can't see the vehicle in front of the truck. So there's another application called Emergency Electronic Brake Light that enables a vehicle-let's say the first vehicle in front of the truck to broadcast a brake event to surrounding vehicles. Upon receiving the event information, the receiving vehicle can determine if the event has an irrelevance and provides a warning to the driver of the vehicle, let's say, behind the truck that, "Hey, the first vehicle is braking. So even though you can't see it, you better start slowing down because he's braking hard." Another application is Intersection Movement Assist warns the driver when it is not safe to enter into an intersection due to a high collision probably with another vehicle. Could be a signalized intersection or it could be a stop controlled intersection. Another application is the Left Turn Assist. So it will warn a driver that's trying to make a left turn if it is not safe to make a left turn because of an oncoming vehicle from the other direction. So these are just some examples of some general V2V safety applications. It's not specific to transit vehicles, but for all equipped vehicles, in general.

This scenario demonstrates something that might be specific for transit vehicles and this application is called the Vehicle Turning Right in Front of a Transit Vehicle, or VTRW application. As we can see, the passenger vehicle intends to make a right turn in front of the bus at the near side stop. Because the passenger vehicle's trajectory takes him from the path of the transit vehicle a warning is issued to the transit vehicle that there is a dangerous situation in case it moves.

Another example: Here we see the Railroad Crossing Warning application. In this application vehicles that are approaching a railroad crossing are alerted to the presence of an incoming train.

So those are from the safety—transit specific safety applications. Let's talk about some transit specific mobility applications. So the Integrated Dynamic Transit Operations, or IDTO, consists of three applications related to transit. There are transit connection protection—allows customers traveling in multi-leg trips to ensure that the connecting trip waits for them. So, for example, if a passenger is on Bus One and must transfer to Bus Two within two minutes of the layover time, but if Bus One is three minutes behind schedule the Connection Protection can be requested either by the vehicle operator on Bus One or the passenger. If approved, Bus Two will hold up the extra minute or two for the connection to be made. Dynamic Transit Operation builds on existing concept of demand-responsive trips with D-RIDE as it's also called. Passengers can use mobile devices to request a pick-up at a specific location. If accepted, the passenger is notified of the time that the pickup will occur? And, finally, there's dynamic ride sharing takes the concept of carpooling and builds upon it. It provides passengers with a method of sharing rides with the use of mobile applications. I apologize: This is called D-RIDE. The previous one was called T-DISP.

Here is on this slide we listed some other transit-specific applications that have been identified by USDOT and it's in the CVRIA. But, again, in the interest of time we're not going to review these applications, but we leave you this list available for you to review.

So we've reached another activity. Which of the following is not an Integrated Dynamic Transit Operations application area or IDTO? So "Which of the following is not an IDTO application?" The answer choices are: a) Transit Connection Protection, or T-CONNECT, b) Dynamic Transit Operations, c) Dynamic Ridesharing, or d) Forward Collision Warning? Again, which of the following is not an Integrated Dynamic Transit Operations application area?

So the correct answer is d) Forward Collision Warning. It's not an IDTO application, but a V2V, a vehicle-to-vehicle safety application. Transit Protection Connection, again, is for protecting transit connections. There's Dynamic Transit Operations and Dynamic Rideshare, which is similar to carpooling.

So, in addition to general connected vehicle applications, there are several applications that have been identified as specific for transit agencies and transit operators. They include Integrated Dynamic Transit Operations bundle, which has three applications. And there are three other transit-specific connected vehicle safety applications that might be of interest, including Transit Vehicle at Station-Stop Warning and Vehicle Turning Right in Front of a Transit Vehicle Warning. Again, if you're interested in finding out more about these transit applications I'll refer you to the CVRIA website. We'll show the link again later, towards the end of this module.

Our next learning objective is to identify challenges to successful deployment of a transit connected vehicle environment. So over the next several slides we're going to discuss some of the technical issues related to deploying a transit connected vehicle environment; describe some of the institutional issues such as privacy, data ownership, and security; identify some of the lessons learned from some of the transit pilot program; and we're going to include some slides that list resources for further reading and information. So the connected vehicle environment, as we've shown, is envisioned to be an interoperable environment, which will provide the ability to broadcast standards-based messages and reliably exchange data regardless of the service provider or the manufacturer. However, these standards are still evolving. Requirements are still being added or tweaked as we've learned more from the prototypes and the field tests that are currently being conducted. NHTSA has recognized this and has sent letters to the standards development organizations, for the various standards, encouraging them that the standards be stable by September 2015 before the rulemaking. Some standards are planned to be updated also to align with the final NHTSA ruling when it's released, which is expected in 2016. There are also efforts to harmonize standards with each other, whether it's just within North America or with other international efforts. But the summary is that thus any early adopters of the initial standards should be aware of potentials for changes as we harmonize the standards and tweak the standards based on the lessons learned. So early deployers should build in means to cope with changes, both planned and unforeseen, and stay informed as the standards are adopted and maintained. There are also some potential challenges with the implementation of standards that's still being researched. For example, we talked about the Basic Safety Message, Part II; there's no assurance that the auto manufacturers will support Part II in the short term, because right now they're focusing only on V2V. So they're primarily focusing only on Part I. And they have concerns about channel congestion. As a de facto mode of operation all Basic Safety Messages for V2V safety applications are being transmitted on one specific channel, Channel 172. They may also transmit the Basic Safety Messages on other channels, but the automobile manufacturers aren't pursuing that implementation right now. And, finally, there right now just exist very few guidance documents on deploying these standards as we try and finalize them.

Other implementation issues that project managers should be aware of, vehicles or devices needed to be equipped to gain the benefits or at least one vehicle or device must be able to broadcast and another vehicle must be able to receive. And that just does not exist right now but as we roll out we expect that more devices will be equipped and be able to broadcast and receive these messages. We also have to be aware of the challenges during the rollout as some vehicles are equipped or not. There's going to be adjustment to driver behavior as the rollout occurs. Finally, near-field tracking is possible. Basic Safety Messages are encrypted, so it is possible to track vehicles for short distances or short periods of time. The vehicle IDs and MAC addresses are randomized. So they change pretty frequently and the standards will define how often they change, but it's probably will be a short period of time, maybe about two minutes that I can track vehicle before its ID changes.

Testing is another issue. There are different types of tests that we may have to consider, testing for conformance to the applicable standards, testing for compliance with the regulations and legal requirements, such as a specification. The testing and certification needs to describe what tests and for whom and by whom and for what purpose. So, just as a piece of information, USDOT intends to enter into a cooperative agreement with one or more facilities to conduct qualification and certification testing for connected vehicle devices and applications. The companies are OCS, 7Layers, and DanLaw. However, it's only certification testing to specific standards and specific versions of the standard. The certification tests are expected to include environmental capabilities, for communication protocol capabilities, interface abilities, overall application abilities, and for the security certificate management system, which we'll talk about in a couple of slides. But, again, this is just certification. It's still not compliance testing. A transit agency still needs to perform testing to check compliance of its specifications and for its agency requirements.

In addition to some of the technical challenges that we just discussed, there are also institutional challenges. Privacy is a key challenge. The issue with privacy is respect to user data, respect to communications that as we all know there's sensitivity to data collection, data use, data distribution, and the relationship to data sources—need to be addressed. Note that the situation for data about vehicles differ from the authorization needed to access data to create information about a vehicle or traveler, such as for electronic payments. Also, again, beware that privacy context differs, context is important, and does make a difference and those types of issues should be noted for project managers. The standards do address privacy in two different ways. IEEE 1609.3 makes it difficult to track a vehicle using its radio MAC address. So that changes at random intervals. And SAE J2945 standard is expected to address it using temporary IDs. So, to get it, they provide some assurance of privacy for users and third parties because an agency won't be able to, or can't track a vehicle from its source and destination without the appropriate authorization.

Security is another concern. The difference between privacy and security: Privacy is the use of data to identify something; with security, it's the exchange of trusted and authenticated data. The message may have incorrect content, but it still can be authenticated. So, for security, the USDOT is researching something called the Security Credential Management System, or SCMS. They are developing the security system that fits the requirements on how certificates are to be used, to revoke, and to refresh, as defined in IEEE 1609.2. So the standards will support the security system. It's still being tested. It's still being designed as part of the connected vehicle pilots. But, hopefully, with the security system it will provide security so we can authenticate that a vehicle or a person is who they say they are.

So we've talked about the connected vehicle environment in general. Let's talk about some of the lessons learned. From the IDTO pilot program. So the purpose of the IDTO pilot program is to demonstrate the technical feasibility of three transit applications, examine the impacts and the benefits of these three applications. Again, the Transit Connection Protection, Dynamic Transit Operations, and Dynamic Ridesharing. These tests were performed at two different test sites Columbus, Ohio, and in Central Florida. They used GTFS to enable agencies to share some information, including using GTFS-Realtime. But these were the only standards used in a demonstration and it wasn't very significant, the use of these standards.

Some of the findings, the findings were limited due to data constraints. From the T-CONNECT application, they discovered there was high value to transit customers by knowing when the connected vehicles will arrive and whether a connection was even feasible or not. From the pilot studies they realized that the value of information in the connections led to increased ridership, repeat usage on a limited number of protected connections. Although demand-responsive service was not included in the demonstration they realized from the pilots that there was demand for trip-planning features. And, again, no ridesharing service was provided in the demonstration.

Some institutionalized observations data access was more difficult than expected. So this is data access from the transit agencies. And elements of data may diverge from plans due to institutional concerns. So they had a plan going in and realized, "Oh, they had to diverge a little, because of institutional privacy concerns, for example." Other observations, T-CONNECT offers value; the challenge is finding circumstances where benefit can be provided beyond what the system is already producing. Information is important to transit users, so the more information that's available the higher the satisfaction of the transit customers. Agencies saw a benefit by providing T-CONNECT and are willing to work with other groups and share information to realize the benefits. So there was a desire to increase collaboration between the agencies to increase efficiencies.

Other lessons learned. Most of the information that they were using for the demonstration was already available, publically available. Some were standardized using a standard GTFS mostly, but most of it was not using any type of ITS standard. "Requires flexibility and changes to policy to support T-CONNECT": So the exchanging of information and changing of policies to make and protect that connection was new. So there were some changes that they had to consider or implement in the policies to support connection protection.

Again, privacy concerns—so there was some concerns that was realized during the demonstration. But in the future they realized to really take it to the next step required full integration with a CAD/AVL systems and also we probably need to create standards for the data exchange to better implement some of the features. Again, they used GTFS and GTFS-Realtime, but there was a limited amount. Everything else to support the demonstration used proprietary communication standards—well, proprietary communication protocols or dictionaries.

We talked about some resources for further reading, for further information. Again, we talked about the CVRIA. It identifies the key interfaces of a connected vehicle environment. It was created originally as an input to create a standard development plan to identify and prioritize standards that were needed to support the connected vehicle environment. However, it's still a great resource for transportation managers to look at to help plan and deploy their devices and systems in the connected vehicle environment. It is actually also a tool bag that exists now called SET-IT that's available on the website that will help managers plan or deploy their connected vehicle environment or systems. As a note, the CVRIA is expected to be merged into the National ITS Architecture in 2016, it's expected to be called Version 8.0 of the National ITS Architecture. Also, the CVRIA contains a list of potential applications that have been considered for deployment. So I would suggest—it's a good resource just to see what applications have been considered all ready.

So this and the next two slides provide links to some of the ITS standards that we've discussed and other connected vehicle activities that have been discussed in this module. There's—here's a link for an ASTM E2213, the link to IEEE 802.11, and the link to the IEEE 1609 family standards. These links also exist in the student supplement so you can find them there also. This is a link to find out more about the IEEE—excuse me—SAE J2735 and SAE J2945. There was a stand—information report called SAE J3067 that was a systems engineering comment to the SAE J2735. So it provides system engineering content for SAE J2735. And this could be a very useful resource—provides insight on how the 2765 and J2945 standards will be structured and can be used for implementation.

And this is more resources to find out more about the connected vehicle environment, in general and for transit specifically. That would be the second link. There have been T3 webinars talking about the connected vehicle transit safety and mobility application in the connected vehicle environment. And there was a webinar on IDTO and that's the link for that, for the presentation.

So activity: "Which of the following are potential barriers to implementation of transit connected vehicles?" So your answer choices are: a) security concerns, b) privacy concerns, c) evolving standards, and d) all of the above. So which of the following are potential barriers to implementation of transit connected vehicles?

So the correct answer is d) all of the above. All of the above are actually issues. Security is a potential barrier, because transit agencies must trust and authenticate the information. Privacy concerns, because that's protecting transit passengers data from other than its intended use. And evolving standards is a potential barrier because it affects interoperability if different devices and systems are using different versions of the standards. It affects interoperability. So all three of these are very important hurdles that must be overcome for the transit connected vehicle environment to be realized and implemented.

So, in summary, the last couple of slides, standards related to transit connected vehicle environment are still evolving. Few vehicles are currently equipped with DSRC technology, which makes implementation difficult. There are privacy, security, technical, and institution issues. There are barriers to successful deployment. And the findings to-date have been limited from the IDTO pilot programs.

So the next couple of slides we'll go ahead and describe some strategies and approaches in deploying a transit connected vehicle environment. We're going to review again the NHTSA Advance Notice of Proposed Rulemaking and its impact on the transit agencies, talk about some deployment considerations for transit agencies, procurement considerations, and conformance considerations all for transit vehicles and transit agencies.

One of the first challenges that also the proposed NHTSA, Advance Notice of Proposed Rulemaking, is expected to equip light vehicles—that is: make them connected. V2I is not mandated. It does not necessarily apply for heavier vehicles, such as some of the large transit vehicles. This means that's while light vehicles, passenger vehicles, are expected to support V2V communications, such as broadcasting or receiving Basic Safety Messages, there is no rulemaking that is expected to require light vehicles to support other messages such as the Traveler Information Message, the MAP Message or the SPaT Message—signal phasing and timing messages. There is no rulemaking expected to require right now. There is no rulemaking that exists already for heavy vehicles either, such as connected for transit vehicles. It was the notice—Advance Notice of Proposed Rulemaking for heavier vehicles is expected in 2014, 2015, excuse me. But it hasn't come out yet, so we just don't know when it might come out.

So why do transit managers care about connected vehicles then? Because connected vehicles and transportation connectivity, even though limited to vehicle-to-vehicle, it's another technology or tool, that's available to transit managers to address transit problems. The connected vehicle environment is standards based and thus is envisioned to be highly interoperable. These standards will make the deployment, design of future systems much easier. With national interoperability all equipped vehicles will someday be connected in a standardized way, providing data in a standardized format. So just by listening to the Basic Safety Messages that are being broadcasted for vehicles-to-vehicle safety, can significantly improve safety of transit vehicles because it knows where those connected vehicles are; where they are moving and what they are doing. With RoadSide Equipment that can listen in a standardized format transit managers also have a source of real-time traffic conditions along the transit routes. So they know, "Oh, these are how many vehicles are on that route. Are the vehicles moving well or are they stop-and-go traffic right now?" So you have a better idea of real-time traffic initiatives. Similarly, the same RoadSide Equipment can be used to deploy focused travelers' messages to vehicle operators and passengers in a standardized format. And because the data interfaces are standardized, it creates competition for connected vehicle equipment and may result in better value.

So what can transit managers do to take advantage of this connected vehicle environment? Well, they have to be open to new applications and integration of new and open applications. So for new procurements or upgrades of existing ITS equipment—provide for the expansion to support the connected vehicle environment. So on transit vehicles, for example, provide for future interfaces, such as to the GPS receiver, to the vehicle bus, to the driver interface, and mobile data terminals. So. An OBE, On-Board Equipment, can be installed to listen to Basic Safety Messages and provide warnings and advice to the transit operator, as necessary. On the infrastructure side, provide for future space and interfaces for RoadSide Equipment, cabinet space to house RoadSide Equipment, including the modems, reliable power supply, a place to mount the DSRC antennas and perhaps a GPS receiver for time-clock synchronization so that we can use the RSEs to provide traveler information to our transit customers or to inform Traveler Information Messages.

Transit managers can also start looking at what data might be available from the connected vehicle environment, what to do with that data. They should coordinate with and interact with the traffic agencies to determine what plans, if any, does the traffic agency have to deploy a connected vehicle infrastructure. For example, if the city department of transportation decides to provide signal phasing and timing information in a signalized intersection, the transit agency should include in its specification for an (OBE) On-Board Equipment on the transit vehicle hear, to listen to the signal phasing and timing information that is going to be broadcast and, possibly, also be able to Transmit Signal Request Messages on to transit signal priority. In return the transit agency would be able to provide real-time traffic probe information due to broadcasts of Basic Safety Messages back to the city department of transportation.

So this module has introduced the concept that connected vehicle environment has to be a standard space environment so that interoperability can be achieved. To support this environment, the components in the environment has to use standards based specifications. That means each specification should conform to the appropriate standards required for the implementation. The specification should indicate the communications media to be supported, the communications protocol standards to be supported, the information performance standards to be supported, and to support the security infrastructure. Similarly, test plans should be developed to verify conformance to the referenced standards and to verify compliance to the specifications, certified devices should be used during the conduct of test plans.

Just a little bit more background, each standard should have a conformance statement indicating how to conform to the reference standard. Systems integrated engineers should understand what a conformance clause means—what the conformance clause means, when the conformance clause applies and how to test for conformance to the standard.

Note there are several ITS standards, basically modules available that provide more information on how to perform ITS standards—standards testing. There are also other test modules that might be of interest T203, "How to Develop Test Cases for ITS Standards Based Test Plans", and T204, "How to Develop Test Procedures for ITS Standards Based Test Plans."

We've reached our final activity. So "What portion of the connected vehicle environment is NHTSA proposing a rulemaking?" So what portion of the connected vehicle environment is being proposed on the rulemaking? V2V safety applications for all vehicles, V2V safety applications for light vehicles, V2I, vehicle-to-infrastructure communications capability for light vehicles, or V2V and V2I communications capabilities for all vehicles? So what portion of the connected vehicle environment is NHTSA proposing a rulemaking currently.

So the correct answer is b) V2V safety applications for light vehicles. So their proposal: making V2V communications on light vehicles. It is not all vehicles and not yet a proposed rulemaking for heavy vehicles, which might include some of the heavier transit vehicles. V2I has not been proposed by NHTSA for any of vehicle and NHTSA has not provided V2I communications capability for any vehicles and only V2V for light vehicles.

So, in summary, the NHTSA Advance Notice of Proposed Rulemaking will require all light vehicles to support vehicle-to-vehicle communications and the Basic Safety Messages. Connected vehicles should be considered or support for the connect vehicles should be considered when deploying or upgrading new ITS equipment and agency cooperation, standards-based procurement, strong test plans, and conformance statements to the standards are keys to the success for supporting the connected vehicle environment and emerging technologies.

So just to review what we have learned, connected vehicles can address three major challenges in transportation: safety, mobility, and environment. DSRC technology has the benefit of being low latency, short- to medium-range and not requiring subscription, and it's only one communications technology that we're considering. The use of standards will create an interoperable connected vehicle environment. Applications are a piece of software that processes inputs for a specific use or purpose and it doesn't have to be input of just the vehicle, the host vehicle, but it could be inputs from other vehicles also. And the Connected Vehicle Reference Implementation Architecture, CVRIA, provides a framework that defines interfaces for connected vehicle applications.

So before we go, I thank you for completing this module. Before we go on I do want to point out that I did receive a question asking about the standards activities and how to get involved. So I will refer you back to the slides earlier or to the student supplement. That provides more information about each of the standards activities and the standards that we've talked about in this module. If you're not familiar with some of the applications, there are two modules on the ITS Professional Capacity Building website that will provide a more basic introduction to connected vehicles, in general, it's CV101 and CV102. So they'll provide a more basic introduction to connected vehicles than this one. This one is a little more technical in nature and really focused on the standards.

So, again, thank you for completing this module. We'd like to receive your feedback on whether this module was helpful for you. You could click "Here" on the slide itself or here's the link: www.pcb.its.dot.gov/stds_training.aspx and provide us with your feedback. Thank you again for completing this module.

#### End of Module11.m4v ####