Mobility Services for All Americans Phase 2: Foundation Research
Subhead1

Generic Traveler Management Coordination Center Concept of Operations

The Systems engineering V. [D]

Prepared for:
US DOT

Prepared by:
SAIC

January 12, 2006


Background

The Mobility Services for All Americans initiative is one of the U.S. Department of Transportation's Intelligent Transportation Systems (ITS) Program's Tier I initiatives. The goal of the MSAA initiative is to provide enhanced mobility and accessibility to all Americans through the use of technology integration, service coordination, and the efficient use of resources.

The foundation of the Mobility Services for All Americans (MSAA) initiative is built around the notions of service coordination and technology integration. Currently, delivery of human services transportation is challenging due to a plethora of issues such as inefficiencies, limited resources, and lack of coordination. In many locations, human services transportation is fragmented, resulting in service area gaps (geographical areas where service is not provided) or limited service area size due to an absence of trip transfers between transportation providers. Often, customers must:

  • Contact multiple case workers among multiple funding programs.
  • Make trip requests well in advance.
  • Contend with inconvenient scheduled trip times.
  • Deal with long and difficult to estimate pick-up wait times.
  • Endure long trip travel times.
  • Contend with limited accessibility to transit, especially if the traveler is a senior or a person with disabilities.
  • Overcome difficulties in locating information on the availability of transit alternatives.

New capabilities and opportunities are being created in both the transportation and health and human services communities through the use of emerging technologies and innovative services. Pioneering public transportation agencies are using Intelligent Transportation Systems (ITS) to provide centralized coordination of community transportation providers, one-stop shopping, and service brokering through integrated automatic vehicle location systems, advanced communications, and universal benefit cards. Others are providing on-vehicle audio annunciation, accessible traveler information, and flexible routing to assist passengers with disabilities in using conventional transit services. In the rehabilitation community, innovative Assistive Technologies (AT) such as personal GPS and personal digital assistants (PDA) using mobile communications provide real-time assistance to those with cognitive disabilities, while accessible pedestrian signals and "talking" bus stops and signs are also being developed. However, the two communities are often unaware of the research, new approaches, and advances that each is making, and neither may have direct communication with the disability community at large.

The U.S. Department of Transportation (USDOT) is helping to bring these communities together through MSAA in an effort create a coordinated approach to the application of technological solutions to the barriers to accessibility and mobility for all Americans. Ultimately, MSAA seeks to:

Establish replicable and scalable models of traveler management coordination centers [TMCC], that provides one-stop, unified customer-based travel information and trip planning services, and supports coordinated human services transportation operations.1

It is hoped that the combination of many available technologies brought together in a TMCC can help overcome the barriers and gaps facing all travelers. The purpose of this generic concept of operations is to help local stakeholders to successfully plan and design this type of TMCC. Technical and planning challenges, if not overcome prior to and during implementation, can affect how useful the technology will be. This document is also meant to create a preliminary picture of the ideal TMCC that could best meet the transportation needs of all Americans. The concept of operations document has been kept generic - that is, a notional deployment scenario has been described throughout the document. In the foundational research undertaken to support the MSAA effort, many stakeholders cautioned that one model may not work well in all applications. Therefore, this document should support the implementation of different configurations of a TMCC.

Definition of A Generic TMCC Concept of Operations

This generic concept of operations for a TMCC is a document that provides a user-oriented vision of the system that can be understood by stakeholders with a broad range of operational and technical experience. This concept provides a method of identifying institutional, operational, and technical aspects of traveler management coordination. The purpose of this document is to provide both guidance in completing a detailed, specific concept of operations for a TMCC and examples to help writers 2 understand the type of material that should be included. A "generic system" has been described throughout the concept. This is meant to illustrate how a stakeholder would develop a concept of operations and, ultimately, the deployment of a TMCC.

This document communicates the overall needs that the TMCC should satisfy and provides the basis for development of an individual, site-specific TMCC concept of operations. An individual concept of operations for a TMCC:

  • Ensures that all users and supporters have the same understanding of the TMCC. By providing a description of the components and operations, stakeholder misunderstandings can be reduced and expectations can be managed.
  • Clearly defines conditions for the use of the TMCC. This should minimize the risks associated with operating a TMCC. A concept of operations should include non-technical descriptions of all TMCC users, the data and information that they need to operate and use the TMCC, and the conditions under which they use this data and information.
  • Documents the operational needs of the users without defining specific technical issues.
  • Provides the operational needs and proposed characteristics for the proposed TMCC.
  • Describes high-level user expectations and functional requirements for the TMCC.
  • Describes information sharing across programs and operators.

