Chapter 13. Transportation

Efficient transportation has revolutionized the way people communicate and interact. With more powerful and cheaper engines, the number of commercial vehicles, passenger cars, buses, trains (including underground, above-ground, trackways, and tramways), and planes of various sizes all grew exponentially during the twentieth century. This explosion brought increased congestion, accidents, and pollution. Today, the main issue affecting the transportation industry is no longer development and growth but rather managing overgrowth and journey experience. IoT and automation can assist individual drivers by providing real-time information on vehicle performance and anticipated journey conditions. IoT can also help entire cities and countries optimize traffic and transportation exchanges.

This chapter includes the following sections:

Transportation and Transports: This section provides a view of the transportation industry and its subsectors.

Transportation Challenges: This section describes challenges that affect road and train travel, for both individuals and mass transit vehicles.

IoT Use Cases for Transportation: This section provides multiple examples of how IoT can dramatically change the transportation industry and the travel experience.

An IoT Architecture for Transportation: This section details the IoT architecture for the transportation industries covered in this chapter: individual vehicles on roads and mass transit buses and trains.

Some of the considerations covered in other chapters also apply to these sectors. For example, most IoT solutions for manufacturing can apply to vehicle manufacturers. (Refer to Chapter 9, “Manufacturing,” for an in-depth discussion on IoT for manufacturing industries.) Similarly, smart and connected cities leverage many IoT solutions for their transportation infrastructure and emergency vehicles. (Refer to Chapter 12, “Smart and Connected Cities,” for a detailed discussion on IoT for public infrastructure, and to Chapter 15, “Public Safety,” for a detailed discussion on IoT for emergency services.) The entire transportation industry is too large to be covered in this book. This book focuses on specific verticals and specific aspects of transportation. Three subsectors of transportation are used as illustrations of how IoT is transforming this industry:

Roadways: Roadways involve individual vehicles, managed fleets, and the entire roadways infrastructure: traffic lights, roadside cameras, roadway sensors, toll plazas, digital signage, etc. Because of the powerful and direct effect on individuals’ lives, IoT improvements for roadways are massive and very visible.

Mass transit: Mass transit extends individual vehicles to collective transportation. This subsector acts as a catalyst for changes in the other subsectors.

Rail: Although mass transit includes subways and light rails, inter-city train traffic also includes freight, which can be a large part of rail activity.

The transformations described for these three examples can be successfully applied to other transportation subsectors (such as aviation, maritime for passengers, and freight/logistics). However, keep in mind that each subsector has specific characteristics that may or may not apply to other sectors.

Similarly, this chapter focuses on aspects of IoT for transportation that have an impact on passenger experience, workforce optimization and operational efficiency, safety, and security. Many other aspects of transportation are seeing massive changes as well, due to optimizations made possible by IoT. For example, smart sensors can adapt a car steering wheel’s stiffness to detected road conditions, which directly increases the lifetime of the car’s tires. Tire lifetime optimization through IoT is a fascinating field, and covering all relationships between IoT and vehicles would take an entire book. In the context of roadways, this chapter focuses on how the interaction between vehicles and the roadways infrastructure can improve the travel experience and also the operational efficiency for the teams in charge of managing fleets.

Safety: According to the US Department of Transportation, 6.3 million crashes were reported in the United States in 2015, resulting in more than 33,000 fatalities and 2.4 million people injured.^1,2

Mobility: With over 1 billion cars on the roads worldwide, congestion has become a major issue. The World Health Organization (WHO, the public health arm of the United Nations) has estimated that 5.5 billion hours of travel delays are caused worldwide by congestion. These delays represent a cost of $101 billion in the US alone.³ The consequences can be extreme. A 60-mile traffic jam in China in 2012 was so severe that it took three days to untangle.

Environment: According to the American Public Transportation Association, each year congestion generates more than 3 billion gallons of wasted fuel in the United States. In addition, transportation creates nearly one-third of greenhouse gas emissions.⁴

The challenges are obvious at a large scale, but they are also present at the scale of an individual driver. Driving at night or in difficult weather conditions is dangerous. Lack of visibility, slow vehicles, unexpected obstacles, and other drivers add to the challenges. These issues are not new. However, automobiles have become an obvious mode of transportation for the twenty-first century. Individuals expect cars and motorcycles to have the same level of intelligence that they see in a smart phone or in navigation systems. Cars are expected to be clever tools, not just basic sets of tires moved by an engine. In this field, IoT can help improve the journey experience by providing detailed information about the vehicle state and anticipating the fatigue or failure of any element. Smart objects can also help a vehicle and its driver communicate with the larger roadways infrastructure, to anticipate obstacles or have better visibility into the journey conditions. This enhanced visibility facilitates mobility and reduces pollution by rerouting around congestion, and also increases safety with collision avoidance and failure warning mechanisms.

This expectation for vehicle cleverness is also present for any organization managing fleets. With hundreds or thousands of deployed vehicles and crews, organizations need to be able to know where each vehicle is, be warned of mechanical issues, and, in short, be able to view and manage the fleet as a whole without having to rely on occasional verbal input from each vehicle driver. Here again, IoT provides powerful tools to combine individual vehicle monitoring (for the benefit of the vehicle crew) with central reporting to help the fleet management team automate maintenance requirement warnings, locate each vehicle and optimize team rotations, and use big data to manage the fleet operations efficiently.

Trains always run on tracks. Mass transit (buses, tramways) may share the street with other vehicles and are therefore often subject to the same challenges relative to congestion. Leaving your car at home to take the bus offers limited incentive if the bus is stuck in the same congested traffic that you would experience in your car.

Trains cover multiple realities. Some of them travel between cities. Mass transit systems (including light rails, metros, buses, and so on) travel over shorter distances but with a much higher frequency. An incident on one mass transit line can be disruptive to passengers in multiple other lines, thus affecting the travel of potentially millions of people. By contrast, an incident on an inter-city track is likely to affect only traffic on that path.

Mass transit passengers may use more than one transit system or one transit line when they travel. For example, traveling on a suburban train and then on a bus (or vice versa) can be a normal part of a daily commute. Basically, the traveler’s concern is to find the fastest route between two points. When events affect the efficiency of one system, the traveler must be able to evaluate alternate solutions and adapt in real time. In contrast, inter-city lines typically offer fewer alternative options between two given points.

