Transit Module 23: Leveraging Communications Technologies for Transit On-board Integration

HTML of the Student Supplement

(Note: This document has been converted from the Student Supplement to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included, plus additional text descriptions for the images, photos and/or diagrams have been provided below.)


Module 23: Leveraging Communications Technologies for Transit On-board Integration

 

Table of Contents

Introduction/Purpose - 2

Samples/Examples - 2

Reference to Other Standards - 19

Case Studies - 23

Glossary - 23

References - 25

Study Questions - 26

 

Module Description

There are a wide variety of onboard transit technologies and they are integrated using several types of communications technologies. These onboard technologies facilitate and automate operations, management, maintenance, traveler information, safety, and security functions of public transit systems. With the advent of newer communication technologies, onboard technologies can be integrated via an onboard transit architecture that is comprised of on-board devices, communications pathways (on and to/from the vehicle), functionality, and interfaces to the vehicle. Onboard devices include a mobile data terminal (MDT), vehicle logic unit (VLU) (sometimes combined with an MDT), equipment to support supervisory and support functions (e.g., ruggedized laptop), Automated Vehicle Announcement (AVA) System (covered in Modules 6 and 7), Automatic Passenger Counter (APC) System (covered in Modules 2 and 5), an Event Data Recorder System (EDRS) and Vehicle Component Monitoring (VCM) (covered in Modules 2 and 5), and Onboard Video Surveillance System (covered in Modules 2 and 5). Module 19 provides details of how to use onboard hardware and software standards and provides case studies and examples that demonstrate how to procure systems that use these standards.

 

1. Introduction/Purpose

This module provides details on how to leverage current communication technologies to integrate onboard devices and provides case studies and examples that demonstrate the use of these technologies. The information in this module will help participants further understand those communication technologies that support the integration of onboard transit devices for buses, specifically Internet of Things (IoT) Gateways, Mobile Gateway Router (MGR), future second generation onboard architectures and the evolution of onboard IoT edge logic. Topics that will be covered in this module include current and future on-board architectures, IoT gateways, moving onboard functionality to the cloud, and transit agency considerations.

 

2. Samples/Examples

2.1. Los Angeles County Metropolitan Transportation Authority (LA Metro) Transit Signal Priority (TSP) Concepts

LA Metro conducted a TSP concept development activity that resulted in the following:

 

Please see Extended Text Description below.

(Extended Text Description: Figure 1. V2I Connected Vehicle Concept has a graphic showing an LA Metro, Metro Rapid bus in the lower right-hand side of the figure, a signal cabinet in the lower left-hand side of the slide, TOC graphic above the bus to the right, a cloud to the left of the TOC graphic, and legend in the upper left-hand corner of the figure. The front of the bus is pointed toward the left-hand side of the slide.

Inside the front of the bus is a graphic labeled "VLU." It is connected using a blue line to a graphic for a GPS antenna, which is sitting on top of the bus right above the VLU. There is a light blue box located in the lower right-hand part of the VLU labeled "DTRP" and a blue box under the VLU labeled "GPS."

Connected to the right of the VLU via a blue line is a graphic labeled "MGR." There is one small blue box right below the MGR labeled "SIM." The MGR is connected using a blue line to a blue box above it labeled "CV Radio." The CV Radio is connected via a blue line to a graphic for a DSRC Antenna, which is sitting on top of the bus right above the MGR.

Also, the MGR is connected via a blue line to a graphic for a Cellular Antenna, which is sitting on top of the bus to the right of the DSRC Antenna.

The MGR is connected via a blue line to nine unlabeled boxes to the right of the MGR representing other on-board systems.

The Cellular Antenna is connected to a cloud labeled "Commercial Cellular Network" via a lightning bolt. This cloud is connected to a graphic to its right representing a TOC via a blue line. Below the TOC is a blue box labeled "CAD."

The DSRC Antenna is connected via a lightning bolt to a DSRC Antenna located on the top of the Signal Cabinet. Within the Signal Cabinet are four elements on top of each other. The blue box at the bottom of the Signal Cabinet is labeled "Signal Controller." The Signal Controller is connected to a graphic representing a PC above the Signal Controller via a blue line. In the lower right-hand corner of the PC is a light blue box labeled "DTGP." The PC is connected via a blue line to a graphic representing a Switch, which is right above the PC. The Switch is connected via a blue line to a blue box labeled "Roadside CV Radio." The Roadside CV Radio is connected via a blue line to the DSRC Antenna, which is located on top of the Signal Cabinet.

Next to the PC are the words "See Note 1." Note 1 states "Local intersection PC is required only if controller is not an Advanced Traffic Controller (ATC). If traffic agency has upgraded to ATC, the BSP application and DTGP can reside on the controller."

Next to the DTGP box are the words "See Note 2." Note 2 states "DTGP functionality may reside on either PC or controller, depending on architecture."

The Signal Controller is connected to a traffic signal located to the left of the Signal Cabinet via a blue line.

The legend to the abbreviations on the slide is located in the upper left-hand corner of the figure as follows:

)

Figure 1. V2I Connected Vehicle Concept (courtesy of Ed Alegre, LA Metro)

 

Please see Extended Text Description below.

(Extended Text Description: Figure 2. V2I Cellular to Isolated Signal has a graphic showing an LA Metro Rapid bus in the lower right-hand side of the figure, a Signal Cabinet (Isolated) in the lower left-hand side of the slide, TOC graphic above the bus to the right, a cloud to the left of the TOC graphic, and legend in the upper left-hand corner of the figure. The front of the bus is pointed toward the left-hand side of the slide.

Inside the front of the bus is a graphic labeled "VLU." It is connected using a blue line to a graphic for a GPS antenna, which is sitting on top of the bus right above the VLU. There is a light blue box located in the lower right-hand part of the VLU labeled "DTRP" and a blue box under the VLU labeled "GPS."

Connected to the right of the VLU via a blue line is a graphic labeled "MGR." There is one small blue box right below the MGR labeled "SIM." The MGR is connected via a blue line to a graphic for a Cellular Antenna, which is sitting on top of the bus above the MGR. The MGR is connected via a blue line to nine unlabeled boxes to the right of the MGR representing other on-board systems.

The Cellular Antenna is connected to a cloud labeled "Commercial Cellular Network" via a lightning bolt. This cloud is connected to a graphic to its right representing a TOC via a blue line. Below the TOC is a blue box labeled "CAD."

The Commercial Cellular Network cloud is connected via a lightning bolt to the top of the Signal Cabinet (Isolated) which is located to the left of the bus. Within the Signal Cabinet are three elements on top of each other. The blue box at the bottom of the Signal Cabinet is labeled "Signal Controller." The Signal Controller is connected to a graphic representing a PC above the Signal Controller via a blue line. In the lower right-hand corner of the PC is a light blue box labeled "DTGP." The PC is connected via a blue line to a graphic representing a Router, which is right above the PC. The Router has a small blue box below it labeled "SIM."

The Signal Controller is connected to a traffic signal located to the left of the Signal Cabinet (Isolated) via a blue line.

The legend to the abbreviations on the slide is located in the upper left-hand corner of the figure as follows:

)

