RFI 99-25.pdf

MASSACHUSETTS BAY TRANSPORTATION AUTHORITY

Rail Transit Train Control

REQUEST FOR INFORMATION 99-25

Commbuys Bid # BD-24-1206-MBTA-MBTA-118174

Contact Person:

Mellissa O’Connor Project Manager - Contractor Massachusetts Bay Transportation Authority 10 Park Plaza Boston, MA 02116 moconnor2@mbta.com

ISSUE DATE: 6/20/2025

Please Note: This is a single document associated with a Request for Information (RFI) that can be found on www.COMMBUYS.com. Interested parties are responsible for reviewing and adhering to all information, forms and requirements for the RFI. Responders may also contact the COMMBUYS Helpdesk at COMMBUYS@state.ma.us or the COMMBUYS Helpline at 1-888-MA-STATE. The Helpline is staffed from 8:00 AM to 5:00 PM Monday through Friday Eastern Standard or Daylight time, as applicable, except on federal, state and Suffolk county holidays.

REQUEST FOR INFORMATION

RFI #99-25 / COMMBUYS Bid # BD-24-1206-MBTA-MBTA-118174

Purchasing Department MBTA Procurement & Logistics Address 10 Park Plaza, Room 2810 City, State Zip Code Boston, MA 02116 Procurement Contact Person Mellissa O’Connor E-Mail Address Moconnor2@mbta.com

1. Description:

Through this request for information (RFI) process the MBTA seeks to understand the market for train control technologies.

Several industry terms can refer to this set of technologies, including computer-aided dispatch (CAD, although may also encompass a wide range of other functions) and centralized traffic control (CTC). This document describes the existing systems, the core functionalities the MBTA is interested in learning more about, and functions that are likely not in scope.

In general, the MBTA is interested in learning about off-the-shelf systems that perform a narrow set of train control functions – the center of the “bullseye” diagram below. Instead of additional features or customizations, the MBTA is interested in exploring options for robust data access so that agency-specific needs (e.g., data analysis, rider information, views for field supervisors, service management) can be performed in other, less-critical systems downstream from train control – the exterior layer of the bullseye diagram.

Context

The MBTA currently owns and maintains an in-house train control overlay system that, among other functions:

Reads data from the signal system (e.g., switch and signal status, track circuit occupancy), Presents dispatching information to the operations control center (OCC), Allows dispatchers to control switches and signals, and Performs automated route-setting and ring-off based on basic service management schedules.

This system has been in place for over 25 years. The MBTA is interested in learning about commercial, largely off-the-shelf alternatives for the following reasons:

End-of-life technology: The system is approaching the end of its useful life and could require in-house investment to ensure continued reliability, security, and responsiveness to operational needs.

Maturation of market and MBTA capabilities: Historically, if the MBTA wanted to give dispatchers or officials a new feature, the only option was to customize the train control system.

This added complexity and hence risk/cost to an operations-critical system. Today, the MBTA has other operations tools (e.g., Glides) that can be customized for support service delivery without risk to critical train control functions. The MBTA’s train control system hence does not need to be highly customizable. But it does need to provide robust and secure APIs and data access for integration with other MBTA systems.

Rail transit system description

The MBTA’s train control system covers the Red Line, Orange Line, and Blue Line heavy rail services.

For these lines, the existing train control system provides basic service management functions (e.g., digital train sheets, terminal management, and ring-offs). The existing system also consolidates signal system and GPS data from light rail (Green Line and Mattapan Line) vehicles. But train protection, service management, and other functions happen outside of the existing system.

The MBTA’s expectation is that a commercial train control system should cover a similar scope.

Goals

The MBTA is primarily interested in learning about the following features, roughly in priority order:

Centralized Traffic Control – Centralized manual command and control, route setting. Receives and displays information about the signal system and enables OCC to control switch and signal functions.