Sizing is an issue. A train that travels daily between two cities is likely to have the same approximate quantity of cargo and/or number of passengers each day, with predictable peaks and valleys (such as for weekdays vs. weekends and holidays). By contrast, an intra-urban mass transit system will also have well-known peaks (business peak hours), but external events can suddenly change the load on the system. A concert in a particular location may bring thousands of new passengers. A disruption on another mass transit system may re-route thousands of travelers to a parallel system. In this context, planning for load and frequency is much more difficult than for inter-city trains. The transport administration must react in real time to maintain the efficiency of the system.

Reality is a bit more complex, however. For example, the United States tends to prefer air travel to trains. Yet, the United States includes 140,000 miles of track across the country.⁵ These are inter-city tracks (and don’t include city transportation) that are used by thousands of trains every day, belonging to multiple companies, carrying passengers or freight or both. Even with the best timing tables, things become complex as soon as an unexpected event occurs (for example, an animal or tree on the tracks, a broken piece of equipment forcing a train to stop). Even without accounting for the unexpected, coordinating times and positions is complex. Complexity increases even more where tracks intersect.

Looking at an individual train also shows this complexity. Suppose you are in charge of operating a train daily between two cities that are not too far apart. Passengers or cargo are expected to leave on time and arrive on time. Freight customers or passengers should not worry about weather conditions. The train should achieve the same performance when heavy rain falls, when the track gets covered by blocks of ice, or when twisters or hurricanes blow objects on the path. They also should not worry about mischievous individuals positioning objects on the tracks or stealing signals or cables.

Signals have been used along the track as long as trains have been running. These signals can let the engineer know if the train is approaching a junction or crossing, and different signal colors indicate whether the junction barriers are up or down. With magnetometers, these signals can also detect a passing train and remain on “other train close by” warning for a specific duration.

Making sure a train gets to its destination safely and on time involves the coordination of multiple signals and systems. A major challenge is to ensure the efficiency of all these systems and to make sure that the information is available in a coordinated manner. If a signal is missing or defective, how will the maintenance team know? What should the locomotive engineer do? If a train has to stop because of an issue on the track, should the train behind get this information in order to stop? If the track issue requires heavy repairs, can the trains be routed to a possible alternate path around the affected segment? For such purposes, IoT can dramatically improve the safety and efficiency of operations, tracking the positions of trains and their speed, and collecting data on the state of the tracks, signals, power lines, and other infrastructure elements along the tracks. Having a real-time view into the state of the rail infrastructure considerably reduces the risks of delays or accidents.

If these concerns appear at the scale of a single train, imagine how complex they get when brought to the level of the entire journey. Rail is usually only one part of the journey of goods. Cargo needs to be delivered on time, or the entire supply chain may be affected.

Similarly, a passenger getting to a train station expects an up-to-date and accurate train timetable (which takes into account the “unexpected events of the day” that could not have been compensated for) and a planner option to choose the best alternative, if needed. Once onboard, the passenger also expects a variety of services that go beyond simple transportation (for example, working and clean toilets, food, comfortable temperature, Internet connectivity). As a result, the train industry faces multiple challenges: Ensure passenger safety, run trains on schedule despite any unexpected events, and offer an onboard passenger experience of high enough quality and comfort that travelers will want to take the train again. IoT can be used to track goods, offer a real-time view into the journey (delays, expected arrival, and so on), and also help optimize the travel experience by tracking and reporting the onboard equipment conditions (from defective toilet alarms to number of sandwiches sold) to allow efficient and targeted maintenance at the next stop.

The users are the first field-level actors. When you get in your car, you want to have a comfortable, predictable, and efficient journey. Your car has to function correctly. (Despite what romantic movies may try to tell you, a car breakdown is usually not a pleasant experience.) When elements of your car are wearing out or on the verge of failure, you want to be informed before the failure occurs. Sensors can provide a clear view of your car’s condition. Intelligent algorithms can anticipate wear and warn you long before breakdown. As you start a journey, you also want to have an idea of the travel duration and conditions, including traffic, road status, and weather. Your car has to be able to operate in comfortable conditions in (almost) any weather. If traffic slows your journey, your car’s system should be able to inform you (before traffic gets heavy) and offer alternate options. In short, you need your car to provide information about its own operational state, anticipate its degradation, and compensate for changing external conditions. You also need information about the journey and the environment where the journey takes place. With IoT, your car can communicate with the roadways infrastructure, be warned about any approaching issue (accident, road blocks, and so on), and also provide you with a view of the expected journey (travel time, weather conditions, and so on).

What is true at the scale of a single driver is also true at the scale of an entire fleet. Imagine that you are running a cable TV company, a power utility, or any other company with a fleet of vehicles. You also need to be able to tell your customers how long it is going to take for the truck to reach them and incorporate traffic density into each crew’s daily workload, based on time and location of travel. The concerns of an individual driver get multiplied by the number of vehicles you have to manage. Being able to track each vehicle in real time or near real time solves this challenge. With smart objects, a vehicle can also report tools and equipment levels to ensure that the crew is always optimally equipped to perform the next mission. If a required tool is missing, the vehicle can be routed to a collection point, or a nearby crew can be sent instead while the other team is routed to another mission for which the vehicle has the appropriate equipment.

The same type of needs appears when you, as an individual traveler, embark on a mass transit journey. In this case, you are free from the need to care about the vehicle. The transit operators are in charge of the journey. Although the state of the transit vehicle does affect your journey, you do not need to care directly about the vehicle; you can just complain if the operators did not take care of it, and the vehicle breaks down. But you still want to have information about the journey (such as transit time and conditions).

Mass transit operators inherit the same worries regarding vehicle state and general traffic conditions. They also operate a fleet and have the same fleet management concerns as private organizations. However, they also operate at a higher level than private drivers. Degradations of driving conditions not only affect many of the vehicles they operate, they also potentially generate more pollution and reduce customer satisfaction. As mass transit is more effective than individual vehicles (in terms of quantity of passengers transported over units of road or track space), these operators have to balance the quantity of vehicles on the road to the cost of operating the vehicles. They also have to balance the travel lines and collect as many passengers as possible, thus maintaining an economically sound solution (if that is their mandate) while being useful to the city population.

At an even higher level, cities either operate the mass transit system directly or have a stake in the mass transit organizations. As such, city authorities (and often citizens who vote on new funding for public transit) have a say in which new tracks need to be built, which street will be made available, and over which travel path, to complement other transportation systems. At this scale, transportation management is not about individual vehicles. It is about congestion and coexistence. More mass transit lines reduce congestion, but only if they fulfill the needs of the citizens. (A transit line between locations that no citizens care about is just a waste of resources.) Incentives to use transit systems can be developed using toll systems and revenue from public transport fares. When congestion occurs, emergency vehicles must have a way to circulate through traffic. Just behind them, mass transit vehicles should have better access to the infrastructure to favor mass transit over individual vehicles.

