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

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


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


i

Table of Contents

1 Purpose of Document ................................................................................................ 1

2 Scope of Project ........................................................................................................ 1

3 Detailed Design Approach ......................................................................................... 2

4 High Level System Design ........................................................................................ 3

4.1 Physical Architecture ........................................................................................... 4

4.1.1 MMITSS Roadside Processor ....................................................................... 7

4.1.2 RSE Radio ..................................................................................................... 7

4.2 Software Components ......................................................................................... 7

4.3 Overview of WAVE Communications ................................................................ 10

5 California MMITSS Implementation ......................................................................... 14

5.1 California MMITSS Software Components ........................................................ 15

5.2 J2735 Library ..................................................................................................... 17

5.2.1 MAP Description File ................................................................................... 19

5.2.2 MAP Data Structure .................................................................................... 20

5.2.3 Encoding and Decoding J2735 Messages .................................................. 23

5.2.4 MAP for Large Intersections ........................................................................ 24

5.2.5 Tracking Vehicle Location on a MAP ........................................................... 25

5.3 Software Component Interfaces ........................................................................ 28

5.3.1 MRP Data Manager ..................................................................................... 29

5.3.2 UNIX Socket API ......................................................................................... 30

5.3.3 MMITSS Message Header .......................................................................... 31

6 Detailed Component Designs (California) ............................................................... 34

6.1 Road Side Equipment (RSE) Components ....................................................... 34

6.1.1 RSE_SecurityCertificateService .................................................................. 34

6.1.2 RSE_ServiceAdvertisementMgr .................................................................. 36

6.1.3 RSE_MessageRX ....................................................................................... 37

6.1.4 RSE_MessageTX ........................................................................................ 38

6.2 On-Board Equipment (OBE) Components ........................................................ 40

6.2.1 OBE_MessageRX ....................................................................................... 40

6.2.2 OBE_MessageTX ........................................................................................ 41

6.2.3 OBE_Aware ................................................................................................. 43

6.2.4 OBE_GUI .................................................................................................... 47

6.3 MMITSS Roadside Processor (MRP) Components ........................................... 49

6.3.1 MRP_DataMgr ............................................................................................. 49

6.3.2 MRP_TrafficControllerInterface ................................................................... 53

6.3.3 MRP_Aware ................................................................................................ 60

6.3.4 MRP_PerformanceObserver ....................................................................... 63


ii

6.4 MMITSS Central System Components .............................................................. 67

6.4.1 MMITSSUserInterface ................................................................................. 67

6.4.2 System_ConfigurationManager ................................................................... 72

6.4.3 System_N_LevelPriorityConfigurationManager ........................................... 73

6.4.4 Section_PriorityRequestServer ................................................................... 76

6.4.5 Section_Coordinator .................................................................................... 76

6.4.6 Section_PerformanceObserver ................................................................... 77

6.5 Nomadic Device Components (Savari SmartCross) .......................................... 79

6.5.1 Nomadic Priority Request Generator ........................................................... 79

6.5.2 Nomadic Signal Status Receiver ................................................................. 80

6.5.3 Nomadic MMITSS Application ..................................................................... 81

6.5.4 Nomadic_PriorityDataServer ....................................................................... 87

6.5.5 Authorized Special User Service ................................................................. 88

7 Appendices ............................................................................................................. 90

7.1 Acronyms .......................................................................................................... 90

7.2 Appendix A: Savari RSE Product Specification Sheets ..................................... 92

7.3 Appendix B: Savari and Arada OBE Product Specification Sheets ................... 93

7.4 Appendix C: J2735 ASN.1 Specification (Revision Number DSRC_R36) ......... 95

7.5 Appendix D: Intersection Map Description Files (CA) ........................................ 96


iii

List of Figures

Figure 1 MMITSS Physical Architecture (updated) ......................................................... 5

Figure 2 MMITSS Software Components ........................................................................ 8

Figure 3 WAVE Short Message Format (Source: IEEE 1609.3-2010) .......................... 11

Figure 4 WSM Flow ....................................................................................................... 12

Figure 5 Savari On-Board Operation System Architecture Diagram ............................. 13

Figure 6 California MMITSS Implementation Architecture............................................. 14

Figure 7 California MMITSS Software Components ...................................................... 16

Figure 8 Class Diagram of J2735 Library ...................................................................... 18

Figure 9 MAP Data Objects (Source: Ref. 1) ................................................................ 19

Figure 10 Class Diagram of MAP Data Structure .......................................................... 21

Figure 11 Example of Intersection Convex Hulls ........................................................... 22

Figure 12 Call Graph of the J2735 message Decoding Function .................................. 24

Figure 13 Placement of MAP Lane Nodes (Way-Points) ............................................... 25

Figure 14 Class Diagram of GeoUtils ............................................................................ 26

Figure 15 Flow Diagram of Locating on MAP Algorithm ................................................ 27

Figure 16 Vehicle Tracking State Transition Diagram ................................................... 28

Figure 17 Class Diagram of UNIX Socket API .............................................................. 31

Figure 18 MMITSS Internal Message Format ............................................................... 32

Figure 19 Structure of MMITSS Messages ................................................................... 33

Figure 20 Security Service Architecture ........................................................................ 35

Figure 21 RSE_MessageRX Interface Diagram ............................................................ 37

Figure 22 RSE_MessageTX Interface Diagram ............................................................ 39

Figure 23 OBE_MessageRX Interface Diagram ............................................................ 40

Figure 24 OBE_MessageTX Interface Diagram ............................................................ 42

Figure 25 Priority Request State Transition Diagram .................................................... 43

Figure 26 OBE_Aware Interface Diagram ..................................................................... 44

Figure 27 Activity Diagram of OBE_Aware .................................................................... 47

Figure 28 Example of OBE_GUI Interface .................................................................... 48

Figure 29 MRP_DataMgr Interface Diagram ................................................................. 52

Figure 30 Activity Diagram of MRP_DataMgr ................................................................ 53

Figure 31 Structure of Model 2070 Controller Pushing Out Messages ......................... 55

Figure 32 Interface Diagram of MRP_TrafficControllerInterface ................................... 58

Figure 33 Activity Diagram of MRP_TrafficControllerInterface ...................................... 59

Figure 34 MRP_Aware Interface Diagram ..................................................................... 61

Figure 35 Activity Diagram of MRP_Aware ................................................................... 63

Figure 36 MRP_PerformanceObserver Interface Diagram ............................................ 65

Figure 37 Web Application Map of MMITSS Central System ........................................ 68

Figure 38 Performance Observer System Structure...................................................... 69


iv

Figure 39 Sequence Diagram of Interactions between MMITSSUserInterface,

System_Configuration Manager, System_N_LevelPriorityConfigurationManager, and

Section_PerformacneObserver ..................................................................................... 69

Figure 40 Sample key to radar diagrams used to describe traffic performance ............ 70

Figure 41 Dashboard consisting of four radar diagrams and a pie chart for comparing

Peak and Off-peak periods ............................................................................................ 71

Figure 42 User Interface_PerformanceObserver Web Application ................................ 72

Figure 43 MMITSS Configuration Manager Web Page for Dedication and Daisy

Mountain ....................................................................................................................... 73

Figure 44 Interfaces of the System_N_LevelPrioirityConfigurationManager ................. 74

Figure 45 Example of Setting the Priority Policy

System_N_LevePrioirityConfigurationManager ............................................................. 75

Figure 46 Savari SmartCross System Architecture ....................................................... 83

Figure 47 SmartCross App User Interface .................................................................... 83

Figure 48 Ped Mode, Bicycle Mode, and Disabled Traveler Mode ................................ 84

Figure 49 SmartCross Flow Chart ................................................................................. 86


v

List of Tables

Table 1 Message Sets Transmitted between the OBE and the RSE ............................ 12

Table 2 Comparison of Inter-process Tasks with and without Data Manager ............... 30

Table 3 MMITSS Messages .......................................................................................... 32

Table 4 Structure Display Message............................................................................... 46

Table 5 MRP_DataMgr Actions on Messages ............................................................... 50

Table 6 AB3418 Signal Status Message ....................................................................... 56

Table 7 AB3418 Soft-Call Message .............................................................................. 57

Table 8 Performance Observations and Associated Data Resources ........................... 64


Page 1 of 96

1 Purpose of Document

This document contains the detailed level system and software design for the California

portion of the Multi-Modal Intelligent Traffic Signal Systems (MMITSS). The approach

taken to the design has been to create a high level component-based design that

ensures all of the requirements are addressed by one or more components. The

component-based design approach supports both reuse and customization in the

software implementation. Each component can be developed by the team members

such that they can use any desired detailed design approach available to them and

define the interfaces that enable communications with other components. Custom

components can be developed where needed, such as at the controller interface that is

different in California and in Arizona. The common components can be reused in each

test network.

The MMITSS software is a prototype and as such is not intended to be fully ready for

field deployment. However, the software design is such that additional error handling,

management, and monitoring could be added to make it a fully deployable system.

2 Scope of Project

The Multi-Modal Intelligent Traffic Signal System (MMITSS) project is part of the

Connected Vehicle Pooled Fund Study (CV PFS) entitled “Program to Support the

Development and Deployment of Connected Vehicle System Applications.” The CV

PFS was developed by a group of state and local transportation agencies and the

Federal Highway Administration (FHWA). The Virginia Department of Transportation

(VDOT) serves as the lead agency and is assisted by the University of Virginia’s Center

for Transportation Studies, which serves as the technical and administrative lead for the

PFS.

The United States Department of Transportation (USDOT) has identified ten high-

priority mobility applications under the Dynamic Mobility Applications (DMA) program for

the connected vehicle environment where high-fidelity data from vehicles, infrastructure,

pedestrians, etc. can be shared through wireless communications. Three of the

applications (Intelligent Traffic Signal System, Transit Signal Priority, and Mobile

Accessible Pedestrian Signal System) are related to transformative traffic signal

operations. Since a major focus of the CV PFS members – who are the actual owners

and operators of transportation infrastructure – lies in traffic signal related applications,

the CV PFS team is leading the project entitled “Multi-Modal Intelligent Traffic Signal

System” in cooperation with USDOT’s Dynamic Mobility Applications Program.

The MMITSS Phase II project is divided into ten (10) tasks that include Detailed Design,

System Development, System Integration and Laboratory Testing, Field Integration,


Page 2 of 96

Testing, and Evaluation, and finally a demonstration of the system in each of the

Arizona and California test beds. The detailed design effort is documented separately

for the Arizona portion and the California portion of MMITSS. This report describes the

detailed design effort by the California portion of MMITSS.

3 Detailed Design Approach

The detailed design approach is based on a revised version of the high-level design

definition of system architecture and component responsibilities. Each of the physical

nodes has a defined set of system components that may be realized as programs

(processes), configurations, or special physical components. Each component design is

specified as follows:

1. Component Name: node_component

2. Overview of Functionality

3. Requirements

a. Functional Requirements (reference)

b. Derived Requirements

i. Timing

ii. Priority

4. Interfaces

a. Required (input)

b. Provided (output)

5. Functional Specification/Description

a. (activity, state, class, etc. diagrams)

6. Example Applications (as appropriate)

a. (sequence diagram)

7. Unit Test Descriptions (as appropriate - debugging and testing)

8. References (as appropriate)

Item 1 identifies the component name (see Section 4.2 below). Item 2 provides an

overview of the functionality (responsibility) of the component. Item 3 is a reference to

the requirements being satisfied, or partially satisfied, by the component and any

additional derived requirements such as timing (processing time, latency time, etc.) or

process priority requirements (e.g. high, medium, low priority). Item 4 identifies the

required and provided interfaces for the requirement. Item 5 describes the functional

specification of the component including any logic, states, etc. that may be expressed

as activity, state, or class diagrams. Item 6 provides an example interaction of the

component with others (e.g. a sequence diagram) or an example if it helps explain the

operation of the component. Item 7 provides a description of how the components can

