WELCOME TO THEITS-NY

22nd ANNUAL MEETING ANDTECHNOLOGY EXHIBITION

2015 ITS-NY TWENTY-SECOND ANNUAL MEETING June 11-12, 2015; Saratoga Springs, NY

“ITS: Looking Forward”

AGENDA Thursday, June 11, 2015 3:15 p.m. Panel 3: “Bridging Institutional Boundaries to Make a

Difference: Have Regional ITS Architectures and Open Standards/Protocols Delivered ITS Services that Matter?”

Panel Moderator: Dr. Rob Jaffe, ConSysTec Tony Laidig, MTA Department of Buses, “From Binary To Text and Back: The Evolution of Real-Time

Transit Data Interchange” Tom Batz,TRANSCOM, “Standardizing the Way Agencies Share Event and Travel Time Data in the

NY/NJ/CT Metropolitan Region” Jim Davis, New York State DOT, “Integration of Multi-Agency Transit Information–How are Open

Standards Helping?” Dr. Arthur T. O’Connor, USDOT/FHWA–NYC Metro Office, “The USDOT Real-Time System Management

Information Program” Dr. Allison L. C. de Cerreño, Tunnels, Bridges & Terminals/Port Authority of New York & New Jersey,

“Regional All-Electronic Tolling: Overcoming Institutional Challenges”

Robert S. Jaffe, PhD, CSEP

President

ConSysTec

Panel 3

Bridging Institutional Boundaries to Make a Difference:

Have Regional ITS Architectures and

Open Standards/Protocols

Delivered ITS Services that Matter?

SpeakersTony Laidig, Systems Engineering Manager, MTA Department of Buses

From Binary To Text and Back: The Evolution of Real-Time Transit Data Interchange

Tom Batz, Deputy Executive Director, CTO, TRANSCOM

Standardizing the Way Agencies Share Event and Travel Time Data in the NY/NJ/CT

Metropolitan Region

Jim Davis, Acting Director, Statewide Policy and Performance Bureau, NYSDOT

Integration of Multi-Agency Transit Information – How are Open Standards Helping?

Arthur T. O’Connor, Ph.D., P.E., Sr. ITS/Operations Engineer, Downstate, USDOT/FHWA – NYC

Metropolitan Office

The USDOT Real-Time System Management Information Program

Allison L. C. de Cerreño, Ph.D., Assistant Director, Policy & Business Programs, Tunnels, Bridges

& Terminals/Port Authority of New York & New Jersey

Regional All-Electronic Tolling: Overcoming Institutional Challenges

2Bridging Institutional Boundaries to Make a Difference:

Have Regional ITS Architectures and Open Standards/Protocols Delivered ITS Services that Matter?

Agenda for Panel 3

• 10 minutes: Introductory remarks (Moderator Jaffe) + speaker intros

• 10 minutes: Tony Laidig

• 10 minutes: Tom Batz

• 10 minutes: Jim Davis

• 10 minutes: Art O’Connor

• 10 minutes: Allison L. C. de Cerreño

• ~15 minutes: Speaker comments/questions/interactions

• ~15 minutes: Q&A with audience participants

3Bridging Institutional Boundaries to Make a Difference:

Have Regional ITS Architectures and Open Standards/Protocols Delivered ITS Services that Matter?

ITS Architecture Layers

• Defines physical entity interfaces

• Distributes functionality

• 3 layers

Communications Layer

• How information is transferred

between ITS elementsInterfacesCommunications

Transportation

Institutional

Institutional Layer

• Supporting institutional

structure, policy, and strategies

• Stakeholder DrivenObjectives &

Requirements

Transportation Layer

• What ITS elements transfer

what informationSolutions

Bridging Institutional Boundaries to Make a Difference:

Have Regional ITS Architectures and Open Standards/Protocols Delivered ITS Services that Matter?

U.S. National ITS Architecture Framework and Template

