Module 19: On-Board Transit Management Systems - PDF of the PowerPoint Presentation

U.S. Department of Transportation

Office of the Assistant Secretary for

Research and Technology

Image specific

to content

Module 19:

On-Board Transit Management Systems

Instructor

Carol L. Schweiger

President

Schweiger Consulting LLC

Review key concepts from Module 5 Transit

Management Standards, Part 2 of 2

Describe how to use the most prevalent standards

for On-board Transit Management systems for buses

Illustrate how to procure systems using the most

prevalent transit on-board management standards

Review Key Concepts from

Module 5 Transit Management

Standards, Part 2 of 2

Structure and Use of Data Exchange Standards

 User need:

▫ Requirement for system to solve user problem

▫ Part of systems engineering process (SEP)

▫ FTA National ITS Architecture Policy includes identification of

applicable ITS standards

▫ May be satisfied by using standards

 Standards being used to meet user needs:

▫ Users may not need customized solutions

▫ Data exchanges facilitated among applications and entities

▫ Can choose most suitable and cost-effective applications, knowing

they use common standards

Standards Facilitate Meeting User Needs

Structure and Use of Data Exchange Standards

 Benefits from using standards:

▫ Reduce complexity and cost in design, procurement,

development and management

▫ Ensure wider choice of suppliers

▫ Certain types of standards strategic to economic

performance

Standards Facilitate Meeting User Needs (continued)

Structure and Use of Data Exchange Standards

 Protection of

investment:

▫ Modularization and

incremental deployment

▫ Choice of suppliers

▫ Reuse

 Interoperability:

▫ Roadmap for evolution

▫ Data management

 Improved quality and

value:

▫ Risk reduction

▫ Better abstraction

▫ Better testing

▫ Process and tool support

▫ Modularization

▫ Reuse

Standards Facilitate Meeting User Needs: Value

Structure and Use of Data Exchange Standards

 International Organization for Standardization (a.k.a. ISO)

standard for worldwide communications that defines

networking framework for implementing standards/protocols

in seven layers

 7 Layers:

▫ Application

▫ Presentation

▫ Session

▫ Transport

▫ Network

▫ Data Link

▫ Physical

Open System Interconnection (OSI)

Structure and Use of Data Exchange Standards

OSI 7 Layer Model: Layers 7, 6 and 5

Layer Application/Example

7. Application. Serves as the window

for users and application processes to

access the network services

End user layer (Program that

opens what was sent or creates

what is to be sent)

6. Presentation. Formats the data to be

presented to the Application layer. It can

be viewed as the “Translator” for the

network

Syntax layer (encrypt and

decrypt if needed)

5. Session. Allows session

establishment between processes

running on different stations

Sync and send to ports (logical

ports)

Structure and Use of Data Exchange Standards

OSI 7 Layer Model: Layers 4, 3, 2 and 1

Layer Application/Example

4. Transport. Ensures that messages

are delivered error-free, in sequence and

with no losses and duplication

Transmission Control Protocol -

TCP (host to host, flow control)

3. Network. Controls the operations of

the subnet, deciding the physical path

the data takes

Packets (“letter,” contains IP

address)

2. Data Link. Provides error-free

transfer of data frames from one node to

another over the Physical layer

Frames (“envelopes,” contains

MAC address)

1. Physical. Concerned with

transmission and reception of raw bit

stream over physical medium

Physical structure (cables, hubs,

etc.)

Structure and Use of Data Exchange Standards

 Facilitates vehicle area network (VAN)

 Only describes two lowest layers

▫ Physical

▫ Data Link

 Used in conjunction with SAE J1587, which:

▫ Is an application layer

▫ Defines format of J1708 messages sent between

microprocessors devices in transit vehicles

▫ Supports communication with external devices

connected to VAN

 J1708 message consists of Message Identification (MID)

character, data bytes and checksum

SAE J1708/J1587

Structure and Use of Data Exchange Standards

 High speed ISO 11898-1 Controller Area Network (CAN)

based communications network:

▫ Simple information exchanges and diagnostic data exchanges

between components physically distributed throughout vehicle

▫ Allows components associated with different manufacturers to

communicate with each other

 Successor to SAE J1708/J1587 low speed networks -

earlier standards provided simple information exchange

between on-board components

 Every J1939 message uses identifier that defines:

▫ Message priority

▫ From whom it was sent

▫ Data that is contained within it

SAE J1939

Structure and Use of Data Exchange Standards

 Layer 1 (physical layer) - electric

interface with physical medium

 Layer 2 (data link layer) - data

communication via Controller

Area Network (CAN) (ISO

standard-ISO 11898 for serial

data communication) based on

CAN 2.0B

 Layer 3 (network layer) -

functionality of bridge for

transmission of messages

between two network segments

SAE J1939 (continued)

Document

Structure and Use of Data Exchange Standards

 Layer 4 (transport layer) - various

network services for message

request mode, acknowledged

transmission, and fragmented

transmission of large data blocks

 Layer 7 (application layer):

▫ Actual data (parameters or

network variables with value

range, resolution, physical unit

and the type of transmission)

▫ Each message unambiguously

referenced by parameter group

number

 Network management - automatic

allocation or determination of node

addresses (plug and play principle)

SAE J1939 (continued)

Document

ITS Standards for Data Exchange Among Transit

Management Systems

 Interface between transit management center and specific type of

infrastructure: dynamic message signs (DMS) and transit signal priority

(TSP)

 DMS:

▫ Information to travelers

▫ May use various technologies to display messages using any

combination of characters

 TSP:

▫ Intersection control through local traffic signal controller

▫ Interface between traffic management center and on-street master

controller

▫ Based on analysis of transit vehicle’s conditions and traffic

characteristics for a given time and type of day

▫ Center invokes appropriate pre-configured traffic signal control

system timing plan

Center-to-Field (C2F) Application Area

Capabilities Related to Transit

ITS Standards for Data Exchange Among Transit

Management Systems

Interface between transit management center and transit or

paratransit vehicles

 Collecting automated vehicle location information

 Collecting operational and maintenance data

 Providing transit vehicle driver with electronic dispatch and routing

instructions

 Providing traveler information to vehicle

 Providing schedule information used to develop corrective actions on-

board

 Providing fare management information, including invalid traveler

credit identities, to transit vehicles

 Supporting transit vehicle operator authentication and ability to

remotely disable vehicle in emergency situations

Center-to-Vehicle/Traveler (C2V) Application

Area Capabilities Related to Transit: Vehicle

ITS Standards for Data Exchange Among Transit

Management Systems

Interfaces between traveler information providers and devices

used by traveling public

 General traveler information, including traffic information, transit

information (fares, real-time schedules, and transactions), incident

information, event information, and parking information

 Emergency traveler information, including alerts and advisories, and

evacuation information

 Traveler services information (e.g., dining, lodging, etc.)

 Trip planning, using various modes of surface transportation and route

options

 Route guidance

Center-to-Vehicle/Traveler (C2V) Application

Area Capabilities Related to Transit: Traveler

ITS Standards for Data Exchange Among Transit

Management Systems

 Multimodal coordination between transit agencies and other public

transportation modes

 Transit incident information, schedules, fare and pricing information

 Transit information suitable for media use

 Emergency transit schedule information to other operations centers

 Transit system information to traffic management centers

 Personalized transit routes requested by travelers

 Financial institution approval and status of electronic fare payments

 Law enforcement regarding the notification of violations

Center-to-Center (C2C) Application Area

Capabilities Related to Transit

ITS Standards for Data Exchange Among Transit

Management Systems

 66 vehicles operating in max. service and 10,040,856 annual

passenger miles

 Required multiplex system on all buses purchased:

▫ System connected to SAE J1939 data bus

▫ Monitor common engine, transmission, and braking faults

transmitted on data bus (e.g., high engine oil temperature, low oil

pressure, high transmission oil temperature)