be tested. This includes laboratory and field testing. Item 8 provides any references to

documents, papers, etc. that are relevant to the design.


Page 3 of 96

4 High Level System Design

The high level system design is defined by the physical and software components. The

high level design in this document has been updated to reflect development and

changes in both the Arizona and the California test networks since the Phase I High

Level design was completed. The detailed software component designs and

implementations of the California portion of MMITSS are in Sections 5 and 6 below.

The primary changes are in the Physical Architecture shown in Figure 1. The USDOT

provided a Security Certificate Message Server (SCMS), which has been added. This

server is interfaced to the Roadside Equipment (RSE) using IPv6 and is used to provide

security certificates to trusted On-Board Equipment (OBEs). There are two radio

channels between an RSE and an OBE. One radio is assigned to channel 172 and is

dedicated to broadcast basic safety messages (BSM), signal phase and timing

messages (SPaT), and MAP messages. The other radio is used for transactions, such

as an OBE requesting priority (using a Signal Request Message – SRM) or an RSE

providing signal status to a priority eligible vehicle (using a Signal Status Message –

SSM) as well as providing Security Certificates. This radio is assigned to two channels

(split assignment) including channel 178 (Control Channel) and channel 182 (selected

service channel for priority transactions). The transaction channel(s) could be used for

other applications, such as Traffic Information Messages (TIM) and others. Ideally, a

Wave Service Announcement (WSA) would be broadcast on the control channel

(channel 178) notifying vehicles of services that are available on the service channels

(channels 174, 176, 180, and 182). [Implementation Note: At the time of development, a

request has been made for an MMITSS PSID (Provider Service Identifier) to be used for

the Wave Service Announcement, but the request was not granted. Only channel 182 is

used for priority control transaction. The WSA and channel switching were not

implemented].

There are two additional communications interfaces in the revised architecture. The first

is to support wireless communication between the nomadic device and the RSE using

Wi-Fi (802.11a/b/n) or DSRC (based on recent developments towards a DSRC capable

smartphone device). [Implementation Note: nomadic device-to-RSE communications

using Wi-Fi was implemented in the Arizona test network. The California test network

utilized Savari SmartCross application for pedestrian service]. The second is roadside

communications between the sensor system and the MMITSS Roadside Processor

(MRP). This capability was identified in the stakeholder interaction process and includes

an interface to a sensor system that might produce data that exceeds the traditional

vehicle detection (e.g. loop) data that is used by the traffic controller. This data might be

a loop count value, or vehicle trajectories. There are no standards for this type of data,

but the capability might prove useful for MMITSS. [Implementation Note: No data was


Page 4 of 96

collected directly from sensor systems in this implementation, but the capability was

considered in the design].

The other architecture change is that the MMITSS Roadside Processor (MRP) might be

integrated with the RSE. In the original high-level design, there was a desire to support

“thin” RSE radio communications such that the MMITSS intersection level applications

are hosted by a separate Linux-based general-purpose computer. The California test

network adopts this approach (The specification of the selected MRP computer is

described in Section 4.1.1). The Arizona test network adopts the integration approach

as the Savari RSE (version 3.1) device has sufficient processing capacity to support the

MMITSS applications. Making the MMITSS Roadside Processor optional allows

flexibility for the field test and deployment. Both the Savari RSE device and the general-

purpose computer are based on Linux so that portability of the applications can be

accomplished with minimal effort. [Implementation Note: The Arizona implementation

runs on the Savari RSE version 3.1, but the interface between components was

designed using sockets so that they could easily be relocated to an MRP].

4.1 Physical Architecture

The Physical MMITSS architecture is shown in Figure 1 as a UML Deployment

Diagram. This architecture is based on the Conceptual Architecture identified in the

MMITSS Concept of Operations and MMITSS Systems Requirements documents. In

the Unified Modeling Language (UML), nodes are shown as 3D blocks and represent

physical devices that have a processor (at least one), memory, and physical interfaces

(e.g. Ethernet, RS-232, or wireless – 3G/4G, 5.9 GHz DSRC, or other such as CAN-

bus). The basic architecture is applicable at each MMITSS controlled intersection. In a

system that consists of several intersections, each intersection would have an RSE

Radio and traffic control equipment as shown in the deployment diagram.

The nodes have been shaded such that the light colored nodes are part of the

connected vehicle system. Traffic Management and Fleet Management Systems (or

nodes that can be modified or assigned MMITSS responsibilities) and the gray colored

nodes represent the vehicles and travelers. The orange colored nodes are the MMITSS

Central System and Nomadic Traveler Server as described below. These two nodes

may be realized as a single node for the test bed implementations.


Page 5 of 96

Figure 1 MMITSS Physical Architecture (updated)

In this view of the system, there are two types of travelers – motorized vehicles and

non-motorized travelers. Motorized vehicles consist of passenger vehicles, trucks,

transit vehicles, emergency vehicles, and motorcycles. This type of traveler includes

any vehicle that must be licensed to operate on the public roadway. Non-motorized

travelers include pedestrians, bicyclists, and other modes such as equestrians that are

not required to be licensed to operate on the public roadway. These travelers are either

unequipped or equipped, meaning that they have some type of OBE (On-Board

Equipment) or nomadic device that is connected vehicle (or MMITSS) aware and can

operate as part of the traffic control system.

Motorized vehicles can be part of a fleet management system such as a transit

management system, commercial freight management system, emergency vehicle

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.


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


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:

Jetway NF9E-Q77 Mini-ITX Motherboard, Q77 Express vPro iAMT, LGA1155, Ivy Bridge

Enclosure, power supply: Super Case MI-100BK Mini-ITX Case Digital I/O board: PCIe-IIRO-8 CPU chipset, fan: Intel Core i5-3570 Ivy Bridge 3.4GHz

(3.8GHz Turbo Boost) LGA 1155 77W Quad-Core Desktop Processor Intel HD Graphics 2500 BX80637i53570

Disk drive: Seagate Constellation ES ST500NM0011 500GB 7200 RPM 64MB Cache SATA 6.0 Gbps 3.5" Enterprise Internal Hard Drive -Bare Drive

System memory: Transcend 8GB (2 x 4GB) 240-Pin DDR3 SDRAM DDR3 1333 Desktop Memory Model JM1333KLN-8GK

Operating System: Ubuntu Server 12.04.2 LTS

4.1.2 RSE Radio

Both the Arizona and the California test networks use the Savari StreetWave version

3.1 RSE units. The units support two 5.9 GHz DSRC radios and an Ethernet interface

for communications. The product spec sheets are available in Appendix A: Savari RSE

Product Specification Sheets.

4.2 Software Components

Figure 2 shows the primary software components of MMITSS, which are identified in the

high level system design.


Page 8 of 96

Figure 2 MMITSS Software Components


Page 9 of 96

The software is grouped according to the deployment nodes. The OBE (on-board

equipment) is deployed on each equipped vehicle. The OBE_name software

components provide the functionality required of the OBE. The OBE communicates with

the RSE (roadside equipment) over one or more of the DSRC WAVE channels. The

RSE_name software components provide the key wireless communication behaviors

including sending and receiving messages, as well as the Service Advertisement and

Security Certificate services.

The MMITSS Roadside Processor (MRP) communicates with the RSE using the local

Ethernet network, and with the MMITSS Central System and the Nomadic Traveler

Service using a combination of field and backhaul communications. In Arizona’s

Maricopa County SMARTDrive network a fiber optic local network is provided between

all of the test intersections and a leased T-1 backhaul connection is provided from the

field to the MCDOT traffic operations center (TOC). In the California test network, field

communications is managed through a field master that communicates with each

intersection controller over multi-drop serial communications, and a 4G LTE mobile

backhaul is provided for each test intersection to communicate with the MMITSS Central

System and the Nomadic Traveler Service. The MRP also communicates with the

intersection traffic signal controller, through NTCIP over Ethernet communications (AZ)

and AB3418 over serial RS-232 communications (CA). The MRP hosts software

components that perform the core intersection level functions of MMITSS. These

components include the MAP and SPaT broadcast manager, the equipped vehicle

tracker, the priority request server, traffic control logic, the interface to the traffic signal

controller (AZ-NTCIP, CA-AB3418 ), and the components that communicate status to the

Nomadic Traveler Service including status. [Implementation Note: The

MRP_NomadicDeviceTracker component was removed from the component design as

its functionality is realized by the Nomadic Traveler Service]. The MRP also hosts the

performance observer component.

The MMITSS Central System hosts software components that provide a user interface,

configuration manager, N-level priority policy configuration manager, and section level

priority server and signal coordination. [Implementation Note: The section level priority

server and the signal coordination components were not implemented as they require a

higher penetration rate of connected vehicles, which was not available when this

document was developed]. The MMITSS Central system also hosts the section level

performance observers. The System_PerformanceObserver component was removed

from the component design. It was decided that section level performance was more

meaningful at this stage in the development of MMITSS.

The Nomadic Traveler Service hosts two software components that provide the priority

data service that relays intersection data (e.g. MAP and SPaT data) to nomadic devices

and receives requests for service/priority from nomadic devices. The Nomadic Traveler


Page 10 of 96

Service also hosts the security and authorization service for nomadic devices that

ensures these devices are associated with valid users and are authorized to receive

special service if the user is a disabled pedestrian. [Implementation Note: The Savari

SmartCross SBIR (Small Business Innovation Research) project was leveraged to

achieve most of the pedestrian service. The SmartCross application uses cellular

technology for communications between a nomadic device and the Nomadic Traveler

Service, and uses backhaul for communications between the Nomadic Traveler Service

and the MRP. In the Arizona test network, a simple pedestrian application, called the

MMITSS Pedestrian App, was developed separately from the SmartCross application.

The MMITSS Pedestrian App uses Wi-Fi for direct communications between a nomadic

device and the MRP. The AuthorizedSpecialUserService was not implemented in both

test networks].

The Nomadic device is assumed to be a smart phone, Android based, and hosts an

application (app) that uses two components. One component requests service/priority

and the other collects and makes status information available for display on the app.

4.3 Overview of WAVE Communications

WAVE is a means of communicating between vehicles (OBEs/ASDs) and between

roadside systems and vehicles. WAVE messaging uses the DSRC protocol, originally

standardized as IEEE 802.11p-2010, and is now incorporated in IEEE 802.11-2012.

When within the communication zones, the applications of MMITSS running on the MRP

and OBE exchange information with each other to perform the MMITSS Traffic Control

service.

In the WAVE environments, the RSE_ServiceAdvertisementMgr broadcasts 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 the service data (e.g. SRM - Signal Request Message and SSM -

Signal Status Message). 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. [Implementation

Note: The RSE_ServiceAdvertisementMgr was not implemented as a software

component, but rather is part of the Savari IEEE 1609 stack that is a standard part of the

RSE operating system. At the time of development, the IEEE 1609 technical committee

was communicating with the SAE DSRC technical committee to determine the proper

operating of the Wave Service Advertisement. A request has been made for an MMITSS

PSID (Provider Service Identifier), but the request was not granted].

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


Page 11 of 96

and receiving SSMs on the SCH indicated in the WSA. The

RSE_SecurityCertificateService manages trust between OBEs and the RSEs to ensure

that only the trusted, eligible OBEs/ASDs can join the MMITSS traffic control service.

[Implementation Note: The RSE_SecurityCertificateService was not implemented as a

software component, but rather is part of the Savari IEEE 1609 stack that is a standard

part of the RSE operating system].

Over-the-air data exchange between OBEs and RSEs is managed by the

OBE/RSE_MessageTX and OBE/RSE_MessagesRX, using the WAVE Short Message

Protocol (WSMP). Over-the-air messages are transmitted in the forms of WAVE Short

Messages (WSMs). The WSM format consists of a WSMP header followed by a

variable-length payload (WSM data) as illustrated in Figure 3. The mandatory PSID

(Provider Service Identifier) identifies the service that the WSM payload (e.g., BSM,

SRM, MAP, SPaT, SSM, etc.) is associated with. Each type of payload must have a

