ITS Transit Standards Professional Capacity Building Program
Module 5: Transit Management Standards, Part 2 of 2
HTML of the Student Supplement
(Note: This document has been converted from the Student Supplement to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included, plus additional text descriptions for the images, photos and/or diagrams have been provided below.)
Module 5: Transit Management Standards, Part 2 of 2
Table of Contents
Introduction/Purpose - 2
Samples/Examples - 2
References to Other Standards - 6
Case Studies - 20
Glossary - 24
References - 25
Study Questions - 27
This module (Transit Management Standards, Part 2 of 2) is the second of the two course modules on Transit Management Standards. It introduces hardware and software standards in addition to Transit Communications Interface Profiles (TCIP), and explains how to use them. The information in this module will help participants identify which standards are most applicable to a particular situation so that an agency can reduce the life-cycle cost of technologies that support Transit Management functions and facilitate the integration with legacy or future technology systems. The structure and use of data exchange standards for Transit Management systems are described along with how to apply standards to the development of procurement specifications. Case studies are incorporated to enhance participants' understanding of how to use the standards.
From a National Intelligent Transportation Systems (ITS) Architecture perspective, Transit Management covers technologies and systems that facilitate and automate operations, planning, management, maintenance, safety, security and data management functions of public transit systems. Transit Management systems are typically located on-board vehicles and at central dispatch or garage locations. Communications technologies provide the basis for receiving and transmitting the data and information generated by these systems. In some cases, information generated by several Transit Management systems provides the basis for generating customer-facing traveler information.
As described in Module 2, there are four categories of Transit Management systems/technologies. The Fleet Operations and Management category covers technologies that are implemented to facilitate transit operations and provide input to senior management in terms of overall system performance. The Safety and Security category covers those technologies that improve the safety and security of transit staff and passengers through on-board and facility technologies. The Maintenance category covers technologies that facilitate maintenance activities, such as engine and vehicle component monitoring and tracking of scheduled and unscheduled maintenance activities and inventory systems. The Data Management category covers public transit ITS components installed in vehicles, at central locations (e.g., control centers), or at other locations (e.g., stops and shelters). These components generate an enormous amount of data typically collected and archived in the individual databases of systems that generate the data. The extent of field data collected onboard vehicles depends on the configuration of the ITS and its subsystems on vehicles or at other locations (e.g., refresh rate of automatic vehicle location (AVL) subsystem, recording rate of onboard video surveillance subsystem and health diagnostics, refresh rate for off-site equipment). Once the ITS data are archived, they are used for a variety of "after-the-fact" analyses and reporting by different business units within a public transport organization (e.g., planning, operations, customer service). Each of the technologies within each category was briefly defined in Module 2.
The relationships among central Transit Management and other transit ITS technologies are shown in Figure 1. Figure 2 shows an example of the relationships on-board a transit vehicle.
(Extended Text Description: Author's relevant notes: Example of Central System Technology Relationships: This graphic shows the relationships among various Central System Technologies. Beginning in the center of the graphic, there is a red rectangular column representing the Central Server Configuration. In this column the following servers are represented in individual blocks from top to bottom: Database Server, CAD/AVL (Computer Aided Dispatch and Automatic Vehicle Location) Server, APC/ASA Mgmt. Server, Fixed Route Scheduling Server, TSP Server, IVR Server, Communications Server, and RTIS/Web Server. 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 RTIS/Web Server, a red line representing data feed points down to a blue box labeled "Transit Agency Website." Coming from the left side of the RTIS/Web Server is another line pointing to blue box labeled "Third Party Developers." From the left side of the Communications Server, there is a dotted gray line that goes to a black box labeled "Comm Gateway" and branches upwards through three cloud networks (bottom to top: the Wi-Fi/Internet, Cellular Network, and Radio systems), going on to two separate yellow boxes. These boxes are labeled "Revenue Fleet" and "Non-revenue Fleet." From the Cellular network cloud, there is another dotted gray line going downwards representing the wireless connection to the Wayside DMS. Coming from the entire Central Server Configuration, there is a solid green line representing the LAN/WAN connection or VPN. This line goes through a light green box labeled "Transit Agency WAN and LAN" and branches out to a light blue section identified as the "Agency Configuration." Within the "Agency Configuration," the following items are represented in individual dark blue boxes (top to bottom): Electronic Payment System, Maintenance Management System, Video Playback Software, WLAN Download Manager, and Workstations to access central systems, VCM Software, and TSP System. Outside the "Agency Configuration," the LAN/WAN connection also leads to a dark blue box labeled as "Future Systems."))
Figure 1. Example of Central System Technology Relationships (courtesy TranSystems Corporation)
(Extended Text Description: Author's relevant notes: Example of Onboard Technology Relationships: This graphic shows an example of the relationships among various ITS technologies onboard a vehicle. In the center of the diagram is a box labeled MDT (Mobile Data Terminal). Coming from the top of MDT, is a box labeled "GPS Receiver and Antenna" connected via a voice radio connection. Connected to the MDT via a vehicle area network are the Maintenance Network Gateway, farebox, headsign and APC. The APC is connected to the front-door sensor and rear-door sensor via an alternative link. Utilizing both a Voice Radio Connection and a Data Connection, the MDT is connected to the Voice and Data Radio. This is then connected to the RF antenna. Connected by another vehicle area network are the Interior DMS, the ASA Controller, and the DVR. The ASA controller is then connected to the PA system and Ambient Noise Control Microphone. The DVR is connected to internal and external cameras. Coming from the bottom of the MDT rectangle is a red line representing an Ethernet link. This link connects a Wireless Mobile Router/Gateway with cellular modem and WLAN card. This link continues and also connects to the DVR. To the left, the MDT is also connected to the following: Collision Avoidance, Odometer, Covert Alarm Switch, Doors, and Wheelchair.))
Figure 2. Example of On-Board Technology Relationships (courtesy TranSystems Corporation)
In order to provide a further, general understanding of how these technologies are related to each other, Table 1 shows the dependencies among the technologies.
Table 1. Dependencies Among Transit ITS Technologies
1 OBD-II is a standard that monitors engine, chassis, body, and accessory devices in a vehicle
3. Reference to Other Standards
3.1. Application Areas
Application areas, as shown in Table 2, provide a starting point for identifying the ITS standards and other resources (e.g., case studies, lessons learned) that may be relevant to a specific type of deployment. Application areas are deployment-oriented categories that focus on commonly deployed ITS services or systems. The National ITS Architecture is divided into interface classes, which are further subdivided into application areas. Interface classes are defined by the type of system at each end of the communications path: center, field, vehicle, and traveler.
Typically, public transit management interface classes are center to infrastructure (C2I) (interfaces between a management center and its field equipment (e.g., dynamic message signs at stops); center to vehicle/traveler (interfaces between a center and the devices used by transit drivers or travelers) (C2V); and center to center (interfaces between transportation management centers) (C2C).
An application area within the C2I interface class would include bidirectional communication between a center-type system (e.g., transit dispatch center) and a field-type system (e.g., dynamic message signs at a transit stop).
Table 2. ITS Standards Application Areas
3.2. Transit Management Application Area
The Transit Management Application Area (center-to-center [C2C] application area) covers the interface between a transit management center and other centers and supports the following capabilities:
The extent to which information and coordination are shared between centers is determined through working arrangements among agencies or jurisdictions.
Figure 3 shows the scope of the Center-to-Center Transit Management application area. This scope is described in the preceding text.
(Extended Text Description: C2C Transit Management Application Area: This is an image that shows the entities that incorporate the C2C Transit Management Application Area. There are five boxes in this diagram – one in the center, and four positioned around the box in the center, connected to the center box by lines. The box in the center is labeled "Transit Management Center" and contains a graphic that shows a dispatcher in front of two computer screens in the box to the left and the front of a bus in the box to the right. The box in the upper right side, which is connected to the "Transit Management Center" box by a line is labeled "Traffic Management Center" and contains a graphic that shows a TMC operator in front of a computer screen in the box to the left and a two-lane road with one car in each lane in the box to the right. The box in the lower right side, which is connected to the "Transit Management Center" box by a line is labeled "Other Transit Management Centers" and contains a graphic that shows a dispatcher in front of two computer screens in the box to the left and the front of a bus in the box to the right. The box in the upper left side, which is connected to the "Transit Management Center" box by a line is labeled "Air, Rail and Ferry Transportation Providers" and contains a graphic that shows a dispatcher in front of two computer screens in the box to the left, and an airplane and train in the box to the right. The box in the lower left side, which is connected to the "Transit Management Center" box by a line is labeled "Traveler Information Provider" and contains a graphic that shows a person using a computer in the box to the left, and an "i" in a circle in the box to the right.)
Figure 3. C2C Transit Management Application Area
This application area focuses on the C2C interfaces with the Transit Management Subsystem (TRMS). The TRMS accepts requests for personalized transit routing, as well as general transit system information requests from the Information Service Provider. The TRMS interfaces to financial institutions to support electronic fare payment. It also coordinates with Other Transit Management systems, as well as Multimodal Transportation Service Providers (i.e., providers of other modes of transportation such as ferry or rail), for the exchange of information to allow schedule and routing coordination between systems. The TRMS disseminates transit incident information, schedules, and fare and price information to Information Service Providers and the Traffic Management Subsystems. The TRMS also distributes transit status and incident reports (appropriately tailored for external distribution) to the media. During emergency situations, the TRMS provides emergency transit schedule information to the Emergency Management (EM) and Traffic Management (TM) subsystems. Finally, the TRMS coordinates the Enforcement Agencies regarding the notification of violations. Note that managing and tracking of transit vehicles is not covered in this set of interfaces, but is included in the center-to-vehicle application areas. In addition, the management of transit incidents is covered in the incident management application area.
In general, the standards shown in Table 3 are applicable to Transit Management deployments. To determine which specific standards are applicable for a deployment you will need to determine which architecture flows will be needed for the Transit Management piece of your deployment.
Table 3. Standards Applicable to Transit Management
In general, the standards shown in Table 3 are applicable to Transit Management deployments. To determine which specific standards are applicable for a deployment, you will need to determine which architecture flows will be needed for the Transit Management piece of your deployment.
3.3. Open System Interconnection
In terms of standards structures, Open System Interconnection (OSI) is 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, proceeding to the bottom layer, over the channel to the next station, and back up the hierarchy.
The seven layers are defined as follows:
3.4. Society of Automotive Engineers (SAE) J1708
J1708 is a Society of Automotive Engineers (SAE) specification developed especially for heavy duty vehicles including transit vehicles. It was considered the first standard for an on-board vehicle area network (VAN), which is analogous to a local area network (LAN) in an office environment. The standard is for serial communication between modules or components with microcontrollers. The standard means that data can be transferred between on-board devices in a more cost-effective way. Further advantages have been as follows:
Since J1708 only describes the lower layers of the OSI model, it is always used with an overlaying application layer. An example of such a layer is J1587, which is used for data exchange between microcontrollers in heavy duty vehicles. Other key facts about J1708 are as follows:
The J1587 protocol defines the format of J1708 messages sent between microprocessor devices in heavy duty vehicles. It also supports communication with external devices connected to the bus. J1587 is an application layer and is used together with J1708, which is the physical layer.
J1587 describes a message format and defines parameters. A J1587 message consists of MID (Message Identification), parameter identification (PID), data bytes, and a checksum. (A checksum is 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.) The length of a J1587 message is limited to 21 bytes according to J1708. J1587 allows for sending messages longer than 21 bytes using a connection oriented transport service (COTS). The transmission rate is 9600 bps. A message contains of a one byte long MID, followed by a number of data bytes, and finally a checksum. A message can be up to 21 bytes long.
3.5. Society of Automotive Engineers (SAE) J1939
The SAE J1939 communications network is a high-speed ISO 11898-1 controller area network (CAN)2-based communications network that supports real-time closed loop control functions, simple information exchanges, and diagnostic data exchanges between on-board components, physically distributed throughout the vehicle. The SAE J1939 common communication architecture strives to offer an open interconnect system that allows components associated with different manufacturers to communicate with each other.
The J1939 network was the next generation successor to the SAE J1708 and SAE J1587 low-speed networks. Those earlier standards provided simple information exchange, including diagnostic data, between on-board components. J1939 was capable of performing all of the functions of those earlier networks. It enhanced previous capabilities and added new ones to better support controls and multiplexing on a single network.
Technology had advanced to the point where a high-speed communication network was feasible. It was needed to secure higher bandwidth capabilities for more demanding control needs, so that component suppliers could integrate subsystems for improved performance, and to meet customer expectations and government regulations.
J1939 uses the CAN protocol, which permits any Electronic Control Unit (ECU) to transmit a message on the network when the bus is idle. Every message uses an identifier that defines:
SAE J1939 is divided into several layers according to the OSI layer model, where each level is specified in a separate document. In a fashion similar to practically all fieldbus protocols, since layers 5 and 6 are not needed in SAE J1939, they are also not specified.
The functionality of SAE J1939 is divided into layers as follows:
Since the network management can be regarded as a separate unit that reaches through to the hardware (layer 1), this block in the layer model is shown as an independent function block on the right-hand side. The network management basically consists of the automatic allocation or determination of node addresses (plug & play principle). Node monitoring is not defined in SAE J1939 and must be implemented via cyclic messages at the application level.
The technical details of SAE J1939 are explained in an easy-to-understand overview in http://www.simmasoftware.com/j1939-presentation.pdf.
2 CAN is a form of serial communications that was developed in 1985 for in-vehicle networks.
3.6. General Transit Feed Specification (GTFS)
The General Transit Feed Specification (GTFS), originally developed by Google, defines a common format for public transportation schedules and associated geographic information. GTFS "feeds" allow public transit agencies to publish their transit data and developers to write applications that consume that data in an interoperable way.
GTFS contains static schedule information for transit agencies including: stop locations, route geometries, and stop times. GTFS consists of a package of comma-delimited text files, each of which contains one aspect of the transit information and a set of rules on how to record it: six mandatory files (agency, stops, routes, trips, stops times, and calendar) and seven optional files (calendar dates, fare attributes, fare rules, shapes, frequencies, transfers, and feed info). The market success of GTFS has led to an unprecedented adoption rate by transit agencies as shown by total unlinked passenger trips for agencies with GTFS. For schedule data, GTFS adoption has substantially outpaced the TCIP and [Service Interface for Real Time Information] SIRI standards in North America due to its relative ease of use for transit agencies to describe, implement, and maintain data feeds.
GTFS is considered a de facto data standard that facilitates the process for agencies to integrate schedules and routes into Google Maps (now Google Transit), and for broader public disclosure of those same datasets.
The following (from https://developers.google.com/transit/gtfs/examples/gtfs-feed) is an example of a GTFS feed. This GTFS feed shows comma-delimited data samples for each file in a transit feed. The sample data files shown here are not all related to each other. You can also download a complete GTFS feed in final form to work with as well.
This example shows service exceptions for the Independence Day holiday in 2006. On Monday, July 3, 2006, regular weekday service (service_id=WD) is interrupted (exception_type=2). Instead, weekend service (service_id=WE) runs on that date (exception_type=1). The same change applies on Tuesday, July 4, as well.
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License, and code samples are licensed under the Apache 2.0 License. For details, see our Site Policies. Last updated January 15, 2013.
GTFS-realtime is a feed specification that allows public transportation agencies to provide real-time updates about their fleet to application developers. It is an extension to GTFS, which was discussed in the prior subsection. GTFS-realtime was designed around ease of implementation, good GTFS interoperability, and a focus on passenger information. It will be discussed more in Modules 6 and 7.
The specification was designed through a partnership among the initial Live Transit Updates partner agencies, a number of transit developers, and Google. The specification was introduced and released under the Creative Commons Attribution 3.0 license in August 2011.
The specification currently supports the following types of information:
Updates of each type are provided in a separate feed. Feeds are served via HTTP and updated frequently. There are no constraints on how frequently nor on the exact method of how the feed should be updated or retrieved. Because GTFS-realtime allows you to present the actual status of your fleet, the feed needs to be updated regularly - preferably whenever new data comes in from your Automatic Vehicle Location system.
The GTFS-realtime data exchange format is based on Protocol Buffers, which is a language- and platform-neutral mechanism for serializing structured data (think XML, but smaller, faster, and simpler). The data structure is defined in a gtfs-realtime.proto file, which then is used to generate source code to easily read and write your structured data from and to a variety of data streams, using a variety of languages (e.g. Java, C++ or Python).
3.8. Other Formats and Standards
There are several other formats that have become de facto standards and are used to exchange data in C2C, C2V and C2I application areas. These include, among others, JSON, Protocol Buffers, REST, SOAP, and XML.
"Protocol buffers are Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data - think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages."3 The GTFS-realtime data exchange format is based on Protocol Buffers.
REST is an architecture style for designing networked applications. The idea is that rather than using complex mechanisms to connect between machines, simple HTTP is used to make calls between machines. RESTful applications use HTTP requests to post data (create and/or update), read data (e.g., make queries), and delete data. One of the case studies we use in this module discusses the use of REST.
The Simple Object Access Protocol (SOAP) facilitates interoperability among a wide range of programs and platforms, making existing applications accessible to a broader range of users. SOAP combines the proven web technology of HTTP with the flexibility and extensibility of XML. SOAP defines a way to move XML messages from point A to point B. It does this by providing an XML-based messaging framework that is 1) extensible, 2) usable over a variety of underlying networking protocols, and 3) independent of programming models.
Extensible Markup Language (XML) is a simple, very flexible text format. Originally designed to meet the challenges of large-scale electronic publishing, XML is playing an increasingly important role in the exchange of a wide variety of data on the Web and elsewhere. It is used for defining data elements on a Web page and business-to-business documents. XML uses a similar tag structure as HTML; however, whereas HTML defines how elements are displayed, XML defines what those elements contain. While HTML uses predefined tags, XML allows tags to be defined by the developer of the page. Thus, virtually any data items can be identified, allowing web pages to function like database records. By providing a common method for identifying data, XML supports business-to-business transactions and has become "the" format for electronic data interchange and web services.
4. Case Studies
4.1. C2I Flows: Interurban Transit Partnership (ITP), Grand Rapids, MI
The Interurban Transit Partnership (ITP) deployed real-time information in 2013, using information generated by their CAD/AVL system. In this case, it was required that information be sent from their dispatch center to field infrastructure (dynamic message signs) located at their major transfer facility (called Central Station) and one other transfer location (Kentwood Station). This is a center-to-infrastructure case.
On the first deployment of wayside signs in Grand Rapids, the vendor developed their solution around the use of GTFS data. Each sign was equipped with an on-board PC that processed real-time and static GTFS, and parsed the applicable data relevant to a given sign location. This involved parsing up to 13 separate files that GTFS specifies. Because processors had to preload the GTFS files, it took a lot of central processing unit (CPU) power from the sign and was a slow process. It also meant that GTFS static files had to be up-to-date to display anything on the sign. Because of these limitations with GTFS, the vendor decided to take a step back and look at what data were really needed to be presented on a sign. The vendor then realized that a lot of unnecessary data were being sent down to the sign. From a product standpoint, the vendor also knew that they wanted to use cellular data connections in the future, and wanted to limit the amount of data being sent back and forth between the sign.
Ultimately, the vendor decided to use REST (Representational State Transfer). This provides the most flexibility moving forward and can be consumed by a wide variety of web clients. They are easily able to return JSON, XML, HTTP and other web standard formats. For ITP, using REST provided the ability to return both JSON and XML. Another benefit of REST is that it provides simple ways to filter data. For example, you can request all departures, departures for a specific sign by ID, departures for a specific sign by media access control (MAC) address, or departures for a single stop based on IDs. These are all built from the same data source, so there is consistency across different requests. You can easily add filtering to cut down on the volume of data or rest all the data based on how the application wants to use the information.
With minimal engineering effort, the vendor developed signage REST endpoints (modeled after existing ones for ITP's interactive voice response [IVR], website, and iPhone apps). The sign hits these endpoints, which feeds back JSON data.
Besides providing filtering, using REST can provide you with the specific data you want. You might want to do this to limit data transfers or only provide specific data to certain clients. The amount of effort to do this is minimal, which was another reason for the vendor to choose the REST architecture. For example, for a client that did not need arrival information, the vendor could easily use REST to leave the information out.
From a diagnostics perspective, the sign does an HTTP Post containing all the diagnostics from the sign. This includes number of LEDs out, current temperature, firmware version, errors, and light sensors. This is consumed by the website, which can process the data and alert the user whenever certain conditions are met. This means that the user will know when the sign stops functioning or if LEDs have failed. This is a proactive approach so the sign is not sitting inoperable for days until it gets reported (usually by a customer).
4.2. 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:
4.3. Tri-Met Case Study
One of the largest and most common hurdles when developing ITS is to make them compatible with existing systems already deployed. There are several important factors that must be considered when integrating new systems with existing ones, and that can have significant impacts on the ITS costs and deployment schedules. These issues include integrating with existing legacy systems to save costs associated with implementing a new system, as well as complying with standards whenever possible.
Experiences from the Tri-County Metropolitan Transportation District of Oregon (TriMet) show that following ITS standards and protocols helped ensure that ITS components being integrated can function together. Additionally, following ITS standards and protocols helps provide vendor and system flexibility. In the case of the TriMet, at the time of its procurement of light-emitting diode (LED) signs, no Transmission Control Protocol/Internet Protocol (TCP/IP) standards for the LED sign interface had been developed. Consequently, the agency was forced to consider sign vendors that had proprietary protocols. Even though no standards were available, TriMet knew it wanted the LED signs to interface with TCP/IP-compliant devices, so TriMet provided specifications that required the sign vendors to interface with the protocols. TriMet staff believed that there was an advantage to using TCP/IP and standard protocols that would enable the agency to use different communication methods, yet retain the same applications. Complying with ITS standards and protocols helps to ensure a modular and compatible infrastructure
Further, integrating with existing legacy systems can save money associated with implementing a new system. During procurement of a real-time bus arrival estimation system, TriMet encountered several technical issues that were addressed successfully during project deployment. The Transit Tracker system was built upon the same platform as TriMet's existing automated vehicle location bus dispatch and rail central control systems, saving software development time and system costs. A few minor changes needed to be addressed because of the different requirements necessary for reporting information to customers as opposed to reporting information to the dispatchers. For example, for the real-time Transit Tracker system, TriMet had to change the rate at which information was provided and expand the type of information provided by the system to respond to the needs of the customer.
4.4. Central Puget Sound Case Study
One successful strategy for procuring ITS technologies is to select commercial off-the-shelf technology (hardware and software) that is already proven. The experience of seven public transportation agencies in the Central Puget Sound region demonstrates that complying with standards and using commercial off-the-shelf technology can help save money, minimize risks, and make it easier to integrate existing systems with new ones, and modifying or customizing a particular technology entails greater risks. A modified or customized system has the advantage of closely meeting the specified needs of the regional partnership, along with the disadvantage of needing more development and testing to be sure it does what it is supposed to do. (In the case of the Puget Sound system, only the on-board driver display unit was significantly customized to accommodate emerging smart bus initiatives.) Customized software may need to be developed in order to accommodate the partners' existing legacy systems.
7. Study Questions
1. How many Public Transportation Service Packages are there in the National ITS Architecture?
2. Which of these is not a Public Transportation Service Package?
3. Which one of these is not a layer within the Open System Interconnection (OSI) model?
4. Which of these standards are on-board vehicle area network (VAN) standards?
5. Which of these issues typically drive the costs associated with using standards?
6. What de facto standard did ITP's vendor use to successfully exchange data between the dispatch center and dynamic message signs in the field?
7. Does complying with standards and using commercial off-the-shelf technology help make it easier to integrate existing systems with new ones?
8. A good approach to defining the functions of your system is to select items from manufacturers' datasheets.
9. Which of the following elements are included in a conformance testing program?