Figure 2. V2I Cellular to Isolated Signal (courtesy of Ed Alegre, LA Metro)

 

Please see Extended Text Description below.

(Extended Text Description: Figure 3. V2C Cellular to Centralized TMC has a graphic showing an LA Metro, Metro Rapid bus in the lower right-hand side of the slide, a Signal Cabinet in the lower left-hand side of the slide, a Signal Cabinet in the upper left-hand side of the slide, a TMC graphic to the right of the Signal Cabinet in upper left-hand side of the slide, another TMC graphic just above the bus and to the right of the Signal Cabinet in the lower left-hand side of the figure, TOC graphic above the bus to the right, and a Commercial Cellular Network cloud to the left of the TOC. The front of the bus is pointed toward the left-hand side of the slide.

Inside the front of the bus is a graphic labeled "VLU." It is connected using a blue line to a graphic for a GPS antenna, which is sitting on top of the bus right above the VLU. There is a light blue box in the lower right-hand corner of the VLU labeled "DTRP." There is a blue box below the VLU to the left labeled "GPS."

Connected to the right of the VLU via a blue line is a graphic labeled "MGR." There is one small blue box right below the MGR labeled "SIM." The MGR is connected using a blue line to a graphic for a Cellular Antenna, which is sitting on top of the bus right above the MGR. The MGR is connected via a blue line to nine unlabeled boxes representing other on-board systems.

The Cellular Antenna is connected to a cloud labeled "Commercial Cellular Network" via a lightning bolt. This cloud is connected to a graphic to its right representing a TOC via a blue line. Below the TOC is a blue box labeled "CAD."

The Commercial Cellular Network cloud is connected via a lightning bolt to a graphic labeled "TMC (Agency X)." Below TMC (Agency X) is a blue box labeled "PRS." The PRS box contains a small light blue box labeled "DTGP." The TMC (Agency X) is connected via a blue line to a blue box inside of the Centralized Signal Cabinet (located in the lower left-hand side of the figure) labeled "Field Communication Hub." The Field Communication Hub is connected via a blue line to a blue box labeled "Signal Controller" located just below the Field Communication Hub inside the bottom of the Centralized Signal Cabinet. The Signal Controller is connected via a blue line to a traffic signal located to the left of the Centralized Signal Cabinet.

The "Commercial Cellular Network" cloud is also connected via a lightning bolt to a graphic labeled "TMC (Agency 1)." Below TMC (Agency 1) is a blue box labeled "PRS." The PRS box contains a small light blue box labeled "DTGP." The TMC (Agency 1) is connected via a blue line to a blue box inside of the Centralized Signal Cabinet (located in the upper left-hand side of the figure) labeled "Field Communication Hub." The Field Communication Hub is connected via a blue line to a blue box labeled "Signal Controller" located just below the Field Communication Hub inside the bottom of the Centralized Signal Cabinet. The Signal Controller is connected via a blue line to a traffic signal located to the left of this Centralized Signal Cabinet.

There are three blue dots between the traffic light in the upper left-hand side of the figure and the traffic light in the lower left-hand side of the figure.

There are three blue dots between the two Centralized Signal Cabinets.

There are three blue dots between the TMC (Agency 1) and TMC (Agency X).

The legend to the abbreviations located in the upper right-hand corner of the figure is as follows:

)

Figure 3. V2C Cellular to Centralized TMC (courtesy of Ed Alegre, LA Metro)

 

Please see Extended Text Description below.

(Extended Text Description: Figure 4. C2C Fully Centralized TOC and TMC has a graphic showing an LA Metro, Metro Rapid bus in the lower right-hand side of the slide, a Signal Cabinet in the lower left-hand side of the slide, a Signal Cabinet in the upper left-hand side of the slide, a TMC graphic to the right of the Signal Cabinet in upper left-hand side of the slide, another TMC graphic just above the bus and to the right of the Signal Cabinet in the lower left-hand side of the figure, TOC graphic above the bus, and a Commercial Cellular Network cloud to the right of the TOC. The front of the bus is pointed toward the left-hand side of the slide.

Inside the middle of the bus is a graphic labeled "MGR." There are two small blue boxes right below the MGR labeled "SIM" and "GPS." The MGR is connected using a blue line to a graphic for a GPS Antenna, which is sitting on top of the bus right above the MGR. The MGR is also connected via a blue line to the graphic for a Cellular Antenna, which is sitting on top of the bus to the right of the GPS Antenna. The MGR is connected via a blue line to nine unlabeled boxes (located to the right of the MGR) representing other on-board systems.

The Cellular Antenna is connected to a cloud labeled "Commercial Cellular Network" via a lightning bolt. This cloud is connected to a graphic above it representing a TOC via a blue line. Below the TOC is a blue box labeled "CAD" and a blue box under the CAD box labeled "PRG." There is a light blue box in the lower right-hand part of the PRG labeled "DTRP."

The TOC is connected via a blue line to another blue line that connects two graphics representing two TMCs – one labeled "TMC (Agency 1)" located above the second labeled "TMC (Agency X)."

Below TMC (Agency 1) is a blue box labeled "PRS." The PRS box contains a small light blue box labeled "DTGP." The TMC (Agency 1) is connected via a blue line to a blue box inside of the Centralized Signal Cabinet (located in the upper left-hand side of the figure) labeled "Field Communication Hub." The Field Communication Hub is connected via a blue line to a blue box labeled "Signal Controller" located just below the Field Communication Hub inside the bottom of the Centralized Signal Cabinet. The Signal Controller is connected via a blue line to a traffic signal located to the left of this Centralized Signal Cabinet.

Below TMC (Agency X) is a blue box labeled "PRS." The PRS box contains a small light blue box labeled "DTGP." The TMC (Agency X) is connected via a blue line to a blue box inside of the Centralized Signal Cabinet (located in the lower left-hand side of the figure) labeled "Field Communication Hub." The Field Communication Hub is connected via a blue line to a blue box labeled "Signal Controller" located just below the Field Communication Hub inside the bottom of the Centralized Signal Cabinet. The Signal Controller is connected via a blue line to a traffic signal located to the left of the Centralized Signal Cabinet.

There are three blue dots between the traffic light in the upper left-hand side of the figure and the traffic light in the lower left-hand side of the figure.

There are three blue dots between the two Centralized Signal Cabinets.

There are three blue dots between the TMC (Agency 1) and TMC (Agency X).

The legend to the abbreviations located in the upper right-hand corner of the figure is as follows:

)