unique PSID so the receiving end knows how to process it.

Figure 3 WAVE Short Message Format (Source: IEEE 1609.3-2010)

The message sets transmitted between the OBE and the RSE and their channel

configurations are summarized in Table 1. For the MMITSS prototype, channel 182 has

been selected as the operating channel for transmitting SRMs and SSMs.

The information flow for WSM data is illustrated in Figure 4. To transmit a WSM, the

OBE/RSE_MessageTX first registers with the WAVE Management Entity (WME) and

provides the content of the WSM plus additional radio control parameters, including

channel number, data rate and transmit power. To receive WSMs, the

OBE/RSE_MessageRX registers with the WME for a list of PSIDs that it would want to

receive. On receipt of a WSM, the WME compares the PSID in the WSMP header with

the registered list of PSIDs and passes the matched WSM to the

OBE/RSE_MessageRX.


Page 12 of 96

Table 1 Message Sets Transmitted between the OBE and the RSE

Message Abbr. From Frequency To Radio Channel PSID (Hex)

WAVE Service

Announcement WSA RSE 1 Hz OBE/ASD Ath0 178 -

MAP MAP RSE 1 Hz OBE/ASD Ath1 172 0xBFF0

Signal Phase and

Timing SPAT RSE 10 Hz OBE/ASD Ath1 172 0xBFE0

Signal Status

Message SSM RSE 1 Hz OBE/ASD Ath0

174,176,

180 or 182 0x80

Basic Safety

Message BSM OBE/ASD 10 Hz RSE Ath1 172 0x20

Signal Request

Message SRM OBE/ASD ASYNC RSE Ath0

174,176,

180 or 182 0x40

Security

Both ASYNC Both Ath0 174,176,

180 or 182 -

Figure 4 WSM Flow

The RSEs and OBEs/ASDs have to support communication between the applications

running on them and the external world. To ensure this, the WAVE messaging

architecture should be capable of providing message agnostic wireless data

WME

WMSPOBE/RSE_MessageTX

Request sending a WSM

WME

WMSPRSE/OBE_MessageRX

Confirm Confirm

Request receiving WSMs

WSM arrival indication

WSM Flow


Page 13 of 96

transmission or reception services to other applications on it. Savari StreetWave and

MobiWave devices run Savari On-Board Operating System (SOBOS), which is a custom

Linux distribution. A high level architecture description of SOBOS is shown in Figure 5.

Figure 5 Savari On-Board Operation System Architecture Diagram

The SOBOS architecture consists of 4 layers. The layers, excluding the application layer,

are common for all applications and based on a set of services defined in software

libraries. The Kernel layer handles the hardware level device drivers for the radios and

wireless devices such as DSRC, Wi-Fi and GPS. All messages on the device are

sent/received via these devices. The services layer handles the messaging services

A

P

P

L

I

C

A

T

I

O

N

S

L

I

B

R

A

R

I

E

S

S

E

R

V

I

C

E

S

K

E

R

N

E

APPLICATION

J2735

DSRC/Wi-Fi

1609.4 GPS 1609.2

BSM

ENC/DEC

TIM

ENC/DEC

MAP

ENC/DEC

SPAT

ENC/DEC

SRM

ENC/DEC

SSM

ENC/DEC

WME RADIO GPSAPI P1609.2 NTCIP SOCKET

Application Logic

1609.3 1609.2 GPS

GPS DRIVER


Page 14 of 96

such as security. Messages are processed by individual applications. These messages

are handled by libraries based on the message type and the appropriate protocols. The

application layer consists of applications that make use of the libraries to get the

messages that they want to process further.

5 California MMITSS Implementation

This California MMITSS implementation followed the high level system design described

in Section 4. The California implementation is centered with a MMITSS Roadside

Processor (MRP). The MRP hosts the core MMITSS functions and the software that

interface with the traffic signal controller, RSE, MMITSS Central System, and the

Nomadic Traveler Server, as it is illustrated in Figure 6.

Figure 6 California MMITSS Implementation Architecture

Due to the MRP-centered architecture, the California MMITSS implementation chose the

use of an MRP data manager component (i.e., MRP_DataMgr) to be the single sink of

data from various sources and the single source for sharing the data among MRP

components such that data from different sources can be used synchronously. The use


Page 15 of 96

of an MRP data manager would also allow it to support a broader range of CV functions

beyond MMITSS (see Section 5.3.1 below).

As the MRP is physically separated from the RSE, the applications running on the MRP

cannot use RSE’s J2375 library for encoding and decoding J2735 messages. The RSE’s

J2735 library is not portable to the MRP, therefore the California implementation

developed its own J2735 library (see Section 5.2.3 below).

The California test network includes several larger size intersections, which caused the

size of MAP messages exceed the max allowed message length. The California

implementation therefore used a different approach to track vehicles on a MAP, which

requires less way-points to define a MAP and can make the MAP messages within the

required length limit (see Section 5.2.4 below). As J2735 message encoding/decoding

and tracking a vehicle on a MAP are common basic functions for any applications

running on the OBE or MRP, the California implementation wraps these functions in a

library class that can be used in both the OBE and MRP (see Section 5.2 below). As a

result, the California implementation regrouped some of the software components

identified in the high level system design (see Figure 2 above).

5.1 California MMITSS Software Components

The primary software components of California MMITSS implementation is shown in

Figure 7. The functionalities of OBE_MAP_SPaT_Receiver, OBE_BSMDataTransmitter

and OBE_PriorityRequestGenerator are grouped into one component (e.g. OBE_Aware).

Regardless of whether the OBE is eligible for priority or not, the functionalities of

processing MAP and SPaT messages and tracking the vehicle on the MAP are desirable

features. With a single component that provides these functionalities, it could be used for

other vehicle-centered applications.

The functionalities of MRP_MAP_SPaT_Broadcast and MRP_SignalStatus_Nomadic are

implemented as part of the MRP_DataMgr component, as the MAP and SPaT messages

broadcast over the air are the same messages provide to the pedestrian data server (i.e.

Nomadic_PriorityDataServer).

To support MMITSS, Caltrans Division of Traffic Operations modified TSCP (Traffic

Signal Control Program) to allow phase calls, extensions, and priority request with newly

defined and implemented AB3418 messages. The protocol requires the MRP to send the

call/extension/priority commands at a rate of 20Hz to avoid dropping a control command.

Therefore the functionalities of MRP_PriorityRequestServer and MRP_TrafficControl are

combined as one component (e.g. MRP_Aware) in the California implementation.


Page 16 of 96

Figure 7 California MMITSS Software Components

cmp MMITSS Software Overv iew

MRP_DataMgr

MRP_Aware

MRP_PerformanceObserver

MMITSS Roadside Processor (MRP)

OBE_MessageRX

OBE_Aware

OBE

AuthorizedSpecalUserService

Nomadic_PriorityDataServer

Nomadic Traveler Service

Nomadic_SignalStatusReciever

NomadicMMITSSApp

Nomadic_PriorityRequestGenerator

Section_PerformanceObserver

System_N_LevelPriorityConfigurationManager

Section_PriorityRequestServer

System_ConfigurationManager

MMITSS Central System

Nomadic Device

RSE_MessageTX

RSE_ServiceAdvertisementMgr

RSE

OBE_Webserver

MRP_TrafficControllerInterface

MMITSSUserInterface

Section_Coordinator

OBE_MessageTX

MRP_Webserver

RSE_MessageRX


Page 17 of 96

5.2 J2735 Library

The data elements, data frames, and messages in SAE J2735 message sets over DSRC

are defined in terms of a formal language called Abstract Syntax Notation One (ASN.1).

The J2735 dictionary standard also calls for use of the Distinguished Encoding Rules

(DER) to translate the ASN.1 into a concrete data stream. The WSM payload transmitted

over-the-air is always encoded in the ASN DER style. Savari RSE and OBE do provide a

J2735 library for encoding and decoding J2735 messages (see Figure 5). However,

applications running on the MRP cannot directly use this library and this library is not

portable to the MRP. The California implementation therefore developed its own library

for encoding and decoding J2735 messages, including BSM, SRM, SPaT, MAP and

SSM.

Both the MRP and the OBE components require a common functionality of locating a

vehicle on a MAP. The OBE component requires this functionality to associate SPaT

messages with MAP messages (an OBE could simultaneously receive SPaT and MAP

messages from multiple intersections), and when it is eligible for signal priority, to

generate signal request messages (SRMs). The MRP component requires this

functionality for MMITSS traffic/priority control and performance measures. The

California implementation chose to implement this function as part of the J2735 library so

the same J2735 message encoding/decoding and vehicle tracking functions can be used

on both the MRP and OBE.

The class diagram of the J2735 Library (e.g. J2735Lib) is illustrated in Figure 8. The

J2735Lib class is created by reading the intersection MAP description file(s) (see Section

5.2.1) and initializing the MapDataStruct object (see Section 5.2.2). An MRP always

keeps the latest version of the intersection MAP description file. An OBE stores the

intersection MAP description file when it passed an RSE. When within the DSRC

communication zones, the OBE checks the version of the MAP description file that was

stored locally against the version of the over-the-air MAP messages. If a newer version

is detected, the OBE calls the updateMapDataStruct function to update the

MapDataStruct for the use of real-time tracking the vehicle on the MAP and calls the

saveNmap function to convert the over-the-air MAP message into the intersection MAP

description file, which is stored locally for the future use.

The sets of encode_ and decode_ functions are for encoding and decoding J2735

messages, respectively (see Section 5.2.3). The locateVehicleInMap function projects

the vehicle geolocation (latitude, longitude and elevation) and tracks its movement

(speed and heading) on the MAP, and returns object vehicleTracking_t which contains

intersectionID, laneID and the projected point along the lane. The updateLocationAware

function calculates the distance from the projected point to the intersection stop-line and

gets the connection lanes and associated maneuvers from the current laneID. The


Page 18 of 96

updateSignalAware function associates the intersectionID and laneID with the SPaT

messages to get the current signal state and the remaining time (see Section 5.2.5).

Figure 8 Class Diagram of J2735 Library

class AsnJ2735Lib

AsnJ2735Lib

- mpMapData: MapDataStruct*

+ AsnJ2735Lib(char*)

+ ~AsnJ2735Lib()

+ decode_bsm_payload(char*, size_t, BSM_element_t*): bool {query}

+ decode_mapdata_payload(char*, size_t, Mapdata_element_t*): bool {query}

+ decode_payload(char*, size_t, MSG_UNION_t*): bool {query}

+ decode_spat_payload(char*, size_t, SPAT_element_t*): bool {query}

+ decode_srm_payload(char*, size_t, SRM_element_t*): bool {query}

+ decode_ssm_payload(char*, size_t, SSM_element_t*): bool {query}

+ decode_wsmp_header(wsmp_header_t *, uint8_t*, size_t): size_t {query}

+ encode_bsm_payload(BSM_element_t*, char*, size_t): ssize_t {query}

+ encode_mapdata_payload(uint32_t, char*, size_t): ssize_t {query}

+ encode_spat_payload(SPAT_element_t*, char*, size_t): ssize_t {query}

+ encode_srm_payload(SRM_element_t*, char*, size_t): ssize_t {query}

+ encode_ssm_payload(SSM_element_t*, char*, size_t): ssize_t {query}

+ encode_wsmp_header(wsmp_header_t *, uint8_t*, size_t): size_t {query}

+ getIntersectionNums(): size_t {query}

+ getMapVersion(uint32_t): uint8_t {query}

+ locateVehicleInMap(GeoUtils::connectedVehicle_t&, GeoUtils::vehicleTracking_t&): bool {query}

+ readNmap(char*): void

+ saveNmap(char*): void {query}

+ updateLocationAware(GeoUtils::vehicleTracking_t&, GeoUtils::locationAware_t&): void {query}

+ updateMapDataStruct(Mapdata_element_t*): void