Bridging Institutional Boundaries to Make a Difference:

Have Regional ITS Architectures and Open Standards/Protocols Delivered ITS Services that Matter?

National ITS Architecture Interfaces and Standards

Vehicles Field

CentersCommercialVehicleAdministration

ArchivedDataManagement

TravelersTollAdministration

EmergencyManagement

TrafficManagement

Fleet andFreightManagement

TransitManagement

Maintenance &ConstructionManagement

Roadway

ParkingManagement

EmissionsManagement

PersonalInformationAccess

RemoteTravelerSupport

InformationServiceProvider

CommercialVehicleCheck

Fixed-Point to Fixed-Point Communications

Veh

icle

to

Veh

icle

Co

mm

un

icati

on

s

Wide Area Wireless

(Mobile) Communications

Vehicle

TransitVehicle

CommercialVehicle

EmergencyVehicle

Maintenance &ConstructionVehicle

Toll Collection

Ded

icate

d S

ho

rt R

an

ge

Co

mm

un

icati

on

s

Security Monitoring

IEEE1512SAE ATISITE/AASHTOTMDD

NTCIP C2C

NTCIP C2F

ASTM ADUS

IEEE 1512

SAE ATISDSRC/WAVE APTA TCIP/CEN SIRI/GTFS

APTA TCIP/ CEN SIRI/GTFS

APTA TCIP

Bridging Institutional Boundaries to Make a Difference:

Have Regional ITS Architectures and Open Standards/Protocols Delivered ITS Services that Matter?

National ITS

Architecture

Regional ITS

Architecture

ITS Standards

ITS Project

ITS Architecture and Standards Relationships

Bridging Institutional Boundaries to Make a Difference:

Have Regional ITS Architectures and Open Standards/Protocols Delivered ITS Services that Matter?

Have Open Standards Delivered ITS Architectures that Matter?

A Passenger Information Perspective

U.S. National ITS Architecture Framework and Template

In the beginning, there was analog

Boston Transit Commission Report, 1890s

Approaching Ubiquity

Oona Räisänen

2000-2006 Standards Era

TCIP – Passenger Information group

Good: Standards Process

Bad: No major implementations

Backward looking: Year 2000 technology

(Not thought through for web / mobile clients)

Ugly: Documentation “cumbersome at best, impossible at worst”

2005 - 2006

2007

2008

2011: GTFS-Realtime

Global ITS Architecture

Have Open Standards Delivered ITS Architectures that Matter?

YES!

The real question

The private sector uses sizeable public investments for profit.

What are the incentives to push the next gen of tech forward?

Standardizing the Way Agencies Share Event & Travel Time Data in the NY/NJ/CT Metropolitan

Region

ITS-NY Annual Meeting

June 11, 2015

TRANSCOM MEMBERSConnecticut DOT

Metropolitan Transportation Authority

MTA Bridges & Tunnels

MTA New York City Transit

New Jersey DOT

New Jersey State Police

New Jersey Transit

New Jersey Turnpike Authority

New York City DOT

New York City Police

New York State Bridge Authority

New York State DOT

New York State Police

New York State Thruway Authority

Port Authority of NY&NJ

Port Authority Trans Hudson (PATH)

FHWA and Over 100 Affiliated Agencies

TRANSCOM Functions

• Primary Mission: Regional Operations• Regional Incident Management - 24/7

• Regional Construction Coordination

• Regional Implementation of ITS Systems

• Additional Mission: Support of Traveler Information Systems• Feed to 511 NY & 511 NJ

• Free data feeds (events, travel times)

• Member agency Variable Message Signs

• Member agency widgets

TRANSCOM Systems

• TRANSCOM OpenReach

• TRANSCOM Data Fusion Engine

• TRANSCOM SPATEL

• TRANSCOM Data Exchange

• TRANSCOM Middleware

TRANSCOM Member Agency Centers