Figure 1 provides a graphical depiction of the high-level elements of a generic concept of operations.

High-level elements of a concept of operations.[D]
Figure 1. Textual Representation of the Major Elements of a Typical Concept of Operations3

Using The Generic Concept Of Operations

The final TMCC concept of operations document will be a guideline for the implementation of the TMCC. It will identify connections and attributes of the proposed TMCC, and the interfacing entities and systems. The generic concept of operations presents illustrative examples of operational scenarios for various applications of the TMCC. Each scenario describes, in narrative text, illustrated cases. Sequence diagrams may eventually support the description of each scenario. Stakeholders may use these examples as they consider what scenarios they would like to include in their final TMCC concept of operations.

The TMCC generic concept of operations should include all stakeholders, existing ITS, proposed ITS, and transportation modes that will be affected by the operation of the new TMCC. The generic concept of operations is designed to be used by the primary stakeholders who will use the description of a generic TMCC as a model to complete a more specific concept of operations document. The stakeholders' specific concept of operations document should detail the specific conditions, modes, and needs that will be incorporated into the deployed TMCC.

Again, the remainder of the document will use examples from a "generic system" to illustrate particular points in the MSAA concept of operations. The generic system is described below in detail.

Generic System Description

The goal of the generic system, as with the MSAA initiative, is to develop a replicable, scalable TMCC which will enhance service accessibility and operational efficiency and provide a single point of access to customer-based travel information and trip planning services for all Americans, especially persons with disabilities, older adults, and individuals with lower income.

The generic system is intended to be a representative example of a real-world TMCC and may not include every possible component/subcomponent of a TMCC as outlined in SAIC's Mobility Services for All Americans Phase 2 Foundation Research Final Report.4 Furthermore, not every component or subcomponent is required (nor perhaps even desirable) for a successful TMCC. The decision as to which components to include will depend upon the needs, resources, and goals of the communities or agencies actually undertaking such implementations. While the generic system could be either a physical or virtual system (and will include actual tangible resources, such as computers and dedicated staff) for purposes of the generic system that is described the remainder of this document, the TMCC is a virtual system with dedicated staff members.

The generic system includes some type of communication network among all relevant funding agencies, contract and/or agency operators, service providers, and the general public. This communications network is the primary means by which the users (riders) schedule a trip. While this network should be technology-based and use telephone and Internet resources to support it, it should also utilize person-to-person interfaces as additional or back-up means of communication for the users/riders. This will help troubleshoot any problems encountered as users try to schedules rides and trips. It is important to note that this communications network may use different forms between stakeholders; for example, communication between a funding agency and an operator might take on one form, but the communication between a customer (e.g., user or rider) and a provider may take on another form.

The generic system benefits from a local champion who ensures the successful implementation and operation of the TMCC. The system also utilizes stakeholder involvement throughout its life-cycle: all stakeholders have been involved in the planning design, procurement, deployment, and evaluation of the generic system. The generic system's stakeholders include:

  • USDOT.
  • State DOT.
  • Other State agencies administering and/or funding human service transportation programs.
  • Local transit agencies.
  • Contract operators that provide service for the transit or human service agency.
  • Privately-provided human service transportation services.
  • Users/customers.
  • Private sector representatives, such as ITS vendor(s).

Memoranda of understanding (MOU), agreements, and shared policies with agencies delineate service, administration, funding, and management roles and responsibilities among providers and other stakeholders. These agreements address the following topics:

  • Cost sharing.
  • Shared eligibility processes between programs.
  • Shared service (e.g., vehicles, reservations, etc.).
  • Shared billing/reporting.
  • Shared or linked technology (e.g., database, scheduling, dispatching, reporting, billing).
  • Shared information across programs and operators.