Service Management [limited] – The MBTA expects most “service management” functions to occur outside of train control (e.g., crew assignments, schedule assignments, yard management, operator communication). However, the train control system should likely include certain core automated, schedule-based dispatching functions such as terminal management, automated ring-off, automated route-setting for branches, and train-tagging.

Data Availability – Data from the train control system is essential for the operation of downstream service management technologies, on-time reporting systems, and other critical MBTA needs. The train control system must make all system data available via documented APIs and securely accept “write” commands or data imports from certain external systems (e.g., scheduling system uploads, schedule adjustments from other systems, assignment of train tags).

Theater Visualization – Graphical representation of train control data for use in the OCC and elsewhere.

Principles

In addition, the MBTA is interested in technology that is modern, secure, and modular. The MBTA has goals for how these features should be delivered and is interested in learning how these goals align with currently available solutions.

Highly reliable. While not technically safety-critical like the underlying signal system, train control is an operations-critical function and the MBTA expects 99.999% (“five nines”) annual availability.

Off-the-shelf. While some provision for the MBTA’s underlying signal technology and operating environment is essential, the MBTA wants to limit customization of the train control system for cost, supportability, and flexibility reasons.

Modular and interoperable. Instead of customizations, the MBTA expects a train control vendor to provide well-documented data access so the MBTA and other vendors can implement any custom needs and analyses in downstream, less-critical systems.

Secure and resilient. The MBTA expects train control systems to implement information security protection consistent with best practices for mission-critical operations technology (not necessarily enterprise IT) and existing MBTA practices.

Non-goals

The MBTA is less interested in these functions:

Passenger information: The MBTA expects to continue pulling train control data into other, existing systems for managing and publishing real-time alerts, countdowns, and vehicle locations to the public.

Service management [extensive]: The MBTA expects existing and planned tools like HASTUS, Radix, Glides (in-house light rail service management app) and Orbit (in-house heavy rail service management app) will handle most schedule, operator, and service management functions outside of terminal management.

The MBTA is interested in solutions that allow external service management decisions to be visible and reflected in train control functions (e.g., train sheets and automated ring-off)

2. Requested Information (RFI Response):

Please formulate a response of not more than 15 pages. Material such as a title page, table of contents, and supplemental material or appendices are not included in that limit.

Response should be submitted in COMMBUYS and should address the following topics:

MBTA procurement features and goals

1. Please describe how your solution delivers on the following features:

o Centralized traffic control o Service management [limited] o Data availability o Theatre visualization

2. Please describe how your solution adheres to the MBTA principles for the system:

o Highly reliable o Off-the-shelf o Modular and interoperable o Secure and resilient

Specific product questions

3. Does your solution offer features that support managing and monitoring personnel or work vehicles on the ROW (Right of Way)?

4. Are your theatre visualizations configurable, and if so, is it possible to change those visualizations without significant vendor support?

a. Does your product support visualizing line speed and temporary speed restrictions?

b. Please provide examples of how your system displays track circuit occupancy, including common situations such as a switch being placed into manual “on hand” operation.

5. How does your product maintain a log of system activity and allow for review? (E.g., playback of track circuit occupancy and train movements, actions taken by dispatchers in the train control interface, API requests from external systems).

Interoperability

6. Does your system ingest schedule data from transit scheduling software like HASTUS?

7. Does your system ingest schedule data from industry-standard feeds like GTFS or TODS?

8. Does your system ingest real-time location data from outside the signal system? (E.g., on-board

GPS, dead reckoning)

9. Does your system provide APIs to query data from the system including:

a. Vehicle location and status

b. Device (e.g., field logic, routing, switch position) status

10. Does your solution provide APIs for sending requests/data to the system including:

a. Service management adjustment (e.g., ring-offs, train sheet adjustments)

b. Route-setting (e.g., assigning routes to trains based on external information)

Infrastructure

11. What kind of infrastructure (e.g., back-office servers, field technology) is required for your system to function?

12. Please describe the protocols your solution supports including

