MMITSS Detail Design (California) Page i of 96 Multi-Modal Intelligent Traffic Signal System System Design – California Portion University of Arizona (Lead) University of California PATH Program Savari Networks, Inc. Econolite Version 1.3.2 (Final Version) 1/31/2016
103
Embed
Multi-Modal Intelligent Traffic Signal System · 2016-08-05 · portion of the Multi-Modal Intelligent Traffic Signal Systems (MMITSS). The approach taken to the design has been to
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
MMITSS Detail Design (California)
Page i of 96
Multi-Modal Intelligent Traffic Signal
System System Design – California Portion
University of Arizona (Lead)
University of California PATH Program
Savari Networks, Inc.
Econolite
Version 1.3.2 (Final Version)
1/31/2016
MMITSS Detail Design (California)
RECORD OF CHANGES
A – Added, M- Modified, D - Deleted
Version Number
Date
Identification of Figure, Table, or Paragraph
Title or Brief Description
Applied Test
Network
Change Request Number
1.0
2/25/2014
N/A Initial Draft for Team
Review/Development
Arizona and
California
1.1 5/26/2014 All Sections Integrated individual component design descriptions from team
Arizona and
California
1.2.1 6/16/2015 All Sections
Updated design to match software that was developed by the University of Arizona portion of the MMITSS Team. Software submitted to the OSADP.
Arizona
1.2.2 10/21/2015 All Sections
Updated design to match software that was developed by the University of California, Berkeley PATH portion of the MMITSS team
California
1.3.2 1/31/2016 All Sections
Updated design to incorporate review comments from the PFS committee and FHWA
California
MMITSS Detail Design (California)
i
Table of Contents
1 Purpose of Document ................................................................................................ 1
2 Scope of Project ........................................................................................................ 1
dispatch system, or taxi dispatch, which is shown as a UML collaboration (oval in Figure
1) meaning that a collection of entities work together to perform the traffic management
functions, but there may be many different systems involved in this collaboration.
MMITSS Detail Design (California)
Page 6 of 96
The infrastructure based traffic signal control equipment consists of the traffic signal
controller, field sensors/detectors, and an MMITSS Roadside Processor (MRP). There
are two traffic signal controllers models that are utilized in the field installation: Econolite
ASC/3 or Cobalt (NTCIP) (AZ) controllers and Type 2070 (Caltrans – AB3418) (CA).
Each of these controllers offers different signal timing logic (software) and require
different communications interfaces. The Econolite ASC/3 and the Cobalt controllers are
based on NEMA standards and support NTCIP over Ethernet communications. The
Caltrans Type 2070 controllers are based on a Caltrans standard and support AB3418
over serial RS-232 communications. Both networks utilize loop detectors for vehicle
detection and push-buttons for pedestrian crossing requests. In the California test
network, the MRP is a Linux-based industrial PC (see Section 4.1.1 for details). In the
Arizona test network, the MRP is integrated with the RSE Radio.
The RSE Radio is the hardware device that is responsible for managing all of the 5.9
GHz DSRC communications between the vehicles and the infrastructure. Both the
Arizona and California networks utilize Savari RSE units.
The OBE is a hardware device deployed on the vehicle. MMITSS applications have
been developed and tested using Savari MobiWave units and Arada LocoMate Mini 2
units (called aftermarket safety devices - ASD). These units are general purpose and
provide a powerful and flexible platform for development and testing. The product data
sheets for the OBEs are in Appendix B: Savari and Arada OBE Product Specification
Sheets.
The larger traffic management system is shown as a UML collaboration in Figure 1. The
RSE is a general communications processing node that coordinates messages from the
various modes of travelers. The MMITSS Roadside Processor (MRP) hosts the core
intersection level infrastructure applications for MMITSS. The MRP contains (deploys)
the MAP artifact, which is the digital description of the intersection geometry and
associated traffic control definitions.
Both motorized and non-motorized travelers can be detected by the Field
Sensor/Detector node at the intersections using a variety of detection technologies,
including inductive loop detectors, video detection, microwave, radar, pedestrian push
button, etc. The detection system at an intersection provides information to the traffic
signal controller that triggers the control algorithms. For example, a vehicle that triggers
a detector will call a signal control phase for service or extension. A pedestrian may
activate a pedestrian push button to request the traffic signal pedestrian interval
associated with a crosswalk movement. The direct communications path from the field
sensor to the MRP allows the communication of information from the sensor. This
information might include vehicle count from presence detectors or possibly vehicle
MMITSS Detail Design (California)
Page 7 of 96
trajectories from radar based sensors in the future. [Implementation Note: No direct
sensor data was used in the MMITSS implementation.]
Each of the systems that can be active participants in the MMITSS (e.g., connected
vehicle, Traffic Management, and Fleet Management) can have different
responsibilities, and in alternative system designs some of these responsibilities can be
assigned to different components. In the discussion presented here, the basic operating
functions will be reviewed and the alternative assignments will be explored in the
detailed design effort.
4.1.1 MMITSS Roadside Processor
In the Arizona test network, the MMITSS Roadside Processor (MRP) is the Savari StreetWave processor. The MRP selected for the California test network is described by the following specification:
2. MMITSS Concept of Operations, 12/4/2012, http://www.cts.virginia.edu/wp-content/uploads/2014/05/Task2.3._CONOPS_6_Final_Revised.pdf
3. MMITSS System Requirements Document, 3/7/2012, http://www.cts.virginia.edu/wp-content/uploads/2014/05/Task3._SyRS_4_PostSubmittal_V3.pdf
Section 7.6 of the MMITSS System Requirements Document provides a detailed
traceability of each requirement to the Stakeholder inputs and Use Cases identified in
the Concept of Operations.
6.1 Road Side Equipment (RSE) Components
6.1.1 RSE_SecurityCertificateService
6.1.1.1 Functional Requirements
Node: RSE Component Name: RSE_SecurityCertificateService Traceability: System Requirements Section 6.6.3
Description of Responsibility: This component is responsible for providing security services on the RSE. It is responsible for ensuring trusted, eligible equipped vehicles (OBEs) can send BSM and SRM messages to the RSE.
Supporting Text: The RSE_SecurityCertificateService will have a connection to a Certificate Server (SCMS) that will provide the security certificates and a revocation list.
6.1.1.2 Functional Description
This component is responsible for providing security services on the RSE. It is
responsible for ensuring that trusted, eligible equipped vehicles (OBEs) can send BSM
and SRM messages to the RSE and to deny services to untrusted equipped vehicles
whose certificates appear on the Certificate Revocation List (CRL).
MMITSS Detail Design (California)
Page 35 of 96
The RSE_SecurityCertificateService is not a traditional software component. The
security services are implemented as part of the IEEE 1609.2 stack that is in the Savari
operating system services.
Figure 20 Security Service Architecture
The current standard requires an end-to-end IPv6 link between the RSE and the Security
Credential Management System (SCMS) (see Figure 20). This requirement is a design
challenge for the field deployment since IPv6 has not yet widely deployed and the
backhaul networks in both the Arizona and the California test beds do not support IPv6.
IPv6 tunneling over existing IPv4 networks is a common method for transition from IPv4
to IPv6, but it is complex to set up and have been observed to suffer a variety of
performance and stability issues2. The development team was not able to test IPv6 over
IPv4 tunneling on the UA and UCB campuses due to restrictions by the universities’ IT
services.
2 American Association of State Highway and Transportation Officials (AASHTO), National Connected Vehicle Field Infrastructure Footprint Analysis – Design Gaps Analysis, Version 1, June 2012 (available online at http://ssom.transportation.org/documents/aashto_footprint_analysis_design_gaps_analysis_v1.docx)
MMITSS Detail Design (California)
Page 36 of 96
6.1.2 RSE_ServiceAdvertisementMgr
6.1.2.1 Functional Requirements
Node: RSE Component Name: RSE_ServiceAdvertisementMgr Traceability: System Requirements Section 6.6.2
Description of Responsibility: This component is responsible for broadcasting WAVE service advertisement (WSA) messages on the WAVE control channel (CCH) to announce the presence of MMITSS Traffic Control service and the WAVE service channel (SCH) to be used for exchanging MMITSS service data (e.g. signal request messages - SRMs and signal status messages - SSMs).
Supporting Text: The RSE_ServiceAdvertisementMgr broadcasts WAVE service advertisement (WSA) messages so that approaching vehicles will be aware of the availability of MMITSS Traffic Control service. Vehicles that receive the WSA will be tuned to the service channel as specified in the WSA to perform the MMITSS service.
6.1.2.2 Functional Description
This component is responsible for broadcasting WAVE service advertisement (WSA)
messages on the control channel (CCH 178) to announce the presence of MMITSS
Traffic Control service and the service channel (SCH 182) to be used for exchanging
data (e.g., SRM and SSM) to perform the MMITSS Traffic Control service.
MMITSS service users (e.g. vehicles that are eligible for signal priority) monitor the WSA.
If desired, they can participate in the MMITSS Traffic Control service by sending SRMs
and receiving SSMs on the indicated SCH (182). Basic safety messages (BSMs), signal
phase and timing (SPaT) messages and MAP messages are expected to be transmitted
on the SCH 172. Thus, no WSA would be needed for these three types of messages.
Currently, there are no SAE J2735 message specifications for the WSA message. WSA
is defined as part of the IEEE1609.4 standard specification, but it is not clear how
Dynamic Mobility Applications, such as MMITSS, should implement the WSA. [Note:
There was a teleconference organized by the SAE DSRC Message Framework
subcommittee on May 23, 2014 to discuss this issue. No specific implementation issues
were resolved, but there were very constructive discussions from a variety of experts].
The WSA use is currently being debated by the IEEE 1609 Technical Committee and the
SAE DSRC Technical Committee. Future developments will clarify the use and protocol
for WSA use.
MMITSS Detail Design (California)
Page 37 of 96
6.1.3 RSE_MessageRX
6.1.3.1 Functional Requirements
Node: RSE Component Name: RSE_MessageRX
Traceability: C2001.001 (All vehicle data acquired by RSE through the WAVE communications)
Description of Responsibility: This component is responsible for receiving properly formatted messages over a specified WAVE channel.
Supporting Text: The RSE_MessageRX component is responsible for receiving properly formatted SAE J2735 messages over a specified (or appropriate) WAVE channel. Example messages would include the Basic Safety Message (BSM), Signal Request Message (SRM), etc.
6.1.3.2 Interfaces
The RSE_MessageRX interfaces are shown in Figure 21. The required interface is the
WME API provided by the WAVE unit (e.g. RSE). The provided interface is the UDP
socket API (see Section 5.3.2) to which to forward the received over-the-air
WSMs/WSMPs.
Figure 21 RSE_MessageRX Interface Diagram
6.1.3.3 Functional Description
The RSE_MessageRX component is responsible for connecting with the WME stack,
receiving over-the-air WSMs/WSMPs, and forwarding the WSMs/WSMPs to the
MRP_DataMgr component for further processing. This component reads a configuration
file (e.g. rseWmefwd.cnf) regarding the mapping between J2735 message sets and the
corresponding actions (e.g., receiving on the UDP socket address and transmitting over
the air, and/or receiving over the air and transmitting to the UDP socket address). The
mapping between J2735 message sets and the associated radio channel characteristics
(e.g., radio interface, channel number and PSID) is included in a header file (e.g.
wmeUtils.h). The same configuration file and the header file are used for both the
RSE_MessageRX Interfaces
RSE_MessageRXMRP_DataMgr
<<manifest>>
wmeUtils.h rseWmefwd.conf
WME
WSMP
UDP Socket API WME API
MMITSS Detail Design (California)
Page 38 of 96
RSE_MessageRX and RSE_MessageTX, while the RSE_MessageRX manages the
message sets to be received over the air and the RSE_MessageTX manages the
message sets to be transmitted over the air.
6.1.3.4 Configuration File Format
A sample Configuration file is attached below, with inline comments explaining the
# TxDirection is between the application and the WSMP stack:
# TX = routing application message to over the air message
# RX = routing over the air messages to the application
# TX_RX = application sending and also receiving the same message set broadcast
# from other parties, such as other intersection’s SPaT, etc.
#
application 1:BSM:USER:RX:MMITSS
application 1:SRM:USER:RX:MMITSS
application 1:MAP:USER:TX:MMITSS
application 1:SPaT:USER:TX_RX:MMITSS
application 1:SSM:USER:TX:MMITSS
#
# Socket configuration:
# protocol : hostname : port
#
listenSocket UDP:192.168.0.150:15001 # for MessageTX
sendSocket UDP:192.168.0.166:15000 # for MessageRX
6.1.4 RSE_MessageTX
This component is complementary to the RSE_MessageRX component. It is responsible
for transmitting SPaT, MAP and SSM messages over the air.
MMITSS Detail Design (California)
Page 39 of 96
6.1.4.1 Functional Requirements
Node: RSE Component Name: RSE_MessageTX
Traceability: C2009.001 (Providing intersection data to connected vehicles)
Description of Responsibility: This component is responsible for transmitting properly formatted messages over a specified WAVE channel.
Supporting Text: The RSE_MessageTX component is responsible for transmitting properly formatted SAE J2735 messages over a specified (or appropriate) WAVE channel. Example messages would include the Signal Status Message (SSM), Signal Phase and Timing (SPaT) message, MAP message, etc.
6.1.4.2 Interfaces
The RSE_MessageTX interfaces are shown in Figure 22. The required interface is the
UDP socket API (see Section 5.3.2) for receiving WSM payloads (e.g. SPaT, MAP and
SSM) from the MRP_DataMgr component. The provided interface is the WME API for
transmitting the messages over the air.
Figure 22 RSE_MessageTX Interface Diagram
6.1.4.3 Functional Description
The RSE_MessageTX component is complementary to the RSE_MessageRX
component with flow of messages going in the reverse direction. This component is
responsible for connecting with the WME stack, receiving payloads from the
MRP_DataMgr component, and transmitting WSMs/WSMPs over the air. This
component uses the same configuration file as that is used by the RSE_MessageRX
component (see Section 6.1.3.4).
RSE_MessageTX Interfaces
WME
WSMP
RSE_MessageTXWME API
MRP_DataMgr
<<manifest>>
wmeUtils.h rseWmefwd.conf
UDP Socket API
MMITSS Detail Design (California)
Page 40 of 96
6.2 On-Board Equipment (OBE) Components
6.2.1 OBE_MessageRX
The OBE_MessageRX component is identical to RSE_MessageRX, while running on an
OBE. This component is responsible for receiving over-the-air WMS/WSMPs and
transmitting the messages to the OBE_Aware component for further processing.
6.2.1.1 Functional Requirements
Node: OBE Component Name: OBE_MessageRX
Traceability: A1002 (All intersection data acquired by OBE through the WAVE communications)
Description of Responsibility: This component is responsible for receiving properly formatted messages over a specified WAVE channel.
Supporting Text: The OBE_MessageRX component is responsible for receiving properly formatted SAE J2735 messages over a specified (or appropriate) WAVE channel. Example messages would include the Signal Phase and Timing (SPaT) message, MAP message, Signal Status Message (SSM), etc.
6.2.1.2 Interfaces
The OBE_MessageRX interfaces are shown in Figure 23. The required interface is the
WME API provided by the WAVE unit (e.g. OBE). The provided interface is the UDP
socket API (see Section 5.3.2) with which to forward the received over-the-air
WSMs/WSMPs.
Figure 23 OBE_MessageRX Interface Diagram
6.2.1.3 Functional Description
The OBE_MessageRX component is responsible for connecting with the WME stack,
receiving over-the-air WSMs/WSMPs, and forwarding the WSMs/WSMPs to the
OBE_Aware component for further processing. This component reads a configuration file
OBE_MessageRX Interfaces
OBE_MessageRXOBE_Aware
<<manifest>>
wmeUtils.h obeWmefwd.conf
WME
WSMP
UDP Socket API WME API
MMITSS Detail Design (California)
Page 41 of 96
(e.g. obeWmefwd.cnf) regarding the mapping between J2735 message sets and the
corresponding actions (e.g., receiving on the UDP socket address and transmitting over
the air, and/or receiving over the air and transmitting to the UDP socket address). The
mapping between J2735 message sets and the associated radio channel characteristics
(e.g., radio interface, channel number and PSID) is included in a header file (e.g.
wmeUtils.h). The same configuration file and the header file are used for both the
OBE_MessageRX and OBE_MessageTX, while the OBE_MessageRX manages the
message sets to be received over the air and the OBE_MessageTX manages the
message sets to be transmitted over the air.
6.2.1.4 Configuration File Format
A sample Configuration file is attached below, with inline comments explaining the
# TxDirection is between the application and the WSMP stack:
# TX = routing application message to over the air message
# RX = routing over the air messages to the application
# TX_RX = application sending and also receiving the same message set broadcast
# from other parties, such as other car's BSM, etc.
#
application 1:BSM:USER:TX:MMITSS
application 1:SRM:USER:TX:MMITSS
application 1:MAP:USER:RX:MMITSS
application 1:SPaT:USER:RX:MMITSS
application 1:SSM:USER:RX:MMITSS
#
# Socket configuration:
# protocol : hostname : port
#
listenSocket UDP:127.0.0.1:15001 # for MessageTX
sendSocket UDP:127.0.0.1:15000 # for MessageRX
6.2.2 OBE_MessageTX
This component is complementary to the OBE_MessageRX component. It is responsible
for transmitting BSM and SRM messages over the air.
MMITSS Detail Design (California)
Page 42 of 96
6.2.2.1 Functional Requirements
Node: OBE Component Name: OBE_MessageTX
Traceability: C2001.001 (Providing all vehicle data to RSE through the WAVE communications)
Description of Responsibility: This component is responsible for transmitting properly formatted messages over a specified WAVE channel.
Supporting Text: The OBE_MessageTX component is responsible for transmitting properly formatted SAE J2735 messages over a specified (or appropriate) WAVE channel. Example messages would include the Basic Safety Message (BSM) and Signal Request Message (SRM), etc.
6.2.2.2 Interfaces
The OBE_MessageTX interfaces are shown in Figure 24. The required interface is the
UDP socket API (see Section 5.3.2) for receiving WSM payloads (e.g. BSM and SRM)
from the OBE_Aware component. The provided interface is the WME API for transmitting
the messages over the air.
Figure 24 OBE_MessageTX Interface Diagram
6.2.2.3 Functional Description
The OBE_MessageTX component is complementary to the OBE_MessageRX
component with flow of messages going in the reverse direction. This component is
responsible for connecting with the WME stack, receiving payloads from the OBE_Aware
component, and transmitting WSMs/WSMPs over the air. This component uses the
same configuration file as that is used by the OBE_MessageRX component (see Section
6.1.3.4).
OBE_MessageTX Interfaces
WME
WSMP
OBE_MessageTXWME API
OBE_Aware
<<manifest>>
wmeUtils.h obeWmefwd.conf
UDP Socket API
MMITSS Detail Design (California)
Page 43 of 96
6.2.3 OBE_Aware
6.2.3.1 Overview of Functionality
The OBE_Aware is the core MMITSS OBE component. It is responsible for:
• Acquiring vehicle geolocation (latitude, longitude and elevation) and movement
state (speed and heading) data from the on-board GPS receiver;
• Forming BSM messages and sending the BSMs to the OBE_MessageTX
component;
• Processing the received MAP messages, tracking the vehicle on the MAP and
estimating the expected time-to-arrive (ETA) at the intersection stop-line
(locationAware);
• Processing the received SPaT messages to obtain the state and the remaining
time of the signal that controls the movement of the vehicle (signalAware); and
• When it is eligible for priority, forming SRM messages and sending the SRMs to
the OBE_MessageTX component.
Sending BSMs, locationAware and signalAware are the common tasks for all OBEs,
regardless whether the OBE is eligible for priority or not. The functionalities of
encoding/decoding J2735 messages, locationAware and signalAware are implemented
by the J2735Lib class (see Section 5.2).
Additional tasks for priority eligible vehicles (e.g. buses, trucks) are forming and sending
SRM messages with information already made available in locationAware and
signalAware, and updating the request information if there is a change in status or date.
When passed the intersection stop line, the OBE_Aware should send a cancel priority
request so that the intersection can serve priority for other vehicles. The transition
diagram of the status of priority request is shown in Figure 25.
Figure 25 Priority Request State Transition Diagram
stm priorityReqState
Idle
RequestedBeenReceived
UpdateRequest
[ETA changed]
[ON_APPROACH]
[Request in SSM]
[Cancel SRM sent]
[Request not in SSM]
[SRM sent]
MMITSS Detail Design (California)
Page 44 of 96
6.2.3.2 Functional Requirements
Node: OBE Component Name: OBE_Aware Traceability: A1002, A1003, A1004, C2001.001
Description of Responsibility: The OBE_Aware component is responsible for formatting the J2735 BSM message by collecting vehicle data from the GPS receiver and (optional) vehicle data systems (CAN bus), determining a vehicle’s eligibility for priority and formatting the J2735 SRM message. It is also responsible for updating any of the request information if there is a change in status or data.
Supporting Text: This component is responsible for getting vehicle data, GPS data, and forming the BSM message. (Part 1 and Part 2 as data is available). When it is eligible for priority, this component is also responsible for determining the level of priority to request, desired service time and service phase or approach, and forming the SRM message (including cancel priority request). The OBE_MessageTX component is responsible for broadcasting the BSM and SRM messages.
6.2.3.3 Derived requirements
The BSM should be sent at a 10Hz rate. The SRM should be sent asynchronously and
not faster than 1Hz.
6.2.3.4 Interfaces
This OBE_Aware interfaces are shown in Figure 26.
Figure 26 OBE_Aware Interface Diagram
The required interfaces include:
OBE_Aware Interfaces
OBE_AwareOBE_GUI
<<manifest>>
obeVin.conf obeSocket.conf
GPS LibUDP Socket API
GPSLib API
OBE_MessageTX OBE_MessageRX
J2735Lib
J2735Lib API
UDP Socket API
MMITSS Detail Design (California)
Page 45 of 96
• The UDP socket API (see Section 5.3.2) for receiving SPaT, MAP and SSM
messages from the OBE_MessageRX component;
• The GPSLib API (provided by the WAVE device) for acquiring vehicle geolocation
and movement data; and
• The J2735Lib API (see Section 5.2) for encoding/decoding J2735 messages and
tracking vehicle on the MAP.
The provided interfaces are the UDP socket API for sending BSM and SRM messages to
the OBE_MessageTX component, and sending the display messages to the OBE_GUI
component.
The socket configuration file (e.g. obeSocket.conf) contains information regarding the
socket addresses for listening and sending the UDP packets, and the directory that
stores the MAP description files. An example of the socket configuration file is attached
below:
#######################################
# Socket configuration file for OBU
#######################################
nmapFile := /root/CAtestbed.nmap
wsmListenSocket := UDP:127.0.0.1:15000 # receive from messagerx
wsmSendSocket := UDP:127.0.0.1:15001 # send to messagetx
guiSendSocket := UDP:127.0.0.1:15005 # send to obe gui
The vehicle configuration file (e.g. obeVin.conf) includes parameters such as vehicle
type (e.g. car, bus, truck, etc.), vehicle length, width, VIN number, and priority level (if it
is eligible for priority). These parameters are used for forming BSM and SRM messages.
An example of the vehicle configuration file is attached below:
reqNums uint32_t The number of priority requests that the MRP have
received (in SSM)
reqList List of requests that the MRP have received (in SSM)
6.2.3.5 Functional Description
An activity diagram which illustrated the operation of the OBE_Aware component is
shown in Figure 27. Actions marked with dark green color are operations of the J2735Lib
class (see Section 5.2).
The OBE_Aware maintains lists of received SPaT and SSM messages, one (latest)
record per intersection. When received MAP messages, it compares the version of the
over-the-air MAP against the version of MAP stored in the memory (e.g. the
mpIntersection object). If a newer version is detected, it updates the stored MAP for the
use of tracking the vehicle on MAP.
The OBE_AWARE acquires GPS data at a 10Hz rate, forms a BSM, and sends to the
OBE_MessageTX component which broadcasts the message over the air. It then uses
the GPS data to locate the vehicle on the MAP (determining intersectionID, laneID and
the projection point on the lane), and calculates the distance to the intersection stop line
and the expected arrival time (updateLocationAware). It finds the intersection SPaT from
the SPAT list and gets the state and the remaining time of the signal that controls the
vehicle’s (lane) movement (updateSignalAware), and finds the intersection SSM from the
SRM list and checks whether it needs to send/update the priority request
(updateReqStatus). When needed, it forms an SRM and sends to the OBE_MessageTX
component. When detected the vehicle has passed the stop line, the OBE_Aware sends
a cancel priority SRM. The state transit of request status is shown in Figure 25.
MMITSS Detail Design (California)
Page 47 of 96
Figure 27 Activity Diagram of OBE_Aware
6.2.4 OBE_GUI
The OBE_GUI is an important component of the in-vehicle system for the MMITSS
project. It allows developers and interested observers to visualize the status of the
vehicle, the communication system, traffic signals, and priority control services.
act OBE_Aware
Start
readConfigurationFiles
createJ2735LibInstance
createSockets
connect2gps
Received
WSMs?
decode_payload
updateSPaTlist
updateSSMlist
updateMapDataStruct
New MAP?
Time to
acquire GPS?
getGPSdata
encode_bsm_payload
sendBSM locateVehicleInMap
updateLocationAware
updateSignalAware updateReqStatus
Send
SRM?
encode_srm_payload sendSRM
SendDispMsg
[Yes]
[No]
[No]
[SPaT]
[Yes]
[No]
[MAP]
[Yes]
[No]
[SSM][Yes]
MMITSS Detail Design (California)
Page 48 of 96
6.2.4.1 Requirements
Node: OBE Component Name: OBE_GUI Traceability: System Requirements Section 6.3 (General
Interface Requirements)
Description of Responsibility: OBE_GUI component is responsible for providing a human interface to the OBE so that the developers can visualize the data used by the OBE processes including vehicle data and priority request data.
Supporting Text: The ability to visualize the status of the OBE components is important in the development, testing, and demonstration of the MMITSS system. The use of a webserver and custom web pages allows the developers to easily visualize data. It is acknowledged that there are some delays or latencies in using web pages, but they have been valuable tools.
6.2.4.2 Interfaces
The required interface is the UDP socket API for receiving the display message from the
OBE_Aware component. The structure of the display message is described in Table 4.
This component does not provide any interface as it is a standalone application which
does not provide any data to other MMITSS components.
6.2.4.3 Functional Description
The OBE_GUI component provides a web page interface to display data to developers
and interested observers for the purpose of visualizing the status of the vehicle.
Figure 28 Example of OBE_GUI Interface
MMITSS Detail Design (California)
Page 49 of 96
The OBE_GUI interface is shown in Figure 28. It consists of several frames. OBE’s
current location is displayed on the top-left Google Map. SPaT information of the
approaching intersection is displayed on the top-right frame with colored movements and
pedestrian signs. The middle frame lists all the MMITSS intersections in the California
test network with a red dot indicating the approaching intersection. The bottom frame
lists the “Current Active Request Table”, which shows the status of all priority requests
that are at the approaching intersection. In the example shown in Figure 28, the OBE
represents a transit vehicle (ID 601). It is traveling northbound on El Camino Real and
heading to the intersection at Stanford Ave. Another OBE (ID 603 representing a truck) is
traveling on southbound of El Camino Real and also heading to the Stanford Ave.
intersection. Both OBEs have requested signal priority. The Stanford intersection is
serving phase 2 and 6 (along El Camino Real) with the Flashing Don’t Walk pedestrian
interval. Green extension priority is granted to the bus (ID 601) as the remaining
pedestrian interval (7 seconds) is shorter than the service time (12 seconds) required by
the bus.
6.3 MMITSS Roadside Processor (MRP) Components
6.3.1 MRP_DataMgr
6.3.1.1 Overview of functionality
The MRP_DataMgr component is responsible for bridging messages between the
MRP_TrafficControllerInterface component and other MMITSS components. The
functionalities of this component include
• Receive and store data from the linked components;
• Encode SPaT message and send it to the MRP_MessageTX, the
Nomadic_PriorityDataServer and the MRP_AWARE components (The
MRP_TrafficControllerInterface component sends the unencoded SPaT data to
the MRP_DataMgr);
• Send encoded MAP messages to the MRP_MessageTX component and the
Nomadic_PriorityDataServer component;
• Forward or send poll response to the linked components; and
• Timestamp all data for use in synchronizing actions and logging data for post-
processing.
In Section 5.3.3, messages that are bridged via the MRP_DataMgr component are
summarized in Table 3, with the structures of each message set illustrated in Figure 19.
Table 5 below summarizes the actions of the MRP_DataMgr component on each of the
messages.
MMITSS Detail Design (California)
Page 50 of 96
Table 5 MRP_DataMgr Actions on Messages
Message Type Message ID From Action
BSM 0x40 RSE_MessageRX Forward to MRP_Aware
SRM 0x41 RSE_MessageRX Forward to MRP_Aware
PSRM 0x42 Nomadic_PriorityDataServer Forward to MRP_Aware
Description of Responsibility: The MRP_DataMgr is responsible for collecting data from the linked MMITSS components, forwarding or sending poll responses to the appropriate components for further processing. It is also responsible for sending J2735 SPAT, MAP and SRM messages to the components for broadcasting it over the air or transmitting it to the nomadic MMITSS app, and forwarding the BSM, SRM and PSRM messages to the component that processes them.
Supporting Text: The California test network uses a Caltrans 2070 controller to push out SPaT data at each intersection.
MMITSS Detail Design (California)
Page 51 of 96
6.3.1.3 Derived requirements
The MRP_TrafficControllerInterface component sends the unencoded SPaT data at a
rate of 10Hz. The MRP_DataMgr immediately encodes SPaT and sends to the
RSE_MessageTX component for broadcasting it over the air, and to the
Nomadic_PriorityDataServer for routing to the appropriate nomadic MMITSS app users.
This component should send MAP messages at a rate of 1Hz.
6.3.1.4 Interfaces
Interfaces of the MRP_DataMgr component are shown in Figure 29.
The required inputs include:
• Over-the-air BSM and SRM messages from the RSE_MessageRX component;
• PSRM messages via the internet backbone from the Nomadic_PriorityDataServer
component;
• SPaT data, controller configuration date, and vehicle detection data from the
MRP_TrafficControllerInterface component;
• SSM, control command (e.g. soft-call), and vehicle trajectory data from the
MRP_Aware component; and
• Intersection MAP description file for constructing the J2735 MAP.
The provided outputs include:
• J2735 BSM, SRM and PSRM messages to the MRP_Aware component;
• J2735 SPaT, MAP and SSM messages to the RSE_MessageTX and the
Nomadic_PriorityDataServer components;
• Control command (e.g. soft-call) to the MRP_TrafficControllerInterface
component; and
• Poll response to the request component.
Socket addresses for the required and provided interfaces are input as a configuration
file (e.g. mgrSocket.conf). An example of the configuration file is attached below.
MMITSS Detail Design (California)
Page 52 of 96
#######################################
# Socket configuration file for DataMgr
#######################################
nmapFile := /home/mrp/conf/CAtestbed.nmap
logPath := /home/mrp/logs
logInterval := 120 # in minutes
wsmListenSocket := UDP:192.168.0.166:15000 # receive from messagerx
wsmSendSocket := UDP:192.168.0.150:15001 # send to messagetx
cloudListenSocket := UDP:192.168.0.166:15010 # receive from ped server
cloudSendSocket := UDP:107.178.209.212:15010 # send to ped server
awareListenSocket := UDP:127.0.0.1:15021 # receive from mrpaware
awareSendSocket := UDP:127.0.0.1:15022 # sent to mrpaware
tciListenSocket := UDP:127.0.0.1:15023 # receive from tci
tciSendSocket := UDP:127.0.0.1:15024 # send to tci
obsListenSocket := UDP:127.0.0.1:15025 # receive from perfobs
obsSendSocket := UDP:127.0.0.1:15026 # send to perfobs
Figure 29 MRP_DataMgr Interface Diagram
6.3.1.5 Functional Description
An activity diagram which illustrates the operation of the MRP_DataMgr component is
shown in Figure 30. Actions marked with dark green color are operations of the J2735Lib
class (see Section 5.2). When receiving a UDP packet, the MRP_DataMgr first updates
MRP_DataMgr Interfaces
<<manifest>>
mgrSocket.conf Int.nmap
OBE_MessageTX OBE_MessageRX
UDP Socket APIMRP_Performance
Observer
Nomadic_Priority
DataServer
UDP Socket API
UDP Socket API
MRP_Aware
MRP_Traffic
ControllerInterface
J2735LibJ2735Lib API
MRP_DataMgr
MMITSS Detail Design (California)
Page 53 of 96
its memory blocks to store the new data, and then checks the message ID insider the
MMITSS message header and performs the actions as described in Table 5:
• Forward BSM, SRM, PSRM, SSM and SoftCall to the appropriate components;
• Encode SPaT data and send J2735 SPaT; and
• Send polled messages to the poll requester.
This component also sends MAP messages to the RSE_MessageTX and the
Nomadic_PriorityDataServer components every 1 second.
Figure 30 Activity Diagram of MRP_DataMgr
6.3.2 MRP_TrafficControllerInterface
6.3.2.1 Overview of Functionality
The MRP_TrafficControllerInterface component is responsible for providing the protocol
specific interface to the traffic signal controller. The California test network uses Caltrans
Model 2070 traffic controllers with AB3418 protocols over serial RS-232
Description of Responsibility: This component is responsible for acquiring data and estimating intersection level performance measures. The collected measures may be requested by section or system level performance observers.
Supporting Text: The MRP_PerformanceObserver is responsible for the estimation of performance measures from data available from the other MRP level components.
6.3.4.3 Interfaces
The MRP_PerformanceObserver interfaces are shown in Figure 36.
dataMgrSendSocket := UDP:127.0.0.1:15025 # send to datamgr
dataMgrListenSocket := UDP:127.0.0.1:15026 # receive from datamgr
observeDuration := 15 # in minutes (the interval for acquiring data from
datamgr, calculating performance metrics, and sending
metrics to datamgr)
6.3.4.4 Functional Description
When an OBE enters the range of the DSRC radio, the MRP_Aware receives the BSM
and SRM messages from the OBE, maps the location of the OBE on the intersection
MAP, and sends its trajectory data to the MRP_DataMgr when the OBE moves out the
MAP (see Figure 35). The trajectory data includes vehicle ID, timestamp, distance to the
stop-line, and the signal phase to which the vehicle is approaching (see Figure 18). Let �Traj�� be the set of vehicle trajectories associated with phase �(� = 1,2,⋯ ,8) during one observation period (e.g. 15 minutes), and let �� be the number of trajectories in �Traj��. Let �� be the length in meters of the approaching leg and �� be the free flow speed (e.g. the speed limit in this design), the free flow travel time is given by
FFTT� = ���� ,� = 1,2,⋯ ,8 (1)
Let Tr� ∈ �Traj�� be the trajectory of vehicle �(� = 1,2, ⋯ , ��) in �Traj��. It enters the approaching leg at time ��� and leaves the approaching leg at ��� with a distance � meters traveled in between. The average travel speed of the vehicle � is given by
MRP_PerformanceObserver
<<manifest>>
obsSocket.conf
UDP Socket API
MRP_Performance
ObserverMRP_DataMgr
MMITSS Detail Design (California)
Page 66 of 96
�̅� = ���� − ��� (2)
Its travel time and delay are given by equations (3) and (4), respectively.
tt� = ���̅� (3)
dt� = tt� − FFTT� (4)
The travel time and travel time variability associated with phase � are given by equations (5) and (6), respectively.
As it is described in Section 6.3.2, the MRP_TrafficControllerInterface component
receives the system detector count data from the 2070 controller and sends the detector
data to the MRP_DataMgr. Let �Count�� be the set of system detector count data associated with phase �(� = 1,2,⋯ ,8) during one observation period (e.g. 15 minutes), and let 7� be the number of detector data messages in �Count��. Each detector data message includes the number of vehicles (8� , � = 1,2,⋯ ,7�) passing over the system detector and the computation period (,� in seconds, � = 1,2,⋯ ,7�). The vehicle throughput associated with phase � is given by VT� = ∑ 8�9'�()∑ ,�9'�() × 3600(vph) (9)
MMITSS Detail Design (California)
Page 67 of 96
6.4 MMITSS Central System Components
6.4.1 MMITSSUserInterface
6.4.1.1 Overview of Functionality
The MMITSSUserInterface component is responsible for providing a user interface for
the system level MMITSS component.
6.4.1.2 Functional Requirements
Node: MMITSS
System
Component Name: MMITSSUserInterface
Traceability: (Overall MMITSS need)
Description of Responsibility: The MMITSSUserInterface component is responsible
for providing a user interface on the system level MMITSS component.
Supporting Text: The user interface is the point where users/operators can access the
PerformanceObserver Visualizations, System_ConfigurationManager, and
System_N_LevelPrioriityConfigurationManager. The user interface can provide
information about the status of the MMITSS system as well as general system
The MMITSSUserInterface is the point where user/operator can access the
System_ConfigurationManager and System_N_LevelPriorityConfigurationManager, and
visualization of performance measures at the intersection, and section levels. The goal of
this user interface is to make the traffic manager’s interaction with the MMITSS system
as simple and efficient as possible in terms of getting and accomplishing operator traffic
preferences (such as establishing the modes that will receive priority at the intersection
level or section level, allowable phase sequences, dilemma zone protection, etc.). The
user interface can provide information about the status of the MMITSS system as well as
general system information.
MMITSS Detail Design (California)
Page 68 of 96
The MMITSSUserInterface is a web-based application. The web server restricts access
to website content to only those traffic operators who have permission to access control
information. The status and performance web pages get data from these components as
well as from a database.
Figure 37 illustrates the architecture of the MMITSS Central user interface. The
MMITSSUserInterface supports both the Arizona and the California test beds. In
addition, there are pages providing MMITSS project information including the MMITSS
team members who are working on the project.
Figure 37 Web Application Map of MMITSS Central System
Figure 38 shows the system structure of the Performance Observer component. The
right side of the structure depicts the Linux or Windows server which gets the
performance metrics from the application, stores them into a database, and provides
visualization in a dynamic web application (WAMP/LAMP: Windows/Linux Apache
MySQL PHP).
MMITSS Detail Design (California)
Page 69 of 96
Figure 38 Performance Observer System Structure
The user can also configure the N-Level Priority Hierarchy for different modes and class
of vehicles. Emergency Vehicles, Trucks, Transit vehicles and non-motorized vehicles
are considered different modes [Note: MMITSS is capable of handling emergency
vehicle priority/preemption requests. However, this function is not implemented for
California MMITSS application due to non-technical considerations]. Within each mode,
there are different classes, such as BRT, express, and local transit classes, that the user
can rank according to the desired level of priority. For example, within emergency
vehicles, fire trucks may have the highest rank, ambulances are ranked second, and
police are ranked third.
6.4.1.5 Example Applications
Figure 39 shows the sequence diagram of interactions between the
MMITSSUserInterface, System_ConfigurationManager,
System_N_LevelPriorityConfigurationManager, and the Section_PerformanceObserver.
Figure 39 Sequence Diagram of Interactions between MMITSSUserInterface, System_Configuration Manager, System_N_LevelPriorityConfigurationManager, and Section_PerformacneObserver
To visualize all the performance measures observed at the intersection level, radar
diagrams are deployed. Figure 40 is a sample radar diagram. On each axis of this
diagram one of the twelve possible movements at an intersection is shown and the
selected performance measure is the average travel time in seconds for passenger
MMITSS Detail Design (California)
Page 70 of 96
vehicles on each approach. For example, passenger vehicles on the Northbound Right
Turn approach spend the least amount of time (17 seconds), and cars on Eastbound Left
Turn movement have the most travel time (78 seconds).
Figure 40 Sample key to radar diagrams used to describe traffic performance
When considering the complex interactions of the different transportation modes, there is
a need for a tool showing all the modes at the same time. The dashboard provided here
is able to show different measures of various modes under specific scenarios.
Figure 41 below is an example of the dashboard resulting from the simulation model of
the mentioned intersection at two different operational hours (peak vs. off-peak). Vehicle
and pedestrian demand are assumed to be 825 vehicles per hour per lane and 350
pedestrians per hour per crosswalk during the peak period and to be 325 vehicles per
hour per lane and 180 pedestrians per hour per crosswalk during the off-peak period.
This dashboard consists of 4 radar diagrams, one for each mode concentrating on the
following measures: travel time for passenger vehicles, delay for transit, number of stops
for trucks, and delay for pedestrians. The pie chart in the middle depicts the distribution
of modes in the system.
MMITSS Detail Design (California)
Page 71 of 96
Figure 41 Dashboard consisting of four radar diagrams and a pie chart for comparing Peak and Off-peak periods
Figure 42 shows three screenshots of the web application that is used to visualize the
outputs of the MRP_PerformanceObserver component. As stated previously in the
system structure, this web app runs on a Windows or Linux server in the same local
network. On the first page (a), the end user can choose between the configuration page
and the performance report page for active intersections. By selecting the report page
(b), the type of metrics and reports to view can be selected. The report page (c) shows
the sample of the types of graphs and visualizations available.
(a)
MMITSS Detail Design (California)
Page 72 of 96
(b)
(c)
Figure 42 User Interface_PerformanceObserver Web Application
Description of Responsibility: The System_ConfigurationManager is responsible for allowing operators to add intersections, create and name sections, assign intersections to sections, and access other critical configuration components including the System_N_LevelPriorityConfigurationManager.
Supporting Text: The configuration manager allows operators the ability to create, change, and delete sections and intersections in the system. This functionality can be accomplished using configuration files, but a simple user interface to view the configuration will support the demonstration of the system.
MMITSS Detail Design (California)
Page 73 of 96
In the Configuration page, the MMITSSUserInterface provides options for both section
and intersection level traffic control. At the section level, the user can specify whether
the section is to be operated as a coordinated section of signals. If so, information
related to coordination, such as the coordinated intersection names, the desired cycle
length, the coordinated phase, the offset for each intersection, and phase splits and
coordination weight should be provided. Figure 43 shows the configuration page of
Dedication – Daisy Mountain Dr. intersection (AZ).
Figure 43 MMITSS Configuration Manager Web Page for Dedication and Daisy Mountain
6.4.3 System_N_LevelPriorityConfigurationManager
6.4.3.1 Overview of Functionality
In each traffic control section, the decision makers define a preference for granting
priority to different classes of vehicles. For example BRT transit is more important than
Express transit and all transit is more important than trucks. In another section trucks are
more important than transit. The System_N_LevelPriorityConfigurationManager is the
mechanism where an operator can configure the policy. Given a policy setting, the
MMITSS Detail Design (California)
Page 74 of 96
configuration manager will set the associated parameters on the MRP and within section
Description of Responsibility: This component is responsible for implementing section level priority control based on requests for priority that are acquired from the intersections.
Supporting Text: Section level priority strategy may include coordination of signals to provide priority for emergency vehicles, or transit/trucks. Typically these strategies include coordination changes (e.g. offsets), queue clearance, or creation of green bands. The N-level priority policy is used to determine which modes/classes of vehicles are given preference over other mode/classes of vehicles.
6.4.5 Section_Coordinator
6.4.5.1 Overview of Functionality
The Section_Coordinator provides priority requests for coordination. If the intersection is
configured as part of a section of coordinated intersections, the phase splits, cycle
length, and offset would be mapped to a Coordination Request Message (CoordRM).
The Section_Coordinator receives trajectory of equipped vehicles from all of the
coordinated intersections within a section. It uses the trajectories to determine if the
offset needs to be adjusted to improve progression. [Implementation Note: The
Section_Coordinator was not implemented. Coordination can use the controller
coordination parameters to generate coordination priority requests].
Description of Responsibility: This component is responsible for acquiring intersection performance estimates and combining them with section level data to estimate section level performance measures.
Supporting Text: Section level performance measures utilize intersection level measures together with section level information (e.g. platoon size, head, tail, stops, travel time, etc.) to provide estimates of section level performance.
6.4.6.3 Interfaces
6.4.6.3.1 Required (Input)
The required data for this component is obtained from MRP_DataMgr in which the main
focus is on collecting intersection performance measures (see Section 6.3.4).
MMITSS Detail Design (California)
Page 78 of 96
6.4.6.3.2 Provided (Output)
The input data will be utilized to calculate and estimate the section performance
measures, including section travel time (STT in section), section delay (SDT in seconds),
and their variabilities (STTV and SDTV in seconds).
6.4.6.4 Functional Description
Let �Traj� be the set of �vehicle trajectories that travel along a section of (7 +1)signalized intersections. The directional section path is composed of 7 links where each link represents the road segment from the stop-line of an upstream intersection to
the stop-line of its downstream intersection. Let ��� be the travel time of vehicle � on link �, the section travel time of vehicle � is then given by �� = / ���9
�() (10)
The intersection level travel time and its variability on link �, estimated at the MRP_PerformanceObserver are given by equations (11) and (12), respectively.
TT� = "�#���$ = ∑ ���&�()� (11)
TTV�- = "�#��� − TT�$- = ∑ ���-&�()� − TT�- (12)
Note that equations (11) and (12) are the same equations (5) and (6) in Section 6.3.4.
The metric of the section travel time is given by
STT = "���� = " C/ ���9�() D = / "�#���$9
�() = / TT�9�() (13)
i.e., the section travel time can be calculated as the summation of intersection level
travel times estimated at the MRP_PerformanceObserver.
The variability of section travel time is defined as
STTV = E"��� − STT�- = ." C/ 0��� − TT�19�() D-
(14)
If assuming ��� are generated by link travel time distributions that are statistically independent, equation (14) becomes
STTV = ./ TTV�-9�() (15)
i.e., the variance of section travel time can be composed as the summation of the link
travel-time variances for all links.
MMITSS Detail Design (California)
Page 79 of 96
Similarly, the section delay time and its variability can be combined from that estimated
at the MRP_PerformanceObserver as follows:
SDT = / DT�9�() (16)
SDTV = ./ DTV�-9�() (17)
In this design, equations (13) and (15) are used for calculating section travel time (STT)
and its variability (STTV). Equations (16) and (17) are used for calculating section delay
time (SDT) and its variability (SDTV).
6.5 Nomadic Device Components (Savari SmartCross)
6.5.1 Nomadic Priority Request Generator
6.5.1.1 Overview of Functionality
This component is responsible for reading the direction that a NomadicMMITSSApp user
is intending to cross the street (by pointing the smartphone at the crosswalk),
determining the lane number of the intended crosswalk, formulating and sending a
Signal Request Message (SRM) to the Nomadic_PriorityDataServer, which in turn
transmits the SRM to the appropriate RSE.
6.5.1.2 Requirements
Node: Nomadic
Device
Component Name: Nomadic_PriorityRequestGenerator
Traceability: C1303.302
Description of Responsibility: This component on the nomadic device is responsible
for formulating and sending a request for service/priority from the nomadic device.
Supporting Text: The Nomadic_PriorityRequestGenerator is analogous to the OBE
based priority request generator, with the additional capability of using the nomadic
devices location services for determining the location and orientation of the device.
6.5.1.3 Interfaces
6.5.1.3.1 Required (input):
This component uses the internal Android APIs to acquire the following on-board sensor
information:
1. GPS sensor of the smartphone for location and speed
MMITSS Detail Design (California)
Page 80 of 96
2. Magnetometer sensor of the smartphone for phone’s orientation in relation to the
Earth’s magnetic field.
The component also uses the decoded MAP structure that is populated when the SAE
J2735 MAP messages are received from the Nomadic_PriorityDataServer.
6.5.1.3.2 Required (output):
This component sends out an ASN.1 encoded SAE J2735 Signal Request Message that
contains the lane number of the crosswalk that the user intends to cross. The SRM is
sent to the Nomadic_PriorityDataServer.
6.5.1.4 Functional Description
The Nomadic_PriorityRequestGenerator is used to formulate and send a signal request
message for pedestrian crossing. This component shall take into account the user’s
position, speed, as well as SPaT and MAP data to determine the user’s position with
respect to the crosswalks. When the user points the smartphone at the crosswalk that
he/she is intending to travel, this component reads the direction that the smartphone is
pointing at, determines the associated lane number of the crosswalk, forms and sends
an SRM to the Nomadic_PriorityDataServer.
6.5.2 Nomadic Signal Status Receiver
6.5.2.1 Overview of Functionality
This component is responsible for receiving MAP and SPaT data from the
Nomadic_PriorityDataServer and make it available to the NomadicMMITSSApp.
Description of Responsibility: This component is responsible for receiving signal
status data from an intersection and making the data available to the NomadicMMITSS
App.
Supporting Text: This is the analogous component to the OBE_MAP_SPaT_Receiver
for the nomadic device. It is responsible for receiving status data and making it available
to the app.
MMITSS Detail Design (California)
Page 81 of 96
6.5.2.3 Interfaces
6.5.2.3.1 Required (input):
SPaT and Map data from the Nomadic_PriorityDataServer.
6.5.2.3.2 Required (output):
This component is internal to the nomadic device and will provide information to the
application logic to determine the phase status for the relevant crosswalk. The output
from this component is sent to the user interface (UI) display component that in turn
alerts the user that his/her message has been acknowledged by the system.
6.5.2.4 Functional Description
This component of the SmartCross application will receive SPaT and MAP data from the
Nomadic_PriorityDataServer. It then decodes the message and determines if the signal
status is applicable based on the user’s location and phone orientation. It also checks if
the user has requested a pedestrian phase (by pointing the smartphone at the crosswalk
and pressing a requesting button on the NomadicMMITSSApp, see Section 6.5.3 below)
and notifies the user whether or not a signal request message has been sent to
Nomadic_PriorityDataServer for requesting service on the pedestrian phase.
6.5.2.5 Unit Test Descriptions (debugging and testing)
This component shall be tested in conjunction with all other components comprising the
Nomadic Traveler Service node. The primary tests for this component are to test the
component output with different user movements:
1. User requests a pedestrian phase and moves away from the curb.
2. User requests a pedestrian phase for a crosswalk and faces another crosswalk.
3. User is at the expected location but GPS errors cause the component to fail.
6.5.3 Nomadic MMITSS Application
6.5.3.1 Overview of Functionality
This is the end-user application that comprises components defined in Sections 6.5.1
and 6.5.2 in addition to:
1. User Interface components
2. SAE J2735 message encode/decode modules
3. Cloud connectivity modules
The smartphone application serves as the user interface component of the SmartCross
system. It enables the pedestrians to interact with the system to:
MMITSS Detail Design (California)
Page 82 of 96
1. Get near real time notifications of crosswalk phases and along with the interval
time;
2. Get audio, visual and haptic alerts when the pedestrian signal state changes or if
the user enters a crosswalk when unsafe to do so;
3. Request a pedestrian phase by pointing the smartphone at the crosswalk the user
wants to use; and
4. Get acknowledgement that the system has received the user’s request.
6.5.3.2 Functional Requirements
Node: Nomadic
Device
Component Name: NomadicMMITSSApp
Traceability: A1303, 13.3.3
Description of Responsibility: The NomadicMMITSS App is a downloadable app that
individuals can install on their nomadic device. It is the base application for the nomadic
device.
Supporting Text: It is assumed that the Nomadic Device is a smartphone (ios based or
android based) and that users will be able to download the app to their device. The app
provides the functionality available to the nomadic device including knowing how to
connect to the Nomadic_PriorityDataServer to get status data and send requests for
service. The Nomadic Device app can be configured to indicate that a user (pedestrian)
is disabled, authorized, and provided additional crossing time if needed.
6.5.3.3 Functional Description
The application’s main purpose is to provide signal timing information in the form of
audio, visual and haptic alerts to the user based on his/her location and phone
orientation. The application received the SPaT and MAP information from the
Nomadic_PriorityDataServer that is, in turn, connected to the RSEs via Internet. The
system architecture of the SmartCross application is as shown in Figure 46.
When the user launches the application, the UI (shown in Figure 47) is presented. If the
phone is used in accessibility mode, then each of the buttons shown on the UI will have
a Talkback mode that provides audio inputs based on where the user is touching the
screen.
Using this screen, the user selects the mode in which the application needs to operate.
When the first mode (e.g. pedestrian) is selected, the UI shown on the left side of Figure
48 is presented. The user interfaces for the other modes (bicycle, visually impaired and
wheelchair) are shown in the middle and right side of Figure 48, respectively.
MMITSS Detail Design (California)
Page 83 of 96
Figure 46 Savari SmartCross System Architecture
Figure 47 SmartCross App User Interface
MMITSS Detail Design (California)
Page 84 of 96
Figure 48 Ped Mode, Bicycle Mode, and Disabled Traveler Mode
For general pedestrians, the left mode shown in Figure 48 is used. This interface
provides the time remaining in seconds if the pedestrian phase interval is active. The
snapshot above shows a screen capture in a scenario where the user is not facing a
crosswalk or the pedestrian interval is inactive. When facing the crosswalk, the user can
request a WALK phase by pressing the blue “Press to Cross” button. When pressed,
the application sends out a Signal Request Message as detailed in Section 6.5.1. On
receipt of this message, the Nomadic_PriorityDataServer component sends a Signal
Status Message back to the pedestrian application. The application will receive this
message and notify the user that the request has been acknowledged. When the blue
“Press to Cross” button is pressed while not facing a crosswalk, an audio alert (“You are
not facing a crosswalk”) is triggered to indicate the user that he/she needs to adjust the
pointing direction of the phone at the crosswalk.
In the bicyclist mode, there is no mechanism to request a phase. The interface merely
displays the time remaining for the phase and along with the signal light state. It also
displays the bicyclist’s speed.
For the visually impaired and mobility impaired mode, the underlying operation is the
same as Mode 1 (general pedestrians). The interface is modified to eliminate the cross
button. Instead, if the user wants to request a crosswalk phase, he/she can do so by
pressing and holding any part of the screen for 3 seconds or until an audio notification is
heard.
In addition to the above operation, multiple scenarios are addressed by the application
to enhance safety.
MMITSS Detail Design (California)
Page 85 of 96
1. If the user enters a crosswalk when the crosswalk is not active, an audio alert
(“Do not walk”) and a strong haptic alert are triggered.
2. When the user is in an active crosswalk, the remaining time along with the
pedestrian signal state and audio beeps accompanied by haptic feedback. The
audio beep frequency and haptic feedback strength are different for WALK and
Flashing Don’t Walk (FDW).
3. When the system is unreliable, a notification communicating that the system is
unreliable and should not be used.
4. The user does not complete crossing the road when the FDW times out, the
green could be delayed. This depends on how the local agency wants to address
such a scenario.
The flowchart in Figure 49 illustrates user interaction with the SmartCross system. The
application sends out Pedestrian Location Messages (PLMs) to the
Nomadic_PriorityDataServer at an adaptive rate based on the proximity to a connected
intersection. Once at the intersection, the application sends out PLMs once a second.
When the Nomadic_PriorityDataServer receives the PLM message, it updates the list of
users at each intersection and begins transmission of SPaT and MAP data to the
appropriate pedestrian users. The application then parses the SPaT and MAP data and
uses it to display alerts/notification to the user.
If the user requests a pedestrian phase, the application encodes the crosswalk lane into
an SAE J2735 SRM message and transmits it to the Nomadic_PriorityDataServer which
forwards the SRM to the appropriate RSE. The application then receives a Signal
Status Message confirming receipt of the SRM.
6.5.3.4 Unit Test Descriptions (debugging and testing)
This component shall be tested in conjunction with all other components comprising the
Nomadic Traveler Service node. The application needs real world testing with the
following variables:
1. Different types of phones
2. Different intersection geometries
3. Different environments ( urban jungles vs. open to sky intersections)
4. Different cellular networks.
MMITSS Detail Design (California)
Page 86 of 96
Figure 49 SmartCross Flow Chart
MMITSS Detail Design (California)
Page 87 of 96
6.5.4 Nomadic_PriorityDataServer
6.5.4.1 Overview of Functionality:
This component is part of the Nomadic Traveler Service. It is responsible for receiving
pedestrian location messages (PLMs) from the nomadic users, receiving SPaT and
MAP messages from RSEs, identifying the intersection that a user is present, and
transmitting the corresponding SPaT and MAP data to the nomadic users.
6.5.4.2 Functional Requirements
Node: Nomadic
Server
Component Name: Nomadic_PriorityDataServer
Traceability: C1303.302
Description of Responsibility: This component is responsible for acquiring
infrastructure data and providing it to nomadic devices using cellular, WiFi, and/or
DSRC enabled smartphones.
Supporting Text: Infrastructure data, including the MAP, SPaT, Signal Status
Messages, etc. needs to be relayed from the MPR to the nomadic device through a
cloud based (or server based) capability. The Nomadic_PriorityDataServer is
responsible for providing this service. This component will host data for all (many)
intersections and the nomadic device will request data (using the NomadicMMITSS
App) based on the device’s location.
6.5.4.3 Interfaces
6.5.4.3.1 Required (input)
• This component should have internet connectivity to communicate with Google
Cloud Messaging (GCM) servers
• This component should receive SPaT and MAP messages from connected RSEs
• This component should receive PLMs and SRMs from the smartphone app
6.5.4.3.2 Provided (output)
• This component should transmit SPaT and MAP data to specific users based on
their location
• This component should forward pedestrian SRMs to the appropriate RSEs
• This component also relays SSM from the RSE to the nomadic user
6.5.4.4 Functional Description
This component receives PLMs from all application users at all connected intersections.
Based on their location and the MAP data, this component matches user locations with
MMITSS Detail Design (California)
Page 88 of 96
the intersections, and transmits the corresponding intersection SPaT and MAP to the
users.
When receiving an SRM from the smartphone app, this component relays the SRM to
the appropriate RSE. The SSM from the RSE is also relayed back to the user.
6.5.4.5 Unit Test Descriptions (debugging and testing)
Since this information is transmitted over the internet using a cellular connection, end-
to-end latency needs to be tested and the time values should be appropriately
compensated using the time mark data element in the J2735 SPaT message.
The system should also be tested for reliability over extended periods of time ranging
from a few hours to weeks.
An assessment of the system when any component of the backend infrastructure fails
needs to be completed before deployment.
6.5.5 Authorized Special User Service
6.5.5.1 Overview of Functionality:
This component is part of the Nomadic Traveler Service and is responsible for
authorizing services for users with special needs. Depending on the type of pedestrians,
this component may allow for an extended pedestrian phase for the particular user. The
functionality of this component is currently limited only to sending a request for extra
crossing time to the RSE.
6.5.5.2 Functional Requirements
Node: Nomadic Server
Component Name: AuthorizedSpecialUserService
Traceability: C1303.301, C1303.302
Description of Responsibility: This component is responsible for ensuring that nomadic devices are authorized participants in the MMITSS system and to authorize special service for pedestrians with a disability.
Supporting Text: This service is required to ensure unauthorized devices do not request service or have any other impact on the MMITSS system. Special users, e.g. pedestrians with disabilities, are required to have special authorization before being allowed to request extra crossing time.
6.5.5.3 Interfaces
This is internal to the Nomadic Traveler Service and does not have any external
interfaces.
MMITSS Detail Design (California)
Page 89 of 96
6.5.5.3.1 Required (input):
Pedestrian Location Message (PLMs)
6.5.5.3.2 Required (output):
Verification of the identity of the user and authorization of special services
6.5.5.4 Functional Specification/Description
This component receives the incoming PLMs from nomadic devices and verifies the
identity of the user requesting special services from a known list of users. Upon
verification, it authorizes the use of special services. These special services are
dependent on support from the traffic signal controller as well as traffic agency policies.
6.5.5.5 Unit Test Descriptions (debugging and testing)
This component will be tested with a known group of users requiring special services.
MMITSS Detail Design (California)
Page 90 of 96
7 Appendices
7.1 Acronyms
API Application Program Interface ASC Actuated Signal Controller ASD Aftermarket Safety Device ASN.1 Abstract Syntax Notation One AZ Arizona BRT Bus Rapid Transit BSM Basic Safety Messages CA California Caltrans California Department of Transportation CCH Control Channel CONOPS Concept of Operations CoordRM Coordination Request Message CRL Certificate Revocation List CTS Cooperative Transportation System CV Connected Vehicle DER Distinguished Encoding Rules DMA Dynamic Mobility Applications DOT Department of Transportation DSRC Dedicated Short Range Communication DT Delay Time DTV Delay Time Variability ENU East-North-Up ETA Expected Time of Arrival EV Emergency Vehicle FHWA Federal Highway Administration GID Geometric Intersection Description GPS Global Positioning Systems ID Identification ISIG Intelligent Traffic Signal System IT Information Technology ITS Intelligent Transportation System MCDOT Maricopa County Department of Transportation MMITSS Multi-Modal Intelligent Traffic Signal System MOE Measures of Effectiveness MRP MMITSS Roadside Processor NEMA National Electrical Manufacturers Association NTCIP National Transportation Communications for ITS Protocol OBE On-Board Equipment PATH Partners for Advanced Transportation Technology PFP Pooled Fund Project PFS Pooled Fund Study PI Principal Investigator
MMITSS Detail Design (California)
Page 91 of 96
PLM Pedestrian Location Message PSID Provider Service Identifier RSE Roadside Equipment SCMS Security Certificate Message Server SCH Service Channel SDT Section Delay Time SDTV Section Delay Time Variability SOBOS Savari On-Board Operating System SPaT Signal Phase and Timing SRM Signal Request Message SSM Signal Status Message STT Section Travel Time STTV Section Travel Time Variability SVN Subversion (PFP Repository with Version Control) SyRS System Requirements TIM Traffic Information Message TOC Traffic Operations Center TSC Traffic Signal Controller TSCP Traffic Signal Control Program TSP Transit Signal Priority UA University of Arizona UCB University of California at Berkeley UDP User Datagram Protocol UML Unified Modeling Language USDOT United States Department of Transportation V2I Vehicle-to-Infrastructure V2V Vehicle-to-Vehicle VDOT Virginia Department of Transportation VIN Vehicle Identification Number WAVE Wireless Access in Vehicle Environment WME WAVE Management Entity WSA WAVE Service Advertisement WSM WAVE Short Message WSMP WAVE Short Message Protocol