The same preoccupations are visible for trains. The main differences lie in the distance traveled and alternate transportation options. If a bus breaks down, you may be able to get on another bus or take the subway. If a train breaks down between two cities, passengers and cargo are stuck, sometimes for hours. The effect of issues on the passenger experience is worse. Customer satisfaction is a higher concern with trains than with urban mass transit because there are no immediate alternatives when things go wrong. However, it is much easier for a traveler to decide to use another option for travel (drive or fly) the next time. Cargo customers are not as flexible as passengers, but they may also study alternate transport options if freight is notoriously delayed on a given route. In urban mass transit, travelers may decide to drive instead of use public transit, but immediate alternative options (another bus or the subway) are usually more readily available to limit the extent of the poor traveler experience. As a result, train operators are usually very sensitive about customer experience and travel reliability. This does not mean, of course, that mass transit operators are not sensitive to the traveler experience. They compete every day against alternative transport options and also focus heavily on the passenger experience to maintain and improve their revenue stream.

People can optimize resources available to them, but localized information in possession of individual drivers is not always sufficient. Sharing this information over radios and other communication means still provides a limited view of the overall conditions.

The story is well known (in the somewhat self-contained circles of mass transit optimization specialists) of a large city in South America whose authorities thought of delegating the task of optimizing public bus travel efficiency to individual drivers. They thought that because the drivers are in the street, they have a better view on local conditions than any higher authority. The mass transit administration therefore enacted a rule that would tie the driver’s pay to his or her performance. Performance would be measured in the time taken to travel each bus from the start to the end of the line and in the number of passengers transported along the way. The reasoning was that this system would encourage drivers to help expedite boarding and alighting of passengers and to find ways around local congestions.

However, stating the objectives that way had a different effect than what was desired. After just a few weeks, buses stopped following the intended bus routes. Drivers would simply take shortcuts, bypassing congested streets—and also bypassing the stops they knew had small numbers of passengers (and not caring about the passengers’ expectation to stop at smaller stops), and would engage in road wars and races to be the first to get to large bus stops, where they knew they would collect the largest numbers of passengers. The drivers did fulfill the mandate as specified, but the overall gain on mass transit efficiency was not achieved.

IoT provides a better solution because information can be local and global at the same time, and it can be made available to multiple stakeholders, who can all benefit from the knowledge gained from the system.

IoT allows smart objects to communicate and to deliver valuable services based on that communication. Any information discovered by your car’s sensors can be shared with systems outside your car. When the information is valid locally, it should be made available locally. When other cars approach a given area, they are warned about congestion due to a local accident, slippery conditions because of oil spilled on the pavement, or difficult traffic due to a broken street light or faulty railroad junction system. This communication implies that there must be a car-to-car, or vehicle-to-vehicle (V2V), information exchange system (one that protects your privacy while providing useful information) and also a vehicle-to-infrastructure (V2I) information exchange system so that local information can be made available where it is relevant.

When the information is relevant solely to your car, it can be made locally available but may be shared with third-party systems. For example, getting a warning that your car is due for an oil change is great, but wouldn’t it be better if your dashboard also popped up possible appointment slots available at your local car care provider? Similarly, if your car maker launches a recall for a defective piece of equipment, wouldn’t it be useful to get an indication on your dashboard if your car is affected? Such communication requires an always-on connection between the vehicle and the Internet.

The reason apps on your phone are able to provide optimal navigation is because your phone is connected to the Internet, and traffic data is updated in real time. However, your phone has no connection to the car’s onboard systems. Connecting the car directly to the Internet or to your phone brings all the advantages of connectivity to your travel experience. Applications are endless. For example, your car manufacturer can map weather forecasts to a very granular level and dynamically adjust car engine settings to adapt to local conditions and save fuel. In a more palpable manner, startups have begun making smart windshields and smart headlights. The lights blink very fast (50 times per second), faster than the eye can detect. For the driver, there is continuous light on the road. At the same time, the windshield is covered by a transparent screen that can turn black. When two equipped cars face each other, they synchronize their lights and screens. When the lights of the car coming in your direction are on, your screen is darkened, and it becomes transparent when the lights blink off. Because the blinking rate is faster than persistence of vision, the result is that both drivers see the road lightened by the beams, but neither of them get blinded by the oncoming lights. This technology optimizes the driving experience for your eyes and greatly improves safety. Inventions of a similar nature are too many to list, but all of them share the same concept: Your car can communicate with the infrastructure and other cars to exchange information that makes your travel experience easier.

This IoT intelligence also has a direct effect on a mass transit user. When walking toward a bus station, a text message to a special number (mentioning the bus ID) or a phone app can display the closest bus stop location and estimated wait time. When waiting at the bus stop, a smart panel can display the expected wait time until the next bus and an estimation of the travel time to any destination. This estimation is real time and smart (based on current traffic conditions and also factoring in the anticipated changes in traffic density in the upcoming hours). At the scale of a city, a journey planner informs you about the travel conditions across the city and across all transit systems and can suggest the best route to your destination. Many other IoT use cases allow for better management of city congestion. (Refer to Chapter 12 for more examples.)

Another effect of IoT on vehicle-to-infrastructure communication is increased safety. For example, a major contributor to car accidents in congested traffic is stop-and-go conditions (when traffic runs at moderate or high speed and then suddenly comes to a stop and becomes fast again a bit farther down the road). The causes of stop-and-go are well known: traffic density (merging lanes), roadside distractions (car accidents, unusual phenomena on the side of the road), inclement weather (patches of rain or mist), poorly coordinated street lights, and reduced lane sizes. Some elements are structural to sections of a road (merging lanes, reduced lane width), and others are occasional. The combined effect of these elements can create stop-and-go effects for many kilometers.

A common way to reduce stop-and-go traffic is to carefully regulate the flow of cars entering the various sections of the road. An optimal injection rate speeds up the overall road traffic, resulting in a more fluid flow (and more cars injected to and traveled on the road per unit of distance and time). IoT coupled with machine learning is a formidable combination for achieving this goal. Traffic density information collected from sensors in the vehicles and on the infrastructure—for example, vehicle-counting cameras, pressure cables recording vehicles and speed, or optic cables in the asphalt that can measure traffic density by estimating the deviation of the light beam due to local vehicle pressure on the asphalt—can dynamically adapt to local conditions and coordinate lights to solve stop-and-go issues and increase overall car flow. At the same time, a sudden drop in traffic fluidity (which may indicate an accident) can trigger an alarm in traffic authority control centers. This alarm can be relayed to emergency organizations, allowing emergency vehicles to be dispatched faster. At the same time, a circle of awareness can be drawn around the accident area, with multiple benefits:

Approaching drivers are warned about the accident zone (infrastructure feedback into the vehicle smart system).

Road entrance ramp traffic lights are adjusted to let fewer cars per minute access the affected section.

Drivers who are near but outside the zone can dynamically receive alternate route suggestions. This has to be done in a centralized, and therefore intelligent, manner. Today, your navigation app can alert you if the road ahead has a slowdown. However, thousands of drivers around you receive exactly the same information and choose exactly the same suggested alternate route, resulting in no overall benefit. Centralizing the system allows for live monitoring and smart distribution of alternate routes; several alternate routes can be distributed for re-routing load balancing.

Emergency service vehicles can ignore the redundant calls they receive reporting the accident. When an accident occurs on a busy road, hundreds and sometimes thousands of drivers call emergency services to report the accident, and emergency services must determine if each call is about a new accident or about an event for which teams have already been dispatched. The circle of awareness can be used to associate similar and overlapping calls from within the circle to the same event. At the same time, smart sensors can detect if another accident happens nearby, thus simplifying event de-duplication.

Roadside sensors can do much more than just count cars. Air quality can be measured, and so can weather conditions. This information can be relayed to central systems for monitoring and alerting. Other sensors can be implemented into the road infrastructure and objects to improve maintenance and safety. For example, sensors in the road can measure the amount of water penetrating the asphalt and evaluate the wear of the surface. On bridges, structural sensors can evaluate the strain and stresses on structural steel members, and tiltmeters can measure the settlement and relative displacement of a bridge and the tilt of piers and abutments. Accelerometers can measure the vibrations and dynamic responses to traffic, wind, or even seismic activity. Figure 13-2 shows an example of these sensors applied to a bridge.

All this information can be reported to roadway maintenance centers, where proactive maintenance can be planned before disruptive events result in accidents or blocked roads. The same types of sensors can be installed on the sides of mountain roads. In short, IoT allows transit authorities to not only monitor and optimize traffic conditions but also proactively monitor the infrastructure.

This information also implies fog and cloud computing. A bridge may incorporate multiple sensors. Not all of them need to report detailed information. A simple “green” status may be a sufficient summary most of the time. Similarly, a standard modern car has multiple sensors generating data. Part of this data is significant only for the driver and should stay in the car. Part of this data is only locally significant and should be processed by roadside fog computing systems. Only the part of the information that is relevant to larger systems (car data for your manufacturer, for example) should be relayed to the cloud (with or without preprocessing in the fog).

With IoT, individual drivers can benefit from a safer and more predictable journey. Traffic authorities can better regulate the flow of vehicles and better manage the roadways infrastructure. These IoT solutions also benefit bus intra-city travelers by providing accurate transit information, smart maps, and journey planners.

IoT applied to mass transportation vehicles can also massively improve travel experience. Monitoring a bus’s performance is an obvious use case, similar to car preventive maintenance. The same logic also applies to railways. For example, many types of trains are powered by electric cables hanging over the track (or, for subways, positioned near the track). Any damage to a cable or any object on the power line can eventually result in trains stopping. Fast passing trains can increase the damage (or break the object, which then becomes a hazard on the track). In the past, traditional rail maintenance was all about visual inspection, which takes time and may render portions of the railway unusable (while inspectors slowly and carefully examine each meter of power line). With IoT, smart sensors are installed on the power bar on top of the train (called a pantograph). As soon as the contact to the power line varies from acceptable limits (based on multiple trips used as a baseline), the sensor automatically sends an alert with the exact GPS coordinate, allowing a maintenance crew to be dispatched before damage becomes severe.

With the same logic, smart sensors can be installed on the wheels of locomotives and cars to process the sound of the wheels on the track and identify any abnormality that may indicate wheel or track wear. Locomotive performance is measured in real time and compared from one trip to the next for track maintenance needs. Inter-car connection systems measure the next-car pull force to track abnormalities (an engaged break, an abnormal cargo load, and so on). On the side of the track, detectors can read information sent by tags installed on cars. As the train passes, each car is identified, along with its order in the train (train cars have a tendency to be swapped from one train to the other, making individual car tracking a very challenging task), and also useful data such as the level of water available in the car toilet reservoir, the details of food sold, or identifiers for the carried cargo. This information is communicated in real time to the control center, where proactive action can be ordered (for example, car inspected, toilet reservoir refilled at the next stop, food supply replenished, cargo location tracked).

Other sensors on the trackside can observe the environment and compare it to known parameters. Such systems can measure water table levels (which affect rail embankments if the ground becomes waterlogged) and landslides, and they can also compare the picture of the passing train to averages and thus detect unusual side bending or other abnormalities. Junctions are also a key location for IoT, and sensors can be used at junctions to detect an approaching train (along with its speed), a failing signal or barrier, or a vehicle on the track, and generate proactive alarms or emergency stops.

IoT can also be extended to the carriage itself, and these applications span across all mass transit systems. Cameras linked to big data processing engines can detect crowd density and can anticipate peak hours, and they are also able to detect abnormal movements that are categorized automatically (unstable cargo load, aggression, accident, fall, and so on) and can trigger the right alarm for the right team. Intersection with social media is used often to predict traffic on particular lines and sections. At a simpler level, this data can be used to provide optimal journey planners. These planners help predict more than the duration of the journey; they can also predict the conditions of the journey that affect the customer’s satisfaction and can impact business. Not having a seat in a train or having to be pressed into a crowd in the subway or a bus is likely to yield negative feedback on mass transit. Being able to use big data and analytics to plan for the right density of trains or buses is key to improving travel conditions. But just being able to proactively inform the traveler is already a giant step. In general, travelers are less likely to feel negatively about conditions of their journey if they are warned in advance about those conditions.

For all these use cases, and many more invented each day, IoT helps improve safety and improve comfort on the journey.

Individual vehicles need an architecture to exchange information with the rest of the world. Range can be short or long, with information being local or destined for the cloud. In most cases, both short- and long-range communications are used, depending on the purpose. Similarly, some information is processed locally (fog computing), while some information is sent to and processed in the cloud. Communication also needs to happen between vehicles and between the vehicles and the infrastructure.