Figure 4. C2C Fully Centralized TOC and TMC (courtesy of Ed Alegre, LA Metro)

 

In addition to these four concepts, LA Metro developed a next generation TSP concept that has the "cloud" as the key component as shown in Figures 5, 6, and 7. For this LA Metro next-gen concept, the cloud performs four main functions:

 

Please see Extended Text Description below.

(Extended Text Description: Figure 5. TSP as a Service (TSPaaS) has a graphic showing an LA Metro, Metro Rapid bus in the lower right-hand side of the slide, a Signal Cabinet in the lower left-hand side of the slide, a Signal Cabinet in the upper left-hand side of the slide, TMC graphic to the right of the Signal Cabinet in upper left-hand side of the slide, TOC graphic above the bus to the right, and several clouds and a circle representing the Internet. The front of the bus is pointed toward the left-hand side of the slide.

Inside the front of the bus is a graphic labeled "VLU." It is connected using a blue line to a graphic for a GPS antenna, which is sitting on top of the bus right above the VLU. Connected to the right of the VLU via a blue line is a graphic labeled "MGR." There are two small blue boxes right below the MGR labeled "SIM" and "GPS.". The MGR is connected using a blue line to a graphic for a Cellular Antenna, which is sitting on top of the bus right above the MGR. The MGR is connected via a blue line to nine unlabeled boxes to the right of the MGR representing other on-board systems.

The Cellular Antenna is connected via a lightning bolt to a blue box labeled "CAD" which is located right below a TOC graphic. The Cellular Antenna is also connected to a cloud labeled "Commercial Cellular Network" via a lightning bolt. This cloud is connected to a graphic representing a Router inside of the Signal Cabinet that is located in the lower left-hand side of the slide. Right below this Router is a small blue box labeled "SIM." Connected to the Router via a blue line is a blue box right under the Router labeled "Signal Controller." This Signal Controller is connected to a traffic signal (located to the left of the Signal Controller) via a blue line.

The TOC is connected via a lightning bolt to a cloud labeled "Transit Operations Platform." In the lower right-hand corner of this cloud is a light blue box labeled "DTRP." This cloud is connected via a blue line labeled "API Access" to a gray circle labeled "Internet." The cloud labeled "Commercial Cellular Network" is connected to the same gray circle labeled "Internet" via a blue line.

The Signal Cabinet located in the upper left-hand side of the slide contains two blue boxes. The box in the top of the Signal Cabinet is labeled "Field Communication Hub." The Field Communication Hub is connected via a blue line to the blue box labeled "Signal Controller" which is located directly below the Field Communication Hub. The Signal Controller is connected to a traffic signal located to the left of the Signal Cabinet via a blue line.

The Signal Cabinet in the upper left-hand side of the slide is connected to a graphic representing a TMC via a blue line. The TMC is located to the right of this Signal Cabinet. The TMC is connected via a lightning bolt to a cloud labeled "Signal System Platform." There is a blue box labeled "DTGP" located in the lower right-hand portion of this cloud. This Signal System Platform cloud is connected via a blue line labeled "API Access" to the circle labeled "Internet."

Right above the TOC graphic is a legend to the abbreviations on the slide as follows:

)

Figure 5. TSP as a Service (TSPaaS) (courtesy of Ed Alegre, LA Metro)

1 DKS Associates, "The Next Generation of Transit Signal Priority: Cloud Computing and the TSP-as-a-Service Model," presentation at 2017 ITS California Annual Meeting, September 30, 2017. Used with permission of DKS.

 

Please see Extended Text Description below.

(Extended Text Description: Figure 6. TSP-as-a-Service Inputs has a cloud in the center of the figure labeled "TSPaaS Cloud." Under this cloud are the following words:

Core functions:

In the upper left-hand portion of the figure is a blue box labeled "Traffic Agency ATMS." A line with an arrow at the end connects this blue box to the TSPaaS Cloud. Under the Traffic Agency ATMS are the following:

In the lower left-hand portion of the figure is a blue box labeled "Isolated Signal." A line with an arrow at the end connects this blue box to the TSPaaS Cloud. Under the Isolated Signal are the following:

In the lower right-hand portion of the figure is a blue box labeled "Bus." A line with an arrow at the end connects this blue box to the TSPaaS Cloud. Under the Bus are the following:

In the upper right-hand portion of the figure is a blue box labeled "Transit Agency." A line with an arrow at the end connects this blue box to the TSPaaS Cloud. Under the Transit Agency are the following:

)

Figure 6. TSP-as-a-Service Inputs (courtesy of Elliot Hubbard, DKS Associates)

 

Please see Extended Text Description below.

(Extended Text Description: Figure 7. TSP-as-a-Service Outputs has a cloud in the center of the figure labeled "TSPaaS Cloud."

In the upper left-hand portion of the figure is a blue box labeled "Traffic Agency ATMS." A line with an arrow at the end connects the TSPaaS Cloud to this box. Under the Traffic Agency ATMS is the following:

Below the Traffic Agency ATMS box is a blue box labeled "Isolated Signal." A line with an arrow at the end connects the TSPaaS Cloud to this box. Under the Isolated Signal is the following:

At the bottom of the figure is a blue box labeled "Third Parties." A line with an arrow at the end connects the TSPaaS Cloud to this box. Next to this box is the following:

In the middle right-hand portion of the figure is a blue box labeled "Bus." A line with an arrow at the end connects the TSPaaS Cloud to this box.

In the upper right-hand portion of the figure is a blue box labeled "Transit Agency." A line with an arrow at the end connects the TSPaaS Cloud to this box. Under the Transit Agency are the following:

)

Figure 7. TSP-as-a-Service Outputs (courtesy of Elliot Hubbard, DKS Associates)

 

2.2. Capital District Transportation Authority (CDTA) Intelligent Transportation Management System (ITMS) - Albany, NY

The Capital District Transportation Authority (CDTA) in Albany, NY conducted a major procurement to replace their aging CAD/AVL system. Within this procurement, there was a requirement for OnBoard Mobile Routers/ Wireless Gateways. The requirement for On-board Mobile Gateway Routers (OMGRs) was included in the specifications in Section 5.2.3. This section of the specifications is contained on the next five pages.

Other portions of Request for Proposal referring to the OMGRs are as follows:

 

Capital District Transportation Authority Intelligent Transportation Management System - Excerpts below:


 

Capital District Transportation Authority Intelligent Transportation Management System

 

5 Wireless Data Communication Requirements

5.1 General

The Contractor shall describe the data communication infrastructure required to satisfy the following communication needs for this project:

The Contractor shall identify the specific on-board and central hardware and software that will be required to establish wireless communication infrastructure.

The Contractor shall identify the necessary cellular data requirements for their proposed solution and include pricing in the cost proposal.