▫ Log data for later retrieval

 Main purpose was for integration with other planned in-vehicle

equipment

 Implemented daily upload of bus diagnostic information collected

onboard to Automatic Vehicle Monitoring server, making data available

to maintenance staff

Case Study for C2V Flows: Chattanooga Area

Regional Transportation Authority (CARTA)

ITS Standards for Data Exchange Among Transit

Management Systems

 Selection of standard(s) to incorporate in functional

specifications for AVM system based on:

▫ Availability

▫ Applicability

▫ Maturity

▫ Vendors’ use/acceptance

 Incorporated into specifications in appropriate location:

▫ On-board Device Alarms Reporting

▫ Automatic Vehicle Monitoring: On-board System

▫ Student Supplement contains specification language

Case Study for C2V Flows: CARTA AVM

Apply Standards to Development of Procurement

Specifications

 Transit Management standards not structured the same

way:

▫ SAE J1939 based on OSI layers

▫ GTFS is a series of comma-delimited text files

▫ GTFS-realtime format based on Protocol Buffers

▫ TransXChange (UK standard) is XML format

 Need to understand enough to:

▫ Identify appropriate standard(s) based on aforementioned criteria

▫ Define use of standard(s) in functional requirements/specifications

▫ Define how compliance with standard(s) can be tested

Read a Standard

Apply Standards to Development of Procurement

Specifications

Read a Standard: SAE J1939

Apply Standards to Development of Procurement

Specifications

 Most messages intended to be broadcast

 Data transmitted on the network without specific

destination:

▫ Permits any device to use data without requiring additional request

messages

▫ Allows future software revisions to easily accommodate new

devices

 When message must be directed to particular device,

specific destination address included within message

identifier

Read a Standard: SAE J1939 (continued)

Apply Standards to Development of Procurement

Specifications

 Discussion of Concept of Operations (ConOps)

 Components/devices you expect to be supplied in system

 Functions to be supported, value ranges and optional

capabilities required

 Detailed listing of requirements

 Language requiring use of standardized dialogs

 Testing program

Incorporate a Standard into a Specification

for Procuring a Transit Management System

Apply Standards to Development of Procurement

Specifications

Incorporate a Standard into a Specification

Concept of Operations:

What you want the

systems/devices to do

Document your

Requirements

Select Functions that

can be Standardized,

and Identify Value

Ranges or Specific

Values Where

Necessary

Select Specific Objects

and Value Ranges Where

Necessary to Meet

Requirements

Develop Test

Procedures

U.S. Department of Transportation

Office of the Assistant Secretary for

Research and Technology

Which one of these is not a layer within Open

System Interconnection (OSI) model?

a) Application

b) Data

c) Service

d) Physical

Answer Choices

Question

Review of Answers

a) Application

Incorrect. This is Layer 7 within the OSI model.

b) Data

Incorrect. This is a Layer 2 within the OSI model.

c) Service

Correct! This is not a layer within the Open System

Interconnection (OSI) model.

d) Physical

Incorrect. This is a Layer 1 within the OSI model.

Describe the details and how to use

the most prevalent standards for

On-board Transit Management

systems for buses

Contents and Use of SAE J1587

 Defines messages transmitted on SAE J1708 network

 Specifies transport, network and application layers

 Outdated and being replaced by J1939

 Defines format of messages and data being communicated

between on-board microprocessors

 Promotes software compatibility among microcomputer

based modules

 Used with SAE J1708, which:

▫ Defines requirements for hardware and basic protocol

needed to implement J1587

▫ Specifies data link and physical layers

Define and Describe the Purpose of J1587

J1587 Message

 Format:

▫ Message identifier (MID) – source address of

transmitting node

▫ One or More Parameters

▫ Checksum

 Messages start with MID indicating source address

of transmitting node

Contents and Use of SAE J1587

Describe the J1587 Message Format

MID Parameter Parameter Parameter Checksum

Contents and Use of SAE J1587

 J1587 specifies a parameter for Battery Voltage

 MID is 128, which means Engine #1

 Battery Voltage is PID 158

