Connected Vehicles: Intelligent Transportation Systems

146 S. Shrivastava Do Not Pass Warning (DNPW) DNPW is intended to warn the driver of HV during a passing maneuver attempt when a slower-moving vehicle ahead cannot be passed safely using a passing zone, because the passing zone is occupied by vehicles moving in the opposite direction. This module can either provide advisory information or a warning based on the driver’s intent to overtake. The arbitration can be done by observing the left-turn activation signal over vehicle CAN. Figure 16a shows the relevant target classification zone for DNPW and Fig. 16b shows a possible scenario for DNPW. DNPW is applicable only for the Remote Vehicles driving in the reverse direction relative to HV in a lane that is classified as ahead left of the HV. DNPW Zone length can be thought of the addition of three different distances: Acceleration Distance, Overtaking Distance, Return Distance as shown in Fig. 17. Acceleration Distance is the distance that the HV travels while accelerating to switch to the oncoming lane. Overtaking Distance is the distance that the HV travels to overtake the slower vehicle. And, the Return Distance is the distance travelled by HV to return to its original lane. The DNPW Zone Length can be computed by simply adding the three distances shown in Fig. 17. A warning is issued if the longitudinal offset between the HV and RV plus a buffer zone length is less than the DNPW zone length and the distance travelled by RV during the calibrated overtaking time combined. Fig. 16 (a) DNPW target classification zones (b) An example scenario for DNPW

V2V Vehicle Safety Communication 147 Fig. 17 Distances that comprise DNPW zone Acceleration Distance = (H V Speed ∗ AccelT ime) (22) + 1 ∗ H V LongitudinalAccel ∗ AccelT ime2 2 OvertakingDistance = (H V Speed + Speed) ∗ OvertakingTime (23)