The generic system's operations include fixed route transit, demand response services, flexible services (e.g., point-deviation, route-deviation, service routes, or community bus routes,5 and volunteer driver programs). It uses a single point of access that provides customer-based travel information, trip planning services, and access to travel training services. The generic system includes multiple funding agencies, service providers, and operators, including: local and State transit agencies, health and human service agencies, department of labor agencies, department of education, family service agencies, and non-profit and for-profit transportation agencies. The generic system includes five providers/operators and five different funding agencies, and is scalable. The generic system benefits from a thorough, efficient, and innovative design processes:

  • The overall process follows a systems engineering analysis approach.
  • The design also considers human factors during the planning, design, implementation and full deployment of the system.
  • The generic system keeps successful elements of previous service offerings. For example, the system accounts for the benefits resulting from integration with personalization offered by smaller, sometimes stove-piped, services.
  • The system's design incorporates a well-established Coordination Transportation Plan (e.g., State Action Plan), a product of the United We Ride campaign. Likewise, it also operates in accordance with the Regional ITS architecture.

The generic system embarks on both a major promotional campaign highlighting the potential benefits of the TMCC to stakeholders and users as well as an ongoing public- relations campaign to promote services to travelers. The system offers trip (itinerary) planning for customers via the Internet or telephone, enhancing customer service by providing the customer with the most cost-effective trip plan while minimizing travel time. The system offers its travelers the following benefits and features:

  • Monthly transit passes.
  • Shared rides between passengers from different programs.
  • Lower fares for riders who pre-group themselves.
  • Fare reduction for off-peak travel.
  • Seamless use of multiple modes (e.g., volunteer, demand response, feeder service, fixed-route transit, etc).
  • Discounts for certain modes/cost sharing for certain modes/times.
  • Accessible vehicles.
  • Easy to understand signage, maps, schedules, etc.
  • Information available in multiple languages, formats and via multiple media.
  • Single point of access to call center for reservations and scheduling (regardless of destination, mode of travel, or provider or payer).
  • Customer service center (via phone, email, Internet or in person) to log concerns, ask questions, buy passes, obtain schedules, make recommendations, etc.

To summarize, the generic system has the following programs in place:

  • Coordinated eligibility processes.
  • Single PAYER System from service providers and riders' perspective.
  • Integrated operational information system potential measures.
  • A central call center "single point of access."
  • Education and training (staff, operators, and customers)
  • Local/regional contribution/ investment; this investment could be financial or operational.
  • Joint purchase, use and maintenance of vehicles, including fuel, insurance, etc.
  • Intermodal transfer centers.

Generic System Core Elements

The generic system's core functional elements are presented in the logical order in which they would be deployed, as follows:

  • System backbone, which consists of:
    • A database which acts as a repository to support business processes. Includes information on funding, eligibility requirements, fare structures, customer information, etc.
    • A data dictionary, which allows data/information exchange among systems and sub-systems, and ultimately between and among funding agencies' and transit provider(s') systems.
  • Elements which support travel planning, including:
    • A booking system (e.g., reservations) that allows access through a variety of means, including 211/511, web, etc. However, must contain at least some options for human interface
    • A scheduling and dispatching system that optimizes resource utilization and minimizes customer wait and travel time.
    • A fare payment and management system, including:
      • An eligibility subsystem that automatically determines eligibility requirements and supports or denies service requests.
      • A fare collection and payment subsystem that automatically deducts the fare based on passenger eligibility for program subsidies.
  • Elements which improve operations and customer service, including:
    • A tracking/communication system, including:
      • A transfer connection protection (TCP) subsystem that minimizes traveler disruption at transfer points and facilities.
      • A vehicle (asset) visibility subsystem that supports both scheduling activities, and the provision of real-time arrival and progress information to travelers.
      • A safety and security subsystem that provides facility, vehicle and passenger security and safety via systems such as on-board cameras and recording, collision detection, silent alarms (panic buttons), facility cameras and recording, and automated activation of information and lights.
  • Elements which support simplified financial transactions, accounting and program management, including reporting, reimbursing, smart card fare collection, payment, recharging, etc. These elements should be transparent to the users.
  • A traveler information system that provides information to riders before they make their trip, once trips are scheduled and en route (as trips are being taken).
  • System activities which occur after service is provided, such as:
    • An invoicing subsystem, which automatically allocates costs across programs based on agreed-to formulae and/or actual trip elements, develops invoicing reports, and minimizes preparation time and errors.