+ updateSignalAware(map<uint32_t,SPAT_element_t>&, GeoUtils::locationAware_t&, GeoUtils::signalAware_t&): void {query}

NmapData::MapDataStruct

- mpIntersection: std::vector<IntersectionStruct>

«struct»

MSG_UNION_t

+ type: MsgEnum::msg_enum_t::MSGTYPE

«union»

MSG_UNION_t::<anonymous>

+ bsm: BSM_element_t

+ mapdata: Mapdata_element_t

+ spat: SPAT_element_t

+ srm: SRM_element_t

+ ssm: SSM_element_t

«enumeration»

MsgEnum::MSGTYPE

UNKNOWN_PKT = 0

BSM_PKT = 1

SPAT_PKT = 2

MAP_PKT = 3

SRM_PKT = 4

SSM_PKT = 5

+mpMapData

+type


Page 19 of 96

5.2.1 MAP Description File

The MMITSS project uses SAE J2735 standard to construct the MAP1 [Implementation

Note: the SAE J2735 standard available at the time of this development was version

SAE J2735-Nov 2009. The latest standard is version SAE J2735-Jan 2016. The J2735

message encoding and decoding functions may need to be revised to reflect the current

version]. The structure of data objects that comprise the MAP payload is illustrated in

Figure 9.

Figure 9 MAP Data Objects (Source: Ref. 1)

1 Battelle Memorial Institute, Signal Phase and Timing and Related Message Binary Format (BLOB) Details, DRAFT, Rev. c, 2012

<Lane Number> <Maneuver Code><Connection>

<Eastern Offset> <Elevation Offset><Node> <Northern Offset> <Width>

<Node> <Node><Node List>

<Lane Number> <Lane Attributes> <Width><Lane> <Lane Type>

<Lane><Approach>

<Egress><Width>

<Latitude> <Longitude> <Elevation><Ref. Point>

<GID><Map Message> <Message Attributes>

<Barrier Attributes> <Width><Barrier> <Node List>

Pedestrian

Computed<Ref. Lane>

<Node List>

<Node List>

<Lateral Offset> <Connection>

Vehicle/Special

<Barrier>

<Ref. Point>

<Approach>

<Geometry> <Egress>

<Geometry><GID> <Intersection ID>


Page 20 of 96

The MMITSS team defined the format of the intersection MAP description file that

contains all the information needed for constructing J2735 MAP messages, as follows:

MAP_Name Intersection_Name.nmap

RSU_ID Intersection_Name

MAP_Version xxx

IntersectionID xxxx

Intersection_attributes xxxxxxxx /*Attributes of the intersection, 8 bits */

Reference_point xx.xxxxxxx xxx.xxxxxxx xxxx /*lat, long, evelation(decimeter)*/

No_Approach xx /*number of approaches*/

Approach 1

Approach_type x /*1: approach, 2: engress, 3: barrier, 4: crosswalk*/

No_lane x

Lane 1.1 x /*x – the signal phase that controls the lane movement*/

Lane_ID 1

Lane_type x /* Veh Lane, Computed Lane, Ped Lane, Special Lane, Barrier*/

Lane_attributes xxxxxxxxxxxxxxxx /*Attributes of the lane, 16 bits*/

Lane_width xxx /*in centimeters */

No_nodes x /*number of lane nodes*/

1.1.1 xx.xxxxxxx xxx.xxxxxxx /*latitude longitude*/

1.1.2 xx.xxxxxxx xxx.xxxxxxx

……

No_Conn_lane x /*connection lanes*/

x.x x

x.x x

end_lane

Lane 1.2 x /*x – the signal phase that controls the lane movement*/

……

end_lane

end_approach

Approach 2

……

end_approach

end_map

A MAP description file was created for each of the test intersections in the Arizona and

the California test networks. Google Earth tools were used for obtaining the coordinates

of the intersection reference point (e.g. the center of the intersection) and lane nodes (a

sequence of way-points along the center of each traffic lanes and pedestrian

crosswalks). Testing has shown that the map data generated with Google Earth tools is

accurate for the MMITSS traffic control applications. Map descriptions files for the

California test intersections plus the Richmond Field Station intersection are in Appendix

D: Intersection Map Description Files (CA).

5.2.2 MAP Data Structure

When creating an instance of the J2735Lib class, the MAP description files are

converted into the MapDataStruct object. The class diagram of MapDataStruct is


Page 21 of 96

illustrated in Figure 10. An MRP may only include one IntersectionStruct object and an

OBE could include multiple IntersectionStruct objects.

Figure 10 Class Diagram of MAP Data Structure

Several parameters are calculated when initiating the MapDataStruct object, including:

• Intersection geographic coordinate conversion matrix (e.g. enuCoord)

It is more intuitive and practical to track a vehicle on the local earth East-North-Up

(ENU) Cartesian coordinate system. The enuCoord object contains the

class NmapData

«enumeration»

laneType

TRAFFICLANE = 1

CROSSWALKLANE = 4

«enumeration»

approachType

APPROACH = 1

EGRESS

BARRIER

CROSSWALK

«struct»

ConnectStruct

+ intersectionId: uint32_t

+ laneId: uint8_t

+ laneManeuver: MsgEnum::maneuverType

«struct»

NodeStruct

+ geoNode: GeoUtils::geoRefPoint_t

+ heading: uint16_t

«struct»

LaneStruct

+ attributes: std::bitset<16>

+ controlPhase: uint8_t

+ id: uint8_t

+ mpConnectTo: std::vector<ConnectStruct>

+ mpNodes: std::vector<NodeStruct>

+ type: maneuver_enum_t::laneType

+ width: uint16_t

«struct»

ApproachStruct

+ id: uint8_t

+ mpLanes: std::vector<LaneStruct>

+ mpPolygon: std::vector<GeoUtils::point2D_t>

+ type: maneuver_enum_t::approachType

«struct»

IntersectionStruct

+ attributes: std::bitset<8>

+ enuCoord: GeoUtils::enuCoord_t

+ geoRef: GeoUtils::geoRefPoint_t

+ id: uint32_t

+ mapVersion: uint8_t

+ mpApproaches: std::vector<ApproachStruct>

+ mpPolygon: std::vector<GeoUtils::point2D_t>

+ name: std::string

+ radius: uint32_t

MapDataStruct

- mpIntersection: std::vector<IntersectionStruct>

«struct»

GeoUtils::geoRefPoint_t

+ elevation: int32_t

+ latitude: int32_t

+ longitude: int32_t

«enumeration»

MsgEnum::maneuverType

UNKNOWN = 0

UTURN = 1

LEFTTURN

RIGHTTURN

STRAIGHTAHEAD

STRAIGHT

«struct»

GeoUtils::enuCoord_t

+ pointECEF: GeoUtils::point3D_t

+ transMatrix: GeoUtils::transMatrix_t

«struct»

GeoUtils::transMatrix_t

+ dCosLat: double

+ dCosLong: double

+ dSinLat: double

+ dSinLong: double

«struct»

GeoUtils::point3D_t

+ x: double

+ y: double

+ z: double

«struct»

GeoUtils::point2D_t

+ x: int32_t

+ y: int32_t

+transMatrix

+mpPolygon

+enuCoord

+mpConnectTo

+type

+laneManeuver

+geoNode

+mpNodes

+geoRef

+pointECEF

+mpIntersection

+mpApproaches

+type

+mpPolygon

+mpLanes


Page 22 of 96

parameters for the conversion from the geographic coordinate system (latitude,

longitude and elevation) to the ENU coordinate system.

• Intersection MAP radius

This is the maximum distance between lane nodes and the intersection reference

point. It is used for fast determining whether a vehicle is inside or outside an

intersection MAP (track initiation).

• Convex hull of the intersection box (e.g. intersection mpPolygon)

The convex hull of the intersection box is formed from land nodes located at the

intersection stop-lines. It is used to rapidly determine whether a vehicle is inside

or outside an intersection box (track initiation).

• Convex hull of intersection approaches (e.g. approach mpPolygon)

The convex hull of an intersection approach (ingress or egress) is formed from

lane nodes on the approach. It is used to rapidly determine whether a vehicle is

inside or outside an approach box (track initiation).

• Driving direction at lane nodes (e.g. node heading)

Lane node heading is the direction (reference to North) between two adjacent

nodes on the same lane, pointing to the driving direction. It is used for checking

against with vehicle’s GPS heading to ensure the vehicle is matched with the

correct approach/lane (track initiation and maintenance).

The convex hulls (intersection box and approach boxes) are also used for geofencing.

Vehicles that are outside the convex hulls are excluded for projecting them on the map.

Figure 11 Example of Intersection Convex Hulls


Page 23 of 96

An example of formed convex hulls is illustrated in Figure 11. The intersection is El

Camino Real and Stanford Ave in Palo Alto, CA. The yellow polygon is the convex hull of

the intersection box, and the 8 green polygons are the convex hulls on each of the 8

intersection approaches.

5.2.3 Encoding and Decoding J2735 Messages

Encoding/decoding J2735 messages was developed based on J2735 ASN.1

Specification, revision number DSRC_R36. The ASN.1 source code is available online