• Member Agency Centers input data through TRANSCOM OpenReach

• Supplemented by TRANCOM OIC

TRANSCOM OpenReach Monitor

• OpenReach Monitor inputs data from non-Member Agency Operations Centers

• Ensures security of Member Agencies

TRANSMIT/TI-MED

• TRANSMIT (Soon to be TI-MED) inputs travel times to TRANSCOM OpenReach

TRANSCOM Data Fusion Engine

• Collects data from OpenReach, OpenReach Monitor, Other Member Agency Systems, and 3rd

Party Providers

TRANSCOM Data Fusion Engine

• Data is validated and verified

• Data is then fused into a single feed• Provides Member Agencies with a single source of data

from multiple inputs • Ensures accuracy in:

• Speed

• Travel Time

• Event Information

TRANSCOM Data Exchange

• TRANSCOM Data Exchange outputs DFE API:• 511NY & 511NJ

• Agency VMS

• other agency systems

• 3rd parties

TRANSCOM SPATEL

• TRANSCOM’s Data Archiving Tool• Currently available

via web portal

• Soon will be available directly to Member Agency Centers

TRANSCOM SPATEL

• Search historical travel time, incident and speed data through interactive, graphical format

• Source of performance measures to NY, NJ, CT, as well as regional Member Agencies

TRANSCOM Middleware

• Platform for member agencies to securely exchange data via open standards

• Goal is for TRANSCOM Member Agencies to be able to connect with TRANSCOM Systems using latest TMDD standards

TRANSCOM Middleware

• One-stop shop for Member Agencies can access all TRANSCOM data

• Standards-based approach allows for single data format agencies to access and upload data

• “Closes the loop” by connecting OpenReach with Data Fusion Engine

TRANSCOM User Needs

Event Information Real-Time Transit Information

Travel Time Device Control Information

Roadway Network

Information

Weather Information

DMS Information Freight Information

CCTV Information Performance Measures and

Data Analysis (MAP-21)

Parking Information Multi-State ATDM/ICM

Real-Time Transit Information

• TRANSCOM Member Agencies operating Transit:• New Jersey Transit (Rail and Bus)• MTA New York City Transit (Bus + Subway + Staten Island

Railway)• MTA Bus Company• MTA Long Island Rail Road• MTA Metro North Railroad• Port Authority Trans-Hudson (PATH)• Staten Island Ferry (NYCDOT)• CT Transit (ConnDOT)• Shore Line East (ConnDOT)

• Many additional agencies/operators exist within TRANSCOM’s Region

17

Summary: Existing Real Time Transit Feeds

• Real Time Feeds are available for:• New Jersey Transit (Rail)• MTA NYCT (Rail, Bus, Staten Island Railway)• MTA Long Island Rail Road• MTA Metro-North Railroad• CT Transit

• There is no common standard/specification used to format real time transit feeds:• NJT (Rail) - Internally Developed API• MTA (NYCT Subway, LIRR, MNR) – GTFS-RT • MTA (NYCT Bus) – SIRI• CT transit – GTFS-RT and Internally Developed API

18

Considerations to Developing a Regional Real Time Transit Data

Feed

• No consensus among regional transit agencies on a unified real time feed.

• Major differences in what is provided in currently available feeds.

• Not all agencies have real time feeds available.

• Project will result in a region-wide standard

19

Preliminary System Architecture for TRANSCOM Regional Real Time Transit Data Feeds

TRANSCOM Middleware

Regional Real Time Transit Data Feed*

NJT Rail(in 2015)

Consumer

ETA +veh loc

FormatXML (Proprietary)

MTA Bus Time

FormatSIRI – XML/JSON

*Output Format- SIRI – XML- GTFS-RT

veh dist. from stop

ETA + veh loc

MTA Subway

FormatGTFS-RT

ETA

MTA LIRR

FormatGTFS-RT

TBD

MTA MNR

FormatGTFS-RTTBD