J1587 Example

J1587 Message

MID=128 PID=158 29 1

Checksum

=196

Contents and Use of SAE J1587

 J1587 is outdated, but is often found in legacy systems

▫ Vehicle and component information

▫ Routing and scheduling information

▫ Driver information relating to driver activity

 SAE J1708, defining basic hardware and conditions

required for on-board data exchange

 With J1708 backbone in place, J1587 added for general

on-board information sharing and diagnostic functions

 Whenever J1587 mentioned, assume that J1708 is

included

 Thus, use of J1587 and J1708 described together

Use of SAE J1587

Contents and Use of SAE J1708

 Addresses transmission of electronic signals and

information among bus components

 Identifies minimum hardware and procedural requirements

for routing messages over network

 Establishes method for determining:

▫ Which device is communicating (i.e., engine, farebox, etc.)

▫ Length of time that each device is allowed to communicate

▫ Which device has priority in accessing network when two try to gain

access simultaneously

▫ That message was received correctly should there be problems in

transmission

 Describes physical and data link layer

Define and Describe the Purpose of J1708

Contents and Use of SAE J1708

 SAE J1587 or J1922, defines actual data or functions to be

transmitted. SAE J1708 only defines hardware and basic

software

 Data can be transferred between devices in more cost-

effective way:

▫ Minimizes hardware cost

▫ Offers flexibility and further expansion of existing system

▫ Uses standard industry electronics

 Transmission rate 9600 bps

 Message up to 21 bytes long

Define and Describe the Purpose of J1708 (cont’d)

Contents and Use of SAE J1708

 Message consists of MID, data bytes and checksum

 Data content not described in J1708 specification but in overlaying

protocol, such as J1587

 MID is 0-255

▫ MIDs 0-68 belong to predefined devices to ensure consistency.

▫ MIDs 69-86 are set aside for J1922 protocol.

▫ MIDs 87-110 are reserved for future applications.

▫ MID 111 is designated for factory tests of electronic control units

and shall not be used by any on-board unit.

▫ MIDs 112-127 are not reserved and can be used as wanted.

▫ MIDs 128-255 are reserved for SAE J1587 protocol.

Describe the J1708 Message Format

J1708 Message

MID=8

Data 1=

123

Data 2=

221

Data 3=

101

Checksum

= 59

Contents and Use of SAE J1708

 Exchange information between AVL, VLU, fare collection,

radio, passenger information, and other systems

 Integration examples:

▫ Passenger information systems with AVL provides automatic

next-stop audio and visual announcements

▫ Fare collection with passenger counters, passenger

information systems and AVL identifies passenger trends

▫ On-board cameras and AVL to store video images on-board

for review or send emergency-related images in real time

 Combine health-monitoring capabilities of vital on-board

components with AVL to send fault alarms in real time

Use of SAE J1708

Contents and Use of SAE J1708

Use of SAE J1708

Contents and Use of SAE J1939

 Defines how information transferred across network to allow

Electronic Control Units to communicate information (e.g.

vehicle speed)

 17 J1939 documents – see earlier slide on how to read a

standard

 Capable of handling requirements currently satisfied by

J1708/J1587/J1922

 Spans all seven OSI layers

 Data rate of 250,000 bits per second, making it much faster

than J1708

Define and Describe the Purpose of J1939

Contents and Use of SAE J1939

 Permits connection of up to 30 units compared to maximum

of 20 for J1708

 Ensures data transmission time fully utilized

 Most messages defined by J1939 intended to be broadcast

▫ Data transmitted on network without specific destination

▫ Permits any device to use data without requiring

additional request messages

▫ Allows future software revisions to easily accommodate

new devices

 Uses the 29-bit identifier defined within CAN 2.0B protocol

Define and Describe the Purpose of J1939 (cont’d)

Contents and Use of SAE J1939

 Defines message timeouts, how large messages are fragmented

and reassembled, the network speed, the physical layer, and