Additionally, the generic system uses key human and technical resources, such as manned help desks (to help riders find and access service) and smart card technology (to facilitate payment).

Major stakeholders of the generic system include:

  • Customer: Rather than interfacing with individual agencies, the customer now interfaces with a central entity. This is similar to what is being proposed in the Oregon State-Wide Trip Planner discussed in Chapter 3 of the Mobility Services for All Americans Phase 2 Foundation Research Final Report. Interaction can occur through standard phone, 511, or 211 to human or IVR, Internet, web-enabled (Wireless Access Protocol) cell phone, PDA, etc. Previous ITS evaluations have shown that, in addition to any automated system, users should be provided the option of reaching a human attendant. Subsequent to booking and scheduling a trip, the customer can utilize the TMCC to make changes to their planned itinerary and/or to receive real-time arrival information.
  • Transportation Providers: Under this model, transportation providers are able to focus solely on operations. Interaction with other providers, funding agencies, and customer bookings occur through the TMCC. Passenger pick-ups, routing decisions, and scheduling are processed by the TMCC and provided to the transportation providers in real-time. Providers continue to monitor their vehicles (where capable) and seamlessly provide this information back to the TMCC. Eligibility decisions are made by the TMCC and invoices are automatically produced.
  • Funding Agencies: Funding agencies interact solely with the TMCC. Agencies provide standards for invoicing, which are updated as necessary. Centralized invoices are produced by the TMCC and submitted to the appropriate funding agencies.

Generic System Schematic

Figures 2 and 3 summarize the generic TMCC. Figure 2 depicts the design and deployment elements as well as the TMCC operational environment. Figure 3 provides a high-level view of the system, stakeholders, and stakeholders' roles.

Flow chart showing Design Elements, Deployment Elements, and Operating Environment characteristics.
Figure 2. Generic System Background Elements



System Diagram of the Virtual TMCC
Figure 3. Generic System Diagram

Concept of Operations

The following sections detail the areas which should be covered by the specific concept of operations. To provide sufficient detail to the authors of future concept of operations documents, some sections provide examples as they would be found within the "generic system."

I. Scope

This section includes, in addition to the points listed below, diagrams to describe relationships and processes. Figures 2 and 3 from the earlier description of the Generic TMCC provide high-level examples of system schematics. The scope contains sufficient information to serve as the Executive Summary of the document.

a. Document contents.

b. Who is the audience of the concept of operations? These are the agencies that will deploy, operate, and use the TMCC. For example, they are usually part of the following organizations:

  • USDOT.
  • State DOT.
  • Other State agencies administering human service transportation programs.
  • Local transit agencies who are participating in the TMCC deployment.
  • Privately-provided human service transportation services which are involved in or affected by the model deployment.
  • Site-specific deployment expertise (e.g., consultants who will assist in the development of a specific concept of operations document).
  • Technology vendors.

c. Identify stakeholders. Stakeholders are identified according to the needs and requirements of each deployment site. In many cases, they are the same entities who will be using (i.e., creating or referencing) the concept of operations. In addition to the concept of operations audience, all users of the transportation system should be considered deployment stakeholders. For the purpose of this generic concept of operations, four stakeholder groups have been identified:

  • Primary stakeholders:
    • State agencies administering and/or funding human service transportation programs.
    • Local transit agencies.
    • Contract operators that provide service for the transit or human service agency.
    • Privately-provided human service transportation services.
  • Secondary stakeholders:
    • USDOT.
    • State DOT.
  • Other interest groups:
    • Site-specific deployment expertise (e.g., consulting firms).
    • Technology vendors.
  • Users/customers - riders, single point of access call centers.