20

*TRANSCOM MiddlewareInput Formats- NJT XML- SIRI – XML- GTFS-RT

PATH

FormatTBD

TBD

CT transit

FormatGTFS-RT

TBD

Real Time Transit Standards

• Service Interface for Real-Time Information (SIRI)• Real Time System Management Information Program

(RTSMIP) provides traceability between requirements and SIRI Design

• Transit Communications Interface Profiles (TCIP)• RTSMIP provides traceability between requirements and TCIP

Design

• General Transit Feed Specification – realtime (GTFS-RT)• Not an actual standard, but a very popular specification• No mapping in RTSMIP• A mapping of GTFS-RT design to RTSMIP requirements will be

developed

21

Open Standards

Enabling Services that Matter

Because of GTFS Everyone Now Knows How to Take a Bus

National ITS Architecture –

Vision for Interoperability

APTA TCIP – Communications Between Devices

BG (Before Google)

BG – Multi-Agency Data Challenges

GTFS – Boring Tables

Google Transit –

Universal Ability to Use Transit Anywhere

Boring Tables – Changing Everything

Apps and Integrated Information

GTFS Real-Time – Emerging

Did Google Solve All of Our Problems?

Operational and Backend Systems

• Payment systems (Fares, parking, etc)

• Dispatching and Active Management Integration (ICM)

• Paratransit, demand responsive services

• Passenger Counting, service planning, Reporting

• Connected Vehicle

Conclusion

• Vision of Interoperability and efficient scaling of technology, nationally, across public agencies remains important;

• GTFS, as an open standard, created a marketplace beyond the wildest dreams of the National ITS Architecture and Standards;

• Google did not do this out of dedication to the National vision of interoperability – they wanted to provide a “service that matters” to customers;

• Achieving efficiencies in ITS transit deployment (for operations) likely goes beyond the purpose or goals of GTFS Community;

• What role do Federal standards play in building on what GTFS has taught us?

12

The USDOT Real-Time System

Management Information Program

ITS-NY 22nd Annual Meeting

Saratoga Springs, NY

June 11-12, 2015

Arthur T. O’Connor, Ph.D., P.E.

Overview

• Background & Purpose

• Data Exchange Format Specification (DXFS)

• DXFS Implementation Guidance

• Contact Information

2

Background & Purpose

• Section 1201 of SAFETEA-LU required a real-time system

management information program in all States

• The capability to monitor, in real time, the traffic & travel

conditions of major highways, and to share that

information to improve the security of the network

• To address congestion, to support response to weather

events & transportation incidents, and facilitate traveler

information.

• SAFETEA-LU also required a data exchange format to be

established to ensure that the data provided by highway &

transit monitoring systems can readily be exchanged across

jurisdictional boundaries.3

Background & Purpose (Cont’d)

• The initial requirements: 23 CFR 511 was developed which required each state to establish & operate a Real-Time System Management Information Program (RTSMIP) capable of gathering and making available (not delivery) the data for traffic and travel conditions.

• The development of a Data Exchange Format Specification (DXFS) and Implementation Guidance was in response to the second provision in SAFETEA-LU

• Section 1201 addresses the requirements of RTSMIP as Regional ITS Architectures are reviewed and updated

4

Background & Purpose (Cont’d)

• Scope of the policy: Monitor and share regional traffic and

travel condition information

• Transportation System Performance

- Travel time

- Speed

• Capacity Reduction

- Construction activities

- Roadway or lane blocking incidents

• Traffic Disturbances

- Roadway weather observations

5

Background & Purpose (Cont’d)

Timeliness of InformationCategory of Information

Metropolitan areas ‡ Non-Metropolitan areas †

Construction 10 minutes 20 minutes

Traffic Incidents 10 minutes 20 minutes

Adverse Weather 20 minutes 20 minutes

Travel Times (limited access roads)

10 minutes N/A

† Interstate Routes