how applications acquire network addresses

 Defined using collection of individual SAE J1939 documents

based on layers of OSI model

 Uses Controller Area Network (CAN) protocol permitting any

Electronic Control Units (ECU) to transmit message on network

 Every message uses an identifier that defines:

▫ Message priority

▫ From whom it was sent

▫ Data that is contained within it

 Collisions are resolved non-destructively as result of arbitration

process that occurs while identifier transmitted

Define and Describe the Purpose of J1939 (cont’d)

Contents and Use of SAE J1939

 J1939 messages built on top of CAN 2.0b - make specific use of

extended frames

 First three bits are priority field - sets message’s priority on network and

helps ensure messages with higher importance sent/received before

lower priority messages. Zero is highest priority

 Next bit reserved for future use - should be set to zero

 Next bit Data Page field used to expand maximum number of possible

messages

 Next eight bits Protocol Data Unit Format (PDU F) field - used to

determine if message intended for specific device on network or for

entire network

▫ If value of PDU F < 240, message meant for specific device

▫ If value is 240 or greater, message intended for all devices

 Next eight bits Protocol Data Unit Specific (PDU S) field - based on

value of PDU F field

Define and Describe the Purpose of J1939 (cont’d)

Contents and Use of SAE J1939

 If PDU F intended for specific device, PDU S is address of specific

device, PDU S field called Destination Address

 If PDU F intended for all devices, PDU S is Group Extension field used

to increase number of possible broadcast messages. Format is called

PDU 2

 Last eight bits identify address of device that transmitted current

message - Source Address Field

Define and Describe the Purpose of J1939 (concluded)

Contents and Use of SAE J1939

 Extended CAN identifier (29 bit)

 Bit rate 250 kbit/s

 Peer-to-peer and broadcast

communication

 Transport protocols for up to

1785 data bytes

 Network management

 Definition of parameter groups

for commercial vehicles and

others

 Manufacturer specific parameter

groups are supported

 Diagnostics features

J1939 Characteristics

Contents and Use of SAE J1939

 Sample of a parameter

group definition:

▫ Name: Engine

temperature 1 – ET1

▫ Transmission rate: 1s

▫ Data length: 8 bytes

▫ Extended Data Page 0

▫ Data page: 0

▫ PDU format: 254

▫ PDU specific: 238

▫ Default priority: 6

▫ PG Number: 65,262

(00FEEE16)

 Description of data:

▫ Byte: 1 Engine Coolant

Temperature

▫ 2 Engine Fuel

Temperature 1

▫ 3,4 Engine Oil

Temperature 1

▫ 5,6 Engine Turbocharger

Oil Temperature

▫ 7 Engine Intercooler

Temperature

▫ 8 Engine Intercooler

Thermostat Opening

J1939 Example

Use of Wireless Access Points and On-

board Internet

 Agencies use wireless

access points (WAPs)

to upload / download

data and perform

software updates for

vehicles

 Current WAPs use

IEEE 802.11ac

 On-board Wi-Fi for

passengers uses

802.11x

Use of IEEE 802.11x

Examples of Use of On-board Standards to

Provide a Single-point Logon

 Computer-aided Dispatch (CAD) allows for single point

logon for all on-board systems

 Driver can initiate systems connected to CAD (e.g., AVL,

farebox)

 Reduces potential for error

 Where more than one GPS unit on board provides one GPS

location and time/date stamp for all systems

 Keeps operational information being used and generated by

on-board systems synchronized

What is Single-point Logon?

Using Standards to Perform Single-point

Logon to On-board Devices

 Capital District Transportation Authority in Albany, NY

 Intelligent Transportation Management System (ITSM) includes

bidirectional interface between farebox and MDT/VLU with single

point logon

▫ Over J1708/1587 network

▫ Single point logon shall negate need for operators to logon

▫ Login includes time, date, driver ID no., route, run, trip and/or

pattern, real-time vehicle location, and vehicle number, which shall

be transferred to the MDT/VLU through bidirectional interface

▫ Changes made either by driver or remotely by dispatch through