Mass transit systems using roadways (buses, tramways, and so on) benefit from an individual vehicle architecture. This architecture can be globally labeled IoT for roadways. Road mass transit organizations also need a more global architecture to manage fleets (for example, a maintenance yard) and to manage or react at a larger scale to changing road conditions.

Railways need their own architecture to allow for traffic, safety, and fleet management. Inter-city railways display a particular sensitivity to the onboard passenger experience as travel durations are longer than intra-city travels.

In some rare cases, class 3 radios are installed to allow V2I communication. In this case, a common application is for traffic lights to interact with public transport systems (emergency vehicles or mass transit) and privilege those vehicles over the rest of the traffic. This application is known as traffic signal prioritization (TSP). Although it can use Bluetooth, a more common technology for TSP is DSRC, detailed later in this chapter. Another application is class 3 Bluetooth radios installed on the side of the road that detect and read the unique MAC addresses of Bluetooth systems in passing cars. This allows for vehicle counting and speed estimation on the equipped section of the road. Although Bluetooth class 3 allows this type of exchange, Bluetooth is a minor player outside the vehicle (initially because of range limitations).

Another technology worth mentioning is WiMAX (802.16e). Although WiMAX does have its place in some last-mile or backhaul applications for IoT, and although it could fit well in the IoT for roadways space (as the specifications in Figure 13-3 show), it failed to get initial wide adoption in this space. With the competition of other technologies, the future of WiMAX for V2X is unclear.

OBU (onboard unit): The system onboard the vehicle

RSU (roadside unit): The system on the side of the road that communicates with the passing OBU

WAVE interface: The radio and communication system

Both OBU and RSU include a WAVE interface, allowing them to communicate.

V2V and V2I communications are possible, as shown in Figure 13-3. DSRC also allows a vehicle to relay information from another vehicle to a nearby RSU.

Communication can occur through several possible channels. At 90 km/h, establishing communications between a vehicle and a roadside system may be challenging. In most cases, the vehicle first needs to be aware of the presence of the roadside RSU. To simplify operations, the RSU uses a predefined static channel (channel 178 for DSRC in the United States) to announce to passing OBUs at 100 ms intervals what applications it supports on which channel. There are two types of applications: safety and non-safety (detailed later in the chapter). The OBU listens on the static channel (178), authenticates the RSU digital signature, executes safety applications first (if any), and then switches channels and executes non-safety applications. The OBU then returns to channel 178 to listen for the next RSU announcements.

The OBU matches the messages it receives from the RSU and other vehicles OBUs with its own GPS location and trajectory to calculate the position of the RSU or of other emitting OBUs. The RSU can also send specialized messages. Typical and common messages are as follows:

Traveler information: Curve speed, height restriction, icy road conditions, collision ahead, red light on, rail crossing, work zone warning, road hazard warning, and so on

Non-DSRC vehicle approaching: A vehicle that is not smart and will not warn or be warned about other vehicles’ positions and trajectories, which means an extra margin needs to be taken

Pedestrian alert: Pedestrian with a DSRC-enabled smart phone detected

Each channel is designated for specific use cases. For example, channel 184 is used exclusively for high-power, long-distance communications for public safety applications.

Emergency services typically use channel 184 to warn other vehicles of their approach. Public safety vehicles also use this channel to get green lights for street lights up to half a kilometer away. Such cases mandate that the vehicle be equipped with DSRC equipment and that the communication occur within less than half a kilometer. With DSRC, channel 172 is used exclusively for V2V safety communications (accident avoidance and mitigation). On channel 172, each vehicle broadcasts its core state information in a basic safety message (BSM) 10 times per second. Upon reception of the BSM, each other vehicle in range builds a model of each neighbor’s trajectory, assesses potential collision risks, and warns the driver (or takes control) in case of emergency. Typical applications are as follows:

A vehicle ahead of you (directly in front of you or a few vehicles ahead) stops or brakes. That car’s OBU broadcasts the stopped or brake status, allowing following vehicles to evaluate the proximity and risk of collision and automatically apply brakes, even if the driver does not see the stopped vehicle yet. This situation is illustrated in Figure 13-4.

You want to change lanes. From the neighboring car’s OBU messages, your car knows that there is a vehicle in your blind spot and displays an alarm when you turn the steering wheel.

Similarly, you want to pass a slower vehicle, and turn the wheel to change lanes. Your OBU detects approaching cars’ signals in the other travel direction and displays an alarm (or takes control for collision avoidance). These cases are illustrated in Figure 13-5.

You approach a road intersection with low visibility because of buildings. Your OBU already has a map of positions and trajectories of other vehicles and can help avoid collisions.

These applications are obvious for the safety of vehicles on the road. However, IoT for connected roadways is about more than just safety. Private apps can be implemented to ask the RSU to relay data to the Internet. The RSU is in this case is just an IP forwarder (it does not necessarily process the data). The example of vehicle diagnostics forwarded to the car maker is provided in the previous section, but many other applications are possible. V2I applications fulfill many requirements of fleet management. In the example provided above of the utility company deploying a fleet after a storm, V2I allows the trucks to communicate through RSUs on the side of the road with the utility company control center to complement direct cellular connections. When a vehicle is sent for maintenance, it automatically uploads its status and log data (service record, recalls, past maintenance, and so on) to better target the maintenance tasks at hand. When coming back to base, trucks can upload their records (speeds, load details, travel duration, and so on). Identifying approaching vehicles may also be very useful for restricted parking access control or even automatic toll collections. Similarly, a rental car company can track each vehicle on the parking lot, along with mileage, fuel level, and many other relevant information, expediting the rental operations.

Dedicated Short Range Communication (DSRC): This is the name of a band allocated in the 5.9 GHz region of the spectrum by regulatory bodies around the world for the needs of the vehicle industry, to be used by intelligent transportation systems (ITSs). The band is 75 MHz wide in the United States (allocated by the US Federal Communications Commission [FCC]). The band size is slightly different in other regulatory domains. However, worldwide allocations are in the same region of the spectrum, and the same radio and antenna can be used for any of these regulatory domains’ implementations.

ASTM Standard E2213-03: The American Society for Testing and Materials (ASTM) developed this standard. Although the name indicates this has an American origin, ASTM is in fact a worldwide nonprofit organization that creates standards. ASTM realized that the region of the spectrum allocated by the FCC for DSRC in 1999 was also used by Wi-Fi. ASTM therefore modified 802.11 to adapt it to vehicle communications. The result of this work was published in 2006 as ASTM Standard E2213-03.