‡ Interstate Routes plus “Routes of Significance”

Background & Purpose (Cont’d)

• DXFS is developed to assist users

• To specify and implement an RTSMIP, and

• Support the need of States for a specification that satisfies

the rule.

• DXFS not only covers all the information defined in 23 CFR

511, but also extends to include transit information and

additional traffic information that is relevant to the

exchange of data between agencies and others.

7

DXFS Scope

• DXFS can be used to define the information exchanges across

system-to-system interfaces

• Provides interoperability of systems that implement the

DXFS.

• DXFS does not specify communication protocols

– Identifies standards at the Information level.

– Refers to existing standardized protocols that can be

used for transferring the data.

8

DXFS Objective

• Primary objective of the DXFS is to establish a standards-

based specification of key RTSMIP interfaces.

• Scope of the DXFS is the set of interfaces used to send

traffic, transit, transportation-related weather, and traveler

information from one agency to another.

• Provision of data directly to travelers is not part of the

scope of the specification.

• DXFS was developed with consideration of the many

stakeholders’ independent goals & objectives

• Used a Systems Engineering process of verification &

validation at each key stage of the DXFS development.

9

Audiences for DXFS

The DXFS has been developed to assist the following groups of users

to specify, implement, or support an RTSMIP:

• Transportation Agencies includes state DOTs & regional

transportation-related organizations (e.g., a municipal DOT, Public

Works, or a transit agency)

• Public Safety Agencies includes state, county, or local public safety

agencies

• Traveler Information Organizations (Public or Private). This group

includes providers of traveler information whether public or private

• Development Contractors. This group includes contractors who

have been hired to develop procurement packages or to develop

RTSMIP-related projects

10

DXFS Interfaces

TransportationAgency Systems

Peer TransportationAgency Systems

Public SafetyAgency Systems

Other PublicAgency Systems

Private Data CollectionOrganization Systems

TransitAgency Systems

Public Traveler InformationProvider Systems

Private Third-Party Systems

Travelers

Legend:Interfaces that are the subject of the DXFSAdditional interfaces

11

DXFS Implementation Guidance

• Developed as a companion to the DXFS

• Contains examples to help guide users through using the DXFS

Guidance: http://www.ops.fhwa.dot.gov/publications/fhwahop13046/

DXFS: http://www.ops.fhwa.dot.gov/publications/fhwahop13047/

12

DXFS Implementation Guidance

Contents:

• Section 1: Introduction

• Section 2: User Needs Identification

• Section 3: Requirements Identification

• Section 4: Systems Design Reference

• Section 5: Implementation Issues

• Section 6: Testing

13

User Needs

• User Needs are organized around the four information areas

described in 23 CFR 511 plus two additional areas:

1. Transit related information, and

2. Road network information

• The resulting six categories of user needs are:

• Travel Time

• Incident Information

• Construction Information

• Weather Information

• Transit Information

• Road Network Information

14

Travel Time User Needs

• Speed Data for Roads. To manage networks to reduce

congestion.

• Travel Time Data for Roads. To provide traveler information.

• Speed Data for Public Traveler Information Providers.

• Travel Time Data for Public Traveler Information Providers.

To receive travel time data on limited access or arterial roads.

• Travel Time Data for Parties who Create Value added

Information Products.

• Transit Vehicle Travel Time. To provide transit vehicle travel

times to travelers, travel information providers and other

parties.

15

Incident Information User Needs• Incident Information from Public Safety for Network Management.

• Incident Information from Public Safety for Traveler Information.

• Incident Information from Transportation Agencies for Public Safety Centers.

• Incident Information from Peer Transportation Agencies. To support regional incident management.

• Incident Information for Transit Agencies. To reroute or inform passengers of delays if necessary.

• Incident Information for Public Traveler Information Providers.

• Incident Information for Parties who Create Value added Information Products. Private third party providers.

• Planned Event Information for Traveler Information.