The Contractor is encouraged to utilize the P25 Radio Communications System Enhanced Data feature to satisfy the wireless data communication functional specifications defined herein. Alternative wireless data communications solutions will be subject to CDTA approval prior to Contract Award.

The Contractor shall provide design documentation and demonstrations for the integration of the new P25 radio communications system for data radio and other wireless data communications requirements for CDTA review at the Preliminary Design Review and for approval at the Final Design Review. PDR FDR 5.1

 

5.2 Wireless Data Communications

5.2.1 Data Transfer

The Contractor shall describe the ITMS data communications between the CDS and all other ITMS systems, equipment, components, and devices (e.g. the mobile systems on vehicles). Data communications at stations/stops, and/or Kiosks shall be provided through an established commercial cellular service provider. The types of data to be communicated shall include, at minimum:

The complete list of data transfer information requirements and design shall be provided to CDTA for review at the Preliminary Design Review and approval at the Final Design Review. PDR FDR 5.2.1

5.2.2 On-Board Hardware

5.2.2.1 Data Communication Hardware

The Contractor shall use the P25 Radio Communications System Enhanced Data features and the associated hardware for meeting the ITMS data communication needs on vehicles. In the event existing data radio hardware is insufficient in meeting the ITMS requirements, the Contractor shall present an alternate data radio solution for CDTAs approval prior to Contract Award.

5.2.2.2 Antenna Hardware

If applicable, proposed antenna hardware shall help limit the number of antenna hardware to be installed on each vehicle. An antenna which can support a combination of global positioning system (GPS) connections, cellular network connection and wireless fidelity (Wi-Fi) connection using a single unit (e.g., dual-mode antenna, tri-band antenna) may be used for the proposed solution. The Contractor must use low-profile antenna hardware.

5.2.2.3 Driver Handset and Speaker

The CAD/AVL vendor must integrate with the P25 Radio Communications System's telephone handset with PTT button and a hang-up cup (e.g. Audio Sears or similar).

Vehicle operators shall be able to adjust the volume of the speaker at any time during the voice communication.

5.2.3 On-Board Mobile Router/Wireless Gateway 5.2.3.1 Hardware and Connectivity

The Contractor shall provide an On-board Mobile Gateway/Router (OMGR) for CDTA vehicles to accomplish wired and wireless connectivity.

The OMGR shall comply with on-board hardware requirements described herein. The OMGR shall provide the following connectivity capabilities:

The Contractor shall provide the required OMGR ITMS data communications design to CDTA for review and demonstration at the Preliminary Design Review and approval at the Final Design Review. PDR FDR 5.2.3.1

5.2.3.2 OMGR Data Communications Requirements

The OMGR shall support quality of service (QoS) to ensure protected bandwidth for multiple sub-channels when multiple sub-channels are enabled for connectivity of individual on-board systems (e.g., CAD/AVL and video surveillance system).

The OMGR shall be configurable to control which on-board system can perform outbound communication based on the speed of data connection available at a given time (e.g., video transmission shall be allowed only when 4G cellular connectivity is available).

The OMGR shall have the ability to configure the data rate limits for inbound and outbound data communications.

The OMGR shall be able to automatically switch to an available network based on the agency configuration. The configuration parameters shall include but shall not be limited to available network(s) and their priorities, time of day, current geographic location and CDTA division. The OMGR shall automatically fallback to cellular communication in the event no data radio coverage is available.

The OMGR shall have the capability use port filtering/blocking to ensure only appropriate data traffic is routes on an available wireless network.

The port forwarding feature shall allow a host application at the central system (e.g., video Playback Software) to connect to a desired on-board system (e.g., DVR).

The OMGR shall support Dynamic Host Control Protocol (DHCP) for connected devices and provide the capability to turn on and off the DHCP server as needed.

The OMGR shall have at least ten (10) GB of built-in storage.

5.2.3.3 System Administration and Real-Time Management of OMGR

The Contractor shall provide OMGR central management software to enable authorized CDTA users the capability to manage and administer the following minimum features and functions of the OMGR.

5.2.3.4 OMGR MDT Connectivity

At minimum, the MDT shall be connected with the OMGR via Ethernet port for the following data exchange activities:

5.2.4 Central Wireless Communication Gateway Software 5.2.4.1 General

A wireless data communications gateway shall be established to carry data using CDTAs private radio data network. However, the system must have the ability to switch to an available cellular network using the OMGR, if configured by CDTA. In the event of cellular communication failure, the vendor shall establish a private secure tunnel configuration in coordination with the cellular carrier and CDTA.

The gateway shall have the ability to support multiple wireless networks, including private radio, cellular and Wi-Fi, simultaneously, if necessary.

The gateway shall be setup in a highly redundant configuration. The Contractor shall describe the redundancy functionality of the gateway.

The gateway shall provide the ability to monitor the communication traffic. Also, the gateway shall provide the ability to temporarily suspend the one-way or two-way wireless data communication path.

5.2.4.2 Data Message Processing

The system shall process data messages received from the vehicles and wayside digital message displays, and pass these messages to the central software.

The system shall process data messages received from the central software and pass these to an individual vehicle or a group of vehicles, or DMS, as applicable.

The system shall log and allow report generation on relevant details about each data message including but not limited to the following:

 

5.3 Garage Wireless Local Area Network (WLAN) Data Exchange

5.3.1 General

The Contractor shall supply, install, and configure a Garage Data Systems (GDS) and wireless data networks at each of the CDTA garage facilities where CDTA vehicles are parked and serviced. Via Wi-Fi communications, the GDS shall manage the secure and expedient transfer of all data transfers between the Central Data System and the ITMS equipment, components, and devices.

The system shall allow all ITMS static files including but not limited to schedules, announcements, service changes, firmware, parameters, configuration settings and other software to be set up so they will be automatically downloaded to vehicles when they connect with the WLAN, including a mechanism to avoid repeating a download to a vehicle that has already previously received it as well as to determine once all vehicles have received the download. The system shall automatically receive from vehicles once they connect to the WLAN any files they have ready for upload, including a mechanism to avoid repeating an upload from a vehicle that has already previously provided it.

The Contractor shall describe the bidirectional wireless data exchange design including all data transfers to and from the vehicle, vehicle coverage, location, and power requirements, and OMGR real-time data transfers and limitations, if applicable, with their proposal response.

 


 

2.3. Tri-County Metropolitan Transportation District of Oregon (TriMet) Hop Fastpass - Portland, OR

"The Tri-County Metropolitan Transportation District of Oregon (TriMet), the primary public transportation provider in Portland, [Oregon] utilized a novel approach to build the Hop Fastpass, its public transit payment system that first launched in 2017 and has steadily added new features."2

The next four pages show relevant portions of the specifications. The conceptual system diagram is shown on the page following the relevant portion of the specifications.