d. Define system boundaries - identify the:

  • Entities included in the system. These entities:
    • Are within the primary organization that is developing or will operate the TMCC. For example, it would include state DOTs, human service agencies, and local level transit agencies - whether public or community/non-profit. In the Generic System, these entities are local and state transit agencies, health and human service agencies, department of labor agencies, department of education, family service agencies, and non-profit and for-profit transportation agencies.
    • Play a significant role in system design, deployment and/or operation. For example, USDOT, technology vendors, and other private companies who may be involved, such as systems integrators, consultants or evaluators. In the design of the generic system, technology vendors and consultants were retained to assist in the planning, design and deployment of the system.
    • Are significantly affected by changes in system design and function. For example, funding agencies, other local providers (private and/or public/community transit agencies) who are not deploying the TMCC, but will be impacted by its operation. The generic system includes five providers/ operators and five different funding agencies, and is expandable.
  • Entities that will be an external interface to the system. These entities:
    • Interact with the system but are outside the scope of its operation, such as MPOs and other local entities. During the planning process of the generic system, the stakeholders conducted a series of meetings with the local MPO and other interest groups who would be utilizing the systems functionality to assess their needs and requirements.
    • Play a secondary role in system function or are only affected by system function.
    • This section should also define where the TMCC's coverage will end. For example, will the system operate across multiple jurisdictions? If so, these additional jurisdictions should be defined and discussed briefly in this section.

e. Purpose for implementing the system:

  • Define current needs. From the MSAA Foundation Research, the system should respond to the following needs:
    • Need for service and for that service to be reliable (on-time arrivals and departures).
    • Need to know about that service and how to plan a trip.
    • Need for accessibility. For example, the vehicles or vehicle stop locations are easy for all individuals to physically access.
    • Need for flexibility. For example, a customer can easily make changes to their trip (e.g., route and point deviation).
    • Security. Security is important to all Americans; nearly all travelers are seeking safe and secure travel options. At times, it may be the most important factor in someone's trip.
  • Identify current shortcomings. This section generally describes the current state of the practice in high-level, generic terms. From the MSAA Foundation Research, the system must attempt to mitigate the following gaps and barriers:
    • Areas of no service.
    • Areas of limited service or service times.
    • Absent and/or limited service information.
    • Absent service assistance (to answer questions and help users understand how to use the system).
    • Limited trip flexibility; for example, the trip must be booked many hours or even days in advance.
    • Limited service accessibility.
    • Variable service reliability.
    • Difficulties in taking chained or multi-destination trips.
    • Inefficiencies in vehicle routing, scheduling, and tracking.
    • Lack of standardized reporting requirements among funding agencies.
    • Lack of automation in recordkeeping.
    • Institutional issues: these could vary to include items such as:
      • Financing for technology procurement, implementation, and on-going operations and maintenance.
      • Coordinating with other providers and agencies in order to jointly procure systems and/or exchange data and information.
      • Lacking ITS technical experience - this can relate to either human or computer resources.
      • Procuring technology from vendors who are unfamiliar or inexperienced with human service agency operations and transportation services.
  • Technical concerns, such as:
    • The automation of functions. In some cases, automation alienates customers, thus the benefit of technology is not realized.
    • A lack of technical guidance and information.
    • A lack of ITS infrastructure, especially in rural areas.

During the generic system planning stage, stakeholders conducted a formal needs analysis, in which they identified the needs and shortcomings of their current system. The stakeholders also identified technology concerns such as the automation of functions, the lack of technical guidance and information, and the lack of ITS infrastructure. This step is critical, as it documents important aspects that the potential TMCC must address. The concept of operations may generally be high-level, and serve as a starting point for the discussion that takes place at the needs analysis meetings.

f. Define the overarching vision of the system. With respect to the generic system, the replicable and scalable TMCC will enhance service accessibility and operational efficiency and provide a single point of access to customer-based travel information and trip planning services for all Americans especially persons with disabilities, older adults and individuals with lower income. These goals tie in with the USDOT's Intelligent Transportation Systems (ITS) Joint Program Office (JPO) and FTA MSAA goals.