• Planned Event Information for Peer Transportation Agencies and Other Parties. To distribute planned event information to peer transportation agencies, public traveler information providers, and private third parties.

16

Construction Information User

Needs

• Construction Information for Traveler Information. Current road or lane closures for traveler information.

• Construction Information for Road Management. Current road or lane closures to implement road management and rerouting strategies.

• Construction Information for Peer Transportation Agencies and Other Parties. Current road or lane closures to peer transportation agencies, public traveler information providers, private third party providers and other agencies.

17

Weather Information User Needs

• Road Weather Environmental Conditions Data to support Traveler Information.

• Road Weather Environmental Conditions Data for Maintenance Operations. Surface treatment, snow plowing, etc.

• Receive Forecasts of Upcoming Adverse Weather Related Conditions. To provide traveler information.

• Provide Forecasts of Upcoming Adverse Weather Related Conditions. Send forecasts of upcoming adverse weather conditions to peer transportation agencies, public traveler information providers, private third parties, and other agencies to support traveler information or other operations.

• Road Weather Information for Peer Transportation Agencies and Other Parties. Provide RWIS information that might restrict or adversely affect travel to peer transportation agencies, public traveler information providers, private third parties and other public agencies.

18

Transit Information User Needs

• Real Time Bus Locations. Share real time bus locations with peer transportation/transit agencies, public traveler information providers, private third party providers, and travelers.

• Real Time Transit Passenger Loading. Share real time transit vehicle passenger loading with peer transit agencies, public traveler information providers and private third parties.

• Predicted Bus or Train Arrival/Departure Times. Share predicted bus or train arrival or departure times with peer transit agencies, public traveler information providers, and private third party providers.

19

Roadway Network

Information User Needs

• Roadway Network and Device Information.

Complete definition of the road network

relevant to the real time information is needed

by agencies / organizations to understand &

interpret the information.

20

Systems Requirements

• DXFS systems requirements define the formal requirements to satisfy

all user needs

• Needs-to-Requirements-Traceability-Matrix traces each user need

to one or more requirements.

• The functional requirements are presented in two broad categories as

follows:

• Data Exchange and Operational Environmental Requirements.

Define the required behavior of the system in exchanging data

across the communications interface based upon the features

identified in this document.

• Architectural Requirements. Define management of the interface

connections between centers, i.e., connection management, error

handling, and the two basic methods of making connections (e.g.,

request/response and subscription/publication).21

Standards Referenced by the DXFS

22

DXFS Functional Area

Standard Description of Standard

Traffic Management TMDD The Traffic Management Data Dictionary (TMDD) provides for information and control exchanges related to real-time roadway and traffic information, incidents, construction, and roadway weather.

Transit Management

TCIP The Transit Communications Interface Profile (TCIP) covers transit communications between centers, and centers and transit vehicles. TCIP provides traveler information on real-time transit vehicle location, and predicted transit vehicle arrival/departure.

Transit Management

SIRI The Service Interface for Real time Information covers transit communications between centers, and centers and transit vehicles. SIRI provides traveler information on real-time transit vehicle location, predicted transit vehicle arrival/departure, and predicted transit trip travel time.

National Weather Service Weather Alerts

OASIS CAP The Common Alerting Protocol (CAP) is a simple but general format for exchanging all-hazard emergency alerts and public warnings over all kinds of networks. CAP allows a consistent warning message to be disseminated simultaneously over many different warning systems, thus increasing warning effectiveness while simplifying the warning task.

Remaining Sections of DXFS Guidance

• Section 5: Implementation Issues –

Communications framework, interoperability

beyond compatibility, legacy systems

• Section 6: Testing – Development of test

documentation to test system interface

specification compliance, i.e., the system

interface implementation is tested against the

requirements specified for the project

23

FHWA HQ Contacts

Bob Rupert, FHWA

Transportation Information Team Leader

