Module 19: On-Board Transit Management Systems
(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
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.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:
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:
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:
"22.214.171.124.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.
126.96.36.199.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."1
1 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/procurements/intelligent-transportation-management-system-itms, 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.
(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.")
(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:
(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
(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:
(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
(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
(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:
(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)
(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.)
(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.)
(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)
(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?
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.
(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
(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
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:
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 follows2:
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-71||Vehicle Application Layer|
|J1939-73||Application Layer - Diagnostics|
|J1939-74||Application - Configurable Messaging|
|J1939-75||Application Layer - Generator Sets and Industrial|
|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.
(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:
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*28)+(29*20) = 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.
(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:
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:
To include additional descriptions/acronyms used primarily in the module. List out in alphabetical order.
|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.|
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/procurements/intelligent-transportation-management-system-itms (requires registration)
7. Study Questions
1. Which one of these is not a layer within Open System Interconnection (OSI) model?
2. Which one of these differences between SAE J1939 and J1708 is not true?
3. What is an interface control document (ICD)?
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.
2) Tools/Applications: 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.
4) Refer to Student Supplement: 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.
6) Checklist: Use to indicate a process that is being laid out sequentially.