Another key requirement in the specifications is as follows: "The eFare system will be built using an account-based, open payment architecture with key system interfaces based on Application Programming Interfaces (APIs) that are published by the Contractor and fully owned or licensed by TriMet."

2 APTA MOBILITY INNOVATION PILOT OF THE MONTH: TriMet's Hop Fastpass Open Architecture in Fare Payment, webinar conducted on June 27, 2019

 

Appendix A/eFare Sys IntTech Specs - 84 Oct. 3, 2013 - Excerpts below:


 

6.2.1-8 Validators will be remotely configurable and managed through the system monitoring and management application (see Section 6.1.3). Validator software and configuration, including all white lists and hotlists will be managed through this system. CDRL6-12

6.2.2 Communications

Req# Requirement Assigned CDRL(s)
6.2.2-1 Onboard validators will be designed with an Ethernet port that enables connection to existing mobile data routers installed on TriMet and C-TRAN buses. Where available, the mobile data routers will serve as primary means of off-board communication with the eFare back office. CDRL6-12 CDRL6-13
6.2.2-2 Platform validators will be designed with an Ethernet port that enables direct connection to the eFare back office. CDRL6-12 CDRL6-13
6.2.2-3 All validators will include an embedded cellular communications interface that supports third generation (3G GSM/CDMA) and fourth generation (4G) Long-Term Evolution (LTE) data networks on all major U.S. carriers. The embedded cellular communications will be used in instances where a mobile data router or Ethernet connection is not available. CDRL6-12 CDRL6-13
6.2.2-4 All validators will include Wi-Fi (802.11a/b/g/n/ac) communications to enable integration with other systems, exchange of non-critical data at designated locations, and sharing of data connections on vehicles and at rail platforms. CDRL6-12 CDRL6-13
6.2.2-5 Validators will be designed with a spare USB port to support the future connection of an ancillary device, such as a barcode reader. CDRL6-12

6.2.3 CAD/AVL Integration

Req# Requirement Assigned CDRL(s)
6.2.3-1 Contractor shall be responsible for integration of the onboard payment validator with the INIT CAD/AVL system installed on TriMet and C-TRAN vehicles. The integration will use the Contractor-supplied CAD/AVL Integration API (see Section 2.2.3.8) and the embedded communication interfaces. CDRL6-12 CDRL6-13
6.2.3-2 Integration with the CAD/AVL systems will support single sign-on, the capture of geo-location data, and provide an auxiliary display and input device for the eFare system through the CAD/AVL operator control unit. CDRL6-13
6.2.3-3 Single sign-on will enable the CAD/AVL login and routing data, including operator ID, pattern, block, route, and direction, to be captured by the eFare validator. The login and routing data will be appended to every fare transaction generated by the eFare validator. CDRL6-13
6.2.3-4 The eFare validator will capture geo-location data generated by the CAD/AVL system, including Bus Stop ID and GPS coordinates. The geo-location data will be appended to every fare transaction generated by the eFare validator. Validators will also include an embedded global positioning system (GPS) receiver, and append local GPS coordinate information to each eFare transaction, in addition to and geo-location data provided by the CAD/AVL system. CDRL6-13
6.2.3-5 The CAD/AVL operator control unit will display fare payment results transmitted from the eFare validator, including fare payment approval or denial, and the case of approval, fare product and fare category associated with the transit account (e.g., adult, youth, or honored citizen) used for payment. CDRL6-13
6.2.3-6 The CAD/AVL operator control unit will be able to initiate a fare override function that will cause eFare validator to flag a fare transaction so that it is priced at a reduced fare, even if a full fare account is being used for payment. The fare override function will be configurable to support both open and closed-loop payments. CDRL6-13

6.2.4 Transaction Processing

Req# Requirement Assigned CDRL(s)
6.2.4-1 The eFare validators will automatically and continuously poll for all supported media formats. CDRL6-13
6.2.4-2 The eFare validators will be equipped with real-time communication to AMPS for the processing of fare payments using the Contractor-supplied fare payment API (see Section 2.2.3.3). CDRL6-12 CDRL6-13
6.2.4-3 Prior to transmitting a fare payment transaction to AMPS, the validators will perform local fare media validity checks, including checks against any locally maintained white lists and hotlists, as deemed necessary for security and the efficient processing of transactions. CDRL6-13
6.2.4-4 Validators will provide a payment result within 500 milliseconds of valid fare media being presented for all fare payment types. CDRL6-12 CDRL6-13
6.2.4-5 Validators will display fare payment results, including approval or denial, fare paid, fare product used for payment, remaining account balance, time remaining on transfers, and fare capping status, for all fare payments. CDRL6-13
6.2.4-6 Validators will be able to accept fare payments in an offline mode, and accommodate scenarios where a full authorization cannot be received within the required timeframe. In these scenarios, risk mitigation strategies will be employed to limit exposure for declined payments. CDRL6-12 CDRL6-13
6.2.4-7 Validators will provide no indication to the customer or operator when they are operating in offline mode. CDRL6-12 CDRL6-13
6.2.4-8 Validators will maintain a whitelist of all media linked to reduced fare accounts to enable indication of a reduced fare payment via the CAD/AVL operator control unit, even when the validator is operating in offline mode. CDRL6-12 CDRL6-13
6.2.4-9 All transactions generated in an offline mode will be sent to AMPS immediately upon restoration of communications. CDRL6-12 CDRL6-13
6.2.4-10 Validators will support an anti-collision algorithm to ensure that payment is only accepted from a single piece of media when multiple valid pieces of media are presented. CDRL6-13
6.2.4-11 The transaction processing algorithm will be subject to agency review and approval during design review. CDRL6-12 CDRL6-13

6.2.5 User Interface

Req# Requirement Assigned CDRL(s)
6.2.5-1 Validators will include a full color displays that supports adjustable brightness and contrast, and can be easily read under any combination of ambient lighting, including direct sunlight and night-time operation. CDRL6-11
6.2.5-2 Validators will include at least three (3) multicolor LED indicator lights that can be configured to provide feedback on payment and device status. CDRL6-11
6.2.5-3 Validators will include an audio interface and speakers for customizable audio feedback, including varying tones and full speech. CDRL6-11
6.2.5-4 Platform validators will include a 3.5mm headphone jack capable of providing customizable audio feedback. CDRL6-11
6.2.5-5 The visual and audio interfaces will provide visual and audible feedback on fare payment and device status that meets all ADA requirements. CDRL6-11 CDRL6-12
6.2.5-6 Voice annunciation of the fare charged and remaining account balance will be separately configurable as follows:
  • Annunciation through the validator speaker
  • Annunciation through the validator headphone jack