(http://www.sae.org/standardsdev/dsrc/usa_2009/DSRC_R36_Source.ASN) and in

Appendix C: J2735 ASN.1 Specification (Revision Number DSRC_R36).

The implemented J2735 library provides the following functions for other MMITSS

components to encode J2735 messages:

ssize_t encode_bsm_payload(const BSM_element_t* ps_bsm,

char* encode_buffer,

const size_t bufsize);

ssize_t encode_srm_payload(const SRM_element_t* ps_srm,

char* enode_buffer,


ssize_t encode_spat_payload(const SPAT_lement_t* ps_spat,



ssize_t encode_ssm_payload(const SRM_element_t* ps_ssm,



ssize_t encode_mapdata_payload(const uint32_t intersectionId,



An application fills the data structure (e.g. BSM_element_t, defined in a header file –

dsrcMsgs.h). The encoding function (e.g. encode_bsm_payload) converts the given

structure into an ASN DER encoded buffer (e.g. encode_buffer) and returns the length of

the endcode_buffer. Encoding of map message is performed by converting the

intersectionStruct (see Section 5.2.2 above) into the encode_buffer.

Function for decoding J2375 messages is as follows:

bool decode_payload(const char* decode_buffer,

const size_t bufsize,

MSG_UNION_t* ps_msg);

An application passes the byte stream received over the air into the decode_buffer, the

decoding function first decodes the WSMP header for the PSID, then calls the

corresponding message decoder which fills the message data structure. The call graph

of the decode_payload function is illustrated in Figure 12.


Page 24 of 96

Figure 12 Call Graph of the J2735 message Decoding Function

5.2.4 MAP for Large Intersections

Both the RSEs and OBEs require that the length of WSM data (payload) not exceeds the

max length of 1,400 bytes. Although longer MAP messages can be accommodated by

fragmenting the messages and sending more one WSM, it is more convenient to keep

the MAP message in one WSM when it is possible. The California test network includes

several large intersections which have 3 through lanes plus 2 left-turn lanes on each

intersection approach. Special attention must be paid on the placement of the lane

nodes such that the lane nodes are adequate to describe the geometry of the

intersection, suitable for applications to locate/track a vehicle on a map, and the number

of the lane nodes would keep the size of MAP messages within the required limit.

Figure 13 shows an example of the placement of lane nodes (way-points). The illustrated

approach has 2 through lanes and 1 left-turn lane. Blue dots are lane nodes (way-points)

and the red dot represents a vehicle (Figure 13(a)). When using the nearest way-point as

the reference to match vehicle’s location with a lane, it would require two additional way-

points (green dots in Figure 13(b)), otherwise the vehicle is matched with the left-turn

lane rather than the middle through lane. The California implementation uses the

approach of projecting vehicle’s location onto lane (point-to-line projection, see Figure

13(c)) to track a vehicle on a map. The lane on which the vehicle is located is determined

by the one with the minimum (perpendicular) distance to the projected lane (d in Figure

13 (c)). Thus fewer way-points will be required. The point-to-line projection also provides

automatic geofencing by adding a maximum (perpendicular) distance to the curb lane.

[Note: The California implementation uses the value of curb-lane width for geofencing].


Page 25 of 96

Figure 13 Placement of MAP Lane Nodes (Way-Points)

5.2.5 Tracking Vehicle Location on a MAP

The class GeoUtils wraps basic geographic calculations, including coordinate conversion

between different geographic coordinate systems, calculation of the distance and

direction between two geo-points, projection of a geo-point onto a lane segment, and

detection of whether a geo-point is inside or outside a convex hull. The class diagram of

GeoUtils is illustrated in Figure 14.

Inputs to the locateVehicleInMap function include vehicle geolocation (latitude, longitude

and elevation), its movement state (speed and heading), and the last projection result

(e.g. isVehicleInMap and vehicleTrackingState which include intersectionID, laneID and

the projected point along the lane). On the MAP, vehicle geolocation and movement data

are obtained from the BSMs. On the OBE, the data are obtained from the on-board GPS

device. Outputs of the locateVehicleInMap function are the updated projection result.

(a) (b)

Way-pointsWay-points

Car

Way-points

Car

Additional

way-points

Car

(c)


Page 26 of 96

Figure 14 Class Diagram of GeoUtils

The flow diagram of locateVehicleInMap function is illustrated in Figure 15.

class GeoUtils

«Enumeration»

locationType

NOT_IN_MAP

INSIDE_INTERSECTION_BOX

ON_APPROACH

ON_EGRESS

«struct»

geoPoint_t

+ elevation: double

+ latitude: double

+ longitude: double

«struct»

motion_t

+ heading: double

+ speed: double

«struct»

projection_t

+ d: double

+ length: double

+ t: double

«struct»

laneProjection_t

+ nodeIndex: uint8_t

+ proj2segment: projection_t

«struct»

intersectionTracking_t

+ approachIndex: uint8_t

+ intersectionIndex: uint8_t

+ laneIndex: uint8_t

+ vehicleIntersectionStatus: locationType

«struct»

vehicleTracking_t

+ intsectionTrackingState: intersectionTracking_t

+ laneProj: laneProjection_t

«struct»

dist2go_t

+ distLat: double

+ distLong: double «struct»

connectTo_t


+ laneId: uint8_t

+ laneManeuver: maneuverType

«struct»

locationAware_t

+ connect2go: std::vector<connectTo_t>

+ controlPhase: uint8_t

+ dist2go: GeoUtils::dist2go_t


+ laneId: uint8_t

«struct»

signalAware_t

+ clearanceIntv: uint16_t

+ currState: vehicular

+ stateConfidence: confidentce

+ timeToChange: uint16_t

«struct»

connectedVehicle_t

+ geoPoint: geoPoint_t

+ id: uint32_t

+ isVehicleInMap: bool

+ motionState: motion_t

+ timestamp: long

+ vehicleLocationAware: locationAware_t

+ vehicleSignalAware: signalAware_t

+ vehicleTrackingState: vehicleTracking_t

«Enumeration»

MsgEnum::maneuverType

UNKNOWN = 0

UTURN = 1

LEFTTURN

RIGHTTURN

STRAIGHTAHEAD

STRAIGHT

«Enumeration»

MsgEnum::vehicular

UNKNOWN

GREEN

YELLOW

RED

FLASHING

«Enumeration»

MsgEnum::confidentce

UNKNOWN_ESTIMATE

MINTIME

MAXTIME

TIME_LIKELY_TO_CHANGE

+dist2go

+geoPoint

+vehicleIntersectionStatus

+proj2segment

+vehicleTrackingState

+intsectionTrackingState

+motionState

+vehicleLocationAware

+currState

+connect2go

+vehicleSignalAware

+stateConfidence

+laneProj

+laneManeuver


Page 27 of 96

Figure 15 Flow Diagram of Locating on MAP Algorithm

Steps for initiating a track are described below:

I1. Find the set of intersections that the vehicle is inside the intersection MAP, by

checking the distance from the vehicle geolocation to the intersection reference

point against the intersection MAP radius;

I2. For each of the intersections that the vehicle is inside, find the convex hulls that

the vehicle is inside;

I3. For each of the convex hulls that the vehicle is inside, project vehicle geolocation

onto the lanes, and get the laneID and the projected point that has the minimum

distance from the vehicle geolocation to the lane among all lanes on the

approach. Vehicle speed and heading are used for the point-to-line projection to

ensure vehicle heading is along the lane node heading; and

I4. In the case that the vehicle geolocation is projected onto two MAPs (when there is

an overlap between the egress lane of an upstream intersection and the ingress

act locateVehicleInMap

Start

isVehicleInMap

IsEmptySet

IsSetEmpty

locateVehicleOnApproach

getNearedIntersections

getNearedApproaches

isEgressLane

getEgressConnect2Ingress

isSetEmpty

End

isInsideGeofenceZones

[No]

[No - ON_APPROACH /

INSIDE_INTERSECTION_BOX]

[Yes]

[No - ON_APPROACH]

[Yes]

[Yes - NOT_IN_MAP]

[Yes - NOT_IN_MAP]

[No]

[No - NOT_IN_MAP]

[No]

[Yes - ON_EGRESS]

[Yes]


Page 28 of 96

lane of the downstream intersection), return the projection result on the ingress

lane.

Steps for maintaining an established track are as follows:

M1. Start with the last projection result (e.g. intersectionID, laneID and the projected

point along the lane) and move the projection forward along the lane. The same

point-to-line method as step I3 above is used. As a vehicle could change lanes,

the projection lane is determined as the one that has the minimum distance from

the vehicle geolocation to the lane. Moving forward the project follows the

transition of vehicleIntersectionStatus state as illustrated in Figure 16; and

M2. When the projection lane is an egress lane, repeat steps I1 to I3 above to

determine whether the vehicle is also on an ingress lane of another intersection.

Return the projection result on the ingress lane (if it exists) otherwise the project

result on the egress lane. At closely spaced intersections, this step ensures a

quick detection of state transit from ON_EGRESS at an upstream intersection to

ON_APPROACH at the downstream intersection.

Figure 16 Vehicle Tracking State Transition Diagram

5.3 Software Component Interfaces

The interfaces between software components allows data to be transferred between

suppliers and consumers.

stm vehicleIntersectionStatus

NOT_IN_MAP

ON_APPROACH INSIDE_INTERSECTION_BOX

ON_EGRESS

[Moved to Ingress Lane of the

Downstream Intersection]

[Left Geofencing Area]

[Entered Geofencing Area]

[Left Geofencing Area]

[Entered Geofencing

Area]

[Passed Outbound Line]

[Passed the Stop Line]


Page 29 of 96

5.3.1 MRP Data Manager

The MRP receives multiple messages from different physical components, such as over-

the-air DSRC messages from the RSE, pedestrian SRMs from the nomadic device, and

configuration, signal status and detection data from the traffic controller. These

messages arrive asynchronously and are processed by different MRP components, e.g.

BSMs for vehicle tracking, SRMs and controller data for priority control, etc. The decision

of MMITSS traffic/priority control is based on the combined vehicular, pedestrian and

controller data. The use of a data manager (e.g. MRP_DataMgr) for routing synchronized

data to the different software modules would be preferable to independently connecting

these modules. The data manager would connect to other software modules with a

socket pair. Data sources, such as the MRP_TrafficControllerInterface, would push

timestamped data into the data manager. The data manager would push synchronized

data into data sinks, such as the MRP_PerformanceObserver. Modules that perform

calculations, such as MMITSS traffic/priority control decisions, would be based on

synchronized data.

A datum is timestamped when received by the data manager; it is again timestamped by

a module when that datum is acted upon. These two timestamps, together with the

datum itself and an identifier of the module using the datum, constitute one data point. A

module using data from more than one source would process all the data and timestamp

them once, so that the data logger could write it all to a data file for post processing.

There are several advantages to using an MRP data manager, among them ease of

debugging code and synchrony in data usage. Table 2 below compares some of the

more important inter-process tasks that need to be performed by the software system.


Page 30 of 96

Table 2 Comparison of Inter-process Tasks with and without Data Manager

Task Without Data Manager With Data Manager

Debugging Chain of data production and use

difficult to track

Easy to track data flow and therefore

mistakes in logic

Current Data

Repository

Data must be acquired separately from

each source

Single point for current data

Synchronization Data can be timestamped, but a datum

used in a particular module may have

been acquired at a different time from

data used in a related module

Single timestamp for current data,

along with timestamp for data

acquisition, so logic can be traced

Complexity Many separate (and possibly

redundant) connections among

software modules

One connection = one use of data

Data Archiving

for Performance

Measurements

Related to synchronization and current

data repository tasks; difficult to track

data usage in a post-mortem

Dual timestamps (“data acquired” and

“data used”) allow tracking of logic and

assumptions made to decide how good

the system is

Fault detection If a piece of hardware does not provide

timely data, the subsequent effects on

the system are hard to trace

Easy to trace stale data and therefore a

problem in either software logic or

hardware

Future

expansion and

integration

May need to modify more than one

module to accommodate connections

to a new module

Adding a new module only requires

adding a UDP/TCP socket to the data

manager, along with the data structure

5.3.2 UNIX Socket API

The data transmission between each component is implemented by UNIX sockets. The

California implementation wraps the basic socket functions (e.g. creating, connecting,

sending and receiving) into the socketUtils class (see Figure 17) to reduce the redundant

socket coding on each component. It supports both UDP and TCP sockets for IPv4 and

IPv6. Socket protocol (e.g. UDP, TCP), hostname and port is included in a configuration

file for each component, in the format of protocol:hostname:port.

bool setSocketAddress(const char* str,socketAddress_t& socketAddr);

int server(const socketAddress_t& myAddress,const bool isNonBlocking);

int client(const socketAddress_t& theirAddress,const bool isNonBlocking);

bool sendall(const int sfd, const char* buf, const size_t len);

The setSocketAddress function converts the configuration string into the

socketAddress_t object for creating a socket. For receiving data, the server function

creates a socket to get a socket descriptor, binds the socket to the local socket address,

and starts listening on the port for incoming TCP connections. For sending date, the

client function creates a socket and connects the socket to the host socket address. The

argument isNonblocking is to set the socket in non-blocking (true) or blocking (false)

mode. In blocking mode, the socket receive commands block the process until a packet

arrives. All the MMITSS components require non-blocking sockets so the component


Page 31 of 96

does not wait for the packets and only process the packet when it arrives. Socket send

commands might not send all the bytes that are asked to. The sendall function ensures

that all the bytes are sent out so the component that uses the Socket API does not need

to handle sending partial messages.

Figure 17 Class Diagram of UNIX Socket API

5.3.3 MMITSS Message Header

A single component may receive different types of messages over socket. For example,

the RSE_MessageTX receives SPaT, MAP and SSM messages to be transmitted over

the air. One option to handle multiple types of messages is to use multiple receiving

sockets with each socket corresponding to one type of message. Another option is to

include a message header that specifies the type of message so only one receiving

socket would be required. The MMITSS teams defined the format of message header as

illustrated in Figure 18. The MessageClass filed classifies that this is an MMITSS internal

message (selected as 0xFFFF), the MessageID field identifies the type of message (e.g.

Data) and the Length field specifies the length (in bytes) of Data.

class socketUtils

«Enumeration»

SocketProtocol

UDP

TCP

«struct»

socketAddress_t

+ name: std::string

+ port: std::string

+ sockeyProtocol: socketUtils::SocketProtocol

socketUtils

+ socketAddr: socketUtils::socketAddress_t

+ client(socketUtils::socketAddress_t&, bool): int

+ sendall(int, char*, size_t): boolean

+ server(socketUtils::socketAddress_t&, bool): int

+ setSocketAddress(char*, socketUtils::socketAddress_t&): boolean

+sockeyProtocol

+socketAddr


Page 32 of 96

Figure 18 MMITSS Internal Message Format

MMITSS message ID and message flow are summarized in Table 3. SRM and PSRM

(pedestrian SRM) have the same message format and are sent from different sources.

The structures of the message body (e.g. Data) are illustrated in Figure 19.

Table 3 MMITSS Messages

Message Type Message

ID From Via To

BSM 0x40 RSE_MessageRX MRP_DataMgr MRP_Aware

SRM 0x41 RSE_MessageRX MRP_DataMgr MRP_Aware

PSRM 0x42 Nomadic_PriorityDataServer MRP_DataMgr MRP_Aware

SSM 0x43 MRP_Aware MRP_DataMgr RSE_MEssageTX


SPaT 0x44 MRP_TrafficControllerInterface MRP_DataMgr

RSE_MEssageTX


MRP_Aware

MAP 0x45 MRP_DataMgr - RSE_MEssageTX


SoftCallReq 0x46 MRP_Aware MRP_DataMgr MRP_TrafficControllerInterface

VehTraj 0x47 MRP_Aware MRP_DataMgr Message requester via poll

PhaseFlags 0x48 MRP_TrafficControllerInterface MRP_DataMgr Message requester via poll

PhaseTiming 0x49 MRP_TrafficControllerInterface MRP_DataMgr Message requester via poll

CoordPlan 0x50 MRP_TrafficControllerInterface MRP_DataMgr Message requester via poll

FreePlan 0x51 MRP_TrafficControllerInterface MRP_DataMgr Message requester via poll

DetPhaseAsgmt 0x52 MRP_TrafficControllerInterface MRP_DataMgr Message requester via poll

DetectorCount 0x53 MRP_TrafficControllerInterface MRP_DataMgr Message requester via poll

DetectorPresence 0x54 MRP_TrafficControllerInterface MRP_DataMgr Message requester via poll

PollReq 0x80 Other components such as


- MRP_DataMgr

Message Class

2 byes

Message ID

1 byte

Timestamp

4 bytes

Length

2 bytes

Data

Var.

MMITSS Message Header

MMITSS Message


Page 33 of 96

Figure 19 Structure of MMITSS Messages

class Message Structure

«struct»

phaseflags_mess_t

+ bike_recall_phases: std::bitset<8>

+ doubleEntry_phases: std::bitset<8>

+ fomaxlock_phases: std::bitset<8>

+ maxgreen2_phases: std::bitset<8>

+ maxgreen3_phases: std::bitset<8>

+ maximum_recall_phases: std::bitset<8>

+ minimum_recall_phases: std::bitset<8>

+ ped_recall_phases: std::bitset<8>

+ permitted_ped_phases: std::bitset<8>

+ permitted_phases: std::bitset<8>

+ red_revert_interval: uint8_t

+ redlock_phases: std::bitset<8>

+ restInRed_phases: std::bitset<8>

+ restInWalk_phases: std::bitset<8>

+ restricted_phases: std::bitset<8>

+ startup_allred: uint8_t

+ startup_green_phases: std::bitset<8>

+ startup_pedCalls: std::bitset<8>

+ startup_vehCalls: std::bitset<8>

+ startup_yellow_phases: std::bitset<8>

+ startup_yellowOverlaps: std::bitset<8>

+ walk2_phases: std::bitset<8>

+ yewlock_phases: std::bitset<8>

«struct»

phasetiming_mess_t

+ added_initial_per_vehicle: uint8_t

+ bike_green: uint8_t

+ bike_red_clearance: uint8_t

+ delay_early_walk_time: uint8_t

+ detector_limit: uint8_t

+ maximum_extensions: uint8_t ([3])

+ maximum_gap: uint8_t

+ maximum_initial: uint8_t

+ minimum_gap: uint8_t

+ minimum_green: uint8_t

+ passage: uint8_t

+ phase_num: uint8_t

+ red_clearance: uint8_t

+ reduce_gap_by: uint8_t

+ reduce_gap_every: uint8_t

+ solid_walk_clearance: uint8_t

+ walk_clearance: uint8_t

+ walk1_interval: uint8_t

+ walk2_interval: uint8_t

+ yellow_interval: uint8_t

«struct»

coordplan_mess_t


+ cycle_length: uint8_t

+ cycle_multiplier: uint8_t

+ force_off: uint8_t ([8])

+ green_factor: uint8_t ([8])

+ hold_phases: std::bitset<8>

+ isPrioEnabled: bool

+ lag_phases: std::bitset<8>

+ laggapout_phase: uint8_t

+ max_early_green: uint8_t

+ max_green_extension: uint8_t



+ offsets: uint8_t ([3])

+ omit_phases: std::bitset<8>


+ plan_num: uint8_t

+ prio_force_off: uint8_t ([8])

+ prio_inhibit_cycles: uint8_t

«struct»

freeplan_mess_t


+ conditional_service_minimum_green: uint8_t

+ conditional_service_phases: std::bitset<8>

+ isPrioEnabled: bool

+ lag_phases: std::bitset<8>



+ omit_phases: std::bitset<8>


+ prio_hold_phases: std::bitset<8>

+ prio_max_green_hold_time: uint8_t

«struct»

system_detector_assignment_mess_t

+ detectorInput: uint8_t ([16])

«struct»

detector_count_mess_t

+ occupancy: uint8_t ([16])

+ volume: uint8_t ([16])

«struct»

detector_presence_mess_t

+ detector_presences: std::bitset<40>

«struct»

poll_req_mess_t

+ req_msgId: uint8_t

«struct»

softcall_req_mess_t

+ callObj: Enumeration

+ callPhase: std::bitset<8>

- callType: Enumeration

«enumeration»

Obj

PED = 1

VEH = 2

PRIO = 3

«enumeration»

Type

CALL = 1

EXTENSION = 2

CANCEL = 3

«struct»

veh_traj_mess_t

+ track_points: std::vector<track_point_t>

+ trackPointNums: uint32_t

+ vehId: uint32_t

«struct»

track_point_t

+ dist2stopline: int

+ ETA: uint32_t

+ geoPoint: GeoUtils::geoPoint_t


+ laneId: uint8_t

+ motionState: GeoUtils::motion_t

+ msgCnt: unit8_t

+ projPoint: GeoUtils::point2D_t

+ secMark: unit16_t

«struct»

GeoUtils::geoPoint_t

+ elevation: double

+ latitude: double

+ longitude: double

«struct»

GeoUtils::point2D_t

+ x: int32_t

+ y: int32_t

«struct»

GeoUtils::motion_t

+ heading: double

+ speed: double

+projPoint

+geoPoint

+callObj

+motionState

+callType +track_points


Page 34 of 96

6 Detailed Component Designs (California)

This section contains a detailed discussion of each of the software components in terms

of their responsibility as defined by the associated requirements and description in the

concept of operations document. Each component is given a name, traceability

information to requirements, concept of operations, and/or stakeholder requirements, a

brief description of the component’s responsibility, and any additional text useful for

understanding the component’s role in MMITSS.

There are three documents that contain the key traceability information:

1. MMITSS Stakeholder Input Document, 8/3/2012,

http://www.cts.virginia.edu/wp-content/uploads/2014/05/PFS_MMITSS02_Task2.2.pdf

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


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)


Page 36 of 96

6.1.2 RSE_ServiceAdvertisementMgr


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.


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.


Page 37 of 96

6.1.3 RSE_MessageRX


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


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


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

meaning of configuration parameters:

#######################################

# WME stake configuration file for RSU

#######################################

# Format of application configuration:

# enable/disable : messageSetName : wmeRegisterType : TxDirection : PSC

# enable/disable = 0 or 1

# wmeRegisterType = USER or PROVIDER

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


Page 39 of 96


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


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


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.


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


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


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

meaning of configuration parameters:

#######################################

# WME stake configuration file for OBU

#######################################

# Format of application configuration:

# enable/disable : messageSetName : wmeRegisterType : TxDirection : PSC

# enable/disable = 1/0

# wmeRegisterType = USER or PROVIDER

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


Page 42 of 96


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


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


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]


Page 44 of 96


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


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:

#######################################

# Vehicle configuration file for OBU

#######################################

isPrioEligible := 1 # 0 – No, 1 - Yes

codeWord := MMITSS # codeword size (1..16)

vehId := 1 # unit32_t

vehLen := 12.0 # double

vehWidth := 3.0 # double

vehName := obuBus_1 # vehName size (1..63)

vehVin := obuBus_1 # vehVin size (1..17)

vehOwner := California_PATH # vehOwner size (1..32)

vehType := 6 # VehicleType_none = 0, VehicleType_unknown = 1,

# VehicleType_special = 2, VehicleType_moto = 3,

# VehicleType_car = 4, VehicleType_carOther = 5,

# VehicleType_bus = 6, VehicleType_axleCnt2 = 7,

# VehicleType_axleCnt3 = 8, VehicleType_axleCnt4 = 9,

# VehicleType_axleCnt4Trailer = 10, VhicleType_axleCnt5Trailer = 11,

# VehicleType_axleCnt6Trailer = 12, VehicleType_axleCnt5MultiTrailer = 13,

# VehicleType_axleCnt6MultiTrailer = 14, VehicleType_axleCnt7MultiTrailer = 15

priorityLevel := 5 # prioLevel range (0..15).


Page 46 of 96

# Can be omitted if isPrioEligible = 0

The display messages are required output to the OBE_GUI component (see Section

6.2.4) for visualizing the status of the vehicle, the communication system, traffic signals,

and priority control services. The structure of the display message is shown in Table 4.

Table 4 Structure Display Message

Name Type Description

intNums uint32_t The number of intersections from which the OBE_Aware

is currently receiving MAP

intID uint32_t ID of the intersection that the vehicle is currently on

intLocStatus uint32_t 1 – on ingress, 2 – at intersection box, 3 - on egress

prioReqStatus uint32_t (OBE_Aware) 1 – requested, 2 – cancelled

signalState uint32_t[8] 1 – green, 2 – yellow, 3 - red

pedSignalState uint32_t[8] 1 – Don’t walk, 2 – Flashing don’t walk, 3 - Walk

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)


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.


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]


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.


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


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.


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

SSM 0x43 MRP_Aware Forward to RSE_MEssageTX and


Unencoded SPaT 0x44 MRP_TrafficControllerInterface

Encode SPaT, send it to

RSE_MEssageTX,

Nomadic_PriorityDataServer and

MRP_AWARE

MAP 0x45 MRP_DataMgr Send to RSE_MEssageTX and


SoftCall 0x46 MRP_Aware Forward to

MRP_TrafficControllerInterface

VehTraj 0x47 MRP_Aware Store in memory, send to the

requested when polled

PhaseFlags 0x48 MRP_TrafficControllerInterface

Store in memory, send to the


PhaseTiming 0x49 MRP_TrafficControllerInterface Store in memory, send to the


CoordPlan 0x50 MRP_TrafficControllerInterface Store in memory, send to the


FreePlan 0x51 MRP_TrafficControllerInterface Store in memory, send to the


DetPhaseAsgmt 0x52 MRP_TrafficControllerInterface Store in memory, send to the


DetectorCount 0x53 MRP_TrafficControllerInterface Store in memory, send to the


DetectorPresence 0x54 MRP_TrafficControllerInterface Store in memory, send to the


PollReq 0x80 Other components such as


Send back the requested

message


Node: MRP Component Name: MRP_DataMgr Traceability: C2004.001, C2005.001, C2005.302, C2004.302,

C2009.302, A1301, A1302

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.


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.


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


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


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


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

communications.

The functionalities of this component include:

1. Collect traffic controller’s configuration data (e.g. phase timing, coordination plans,

free plan, detector phase assignment, etc.);

act MRP_DataMgr

Start

readConfFiles


createSockets

Received a

packet?

storeData

encode_mapdata_payloadencode_spat_payload sendSPaT

forwardMsg

sendPollResponse

Time to send MAP?

sendMAP[Yes]

[No]

[pollReq]

[BSM/SRM/PSRM/SSM/SoftCall]

[SPaT Data][No]

[Yes]


Page 54 of 96

2. Collect signal status data (e.g. active phases and intervals, etc.) from the traffic

controller and populate SPaT data for constructing J2735 SPaT;

3. Collect vehicle detection data (e.g. count and occupancy) from the traffic

controller; and

4. Command MMITSS traffic and priority control to the traffic controller.

AB3418 messages are variable length and have the following format:

Byte 1 - Start Flag 0x7E

Byte 2 - Controller Address 1 to 255

Byte 3 - Control Byte

0x13 – single address Unnumbered Information (UI) control byte

0x03 – broadcast Unnumbered Information (UI) control byte

0x33 – single address Unnumbered Poll (UP) control byte

Byte 4 - IPI (0xC0)

Byte 5 - Message Type

Variable Bytes - Packet Message Data (0 to n bytes)

Byte - 16-bit FCS MSB (most significant byte of the Frame Check Sequence,

bytes #2 to end of Packet Message Data)

Byte - 16-bit FCS LSB (least significant byte of the Frame Check Sequence)

Byte - End Flag 0x7E

Traffic Signal Control Program (TSCP) runs on the Model 2070 traffic controller supports

Message Get (Message Type = 0x87) and Message Set (Message Type = 0x96) to read

and modify TSCP memory blocks. The Get and Set commands are for the purpose of

remotely downloading and modifying controller’s configuration and timing parameters,

not for real-time traffic control. Caltrans Division of Traffic Operations (TrafficOps)

modified TSCP to support the MMITSS functions. The modifications include:

• Push out GetStatus8Response message, which contains detector presence data,

at a rate of 1Hz on port C20S;

• Push out GetStatus8eResponse message, which contains detector count and

occupancy data, every 60 seconds or at the end of a signal cycle on port C20S;

• Push out signal_status message, which contains information for constructing

J2735 SPaT, at a rate of 10Hz on port C21S; and

• Accept vehicular phase call/extension, pedestrian phase call, and signal priority

call (e.g. AB3418 SoftCall) on port C20S.

The structure of the 2070 controller pushing out messages are illustrated in Figure 31.

The GetStatus8Response and GetStatus8eResponse messages are already defined

AB3418 messages. The signal_status message is a new AB3418 message that is

implemented for MMITSS, which includes necessary data fields for this component to

estimate the remaining time for all permitted phases. The definition of data fields of the

signal_status message is shown in Table 6.


Page 55 of 96

Figure 31 Structure of Model 2070 Controller Pushing Out Messages

The SoftCall message is also a new AB3418 message that is implemented for MMITSS

traffic and priority control. The message sends to the 2070 controller in the frame defined

in Table 7 below.

TSCP control logic that responds to SoftCall remains the same as the logic that

responds to field sensors (e.g. loop detectors, pedestrian push-buttons, etc.). SoftCall is

implemented as an alternative detection means via AB3418 protocol other than the field

sensor detection. The effect of SoftCall is as follows:

• Pedestrian call will place a pedestrian service request on the phases called;

• Vehicle call will place a service request on the calling phases when the phase is in

yellow or red; and place an actuation (passage) when the phase is in green.

Continuous calls will be required to hold the request (at a rate of 50 milliseconds);

and

• TSP call will place a priority request on the calling phase and the call should be

continuously sent at a rate of 50 milliseconds. The traffic controller will execute

the build-in priority control logic until the TSP call is dropped.

TSCP build-in priority control provides early green and green extension treatments. Per

Caltrans priority control policy, signal priority only applies to the main streets.

class 2070 Pushing out msgs

«struct»

signal_status_mess_t

+ active_force_off: uint8_t ([2])

+ active_interval: std::bitset<8>

+ active_phase: std::bitset<8>

+ interval_timer: uint8_t ([2])

+ local_cycle_clock: uint8_t

+ master_cycle_clock: uint8_t

+ next_phase: std::bitset<8>

+ pattern_num: uint8_t

+ ped_call: std::bitset<8>

+ ped_permissive: uint8_t ([8])

+ permissive: uint8_t ([8])

+ preempt: std::bitset<8>

+ veh_call: std::bitset<8>

«struct»

status8_mess_t

+ controller_status: std::bitset<8>

+ detector_presences: std::bitset<40>

«struct»

status8e_mess_t

+ occupancy: uint8_t ([16])

+ volume: uint8_t ([16])


Page 56 of 96

Table 6 AB3418 Signal Status Message

Parameter Note

active_phase Bit set true for phase active

active_interval Bits 0 – 3 � Ring A interval

Bit 4 – 7 � Ring B interval

Interval encoding:

0x00 = Walk

0x01 = Don’t Walk

0x02 = Minimum Green

0x04 = Added Initial

0x05 = Passage

0x06 = Max Gap

0x07 = Min Gap

0x08 = Red Reset

0x09 = Preemption

0x0A = Stop Time

0x0B = Red Revert

0x0C = Max Termination

0x0D = Gap Termination

0x0E = Force off

0x0F = Red Clearance

interval_timer[2] Countdown timer on Ring A and Ring B

pattern_num Current control plan and offset

next_phase Bit set true for phase next (available when the

active phase is in yellow interval)

ped_call Bit set true for phase has pedestrian call

veh_call Bit set true for phase has vehicular call

local_cycle_clock Local cycle timer

master_cycle_clock Master cycle timer

preempt Bit 0 – 3 � EV A – D

Bit 4 – 5 � RR 1 – 2

Bit 6 � Pattern Transition

Bit 7 � TSP

active_force_off[2] Force-off points for phase active

Permissive[8] Permissive periods vehicular phases

ped_permissive[8] Permissive periods for pedestrian phases


Page 57 of 96

Table 7 AB3418 Soft-Call Message

Byte # Description Notes Range

1 Start Flag 0x7E

2 Controller Address 1 to 255

3 Control 0x13

4 IPI 0xC0

5 Message – SET 0x9A

6 Vehicle Call/Extend Bits 0-7 � vehicle call on phase 1-8 0 to 255

7 Pedestrian Call Bits 0-7 � pedestrian call on phase 1-8 0 to 255

8 TSP Call Bits 0-7 � TSP call on phase 1-8 0 to 255

9 Spare Reserved 0 to 255





14 16-bit FCS MSB Checksum MSB 0 to 255

15 16-bit FCS LSB Checksum LSB 0 to 255

16 End Flag 0x7E


Node: MRP Component Name: MRP_TrafficControllerInterface

Traceability: C2011.001, C2011.302, C2011.005, C2011.006,

A2012, C2012.001, C2012.002, C2101.001, C2101.002,

C2101.003, C2101.004, C2101.305

Description of Responsibility: This component is responsible for providing the

protocol specific interface to the traffic signal controller.

Supporting Text: The MRP_TrafficControllerInterface component is a unique

component for field test network implementation in terms of the protocol supported for

communications. The California test network uses Model 2070 controllers with AB3418

protocols. This component will provide the necessary protocol specific interfaces

including messages and channel control/management capabilities.

6.3.2.3 Derived Requirements

This component should send SoftCall at a rate of 50 milliseconds until the vehicle

passed the intersection stop line.

6.3.2.4 Interfaces

The interfaces of the MRP_TrafficControllerInterface component are shown in Figure 32.


Page 58 of 96

Figure 32 Interface Diagram of MRP_TrafficControllerInterface


• Controller pushing out messages (GetStatus8Response, GetStatus8eResponse

and signal_status messages with structures as shown in Figure 31);

• Controller configuration data (PhaseFlags, PhaseTiming, CoordPlan, FreePlan,

DetPhaseAsgmt objects with structure as shown in Figure 19); and

• Soft-call request (e.g. SoftCallReq object in Table 3) from the MRP_DataMgr

component.


• SPaT data, controller configuration date, and vehicle detection data

(DetectorCount and DetectorPresence objects in Table 3 and Figure 19) to the

MRP_DataMgr component; and

• AB3418 soft-call message (frame structure as shown in Table 7) to the traffic

controller.


file (e.g. tciSocket.conf). An example of the configuration file is attached below.

#######################################

# Socket configuration file for TCI

#######################################

spatPort := /dev/ttyS0

spat2Port := /dev/ttyS1

dataMgrSendSocket := UDP:127.0.0.1:15023 # send to datamgr

dataMgrListenSocket := UDP:127.0.0.1:15024 # receive from datamgr


An activity diagram which illustrates the operation of the MRP_TrafficControllerInterface

component is shown in Figure 33.

MRP_TrafficControllerInterfaces

<<manifest>>

tciSocket.conf

UDP Socket API

MRP_Traffic

ControllerInterfaceMRP_DataMgr

Model 2070

Controller

RS-232


Page 59 of 96

Figure 33 Activity Diagram of MRP_TrafficControllerInterface

Serial ports and sockets are opened/created in non-blocking mode, so this process does

not wait for data. It sends controller configuration data, vehicle count data, and detector

presence data when receiving them from the traffic controller. When receiving signal

status data from the traffic controller, this component estimates the remaining time for all

permitted phases, and sends the SPaT data. The estimation is a combination of signal

status data, phase timing data, and coordination/free plan parameter, and follows NEMA

dual-ring control logic. This component updates the list of vehicle, pedestrian and priority

act MRP_TrafficControllerInterface

Start

readConfFiles

openSerialPorts

createSockets

pollControllerConfData

Received

serial data?

sendCountData

sendPresenceDatasendConfData

estPhaseRemainingTime sendSPaTdata

Received soft-call

request? updateSoftcallState

Empty softcal l

set?

sendSoftcall

checkSoftcall2send

[Yes]

[Yes]

[No]

[No]

[signal status]

[status8e]

[Yes]

[status8]


Page 60 of 96

calls when it received soft-call requests (including cancel request) from the MRP_Aware

component.

Pedestrian calls are sent to the traffic controller right away and removed from the list.

Vehicle phase calls and early green priority calls are only sent when the calling phase is

in red or yellow. These calls are dropped and removed from the list when either the

calling phase has turned to green or this component has received a cancel soft-call

request from MRP_Aware. Vehicle green extension and priority green extension calls are

only sent when the calling phase is in green, and are removed from the list when either

the phase has turned yellow or the request has been cancelled.

6.3.2.6 References

[1] Standard Communications Protocol for Traffic Signals in California, 1995.

[2] Caltrans. Traffic Signal Management and Surveillance System TSCP Memory Map, Version 1.05A, 2013.

[3] Caltrans. Model 2070 TSCP User Manual, Version 2.22, 2013.

6.3.3 MRP_Aware


The MRP_Aware component is responsible for processing BSM, SRM and PSRM

messages, managing requests for priority, and integrating equipped vehicles into the

traffic control logic through phase calls and phase extensions for each of the different

modes (and dynamics) of vehicles. This component is also responsible for providing

SSMs to equipped vehicles and travelers.


Page 61 of 96


Node: MRP Component Name: MRP_Aware


C2006.001, C2007.001, C2007.202, C2007.404, C2008.001,

C2008.202, C2008.303, C2008.404, C2009.001, C2009.302,

C2010.202, C2010.303, C2010.404, C2011.001, C2011.302,

C2011.005, C2011.006, A2103

Description of Responsibility: The MRP_Aware component is responsible for

processing BSM, SRM and PSRM messages, managing requests for priority, and

integrating equipped vehicles into the traffic control logic through phase calls and phase

extensions for each of the different modes (and dynamics) of vehicles, based on signal

controller capability. This component is also responsible for providing SSMs to equipped

vehicles and travelers.

Supporting Text: The California implementation utilizes Model 2070 controller TSCP

(Traffic Signal Control Program) build-in priority control logic. TSCP has been modified

to take inputs of vehicular and pedestrian phase call, vehicle phase extension, and

priority calls using AB3418 protocols.

6.3.3.3 Interfaces

The MRP_Aware interfaces are shown in Figure 34.

Figure 34 MRP_Aware Interface Diagram


• J2735 BSM, SRM, PSRM and SPaT messages; and

• Intersection MAP description file for tracking BSMs on the MAP


MRP_Aware

<<manifest>>

awareSocket.conf

UDP Socket APIMRP_DataMgr

J2735Lib

MRP_Aware

J2735Lib API

Int.nmap


Page 62 of 96

• J2735 SSM messages;

• AB3418 soft-call request messages; and

• Vehicle trajectory data


file (e.g. awareSocket.conf). An example of the configuration file is attached below.

#######################################

# Socket configuration file for MRP_Aware

#######################################



dsrcTimeout := 2 # in seconds (remove veh from tracking list if timeout

expires)


An activity diagram which illustrates the operation of the MRP_Aware component is

shown in Figure 35. This component maintains two lists, a list of active requests for

priority and a list of vehicle trajectories. When receiving a BSM, depending on whether

the vehicle ID is on the vehicle list or not, either a new track is initiated or an existing

track gets updated. When receivingd a SRM or a PSRM, it updates the request list.

In the decision of making soft-call request, this component checks every vehicle on the

priority request list as well as every vehicle on the vehicle list. Rules for selecting soft-call

target are as follows:

• Pedestrian phase call will be sent to the MRP_TrafficControllerInterface right

away;

• Vehicle phase call will be sent if the requested phase is not in green;

• Request for priority has higher priority than vehicle phase extension calls; and

• Green extension priority request has higher priority than early green request, as

priority treatments are provided to the main streets, green extension always

reduce the total delay more than the early green treatment.


Page 63 of 96

Figure 35 Activity Diagram of MRP_Aware

6.3.4 MRP_PerformanceObserver


The MRP_PerformanceObserver component is responsible for periodically acquiring CV

trajectory data and traffic detector data from the MRP_DataMgr component, based on a

defined observation period, estimating intersection level performance measures from the

acquired data, and sending the estimated measures to the MRP_DataMgr such that the

measures become available to the MMITSS Central System.

As it is described in Section 6.3.3, the MRP_Aware component processes BSM and

SRM messages received from connected vehicles, tracks the vehicles on the

intersection MAP, and when a vehicle moves out the MAP, it sends its trajectory data to

act MRP_Aware

Start

readConfFile


createSockets

Received J2735

messages?

decode_payload

Is vehID on l ist?

initialTrack

updateLocation locateVehInMap

updateLocationAware

updateSignalAware

updateReqList

getSoftcallTargets

Empty set?

updateVehList

sendSoftCall

Any vehile

move out

MAP?sendVehTraj

Time to send SSM? sendSSM

[Yes]

[No]

[Yes]

[No]

[BSM]

[SRM, PSRM,

SPaT]

[No]

[No]

[Yes]

[Yes]

[No]


Page 64 of 96

the MRP_DataMgr (see Figure 35). The MRP_TrafficControllerInterface component

receives detector count data from the traffic signal controller and sends the count data to

the MRP_DataMgr (see Figure 33). Data structures of vehicle trajectory data message

and detector count data message are illustrated in Figure 19. The intersection level

performance measures are estimated by the MRP_PerformanceObserver component

and the data resource regarding each measure are summarized in Table 8. The signal

request messages (SRMs) are used together with BSMs to obtain the travel time by

mode as the vehicle type information is not included in the Part I BSM. [Note: the issue

of including vehicle classification is currently being considered by the SAE DSRC

Technical Committee (May 22, 2015)].

Table 8 Performance Observations and Associated Data Resources

Performance Metric Abbreviation Unit Data Source

Travel Time

by Movement and Mode TT Second

BSM, SRM � Vehicle trajectory

(MRP_Aware)

Travel Time Variability

by Movement and Mode TTV Second


(MRP_Aware)

Delay

by Movement and Mode DT Second


(MRP_Aware)

Delay Variability

by Movement and Mode DTV Second


(MRP_Aware)

Vehicle Throughput

by Movement VT

Vehicles per Hour

(vph)

Detector count �Movement-

based throughput

(MRP_TrafficControllerInterface)


Node: MRP Component Name: MRP_PerformanceObserver

Traceability: C2013.001, C2013.002, C2013.003, C2013.004, C2013.005, C2013.006, C2013.007, C2013.008, C2015.001, C2015.002, C2015.003, C2015.004, C2015.005, C2015.006, C2015.007, C2015.008, C8101.101

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.


Page 65 of 96

Figure 36 MRP_PerformanceObserver Interface Diagram

The required inputs include the vehicle trajectory data and detector data from the

MRP_DataMgr (see Figure 19 for the data structures of the trajectory data and the

detector data). The provided outputs are the estimated performance measures (see

Table 8 for the performance metrics). Socket addresses for the required and provided

interfaces are input as a configuration file (e.g. obsSocket.conf). An example of the

configuration file is attached below.

########################################################

# Socket configuration file for MRP_PerformanceObserver

########################################################



observeDuration := 15 # in minutes (the interval for acquiring data from

datamgr, calculating performance metrics, and sending

metrics to datamgr)


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