MDT will update farebox logon and vice versa

▫ Operator shall continue to be able to use all farebox operator

control unit (OCU) features

Examples of Use of On-board Standards to

Provide a Single-point Logon

Single-point Logon at King County Metro

On-Board Architecture

Examples of Use of On-board Standards to

Provide a Single-point Logon

 On-Board Systems

(OBS) Project:

▫ Smart bus concept

▫ GPS/odometer/gyroscope

solution

▫ Stop announcements

▫ Next stop electronic

displays

▫ Destination sign

integration

▫ Automatic passenger

counting

▫ Vehicle monitoring

▫ Installs in progress

King County Metro (continued)

Examples of Use of On-board Standards to

Provide a Single-point Logon

 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

Use of On-board Standards to Provide a

Single-point Logon

Washington Metropolitan Area Transit Authority

(WMATA) Single-point Logon

U.S. Department of Transportation

Office of the Assistant Secretary for

Research and Technology

Which one of these differences between SAE

J1939 and J1708 is NOT true?

a) J1939 is much faster than J1708

b) J1939 permits a connection of more devices than J1708

c) J1939 is based on the Controller Area Network (CAN)

d) J1939 covers the same number of OSI layers as J1708

Answer Choices

Question

Review of Answers

a) J1939 is much faster than J1708

Incorrect. SAE J1939 has a data rate of 250,000 bits per

second, making it much faster than J1708

b) J1939 permits a connection of more devices than J1708

Incorrect. SAE J1939 also permits a connection of up to 30

units compared to a maximum of 20 for a J1708 network

c) J1939 is based on the Controller Area Network (CAN)

Incorrect. J1708 is not based on the CAN

d) J1939 covers the same number of OSI layers as J1708

Correct! J1939 covers all 7 layers while J1708 only

covers 2

Illustrate how to procure systems

using the most prevalent transit on-

board management standards

Case Study of Procuring System(s) Using

SAE J1708/1587

Identify system integration needs: Using vehicle area

network (VAN) to connect mobile data terminal (MDT) with:

 Farebox

 Headsign

 Automatic passenger counter (APC) controller

 Digital video recorder (DVR)

 Automatic voice annunciation (AVA) controller

 Interior AVA dynamic message signs (DMS)

 Optional on-board equipment:

▫ Transit signal priority (TSP) emitters

▫ On-board surveillance system

▫ Maintenance network gateways for vehicle component monitoring

Single-point login

Norwalk Transit District (NTD) CAD/AVL System

Case Study of Procuring System(s) Using

SAE J1708/1587

NTD CAD/AVL System

Case Study of Procuring System(s) Using

SAE J1708/1587

NTD CAD/AVL On-board Systems

Case Study of Procuring System(s) Using

SAE J1708/1587

 Vehicle Area Network (VAN)

 Farebox Integration

 Headsign Integration

 APC Installation/ Integration

 Optional Vehicle

Component Monitoring

 Integration with Interior

DMS

 Optional Interface with

Transit Signal Priority (TSP)

Emitter (fixed-route only)

NTD CAD/AVL Procurement

Case Study of Procuring System(s) Using

SAE J1708/1587

 Single-point login

 SAE J1708/1587 to

connect ITMS Vehicle

Logic Unit (VLU) with:

▫ Farebox

▫ Headsign

▫ Automatic Passenger

Counters (APC) controller

▫ Global Positioning System

(GPS) receiver

▫ Transit Signal Priority (TSP)

emitter

▫ Digital Video Recorder

(DVR)

▫ Automated Vehicle

Announcements (AVA)

controller

▫ Covert alarm

▫ Vehicle diagnostics

interfaces

▫ Support data transfer

to/from Central Data

System (CDS)

▫ P25 radios

▫ Interior Dynamic Message

Signs (DMS) for AVA

Capital District Transportation Authority (CDTA)

Intelligent Transportation Management System (ITMS)

Case Study of Procuring System(s) Using

