Module 19: On-Board Transit Management Systems

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 19: On-Board Transit Management Systems

Table of Contents

Module Description - 2

Introduction/Purpose - 2

Samples/Examples - 2

Reference to Other Standards - 17

Glossary - 23

References - 25

Study Questions - 27

Icon Guide - 28

1. Module Description

On-board Transit Management for buses covers technologies and systems that are located within transit vehicles that facilitate and automate operations, management, maintenance, safety and security functions of public transit systems. While there are currently few standards that govern receiving and transmitting the data and information generated by these systems, the use of the existing relevant Society of Automotive Engineers (SAE) standards facilitate the systems' operations and maintenance. An on-board system can include a vehicle area network (VAN), mobile data terminal (MDT), vehicle logic unit (VLU) (sometimes combined with an MDT), equipment for supervisor/support vehicles (e.g., ruggedized laptop), an Automated Vehicle Announcement (AVA) System (covered in Modules 6 and 7), an 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 On-board Video Surveillance System (covered in Modules 2 and 5).

Module 2 - Transit Management Standards, Part 1 of 2 and Module 5 - Transit Management Standards, Part 2 of 2 can be found respectively at

StandardsTraining/Modules.aspx?Year1Transit=1&ModuleID=57#mod57 and

StandardsTraining/Modules.aspx?Year1Transit=1&ModuleID=60#mod60.

2. Introduction/Purpose

The purpose of Module 19 is to provide details of on-board hardware and software standards (in addition to Transit Communications Interface Profiles (TCIP) covered in Module 3 and Module 4). Examples will demonstrate how to procure systems that use these standards.

The information provided in this module will help participants further understand those standards that support On-board Transit Management functions for buses, specifically SAE J1587, J1708 and J1939 profiles, and how to procure systems using these standards. Topics covered in this module includes single point logon/logoff, data upload/download from an on-board device, and the use of an interface control document (ICD) (An ICD is the formal means of establishing, defining, and controlling interfaces and for documenting detailed interface design definitions. See Section 6 for the full definition of an ICD).

3. Samples/Examples

3.1. C2V Flows: Chattanooga Area Regional Transportation Authority (CARTA)

Beginning in 2006, CARTA required the inclusion of a multiplex system on all buses purchased. This system connected to the SAE J1939 data bus; monitored common engine, transmission, and braking faults transmitted on the data bus (e.g., high engine oil temperature, low oil pressure, high transmission oil temperature); and logged the data for later retrieval. The main purpose of this system was for integration with other planned in-vehicle equipment to eventually provide CARTA with a full remote diagnostics maintenance system. The system is now operational. In 2009, CARTA implemented the daily upload via wireless local area networks (WLAN) of bus diagnostic information collected on-board to the Automatic Vehicle Monitoring (AVM) server, making these data available to maintenance staff. Prior to this, CARTA deployed on-board components for an AVM system on fixed route vehicles, including WLAN communications at both vehicle storage facilities to enable bulk data transfer with vehicles.

The 2009 rollout of the AVM system provided another example of CARTA's commitment to testing. The core infrastructure needed to support AVM - the on-board equipment, the WLAN for daily data uploads, and the AVM software - was in place early in 2008. However, it had been decided to focus 2008 ITS resources on implementing systems that would deliver the most direct and visible benefits most directly and visibly to riders, such as the next-stop announcements and the next-arrival-time predictions. After these systems came online in December 2008, CARTA shifted focus to rolling out AVM. By January 2009, the AVM system elements were integrated and the AVM system was receiving daily uploads of data from the buses. CARTA then conducted internal testing of the AVM system to confirm it was operating correctly before releasing it for use by the mechanics in March 2009.

CARTA included the requirements for the AVM system in the request for proposals (RFP) for their CAD/AVL system. In developing these specifications, they reviewed and selected the most appropriate standards that could facilitate the implementation of AVM. In their review, they assessed standards availability, applicability to their needs, maturity of the standards, and the vendors' use, experience, and acceptance of the standards. This led them to specify the use of either SAE J1708 or J1939 to facilitate the implementation of the AVM system.

After making this selection, they incorporated the requirement of SAE J1708 or J1939 into the specification in several places, as follows:

Forming a vehicle area network (VAN) connecting the on-board mobile data terminal (MDT) with several other on-board devices (e.g., headsign):

The on-board Vehicle Area Network (VAN) shall support the functional capabilities of the interconnected equipment, as identified in the specifications, and conform to one of the following standards: (1) SAE J-1708/1587; (2) SAE J-1939; (3) IEEE 802.3 (i.e., Ethernet); or (4) IEEE 802.11g (i.e., Wi-Fi).

The supported Message IDs (MID) and Parameter IDs (PID), available for communications with future on-board devices using the J-1708/1587 interface, shall be fully documented (or equivalent information for a J-1939 interface).

The MDTs shall allow a single logon for all onboard equipment integrated over the VAN, including exterior variable signs, APCs, AAS and fare box.

The MDTs shall provide a single logon, as well as automatic updates for changes in route, run, block, trip, destination, and schedule direction, to all components integrated through the MDT via the VAN.

Each MDT shall be integrated with the mobile data communications equipment, including the maintenance of a Virtual Local Area Network (VLAN) over the mobile data communications system with the central systems.

The MDTs shall use the VAN to provide information to, and receive information from, other on-board equipment, including the automated annunciation/signage system, APC system, external variable signs, fare box and the vehicle maintenance controller.

The MDTs shall be integrated with the fixed voice radios, handset and speakers on fixed route and flexible route vehicles so as to allow the MDT to control when the operator can use the radio to send and receive.

All new vehicles currently being ordered by CARTA, including the last 10 fixed route vehicles ordered, have I/0 Controls multiplex systems. The remaining fleet vehicles have standard OEM wiring harnesses, and onboard device monitoring shall support the communications protocols of the installed equipment. The devices to be monitored on a given vehicle could involve a mix of monitoring J1708/1587 or J1939 communications and monitoring discrete interfaces. Any additional details will be discussed during the design review process.

Integrating the automatic passenger counting (APC) controller with the on-board MDT

The APC controller shall be integrated with the on-board MDT, using the VAN.

The APC sensors may alternatively be each connected directly to the VAN, to enable communications with the MDT without any intermediate APC controller.

Integrating the on-board MDT with interior DMS

The AAS controller shall be integrated with the on-board MDT, using the VAN.

Integrating the on-board MDT with the VAN to provide Vehicle Component Monitoring (VCM) (collecting codes from Engine Control Module, Transmission Control Module, and Automatic Braking System)

The MDT shall provide the on-vehicle features of Automatic Vehicle Monitoring.

The system shall collect transmitted fault and operational performance data from subsystems on-board the vehicle via the J1708, J1939 and multiplex networks, simultaneously.

The MDT shall send and receive messages from all sub-systems actively communicating and connected to the J1708/CAN networks that conform to the SAE J1587/J1939 data definitions.

Multiplex systems shall be monitored via J1708/J1939 and/or RS232/485. It is the responsibility of CARTA to ensure that the vehicles are equipped with all necessary gateways configured to externalize data in a manner compatible with the MDT.