CDRL6-11 CDRL6-12
6.2.5-7 All validator visual and audio output will be fully configurable and subject to agency review and approval during design review CDRL6-11 CDRL6-12

6.2.6 Electronic Storage

Req# Requirement Assigned CDRL(s)
6.2.6-1 Validators will include sufficient embedded storage to hold thirty (30) days of fare payment transactions, and a hotlist or whitelist equivalent to 75% of total media issuance, at the anticipated maximum usage of the system. CDRL6-11 CDRL6-12
6.2.6-2 Validators will support expandable storage in a common, commercially available format (e.g., compact flash, secure digital, etc.) that can be easily swapped or expanded without modification to the rest of the device components. CDRL6-11 CDRL6-12
6.2.6-3 Validators will generate an alarm through the system monitoring and management application (see Section 6.1.3) and provide a visual indication if a failure of either the primary or backup data storage occurs. CDRL6-12
6.2.6-4 An alternate means of removing data from the validator device will provided for instances where the there is a failure of the wired or wireless communication or power supply. CDRL6-11 CDRL6-12
6.2.6-5 Where it is necessary to store sensitive data, including all transaction data, white lists and hotlists, validators will do so in a PCI-compliant manner. CDRL6-11 CDRL6-12

6.2.7 Finish/Mounting

Req# Requirement Assigned CDRL(s)
6.2.7-1 Validators will be rugged and function under environmental conditions including: direct sunlight, dust/grit/sand, humidity, electrical storms, exposure to urban environment, and the range of elevations and altitudes in the operation region (see Section 3.3). CDRL6-11
6.2.7-2 Validator housing will be resistant to corrosion, abrasion, scratching, impacts, and vandalism. CDRL6-11
6.2.7-3 Validator housing color and finish will be such that it minimizes reflection and is highly resistant to fading, cracking, and peeling. CDRL6-11
6.2.7-4 All validator corners will be rounded, and there will be no exposed bolt heads, nuts, sharp edges, or cracks on outside surfaces. CDRL6-11
6.2.7-5 Validator displays will be flush mounted in the housing. CDRL6-11
6.2.7-6 Covers on the validator housing for accessing modules and subassemblies will be secured with mechanical locks and keys that are not readily duplicated, nor readily available to the public, and uniquely serialized and stamped "Do Not Duplicate." CDRL6-11

Appendix A/eFare Sys IntTech Specs

86 Oct. 3, 2013

 


 

Figure 2-1 Conceptual System Diagram

Please see Extended Text Description below.

(Extended Text Description: The figure labeled Figure 2-1. Conceptual System Diagram has a flowchart describing TriMet's fare system.

There is a legend in the upper right-hand corner of the slide showing the following:

On the far left of the flowchart excerpt are four boxes. From top to bottom, the boxes are labeled "On-board Validators," "Off-board Validators," "Retail Device" and "Mobile Inspection Device." The On-board Validators box is connected via a lightning bolt to a cloud graphic with the words "Internet (VPN)/TriMet LAN" inside of it. The Off-board Validators and Retail Devices boxes are connected to this cloud via red dashed lines. The Mobile Inspection Device is connected via a lightning bolt to this cloud.

The Internet (VPN)/TriMet LAN cloud is connected via a yellow line to a computer labeled "Device Monitoring and Management System" located to the right of this cloud. This computer is connected via a yellow line to a computer labeled "Maintenance Management System" which is located to the right of the Device Monitoring and Management System. The Maintenance Management System is connected via a yellow line to a computer labeled "TriMet MMIS" and via a yellow line to a computer labeled "Data Warehouse."

Above and to the left of the Device Monitoring and Management System is a laptop graphic labeled "Device Monitoring Tool." Above and to the right of the Maintenance Management System is a laptop graphic labeled "Maintenance Management Tool."

The Internet (VPN)/TriMet LAN cloud is connected via a red line to a computer labeled "Account-based Processor." The Account-based Processor is connected via a green line to a computer labeled "Financial Clearing and Settlement System." The Financial Clearing and Settlement System is connected via a green line to a computer labeled "Data Warehouse."

The Data Warehouse is connected via all four colors to a computer labeled "Reporting." Located above and to the right of Reporting is a laptop labeled Reporting Tool.

The Account-based Processor is connected via a red line to a computer labeled "Web Server," which is located directly below the Account-based Processor. The Web Server is connected via a red and blue line to a cloud located to the left of the Web Server labeled "Internet." This cloud is connected via red and blue lines to two laptops labeled "Customer Website" and "Institutional Website" located to the left of this cloud. This cloud is also connected via a lightning bolt to a graphic representing Mobile Website and Applications, which is located directly below the Institutional Website laptop.

The Web Server is connected via a blue line to a computer labeled "Customer Relationship Management (CRM) System," which is located to the right of the Web Server. The CRM System is connected via a green line to a computer labeled "Payment Gateway," which is located directly above the Web Server. Above and to the right of the CRM System is a laptop labeled "CRM Tool." The Payment Gateway is connected via a green line to the computer labeled "Financial Clearing and Settlement System," which is located directly above the Payment Gateway. The Payment Gateway is also connected to the Account-based Processor via a green line. The Payment Gateway is connected via a green line to a graphic representing a Bank.

The CRM System is connected via a blue line to the Data Warehouse. The CRM System is connected via a blue line to the computer labeled "Transit Store POS System," which is located under Fareboxes (Not Integrated). The Account-based Processor is connected via a red line to the Transit Store POS System as well.

The Financial Clearing and Settlement System is connected via a green line to a computer labeled "TriMet General Ledger," which is located to the right of the Financial Clearing and Settlement System, and directly under the TriMet MMIS.

The Account-based Processor is connected via a red line to a computer labeled "Trapeze Scheduling (Paratransit)," which is located directly under the Ticket Vending Machines.

The Account-based Processor is connected via a red line to a computer labeled "TVM Back Office." The TVM Back Office is connected via a red line to a box labeled "Ticket Vending Machine."

The Account based Processor is connected via a red line to a cloud labeled "Retail Network." To the right of this cloud is a cash register graphic.

On-board Validators are connected via a black line to a graphic labeled "CAD/AVL," which is located directly above the cash register graphic. To the right of the CAD/AVL is a graphic labeled "Fareboxes (Not Integrated)," which is located directly above the Transit Store POS System.

A light blue box labeled "System / Device Development Outside of Contractor Scope" is overlaid over several flowchart elements on the right-hand side of the figure. These elements from top of the overlay to the bottom are: CAD/AVL and Fareboxes (Not Integrated); Retail Network cloud and cash register graphic; Transit Store POS System; TVM Back Office and Ticket Vending Machines; Trapeze Scheduling (Paratransit); TriMet MMIS; TriMet General Ledger; and the Bank.)

Appendix A/eFare Sys IntTech Specs 20 Oct. 3,2013

 