SAE J1708/1587

 SPX-Genfare FastFare™ Fareboxes integration with ITMS

to provide:

▫ GPS data

▫ Single login capability across all on-board systems

 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

▫ Created during Planning and Design Phases

▫ Helps ensure compatibility between system segments

and components

CDTA ITMS – Interface Control Document (ICD)

Case Study of Procuring System(s) Using

SAE J1708/1587

 Scope/Purpose of ICD

 Physical interface

 J1587 Protocol:

▫ MID Assignments

▫ PID Definitions

▫ Application Protocol

 Initialization:

▫ Normal Vehicle Power Up

▫ MDT/VLU Power Interruption or Reboot

▫ Farebox Power Interruption or Reboot

Potential ICD Contents: Farebox – ITMS Integration

Case Study of Procuring System(s) Using

SAE J1708/1587

 MDT/VLU Initiated Logon

 Farebox Initiated Logon

 Location Reporting

 Starting a Trip

 Servicing a Stop

 Time Synchronization

 MDT/VLU Initiated Driver Logoff

 Farebox Initiated Driver Logoff

 Error Handling

Potential ICD Contents: Farebox – ITMS Integration

Case Study of Procuring System(s) Using

SAE J1708/1587

CDTA ITMS – Additional Testing for Integration

Case Study of Procuring System(s) Using

SAE J1939

 Vehicle area network (VAN):

▫ Farebox

▫ Headsign

▫ New interior DMS that

communicate with automatic voice

announcement (AVA) controller

▫ Automatic passenger counting

(APC) controller integrated with

the on-board mobile data terminal

(MDT)

▫ MDT to collect codes from Engine

Control Module, Transmission

Control Module and Automatic

Braking System

▫ Optional DVR

Ann Arbor Area Transportation Authority

(AAATA) CAD/AVL Hardware and Software

Case Study of Procuring System(s) Using

SAE J1939

AAATA CAD/AVL On-board Systems

Case Study of Procuring System(s) Using

SAE J1939

AAATA CAD/AVL Procurement

U.S. Department of Transportation

Office of the Assistant Secretary for

Research and Technology

What is an interface control document (ICD)?

a) Documents and tracks necessary information to define system’s

interface

b) Communicates inputs and outputs for all potential actions whether

internal to system or transparent

c) Helps ensure compatibility between system segments and

components

d) All of the above

Answer Choices

Question

Review of Answers

a) Documents and tracks necessary information to define system’s

interface

Incorrect. This answer is correct along with b and c

b) Communicates inputs and outputs for all potential actions

whether internal to system or transparent

Incorrect. This answer is correct along with a and c

c) Helps ensure compatibility between system segments and

components

Incorrect. This answer is correct along with a and b

d) All of the above

Correct! All statements are correct

Module Summary

1. Reviewed the structure and use of data

exchange standards for Transit Management

systems

2. Identified and described contents and use of

SAE J1587/J1708 and J1939, and provided

examples of single-point logon using standards

3. Provided case studies of procuring systems

using SAE J1587/J1708 and J1939

4. Identified what is included in specifications

Module Summary

1. The use of data exchange standards for Transit Management

systems allow agencies to use components/systems from multiple

vendors

2. The use of SAE J1708 must include J1587 as well

3. The selection of standard(s) to incorporate in functional

specifications is based on the standard’s availability, applicability,

maturity and the vendors’ use and acceptance of the standard

4. SAE J1708 is outdated, so transit agency may want to consider

moving their on-board systems to use J1939

Lessons Learned

Module Summary

5. Agencies have experienced cost savings through the use of on-

board transit standards, as shown in the CARTA case study

6. The use of on-board transit standards facilitates the replacement of

on-board components/systems

7. An Interface Control Document (ICD) documents the necessary

information required to effectively define a system’s interface as

well as any rules for communicating with them

8. Single-point login requires the use of on-board transit standards

Lessons Learned (continued)

Feedback

Please use the Feedback link below to

provide us with your thoughts and

comments about the value of the training.

Thank you!

Thank you for completing this module.