3.2. Capital District Transportation Authority (CDTA) Single-point Logon- Albany, NY

The Capital District Transportation Authority (CDTA) is New York State's Capital Region mobility company with an annual ridership of 17.2 million. CDTA provides express, park & ride, local, and paratransit services. CDTA operates 280 buses from three facilities and owns and operates rail stations in Saratoga Springs and Rensselaer. CDTA serves 55,000 customers on a typical weekday. Buses travel 25,000 miles each day along 50 individual routes.

CDTA is conducting a solicitation (beginning in April 2016) that is part of a larger initiative to upgrade CDTA's Computer Aided Dispatch/Automatic Vehicle Location (CAD/AVL) and radio communication system, and related Advanced Public Transportation Systems (APTS). These dated technologies will be replaced with current, state of the art Intelligent Transportation Systems (ITS) that more closely align themselves with the goals of CDTA. The objective of this project is to use a new and functional system to improve transit customer service, safety, reliability, and efficiency.

CDTA, like NTD, began their procurement by, in part, identifying system integration needs. Out of their 20 base system (high-level) requirements, they identified the following:

Provide a fully integrated vehicle area network infrastructure to support integrated subsystems including passenger Wi-Fi, ITMS mobile equipment diagnostics, single sign on, monitoring, and diagnostic reporting.
Integrate mobile data terminals with existing ITS systems including: SPX-Genfare FastFare™ Fareboxes, Twin Vision head signs, March Networks mobile digital video recorders, odometers, and GTT Opticom™ traffic signal priority emitters, among others.
Provide an integrated automatic passenger counting (APC) system to count boarding and alighting events.
Provide automated vehicle announcement audio/video displays on-board each revenue service vehicle to inform passengers about upcoming stops, major intersections, and landmarks.
Implement Traffic Signal Priority (TSP) to be used in coordination with passenger load, schedule adherence, and route specific eligibility requirement information along premium service lines.
Provide on-board passenger Wi-Fi functionality.
Provide automated vehicle component monitoring of critical system components.

Out of 3 future system capabilities, one deals with on-board integration. The successful vendor/systems integrator shall partner with SPXGenfare to integrate open payments through CDTA's new FastFare® ® electronic Fareboxes via the Contractor's ITMS on-board mobile gateway router. The purpose of this interface is to provide customers with on-board payment card transactions in real time.

A slide in this module shows the systems to be integrated with the vehicle logic unit (VLU) using J1708/J1587. Also, this integration shall result in single-point logon, as mentioned in this module.

In April 2016, CDTA issued a Request for Proposals (RFP) for an Intelligent Transportation Management System (ITMS). In the specifications for the ITMS, there is a requirement to integrate the vehicle logic unit (VLU) through a bidirectional interface with CDTA's new FastFare™ electronic Fareboxes provided by SPX-Genfare (and Twin Vision head signs) to eliminate the need for multiple driver log-on processes. The language in the specification addressing this requirement is as follows:

"4.2.11.2.1 Farebox Integration

The ITSM shall support a bidirectional interface between the SPX-Genfare FastFare™ Farebox and the Contractor's MDT/VLU with a single point logon on all revenue service vehicles. The SPX-Genfare Farebox shall interface with the MDT and/or the VLU over J1708/1587 network to enable single point logon for the vehicle operator. The single point logon shall negate the need for operators to logon on to the MDT.

The existing SPX-Genfare Farebox login is automated through the use of the smart card reader on the SPX-Genfare FastFare® ® Farebox. At minimum, this login includes the time, date, driver identification number, route, run, trip and/or pattern, real-time vehicle location, and vehicle number, which shall be interface transferred to the MDT/VLU through a bidirectional interface. If a change to the driver identification number, route, run, trip, and/or pattern is made either by the driver or remotely by dispatch through the MDT, this same information will update the SPXGenfare Farebox logon. Conversely, the Farebox shall update the MDT data when the operator makes a change.

The operator shall continue to be able to use all Farebox operator control unit (OCU) features, regardless of whether or not the operator has logged into a run using the MDT or whether the MDT is operational.

Upon request from the Farebox, the MDT shall send the current location. The MDT shall automatically provide to the Farebox the segmentation data for the beginning of each trip. The Farebox shall request at least once each day from the MDT the current date/time, and reset its internal clock when needed to synchronize with the MDT.

The MDT shall be able to send Farebox alarms data through to the central system. The Contractor shall provide the design specifications and demonstrate the Farebox integration for CDTA review at the Preliminary Design Review and approval at the Final Design Review.

4.2.11.2.2 Head Sign Integration

Through a bidirectional interface, the MDT software shall provide the time, date, driver identification number, route, run, trip and/or pattern, and vehicle number, along with the ability to control the destination text to be displayed on CDTA's existing head signs on all revenue Capital District Transportation Authority Intelligent Transportation Management System service vehicles. The VLU/MDT shall also automatically adjust the electronic destination (head) signs based on GPS location. At a CDTA configurable distance before the start of each trip, the MDT shall change the head sign message to display a message that can be configured by CDTA. The head signs shall send to the MDT any hardware or software alarm codes for the head signs. These alarms will be sent to the ITMS CDS via the MDT.

The VLU shall interface with the electronic destination (head) signs provided by Twin Vision signs provided by Luminator Technology Group. Programming must include any route interlining that may accompany a vehicle route or block number with no additional driver or operator involvement. Additional electronic destination (head) sign programming shall be available to accommodate the display of the route name, route number, end terminal or end destination, and other messages, which may rotate through the head sign display based on programmable measures configurable by CDTA authorized staff. At minimum, the integration will allow for the head sign display, to show (left-justified) the route number followed by route name.

When the vehicle is logged into a run using the MDT but operating on a deadhead run from the garage to the first trip of the run, the MDT shall automatically command the head sign to display a message that can be configured by CDTA. This message could be "OUTBOUND", "INBOUND", "OUT OF SERVICE", "FROM GARAGE" or the message that will be displayed during the first trip.

When the vehicle is logged into a run using the MDT, but operating on deadhead to the garage from the final trip of the run, the MDT shall automatically command the head sign to display a message that can be configured by CDTA. This message could be "OUT OF SERVICE", "TO GARAGE" or the message that will be displayed during the final trip.

When the vehicle is logged into a run using the MDT, but operating on deadhead for interlining between trips in the course of a run, the MDT shall automatically command the head sign to display a message that can be configured by CDTA. This message could be "OUT OF SERVICE" or the message displayed during either the previous or upcoming trip.

When the vehicle is logged into a "special" run using the MDT, the MDT shall automatically command the head sign to display a message that can be configured by CDTA for that run (e.g., "OUT OF SERVICE", "IN TRAINING").

When the vehicle is logged into any run using the MDT, the vehicle operator shall be able to manually command the head sign to display one of a set of preconfigured messages that can be configured by CDTA (e.g., "OUT OF SERVICE", "IN TRAINING").

When the vehicle is in covert alarm mode, the MDT shall automatically command the head sign to display one of a set of preconfigured messages that can be configured by CDTA (e.g., "CALL POLICE" or "CALL 911-EMERGENCY").