<<manifest>>

obsSocket.conf

UDP Socket API

MRP_Performance

ObserverMRP_DataMgr


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.

TT� = "#tt�$ = ∑ tt�&'�()�� (5)

TTV� = +"#�� − ,,�$- = . 1�� / 0tt� − TT�1-&'�() (6)

The delay and delay variability associated with phase � are given by equations (7) and (8), respectively.

DT� = "#dt�$ = ∑ dt�&'�()�� (7)

DTV� = +"#�� − �,�$- = .1�� / 0dt� − DT�1-&'�() (8)

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)


Page 67 of 96

6.4 MMITSS Central System Components

6.4.1 MMITSSUserInterface


The MMITSSUserInterface component is responsible for providing a user interface for

the system level MMITSS component.


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

information.

6.4.1.3 Interfaces

6.4.1.3.1 Required (input)

Desired Performance Metrics, Modes’ Weights, Coordination Configuration, N-Level

Priority Hierarchy.

6.4.1.3.2 Provided (output)

Performance Measure Reports, Modes’ Weights, Coordination Configuration, N-Level

Priority Hierarchy.

6.4.1.4 Functional Specification/Description

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.


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


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


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.


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)


Page 72 of 96

(b)

(c)

Figure 42 User Interface_PerformanceObserver Web Application