WAVE (802.11p): This is an amendment to the 802.11 standard. 802.11 is defined by the IEEE, so ASTM work could not possibly be integrated directly into 802.11. In 2004, the IEEE 802.11 working group created the 802.11p task group to adapt 802.11 to vehicular communications. The group, named Wireless Access for the Vehicular Environment (WAVE), published its amendment in 2010.

IEEE P1556 and P1609: This is a family of protocols related to vehicular communication. While the 802.11 group was working on WAVE, the idea of transmitting information between vehicles and infrastructure raised legitimate concerns about privacy. Another IEEE group created P1556 (Standard for Security and Privacy of Vehicle/Roadside Communication Including Smart Card Communication). This standard was renumbered IEEE 1609.2 and integrated into the larger P1609 family of protocols for WAVE listed in Table 13-1.

The relationship between these various standards is a bit complex. For example, WAVE is based on 802.11p, but its P1609 approach is concerned with wireless access for vehicular environments in general, not just the first two layers. Figure 13-6 summarizes the interactions between these standards and the OSI model.

The Society of Automotive Engineers (SAE) also defines standards that apply to WAVE. SAE J2735 defines the messaging schema implemented over DSRC to enable V2I and V2V data exchanges, and SAE J2945 defines the minimum performance requirements for DSRC systems.

Being based on 802.11, DSRC/WAVE communications are half-duplex. 802.11 physical and data link layers are optimized for speeds up to 90 km/h. For vehicular communications, 802.11 was also modified to allow communications without the requirement for an access point. The need to rely on an access point and mandate authentication/association messages is not practical when a vehicle is moving rapidly. Therefore, communications without association are optional but allowed; the concept of a cell, or Basic Service Set (BSS), is still present, if needed. 802.11p builds on previous 802.11 amendments, integrating the concept of QoS and various statistical priorities for different frames types (defined by 802.11e in 2005).

DSRC is driven by local regulatory bodies, such as the Federal Communications Commission (FCC) in the United States; the European Telecommunications Standard Institute (ETSI) in Europe, which works in coordination with the European Committee for Standardization (CEN); and the Association of Radio Industries and Businesses (ARIB) in Japan. Each regulatory body defines the frequencies and radio output power allowed for DSRC.

For example, in the United States, the available spectrum is divided into seven 10 MHz-wide channels (channels 172, 174, 176, 178, 180, 182, and 184), allowing a data rate of 6 to 27 Mbps over a typical range of 300 meters (1000 feet) to 1000 meters (3200 feet). As described in the previous section, channel 178 sits in the middle of the band and is designated the “control channel,” and some channels are reserved for specific communication requirements (for example, channel 172 for basic safety messaging).

Other regulatory bodies determine the “rules of the road.” For example, in the United States, the National Highway Traffic Safety Administration (NHTSA) determines which vehicle equipment is authorized or mandated on US highways. The agency, driven by the government, is working on new rules that could mandate DSRC in all vehicles by 2020.⁶

DSRC is the primary protocol for V2I communications, but it is not the only protocol you will encounter for vehicle and roadway exchanges. Table 13-2 compares DSRC to other protocols for connected roadways.

The vehicle carries the OBU. The OBU does not operate independently. It needs to collect information from other sensors, such as the vehicle location unit (VLU), also called the automated vehicle location (AVL) unit. The onboard computer needs to process data about the vehicle and send it to the cloud or the other vehicles. Computer-aided dispatch (CAD) is the common name for this function. CAD was initially designed for dispatching vehicles and technicians, but was later extended to include any vehicle data and emergency management software. A ruggedized router is typically needed to connect these various elements.

The roadside features RSUs. As an RSU is also an IP forwarder, it also commonly includes a ruggedized router. The RSU may communicate with the backbone over wireless technologies. However, Ethernet and fiber are common options, as roads, streets, and roadside fixtures are more and more commonly equipped with wired communication possibilities. The RSU can also connect to streetlights. In that case, a traffic signal controller (TSC) with traffic signal priority (TSP) capability is installed either at the RSU or the street light. This functionality allows the emergency vehicles to control the streetlight through DSRC while in range of the RSU.

Several RSU routers can connect to a common ruggedized switch, still in the roadside layer. Data is then transported over the metro network. A common technology for this space is MPLS. Aggregation routers collect traffic from multiple street-level switches. Carrier-grade routers interconnect the core of the network.

Data can then be forwarded to the different actors (car manufacturers, fleet management control center, traffic authorities, emergency services, and so on), where it is processed in the respective data centers. Figure 13-7 summarizes this IoT network architecture for connected roadways.

Note that this OBU/RSU architecture is relevant for V2X IoT. When sensors are integrated directly into roadside objects (that is, the roadside objects are not intended to communicate with vehicles but collect their own sets of data, such as bridge vibration monitoring), the amount of data to forward is more limited. In addition, sensors may be located in places where wired connections are not practical. In this case, longer-range technologies such as LoRaWAN are more common. LoRaWAN is discussed in detail in Chapter 4.

Communication has to happen in both directions. That is, the control center also needs to communicate with the driver about the day’s mission. This part is achieved with a computer-aided dispatch (CAD) module in the vehicle that allows information exchange between the crew and the control center. This real-time exchange allows for better use of the crew schedule by incorporating events in the schedule as they occur. The CAD also reduces communication costs, and it increases operations security by allowing the crew to alert the control center about any unusual events. Some fleets may also include security cameras. For example, delivery companies may deploy cameras around a vehicle in order to track theft while the vehicle is parked and the driver is delivering a parcel. Similarly, utility companies may need to capture the behavior of other vehicles when the utility truck is parked on the side of the road. In these cases, one or several video cameras capture and store data. When the vehicle comes back to its base, Wi-Fi is used to upload the recordings to a storage server.

With this logic, the vehicle includes a switch that connects the cameras and the crew CAD system (often a tablet or a laptop that can be docked in the vehicle and undocked when the driver needs to process information outside the vehicle). A router incorporates a cellular module and a Wi-Fi client card. This card is used for connection to the yard Wi-Fi system. The router can also act as an access point to connect the tablet or a Wi-Fi phone, as shown in Figure 13-8.

As a result, the communication architecture is slightly different when the vehicle is on the road than when the vehicle is in the yard. The overall architecture is displayed in Figure 13-9.

While the vehicle is on the road, communications occur through cellular connections most of the time. The mobile service provider network connects to the operations center, where data is stored and analyzed and where location and CAD systems interact with each vehicle.