g. Define major goals and objectives of the system. This section describes the goal of each TMCC sub-system. Then a short description of how replicability and scalability can be achieved in each subsystem or environment is included. A logical means of presenting the sub-systems is in the order in which they would need to be deployed. For example:

  • First-level systems. These must exist before any other systems are implemented. These would likely include:
    • Data dictionary.
    • Database.
  • Second-level systems. These include elements that are required to plan travel; i.e., make reservations, schedule vehicles and drivers, and dispatch vehicles. They include:
    • Booking.
    • Scheduling and dispatching.
    • Fare payment and management:
      • Eligibility.
      • Fare collection and payment.
  • Third-level systems: these are systems that involve providing service to the customers, including:
    • Tracking:
      • Transfer connection protection.
      • Asset visibility.
      • Security and safety.
  • Fourth-level systems, which provide information to travelers once the trips are scheduled and service is being provided. For example, traveler information.
  • Fifth-level systems - these are provided after service is used. For example, invoicing.
  • Potential environments: could include any combination of elements. Some examples include:
    • Areas:
      • Rural / "remote frontier."
      • Urban.
      • Small urban.
      • Suburban.
    • Operation:
      • Fixed route.
      • Demand response.
      • Flexible (e.g., route- or point-deviation).

Table 1 summarizes the subsystems that are contained within the generic system.

Table 1. Generic System Components
empty cell Yes No
First Level System
Data Dictionary
X
empty cell
Database
X
empty cell
Second Level System
Booking
X
empty cell
Scheduling and Dispatching
X
empty cell
Fare Payment and Management
X
empty cell
Eligibility
X
empty cell
Fare Collection and Payment
X
empty cell
Third Level Systems
Tracking
X
empty cell
Transfer Connection Protection
X
empty cell
Asset Visibility
X
empty cell
Fourth Level Systems
X
empty cell
Fifth Level Systems
Invoicing
X
empty cell
Potential Environments
Operations
Fixed Route Transit
X
empty cell
Demand Response Services
X
empty cell
Flexible Services
X
empty cell
Volunteer Drivers Programs
X
empty cell


II. References

The documents listed in this section should help the authors of the detailed TMCC concept of operations add the necessary level of information to their document. These sections provide guidance as the complete Concept is developed. These sources may also act as references as the TMCC system development is refined.

a. Generic examples:

  • Transportation planning documents such as transportation improvement plans, statewide transportation improvement plans, and corridor plans.
  • Human resources.
  • Other concepts of operations (ICMS, iFlorida).
  • System requirements document (for similar systems).
  • Meeting minutes.
  • Strategic plans, such as ITS strategic plans.
  • Regional and statewide ITS architectures.

b. MSAA and TMCC specific references:

  • "Developing and Using a Concept of Operations in Transportation Management Systems," an FHWA Pooled Fund Study, December 2004.
  • "Developing Functional Requirements for ITS Projects," Mitretek Systems, April 2002
  • Information from the existing 11 ITS deployments, other integration or coordination efforts.
    • Documentation from European deployments (e.g., SAMPO and SAMPLUS, FAMS and ASK-IT, which are projects that have Travel Dispatch Centers that are equivalent to the proposed TMCC).
  • Stakeholder input (APTA, CTAA).
  • National ITS Architecture.
  • Relationship to United We Ride and other human services transportation coordination efforts.

III. TMCC System Overview

This section describes what the TMCC will do: the how and when of its activities and functions.

a. High-level diagram(s) of the TMCC. This section presents the depictions of the TMCC configurations. In the generic system, these high-level diagrams were presented in figure 2 and figure 3. System designers may also choose to present specific schematics for each subsystem. The diagrams present the configuration and interaction of these subsystems, whether it is a physical configuration, a virtual configuration with the presence of centralized hardware and data base support, or a virtual configuration without the presence of centralized hardware and database support.

These diagrams are meant to show the relationship of the TMCC to each of the subsystem and transportation system elements. The final diagram(s) and configuration of the TMCC should ultimately be completed by the primary stakeholders and local implementation team. The diagram(s) may serve as the basis for any operational scenario diagrams presented in the "Operational Scenarios" section of the concept of operations.

b. Text description of this diagram.

c. Description of high-level system parameters, such as:

  • System scope (geographical boundaries, stakeholders).
  • Goals and objective of the TMCC. For example, a goal of the TMCC is to increase the mobility of all users of the transportation system, while the objective of the TMCC would be the steps which are taken to achieve this goal. In this case, the objectives are to expand the service area, service hours, or staff productivity while remaining within the existing budget.
  • Users (define their relationship to the system).
  • System interfaces (internal and external, user relationships, sub-system relationships).
  • System states or modes (operating modes, how relationships with other sub-systems change with each mode).
  • System capabilities (high-level).
  • System architecture.

IV. Operational Description of the TMCC