3. Reference to Other Standards

3.1. IEEE 802.11

802.11 [and 802.11x] refers to a family of specifications developed by the IEEE for wireless [local area network] LAN (WLAN) technology. 802.11 specifies an over-the-air interface between a wireless client and a base station or between two wireless clients.

There are several specifications in the 802.11 family:

 

3.2. Payment Card Industry Security Standards

Information regarding these standards are shown in the next two pages.

3 https://www.webopedia.com/TERM/8/802 11.html

4 http://www.iaeng.org/publication/WCECS2014/WCECS2014 pp691-698.pdf

 

Payment Card Industry Security Standards - Excerpts below:


 

Payment Card Industry Security Standards - header for excerpt. Contains the PCI logo on the left, and the following text: Security Standards Council - At A Glance - Standards Overview

Payment Card Industry Security Standards

PCI security standards are technical and operational requirements set by the Payment Card Industry Security Standards Council to protect cardholder data. The standards globally govern all merchants and organizations that store, process or transmit this data - with new requirements for software developers and manufacturers of applications and devices used in those transactions. Compliance with the PCI set of standards is mandatory for their respective stakeholders, and is enforced by the major payment card brands who established the Council: American Express, Discover Financial Services, JCB International, MasterCard Worldwide and Visa Inc.

Please see Extended Text Description below.