6.4.2 System_ConfigurationManager

Node: MMITSS System

Component Name: System_ConfigurationManager

Traceability: A4101, A4102, 13.3.1; §11.1.2, §11.1.3

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.


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


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


Page 74 of 96

configuration manager will set the associated parameters on the MRP and within section

level priority request servers.


Node: MMITSS

System

Component

Name: System_N_LevelPriorityConfigurationManager

Traceability: A8001, A8002, C8002.402, C8002.503, 13.3.1,

13.3.2, 13.3.3, 13.3.4, 13.3.5; §11.0, §11.1.1, §11.2, §11.3,

§11.4, §11.5

Description of Responsibility: This component is responsible for allowing an operator

to set the policy preferences for the N-Level Priority policy.

Supporting Text: 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 that 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 configuration manager will set the

associated parameters on the MRP and within section level priority request servers.

6.4.3.3 Interfaces

The System_N_LevelPriorityConfigurationManager interface is shown in Figure 44.

Figure 44 Interfaces of the System_N_LevelPrioirityConfigurationManager

cmp System_N_LevelPriorityConfigurationManager

MMITSSUserInterface

System_N_LevelPriorityConfigurationManager

priorityConfiguration

«use»

«abstraction»


Page 75 of 96


The System_N_LevelPriorityConfiguratuionManager is responsible for providing a data