The model deployment site which is selected will affect how this section of the concept of operations is completed. This section largely defines high-level functional requirements, operational constraints, and staff roles and responsibilities. It describes the current operating conditions, why the TMCC is needed (justification), and the nature of the changes the TMCC will have on the existing transportation system.

a. Operational overview.

  • Describe the current transportation system. For example: modes (for example, normal, maintenance, training, and emergency) or operations.
  • Define existing systems. Reference the list of sample sub-systems in Part I, g. of this document
  • Identify the functional requirements that must be satisfied by the model deployment.
  • Define what subsystems will be added as part of the TMCC model deployment. Again the list of sample sub-systems acts as a starting point.

b. Staffing. Define the roles and responsibilities of staff within each agency that is included in the system. In the generic system, they are either Primary or Secondary Stakeholders, Interest Groups, or Users/Customers. Interest Groups and Users/Customers do not need to be assigned responsibilities, as they are not likely to be directly involved in the design and deployment of the notional TMCC.

c. Operational processes (when, in what order, operations take place).

  • Describe the existing system. Specific elements will be dependent on the model deployment site. The generic system's concept of operations includes a detailed description of the existing transportation capabilities, modes, and operations; it should also include a list and short description of all ITS that are currently in use and all coordination activities that are taking place.
  • Describe the interface(s) among existing and proposed systems. The generic system's concept of operations describes how the TMCC elements will fit together. For example, the system may operate via a central, physical center. It also may operate as a virtual center with centralized hardware and databases. Finally, it could also operate virtually with NO centralized hardware or database support. The deploying agency may develop a unique scheme for how the TMCC will operate and interface with their existing systems. The diagrams and schematics may assist in these descriptions.
  • Describe the institutional framework and constraints for the existing transportation system and ITS.
  • Describe the system's operation from each user's perspective. The generic system's concept of operations includes short descriptions of each stakeholder's role in both the entire transportation system and in the proposed TMCC operation.
  • Describe the steps taken to accomplish each TMCC activity. The generic system concept of operations lays out sample activities that should be completed by each staff position as a trip is booked. It is not necessary to provide specific steps for each staff position, as this may cause the concept of operations to become too detailed. The generic system relies on flow charts to effectively communicate this information.
  • Describe the nature of the proposed changes (caused by the deployment of the TMCC) in the transportation system. The generic system considers and describes operational, institutional, or technological changes.

V. Relationship of the MSAA TMCC to the National ITS Architecture.

Agencies should use the National ITS architecture diagram as a starting point for defining the relationship of the TMCC to the National ITS Architecture. Existing connections (operational, institutional, technological, and stakeholders) and new connections required by the TMCC are then realized. While the relationship of the TMCC to the National and regional ITS architecture will ultimately need to be explored by the deployment site, it does not necessarily have to be completed within the creation of the concept of operations. This section merely reminds the stakeholders that these relationships will need to be considered at some point during the deployment process.

VI. Operational Needs

This section defines the policies and issues that need to be addressed by stakeholders involved in the TMCC deployment. This will help to ensure that the TMCC complements and improves the operations of the existing transportation system. The generic system's operational needs include:

a. The stakeholders' expected outcomes for the TMCC's operation.

b. The institutional issues addressed by the TMCC.

c. The operational policies that are impacted by the deployment of the TMCC.

d. The technology considerations that are required (including both the existing technologies that are impacted - changed or eliminated - and the technologies that must be added) in deploying the TMCC. This section could be presented in a various ways. Some examples are:

  • "The following current system weaknesses will need to be addressed by the TMCC..."
  • "The (physical/virtual) TMCC concept of operations discusses the following needs for the system..."
  • Tabular: column headings = operational category, needs procedures/practices, needed policies. The tabular presentation may provide an easy to reference summary of the operational needs that are satisfied by the TMCC.

VII. Operational and Support Environment

This chapter includes a description of the required operational support environments for the individual agency-based systems and the proposed TMCC. The elements presented in this document are not required - the arrangement (physical, virtual, etc.) of the TMCC will influence how this section is presented. This section describes the TMCC in terms of:

a. Physical facilities.

b. Hardware and software.

  • Hardware.
  • Software.

c. Staffing.

d. Operational Procedures.