(Extended Text Description: There is a graphic at the top right of this page. At the top of the graphic are the words "Payment Card Industry Security Standards." Right below that are the words in smaller font "Protection of Cardholder Payment Data." Right below these words are three rectangles from left to right labeled as follows:

To the right of the last rectangle are the words "PCI Security Standards & Compliance. In a line under all three rectangles says "Ecosystem of payment devices, applications, infrastructure and users.")

PCI Standards Include:

PCI Data Security Standard: The PCI DSS applies to any entity that stores, processes, and/or transmits cardholder data. It covers technical and operational system components included in or connected to cardholder data. If your business accepts or processes payment cards, it must comply with the PCI DSS.

PIN Entry Device Security Requirements: PCI PED applies to manufacturers who specify and implement device characteristics and management for personal identification number (PIN) entry terminals used for payment card financial transactions.

Payment Application Data Security Standard: The PA-DSS is for software developers and integrators of applications that store, process or transmit cardholder data as part of authorization or settlement. It also governs these applications that are sold, distributed or licensed to third parties.

In the lower left-hand side of the page are several logos under the heading "PCI SSC Founders:" American Express logo, Discover Network logo (directly under the American Express logo), JCB logo (directly under the Discover Network logo), MasterCard Worldwide logo (directly below the JCB logo), and the VISA logo (directly below the MasterCard Worldwide logo).

Participating Organizations

Merchants, banks, processors, developers and point of sale vendors

PCI Data Security Standard for Merchants & Processors

The PCI DSS is the global data security standard that any business of any size must adhere to in order to accept payment cards. It presents common sense steps that mirror best security practices.

Goals PCI DSS Requirements
Build and Maintain a Secure Network
  1. Install and maintain a firewall configuration to protect cardholder data
  2. Do not use vendor-supplied defaults for system passwords and other security parameters
Protect Cardholder Data
  1. Protect stored data
  2. Encrypt transmission of cardholder data across open, public networks
Maintain a Vulnerability Management Program
  1. Use and regularly update anti-virus software
  2. Develop and maintain secure systems and applications
Implement Strong Access Control Measures
  1. Restrict access to cardholder data by business need-to-know
  2. Assign a unique ID to each person with computer access
  3. Restrict physical access to cardholder data
Regularly Monitor and Test Networks
  1. Track and monitor all access to network resources and cardholder data
  2. Regularly test security systems and processes
Maintain an Information Security Policy
  1. Maintain a policy that addresses information security

 

COMPLIANCE PROGRAM

Assessing

Secure collection and tamper-proof storage of cardholder data; it must be available for analysis

Reporting

Prove compliance if assessed and present evidence that data protection controls are in place

Monitoring & Alerting

Have systems for auto-alerting to constantly monitor access and usage of data

Systems should extend to log data with proof of being collected and stored

 

PCI AT-A-GLANCE

(visit www.pcisecuritystandards.org/ for more information)

Overview

Getting Started with PCI DSS

10 Common Myths of PCI DSS

Data Security Do's and Dont's

Getting Started with PA-DSS

Getting Started with PCI PED

 

How to Comply with PCI DSS

The PCI Security Standards Council sets the standards for PCI security but each payment card brand has its own program for compliance. Specific questions about compliance should be directed to your acquiring financial institution. Links to payment card brand compliance program include:

Qualified Assessors. The Council provides programs for two kinds of certifications: Qualified Security Assessor (QSA) and Approved Scanning Vendor (ASV). QSAs are companies that assist organizations in reviewing the security of its payments transaction systems and have trained personnel and processes to assess and validate compliance with PCI DSS and PA-DSS. ASVs provide commercial software tools to perform certified vulnerability scans for your systems. Additional details can be found on our Web site at: www.pcisecuritystandards.org/.

Self-Assessment Questionnaire. The "SAQ" is a validation tool for merchants and service providers who are not required to do on-site assessments for PCI DSS compliance. Different SAQs are specified for various business situations; more details can found on our Web site at: www.pcisecuritystandards.org or contact the acquiring financial institution to determine if you should complete an SAQ.

 

Payment Application Data Security Standard for Developers

The PA-DSS minimizes vulnerabilities in payment applications. The goal is to prevent the compromise of full magnetic stripe data located on the back of a payment card. PA-DSS covers commercial payment applications, integrators and service providers. Merchants and service providers should use certified payment applications and should check with their acquiring financial institution to understand requirements and associated timeframes for compliance.

Payment Application DSS Requirements - Validated by PA-QSA Assessment
1. Do not retain full magnetic stripe, card validation code or value (CAV2, CID, CIV2, CW2) or PIN block data
2. Provide secure password features
3. Protect stored cardholder data
4. Log application activity
5. Develop secure applications
6. Protect wireless transmissions
7. Test applications to address vulnerabilities
8. Facilitate secure network implementation
9. Do not store cardholder data on a server connected to the Internet
10. Facilitate secure remote software updates
11. Facilitate secure remote access to application
12. Encrypt sensitive traffic over public networks
13. Encrypt all non-console administrative access
14. Maintain instructional documentation and training programs for customers, resellers and integrators

PIN Entry Device (PED) Security Requirements for Manufacturers

This standard, referred to as PED, applies to companies which make devices that accept personal identification number (PIN) entry for all PIN-based transactions. Merchants and service providers should use certified PED devices and should check with their acquiring financial institution to understand requirements and associated timeframes for compliance.

PIN Entry Device Security Requirements - Validated by PED Laboratory
Device Characteristics
Physical Security Characteristics (to prevent the device from being stolen from its location)
Logical Security Characteristics (to provide functional capabilities that ensure the device is working appropriately)
Device Management
Device Management during manufacturing
Device Management between manufacturer and initial cryptographic key loading
Considers how the PED is produced, controlled, transported, stored and used throughout its lifecycle (to prevent unauthorized modifications to its physical or logical security characteristics)

© 2008 PCI Security Standards Council LLC. The intent of this document is to provide supplemental information, which does not replace or supersede PCI SSC Security Standards or their supporting documents.

 


 

4. Case Studies

There are no new case studies in this module in addition to the following three presented in the module:

 

5. Glossary

Term Definition
Automatic vehicle location (AVL) The central software used by dispatchers for operations management that periodically receives real-time updates on fleet vehicle locations. In most modern AVL systems this involves an onboard computer with an integrated Global Positioning System receiver and mobile data communications capability.
Computer-aided Dispatch (CAD) CAD software integrates transit operations by giving transit dispatchers and supervisors' decision support tools to manage the operating environment.
Global System for Mobile communication (GSM) GSM is a digital mobile network that is widely used by mobile phone users in Europe and other parts of the world. GSM digitizes and compresses data, then sends it down a channel with two other streams of user data, each in its own time slot.
Infrastructure as a Service (IaaS) Cloud layer offering that enables a self-service model for managing virtualized data center infrastructure. Customers pay for on-demand access to pre-configured computing resources, such as network, storage, and operating systems.
Internet of Things (IoT) The interconnection via the Internet of computing devices embedded in everyday objects, enabling them to send and receive data.
Internet Protocol (IP) A set of rules governing the format of data sent over the Internet or other network.
Long Term Evolution (LTE) LTE is a standard for 4G wireless broadband technology that offers increased network capacity and speed to mobile device users. It also provides reduced latency, scalable bandwidth capacity and backward-compatibility with existing GSM and UMTS technology.
Mobile Gateway Router (MGR) [also known as On-board MGR and mobile access router] Wireless gateways work in the cellular radio space and add intelligence to the activity of connecting a device to the internet. They will translate a private local IP to a public network IP assigned by the cellular service carrier. The gateway connects a local private device or local private network to the carrier's public network and the internet. Mobile gateway routers perform all the functions of a wireless gateway, and add sophisticated routing capabilities as well as multiple Ethernet and/or WLAN connections. These capabilities involve port forwarding or mapping and port routing. The single public IP assigned from the carrier may be mapped in the router so that one port of the single public IP is mapped to a camera, another to a sensor, and another to manage the router, and another to a locally connected network for web access. Often these two devices can be combined into one and referred to as an on-board mobile gateway router (OMGR).
Open Systems Interconnection (OSI) The OSI model is a conceptual framework that describes the functions of a networking or telecommunication system.
Platform as a Service (PaaS) Cloud layer offering that provides tools and other computing infrastructure, enabling organizations to focus on building and running web applications and services. PaaS environments primarily support developers, operations, and hybrid teams.
Quality of service (QoS) QoS is a family of evolving Internet standards that provides ways to give preferential treatment to certain types of Internet Protocol (IP) traffic.
Software as a Service (SaaS) Applications hosted by a third party and usually delivered as software services over a web browser that is accessed on the client's side.
Transit signal priority (TSP) TSP is a general term for a set of operational improvements that use technology to reduce dwell time at traffic signals for transit vehicles by holding green lights longer or shortening red lights.
Universal Mobile Telecommunications Service (UMTS) UMTS is a third-generation (3G) broadband, packet-based transmission of text, digitized voice, video, and multimedia at data rates up to 2 megabits per second (Mbps).
Vehicle logic unit (VLU) Typically, the VLU within the mobile data terminal (MDT) provides the processing power needed to support automation, single point log-on, and other onboard transit ITS applications.
Wide area network (WAN) A computer network in which the computers connected may be far apart, generally having a radius of half a mile or more.

 

6. References

 

7. Study Questions

Which one of these differences between SAE J1939 and J1708 is NOT true?

Answer Choices:

  1. J1939 is much faster than J1708
  2. J1939 permits a connection of more devices than J1708
  3. J1939 is based on the Controller Area Network (CAN)
  4. J1939 covers the same number of OSI layers as J1708

What is the difference between Generation 1.5 and 2.0 of on-board architectures?

Answer Choices:

  1. The mobile gateway router (MGR) was introduced in Generation 2
  2. Not all on-board devices are IP-ready in Generation 1.5
  3. On-board analytics & "smarts" stay on-board in Generation 2
  4. Ethernet is no longer used in Generation 2

CDTA's selection of an On-board Mobile Router/Wireless Gateway included which considerations?

Answer Choices:

  1. Need to operate both private and public networks for internal data transfer and public Wi-Fi
  2. Flexibility to handle multiple inputs, antennae and multiple SIM cards for redundancy
  3. Hardware needed to be already deployed and proven to be reliable
  4. All of the above

Which one of these benefits has been experienced by AC Transit due to their implementation of multiple technology communications?

Answer Choices:

  1. Limit service area coverage
  2. Provide a path for technology evolution
  3. Eliminate LMR assets
  4. Reduce the number of FCC licenses

 

Icons to be used in ITS PCB Standards Training PowerPoints

A key of these icons that may be found in the PowerPoint presentations.

1) Background information: General knowledge that is available elsewhere and is outside the module being presented. This will be used primarily in the beginning of slide set when reviewing information readers are expected to already know. Example: Information on the standard.

Background information icon indicates general knowledge that is available elsewhere and is outside the module being presented.

2) Tools/Applications: An industry-specific item a person would use to accomplish a specific task, and applying that tool to fit your need.

Example: Systems engineering, specifications, test documentation, etc. A systems engineering approach to developing an ATC procurement specification.

Tools/Applications icon. An industry-specific item a person would use to accomplish a specific task, and applying that tool to fit your need.

3) Remember: Used when referencing something already discussed in the module that is necessary to recount.

Example: "Recall our discussion on [insert topic] back in Learning Objective 1…"

Remember icon. Used when referencing something already discussed in the module that is necessary to recount.

4) Refer to Student Supplement: Items or information that are further explained/detailed in the Student Supplement.

Example: Additional information on a standard, additional case studies or examples that don't fit into the PowerPoint itself, external resources, etc.

Supplement icon indicating items or information that are further explained/detailed in the Student Supplement.

5) Example: Can be real-world (case study), hypothetical, a sample of a table, etc.

Example icon. Can be real-world (case study), hypothetical, a sample of a table, etc.

6) Checklist: Use to indicate a process that is being laid out sequentially. Example: Process to write test plans to verify standard requirements.

Checklist icon used to indicate a process that is being laid out sequentially.

↑ Return to top