This structure is the same for any type of fleet, including mass transit vehicles (for example, buses), as discussed further later in this chapter. In the case of buses, bus stops are also equipped with cellular connections (or Wi-Fi in dense urban environments) to provide information to the operations center (video-based automated customer count at the bus stop, for example) and return information back to the bus stop (smart panels with wait time, for example).

When the vehicle is in the yard, communication uses Wi-Fi to allow for upload of recorded data (vehicle metrics, onboard camera recordings, and so on). Each yard Wi-Fi access point communicates, typically over an IP/MPLS metro network, with the central operations center, where a central wireless LAN controller manages channels, power, and individual vehicle Wi-Fi connections (authentication, firewalling, and so on).

Management of operations in the control center is a critical element of the IoT chain. The system needs to connect securely to each vehicle’s onboard system and retrieve information about the vehicle (fuel, state of various equipment, location, and so on) but also to potentially hundreds of other systems (customer interaction center, ticketing or billing, day planners, fuel or part supply chain, and specialized equipment management systems, such as truck buckets, onboard cameras, and so on). The management system is also likely to interact with smart systems that analyze specific data collected from the field to provide actionable analysis back to the system. Tire and oil pressure are obvious examples, but the system may also monitor how many meters of wire are still available on the vehicle, or monitor biometric values from a driver who is performing hazardous tasks.

While the vehicles communicate primarily with the control center, an Internet connection may also allow for communication with third parties (for example, vehicle part manufacturers or various maintenance contractors).

Fleet management also benefits from V2V communications. A growing example of leveraging these exchanges is platooning. Large 18-wheel trucks do not have a shape optimized for air penetration; rather, their shape is optimized for maximum cargo loading. Therefore, they consume a lot of energy just pushing the truck mass through the air. The air flows back in the form of turbulence a few tens of yards behind the truck, while the air just at the back of the truck moves at the speed of the truck. With platooning, a number of trucks follow one another at close range. This structure has several advantages:

Only the first truck consumes air-penetration energy. The following trucks stay in the quiet zone and benefit from the first truck’s air trail.

The group of trucks consume less space on the road. They form a compact block instead of a long line.

With V2V communications, a zero reaction time is implemented for the entire convoy. When the first truck brakes, all the following trucks also brake exactly the same way, immediately. This results in safer travel for the entire convoy.

As each following truck sets its speed based on the previous one, there is no need for each driver to manually evaluate the previous truck speed, alternating between gas pedal and brake to adapt to changes and terrain. The coordinated exchanges allow the followers to simply mimic the first truck’s speed pattern, resulting in lower fuel consumption.

Truck platooning is not autonomous driving, as each truck has a driver. Coordination between trucks through V2V communication optimizes the travel. At the control center, each truck is still monitored, along with individual driver action. However, the entire convoy can act as a single block.

However, mass transit expands beyond buses. (The architecture for trains is discussed next.) In addition, buses need expanded capabilities beyond what is offered by DSRC.

Buses do not always travel in cities equipped with RSUs, and they are not always surrounded by other vehicles with OBUs. Therefore, leveraging IoT for buses boils down to fulfilling a need more than implementing a specific technology:

Buses need to convey information about their location. This is basic GPS data. Technical information about the bus state is also needed.

Buses commonly use cameras for safety and security purposes. These cameras can store recordings locally and upload via Wi-Fi their recorded content when the bus returns to its depot. However, live feed should also be accessible remotely in case of alarm or emergency.

Users like to be connected to the Internet while on their journey.

Sending GPS coordinates or basic vehicle status information at regular intervals does not require a DSRC architecture. A simple cellular transmitter can be enough to fulfill this need. When cameras are onboard the bus, cellular can also be used to provide live access (or transmit alarm messages) to a central monitoring station. The central station can also correlate information from other buses to calculate passenger or road traffic load and suggest alternate routes around congested points, when applicable. The purpose here is not to skip stops (although the central management system can calculate that skipping stops may be valuable, as explained shortly) but to avoid roadblocks due to accidents or unusually highly loaded choke points.

A Wi-Fi access point can be installed inside a bus to provide Internet access to passengers. A cellular data connection can relay the traffic over the distances needed. In some cases, where Wi-Fi is deployed along the bus travel path, a workgroup bridge (an access point configured as a client) can be used to connect the bus to the municipality Wi-Fi infrastructure. This Wi-Fi connection can also be used when the bus is in the maintenance yard.

The bus driver may also need to be in contact with the base station. Such communication can use either dedicated radio equipment or leverage a smart phone, either connected directly to the cellular network or over the bus Wi-Fi connection. Therefore, by contrast with the vehicle onboard architecture described in Figures 13-8 and 13-9, a bus’s onboard system would be as depicted in Figure 13-10.

In the case of mass transit, IoT is not limited to the bus itself. A bus stop can be equipped with a ruggedized router to allow for Wi-Fi connection (in case of municipality Wi-Fi access) or cellular connection. A fog compute platform receives updates from the cloud, and a screen displays the calculated time before the next bus (and the one after) so that passengers can decide if they should get onboard a crowded bus or wait for the one that follows. Bus load information may also be displayed. A smart panel can also be connected to the control center system to display journey information. The panel can display a map of the town, with the current congestion points. The panel can also suggest the best route between two points to help passengers optimize their travel time.

Finally, a bus stop can also include a basic presence detector aimed at providing an approximate count of the number of people waiting for the bus. This helps the control center decide whether additional buses need to be injected along this line. When a stop is in a heavily congested area, this counter can also help the driver of an approaching bus decide whether taking a shortcut and skipping a stop may be valuable.

Systems onboard trains are slightly different from systems onboard buses. The Wi-Fi connections are similar, and trains also use sensors; however, train sensors are in different locations and monitor different elements from bus sensors. Trains are also larger vehicles and therefore include more components, as illustrated in Figure 13-11.

The top layer summarizes the needs, which are similar for both trains and buses. Because train travel might be longer than bus travel, passenger services, such as infotainment, are more commonly expected in trains than on buses. Those passenger services obviously do not apply to freight.

The second layer describes the communication infrastructure used to address the needs of the train. This layer is different from the similar layer for buses. Trains run on tracks, meaning their path is controlled and predictable, allowing more deterministic connections. Dedicated communications systems can be built along the tracks and leveraged by all passing trains. CCTV recordings (full flow or triggered chunks) and sensor information can be uploaded, and prerecorded messages (matching targeted events) can be pushed to the trains when needed. Passenger Internet connection traffic also needs to transit through the railside connection system. The result is a need for high-capacity bidirectional transfers.