e. Other support necessary to operate the deployed system. For example:

  • Human resources.
  • Finance.
  • Management.
  • Consultant.
  • City departments.
  • Maintenance.

VIII. Operational Scenarios

This section presents a list of generic scenarios addressed in the concept of operations. This process begins when the stakeholder group identifies the basic operating scenarios for the system. The total number of scenarios described is dependent on the number and type of stakeholders, unique features of the system (both the entire transportation system and the TMCC), the transportation services that are provided by the agency, the transportation system boundaries, and the number of system states.

a. Scenario Components: The scenario describes the TMCC operating scheme in general. In the case of the generic system, the configuration that would be described would be a virtual system with centralized hardware. It could also be a physical or virtual system with no centralized hardware, or an alternative deployment method chosen by the stakeholders to deploy the TMCC.

  • Describes the TMCC operation from the perspective of fixed route service, demand response service, flexible service, human service agency demand response service, etc.
  • Describes the TMCC operation from the trip components a rider would encounter: planning the trip, accessing the system, entering/using/exiting the system, and arriving at the trip's destination.
  • Describes the system operations for special circumstances. For example, multi-destination trips, trips which consist of fixed route, paratransit and/or flexible service elements, trips which cross jurisdictions/agency boundaries and multi-modal trips.
  • Documents the capabilities of each TMCC element or subsystem.
  • Describes how each operating scenario appears to the user/customer groups (i.e., customer perspectives).
  • Describes aspects which change along with the operating scenario.
  • Describes how the institutional situation and inter-jurisdictional/interagency interaction adjusts based on the systems operation, if applicable.
  • Documents the anticipated impacts or improvements made by the TMCC during a specific scenarios.
  • Documents the disadvantages and limitations of the TMCC during the specific scenarios.
  • Presents alternatives or trade-offs, should there be any available during that specific scenarios.

b. Scenario 1: Normal operations. The overview of normal operations should include certain 'unexpected' aspects of normal operations, such as:

  • Normal information request and travel (from trip booking to completion and post trip back office processing).
  • Real-time itinerary change requests.
  • Simultaneous scenarios.
  • Maintenance activities.

c. Expanded scenarios:

  • Changes in service providers/brokers.
  • Changes in participating human service programs.


1 http://www.its.dot.gov/msaa/msaa_overview.htm, "Initiative Overview" presentation, slide 3, accessed January 11, 2006.
2 An effective concept of operations should be written by a team. The team should primarily consist of those stakeholders "who will be at the core of the system, those who will be the immediate users." The team should be a core group of stakeholders, as opposed to all stakeholders. This ensures that "the system development focuses on those stakeholders whose need for the system is most critical." Source: Federal Highway Administration, Developing and Using a Concept of Operations in Transportation Management Systems, p. 4. (Washington, DC: 2004) http://tmcpfs.ops.fhwa.dot.gov/cfprojects/uploaded_files/Chapter4_Final_Dec16_2004.doc, accessed January 12, 2006.
3 Federal Highway Administration, Developing and Using a Concept of Operations in Transportation Management Systems," A Project Update. (Washington, DC: 2004)
4 Federal Highway Administration, Mobility Services for All Americans Phase 2 Foundation Research Final Report. (Washington, DC: 2005) http://www.its.dot.gov/msaa/msaa2/index.htm, accessed January 12, 2006.
5 Service routes are one type of flexible service. The definition of service routes is as follows: Service routes (also called community bus routes) are "fixed routes that are designed to reduce the distances that elderly persons and persons with disabilities must travel to get to and from bus stops. Typically, smaller vehicles are used, and vehicles travel on neighborhood streets or to mall or hospital doorways to reduce walking distances. Although routes are designed to better meet the needs of persons with disabilities and elderly persons, they are open to the public. Services can be planned as feeders to other fixed-route services and can include a "route deviation" option." Source: EG&G Dynatrend and Crain & Associates, Transit Operations for Individuals with Disabilities, TCRP Report 9, p. 9 (National Academy Press: 1995).

Additional ITS Resources on the Federal Highway Administration Office of Operations Website




RITA's privacy policies and procedures do not necessarily apply to external web sites.
We suggest contacting these sites directly for information on their data collection and distribution policies.