Robert.Rupert@dot.gov

202-366-2194

Kingsley Azubike, FHWA

ITS Standards Implementation

Kingsley.Azubike@dot.gov

717-221-3701

Web site: www.ops.fhwa.dot.gov/1201

Thank You!24

Regional All-Electronic Tolling:

Overcoming Institutional

Challenges

Panel 3: Bridging Institutional Boundaries to Make a Difference

ITS-NY 22nd Annual Meeting

Allison L. C. de Cerreño, Ph.D.

Assistant Director, Tunnels, Bridges and Terminals

Port Authority of NY & NJ

Port Authority Toll Facilities

Facilities

• 2 tunnels: Lincoln and Holland

• 4 bridges: George Washington, Goethals, Bayonne,

and Outerbridge Crossing

• 8 toll plazas: 72 toll lanes

2014 Traffic: 114 million (eastbound only)

2014 Toll Revenue: $1.4B

Benefits of E-ZPass

No Stopping to Pay Tolls

• Less fuel consumed

• Less congestion

Improved Air Quality

• Reduced vehicle emissions

Regional Seamless Travel

• 26 Toll Agencies across 15 States

From: E-ZPass Group, http://www.e-zpassiag.com/about-e-zpass.

E-ZPass – How It Works

E-ZPass Customers

• Patron establishes pre-paid

account, linked to a tag in the

vehicle

• Tag is read in the toll lane

• Toll is deducted from the

Patron’s account

GOE-ZPASS

Driver Feedback

Sign (DFS)and Traffic Light

Rear VESCamera

Front VESCamera

Treadle

AVI Antenna

Canopy Traffic Light

Overhead Vehicle Profiler

Mark IVRFID Tag

ABC-123

Lane Mode Sign (LMS)SM

Violators

– Image taken of license plate

– Look-up request sent to appropriate DMV

– DMV address information is used to issue a “failure to pay” or

“notice of violation” to the registered owner of the vehicle

From Electronic Tolling to All-Electronic Tolling

• Electronic Tolling (Cash and E-ZPass)

• No stopping to pay toll for customers with tags

• Requires a tag in vehicle

• Treats owners of vehicles without tags as violators

• All-Electronic Tolling (AET)

• No stopping to pay toll for everyone

• Customers without tags are no longer treated as

violators at the point of toll

Goals and Benefits of All-Electronic Tolling (AET)

Regional Mobility

• No stopping to pay tolls

Air Quality

• Emissions reductions

Safety

• Reduced merging

Costs

• Capital & Operating Cost

reductions

Challenges

Technical

• Recognizing license plates

from multiple states

• Specific challenges for

bridges and tunnels

Business/Financial

• Moving the model from pre-

pay/pay at point to post-pay

• Ability to address scofflaws

effectively

Customer-related

• Multi-jurisdictional environment

• Providing cash alternatives beyond the plaza

MdTADTRGGB

NTTA

TxDOT(Austin)

HCTRA

THEA

FTE

MDX

NCTA

ERC

DRTBC

PTCPANYNJ

MTA B&T

NET RMA

BHICTRMA (Austin)

BATA

WSDOTSR520

MDC

CFX (Wekiva Pkwy)

E470

FDOT

NYSTA

TCA

NWPKWY

ISTHA

KIPDA

SNJB

Source: Atkins, NA

Current and Planned Regional AET Facilities

MTA Triborough Bridges & Tunnels Authority

• Henry Hudson Bridge (2012)

Port Authority of NY & NJ

• Bayonne Bridge (2016)

New York State Thruway Authority

• Tappan Zee Bridge (2015)

Beyond AET?

Other Point of Travel Technologies• Weigh-in-Motion

• GPS

Mileage-Based User Fees• Odometers

• Smart phones

• GPS

• Onboard units

Source: http://www.irdinc.com/library/pdf/Role-for-Weigh-In-Motion-

Finalpaper.pdf