The third layer describes the objects involved in the connected train architecture, from sensors, cameras, and displays to onboard servers and storage systems. All of them require connectivity (and therefore an IP network).

The resulting IoT network architecture is displayed in Figure 13-12.

Inside the train, positive train control (PTC) and train management computer (TMC) systems integrate command, control, communications, and information networks for controlling train movements. Train vehicle management systems (TVMSs) provide detailed maintenance information and equipment status. These systems, along with other sensors, video cameras, and Wi-Fi access points, connect through an Ethernet switch, which should be ruggedized. Depending on the environment, the train communicates with the cellular network or Wi-Fi outdoor APs positioned along the tracks. Those outdoor APs connect to switches, commonly organized around robust redundant link protocols like Resilient Ethernet Protocol (REP; described in Chapter 9). Trackside cameras may also connect to the same switches, along with other equipment (specific sensors, IP phones, and so on). Ruggedized routers connect to the network transport side, the structure of which is similar in concept to that of other mass transit systems. In most cases, data is directed to the railway company data center. However, some data may be rerouted to third-party data centers (for example, cargo customers, food or parts suppliers, other contractors).

The main difference between the bus and the train mass transit architectures lies in the connection to the infrastructure network. Buses typically include a single coach. Connecting the coach and connecting the bus have the same meaning (beyond the English subtlety, where the “coach” means the passenger part of the bus). By contrast, a train consists of multiple cars. Each car includes sensors, cameras, Wi-Fi access points, and communication systems (for example, speakers, phones for staff). They need to communicate with the railside infrastructure and with one another. A completely distributed system may implement complete autonomy for each car. Each car has its own cameras, switches, sensors, APs, communication modules, rugged servers (for video surveillance, sensor data storage, and so on), and router, communicating independently with the railside infrastructure. However, this distributed model is expensive. A semi-distributed model, as shown in Figure 13-13, is more common.

In this semi-distributed model, each car has its own rugged switch, video cameras, sensors, and APs for its own monitoring and connectivity functions. However, cars are of different types (three in the example in Figure 13-13), and each type adds a specific component that is not present in all cars (such as rugged router, communication module, or server). Connections between cars allow the cars to share these functions. When trains are assembled, the rail operator needs to make sure to include enough cars of each type to allow for full train functionality.

The car-to-car connection can be wired. However, Wi-Fi connections are also common. In this case, a mesh Wi-Fi network is a very flexible structure. One of the APs (typically the AP associated with the car that includes the router) acts as the root access point (RAP), while the APs in the other cars are mesh access points (MAPs), as illustrated in Figure 13-14. (For a more detailed discussion on mesh Wi-Fi, refer to Chapter 14, “Mining.” Refer to Chapter 2, “IoT Network Design Architecture,” for more details on mesh network topologies.)

This inter-carriage Wi-Fi connection is implemented regardless of whether Wi-Fi is offered onboard. When Wi-Fi access is provided, the 2.4 GHz band is typically used for passenger access, while the 5 GHz band is used for the mesh backhaul, as shown in Figure 13-15.

Each car includes one or several APs to provide consistent coverage throughout the carriage. Traffic is aggregated and passed to the mesh network and then forwarded along to the RAP. The RAP can then connect through the router to a trackside wireless system (cellular) or even to satellite connections. When Wi-Fi is available along the track, the RAP can connect to another AP configured as a wireless client (for example, workgroup bridge [WGB]).

Depending on the trackside Wi-Fi capabilities, different throughput can be offered inside the train. Higher throughputs require that more WGBs be deployed. Each WGB connects to the trackside Wi-Fi infrastructure, as shown in Figure 13-16.

One challenge relates to the speed at which the train moves. Each WGB needs to roam from one railside AP to the next. Roaming needs to stay within 15 ms to limit communication disruptions. This requirement dictates the position of the APs on the railside, their spacing, and the type of antenna.

All these systems need to communicate through a shared IP infrastructure. In addition, trains may commonly upload the core of their data once at the station. Station operations need to receive this data and process it. Therefore, the station needs to connect to the operator data center as well.

To address these challenges, vehicle manufacturers as well as transport and safety authorities have worked on several approaches. The efficiency of these approaches can be enhanced with IoT, resulting in connected vehicles, connected roadways, connected mass transit, and connected railways.

At the individual vehicle level, multiple sensors can provide a proactive view of vehicle conditions, limiting the number of surprise breakdowns. At the same time, intelligent onboard systems allow for a better travel experience by allowing the vehicle to dynamically react and adapt to surrounding conditions.

Technologies such as DSRC, which is built on 802.11, allow a vehicle to exchange information with the roadside infrastructure. This exchange is beneficial to the vehicle, which can now receive locally significant warnings. Specialized vehicles (such as emergency services) can also use this communication system to get privileged access as they pass through intersections. Private applications can leverage this system for fleet management or car monitoring.

These individual vehicle IoT enhancements also benefit mass transit vehicles (such as buses and tramways). IoT allows the transportation authority to have a global, dynamic, and adaptive view of transit conditions, anticipating maintenance needs and adapting the transport offer to the changing density of users in the network.

Travelers can directly see these benefits through more efficient transit systems and also through smart panels in bus or train stations that provide an intelligent view of the journey through the transit system. Trains also leverage these systems, with the added specifics of a vehicle moving along fixed tracks.

2. National Highway Traffic Safety Administration, Fatalities in the United States, September 16, 2016, https://crashstats.nhtsa.dot.gov/Api/Public/ViewPublication/812349.

3. World Health Organization, Global Status Report on Road Safety, 2013, http://www.who.int/violence_injury_prevention/road_safety_status/2013/en/.

4. American Public Transportation Association, Moving America Forward, 2013, http://www.apta.com/resources/reportsandpublications/Documents/APTABrochure_v28%20FINAL.pdf. Accessed December 24, 2016.

5. Dr. Jean-Paul Rodrigue, The Geography of Transport Systems, https://people.hofstra.edu/geotrans/eng/ch3en/conc3en/usrail18402003.html. Accessed December 24, 2016.

6. S. Abuelsamid, New Cars Could Be Required to “Talk” to Each Other as Soon as 2020, December 13, 2016, www.forbes.com/sites/samabuelsamid/2016/12/13/nhtsa-finally-issues-draft-v2v-communications-rule-could-be-mandatory-from-2021/#2efae50f6f23.