148 S. Shrivastava ReturnDistance = (H V Speed + Speed) ∗ ReturnTime (24) Where, Speed is the increment in HV Speed in order to overtake the slow-moving vehicle. A simple pseudocode for the implementation of DNPW is given below: DNPW_WARNING = FALSE IF ((RV_ZONE is AHEAD_LEFT) AND (RV_DIRECTION is REVERSE)) THEN DNPW_ZONE = ACCEL_DIST + OVERTAKING_DIST + RETURN_DIST TIME_TAKEN = K_ACCEL_TIME + K_OVERTAKE_TIME + K_RETURN_TIME IF (LON_OFFSET < (DNPW_ZONE + TIME_TAKEN*RV_SPEED + K_BUF_ZONE) THEN DNPW_WARNING = TRUE END IF END IF Where, RV_ZONE: RV relative zone as obtained from the TC module RV_DIRECTION: RV relative direction as obtained from the TC module RV_SPEED: Speed of Remote Vehicle DNPW_ZONE: DNPW Zone Length ACCEL_DIST: Acceleration Distance as calculated in Eq. (22) OVERTAKING_DIST: Overtaking Distance as calculated in Eq. (23) RETURN_DIST: Return Distance as calculated in Eq. (24) TIME_TAKEN: Time taken by the HV to complete overtaking and get back to its lane K_ACCEL_TIME: A Calibrated time taken by HV to travel Acceleration Distance K_OVERTAKE_TIME: A Calibrated time taken by HV to travel Overtaking Distance K_RETURN_TIME: A Calibrated time taken by HV to travel Return Distance LON_OFFSET: Longitudinal Offset as obtained from the TC module K_BUF_ZONE: A calibrated buffer zone length allowed DNPW_WARNING: FALSE – No Warning; TRUE – DNPW Warning Generated Blind-Spot Warning (BSW)/Lane-Change Warning (LCW) BSW safety application either provides an advisory alert or warns the driver of HV if another vehicle occupies the adjacent lane in Host Vehicle’s Blind-Spot. The application arbitrates one versus the other depending on driver’s intent to change the lane to the one occupied by another vehicle. A driver shows the intention to change the lane by activating a turn signal which information can be pulled into the system from the Vehicle CAN Bus. An extension of the Blind-Spot Warning is the Lane-Change Warning which generates a warning if the HV’s blind-spot is not currently occupied by a Remote Vehicle but will soon be occupied by a fast approaching vehicle and a collision is

V2V Vehicle Safety Communication 149 Fig. 18 (a) BSW/LCW target classification zones (b) An example scenario for BSW/LCW inevitable if the HV changes its lane. Clearly, this application module is relevant only if the RV is travelling in the same direction on an adjacent lane and the driver of HV intends to change the lane. Figure 18a shows the relevant target classification zone for BSW/LCW and Fig. 18b shows a possible scenario for BSW/LCW. The time-to-collision (TTC) decreases with increasing HV speed and RV-to-HV relative speed. To compensate for this decrease in TTC, BSW Zone length can be increased with increasing HV speed and the relative speed. A simple pseudo-code for the implementation of BSW/LCW is given below: BSW_WARNING = FALSE IF ((RV_DIRECTION is EQUIDIRECTIONAL) AND ((RV_ZONE is BEHIND_LEFT) OR (RV_ZONE is BEHIND_RIGHT))) THEN REL_SPEED = RV_SPEED - HV_SPEED IF (REL_SPEED > 0) THEN BSW_ZONE = K_BSW_ZONE_MIN_LEN + K_SPD_MULT*HV_SPEED + K_REL_SPD_MULT*REL_SPEED ELSE BSW_ZONE = K_BSW_ZONE_MIN_LEN + K_SPD_MULT*HV_SPEED END IF IF (LON_OFFSET < BSW_ZONE) THEN IF (RV_ZONE is BEHIND_LEFT) THEN IF LEFT_TURN_SIGNAL is ACTIVATED THEN BSW_WARNING = BSW_LEFT_WARN ELSE BSW_WARNING = BSW_LEFT_ADVISORY END IF

150 S. Shrivastava END IF IF (RV_ZONE is BEHIND_RIGHT) THEN IF RIGHT_TURN_SIGNAL is ACTIVATED THEN BSW_WARNING = BSW_RIGHT_WARN ELSE BSW_WARNING = BSW_RIGHT_ADVISORY END IF END IF ELSE TTB = (LON_OFFSET - BSW_ZONE) / REL_SPEED IF (TTB < K_LCW_TTB_THRESHOLD) THEN IF (RV_ZONE is BEHIND_LEFT) THEN IF LEFT_TURN_SIGNAL is ACTIVATED THEN BSW_WARNING = LCW_LEFT_WARN END IF END IF IF (RV_ZONE is BEHIND_RIGHT) THEN IF RIGHT_TURN_SIGNAL is ACTIVATED THEN BSW_WARNING = LCW_RIGHT_WARN END IF END IF END IF END IF Where, RV_ZONE: RV relative zone as obtained from the TC module RV_DIRECTION: RV relative direction as obtained from the TC module RV_SPEED: Speed of Remote Vehicle HV_SPEED: Speed of Host Vehicle REL_SPEED: Relative Speed BSW_ZONE: Blind-Spot Warning Zone Length K_BSW_ZONE_MIN_LEN: Calibrated minimum BSW Zone Length K_SPD_MULT: Calibrated HV Speed Multiplier K_REL_SPD_MULT: Calibrated Relative Speed Multiplier LON_OFFSET: Longitudinal offset as obtained from the TC module LEFT_TURN_SIGNAL: Left Turn Signal Status as obtained from the Vehicle CAN Bus RIGHT_TURN_SIGNAL: Right Turn Signal Status as obtained from the Vehicle CAN Bus TTB: Time taken by RV to enter the HV’s Blind-Spot K_LCW_TTB_THRESHOLD: Calibrated maximum TTB threshold for trigger- ing LCW BSW_WARNING: FALSE – No Warning; BSW_LEFT_WARN – Left Blind- Spot Warning; BSW_LEFT_ADVISORY – Left Blind-Spot Advisory Alert; BSW_RIGHT_WARN – Right Blind-Spot Warning; BSW_RIGHT_ADVISORY – Right Blind-Spot Advisory Alert

V2V Vehicle Safety Communication 151 Left Turn Assist (LTA) The LTA module assists the driver of HV in making a left turning maneuver at an intersection. It can use both V2V and V2I information to decide if it is safe to turn left at an intersection. Two types of messages, Map Data (MAP) & Signal Phase and Time (SPaT) are broadcasted from the Roadside Unit (RSU). Typically, MAP is sent every second and SPaT every 100 ms. MAP describes the physical geometry of one or more intersections. The SPaT message informs drivers about the current status and change of the traffic signal ahead as well as when the next signal stage changes [13]. It also provides information about approaching traffic to optimize the signal system. The IntersectionGeometryData Frame in the MAP message combined with the vehicle position can be used to determine if HV is in a lane for which left maneuver is allowed. The SPaT message provides the traffic light status (in MovementPhaseStateData Element of the SPaT message) for the lane that the HV is currently in. This module generates a warning if a RV is approaching fast towards the HV from ahead while HV is in a lane that has left maneuvers allowed and the Traffic Light State is one of the following: “permissive-green”, “permissive-yellow”, “protected- yellow”, or “flashing-yellow” [2]. The distance needed to be travelled by the HV to reach the intersection can be easily computed using the intersection geometry information in the MAP message and HV current position, which then further combined with a calibrated distance required to make a turn yields the total distance from HV to the road it needs to go on after making a turn. Figure 19a shows the relevant target classification zone for LTA and Fig. 19b shows a possible scenario for LTA. Fig. 19 (a) LTA target classification zones (b) An example scenario for LTA

152 S. Shrivastava Although similar, LTA module is different from DNPW in many ways. Unlike DNPW, any oncoming RV is of relevance for this warning module. Additionally, the lane and traffic light state should allow the HV to make a left maneuver with care. A simple pseudo-code for the implementation of LTA is given below: LTA_WARNING = FALSE IF ( (((ALLOWED_MANEUVER is MANEUVER_LEFT_ALLOWED) OR (ALLOWED_MANEUVER is YIELD_ALWAYS_REQUIRED))AND (LEFT_TURN_SIGNAL is ACTIVATED) AND ((MOVEMENT_PHASE_STATE is PERMISSIVE_MOVEMENT ALLOWED) OR (MOVEMENT_PHASE_STATE is PROTECTED_MOVEMENT_ALLOWED) OR (MOVEMENT_PHASE_STATE is PERMISSIVE_CLEARANCE) OR (MOVEMENT_PHASE_STATE is PROTECTED_CLEARANCE) OR (MOVEMENT_PHASE_STATE is CAUTION_CONFLICTING_TRAFFIC))) OR ((ALLOWED_MANEUVER is MANEUVER_LEFT_TURN_ON_RED_ALLOWED) AND (LEFT_TURN_SIGNAL is ACTIVATED) AND (MOVEMENT_PHASE_STATE is STOP_THEN_PROCEED)) )THEN IF ((RV_DIRECTION is REVERSE) AND ((RV_ZONE is AHEAD_LEFT) OR (RV_ZONE is AHEAD_FAR_LEFT))) THEN LTA_ZONE = DIST_TO_INTERSECTION + K_INTERSECTION_TURN_LEN LEFT_TURN_TIME = LTA_ZONE/HV_SPEED IF (LON_OFFSET < (LTA _ZONE + LEFT_TURN_TIME*RV_SPEED + K_BUF_ZONE))THEN LTA_WARNING = TRUE END IF END IF END IF Where, RV_ZONE: RV relative zone as obtained from the TC module RV_DIRECTION: RV relative direction as obtained from the TC module HV_SPEED: Speed of Host Vehicle RV_SPEED: Speed of Remote Vehicle LTA_ZONE: LTA Zone Length ALLOWED_MANEUVER: Data Element DE_AllowedManeuversas defined in [2] MOVEMENT_PHASE_STATE: Data Element DE_MovementPhaseState as defined in [2] DIST_TO_INTERSECTION: Distance to intersection computed using HV cur- rent position and Intersection Geometry Data Frame in the MAP message. K_INTERSECTION_TURN_LEN: Calibrated distance required to make a turn on an intersection. LEFT_TURN_TIME: Total time required to make a turn. LON_OFFSET: Longitudinal Offset as obtained from the TC module K_BUF_ZONE: A calibrated buffer zone length allowed LTA_WARNING: FALSE – No Warning; TRUE – LTA Warning Generated

V2V Vehicle Safety Communication 153 Control Loss Warning (CLW) The CLW module warns the driver of the HV if any RV ahead and in the same or adjacent lane as HV loses its control. A control loss event is defined as the activation of one of the following: Antilock Brake System (eventABSactivated), Traction Control Loss (eventTractionControlLoss), or Stability Control Loss (eventStabil- ityControlactivated). If RV detects a control loss event, it sets the corresponding flag in the Data Element DE_VehicleEventFlags [2] and broadcasts this information within the BSM. J2735 defines this Data Element in ASN.1 representation as the following. VehicleEventFlags ::= BIT STRING { eventHazardLights eventStopLineViolation eventABSactivated eventTractionControlLoss eventStabilityControlactivated eventHazardousMaterials eventReserved1 eventHardBraking eventLightsChanged eventWipersChanged eventFlatTire eventDisabledVehicle eventAirBagDeployment } (SIZE (13, ...)) A RV is relevant for the CLW application if it is ahead of the HV in either the same or adjacent lane as the HV, and its relative direction is either Equidirectional or Reverse. Upon receiving a BSM from the RV, if HV determines that the vehicle is in CLW Zone as shown in Fig. 20a and one of the control loss event flag is set, then a warning is issued if calculated TTC is lower than a calibrated threshold. Figure 20a shows the relevant target classification zone for CLW and Fig. 20b shows a possible scenario for CLW. A simple pseudo-code for the implementation of CLW is given below: CLW_WARNING = FALSE IF(((RV_DIRECTION is EQUIDIRECTIONAL) OR (RV_DIRECTION is REVERSE)) AND ((RV_ZONE is AHEAD_LEFT) OR (RV_ZONE is AHEAD) OR (RV_ZONE is AHEAD_RIGHT))) THEN IF((EVENT_ABS_ACTIVATED) OR (EVENT_TRACTION_CONTROL_LOSS) OR (EVENT_STABILITY_CONTROL_ACTIVATED)) THEN IF(RV_DIRECTION is EQUIDIRECTIONAL) THEN IF (HV_SPEED > RV_SPEED) THEN TTC = LON_OFFSET/(HV_SPEED - RV_SPEED) IF (TTC < K_CLW_TTC_THRESHOLD) THEN CLW_WARNING = TRUE END IF

154 S. Shrivastava Fig. 20 (a) CLW target classification zones (b) An example scenario for CLW END IF ELSE TTC = LON_OFFSET/(HV_SPEED + RV_SPEED) IF (TTC <K_TTC_THRES) THEN CLW_WARNING = TRUE END IF END IF END IF END IF Where, RV_ZONE: RV relative zone as obtained from the TC module RV_DIRECTION: RV relative direction as obtained from the TC module HV_SPEED: Speed of Host Vehicle RV_SPEED: Speed of Remote Vehicle EVENT_ABS_ACTIVATED:eventABSactivated event flag as defined in [2] EVENT_TRACTION_CONTROL_LOSS: eventTractionControlLossevent flag as defined in [2] EVENT_STABILITY_CONTROL_ACTIVATED: eventStabilityControlactivat- edevent flag as defined in [2] TTC: time-to-collision K_TTC_THRES: CLW time-to-collision calibrated threshold LON_OFFSET: Longitudinal Offset as obtained from the TC module CLW_WARNING: FALSE – No Warning; TRUE – CLWWarning Generated

V2V Vehicle Safety Communication 155 References 1. National Highway Traffic Safety Administration (NHTSA), Department of Transportation (DOT), “Notice of proposed rulemaking (NPRM),” Federal Motor Vehicle Safety Standards; V2V Communications, Tech. Rep. 49 CFR Part 571, 2016. 2. SAE International, “Dedicated Short Range Communications (DSRC) Message Set Dictio- nary” SAE J2735 Standard, March 2016. 3. IEEE standard for wireless access in vehicular environments–security services for applications and management messages. IEEE Std 1609. 2-2016 (Revision of IEEE Std 1609. 2-2013) pp. 1–240. 2016. DOI: https://doi.org/10.1109/IEEESTD.2016.7426684. 4. M. Raya and J. Hubaux, “The Security of Vehicular Networks,” EPFL Technical Report IC/2005/009, March 2005. 5. CAMP LLC - Vehicle Safety Communication 5 (VSC5), “Security Credential Management System Proof–of–Concept Implementation – “EE Requirements and Specifications Supporting SCMS Software Release 1.0”,” January 11, 2016. 6. IEEE guide for wireless access in vehicular environments (WAVE) - architecture. IEEE Std 1609. 0-2013 pp. 1-78. 2014.. DOI: https://doi.org/10.1109/IEEESTD.2014.6755433. 7. IEEE standard for wireless access in vehicular environments (WAVE) – networking services. IEEE Std 1609. 3-2016 (Revision of IEEE Std 1609. 3-2010) pp. 1-160. 2016.. DOI: https://doi.org/10.1109/IEEESTD.2016.7458115. 8. IEEE standard for wireless access in vehicular environments (WAVE) – multi-channel operation. IEEE Std 1609. 4-2016 (Revision of IEEE Std 1609. 4-2010) pp. 1-94. 2016.. DOI: https://doi.org/10.1109/IEEESTD.2016.7435228. 9. IEEE standard for wireless access in vehicular environments (WAVE) - identifier allocations. IEEE Std 1609. 12-2016 (Revision of IEEE Std 1609. 12-2012) pp. 1-21. 2016.. DOI: https://doi.org/10.1109/IEEESTD.2016.7428792. 10. IEEE standard for information technology– local and metropolitan area networks– specific requirements– part 11: Wireless LAN medium access control (MAC) and physical layer (PHY) specifications amendment 6: Wireless access in vehicular environments. IEEE Std 802. 11p- 2010 (Amendment to IEEE Std 802. 11-2007 as Amended by IEEE Std 802. 11k-2008, IEEE Std 802. 11r-2008, IEEE Std 802. 11y-2008, IEEE Std 802. 11n-2009, and IEEE Std 802. 11w- 2009) pp. 1–51. 2010.. DOI: https://doi.org/10.1109/IEEESTD.2010.5514475. 11. SAE International, “On-Board System Requirements for V2V Safety Communications” SAE J2945/1 Standard, March 2016. 12. ITU-T: OSI networking and system aspects – Abstract Syntax Notation One (ASN.1), “Information technology – ASN.1 encoding rules: Specification of Packed Encoding Rules (PER)”. 13. ISO/TC 204/SC/WG 18, Intelligent transport systems — Cooperative Systems — SPAT (Signal Phase and Timing) message, MAP (Intersection topology) message, Draft versions 2013. 14. Harding, J., Powell, G., R., Yoon, R., Fikentscher, J., Doyle, C., Sade, D., Lukuc, M., Simons, J., & Wang, J. (2014, August). Vehicle-to-vehicle communications: Readiness of V2V technology for application. (Report No. DOT HS 812 014). Washington, DC: National Highway Traf c Safety Administration.

Vehicle to Infrastructure Communications Samer Rajab V2I Overview V2I communication is an attractive solution for many connected vehicles problems. As such, V2I technology has been a focal point for extensive Intelligent Trans- portation Systems (ITS) research and deployment efforts in the recent few years. This activity has led to a leap in the technology readiness for mass deployment and adoption. Examples of V2I technology advantages are provided in the following: – Early benefit: Benefit to early connected vehicle adopters is probably the main driver behind the recent push for V2I research and deployment in the United States. Projecting into the future, it may take up to 10 years from a specific date to realize a 50% market penetration rate for DSRC equipped vehicles assuming all new vehicles are equipped starting from this date [1]. Customer purchasing vehicles that are equipped with V2V technology will suffer from limited benefit resulting from rare encounters between V2V vehicles during that time. V2I technology can address this issue by providing benefit to early V2V adopters resulting from interaction with infrastructure instead of other equipped vehicles. – Interface to road infrastructure: Vehicles interact with different type of roadway infrastructure during their everyday commute. This ranges from traffic lights and road signs all the way to the pavement markings. Improving this interaction by adding a communication link between vehicles and roadway infrastructure allows for more information, at higher distances, to be conveyed to vehicles from the infrastructure and the vice versa leading to safety and mobility benefits among others. S. Rajab ( ) 157 Honda R&D Americas, Inc., Southfield, MI, USA e-mail: [email protected] © Springer Nature Switzerland AG 2019 R. Miucic (ed.), Connected Vehicles, Wireless Networks, https://doi.org/10.1007/978-3-319-94785-3_6

158 S. Rajab – Expanding connected vehicle benefits to sparsely populated areas: V2I can be used to convey safety information (e.g. spot weather information) in a suburban and rural area where V2V communication may not be an option. Infrastructure may have its own information to be shared with vehicles, such as traffic light controller data or data collected from weather sensor. Alternatively, infrastructure may relay information transmitted from other vehicles that passed through an area in the recent past (e.g. Traction Control System activation inferring a slippery road). – Assist future autonomous vehicle functionality: adding future automated vehicles into the equation, V2I connectivity extends from just providing safety and mobility value to becoming a necessity. Automated vehicles operation require certain information about the roadway, such as up to date HD maps, which can be provided by the infrastructure. Several wireless communication technologies are being investigated in the indus- try and research community to support V2I communications. Examples of these technologies include DSRC, cellular communications, satellite communication and infrared communications. Each of these technologies has their advantages and disadvantages in terms of cost, availability and technical performance. However, it may be concluded that DSRC is currently the front-runner judging from the ongoing deployment effort across the United States. Notably, 5G cellular communication has been gaining momentum recently as a promising future technology that may compete with DSRC. Note that the term “Road Side Unite (RSU)” will be used moving forward in this chapter to refer to the computing device on the infrastructure side that includes the DSRC radio and is responsible for sending and receiving Over The Air (OTA) messages. V2I Messages This section provides the reader with details on existing V2I messages that have been standardized in Society of Automotive Engineers SAE J2735 standard [2] or are in the process of standardization. Notably, these messages may change between standard revisions. As such this book will provide a high-level overview of the messages structure and their intent. The reader may refer to the latest standard revision for further details on messages data elements. Notably, this book will use the same naming convention as the SAE J2735 standard in which a prefix of “DE_” labels a data element and a prefix of “DF_” labels a data frame.

Vehicle to Infrastructure Communications 159 MapData (MAP) This message offers the receiving side with a full description of an intersection, or multiple intersections, geometry. Such information enables roadway users, such as cars, motorcycles or pedestrians, to localize themselves at a lane-level accuracy within the intersection area. Lane level localization within an intersection or a corridor enable several applications, such as Red Light Violation Warning, which will be discussed in greater details in the following sections. Message Structure An overview of MAP message architecture including some of the essential elements structure can be seen in Fig. 1. The standard defines additional optional and “placeholder” data frames and elements which the reader can explore further in the SAE J2735 document if interested. MAP message can describe multiple intersections through DF_IntersectionGeometry data frame, each with a regionally unique identifier (DE_IntersectionID). An RSU transmitting MAP is also required to send the message revision number using DE_MsgCount. Going to further lower layers inDF_IntersectionGeometry we find the following fields that are used for lanes geometry description: • refPoint: a WGS-84 coordinate system location that includes longitude, latitude and optionally altitude. This location serves as a reference point using which, any point in the intersection geometry can be described by taking offsets to the reference point instead of using the full coordinates of that point. This method of using offsets to a reference point to represent geometry improves efficient by reducing the size of the MAP message. Fig. 1 MAP message architecture

160 S. Rajab • laneWidth: an optional field used to provide the width for all lanes in the intersection in centimeters unless otherwise specified in the following data frames/elements. • speedLimits: an optional list providing regulatory speeds for all lanes in the intersection unless otherwise specified in the lane description. • laneSet: this a mandatory list that contains all of the details regarding all lanes geometry in the intersection. laneSet is represented by DF_LaneList in the stan- dard, which is a sequence of up to 255 DF_GenericLane. Each DF_GenericLane contains information about a single lane in the intersection: – laneID: a unique ID assigned to the corresponding lane in the intersection. – name: an optional descriptive name that can be used for debugging purposes. – ingressApproach and egressApproach: optional unique indexes for different approaches in the intersection roads for both ingress and egress direction to the intersection respectively. – laneAttributes: a field containing attributes for a lane including lane angles and speed limits. – maneuvers: optional field that specifies the allowed maneuvers on a lane including straight, right, left, left or right turn on red, lane change, no stop, yield, move after a full a stop and proceed with caution. – nodeList: a list of nodes, each including a lateral offset, longitudinal offset and optional altitude offset and lane width, representing the lane geometry. This is the key field in MAP message that vehicles would use to map match themselves to a particular lane, and location within a lane. Such localization information can then be used for a variety of applications including Red Light Violation Warning, which will be discussed in following sections. – connectsTo: an optional field comprising a list of lanes that connect to this particular lane beyond the stop bar. – overlays: a list of lanes that have overlapping paths with the current lane. – regional: this an additional optional field reserved for regions that may require certain additions to the message. Signal Phase and Time (SPaT) The SPaT message is intended to deliver the traffic signal status including the active signal phases for different lanes, next phases, and their timing. This information may be transmitted for single or multiple signalized intersections. When linked with MAP message, SPaT enables a variety of V2I use cases including Red Light Violation Warning, signal priority and preemption for emergency and transit vehicle, eco approach and departure, also known as green wave providing speed recommendation to optimally traverse corridor at traffic signals green phases, among other possible applications.

Vehicle to Infrastructure Communications 161 Message Structure The following provides a detailed description of limited fields in SPaT message to explain the functionality while avoiding an unnecessary reiteration. The reader can refer to SAE J2735 standard for complete details of SPaT. Similar to all standardized DSRC messages, SPaT data begins with unique msgID (13 decimal or “0D” hexadecimal). As mentioned earlier, SPaT can support multiple intersections. This can be done by using the “intersections” field which is a list of DF_IntersectionState data frames, each containing signal phase, and time data for one or more than one intersection. Details of some of the fields in DF_IntersectionState will be provided in the following list given that this data frame contains the core data of SPaT message: • id: a unique identifier assigned to this particular intersection matching the MAP message identifier of the intersection in question. • revision: message revision number. This number is updated when the message content changes. • status: provides the status of the traffic signal controller in the intersection such as fixed time operation only (no actuated traffic control) and SPaT information availability from the controller. • timestamp: an optional millisecond timestamp in coordinated universal time (UTC) at which the current SPaT is constructed. • enabledLanes: an optional list of active lanes for driving in the current intersec- tion (have their RevocableLane bit set to one). This is used to describe different regulatory states for the driving maneuvers in the intersection. An example of such regulatory states would be a rightmost lane that has the right turn on red permission activated and deactivated at different times of the day. • states: a list of different movement states in the intersection with a description of their current phases (and possibly their future phases): – signalGroup: the identifier of the lanes group which is represented in the current movement state. – state-time-speed: this field contains the core information about SPaT data for up to 16 movement events including: eventState: a representation of the multiple states (e.g. permissive, stop and proceed, stop and remain) associated with different phases (red, green and yellow). A full list of states corresponding to different phases can be seen in Fig. 2. timing: an optional field that provides the timing details of the phase being represented in the current movement event. Examples of this timing information include phase start time, minimum and maximum end time (given that the end time may get extended in actuated traffic signals), and next time representing an estimate of when the next phase will start. Accurate prediction of phases timing in non-fixed time traffic controllers is

162 S. Rajab Fig. 2 The state diagram of different phases in signalized intersections [2] very challenging as can be inferred from these different times complicating V2I applications development for such controllers. speeds: an optional element used to provide advisory speeds for vehicles supporting a particular type of eco-approach and departure/green wave traffic flow application. regional: an additional, optional, field reserved for regions that may require certain additions to the corresponding movement event. – maneuverAssistList: an optional list providing additional information for different maneuvers to assist vehicles in navigating the corresponding lanes. Examples of this information include a length of a queue if it exists and detection of a crossing pedestrian or a bicycle in these lanes. – regional: an additional optional field reserved for regions that may require certain additions to the corresponding movement state. • maneuverAssistList: this is the same maneuverAssistList field in DF_MovementList. However, it may be provided in DF_IntersectionState in case there is common information pertaining to different lanes at an intersection level. • priority: any active priority state. This field is optional. • preemption: any active preemption state. This field is optional. • regional: an additional optional field reserved for regions that may require certain additions to the corresponding intersection.

Vehicle to Infrastructure Communications 163 Traveler Information Message (TIM) This message is intended to provide roadway travelers with road signs type of information and advisories. The information can include a wide span of use cases ranging from safety advisories to restaurant and rest areas exit signs. Message Structure TIM makes a heavy use of ITIS codes in which different traveler’s information data can be presented by different codes and text phrases [3]. This message starts with msgID (similar to other DSRC messages) and optional fields such as packet count and a URL to a source web address. Subsequently, TIM is divided into three parts, each with a different purpose as will be explained in the following sections. Part I, Frame Header This part serves as a header to the TIM containing general information such as message type and timing. The following provides an example of some of the fields in Part I: • frameType: this field provides a choice of either one of furtherInfoIDor road- SignID fields. furtherInfoID can link TIM to other messages that may provide additional information about the event in question.roadSignID provides informa- tion about the road sign in question, in case the message is describing a road sign, including the location of the sign, vehicle travel direction when facing the sign and other optional elements. • startYear: optional field representing the year that the event had begun. The current year is assumed if startYear is missing. • startTime: the minute of the year that the event had started. • durationTime: the duration of this message validity in minutes. A value of integer 32,000 means that the message is valid forever. Part II, Applicable Regions of Use This part provides details of the area at which the message applies: • commonAnchor: optional WSG-84 coordinates that other locations being repre- sented in the message can refer to. • commonLaneWidth: optional field representing the width of lanes being repre- sented in the message, unless otherwise specified at lower levels of the message. • regions: a geometrical representation of the geographical location at which the message applies.

164 S. Rajab Part III, Content Details about the event being specified in TIM is provided herein. Notably, all content in the TIM is provided as ITIS code and text as provided in SAE J2540-2 [3]. Note that TIM allows for a sequence of up to ten ITIS codes or texts to provide an intelligible information that can be presented to the road user. An example of such sequence is provided below in the speedLimit field description on how to represent speed advisory on a curve. Note that the TIM content provided in Part III is divided into five general categories to facilitate providing a generic in-vehicle advisory in the event that the vehicle cannot decode the corresponding ITIS code. Part III is a choice of one of the following categories: • advisory: an ITIS code or text that can be used to provide an advisory to the driver about a particular roadway situation. Examples of events text and code in ITIS that can be used to improve the roadway user situational awareness include; falsh_flood (3073), wildfire (3084) and checkpoint (3355). • workZone: ITIS codes pertaining to an upcoming work zone signage on the roadway. Examples of such codes include road-construction (1025) and reduced- to-one-lane (777). • genericSign: this field provides generic signs encoded in ITIS codes such as rest-area (7986) and t-intersection-oncoming (12316). Note that while the SAE J2540-2 provided encoding for these signs, their definition and usage information are provided in the Manual on Uniform Traffic Control Devices (MUTCD) [4]. • speedLimit: a speed limit representation using ITIS code. For example, a speed limit of 20 on a curve may be represented by the following ITIS text and code: – Text: advice, on a curve, speed limit, n20, mph. – Code: 7712, 8026, 268, 12,564, 8720. • exitService: ITIS codes of available roadside services such as accommodation or restaurants (e.g. text: lodging, code: 13069). An optional URL that links to additional information on the event and message CRC is included in Part III of TIM as well. Basic Information/Infrastructure Message (BIM) This message is envisioned to support sharing information from infrastructure to roadway users in order to facilitate different V2I application and provide data on upcoming traffic event. The most mature development of this message has been done by CAMP. However, details of BIM are not available in any of the SAE, or other organizations, standards as the message is still in the standardization process at the SAE DSRC Technical Committee.

Vehicle to Infrastructure Communications 165 Message Structure Very limited information is available in literature at the time of this book writing regarding the CAMP version of BIM, referred to as BIM moving forward. As such, a brief overview of CAMP BIM using the material available on the internet will be presented herein [5]. BIM follows a container based logic. This means that data is categorized depending on their use cases and then is grouped in different containers. As such, the message structure definition may contain a large number of container pertaining to different applications (or events). However, a message being sent from an RSU to enable an application, based on a particular event, will include a limited number of containers that are necessary to describe the event in question. For example, a curve speed warning application requires a common container that includes the message identifier, curve’s location, timing information and the fact that the event this message is describing a curve. Subsequently, a curve container would be included in the message to convey information about the curve in question (e.g. curve geometry, banking angle, road friction coefficient, road surface condition). See Fig. 3 for an overview BIM structure. A vehicle receiving this message can then use this data to realize that it is approaching a curve, map matches itself to the curve geometry using its GPS location, and then issues any necessary warnings/advisories to the driver if the vehicle speed is at a dangerous level given the banking angle, roadway friction, and road surface conditions. This is applicable to any other use case (e.g. work zone), in which the common container will include generic information and the event container would provide the necessary event information to enable a corresponding application (e.g. Reduced Speed Work Zone Warning). Basic Information Example: Curve Speed Common Container Work Zone Container (opt) - Location information - Speed limit Message Warning Application - Event type - Map - Time information - Workers present Common Common Container Container Common Curve Container (opt) Container - Speed limit / Advisory Application 1 Curve Container - Speed Container Application - Map Container - Banking angle Application 2 - Road friction coefficient Container - Road surface condition Fig. 3 CAMP basic information message (BIM) structure [5]

166 S. Rajab Use Cases and Application Concepts This section provides a number of V2I use cases and applications highlighting the potential benefits of the technology. Some of these concepts have been developed into prototype applications and tested under various conditions, while others are still in their research infancy stages. As such, the level of details provided in the following for each of the different concepts will vary considerably. Notably, V2I deployments, which will be discussed in later sections, contain plans for multiple V2I application with a wide range of maturity. Eight V2I applications were identified as high priority for further research by the United States Federal Highway Administration (FHWA) [6]. These applications were selected due to their potential benefits based on analysis of crash factors. This analysis resulted in the identification of high priority crash types that may be addressed by V2I communications in a cost-effective manner. Consequently, this book will discuss the concepts of these eight applications as examples of V2I communications usage. Reader may refer to [7] for other V2I applications examples. Notably, only three applications out of the eight applications will be discussed in details due to their maturity levels: (1) Red light violation warning; (2) Curve speed warning; and (3) Reduced speed work zone warning. A high-level description of the remaining five applications will be provided in the following. Red Light Violation Warning (RLVW) RLVW may be considered as the most popular use case of V2I communication. This application has been through multiple rounds of research, development, and refinements as well as deployments. One of the early research and development efforts was performed in the CICAS-V project under CAMP consortium [8]. Since then, the application was included in deployment activities/plans as well as CAMP V2I consortium efforts resulting in performance requirements document released by the Federal Highway Administration FHWA [9]. The purpose of this application is to prevent vehicle approaching a signalized intersection from violating a red light. The driver shall receive a warning in case the vehicle determines that the probability of a red light violation is high. See Fig. 4 for an illustration of the RLVW scenario. Concept of Operation The functionality of RLVW can be achieved by sending the Signal Phase and Time (SPaT) and the intersection geometry (MAP) from roadside infrastructure to the surrounding vehicles via V2I communications. As discussed in the previous section, SPaT and MAP are standardized messages in SAE J2735. SPaT information

Vehicle to Infrastructure Communications 167 Fig. 4 RLVW scenario [5] includes the phase of the traffic signal (green, yellow and red) for each of the different lanes feeding into the intersection. Notably, information for certain phases are optional and may not be transmitted in every SPaT message. MAP message, on the other hand, contains three-dimensional representation, latitude, longitude and altitude (optional), of the lanes in the corresponding intersection as well as the location for each stop bar. Note that a particular mechanism exists to link SPaT and MAP messages to enable a receiving vehicle to determine what lane corresponds to what signal phase and time. After receiving the MAP message, the vehicle would map matches itself to a particular lane in the intersection and find the distance to the stop bar using the vehicle GPS position. Afterwards, the vehicle would lookup its lane signal phase and time information from the SPaT message. If the algorithm determines that the vehicle will cross the stop bar on red if it maintains current speed and acceleration, then a warning will be provided to the driver to apply the brake and stop the vehicle in time. Curve Speed Warning (CSW) The purpose of this application is to reduce vehicles skidding or rolling over at curve as a result of navigating the curve at a high speed. Generally, curves in the United States include posted advisory speed signs for approaching traffic. Adhering to these signs is not necessarily mandatory given that such speeds are designed for heavy vehicles at unfavorable weather conditions. Consequently, drivers usually navigate curves at speeds much higher than the posted advisory speed. Depending on the speed, the vehicle type, and the weather conditions, this may lead to serious accidents. The CSW application is intended to provide a warning to the drivers if they are approaching the curve at a hazardous speed. See Fig. 5.

168 S. Rajab Fig. 5 CSW scenario [5] Concept of Operation There are different variations of how this application is envisioned to operate including: 1. The infrastructure sends the advisory speed from the infrastructure to the vehicle. Afterwards, the vehicle would warn the driver in the event that the speed is higher than a particular threshold beyond the advisory speed. 2. The infrastructure sends several data elements regarding the curve geometry, and possibly weather conditions, to the approaching vehicle. The vehicle then calculates a critical speed and warns the driver if the vehicle’s speed exceeds the critical speed. This is a more sophisticated approach of implementing CSW that takes into account current weather condition and vehicle dynamics which will be discussed in more details in the following based on CAMP development reported in [5, 10]. The CAMP implementation of CSW assumes that the infrastructure has various curve information such as curve geometry, banking angle, the radius of curvature, the coefficient of friction (or road material and condition enabling estimation of the coefficient of friction). This information is included in a message called Basic Information Message (BIM). Notably, this is a CAMP specific implemen- tation of BIM message that is in a standardization process in the Society of Automotive Engineers (SAE) DSRC technical committee at the time of writing this book. The vehicle then map matches itself to the curve approach using geometry data received from infrastructure. Afterwards, the vehicle can use its kinematics and as well as the radius of curvature, banking angle, and coefficient of friction to estimate the critical speed at which the vehicle would slip or rollover whichever is smaller. The driver can then be alerted if the speed surpasses a certain threshold below the critical speed. Such threshold can be adjusted based on the how conservative the

Vehicle to Infrastructure Communications 169 application design is. A higher threshold, leading to a lower warning speed, leads to a more conservative, safer, design. However, this may result in nuisance warning to the driver in case the warning speed drops to a much lower value than the critical calculated speed. Reduced Speed Work Zone Warning (RSZW) This application is intended to provide information to the vehicle about an upcoming work zone. This enables the driver to remain within the work zone posted speed limit and avoid closing lanes. Road workers safety in construction areas is a major concern for road owners and operators agencies. Also, lane closures in these areas may create backups generating additional problems for these agencies. Currently, a work zone is equipped with the speed limit and lane closure signs based on the Manual on Uniform Traffic Control Devices (MUTCD) [4]. Nevertheless, the driver may lack certain information to assist in making a judgment regarding the work zone condition. For example, a “reduced speed sign where workers are present” sign may exist but it may difficult for the driver to gauge workers presence due to road geometry, lighting conditions or weather conditions. Also, a warning originating from the vehicle in case of work zone regulations violation may result in a stronger impact on the driver compared to an advisory sign. See Fig. 6 for an example scenario of RSZW application. Fig. 6 RSZW scenario [5]

170 S. Rajab Concept of Operation The concept discussed herein describes the CAMP implementation of RSZW [5, 10]. This particular implementation was selected given that it is the most mature one at the date of this book writing. To enable this application, the infrastructure needs to transmit work zone related information such as geometry, reference point referring to the beginning of the work zone, location of the closed lane and worker presence status. In the CAMP implementation, the aforementioned BIM message was used to send this data to vehicles. The vehicle can then use its GPS coordinates and path history to map match itself with respect to the work zone geometry. Afterwards, the vehicle can determine whether or not it is on an approach leading to the work zone. The vehicle can warn the driver in case its speed is higher than the speed limit of the work zone or if the vehicle is driving on a closing lane. An indication of workers presence can also be conveyed to the driver via certain Human Machin Interface (HMI) to further enhance situational awareness. Stop Sign Gap Assist (SSGA) SSGA addresses potential accidents at minor/major road intersection. The minor road driver may misjudge available gap, on either side of the intersecting road, and advance into the intersection resulting in an accident. This application can be implemented via V2V communications where a vehicle on the minor road uses location data transmitted by other vehicles on the major road, and potentially stored road geometry data, to estimate the available gap and warn the driver in case of a potential accident. However, a V2V implementation would provide minimal benefit during early deployment time due to low DSRC market penetration rate. Also, maintaining an up-to-date map on the vehicle may not be limiting factor for implementing SSGA. A V2I solution may also be implemented in which roadside infrastructure use range detectors, such as Radars or LIDARS, to detect oncoming vehicles and calculate available gap. A warning is then conveyed to vehicles on minor road using V2I in case of the insufficient gap. Alternatively, the warning may be displayed on roadside signage making the solution fully dependent on infrastructure [11]. Pedestrian in Signalized Crosswalk (PCW) PCW aims at protecting pedestrians crossing the road at the signalized intersection. This application requires vehicle’s knowledge of intersection geometry, including crosswalk geometry, which can be satisfied through the MAP message. Also, the

Vehicle to Infrastructure Communications 171 infrastructure needs to be able to detect pedestrians in the crosswalk. This may be achieved using some form of sensing technology, e.g. vision or LIDAR, or by implementing wireless communications between the pedestrian handset and the infrastructure [12]. Infrastructure can then send the crossing pedestrian information to the vehicle through V2I communication. Finally, the vehicle would map match itself to the approach leading to the corresponding crosswalk and warn the driver if needed. Different implementations of PCW can be found in [13]. Spot Weather Impact Warning (SWIW) SWIW warns drivers approaching an area with dangerous weather. Examples include dense fog, heavy rain, and slippery roads. Weather conditions may be detected by traveling vehicles and transmitted to roadside infrastructure, which in turn retransmit that information to approaching vehicles. Alternatively, infrastruc- ture may be equipped with weather stations capable of detecting hazardous weather conditions. SWIW is supported in the SAE J2735 standard through TIM message. TIM message, discussed in the previous section, include a variety of options to represent different weather conditions. The vehicle receives TIM via V2I communications and advises the driver when approaching a hazardous area. Several projects have investigated connected vehicles severe weather reporting and response concepts under the road weather management program [6]. These projects are intended at enabling the infrastructure to collect weather data from vehicles and then provide a countermeasure by either sharing this data with the public through cellphone/website or change roadway speed limit. Such work shows great potential for future standardization efforts. Oversize Vehicle Warning (OVW) This application is intended to warn oversized vehicles to avoid collision with roadway obstacle and structure such as bridges and tunnels. Oversize includes height, width, and length. FHWA funded programs had provided a concept of operation and system requirements for the system [14]. However, to the best of the author’s knowledge, no practical implementation of OVW has not been researched and/or prototyped.

172 S. Rajab Railroad Crossing Violation Warning (RCVW) RCVW addresses at-grade railroad crossing by providing a warning to a driver in case of an approaching train. This requires the infrastructure to have information about approaching train, including the estimated time they need to reach the railroad crossing area. In turn, the infrastructure would transmit the information to surrounding vehicles through V2I. Similar to OVW, to date this application has not been implemented or prototyped to the best of the author’s knowledge. V2I Deployment Activities in the U.S. The number of V2X deployments across the United States has been ramping up in recent years due to the maturity level this technology had reached. This started with safety pilot model deployment in Ann Arbor, Michigan in 2012 and continued with a variety of deployments such as the connected vehicle deployment program and smart city challenge. This chapter will focus on the V2I aspect of these major deployment while leaving out other V2X technologies which are covered in other chapters. Safety Pilot Model Deployment (SPMD) Starting in 2012, SPMD is the pioneer V2X deployment helping the technology take the first steps towards a large adoption [15]. This deployment was executed in southeast Michigan (Ann Arbor) and is still running to the time of this book’s write up with varying levels of operation. The focus of this activity was mainly V2V communications. However, a number of Road Side Unites (RSUs) were deployed to collect data and test a limited number of V2I applications. A total of 29 infrastructure sites were built for this deployment. RSUs at these sites collected BSMs from surrounding vehicle for data analysis purposes. Also, different RSUs transmitted MAP, SPaT and TIM messages depending on the location of the RSU in question. Figure 7 shows the locations for RSUs in SPMD. Examples of V2I applications tested in this deployment: 1. Curve Speed Warning (CSW): as explained in earlier sections of this chapter, CSW assists the driver is safely negotiating a roadway curve. This application was enabled using TIM in SPMD in which an advisory speed, same as the curve’s advisory speed sign, was sent to the surrounding vehicles. Vehicles with enabled V2I functionality, in turn, displayed this advisory speed to their drivers. Total of three curves were outfitted with RSUs supporting CSW TIM transmission.

Vehicle to Infrastructure Communications 173 Fig. 7 Safety pilot model deployment area [16] 2. Ice Warning System: this application was developed and tested on an RSU that was deployed at one of the intersection site in SPMD [16]. The system consisted of water detection sensor, pavement temperature sensor, and a humidity sensor. These sensors worked in combination to detect icy road conditions. This information was then sent out to vehicles using TIM message. 3. SPaT and MAP transmission: SPaT and MAP messages were transmitted at intersections in Ann Arbor [17]. Total of 21 signalized intersections were outfitted with RSUs. As discussed earlier, these messages can be used to implement RLVW application.

174 S. Rajab Connected Vehicle Pilot Program In September 2016, The United States Department of Transportation (USDoT) awarded three cooperative agreements to New York City Department of Trans- portation, Tampa Hillsborough Expressway Authority and Wyoming Department of Transportation to perform large-scale connected vehicles deployments. Contrary to SPMD, these deployments have more focus on infrastructure related activities. Notably, these deployments were still in the design/build/test phase during the time of this book’s writing. This phase is expected to last until mid-2018. Afterwards, an 18 phase of Maintain/Operate Pilot is planned followed by Post-Pilot operations [18]. New York City DOT (NYCDOT) Pilot The purpose of this pilot is to improve travelers’ safety and mobility in New York City through connected vehicles [19]. New York City poses a particular challenge for vehicle localization given its deep urban environment. As such, results from NYCDOT are anticipated to research the V2X system performance in deep urban conditions. RSUs will be installed at 353 locations across the New York city making it the largest infrastructure deployment to date nationwide. A high level overview of deployment area in Fig. 8. The RSU installations will be, tentatively, divided as follows: • Manhattan Ave: 202. • Manhattan Cross: 79. • Flatbush Ave: 28. • FDR Drive: 8. • Support locations (airports, river crossings . . . etc.): 36. Fig. 8 NYCDOT pilot deployment area [19]

Vehicle to Infrastructure Communications 175 Depending on their location and functionality, these RSUs will be sending a combination of the following messages: • TIM. • Priority request/Status (SRM/SSM): SRM is a message that is transmitted from a vehicle to the RSU in a signalized intersection to request either priority or preemption of the traffic signal. SSM, on the other hand, comprises information about the signal priority and preemption requests status including acknowledg- ments and rejections. • Location correction (RTCM): a message used to encapsulate Differential GPS (DGPS) corrections to improve localization accuracy for GPS receivers. RSUs will collect BSM transmitted by passing vehicles in addition to sending out the aforementioned messages. Notably, RSUs will be used to perform Over The Air (OTA) updates to in-vehicle DSRC units (OBUs). The following list of V2I applications are planned to be implemented and tested in the NYCDOT Pilot: • RLVW. • Speed Compliance: an application providing warning to drivers exceeding speed limits for a certain amount of time. This application uses speed limit information sent via TIM in conjunction with vehicle’s location. • Curve Speed Compliance: this application is similar to the CSW concept discussed earlier. The difference is only in the naming. • Speed Compliance/Work Zone: an application similar to RSZW presented in the previous sections with the exception that this app intends to support both static and moving work zone (e.g. potholes fixing repairs crews). • Oversize Vehicle Compliance: the same as OVW use case. • Emergency Communications and Evacuation Information: this application is intended to distribute emergency, evacuation and restricted access information to roadway users using infrastructure. This information is obtained from NYC Office of Emergency Management (NYC OEM) and NYCDOT Office of Emer- gency Response (OER). Tampa-Hillsborough Expressway Authority (THEA) Pilot The THEA Pilot aims at preventing crashes, improving mobility and reducing greenhouse emissions to transform the experience of downtown Tampa road users [20]. A total of 41 RSUs are planned to be installed in downtown Tampa to support a variety of applications. See Fig. 9. The following list provides V2I applications to be implemented and tested in the THEA deployment [12]. Notably, full names of applications will be provided as applications in this deployment may have same name but a different abbreviation compared to literature. • Curve Speed Warning (CSW) • Pedestrian in Signalized Crosswalk (PED-X)

176 S. Rajab Fig. 9 THEA pilot deployment area [20] • Red Light Violation Warning (RLVW) • Intelligent Traffic Signal System (I-SIG): this application is intended to improve traffic flow at signalized intersections. This is performed by improving traffic signal control using connected vehicle data received by the infrastructure as well as non-equipped vehicles detected by a to-be-defined sensing mechanism in the infrastructure. • Transit Signal Priority (TSP): a transit vehicle can request priority at signalized intersections using this application leading to improving transit system perfor- mance. As such, a bus that is behind schedule can send a request via V2I to be granted priority at the intersection. • Mobile Accessible Pedestrian Signal (PED-SIG): this application is intended to perform a collection of tasks to support pedestrians’ movement through the intersection using V2I communications: (1) Request dynamic pedestrian signal; (2) Inform pedestrians when it is their turn to cross; (3) Request priority for disabled pedestrians in some cases. Wyoming DOT (WYDOT) Pilot WYDOT goal is to improve safety and mobility on the I-80 interstate highway in Wyoming. The major focus of this deployment is to assist fleet managers, truck drivers and passenger vehicles drivers in safely navigating the highway by providing traveler information especially during hazardous weather conditions and through work zones [21]. As such, highway users can make better decisions to seek alternative routes, park or adjust their speed using the information shared via V2V and V2I communications.

Vehicle to Infrastructure Communications 177 Fig. 10 WYDOT pilot deployment area [22] The focus of this pilot is a 402 miles stretch of I-80 that impose a serious hazard to truck fleets, and to some extent passenger vehicles, during severe weather. See Fig. 10. This makes WYDOT Pilot a unique deployment focusing on freight trucks safety in response to severe weather impact compared to urban deployments focusing on passenger vehicles and valuable user safety such as NYCDOT and THEA Pilots. A total of 75 RSUs will be installed along the aforementioned I-80 section at “hotspot” locations that were identified through a statistical approach using parameters such as average daily traffic, the percentage of trucks, weather conditions and roadway geometry [23]. The following V2I applications are planned to be implemented and tested during the WYDOT Pilot: • Infrastructure-to-Vehicle (I2V) Situational Awareness (SA): this application enables an RSU to transmit downstream information such as weather informa- tion, speed limits and road condition to vehicles traveling along the I-80. Such situational awareness helps vehicles avoid hazards, anticipate upcoming road conditions and adhere to traffic laws. • Work Zone Warning (WZW): this application is similar to RSZW use case that was discussed in previous sections. • Spot Weather Impact Warning (SWIW): the use case was presented earlier. • Distress Notification: Vehicles enabled with this application can transmit requests for assistance in case of manual activation or an event that is detected by the vehicle sensors.

178 S. Rajab Smart City of Columbus (SCC) SCC focuses on bringing new smart city technologies to the city of Columbus to serve as a pilot in the United States. This includes V2V/V2I as well as other technologies such as electric vehicles, automated vehicles and community improvement projects. To date, the SCC plan is still in infancy. The proposed V2I plan is to equip 175 intersections with RSUs in downtown Columbus to support a variety of applications. The following list provides examples of proposed applications for this deployment [24]. • Signal preemption and priority for emergency and transit vehicles. • Intersection safety applications including RLVW and pedestrian detection. • The reduced speed at school zones. Notably, limited details regarding these applications can be found in SCC published materials given that this deployment is still in the early planning phase. References 1. J. Chang, “Market penetration analysis for VSC-A safety benefit opportunities estimation,” Discuss. Doc. Prep. ITS Jt. Progr. Off., 2010. 2. Society Automotive Engineers International, “Dedicated Short Range Communications (DSRC) Message Set Dictionary: J2735.” Society Automotive Engineers International, 2016. 3. Society Automotive Engineers International, “ITIS Phrase Lists (International Traveler Infor- mation Systems): J2540/2.” Society Automotive Engineers International, 2009. 4. FHWA, “Manual on Uniform Traffic Control Devices for Streets and Highways,” 2009. 5. J. Parikh and C. Andersen, “Development of Vehicle-to-Infrastructure Safety Appli- cations in the United States,” 23rd World Congress on Intellignt Transport Sys- tems, 2016. [Online]. Available: https://www.its.dot.gov/presentations/world_congress2016/ WC_TP79_ParikhAndersen.pdf. 6. J. Chang et al., “Estimated Benefits of Connected Vehicle Applications: Dynamic Mobility Applications, AERIS, V2I Safety, and Road Weather Management Applications,” 2015. 7. K. K. Hartman, “Connected Vehicle Applications,” United States Department of Transporta- tion. [Online]. Available: https://www.its.dot.gov/pilots/cv_pilot_apps.htm. 8. M. Maile and L. Delgrossi, “Cooperative intersection collision avoidance system for violations (CICAS-V) for avoidance of violation-based intersection crashes,” Enhanc. Saf. Veh., pp. 118– 2009, 2009. 9. R. L. V. Warning, “Vehicle-to-Infrastructure (V2I) Safety Applications.” 10. M. Shulman and S. Geisler, “Development of Vehicle-to-Infrastructure Applications Program Second Annual Report,” 2016. 11. L. Alexander et al., “The Minnesota mobile intersection surveillance system,” in Intelligent Transportation Systems Conference, 2006. ITSC’06. IEEE, 2006, pp. 139–144. 12. G. Cordahi et al., “Connected Vehicle Pilot Deployment Program Phase 1, Application Deployment Plan–Tampa (THEA),” 2016. 13. R. E. Zimmer, M. Burt, G. J. Zink, D. A. Valentine, and W. J. Knox Jr, “Transit Safety Retrofit Package Development,” 2014. 14. D. R. Stephens, T. J. Timcho, R. A. Klein, and J. L. Schroeder, “Vehicle-to-Infrastructure (V2I) Safety Applications Concept of Operations Document,” 2013.

Vehicle to Infrastructure Communications 179 15. K. Gay and V. Kniss, “Safety Pilot Model Deployment: Lessons Learned and Recommenda- tions for Future Connected Vehicle Activities,” 2015. 16. D. Bezzina and J. Sayer, “Safety pilot model deployment: Test conductor team report,” Rep. No. DOT HS, vol. 812, p. 171, 2014. 17. C. V. INFRASTRUCTURE, “Lessons Learned from Safety Pilot and Other Connected Vehicle Test Programs,” 2014. 18. K. K. Hartman, “Program Overview.” [Online]. Available: https://www.its.dot.gov/pilots/ pilots_overview.htm. 19. M. Talas, I. Morel-Dziengeleski, F. Esposito, E. Flanigan, D. Benevelli, and R. Rausch, “Connected Vehicle Pilot Deployment Program Phase 1, Partnership Status Summary–New York City,” 2016. 20. Tampa Hillsborough Expressway Authority, “TAMPA CONNECTED VEHICLE PILOT — FACT SHEET,” 2017. [Online]. Available: https://www.tampacvpilot.com/wp-content/ uploads/2017/03/2672-Tampa-Connected-Vehicle-Pilot-Fact-Sheet-20170815-rgb.pdf. 21. D. Gopalakrishna et al., “Connected Vehicle Pilot Deployment Program Phase 1, Concept of Operations (ConOps), ICF/Wyoming,” 2015. 22. “Connected Vehicle Pilot Deployment Program: WYOMING,” 2017. [Online]. Available: https://wydotcvp.wyoroad.info/assets/promotion/ WyomingCVPilot_Factsheet_v2_020817.pdf. 23. D. Gopalakrishna et al., “Connected Vehicle Pilot Deployment Program Phase 1 Comprehen- sive Pilot Deployment Plan, ICF/Wyoming,” 2016. 24. “BEYOND TRAFFIC: The Smart City Challenge Phase 2,” 2016.

Cooperative Vehicle to Pedestrian Safety System Radovan Miucic and Sue Bai Introduction This chapter provides an overview of the Vehicle-to-Pedestrian cooperative safety application, enabling technologies and field test results. We describe implemented system architecture and basic concepts of operation. The chapter is organized as follows. We describe the motivation for DSRC based V2P safety application research. Then we compare the DSRC and Vision V2P collision detection systems. Afterward, we describe the V2P system and vehicle warning strategy. This is followed by a description of our test setup. Finally we present the results of communication and application performance. Motivation Each year, in the world there are approximately 1.25 million fatalities in road traffic collisions. Also, 20–50 million people suffer non-fatal injuries [1]. Almost half are vulnerable road users: pedestrians, cyclists, and motorcycle riders. The pedestrian fatality proportion is higher in the poorer economies of the world. In Americas 22% of the reported road deaths are among pedestrians. In Africa 39% of the reported road death are among pedestrians. There is a need to develop affordable R. Miucic ( ) 181 Department of Electrical and Computer Engineering, Wayne State University, Detroit, MI, USA e-mail: [email protected] S. Bai Honda R&D Americas, Inc., Southfield, MI, USA e-mail: [email protected] © Springer Nature Switzerland AG 2019 R. Miucic (ed.), Connected Vehicles, Wireless Networks, https://doi.org/10.1007/978-3-319-94785-3_7

182 R. Miucic and S. Bai devices and technology to address the pedestrian fatality. U.S., Department of Transportation issued a Notice of Proposed Rule Making (NPRM) [2]. NPRM outlines the potential mandate of Vehicle-to-Vehicle (V2V) Dedicated Short Range Communication (DSRC) safety communication system. DSRC is high-availability and low-latency broadcast communication technology. The V2V applications across the U.S. vehicle fleet can address more than 70% of the vehicle-to-vehicle collisions. Furthermore, the V2V system can expand to address pedestrian safety. This will be by vehicle and pedestrian devices exchanging safety messages. In 2013, Honda R&D demonstrated the world’s first Vehicle-to-Pedestrian (V2P) DSRC safety system. In which we used an off-the-shelf smart phone with a modified Wi-Fi transceiver interacting with a DSRC equipped vehicle. In March 2016 Society of Automotive Engineers (SAE) published the world’s first V2P Pedestrian Safety Message (PSM). PSM is part of safety communication standard J2735. In March 2017 SAE published the world’s first Pedestrian Safety Communication System Recommended Practice standard J2945/9. In this chapter, we describe V2P system. The system increases vehicle’s awareness of nearby pedestrians. We show how the system can improve pedestrian safety. We also describe the PSM contents and the recommended use. Finally, we address the challenges and opportunities for production deployment of the V2P system. Worldwide, there are more than 270,000 pedestrian traffic accident related fatalities every year [3]. This issue transcends economic and regional borders. For example, there are more than 20,000 annual pedestrian road fatalities within the 34 Organization for Economic Co-operation and Development (OECD) member countries [4]. In recent years the number of pedestrian fatalities in the US trends upwards. Figure 1 shows the breakout of the number of fatalities in traffic related Fig. 1 Traffic fatalities trend in the U.S.

Cooperative Vehicle to Pedestrian Safety System 183 Fig. 2 Pedestrian fatalities percent of the total accidents. The data for Figs. 1 and 2 are from FARS database [5] and 2015 Motor Vehicle Crashes USDOT report [6]. Figure 2 shows that in 2015, pedestrian deaths accounted for over 15% of all traffic fatalities in motor vehicle traffic crashes in the US. Pedestrian fatalities percentage of the total is on a constant rise since 2004. Most of the fatalities (74%) occurred in an urban setting and during the nighttime (from 6 p.m. to 5:59 a.m.) [3]. Dedicated Short Range Communications (DSRC) is two-way wireless communication for automotive use, with interoperability and standardization enabled by the corresponding set of protocols and standards [7]. The automotive industry, the wireless industry, the U.S. Department of Transportation (USDOT) and academia have researched V2V cooperative safety applications [8] since 1999. However, research into advanced pedestrian cooperative safety applications is relatively recent. Various cooperative V2P safety application systems were proposed using infrastructure, Wi-Fi, or cellular communication such as [9– 11]. All these proposals have one thing in common: using the infrastructure to relay messages that adds an intermediary to the transmission. That adds delay and it is difficult to scale. Therefore, using direct dedicated and licensed communication bands within DSRC viable promising option for safety-of-life application of V2P systems. The implementation of a prototype Vehicle-to-Pedestrian (V2P) cooperative safety system has been first presented in [12] and demonstrated to the USDOT and public in 2013 [13] and in 2014 at the Intelligent Transportation Systems (ITS) World Congress. In the remainder of this chapter, we describe the use of smartphones as the DSRC transceivers and warning devices for pedestrians alongside widespread V2V deployment.

184 R. Miucic and S. Bai Smartphones are widespread, and the proposition of DSRC in smartphones is our motivation. The majority of smartphones are equipped with Wi-Fi, which has the capability to transmit and receive of DSRC signals [14, 15], as DSRC is based on IEEE 802.11. Therefore, needed hardware is already present in the smartphones. For our prototype work, it simply needed a firmware modification to be able to send and receive DSRC messages. Traditional Advanced Driver Assistance System (ADAS) sensors such as radar and cameras suffer from inefficiency in certain road and weather conditions. Vehicle-mounted cameras for pedestrian detection are typically most useful during the daytime, for certain vehicle speeds, and certain angle of view. Furthermore, cameras may be affected by rain or snow or by the position of the sun. As an example, a commercial-off-the shelf system such as [16] cannot detect pedestrian at night or when the vehicle is traveling faster than 15 m/s. Camera, radar, and LiDAR systems require line of sight and are not able to detect pedestrians that are fully obstructed by a building or a vehicle. Because it is a Radio Frequency (RF) communication system, DSRC can overcome most of these challenges. Because of multipath—or reflection and diffraction, the surrounding vehicles, roads and building infrastructure—messages from the transmitters can reach the receivers in non line-of-site situations. Moreover, DSRC works at night, daytime and in all weather conditions. Comparison of DSRC and Vision V2P Frequency and severity of crash types for pedestrians have been studied by National Highway Traffic Safety Administration (NHTSA) in 1996 [17]. The study applied the basic pedestrian typologies to a sample of pedestrian motor vehicle crashes from six states with the purpose of refining and updating the crash type distributions. Table 1 reprints statistics of the most frequent and severe accidents, showing types of crashes, frequency (number of crashes), severity (percent of all crashes), the number of high-severity crashes, and drivers’ visibility of pedestrians. For a more detailed description of the scenarios see [17]. As described earlier, the primary advantage of the DSRC-based V2P warning system is its ability to work at night, in bad weather conditions, and in non line-of- sight scenarios. These adverse situations are implied by some of the most dangerous typologies. Although there is not enough detail to map these conditions where vision-based systems do not work well, our common driving experiences suggest that the ‘Midblock Dash’ scenario is a situation where DSRC may be superior to vision, because DSRC messages from a pedestrian can be received in this more sudden non line-of-sight hazardous situation. In this scenario, a vision-based system will not be able to detect a pedestrian until the pedestrian suddenly crosses the line of sight of the vehicle, which in many cases, may be too late.

Table 1 Most frequent types of crashes involving vehicles and pedestrians and applicability of DSRC Cooperative Vehicle to Pedestrian Safety System Num. of % of % of serious Num. of serious Addressed with Addressed with crashes crashes or fatal Crash type or fatal View obstructed V2P DSRC COTS vision Notes Midblock other 548 10.8 49 269 Unknown Likely Likely a d Vehicle 497 9.8 18 89 Unknown Yes Likely b turn/merge a Midblock dash 442 8.7 37 164 No Yes Somewhat a Not in roadway 404 7.9 28 113 Unknown Likely Likely c Walking along 375 7.4 37 139 Unknown Yes Yes e road f Intersection 364 7.2 42 153 Unknown Likely Likely c other c Intersection 363 7.2 34 123 Yes Yes No dash g Backing vehicle 351 6.9 23 81 Unknown Yes Likely Driver violation 259 5.1 28 73 Unknown Yes Yes at intersection Midblock dart 232 4.6 32 74 Yes Yes No out Disabled 124 2.5 42 52 Yes Yes No vehicle related Driverless 104 2.1 38 40 NA Somewhat No vehicle aUnclear scenario description 185 bMost of the crashes occurred at vehicle speeds higher than 50 kmph. The vision systems may not be able to adequately warn the driver cMotorist’s view of the pedestrian was blocked until an instant before impact dThe angle of pedestrian direction may influence the performance of the vision based system eThe vision based system will address this accident if the back camera system is present, pedestrian is in the field of view and not obstructed fMost often the speeds are low for both systems to work well gSmart phone may warn the pedestrian of an approaching vehicle if the vehicle is actively broadcasting BSMs

186 R. Miucic and S. Bai We understand that the DSRC solution requires both the vehicle and pedestrian to be equipped with DSRC transceivers, whereas a vision system does not depend on the transmitting devices and can work autonomously. Therefore, a sensor fusion system is quite desirable, at least until the DSRC market penetration reaches high enough levels, and promises improved performance of the V2P collision avoidance system. V2P System Architecture In this section, we discuss the system that we developed that includes an application for the driver in the vehicle and application for the pedestrian within the smartphone. We used the same setup as described in [12]. Vehicle System Design Vehicle installation consists of processing, communicating, and positioning hard- ware. Together they are also known as On Board Equipment (OBE). Figure 3 shows an overview of the functional blocks that comprise vehicle installation. Inputs to the OBE include signals from the host vehicle’s Controller Area Network (CAN), GPS, and DSRC receiver. In our system, the OBE outputs audio and visual warnings to the driver. Additionally, OBE broadcast vehicle awareness messages used by pedestrians equipped with DSRC smartphones. To compute a vehicle’s path, the V2P system uses the vehicle’s yaw-rate, speed, and location. The onboard system also calculates the path of the pedestrian via the awareness message received from the smartphone. First, the V2P system computes vehicle and pedestrian path predictions. Second, the system classifies the collision threat level. Third, the system determines if the vehicle is on the collision path with a pedestrian. There can be many targets. The threat arbitration process selects the target with the highest likelihood of collision. Finally, the system warns the driver if needed. The Human Machine Interface (HMI) Notifier modifies the warning state for this highest collision threat. The system displays the visual warnings on a transparent Heads-Up Display (HUD). The system produces audio warnings through the vehicle’s speakers. To alert pedestrians to the vehicle’s location, speed, and state, the OBE periodically sends a BSM over the DSRC channel. Smartphone System Design The V2P prototype we developed on Android smartphones, equipped with Qual- comm Wi-Fi solutions. Our design goal was to provide an always-on, highly

Cooperative Vehicle to Pedestrian Safety System 187 Vehicle CAN GPS Receiver DSRC Radio Gateway Device Vehicle Information Time and Radio Process Process Position Process Software Services API Wireless Message Handler Sensor Data Handler Host Vehicle OBE Audio Path History Speakers Human Machine Host Vehicle Interface Notifier Heads Up Path Prediction Display Threat Pedestrian Security Arbitration Path Prediction Module False Alarm Target V2P Applications Supression Classification Collision Detection Fig. 3 Vehicle logical setup accurate and low latency pedestrian collision warning system. The system should not introduce significant hardware or processing overhead to smartphones. Towards this end, we implemented different modules at different layers of the smartphone software stacks, as shown in Fig. 4. In particular, the lower layer is the firmware and driver layer. The lower layer deals with I/O operation on the data from communication links and sensors. Here, our main effort was to enable DSRC radio on the Wi-Fi chip. The middle layer is the service layer. The service layer implements three necessary components required for a V2P system. These are Context Awareness, DSRC Manager, and Safety Service. We use context awareness module to gate the DSRC operation for power saving and channel congestion control. DSRC manager includes the DSRC upper layer stack and queues the incoming or outgoing BSM messages. We implemented Human-Machine-Interface (HMI) to the pedestrian in the upper layer.

188 R. Miucic and S. Bai V2P Application Motion State BSM Queue Classifier Collision DSRC Stack Data Distraction Detection DSRC Manager Flow Monitor Safety Service Control Context Awareness Flow Android API Driver GPS Inertial Sensors Others WiFi Fig. 4 V2P system design in smartphone Firmware and Driver Modifications The key challenge was to enable DSRC operation without adding new hardware to the phones. In particular, we modified the Qualcomm Wi-Fi chipset firmware and driver software. Modifications allow (1) DSRC band operation (5.85–5.925 GHz), and (2) transmit and receive DSRC packets, defined as BSM (Basic Safety Messages), without the need to establish association with an access point. For (1), we added DSRC channels to the existing Wi-Fi channels and modified the Wi-Fi driver to tune the RF front end to operate in the DSRC band. Since DSRC band is adjacent to the legacy 5 GHz Wi-Fi band, no hardware modification was required. For (2), we again modified the Wi-Fi driver such that all packets received in the DSRC channels were passed to the upper layer for processing, without the need to check whether the device is associated with any access point. Services In services layer, we implemented several key enabling modules for efficient DSRC operation. We implemented a context awareness module. In particular, we incorporated a motion classifier that detects if the pedestrian is stationary, walking or running. The system turns on/off DSRC operation based on the motion state of the pedestrian. The motion classifier uses three-dimensional accelerometer data from the smartphone. In the prototype implementation, reception of BSM and GPS signal is completely disabled if a pedestrian is stationary. Hence, the context awareness

Cooperative Vehicle to Pedestrian Safety System 189 module is a key to reducing battery drain speed. The context awareness makes always-on V2P capability possible in smartphones. The motion classifier uses sensors to gate the transmission of Pedestrian Safety Messages (PSMs) and enable operation of other hardware blocks. To improve performance, we can fuse other sensors to further optimize power usage. Examples include, using the GPS and audio to detect if a person is indoor or outdoor; or using a precise map and camera to detect if a person is walking alongside or on a street. This context awareness enables the transmission of PSMs only when necessary. This avoids a large number of V2P packets introduced by pedestrians using our smartphone safety applications and thus reduces channel congestion in DSRC channels. Additionally, the distraction monitor runs as part of our context awareness service. The module detects pedestrian’s distracting activities. Distracting activities may include texting, listening to music or talking to the phone. Such information is sent over to the vehicle side as part of the PSM message. Depending on the type of pedestrian distraction, the vehicle’s V2P system can adjust the safety algorithm. It can also trigger different warning messages to the driver. The safety service runs the collision detection algorithm based on the pedestrian location. The pedestrian location is in PSM. Designing reliable collision detection algorithms for V2P is much more challenging than designing V2V algorithms. This is because a vehicle moves in a more predictable, kinematic manner than pedestrians. The uncertainties of pedestrian motion mainly arise from two sources: GPS positioning error and changes to movement trajectories. V2P Messaging In our prototype, the vehicle sends the Basic Safety Message (BSM) defined in SAE J2735 [18] at 100 ms intervals. The BSM is populated with vehicle information such as speed, GPS position, and yaw rate. Automotive consumer-grade GPS receiver has an antenna on the vehicle roof. GPS receiver is usually coupled with accelerometers and odometer sensors. This provides more accurate GPS readings. In open sky conditions, current, automotive grade GPS receivers provide sub-meter accuracy. They are able to output the GPS solution every 100 ms. A pedestrian carrying a smartphone also sends frequent Pedestrian Safety Messages (PSM). PSM includes pedestrian position, speed, direction, time, device state, and pedestrian type. Device states include talking on the phone, texting, and listening to the music. Pedestrian types include pedestrian walking, bicycle rider, wheelchair rider. PSM is a newly invented message for this V2P prototype, like V2V BSM. A draft standard (Performance Requirements for Safety Communications to Vulnerable Road Users J2945.9) that captures PSM is currently being created in the SAE DSRC technical committee. Our V2P work influenced the creation of the draft standard.

190 R. Miucic and S. Bai Typically, a smartphone acquires a GPS position reading every second and provides a location that is less accurate than the position reported by the vehicle. Accuracy varies but is typically less than 2–3 m under benign conditions, as was previously reported in [12]. Built-in smartphone accelerometers determine if the pedestrian is walking, standing or riding a bicycle. The phone knows if the user is texting, browsing the Internet, listening to the music or talking over the phone. In other words, context sensing is able to determine if the pedestrian is distracted or not. All this information about the pedestrian is embedded in the prototype PSM and sent over the air, see Table 2. Table 2 PSM data elements Variable More information Description msgID A new message ID msgCnt Pedestrian safety message Revolving message counter Id 0–127 Temporary ID of the sending device DSecond 4 byte value Time in seconds of the current Integer (0.65535)—units of minute GPS was acquired Latitude milliseconds The geographic latitude of an object Longitude In micro degrees The geographic longitude of an In micro degrees object The geographic position above or Elevation In decimeters below the reference ellipsoid Heading In 0.0125◦ The current heading of the sending device PositionalAccuracy – Semi-major accuracy Quality used to model the accuracy – Semi -minor accuracy of the positional determination with Speed – Orientation of semi-major respect to each given axis AccelLat axis AccelLong Speed of the pedestrian AccelVert In m/s Lateral acceleration data PedSize In m/s2 Longitudinal acceleration data PedType In m/s2 Vertical acceleration data In m/s2 Dimensions of the space (rectangle) PedDeviceState pedestrian is occupying PedWidth (in cm) Pedestrian type PathHistory PedLength (in cm) PathPrediction Device state Enum: WalkPedestrain Pedestrian history points BicycleRider WheelChairRider Curvature describing path prediction Enum: Talking Texting MusicListening HistoryPoints (similar to vehicle) Curvature (similar to vehicle)

Cooperative Vehicle to Pedestrian Safety System 191 Fig. 5 Simplified V2P algorithm in vehicle V2P Algorithm in the Vehicle Figure 5 shows simplified V2P algorithm in the vehicle. The vehicle and the smartphone independently calculate collision probability. The system warns the driver and pedestrian if there is a high chance of collision. The vehicle determines path prediction based on the current location and path history. Likewise, the phone projects the future path of the pedestrian. If those two paths intersect and the time to collide is below a certain threshold there is a chance for a collision. The system warns the driver and the crossing path pedestrian. Yet, most of the time the pedestrian path is random and the prediction is random as well. For example, the pedestrian can walk and stop just in time before stepping on to the road. This walking behavior may trigger unnecessary warnings to the driver and the pedestrian. Vehicle Warning Strategy Figure 6 shows an overview of the vehicle warning strategy. The vehicle calculates the relative position and direction of a pedestrian. In our system, pedestrians may be located either ahead or behind the vehicle. For vehicles traveling forward, in this system, only pedestrians classified as ahead are of interest. Depending on the distance and vehicle speed, pedestrians can be further classified to be within

192 R. Miucic and S. Bai Fig. 6 Vehicle warning strategy INFORM, ALERT or WARN zones. The system displays the zone and classification on Heads Up Display (HUD), as shown in the lower left corner of Fig. 6. For example, if a pedestrian is in the INFORM zone the system shows a static INFORM image to the driver. Furthermore, the smartphone’s context sensing deter- mines whether the pedestrian is distracted or not. The distracted state information becomes part of the continuously broadcasted PSM. The vehicle reads the pedestrian distraction state information. When the pedestrian is in the ALERT ZONE, the V2P system presents an appropriate ALERT image to the driver. If the driver fails to react to the alert, the vehicle issues a more intense audio and visual warning. Finally, when the pedestrian is in the WARN zone, the system presents a flashing “BRAKE” image to the driver. In a similar manner, when a vehicle is backing out of a parking lot with a pedestrian and smartphone in its path, the vehicle informs the driver using audible beeps that vary in frequency based on the distance from the pedestrian. Once the driver acts on any of the warnings and applies the brakes, V2P warnings disappear. All the parameters in the V2P system are customizable. For the purposes of evaluating the V2P application, configuration parameters in Table 3 were used. Parameters values are used for the evaluation purposes only. The values should not be considered as recommended values for the application deployment. State information on distracted pedestrians can be used in a more mature system. Pedestrian distraction state information can be very useful with quiet vehicles. For example, an approaching electrical vehicle is less noticeable to pedestrians. A

Cooperative Vehicle to Pedestrian Safety System 193 Table 3 Nominal Nominal Value Unit application parameter values lane_width 3.5 [m] inform_time 10.5 [s] alert_time 7.5 [s] warn_time 3.3 [s] Start Position 2 120m 3 Distracted Pedestrian P2 P3 P1 2 Parallel Pedestrians P4 NLOS Start Pedestrian Position 1 1 160m Fig. 7 Test setup pedestrian is listening to music through headphones. Flashing of headlights may be a better option to warn the pedestrian than sounding a horn. If a pedestrian is texting, using the horn may be more appropriate. Test Setup Figure 7 shows V2P test setup. We used one vehicle with a DSRC OBE and four pedestrians carrying DSRC smart-phones. In one vehicle loop there are three scenarios: (1) pedestrian P1 is approaching perpendicular to the vehicle path from non line of sight (NLOS), obstructed by a trailer and several buildings; (2) two pedestrians P2 and P3 are walking next to the road parallel to the vehicle path; and (3) distracted pedestrian P4 is approaching perpendicular to the vehicle path in the line of sight (LOS). DSRC is most valuable in NLOS scenarios. Autonomous sensors may not detect the out of view pedestrian or cyclist, such as P4 in Scenario 1. Accurate relative positioning helps the system decrease false alerts. Also, the system suppresses the alerts for the pedestrians walking in parallel. Vehicle should not engage alert for the two pedestrians P2 and P3 in Scenario 2. Besides the collision detection DSRC provides distracted state of the pedestrian. A distracted pedestrian may react in a different manner to the approaching vehicle compared to an attentive one. Along with the position information smartphone (P4) sends out distracted state of the pedestrian to the vehicle, as in Scenario 3. We drove the vehicle up to 11.2 m/s (25 mph) and the pedestrian walking speed was up to 1.5 m/s. The vehicle stopped for pedestrians P1 and P4 but not for P2

RX RSS[dBm]194 R. Miucic and S. Bai RX RSS[dBm]and P3. The vehicle and pedestrians carrying smart-phones were sending messages every 100 ms. We collected data logs at the vehicle end from 16 runs. Results Analysis is split into two parts: communication performance analysis and applica- tion performance analysis. Communication Performance Figure 8 Received Signal Strength (RSS) at the receiver from successfully decoded messages sent by pedestrians and received by the vehicle. The top part of the figure indicates RSS values at various V2P distances from non line of sight (NLOS) pedestrian P1. The bottom part of the figure indicates RSS values from the line- of-sight (LOS) pedestrian P4. Figure 9 shows side by side comparison of binned average RSS values. The size of the bins is 10 m. For example, the red inverted triangle at x = 15 m, y = −69 dBm indicates RSS value of 69 dBm. This value is an average of the signals coming from the LOS pedestrian positioned between 10 m and 20 m from the vehicle. Figure 10 -60 NLOS RSS -70 -80 -90 -100 0 10 20 30 40 50 60 70 80 90 100 110 120 130 -60 LOS RSS -70 -80 -90 -100 0 10 20 30 40 50 60 70 80 90 100 110 120 130 distance [m] Fig. 8 Received RSS versus V2P distance for NLOS and LOS scenarios

Cooperative Vehicle to Pedestrian Safety System 195 -65 NLOS Ave. RSSRX RSS[dBm] LOS Ave. RSS -70 -75 -80 -85 -90 -95 -100 0 10 20 30 40 50 60 70 80 90 100 110 120 130 distance [m] - bin size 10m Fig. 9 Binned average RSS versus V2P distance PER [%] 70 NLOS Ave. PER LOS Ave. PER 60 50 40 30 20 10 0 0 10 20 30 40 50 60 70 80 90 100 110 120 130 distance [m] - bin size 10m Fig. 10 Binned average PER versus V2P distance

IPG [100 ms]196 R. Miucic and S. Bai 400 NLOS Ave. IPG 350 LOS Ave. IPG 300 250 200 150 100 50 0 0 10 20 30 40 50 60 70 80 90 100 110 120 130 distance [m] - bin size 10m Fig. 11 Binned average IPG versus V2P distance shows binned average Packet Error Rate (PER) at the receiver, of the packets sent by pedestrians P1 and P4 and received by the vehicle. The size of the bins and average values calculation is the same as RSS in Fig. 9. Most of the time, LOS RSS values are above −95 dBm and the vehicle is able to decode the majority of the packets. PER is close to 0 for all distances as Fig. 10 shows. Beyond the distance of 75 m NLOS RSS values are below −95 dBm. Thus, the vehicle radio is able to decode all packets as indicated in Fig. 10. Figure 11 shows averaged binned Inter Packet Gap (IPG) at the receiver, of the messages sent by the pedestrians P1 and P4 and received by the vehicle. The size of the bins and average values calculation is the same as RSS and PER. IPG is a measure of the difference in timestamps of two consecutively received messages at the receiver. LOS IPG values are close to 100 ms (sending interval) for all distances. Beyond the distance of 75 m NLOS IPG values grow significantly. NLOS IPG and PER values for the distances beyond 90 m are not very reliable. This is due to the low number of samples that contributed to the average calculation. Application Performance Table 4 shows the Inform, Alert, and Warn times for the NLOS and LOS scenarios for the 16 runs. The V2P system missed one NLOS Inform display message in run

Cooperative Vehicle to Pedestrian Safety System 197 Table 4 Inform, Alert, and Run# NLOS Alert Warn LOS Alert Warn Warn times for the NLOS and 1 Inform 7.50 3.37 Inform 6.27 3.26 LOS scenarios for the 16 runs 2 10.34 7.45 2.40 10.61 7.54 3.14 3 9.55 7.42 3.19 10.55 NaN NaN 4 9.29 7.30 3.19 NaN 7.41 3.35 5 8.24 7.48 3.32 9.87 5.86 3.24 6 8.47 7.42 3.33 10.24 7.52 3.30 7 9.18 7.25 2.64 10.45 7.53 3.26 8 8.00 7.45 3.21 10.48 7.45 3.28 9 7.69 7.21 3.25 10.38 7.47 3.28 10 NaN 7.53 2.30 10.50 7.56 3.30 11 9.20 7.36 2.63 10.36 7.41 3.27 12 9.47 7.06 3.26 10.48 7.53 3.28 13 6.04 7.42 3.34 10.29 7.40 3.31 14 9.61 7.53 3.41 10.47 7.41 3.21 15 9.70 7.24 3.33 10.45 7.45 NaN 16 8.01 7.28 3.39 10.44 7.34 2.27 9.34 10.50 Table 5 Mean, standard deviation, nominal and offset from the configured nominal values of the display timings Mean NLOS Alert Warn LOS Alert Warn Std Inform 7.37 3.10 Inform 7.29 3.19 Nominal 8.74 0.13 0.37 10.41 0.49 0.25 Nominal-mean 1.08 7.50 3.30 0.17 7.50 3.30 10.50 0.13 0.20 10.50 0.21 0.11 1.76 0.09 9 and one LOS Warn display message in run 15. The system failed to issue display message for the LOS scenarios in Run 3. Table 5 shows mean, standard deviation, nominal and offset from the configured nominal values of the display timings. Table 3 shows configured nominal values for INFORM, ALERT and WARN times. Figure 12 shows these values with black circles. The figure shows V2P application performance at vehicle end. The figure shows how well application timing matches configured nominal values. The blue diamond shows an average warning times for different warning stages. The blue bar shows standard deviation. WARN and ALERT stages were very close to the nominal values (3.3 and 7.5 s respectively) for both LOS and NLOS scenarios. Also, the INFORM stage for the LOS was very close to the nominal value of 10.5 s. Yet, the INFORM stage for the NLOS was delayed because of the high PER for the INFORM range (84–117 m). NLOS environment (3/4 open intersection), where a single obstacle blocks the view of the pedestrian, is very challenging for DSRC.Typical suburban/urban