a. What protocols do you recommend for the highest bandwidth communication between the signal system and the train control solution?

b. How are you able to support legacy protocols like Modbus RTU? The MBTA has a mix of equipment that uses both Modbus RTU and Genisys protocols.

13. What platforms are supported for dispatcher workstations? E.g., Linux, Windows, web based.

14. What infrastructure (data centers etc.) are needed to support high availability?

Support services and training

15. Describe how your solution makes diagnostic data available to customers (e.g., device connectivity, failure codes, content versioning). Does this include a provided graphical interface as well as APIs or other machine-readable endpoints?

16. Please describe the kind of bench testing equipment required to operate and maintain your solution and how that equipment would be provided.

17. What is your model for implementation and training, and what are representative implementation and training costs?

18. Would the MBTA be able to configure your product to support changes to the underlying transportation network or signal infrastructure? (E.g., track circuit changes, station renaming, track reconfiguration)

a. Under what circumstance would vendor support be required, and how would that be priced/provided?

Financial and legal considerations

19. Please describe the ownership and licensing model for your system, including software code, hardware, and the data the MBTA would store in your system.

20. Please describe your license model including types of licenses.

21. Please provide representative pricing information for your solution. Assume unlimited MBTA users (although please note whether those assumptions conflict with your cost model). This pricing should include:

a. Upfront costs for system installation, setup, and cutover.

b. Ongoing license and support costs

c. Estimated hardware lifecycle and replacement costs

22. What kind of offboarding and uninstallation activities (and costs, if any) would you expect when the system reaches end-of-life, or the MBTA chooses to move to a new vendor?

23. Please describe the cost model associated with your software and upgrades. E.g., is there continuous deployment of new features? Are there any costs associated with security updates and new features?

Information Security

24. Briefly describe your information security controls and processes.

25. What types of Information Security certifications/attestations does your platform support/provide?

Software Accessibility

26. Is your solution and included documentation compliant with Web Content Accessibility Guidelines (WCAG) version 2.1, levels A and AA? If not, in what areas is the solution noncompliant?

27. Does your solution have a complete Accessibility Compliance Report (ACR) from the latest version of the VPAT 2.1 (Voluntary Product Accessibility Template) or equivalent? If so, does the ACR include reporting for WCAG 2.1 levels A and AA (AAA optional) and Functional Performance Criteria (Section 508 requirements)?

Experiences and references

28. Please provide up to three case studies including, if possible, the following information:

o The signal technologies used by those customers and how your solution integrates with those systems.

o The timeline from contract signing to full implementation.

3. Next Steps

Upon receipt of responses, the MBTA may request additional information or demonstration of system capability through email or virtual meeting.

Responses to this RFI will be used to understand currently available capabilities and determine the merits of moving forward with a Request for Proposal (RFP). If the decision is to move forward, the MBTA will post an RFP on COMMBUYS, and endeavor to notify all companies that respond to this RFI.

4. RFI Calendar

Procurement Activity Date Time

RFI Published June 20, 2025

Deadline for Submission of Questions through COMMBUYS “Bid Q&A”

July 8, 2025 4:00 p.m.

Response to Questions Posted Online July 11, 2025

Deadline for Responses (“Bid Opening Date/Time” in COMMBUYS)

July 17, 2025 2:00 p.m.

Responders are required to monitor COMMBUYS for changes to the RFI calendar for this Bid.

5. Online Questions (Bid Q&A)

Written Questions must be entered through the “Bid Q&A” tab for the Bid in COMMBUYS no later than the Questions Due date and time indicated in the RFI Calendar (above). The MBTA reserves the right not to respond to questions submitted after this date. It is the Responder’s responsibility to verify questions that were successfully posted on COMMBUYS.

Written Responses to Questions will be posted on the Bid Q&A Tab in COMMBUYS on or about the “Response to Questions Posted Online” date indicated in the RFI Calendar (above).