structure for the MRP_Priority_Solver and the MRP_PRS_PriorityRequestServer. The

data structure contains weights for transit and truck. If the coordination is considered as

a form of priority, the weight of coordination as well as the cycle, split, offset, and

coordinated phases are determined in the data structure.


The System_N_LevelPriorityConfiguratuionManager uses MMITSSUserInterface to

receive the priority configuration. The user may define the configuration for each

intersection. Figure 45 shows the priority configuration webpage for the Dedication and

Daisy Mountain Dr. intersection (AZ). The user can set the priority policy by changing the

weights. There are slider bars for setting the transit, truck, and coordination weight. By

clicking the “Submit To RSE” button, the priority policy data will be transferred to the

corresponding RSE (in this example Dedication-Daisy Mountain Dr.) and will be stored in

a file. The MRP_Priority_Solver and MRP_PRS_PriorityRequestServer will read the file

to implement the priority policy.

Figure 45 Example of Setting the Priority Policy System_N_LevePrioirityConfigurationManager

In “priorityConfiguration.txt” file, coordination plan such as cycle split and offset is also

considered. (Note: The coordination plan should have obtained from Traffic Signal

Control through TCConfig. But in the current system, it is read from a file).

An example of priorityConfiguration.txt is shown as follow:


Page 76 of 96

coordination 1 coordinated_phase 2 6 cycle 100 offset 0 split 30 transit_weight 1 truck_weight 1

6.4.4 Section_PriorityRequestServer


The Section_PriorityRequestServer is responsible for the coordination of priority

requests at a section level. [Implementation Note: This section was not implemented].


Node: MMITSS System

Component Name: Section_PriorityRequestServer


C4003.402, A4004, C4004.201, 13.3.2; 13.3.4; 13.3.5; §11.0,

§11.0.1, §11.0.2, §11.2, §11.2.3, §11.4, §11.4.2, §11.5

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


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


Page 77 of 96


Node: MMITSS

System

Component Name: Section_Coordinator


C3003.005, C3003.006, A3004, C3005.001, C3005.002, A3006,

A3101, C3101.001, C3102.001, C3102.002, A3103, 11.1.2;

13.3.1, 13.3.2, 13.3.3, 13.3.4, 13.3.5; §4.1.1, §4.2, §5, §11.0,

§11.1.2, §11.4.2, §11.5.2

Description of Responsibility: This component is responsible for the identification of

platoons, estimation of the platoon arrival time at intersections in the section, setting

offsets and coordinated phase splits.

Supporting Text: The Section_Coordinator provides adjustments to coordination timing

that considers the movement/progression of platoons within the priority framework.

Trade-offs between priority for different modal vehicles and coordination is part of the N-

level priority policy.

6.4.6 Section_PerformanceObserver


The Section_PerformanceObserver is responsible for acquiring data from MRP_DataMgr

component of each intersection and combining them to estimate section level

performance measures, including section travel time (STT in seconds), section delay

(SDT in seconds), and their variabilities (STTV and SDTV in seconds).


Node: MMITSS System

Component Name: Section_PerformanceObserver


C3002.005, C3002.006, C3002.007, C3002.008, C8101.102,

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


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


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.


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


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.


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


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.


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


This component is responsible for receiving MAP and SPaT data from the

Nomadic_PriorityDataServer and make it available to the NomadicMMITSSApp.


Node: Nomadic

Device

Component Name: Nomadic_SignalStatusReceiver

Traceability: A1301, A1302, 13.3.3; §5, §8, §11.1, §11.3"

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.


Page 81 of 96

6.5.2.3 Interfaces


SPaT and Map data from the Nomadic_PriorityDataServer.


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.


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


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:


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.


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.


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.


Page 83 of 96

Figure 46 Savari SmartCross System Architecture

Figure 47 SmartCross App User Interface


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.


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.


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.


Page 86 of 96

Figure 49 SmartCross Flow Chart


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.


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


• 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


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


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.


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.


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.


Page 89 of 96


Pedestrian Location Message (PLMs)


Verification of the identity of the user and authorization of special services


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.


This component will be tested with a known group of users requiring special services.


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


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


Page 92 of 96

7.2 Appendix A: Savari RSE Product Specification Sheets


Page 93 of 96

7.3 Appendix B: Savari and Arada OBE Product Specification Sheets


Page 94 of 96


Page 95 of 96

7.4 Appendix C: J2735 ASN.1 Specification (Revision Number DSRC_R36)


Page 96 of 96

7.5 Appendix D: Intersection Map Description Files (CA)

Documents

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