All messages shall be adjustable manually by the operator without shutting down the vehicle to reset or refresh the system.

The head sign shall request at least once each day from the MDT the current date/time, and reset its internal clock when needed to synchronize with the MDT.

The Contractor shall confirm if any upgrades to the head sign or head sign controller firmware are needed to implement this interface.

The vehicle operator shall continue to be able to use all features of the existing head sign controller, regardless of whether or not the vehicle operator has logged into a run using the MDT or whether the MDT is operational.

The Contractor shall provide the design specifications and demonstrate the head sign integration for CDTA review at the Preliminary Design Review and approval at the Final Design Review."¹

¹ Capital District Transportation Authority (CDTA), Request for Proposals (RFP), Proposal Title: Intelligent Transportation Management System (ITMS), Proposal Number: CDTA IT-57-1000, https://www.cdta.org, pages 4-107 through 4-109.

3.3. King County Single-point Logon

Information regarding King County Metro's single-point logon is as follows.

This slide is the title slide of the presentation, Seattle Metro and Mobile Routers. Please see the Extended Text Description below.

(Extended Text Description: This slide is the title slide of the presentation, Seattle Metro and Mobile Routers. There is a photo of a King County Metro bus in the center, then the text, "APTA Fare Collection Workshop March 2011." At the bottom is the King County Metro logo with the text "We'll Get You There.")

This slide, entitled Presentation Overview, has a rendering of a King County Metro bus station to the left of the bullets. Please see the Extended Text Description below.

(Extended Text Description: This slide, entitled Presentation Overview, has a rendering of a King County Metro bus station to the left of the bullets. The full bulleted text of the slide includes:

Presentation Overview

ORCA fare collection system
On-board systems project
On-board integration
Role of the mobile router

This slide, entitled ORCA Fare Collection System, has the ORCA logo to the left of the bullets. Please see the Extended Text Description below.

(Extended Text Description: This slide, entitled ORCA Fare Collection System, has the ORCA logo to the left of the bullets. The full bulleted text of the slide includes:

ORCA Fare Collection System

7 Agencies
Regional fare products
Ferry, bus, light rail, commuter rail
255,000 Average weekday ORCA boardings

This slide, entitled Status, has a photo of an ORCA farecard reader on a King County Metro bus to the left of the bullets. Please see the Extended Text Description below.

(Extended Text Description: This slide, entitled Status, has a photo of an ORCA farecard reader on a King County Metro bus to the left of the bullets. The full bulleted text of the slide includes:

Status

Contract with ERG signed April 2003
Public launch April 2009
Full system acceptance April 2011
10-year Operating contract

This slide, entitled On-Board Systems (OBS) Project, has a photo of a King County Metro RapidRide bus. Please see the Extended Text Description below.

(Extended Text Description: This slide, entitled On-Board Systems (OBS) Project, has a photo of a King County Metro RapidRide bus. The full bulleted text of the slide includes:

On-Board Systems (OBS) Project

INIT
Smart bus concept
GPS/odometer/gyroscope solution
Stop announcements
Next stop electronic displays
Destination sign integration
Automatic passenger counting
Vehicle monitoring
Installs in progress

This slide, entitled Business Need for Integration, has a photo of a King County Metro bus driver. Please see the Extended Text Description below.

(Extended Text Description: This slide, entitled Business Need for Integration, has a photo of a King County Metro bus driver. The full bulleted text of the slide includes:

Business Need for Integration

Single logon for operators
Automatic fare zone changes
Space and power constraints
Maintenance requirements
Network infrastructure support
Multiple hardware and software vendors
Phased implementation

This slide, entitled Evolution, has a photo of a King County Metro bus yard. Please see the Extended Text Description below.

(Extended Text Description: This slide, entitled Evolution, has a photo of a King County Metro bus yard. The full bulleted text of the slide includes:

Evolution

OBS should have come first but...
ORCA became the integration platform
Driver Display Unit (DDU)
Wireless bridge (Cisco 1310)
Regional requirements and agency-specific requirements
Migrating to mobile router (MAR)

This slide, entitled Driver Display Unit (DDU), has a photo of a King County Metro bus DDU at the bottom of the slide. Please see the Extended Text Description below.

(Extended Text Description: This slide, entitled Driver Display Unit (DDU), has a photo of a King County Metro bus DDU at the bottom of the slide. The DDU screen has three primary sections: (1) The radio window, which is at the top of the screen, (2) the Fares window, which is at the center of the screen, and (3) the OBS window, which is toward the bottom of the screen. The full bulleted text of the slide includes:

Driver Display Unit (DDU)

Window CE operating system
Software development kit and certification process part of contract

King County ITS Architecture. Please see the Extended Text Description below.

(Extended Text Description: This slide, entitled King County ITS Architecture, has an architecture diagram which is separated into Coordinator Consoles (in the upper-right of the slide), Control Center (which encompasses the Coordinator Consoles section), Microwave (in the center right side of the slide), On-Board (in the lower right of the slide), Roadside (in the lower left of the slide), .KCM Bus Bases (in the center left of the slide), and Sabey and KSC (in the upper left of the slide). The legend for the letters that are shown after the box labels is as follows: (A) is Apollo, (E) is ERG, (ET) is Eurotech, (I) is INIT, (K) is King County, (M) is Motorola and (Mc) is McCain. Above the Sabey and KSC section of the chart are two boxes that are connected via a line labeled "Clearinghouse (E)" and "Websites, Other Agencies & Other Services." To the right of the Websites, Other Agencies & Other Services box is a box labeled "Metro Online." In the Coordinator Consoles section, there are two boxes labeled "CAD/AVL Console (I)" and "Radio System Console (M)." In the rest of the Control Center section, there are three boxes: one that is small and not labeled, one that is labeled "Comm Center System (I)" and "Radio System Master Site (M)." In the Sabey and KSC section, there are four boxes labeled "Back Office (E)," "Base Server (I), (K)," "KCM Data Sources (K)," and "Signal Priority Server." In the KCM Bus Bases, there are three boxes labeled "Data Acquisition Computer (E)," "Landing Pad (I), (K)," and "DVR Server (K)." In the middle of the slide, there are six boxes labeled "KC Traffic Control Center (K)," "King County WAN (K)," "Metro Police Cars (K)," "Transit Radio Sites (M), (K)," "Traffic Buster Network (K)," and "SDOT and WashDOT Networks." In the Roadside section of the chart, there are five boxes: "RapidRide Real Time Information Signs (I)," "Stand-Alone Fare Processor (E)," "Transit Signal Priority System (Mc)," "Mobile Access Router (ET)" and "Metro ITS Network (K)." The bottom right-hand corner of the diagram, the On-Board section, contains the boxes and elements as described above for Page 13 below in the following row of this table. The following describes the connections between the boxes described above. There is a line between the Clearinghouse and Websites, Other Agencies & Other Services boxes. There is a line between the Clearinghouse, and Back Office, Base Server and KCM Data Sources boxes. There is a line with arrows at both ends between the Back Office and Data Acquisition Computer boxes. There is a line between Base Server and Landing Pad boxes. There is a line between the Signal Priority Server and King County WAN boxes. This line has an arrow at the end of the line pointing at the King County WAN box. There is a line from Data Acquisition Computer, Landing Pad and DVR Server boxes to the King County WAN box. This line has an arrow at the end of the line pointing at the King County WAN box. There is a line between the KC Traffic Control Center and King County WAN boxes. There is a line between the Traffic Buster Network and SDOT & WashDOT Networks boxes. There is a line with arrows at both ends between the CAD/AVL Console and Comm Center System boxes. There is a line between the Radio System Console and Radio System Master Site boxes. There is an arrow on this line pointed toward the Radio System Master Site box. There is a line between the small unlabeled box in the center of the Control Center section, and CAD/AVL Console, Radio System Console, Radio System Master Site and Comm Center System boxes. This line has arrows pointing toward the small box. There is a line with arrows at both ends between the small unlabeled box and King County WAN box. There is a line with arrows at both ends between King County WAN and SDOT & WashDOT Networks boxes. There is a line between the Mobile Access Router box and the RapidRide Real Time Information Signs and Stand-Alone Fare Processor boxes. There is a line between the Transit Signal Priority System and Metro ITS Network boxes. There is a lightning bolt labeled "4.9 GHz" between the Mobile Access Router and Metro ITS Network boxes. There is a lightning bolt between the On-Board section and the Metro ITS Network box. There is a lightning bolt labeled "4.9 GHz" between the On-Board section and the King County WAN box. There is a lightning bolt between the On-Board section and the Metro Police Cars box. There is a lightning bolt labeled "700 MHz" between the On-Board section and Transit Radio Sites box. There is a lightning bolt labeled "Microwave" between the On-Board and Control Center sections.)

On-Board Architecture. Please see the Extended Text Description below.

(Extended Text Description: This slide, entitled On-Board Architecture, has a graphic showing boxes, each containing an on-board component, that are connected via either lines or lightning bolts. In the upper-left hand part of the graphic is a box labeled "Base" connected via a lightning bolt to a box labeled "Mobile Access Router" which is located in the upper-left hand part of the center of the graphic. In the center-left hand part of the graphic is a box labeled "Roadside" connected via a lightning bolt to the "Mobile Access Router" box. In the upper-right hand part of the graphic is a box labeled "Control Center" which is connected via a lightning bolt that is labeled "700 MHz" to a box labeled "Mobile Radio." The Mobile Radio box is located in the upper-right hand part of the center of the graphic, and is connected via a line to a box labeled "Vehicle Logic Unit" that is below the Mobile Radio box. The Vehicle Logic Unit is connected via a line to a box labeled "Other On-Board Devices." The Other On-Board Devices box is located below the Vehicle Logic Unit box. To the left of the Other On-Board Devices box is a box labeled "Fare Transaction Processor." These two boxes are not connected. To the left of the Fare Transaction Processor box is a box labeled "Driver Display Unit." There is a small box located above the Driver Display Unit and Fare Transaction Processor boxes. The Driver Display Unit is connected to the small box with a line, as is the Fare Transaction Processor box. This small box is connected to the Mobile Access Router box with a line. There is a small dashed box located above the Vehicle Logic Unit box, and it is connected to the Vehicle Logic Unity box via a line that has arrows at both ends. This small box is connected to the Mobile Access Router box via a line that has arrows at both ends. Finally this small box is connected to a box labeled "Digital Video Recorder" via a dashed line that has arrows at both ends.)

This slide, entitled Mobile Access Router (MAR), has a photo of the router to the left of the bullets on the slide. Please see the Extended Text Description below.

(Extended Text Description: This slide, entitled Mobile Access Router (MAR), has a photo of the router to the left of the bullets on the slide. The full bulleted text of the slide includes:

Mobile Access Router (MAR)

DuraMAR 2150 from Eurotech
Configuration data
Schedule and trip details - OBS and ORCA need to match
Trigger points
Announcement text
Audio files
Usage data
Fare transactions
Vehicle history
Schedule adherence
Passenger counts

This slide, entitled Why a Mobile Router, has a photo of a King County Metro bus moving from left to right to the left of the bullets on the slide. Please see the Extended Text Description below.

(Extended Text Description: This slide, entitled Why a Mobile Router, has a photo of a King County Metro bus moving from left to right to the left of the bullets on the slide. The full bulleted text of the slide includes:

Why a Mobile Router?

Roaming and reduced authentication time supports TSP
Licensed 4.9GHz spectrum
Reduced interference
Better yard coverage
Simplified IP addressing
Migration from in progress

3.4. Norwalk Transit District (NTD) Computer-aided Dispatch (CAD)/ Automatic Vehicle Location (AVL)

Figures 1 and 2 present the System and On-Board System Overviews. Figure 1 is the system overview including on-board and real time information systems. Figure 2 shows the on-board system overview for fixed-route and dual-use vehicles.

Once NTD documented the system integration requirements, the procurement process continued with proposers stating if they are in compliance, not in compliance or in compliance with modification with the specifications in their proposals. Sections of the specifications that addressed SAE J1708/J1587 were (1) Vehicle Area Network (VAN), (2) Farebox Integration, (3) Headsign Integration, (4) APC Installation/Integration, (5) Optional Vehicle Component Monitoring, (6) Integration with Interior DMS and (7) Optional Interface with Transit Signal Priority (TSP) Emitter (fixed-route only). The following language is directly from the specifications.

Vehicle Area Network (VAN). "The Contractor shall install communications cabling and connections compliant with the Society of Automobile Engineers (SAE) J-1708/1587 or J-1939 network standard, to form a VAN connecting the MDT with fare box (when available), headsign, APC controller, DVR, AVA controller and interior DMS for AVA, for common login, operating control and other integrated functionalities. Further, MDTs shall be able to be integrated with optional on-board equipment (when purchased) that includes TSP emitters, on-board surveillance systems and maintenance network gateways for vehicle component monitoring.

"All supported Message IDs (MID) and Parameter IDs (PID), available for communications with on-board devices using the J-1708/1587 or J-1939 interface, shall be fully documented."

System Overview of the NTD CAD/AVL System. Please see the Extended Text Description below.

(Extended Text Description: System Overview of the NTD CAD/AVL System. This graphic shows the relationships among various NTD Central System Technologies. The orange boxes indicate existing systems, purple boxes indicate core systems that are required in the procurement and the red boxes indicate desired systems that may be added in the future. Beginning in the center of the graphic, there is a rectangular column representing the Central Server Configuration. In this column the following servers are represented in individual blocks from top to bottom: Database Server (purple), CAD/AVL (Computer Aided Dispatch and Automatic Vehicle Location) Server (purple), APC/AVA Mgmt. Server (purple), Fixed Route Scheduling Server (purple), IVR Server (red), Communications Server (purple), Routematch TS Server (orange), and RTCIS/Web Server (purple). From the IVR Server, there is a gray line representing a wired connection that leads to a black box labeled "Central Phone System" with a smart phone icon above it. From the RTCIS/Web Server, a red line representing data feed points connects to a purple box labeled "NTD Website." This red line has an arrow at the NTD Website box. Coming from the left side of the RTCIS/Web Server is another red line connecting to purple box labeled "Third Party Developers." This red line has arrows at both ends. To the right of the line going from the RTCIS/Web Server to the NTD Website is a red box labeled Regional Agencies connected to the line via a red line with an arrow at the Regional Agencies box. From the left side of the Communications Server, there is a dotted gray line that goes to a purple box labeled "Mobile Comm Gateway" and branches upwards through two cloud networks (bottom to top: the Cellular Data Network and Voice Radio Network systems), going on to two separate yellow boxes. These boxes are labeled "Revenue Fleet" and "Non-revenue Fleet." Also, there is a dotted gray line from the Mobile Comm Gateway box and a purple box labeled "TAG Dispatch." From the Cellular Data Network cloud, there is another dotted gray line going downwards representing the wireless connection to the DMS box (purple). From the Revenue Fleet box, is a dotted gray line going to a purple box labeled "Garage WLAN." This box is connected to the top of the entire Central Server Configuration. Coming from the entire Central Server Configuration, there is a solid green line representing the NTD LAN/WAN connection or VPN. This line goes through a light green box labeled "NTD WAN/LAN or VPN" and branches out to a light blue section identified as the "Workstation Configuration." Within the "Workstation Configuration," the following items are represented in individual boxes (top to bottom): Workstations to access control systems (purple), Maintenance and Fiel Management System (orange), Video Playback Software (red), WLAN Download Manager (purple), Fare payment system (orange), VCM Software (red), and Yard Management Software (red). Outside the "Workstation Configuration," the LAN/WAN connection also leads to a red box labeled as "Future Systems.")

Figure 1. System Overview

Farebox Integration. The MDT shall interface with the GFI fare box (for fare box equipped vehicles only) to enable single point logon for the vehicle operator. The single point logon shall override the current logon on the fare box
Headsign Integration. The MDT software shall control the destination text to be displayed on the existing headsigns. The Contractor shall confirm if any upgrades to the headsign or headsign controller firmware are needed to implement this interface. NTD will coordinate these upgrades.
APC Installation/Integration. "The APC controller shall be integrated with the on-board MDT, based on the standard SAE J-1708/J-1587 or J-1939 VAN."
Optional Vehicle Component Monitoring. "The MDT shall be integrated with existing J1708/1587 and J1939 network on the fixed-route fleet to collect codes from Engine Control Module, Transmission Control Module and Automatic Braking System."
Integration with Interior DMS. "The Contractor shall install new interior DMS that shall communicate with AVA controller over the J1708/1939 network."

On-board System Overview for Fixed-Route and Dual-Use Vehicles. Please see the Extended Text Description below.

(Extended Text Description: On-board System Overview for Fixed-Route and Dual-Use Vehicles: This graphic shows an example of the relationships among various ITS technologies onboard an NTD vehicle. The orange boxes show existing systems that are integrated through the use of J1708/J1587. The purple boxes show the required and deployed core systems, and the red boxes show systems that may be deployed in the future. The black lines are connections made using the vehicle area network (VAN) that employs J1708/J1587. In the center of the diagram is a purple box labeled MDT (Mobile Data Terminal). Coming from the top of MDT, is a black line that is connected to a purple box labeled "APC," an orange box labeled "Headsign," an orange box labeled "Farebox" and a red box labeled "Maintenance Network Gateway." To the left of the MDT box is a line connecting to boxes labeled "GPS Receiver and Antenna," (purple) "Odometer," (purple) "Doors," (orange), "Covert Alarm Switch," (purple) "Cell Data Modem," (purple) and "Wheelchair" (orange). The APC is connected to the front-door sensor and rear-door sensor via an alternative link. Connected by another vehicle area network to the MDT are the Interior DMS (purple) and the AVA Controller (purple) via a black line, and the DVR (red) via a red line which indicates an Ethernet connection. The AVA controller is then connected to the PA system and Ambient Noise Control Microphone. The DVR is connected to internal and external cameras.)

Figure 2. On-board System Overview for Fixed-Route and Dual-Use Vehicles

Optional Interface with Transit Signal Priority (TSP) Emitter (fixed-route only). "The MDT shall be interfaced with signal priority emitters using the standard VAN. The Contractor shall obtain from the emitter vendor the standard interface, protocols and messages applicable to the emitter for communication with the MDT."

3.5. Ann Arbor Area Transportation Authority (AAATA) Computer-aided Dispatch (CAD)/ Automatic Vehicle Location (AVL)

The following bullets are from portions of the AAATA's specifications that address SAE J1708 or J1939:

The Contractor shall install communications cabling and connections compliant with the Society of Automobile Engineers (SAE) J-1708/1587 or J-1939 network standard, to form a VAN connecting the MDT with fare box, headsign, APC controller, DVR [optional], AVA controller and interior DMS for AVA, for common login, operating control and other integrated functionalities.

All supported Message IDs (MID) and Parameter IDs (PID), available for communications with onboard devices using the J-1708/1587 or J-1939 interface, shall be fully documented.
The APC controller shall be integrated with the on-board MDT, based on the standard SAE J-1708/J-1587 or J-1939 VAN.
The MDT shall interface with the existing GFI fare box over J1939 network to enable single point logon for the vehicle operator. The single point logon shall negate the need for operators to logon on the fare box
The Contractor shall install new interior DMS that shall communicate with AVA controller over the J1708/1939 network.
The MDT shall be integrated with existing J1708/1587 and J1939 network on the fixed-route fleet to collect codes from Engine Control Module, Transmission Control Module and Automatic Braking System.

4. Reference to Other Standards

There are a few other standards related to the on-board transit standards described in this module. The following subsections explain these additional standards.

4.1. Open System Interconnection (OSI)

While this is not a standard, it is critical to understand Open System Interconnection (OSI). OSI is an ISO standard for worldwide communications that defines a networking framework for implementing protocols in seven layers. Control is passed from one layer to the next, starting at the application layer in one station, proceed to the bottom layer, over the channel to the next station and back up the hierarchy.

The 7 layers are defined as follows²:

Physical (Layer 1): This layer conveys the bit stream - electrical impulse, light or radio signal -- through the network at the electrical and mechanical level. It provides the hardware means of sending and receiving data on a carrier, including defining cables, cards and physical aspects.
Data Link (Layer 2): At this layer, data packets are encoded and decoded into bits. It furnishes transmission protocol knowledge and management and handles errors in the physical layer, flow control and frame synchronization. The data link layer is divided into two sub layers: The Media Access Control (MAC) layer and the Logical Link Control (LLC) layer. The MAC sub layer controls how a computer on the network gains access to the data and permission to transmit it. The LLC layer controls frame synchronization, flow control and error checking
Network (Layer 3): This layer provides switching and routing technologies, creating logical paths, known as virtual circuits, for transmitting data from node to node. Routing and forwarding are functions of this layer, as well as addressing, internetworking, error handling, congestion control and packet sequencing.
Transport (Layer 4): This layer provides transparent transfer of data between end systems, or hosts, and is responsible for end-to-end error recovery and flow control. It ensures complete data transfer.
Session (Layer 5): This layer establishes, manages and terminates connections between applications. The session layer sets up, coordinates, and terminates conversations, exchanges, and dialogues between the applications at each end. It deals with session and connection coordination.
Presentation (Layer 6): This layer provides independence from differences in data representation (e.g., encryption) by translating from application to network format, and vice versa. The presentation layer works to transform data into the form that the application layer can accept. This layer formats and encrypts data to be sent across a network, providing freedom from compatibility problems. It is sometimes called the syntax layer.
Application (Layer 7): This layer supports application and end-user processes. Communication partners are identified, quality of service is identified, user authentication and privacy are considered, and any constraints on data syntax are identified. Everything at this layer is application-specific. This layer provides application services for file transfers, email, and other network software services. Telnet and FTP are applications that exist entirely in the application level. Tiered application architectures are part of this layer.

² http://www.webopedia.com/TERM/O/OSI.html and http://www.webopedia.com/quick_ref/OSI_Layers.asp

4.2. Society of Automotive Engineers (SAE) J1939 Documents

SAE J1939 is defined by a series of documents shown on Table 1 that describe various aspects of the standard. For example, the physical layer (J1939/11) describes the electrical interface to the bus (bus being a shared digital pathway between resources and devices). The data link layer (J1939/21) describes the rules for constructing a message, accessing the bus, and detecting transmission errors. The application layer (J1939/71 and J1939/73) defines the specific data contained within each message sent across the network.

Table 1. Core J1939 Standards

J1939	Recommended Practice for a Serial Control and Communications Vehicle Network
J1939-01	Recommended Practice for Control and Communications Network for On-Highway Equipment
J1939-02	Agricultural and Forestry Off-Road Machinery Control and Communication Network
J1939-03	On Board Diagnostics Implementation Guide
J1939-05	Marine Stern Drive and Inboard Spark-Ignition Engine On-Board Diagnostics Implementation Guide
J1939-11	Physical Layer - 250k bits per second, Twisted Shielded Pair
J1939-13	Off-Board Diagnostic Connector
J1939-15	Reduced Physical Layer, 250K Bits/sec, Un-Shielded Twisted Pair (UTP)
J1939-21	Data Link Layer
J1939-31	Network Layer
J1939-71	Vehicle Application Layer
J1939-73	Application Layer - Diagnostics
J1939-74	Application - Configurable Messaging
J1939-75	Application Layer - Generator Sets and Industrial
J1939-81	Network Management
J1939-82	Compliance - Truck and Bus
J1939-84	OBD Communications Compliance Test Cases for Heavy Duty Components and Vehicles

4.3. Society of Automotive Engineers (SAE) J1587

An example of a J1587 message was provided in the slides. The example was a J1587 message for battery voltage. See Figure 3.

J1587 Example. Please see the Extended Text Description below.

(Extended Text Description: J1587 Example. There is a graphic at the bottom of this slide. There is one rectangular box labeled "J1587 Message" with five smaller boxes inside. The first inside box on the far left-hand side is labeled "MID=128." The small box to the right of this box is labeled "PID=158." The small box to the right of this box is labeled "29." The small box to the right of this box is labeled "1." The small box to the right of this box is labeled "Checksum=196.")

Figure 3. J1587 Example

The Battery Voltage, which is PID 158, is specified as follows:

Parameter Data Length: 2 Characters (which is equal to 2 bytes in this protocol)
Data Type: Unsigned integer
Bit Resolution: 0.05 V
Maximum Range: 0.0 to 3276.75 V
Transmission Update Period: On request
Message Priority: 8

Now, look for PID = 158 in the message and extract the data characters according to the specification above. Due to the specification there are two characters of data and they should be treated like an unsigned integer (16 bits where the bits are grouped into 8 bits and sent in reverse order). The interpretation of the data bytes 29 and 1 as an unsigned integer is (1*2⁸)+(29*2⁰) = 285. The result must then be scaled by the bit resolution (=0.05V per bit), i.e. 285 * 0.05 = 14.25V which is the voltage level at the engine ECU.

Every PID is followed by a number of parameter data bytes. Their number and interpretation depend on the value of the PID.

4.4. Society of Automotive Engineers (SAE) J1708

An example of a J1708 message was provided in the slides. The example is sending a message from the node at the brakes of a transit bus (MID = 8). See Figure 4.

J1708 Example. Please see the Extended Text Description below.

(Extended Text Description: J1708 Example. There is a graphic at the bottom of this slide. There is one rectangular box labeled "J1708 Message" with five smaller boxes inside. The first inside box on the far left-hand side is labeled "MID=8." The small box to the right of this box is labeled "Data 1=123." The small box to the right of this box is labeled "Data 2=221." The small box to the right of this box is labeled "Data 3=101." The small box to the right of this box is labeled "Checksum=59.")

Figure 4. J1708 Example

The messages are byte-oriented, that is to say constructed of a number of bytes. Every byte consists of a start bit eight data bits and a stop bit. The start bit is of logical low level and the stop bit is a logical high level. The eight data bits are sent with the least significant bit first. This follows a standard serial UART (Universal Asynchronous Receiver/ Transmitter) communication. A message is always preceded by an idle time which is at least the shortest bus access time. The time between two bytes in a message is not allowed to be more than two bit times.

The information to send is 123, 221 and 101 from the node at the brakes of a transit bus (MID = 8). The sum of these gives 8 + 123 + 221 + 101 = 453 = (1C5)_W. Mask the 8 least significant bits => (C5)_w= (11000101)2. Take the two's complement: (00111010)2 + 1 = (00111011)2 = 59. The complete message to be sent will now be: 8, 123, 221, 101, 59. The reason why the checksum is calculated as described is that it becomes easy in the receiver to detect an error in the message. The receiver will just have to add all the characters in the message (including the checksum) and make sure that the eight least significant bits of the sum are equal to zero

4.5. Institute of Electrical and Electronics Engineers (IEEE) 802.3

"Ethernet, defined under IEEE 802.3, is one of today's most widely used data communications standards, and it finds its major use in Local Area Network (LAN) applications. Ethernet, IEEE 802.3 offers a considerable degree of flexibility in terms of the network topologies that are allowed. Furthermore as it is in widespread use in LANs, it has been developed into a robust system that meets the needs to wide number of networking requirements.

"The Ethernet IEEE 802.3 LAN can be considered to consist of two main elements:

Interconnecting media: The media through which the signals propagate is of great importance within the Ethernet network system. It governs the majority of the properties that determine the speed at which the data may be transmitted. There are a number of options that may be used:
- Coaxial cable: This was one of the first types of interconnecting media to be used for Ethernet. Typically the characteristic impedance was around 110 ohms and therefore the cables normally used for radio frequency applications were not applicable.
- Twisted Pair Cables Type types of twisted pair may be used: Unshielded Twisted Pair (UTP) or a Shielded Twisted Pair (STP). Generally the shielded types are better as they limit stray pickup more and therefore data errors are reduced.
- Fiber optic cable: Fiber optic cable is being used increasingly as it provides very high immunity to pick up and radiation as well as allowing very high data rates to be communicated.
The network nodes are the points to and from which the communication takes place. The network nodes also fall into categories:
- Data Terminal Equipment - DTE: These devices are either the source or destination of the data being sent. Devices such as PCs, file servers, print servers and the like fall into this category.
- Data Communications Equipment - DCE: Devices that fall into this category receive and forward the data frames across the network, and they may often be referred to as 'Intermediate Network Devices' or Intermediate Nodes. They include items such as repeaters, routers, switches or even modems and other communications interface units."³

³ http://www.radio-electronics.com/info/telecommunications networks/ethernet/ethernet-ieee-802-3-tutorial.php

4.6. 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:

802.11 — applies to wireless LANs and provides 1 or 2 [megabits per second] Mbps transmission in the 2.4 [gigahertz] GHz band using either frequency hopping spread spectrum (FHSS) or direct sequence spread spectrum (DSSS).
802.11a — an extension to 802.11 that applies to wireless LANs and provides up to 54-Mbps in the 5GHz band. 802.11a uses an orthogonal frequency division multiplexing encoding scheme rather than FHSS or DSSS.
802.11b (also referred to as 802.11 High Rate or Wi-Fi) — an extension to 802.11 that applies to wireless LANS and provides 11 Mbps transmission (with a fallback to 5.5, 2 and 1-Mbps) in the 2.4 GHz band. 802.11b uses only DSSS. 802.11b was a 1999 ratification to the original 802.11 standard, allowing wireless functionality comparable to Ethernet.
802.11e — a wireless draft standard that defines the Quality of Service (QoS) support for LANs, and is an enhancement to the 802.11a and 802.11b wireless LAN (WLAN) specifications. 802.11e adds QoS features and multimedia support to the existing IEEE 802.11b and IEEE 802.11a wireless standards, while maintaining full backward compatibility with these standards.
802.11g — applies to wireless LANs and is used for transmission over short distances at up to 54-Mbps in the 2.4 GHz bands.
802.11n — 802.11n builds upon previous 802.11 standards by adding multiple-input multiple-output (MIMO). The additional transmitter and receiver antennas allow for increased data throughput through spatial multiplexing and increased range by exploiting the spatial diversity through coding schemes like Alamouti coding. The real speed would be 100 Mbit/s (even 250 Mbit/s in PHY level), and so up to 4-5 times faster than 802.11g.
802.11ac — 802.11ac builds upon previous 802.11 standards, particularly the 802.11n standard, to deliver data rates of 433Mbps per spatial stream, or 1.3Gbps in a three-antenna (three stream) design. The 802.11ac specification operates only in the 5 GHz frequency range and features support for wider channels (80MHz and 160MHz) and beamforming capabilities by default to help achieve its higher wireless speeds. This standard is being used currently for new wireless access points (WAPs) in transit garages and facilities in order to upload or download data and software updates.
802.11ac Wave 2 — 802.11ac Wave 2 is an update for the original 802.11ac spec that uses [multiple user] MU-MIMO technology and other advancements to help increase theoretical maximum wireless speeds for the spec to 6.93 Gbps.
802.11ad — 802.11ad is a wireless specification under development that will operate in the 60GHz frequency band and offer much higher transfer rates than previous 802.11 specs, with a theoretical maximum transfer rate of up to 7Gbps (Gigabits per second).
802.11ah— Also known as Wi-Fi HaLow, 802.11ah is the first Wi-Fi specification to operate in frequency bands below one gigahertz (900 MHz), and it has a range of nearly twice that of other Wi-Fi technologies. It's also able to penetrate walls and other barriers considerably better than previous Wi-Fi standards.
802.11r - 802.11r, also called Fast Basic Service Set (BSS) Transition, supports VoWi-Fi handoff between access points to enable VoIP roaming on a Wi-Fi network with 802.1X authentication.
802.1X — Not to be confused with 802.11x (which is the term used to describe the family of 802.11 standards) 802.1X is an IEEE standard for port-based Network Access Control that allows network administrators to restricted use of IEEE 802 LAN service access points to secure communication between authenticated and authorized devices."⁴
"802.11p is one of the recent approved amendments to the IEEE 802.11 standard to add wireless access in vehicular environments (WAVE). It appended some enhancements to the latest version of 802.11 that required to support applications of Intelligent Transportation Systems (ITS). This includes data exchange between high-speed vehicles and between the vehicles and the roadside infrastructure in the licensed ITS band."⁵

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

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

5. Glossary

To include additional descriptions/acronyms used primarily in the module. List out in alphabetical order.

Term	Definition
Checksum	A count of the number of bits in a transmission unit that is included with the unit so that the receiver can check to see whether the same number of bits arrived.
Controller Area Network (CAN)	A serial bus network of microcontrollers that connects devices, sensors and actuators in a system or sub-system for real-time control applications. There is no addressing scheme used in controller area networks, as in the sense of conventional addressing in networks (such as Ethernet). Rather, messages are broadcast to all the nodes in the network using an identifier unique to the network. Based on the identifier, the individual nodes decide whether or not to process the message and also determine the priority of the message in terms of competition for bus access. This method allows for uninterrupted transmission when a collision is detected, unlike Ethernets that will stop transmission upon collision detection.
Interface Class	In order for a subsystem to communicate with other subsystems, one or more of the telecommunication connections would be used to make a link between the subsystems. Subsystem to subsystem communications are categorized by the communicating subsystem category, or interface classes. For example, the communication between a "center" subsystem and another "center" subsystem (such as a traffic management center communication with a transit management center) belongs to the center-to-center (C2C) interface class. Other communications interface classes include center-to-field (C2F), center-to-vehicle, center-to-traveler, roadside-to-vehicle, and roadside-to-roadside.
Interface Control Document (ICD)	ICDs are the formal means of establishing, defining, and controlling interfaces and for documenting detailed interface design definitions. In other words, an ICD describes the interworking of two elements of a system that share a common interface. For example, a communications interface is described in terms of data items and messages passed, protocols observed and timing and sequencing of events. An ICD may also describe the interaction between a user and the system, a software component and a hardware device or two software components.
Open System Interconnection (OSI)	An International Organization For Standardization (ISO) standard for worldwide communications that defines a networking framework for implementing protocols in seven layers. Control is passed from one layer to the next, starting at the application layer in one station, proceed to the bottom layer, over the channel to the next station and back up the hierarchy.
SAEJ1587	SAE J1587 is a specification which defines messages that are transmitted on a SAE J1708 network. J1708 specifies the data link and physical layers, while J1587 specifies the transport, network, and application layers.
SAEJ1708	The SAE J1708 specification specifies a differential serial communications bus for inter-connecting electronic control units (ECUs) on heavy-duty and commercial vehicles. It does this by standardizes a hardware and software protocol for sending messages.
SAEJ1939	SAE J1939 is used in the commercial vehicle area for communication in the commercial vehicle. In this application note, the properties of SAE J1939 should be described in brief. SAE J1939 uses CAN (Controller Area Network, ISO11998) as physical layer. It is a recommended practice that defines which and how the data is communicated between the ECUs within a vehicle network. Typical controllers are the Engine, Brake, Transmission, etc.
Systems Engineering Process (SEP)	Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem.
Vehicle Area Network (VAN)	A local area network in and around a moving vehicle. It enables devices in and around the vehicle to communicate, either directly connected or through wireless protocols over the Internet.

6. References

Shinyoung Cho, "Vehicle Area Networks," http://www3.cs.stonybrook.edu/~bjchoi/teaching/cse534/resources/VAN.pdf- content is no longer available.

"Controller Area Network," http://www.webopedia.com/TERM/C/controller area network.html- content is no longer available.

"RoadRecorder® 7000 NVR J1939 Implementation Specification," Version: 1, Revision: 2, ©2014

"What is Systems Engineering," http://www.incose.org/AboutSE/WhatIsSE- content is no longer available.

"Consolidation of On-Board Ancillary Equipment for Metrobus,"http://itsmd.org/wp-content/uploads/Jonathan-Walker-WMATAs-Consolidation-of-On-Board-Bus-Equipment.pdf

Road Recorder 6000 Pro, J1939 Implementation Specification

Kvaser, "Introduction to SAE J1587," https://www.kvaser.com/about-can/can-standards/j1587/

SAE International, "J1587: Electronic Data Interchange between Microcomputer Systems in Heavy-Duty Vehicle Applications," http://standards.sae.org/j1587 201301- content is no longer available.

Simma Software, "J1587 Introduction," https://www.simmasoftware.com/j1587-introduction.pdf

"In-Vehicle Networking," Lecture 6 Introduction to SAE J1587, BAE 5030 - 003, Fall 2008, Instructor: Marvin Stone, Biosystems and Agricultural Engineering, Oklahoma State University

Kvaser, "Introduction to SAE J1708," https://www.kvaser.com/about-can/can-standards/j1708/

Texas Instruments, "AN-915 Automotive Physical Layer SAE J1708 and the DS36277," https://www.ti.com/lit/an/snla038b/snla038b.pdf

Simma Software, "J1708 | SAE J1708 Software, Protocol Stack, Source Code," https://www.simmasoftware.com/j1708.html

John Toone, "Seattle Metro and Mobile Routers," presented at APTA Fare Collection Workshop, March 2011, http://www.apta.com/mc/fctt/previous/2011fare/program/Presentations/Seattle%20Metro%20and%20mobile%20routers.pdf- content is no longer available.

John Toone, "King County Metro RapidRide ITS: Technology Review and Lessons Learned," https://www.apta.com/mc/its/previous/2015-april/presentations/Presentations/King%20County%20Metro%20RapidRide%20ITS%20Technology%20Review%20and%20Lessons%20Learned%20-%20John%20Toone.pdf- content is no longer available.

John Toone, "King County Metro RapidRide: Transit Signal Priority in a Connected Vehicles Environment," http://www.signalsystems.org.vt.edu/documents/July2013AnnualMeeting/Toone Metro TSP TRB2 013.pdf- content is no longer available.

Ben Hoffman, "New Eagle J1939 Blockset for MotoHawk," June 19, 2014, https://www.neweagle.net/wp-content/uploads/2014/06/NewEagle J1939 Seminar 6 19.pdf- content is no longer available.

Fetah Basic, "Vehicle Network Gateway (VNG) (With emphasis on the j1850 interface)," http://ece.utah.edu/~cs3992/archive/2004/VNG-final-prop.pdf- content is no longer available.

Doug J. Parker, "AVL Systems for Bus Transit: Update," TCRP Synthesis 73, Sponsored by the Federal Transit Administration, 2008, http://www.tcrponline.org/PDFDocuments/tsyn73.pdf

Bill Brown, Avail and Patrick Dietrich, Connect Tech, "Case Study: Location-Aware Public Transit Drives Custom 1/0 Controller Card Development I Transportation Systems," http://eecatalog.com/transportation/2013/06/07/case-study-location-aware-public-transit-drives-custom-io-controller-card-development/- content is no longer available.

SAE, "The SAE J1939 Communications Network: An overview of the J1939 family of standards and how they are used," http://www.sae.org/misc/pdfs/J1939.pdf- content is no longer available.

Simma Software, Inc., "Understanding SAE J1939," https://www.simmasoftware.com/j1939-presentation.pdf

Simma Software, Inc., "J1708 Introduction," https://www.simmasoftware.com/j1708-introduction.pdf

Vector, "Introduction to J1939," Version 1.1, 2010-04-27, Application Note AN-ION-1-3100, http://vector.com/portal/medien/cmc/application notes/AN-ION-1-3100 Introduction to J1939.pdf- content is no longer available.

Motor Coach Industries, "Maintenance Matters: Driving the Data Bus," February 2009, http://www.mcicoach.com/fyiFromMci/maintMatters/0209.htm- content is no longer available.

John J. Schiavone, "Understanding and Applying Advanced On-Board Bus Electronics," TCRP Report 43, 1999, http://onlinepubs.trb.org/onlinepubs/tcrp/tcrp rpt 43.pdf- content is no longer available.

R. Haas, E. Perry and J. Rephlo, "A Case Study on Applying the Systems Engineering Approach: Best Practices and Lessons Learned from the Chattanooga SmartBus Project," prepared for United States Department of Transportation, ITS Joint Program Office, Research and Innovative Technology Administration (RITA), November 2009, http://ntl.bts.gov/lib/32000/32600/32672/61027 se.pdf- content is no longer available.

John Carney, "APTA Bus Maintenance Webinar Series: Remote Diagnostics," http://www.docfoc.com/2012-apta-bus-roadeo-maintenance-vehicle-inspection-guidelines-sponsored-by-fraser-guage- content is no longer available.

"A Brief Introduction to SAE J1708 and J1587"

Ann Arbor Area Transportation Authority, Request for Proposal (RFP) #2015-09 for: INTELLIGENT TRANSPORTATION SYSTEMS (ITS) COMPUTER AIDED DISPATCH (CAD/AVL), October 20, 2014, http://www.mitn.info/xfer/PublicSolicitation Docs/SDIR~136985/0-RFP%202015-09%20ITS%20(CAD-AVL)%20System.pdf- content is no longer available.

Norwalk Transit District, Request for Proposals (RFP), "Purchase, Installation and Support of An Intelligent Transportation System," July 22, 2013, http://www.norwalktransit.com/documents/1-proposalprocedure.doc- content is no longer available.

Capital District Transportation Authority (CDTA), Request for Proposals (RFP), "INTELLIGENT TRANSPORTATION MANAGEMENT SYSTEM (ITMS)," Proposal Number: CDTA IT-57-1000, issued April 8, 2016, https://www.cdta.org (requires registration)

7. Study Questions

1. Which one of these is not a layer within Open System Interconnection (OSI) model?

Application
Data
Service
Physical

2. Which one of these differences between SAE J1939 and J1708 is not true?

J1939 is much faster than J1708
J1939 permits a connection of more units than J1708
J1939 is based on the Controller Area Network (CAN)
J1939 covers the same number of OSI layers as J1708

3. What is an interface control document (ICD)?

Documents and tracks necessary information to define system's interface
Communicates inputs and outputs for all potential actions whether internal to system or transparent
Helps ensure compatibility between system segments and components
All of the above

8. Icon Guide

The following icons are used throughout the module to visually indicate the corresponding learning concept listed out below, and/or to highlight a specific point in the training material.

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.

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.

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.

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.

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.

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